Comment by Dagger2
23 days ago
Right, we were talking about NAT. So how is any of that non-NAT-related stuff relevant?
> Sure, but the Internet will not route packets going to RFC1918 addresses
This is about RFC1918, not NAT.
> So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped.
This is about reverse path filtering, not NAT.
> And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused.
And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.
> And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.
Fine. Packets that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection, an explicit port forwarding rule, OR the port of a service on the router itself listening on the WAN IP will also get refused.
The point is that any LAN box sitting behind the NAT will not get that packet, same as if the router had a stateful firewall running.
And sure, this is not purely a property of the NAT itself, it's a combination of the Internet not routing private IP addresses, reverse path filtering, and NAT. That still doesn't need any firewall to achieve this.
Well no, it's purely a property of the fact that the packet is addressed to the router.
If the packet is addressed to a machine on the LAN, neither RPF or NAT will protect you from it. "The Internet won't route to private IPs" only protects you if you have private IPs on the LAN, and even then it only protects you from people who can't get access to the network on your WAN interface.
Any way you dice it, NAT isn't providing any protection.