In my experience, PF operates a LOT more like commercial firewalls in how you think about filtering and NAT.
In Linux, even with nftables you still have the concepts of "chains" which goes all the way back to the ipchains days. IME this isn't a particularly helpful way of viewing things. With PF you can simply make your policy decisions on in or out and on which interface(s). Also I'm not sure I ever saw a useful application of why you'd apply a policy on the pre/post-routing chains that wasn't achievable elsewhere in PF and in a simpler way.
Also I've never been a fan of having a command that just inserted or deleted a policy instead of working from a configuration file. (nft "config" files are really just scripts that run the command successively.) I get why some folks would want that (it probably makes programmatic work a lot easier) but for me it was never a benefit.
Anyhow it's been a long time since I've had to do this kind of thing so maybe I'm out of touch on the details. Happy to hear about how I'm wrong lol.
yeah but the likelihood of this is incredibly remote. It would shock me if ISPs didn't have alarms going off if RFC1918 space was suddenly routable within their BGP table.
Not to mention the return packet would be NAT'd so the attacker would have to deal with that complication.
The return packet wouldn't be NATed, because stateful NAT tracks connections and only applies NAT to packets that belong to outbound connections.
Arguing over how likely this is is missing the point. If it can happen at all when you're running NAT, then it should be clear that NAT isn't providing security.
“if it protects 99.999% of attackers from reaching you but not this one specific attacker in this one case of misconfiguration, it’s not providing security”…
Dude, that’s a really shitty take and this is why people that do care about security end up ignoring advice from anyone who thinks this way.
You’re in the camp of “don’t use condoms because they can break”.
NAT doesn't protect you from 99.999% of attackers though. It doesn't do anything to incoming connections, so it actually protects you from 0% of attackers.
Nobody on the Internet can send a packet to an internal IP on your network except for immediate L2 neighbors (I.e. your ISP).
Symmetric NAT 100% stops inbound unsolicited connections to the public IP. And using the public IP is the only way 99.999% can address you.
I implore you to write down (even if just for yourself) what the packet headers would be for you to get a packet from Starbucks WiFi to the device at your home at 192.168.0.5 that has made no egress connections.
You’ll quickly find what you’re suggesting is nonsense. port address translation requires an entry to function. It’s not some optional security feature. It’s required information to get the packet header rewritten to reach private devices.
You can't get a packet from a random store wifi network to your home network when your home network is using 192.168.* (barring something like routing headers, which most routers wouldn't process). You said that yourself in the first part of your post, and I don't think I ever argued otherwise.
> Symmetric NAT 100% stops inbound unsolicited connections to the public IP
No, it doesn't. If it did it wouldn't be possible for routers to accidentally make their web admin or UPnP interfaces available to the Internet.
It doesn't stop connections to your router, and it doesn't stop connections through your router either. It just plain doesn't stop connections, which is why it protects you from 0% of attackers.
Okay, but unless you've poked a hole through NAT (and if you have, presumably you know what you're doing), what are those incoming connections going to connect to?
If there's nothing to connect to, is there really an incoming connection?
They connect to whatever IP is specified in the packet's "destination IP" header field. It's exactly the same behavior as if there was no NAT going on.
No, it might belong to the router. If it does then the connection goes to the router, but if it's set to a LAN machine's IP then the packet gets routed to the LAN machine.
You aren't in control of the contents of inbound packets, and NAT won't filter them to enforce anything about the destination IPs in them either.
The same problem applies to masquerading. Routers are happy to route packets they receive, and NAT (in whatever form) isn't the tool you use to drop those packets.
I used to be connected to the community where stuff like this was passed around. But that was a long, long time ago.
reply