3 ms·
It's not the same scenario at all. If there's no route to the destination then the packet will necessarily be dropped, but with no matching NAT state table entr
by Dagger2 8y ago
It's not the same scenario at all. If there's no route to the destination then the packet will necessarily be dropped, but with no matching NAT state table entry for a packet all that happens is that the dst header field is left alone.
There will still be an IP in the dst header field! The router will still deliver the packet to that IP, subject to all the usual constraints (e.g. it needs a valid route etc). NAT won't stop that; only a firewall will.
- AnIdiotOnTheNet 8y agoAnd in practice what that means is that the router's own IP is the destination and the packet ends up at a closed port. Unless of course you're talking about using NAT outside the context of the RFC1918/internet boundary, in which case you're absolutely right, but that wasn't what was being discussed.
- Dagger2 8y agoIsn't it? I thought we were talking about NAT, not about RFC1918. Even NAT in combination with RFC1918 doesn't give you security. The use of RFC1918 would certainly limit the set of people that could connect to your LAN machines, but it would be hard to call the result secure since anybody sharing your upstream L2 network, plus your ISP and anyone who can trick, force or coerce them into cooperating could still access your network. And what does NAT add to the situation? Certainly not any security, since any connections that were possible before you added the NAT will still be possible afterwards too. In fact a lot more connections will become possible, so it seems like it reduces the security rather than improves it.
- bartwe 8y agoTerminology shifted, when NAT is talked about it is generally considered to be MASQ NAT to RFC1918 ranges
- Dagger2 8y agoEven then, that would still only put you into the situation in the second paragraph of my previous post. You would still need a firewall, and if you have a firewall then shifting to RFC1918, adding MASQ NAT or even doing both won't help, because inbound connections are already blocked.
- AnIdiotOnTheNet 8y ago> call the result secure since anybody sharing your upstream L2 network, plus your ISP and anyone who can trick, force or coerce them into cooperating could still access your network Ok, so the L2 thing isn't unheard of, but otherwise these are relatively unrealistic scenarios to be concerned about, don't you think?
- Dagger2 8y agoI guess, but the fact remains that using RFC1918 is still both more effort and less secure than just using a firewall is, and that NAT doesn't help the situation. Do you really want the security of your network to rely on your ISP always doing the right thing for you?
- quicklyfrozen 8y agoThe destination IP will be for the router itself, so the router can either re-deliver the packet to itself or drop it. I don't see how NAT isn't an effective inbound firewall by itself in the normal case where it's in front of local non-internet-routable IP addresses.
- Dagger2 8y agoIt won't necessarily be for the router. The packet could be addressed to one of the machines on your LAN, in which case nothing NAT does will stop the router from happily forwarding it right through. NAT does nothing to stop a router from forwarding any given packet -- and that's something that's still true regardless of what IP range you're using on the LAN side.