Because this is exactly what the GP was claiming, and you denied: even without a firewall, packets that don't correspond to an open connection will get dropped by a NAT, even without a firewall. Sure, maybe "dropped" is wrong, as the NAT box will probably instead send a RST packet, but this is almost entirely irrelevant.
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.
Because this is exactly what the GP was claiming, and you denied: even without a firewall, packets that don't correspond to an open connection will get dropped by a NAT, even without a firewall. Sure, maybe "dropped" is wrong, as the NAT box will probably instead send a RST packet, but this is almost entirely irrelevant.
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.
1 reply →
Because that is the most common NAT configuration for 99.99% of residential users. Anything else is academic discussion.
And in this common configuration, NAT does nothing to prevent inbound connections.
Do you admit using RFC-1918 + NAT provides some security even with no firewall for the majority of residential users?
2 replies →