NAT does not, in any way, "force" the use of a firewall. They're entirely separate concepts.

NAT _is_ a firewall. And it provides the same level of security as pretty much all of the "firewalls" marketed as such.

No... it's not? It's simply a widely-used technique to rewrite the addresses of IP packets that transit a router. It inherently makes no policy decisions on which packets should and shouldn't flow over and above what a router does anyway.

I’ve never seen one without the other, so while technically correct, not useful to debate.

shrug at work we use NAT to let two different networks with overlapping addresses talk to each other all the time. No firewalls there.

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.

We out-number companies, perhaps by an order of magnitude.

Not by allocated IP address count.

It's useful to correct this misunderstanding, because people often take "I've always seen NAT come with firewalling" to mean "firewalls are impossible without NAT".

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.

It automatically prevents the outside world from being able to access the inside network. Which is the main function of most of the firewalls.

Pretty much everything else in a firewall in the modern world is just useless feature creep.

It doesn't do that. It rewrites the source address that outbound connections appear to come from; it doesn't implement any kind of access control.

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 doesn't do that. It rewrites the source address that outbound connections appear to come from; it doesn't implement any kind of access control.

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.

I've just remembered the firewall alignment chart, which asserts a view of the world that an excavator is a firewall.

https://sh.itjust.works/pictrs/image/421c9549-83ee-487a-9fa0...

It's possible to get to your computer without hacking the "NAT server", but I'm not in a position to do it. There's no point setting up a demonstration if you don't make it possible for me to actually do the demonstration!

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.

> It's possible to get to your computer without hacking the "NAT server", but I'm not in a position to do it.

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.

No, you don't need to be in direct contact with the NATing router. That's kind of the entire point we're trying to making here.

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.

> No, you don't need to be in direct contact with the NATing router.

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.

You can do it from anywhere on the Internet, you don't need to control the ISP's network or anything. If your NATing router receives a packet with the dest IP set to a LAN machine, it forwards it to said LAN machine regardless of where that packet came from, unless blocked by a firewall.

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.

NAT is by definition not a firewall. And while it provides security, it provides no more security than having a firewall, while making various scenarios worse. NAT is not a good solution for security.

It forces the use of some system that statefully tracks packets and makes routing decisions based on that information. Such a system will be capable of firewalling unless you go out of your way to make it not.

No, your thinking of a stateful IPv4 home style NAT. There's also stateless subnet mapping.

There are some stateless things that are also called NAT, sure, but that's not what we're talking about here. (Fairly obviously, since a stateless mapping doesn't and can't save addresses).

But this feels tautological. It's been reduced to "If you want to use NAT with features that only a firewall gives you, then that forces you to use a firewall".

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".

Feel free to replace "NAT" with "the kind of NAT that permits you to share an address between multiple devices" if you feel the need to be pointlessly pedantic about it. The point is that any device that allows sharing a single IP between multiple devices will necessarily implement connection tracking, and will therefore be capable of functioning as a firewall.

(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?)

Pretty much any system that's capable of handling IP traffic is also capable of firewalling. Not sure what that's got to do with address rewriting though.

> Pretty much any system that's capable of handling IP traffic is also capable of firewalling.

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.

In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whatever) it does block incoming connections, only allowing replies to internally-originated traffic, and to do that it tracks the state of all traffic.

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".

> In the most commonly (almost exclusively, in case of end users) deployed setups (call them NAT Masquerade, NAT Hide, NAT Overload, NAT Many-to-One, PAT, whatever) it does block incoming connections, only allowing replies to internally-originated traffic, and to do that it tracks the state of all traffic.

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.

> if a device on the WAN side sends to your router a packet with destination address on the LAN side

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.

> 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 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 second this, it forces security by default (at least keeping devices from being directly exposed)