NAT is awesome. It automatically forces users to have a stateful border firewall that makes incoming connections impossible.
Is that a real, full firewall? Heck no, I'm equally worried about what my systems leak than outside threats, and it does nothing for that.
but aren't we nitpicking a little here? veering on the "technically correct, worst kind of correct".
Yes, but that's because it's co-located with a stateful firewall, sharing the same connection tracking state. Without that firewall, if a device on the WAN side sends to your router a packet with destination address on the LAN side, your router will route that packet to the LAN, even though it's not a reply to anything sent from the LAN to the WAN. That is: it's a misconception that port mapping NAT blocks incoming connections; port mapping NAT only affects outgoing connections and replies to them.
This can happen only if the device is directly attached to the NAT server. Basically, only your ISP can do that.
Most NAT servers by default also prohibit this kind of routing (because why even allow it?!?), but even the most misconfigured bad NAT server is still vulnerable only if you control the ISP, in practice.
But it is. Even a "full" firewall can't do anything against something on one of the inner host leaking into the outside. Most of the traffic is encrypted, even DNS. So the firewall can't operate on much more than the destination address to decide if a connection should be allowed.
If you want more security, you need to secure individual endpoints.
I suspect when people talk about "NAT" in the context of a residential connection, what they actually mean is a "default-deny firewall with connection tracking".
(Are you going to point out that statelessly blocking a fixed IP range used to be called "firewalling" so a device without connection tracking can still technically be a "firewall" next?)
A system that can't track connection state, or doesn't have enough capacity to do so at line rate, can't meaningfully firewall. When the norm for home equipment is ISPs sending it out for "free", they absolutely send out the cheapest stuff they can get away with, and in the pre-smartphone era that meant "modems" that would just provide a straight PPPoA connection with no firewalling.
Pretty much everything else in a firewall in the modern world is just useless feature creep.
Take two networks that are identical, except one is doing NAT and one isn't, and test them. Every connection that works on the without-NAT network will also work on the with-NAT network. The only difference you'll find is that some outbound connections which didn't work on the former will work on the latter.
Some would argue that "every connection that used to work still works, and some connections that didn't work before do now work" is kind of the opposite of a firewall.
It absolutely does. There is no way with NAT to connect from the outside network to the inside ("but what if the attacker is directly attached to the next hop blahblahblah"). That's all that firewalls need to do, everything else is useless noise in the current world.
> Take two networks that are identical, except one is doing NAT and one isn't, and test them.
Here's my IP: 192.168.80.36. Feel free to attack me. Go on. The public IPv4 of my router is 76.191.126.81. I even opened a port 8871 for you with a static page with a Bitcoin wallet worth $1000, you just need to get to it.
You can't. There's no way to get to my computer without hacking the NAT server first.
That's why NAT _is_ a firewall, and a foolproof one at that. It's secure by default, unlike IPv6 firewalls that can fail open.
https://sh.itjust.works/pictrs/image/421c9549-83ee-487a-9fa0...
When I set one up for you (back here: https://news.ycombinator.com/item?id=39173556) I gave you the access needed to actually do the test (...but you either missed that message or opted to ignore it, so you never tried it). You need to either move your network to routed IPs or give me a tunnel to the upstream network of your router first.
Not doing either of those doesn't make you right. NAT is still not acting as a firewall here. I'm just not in a position to take advantage of that, due to your use of RFC1918 addresses on the LAN side.
Nope. Even with a misconfigured box that forwards the traffic from WAN to LAN, you need to be in the direct contact with the NAT server (an OpenWRT box). And that's the point, you are _not_, as is pretty much everybody else in the world, outside of people who have keys to my house and my ISP.
In practice, this provides all the practical security you need from a firewall.
> I'm just not in a position to take advantage of that, due to your use of RFC1918 addresses on the LAN side.
Well, duh. That's the whole point of NAT (when used typically). You don't get to access my internal network, you simply can't do that physically.
All you need to be able to do is send a packet that ends up at your router with the dest IP set to one of your LAN machines. This only requires being directly attached to your router if you're using RFC1918 on the LAN; if you're using a properly routed prefix then it can be done from anywhere.
> Even with a misconfigured box that forwards the traffic from WAN to LAN
Forwarding traffic from WAN to LAN isn't a misconfiguration. Your router needs to do that for TCP to work, or get replies to outbound UDP.
Or control the internal network of my ISP.
> All you need to be able to do is send a packet that ends up at your router with the dest IP set to one of your LAN machines.
Which you can't do.
> if you're using a properly routed prefix then it can be done from anywhere.
If I had a publically routed /24, then I wouldn't be using NAT in the first place. Which is the case in point: NAT _is_ a firewall.
> Forwarding traffic from WAN to LAN isn't a misconfiguration
Sigh. I mean allowing the SYN packets to be forwarded from WAN to LAN.
Whether or not someone can get that packet to your router in the first place is a separate question. If you're using RFC1918 then yeah, they'd need access to your direct upstream network. But the point I've been trying to make is that NAT doesn't influence the answer to this question: whether or not you do NAT has no influence on the behavior of any of the routers upstream of you.
NAT has no influence on whether these packets can reach your router or not, or on whether your router will forward them if they do arrive. That's why it's not a firewall: because it's not actually doing any firewalling.
> If I had a publically routed /24, then I wouldn't be using NAT in the first place. Which is the case in point: NAT _is_ a firewall.
It's not possible to go from "I wouldn't be using NAT if I had a routed /24" to "NAT's a firewall".
If you had a routed /24 then you might not use NAT, but that says nothing about whether NAT works as a firewall or not. The relevant part isn't "would I still be using NAT if the situation was different?", it's "does NAT block inbound packets?". Since it doesn't, it's not.
> Sigh. I mean allowing the SYN packets to be forwarded from WAN to LAN.
Well, yeah, allowing those is generally a misconfiguration... in the firewall. The routing part of the router doesn't pay any attention to TCP flags, just IP addresses.
You quite regularly see people pop up in these threads arguing something like, oh, I dunno, "In IPv6 typically every machine on a LAN is directly connected to the internet with a public IP address. Every one of those machines now needs a full strength internet firewall.", as if this is somehow a problem with IPv6 rather than a problem with their own understanding. It's hard enough to get people to deploy v6 as it is without them mistakenly believing that a lack of NAT means their router can't provide firewalling either.
NAT wasn't invented for the home-broadband user, you know.
But I'm at least glad we've cleared up the myth that NAT provides any security benefit when, in fact, it's the often deployed accompanying stateful firewall that's actually providing this.