Comment by mannyv
17 days ago
You are wrong because you are being overly pedantic.
NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate).
Your definition of security is too narrow.
And saying that NAT is broken all the time, implying that NAT is not security, is ridiculous. SSH is 'broken' all the time. TLS is broken all the time.
Here's the end point: NAT effectively reduces the attack surface for a home network to the router. That is security, practically speaking.
> And indeed, if a firewall is off NAT can still function (if NAT is separate).
Well technically you can translate your /16 to look like a different /16 from the outside. IE each internal address gets turned into its own separate external address.
But that's not how NAT gets used in practice. How it actually gets used is to but many hidden addresses behind one or a few public addresses. And that multiplexing necessarily implies that incoming connections must be specifically told where to go; ie that there's a firewall.
No, it doesn't imply that.
Let's say your LAN is using 192.0.2.0/24, and your router has 203.0.113.42 on its WAN interface. With NAT, outbound connections from 192.0.2.x will appear to be coming from 203.0.113.42 -- in your words, the 192.0.2.x addresses on the LAN are hidden behind 203.0.113.42.
Now imagine an inbound connection to 192.0.2.10. Does this connection need to be told where to go? It already clearly states where it needs to go in the packet itself: to 192.0.2.10, and the fact that your outbound connections all appear to be coming from 203.0.113.42 didn't prevent that at all.
So no, NAT doesn't necessarily imply that incoming connections need to be told where to go. The packets themselves can specify that.
> NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
Any good firewall does the same, by having a default “no” rule for incoming connections.
> A firewall is not required for NAT to work
Do you have any examples of NAT that isn't implemented in a more general firewall subsystem?
> NAT effectively reduces the attack surface for a home network to the router.
While true, this doesn't add to the argument for/against IPv6. That is just security provided by default configuration, which can be provided many other ways and could be before the subset of NAT you are talking about was common.
> Do you have any examples of NAT that isn't implemented in a more general firewall subsystem?
When I was a network engineer, we did NAT on edge routers for B2B connections all the time. Like literally hundreds of thousands of them. I am 100% serious on this.
My understanding is that almost all edge routers provide at least basic firewalling, not just pure routing. How were you “doing NAT” on the edge routers you were using otherwise?
(Baring in mind that what most people are referring to as NAT here and elsewhere is “IP masquerading with connection tracking” rather than simple static SNAT & DNAT)
3 replies →
> NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
Which NAT?
A 1:1 'basic' NAT [1] could allow stateless flow between two different address schemes. Then you have NAPT where multiple IPs can be mapped via one-IP-many-port system, in which you need state and thus have a filtering mechanism.
Similarly you can have IPv6 ULA and do a stateless address translation (NPT) without any blocking policy, which would achieve the same (lack of) security as the 1:1 scenario above.
Address translation can have the same level (or not) of security in both IPv4 and IPv6.
[1] https://datatracker.ietf.org/doc/html/rfc2663#section-4.1.1
Busses aren't for safety. Seatbelts and airbags and etc are. Busses are just for moving large numbers of people around efficiently.
And yet statistically I'm safer on a bus. Therefore it's reasonable to ride the bus "for safety".
I would phrase it as: NAT accidentally "breaks" or "makes harder/impossible" something which yields increased security, under some circumstances.
It doesn't though. NAT edits your outbound connections to appear to come from the router's IP; it doesn't do anything to make inbound connections harder.
14 replies →
> NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
No... it doesn't do that.
NAT edits your packets so that your outbound connections appear to come from your router's IP. If you set up a port forward rule, then it edits matching inbound connections so they appear to be coming to a different destination IP.
Notice how no part of that description involves blocking or preventing inbound connections. That's because that's just not something NAT does.
Non-routeable internal addresses are pretty effective at preventing external actors. When most people say "NAT", that is what they mean.
You are technically correct in that 1) disallowing external actors is not a property of "NAT" itself, 2) theoretically someone could establish routing to your RFC-1918 network if they had ISP control or had layer-2 adjacency.
Practically speaking, this is not a problem. NAT + RFC-1918 addressing provides a layer of security. Is a firewall better? Of course.
So what do you think will happen with a packet that arrives at the router with destination IP set to the router's IP, and destination port set to some port for which there is no port forward rule (and no currently open TCP connection)? Will it reach some machine on the network, or will it get dropped/NACKed?
It will reach the router, obviously. If it's a TCP SYN packet and there's a server listening on that port, you'll connect to that server. If there's no listener then you get a RST.
4 replies →
>NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
No. NAT enables internal, non-routable (cf. rfc1918[0]) actors on the inside to access external resources on the Internet. Generally, that's done via NAT masquerade[1] (one-to-many NAT), but can also be done with one-to-one NAT.
>A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate).
No. It isn't. And if you enable NAT without firewall rules, it will happily expose your internal network to external actors. In fact, that's the whole point of NAT.
In fact, not using IPv4 NAT is enormously more secure than using IPv4 NAT, assuming you're using RFC1918 addresses internally. Primarily because non-NATted RFC1918 addresses won't be forwarded by routers on the Internet (CGNAT notwithstanding).
>Here's the end point: NAT effectively reduces the attack surface for a home network to the router. That is security, practically speaking.
Again, no. Enabling NAT increases the attack surface for all networks, regardless of type. Without NAT, external actors need to compromise your router first, then get it to accept spoofed packets.
Yes, there's detail that I've ignored, as it's irrelevant to the statements made. Most of that is related to "I want to access Internet resources, but my ISP won't give me anything but a single, ephemeral, routable IPv4 address, so I need to use NAT to share that one address."
That's not an argument for the "security" of NAT, it's an argument for being mad at your ISP, especially if they won't give you a /56 block of IPv6 addresses.
[0] https://www.rfc-editor.org/rfc/rfc1918
[1] https://en.wikipedia.org/wiki/Network_address_translation#On...
> No. It isn't. And if you enable NAT without firewall rules, it will happily expose your internal network to external actors. In fact, that's the whole point of NAT.
How exactly would a regular NAT implementation, such as s consumer router's NAT, remove security compared to a direct connection? Assuming there is no port forwarding configured, the NAT will drop (or NACK) any packets addressed to the router's IP on any port that doesn't correspond to a currently open connection.
Since the machines behind the NAT have RFC1918 addresses, remote actors will not be able to send a packet to them, other than by sending packets to the router's IP.
So, overall, a NAT box with no firewall rules configured still acts like a stateful firewall for remote attackers. It's true that attackers that have access to the WAN port of the router, such as someone infecting your ISP, can still send traffic directly to the RFC1918 addresses behind the router, and the router would deliver them (whereas with a firewall, those would also get dropped). So a firewall is still preferable, but the difference in security is actually quite low.
> In fact, not using IPv4 NAT is enormously more secure than using IPv4 NAT, assuming you're using RFC1918 addresses internally. Primarily because non-NATted RFC1918 addresses won't be forwarded by routers on the Internet (CGNAT notwithstanding).
This statement makes no sense. If you are not using NAT of some kind, and your machines only have RFC1918 addresses, then your machines can't access the Internet at all. Now, sure, that is quite secure - but you can get the exact same security by disconnecting the WAN port of the router, with the exact same effects - so this is quite irrelevant to the use-cases being discussed.
>How exactly would a regular NAT implementation, such as s consumer router's NAT, remove security compared to a direct connection? Assuming there is no port forwarding configured, the NAT will drop (or NACK) any packets addressed to the router's IP on any port that doesn't correspond to a currently open connection.
No one (at least not me) said anything about a "direct connection" (which I assume means using globally routable IPv4 addresses on your internal systems).
Nor did anyone say anything about not forwarding any ports. In fact, much of the discussion has been about how "secure" NAT is when forwarding ports, with some folks claiming that doing so is all you need. Or did you miss those 80-100 comments?
>This statement makes no sense. If you are not using NAT of some kind, and your machines only have RFC1918 addresses, then your machines can't access the Internet at all.
Exactly. That was my point. And if you add NAT without stateful firewall rules to limit access, your internal systems are exposed.
I tell you what: post the IP address/range of your home network, turn off the firewall you're using and just leave NAT enabled as it is right now and we can see for ourselves just how "secure" bare NAT is. What do you say?
Unsecured NAT (i.e., without, at a minimum, firewall rules limiting connectivity -- a default deny rule at least) is not secure at all.
I've said (now twice) what I had to say. Feel free to disagree (again) and/or downmod my post, but my decades of experience professionally implementing networks, the security infrastructure which attempts to secure them, at the perimeter as well as at the LAN, server and endpoint informs my opinion.
Don't agree? That's fine with me. It's no skin off my nose. I have no axe to grind with you or anyone else around this or anything else.
Have a good day.
Edit: Clarified the "Globally routable" addresses as IPv4.
1 reply →