Hacker News Reader

Comment by simoncion | Hacker News Reader

I think it is true... at least on Linux. I am pretty sure that if my firewall didn't have this line in the filter table

   -A INPUT -i wan-interface -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

along with this line in the nat table (or the equivalent with the SNAT target if you have a static WAN IP)

  -A POSTROUTING -o wan-interface -j MASQUERADE

then IPv4 NAT simply wouldn't work... well, not the NAT that nearly all regular folks have on their home networks.

It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0] But it's the decisions made in the firewall that both make the NAT work, and ensure that WAN traffic that hasn't been requested stays out.

[0] Unless the router were "excitingly" misconfigured!

View on HN

The second line is the only one you need for NAT to work. The first is irrelevant to forwarded traffic. If you have no other rules then a) NAT will be applied to your outbound connections, and b) you'll have no firewall for the network behind the router.

NAT and firewalling might both done in netfilter via iptables/nftables rules, but they're completely orthogonal decisions. You can do either of them without the other.

> It is true that without the firewall's involvement the router would drop all traffic destined to the LAN. [0]

Which means this is completely wrong. It won't do this unless you do something to make it do this (i.e. put some rules into FORWARD that control what traffic is/isn't allowed). MASQUERADE just changes the source IP on outbound connections; it doesn't drop inbound connections.

> [0] Unless the router were "excitingly" misconfigured!

This is probably the pivotal difference lol. Most of the ISP-provided routers I've used either have a default-allow policy or auto-create firewall rules when you add a NAT forwarding rule. I don't honestly recall which because it's been like a decade, but I do remember that I didn't have to explicitly add a firewall rule.

The exciting misconfiguration I was thinking of was one where Internet hosts could send packets to the router with LAN IPs as the destination IP and the router would happily forward those along and output them on the LAN interface(s).

On a Linux router, perhaps setting ip_forward to 1 and leaving rp_filter at 0 would do the trick? It has been ages since I've had to play with rp_filter, so I can't remember exactly what its behavior is.

Reply on news.ycombinator.com