Comment by Dagger2
6 days ago
It keeps getting repeated precisely because it isn't gaslighting. And yet we still see people claiming that NAT is security.
The only reason those networks aren't exposed to the whole Internet on v4 is because they're using RFC1918, not because of NAT -- but that still leaves them exposed to some outside networks, so routers come with firewalls, which act as an actual security boundary.
And they won't be exposed on v6, because those exact same firewalls work their magic on v6 too.
NAT doesn't provide and isn't needed for security. Its main security contribution is to confuse people about how secure their network is.
NAT effectively stops inbound connectivity at the NAT edge. A system could be a dozen hops beyond that and no inbound traffic can reach it.
IPv6 (without any NAT) means that the source and destination are fully routable.
How folks DON'T see this as a functional component of security is beyond me.
I'd expect folks would see the behavior you're describing here as being part of security.
However, NAT in the real world doesn't work the way you're describing here. My position is based on how NAT actually behaves, not on incorrect descriptions of how it behaves.
Or perhaps you could explain how NAT stops inbound connectivity at the NAT edge? I've tested and it doesn't, so I don't think it's possible to explain how it does, but I'm open to being wrong on that if anybody could actually explain it in a way that doesn't contract actual observed behavior.
Look I get where you're going with this. I do. All things being equal, a device that routes packets will route packets whether or not a NAT is in place. That's not the issue at hand.
The situation is simply that except in the rarest of cases, you're not going to be able to manipulate routing to achieve getting a packet with a RFC1918 (let's be real here, this is what we're talking about 99.9% of the time) destination address to go anywhere, much less to the target. Or more broadly, getting a packet addressed for a target behind a NAT to route TO a NAT gateway. Not to mention that if somehow it did get through, return packets are almost guaranteed to end up NAT'd, preventing traffic flow. So there's that.
On the Internet, even if your ISP didn't drop your packets outright, the routers wouldn't have the faintest idea how to route your packets to your victim.
Not Internet? Ok, let's say you're on a corporate network. You're a user and not a network admin.
Your company has a VPN to a partner company, and you're both using various subnets in 10/8. The partner has provided 192.168.1.0/24 of 1:1 NAT addresses so your two companies can share data, etc.
But there is no route in the IGP to the partner company's 10/8 network, only a block of 192.168.1.x addresses, none of which you are able to use. A magic fairy tells you that partner's payroll server has admin/admin credentials at 10.5.5.5. How are you going to get across the VPN to that address?
You won't, because you can't. Because there's no route, and in the case of a VPN, the interesting traffic probably doesn't include that IP even if you got a packet that far.
It's all simply a question of routing. Whether your traffic is being dropped by a firewall or dropped by a router, it's still being dropped.
FWIW I was a network engineer and architect at a massive enterprise for almost 15 years, and my team had management over all our Internet circuits, NAT, our WAN, etc. At the time I left we probably had >200k 1:1 NAT addresses; mostly across B2B links for management access of our devices on customer premises. It was an enormous PITA.