Comment by deng
1 month ago
Before you engage in discussions, may I suggest to look into RFC 4787, especially section 5 about filtering behaviors of NAT: https://datatracker.ietf.org/doc/html/rfc4787#section-5
Several things can be correct at the same time:
* NAT is not a firewall
* NAT can still filter traffic (and practically always does)
* NAT can hence still provide security features
* The real world often does not care about original definitions of a term. NAT was originally meant to just do address translation, but it has evolved.
* Of course, ipv6 is not less secure because it doesn't have NAT, as the same filtering behavior can be replicated with a firewall. That may even have advantages over NAT.
RFC 4787 does not really describe how real world implementations behave. As almost all SOHO routers are Linux-based, i prefer to discuss Linux netfilter-based NAT behavior than some hypothetical RFC 4787 NAT. There are clear differences. For example, RFC 4787 says:
> REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior
While Linux netfilter behavior is "Address and Port-Dependent Mapping".
As Linux netfilter implements both NAT and firewall behavior, it is relevant for the discussion which parts of overall netfilter behavior falls into 'NAT part' and which into 'firewall part'. There is clear distinction - DNAT/SNAT rules in nat table represent NAT behavior, while REJECT/DROP rules in filter table represent firewall behavior.
As Linux-based SOHO routers are usually configured with both NAT and firewall netfilter rules to implement both NAT and firewall behavior, one cannot answer question 'Does NAT filter traffic?' based on external behavior of such SOHO routers, but has to analyze which part of the network stack is responsible for such behavior, or how the same network stack configured with just NAT rules and no firewall rules would behave. And here the answer is no, it would pass traffic (that do not match existing connections) unmodified.
The problem is: what is an implementation detail, and what is NAT as a concept? This line is very blurry. The RFC does not really distinguish this and also doesn't want to. As it says, it tries to document behavior and explicitly uses the term "NAT filtering". When we say "This box here does NAT", then we implicitly assume this behavior. You might argue that implicit is not good, and I would agree (this is the advantage of ipv6 with firewall: filtering is explicit rather than implicit). However, if someone tells me "Well actually, NAT does not do filtering, the firewall does", then to me this is similar to arguing with staff in a supermarket that the tomato belongs in the berries section.
I also want to make clear that I fully agree with the article's main point: NAT's primary purpose was and still is address conservation, and that ipv6 is no less secure than ipv4. I do disagree though with the notion that "NAT does not do filtering" or that "NAT does not provide any security".
NAT:
Firewall:
If you omit the first line, you get firewalling without NAT. If you omit the second set of lines, you get NAT without firewalling. This should make it pretty clear that they're orthogonal features.
If NAT functioned as an inbound firewall, the second set of lines wouldn't be necessary and removing them wouldn't let you make inbound connections. But you can just test it yourself, and you'll see that NATing your outbound connections doesn't block new inbound ones.
10 replies →
All the Linux routers I've used utilize Endpoint-Independent mapping with Address- and Port-Dependent _filtering_.
This means you can still establish direct P2P connectivity behind a Linux-based NAT device with users behind other Linux-based NAT devices. The only time it becomes an issue is when attempting to communicate with users behind NAT devices that do Address-Dependent _mapping_ or Address and Port-Dependent _mapping_. Some *BSD-based NAT implementations are this way.
Endpoint-independent _filtering_ is only a good idea for CGNAT implementations. Having an EIM/EIF NAT/firewall setup without additional firewalling makes it possible and easy for devices to run public-facing UDP-based servers without anyone's knowledge. With EIM/EIF, once you create a NAT mapping, so long as you send out periodic keepalives, _any_ IP address with _any_ source port can make unsolicited connections to a server that the NAT mapping points to. The best compromise is Endpoint-independent mapping with Address- (but not port-) dependent filtering.
> Of course, ipv6 is not less secure because it doesn't have NAT, as the same filtering behavior can be replicated with a firewall. That may even have advantages over NAT.
I don't think this follows - defaults matter after all. More precise would be to say that IPv6 setups can be as secure as IPv4 setups.
CPE like wifi router+nat boxes do by default have IPv6 firewall on, so s/can/is/
That whole section is talking about outbound connections:
When you connect outwards, the NAT creates a state table entry which matches inbound packets corresponding to that outbound connection, and this section is discussing which packets will match those entries.
Don't get distracted by its use of the word "filtering". It's not talking about unsolicited inbound connections, which is what we're talking about in this thread.
> That whole section is talking about outbound connections
Erm... no? Immediately after the paragraph you cited, it continues with
and then, on "Address-Dependent Filtering", it says
Meaning: unsolicited inbound connections will be filtered out.
And if I think back to my 30 years of IT, environments with NAT end up with lazy engineering from systems and application folks. It doesn't provide an environment that forces folks to understand their problems holistically. Thus, relying on perimeter firewalling and NAT as a large catch all. It's a bad security practice imo
The correct way is hard. You either have to manage firewalls on each host, or your switches need to have firewalls (I assume that’s a thing?). Hosts on the same subnet never hit layer 3 so IP-based firewalls don’t see them.
You either need very static infrastructure so you can hard-code firewalls on the hosts, or you need a system to dynamically manage the firewalls on each host, or an SDN that can sanely manage layer 2 flows. Little things like moving an app to a new server become a whole project unless you have really good tools to reconfigure the firewalls on everything that touches the app.
Then you need a way to let people self-service those rules or else security has to be involved in like everything just to do firewall rules.
It’s a good idea, but a huge pain and I’ve not seen good solutions
That's why I like mesh overlay networks (things like Tailscale, Nebula, etc.). You can largely set host firewalls to deny all, and access services over the overlay network which is software defined and more easily managed and deployed at scale.
It doesn't solve all problems, but its a good start, and modern MDMs & Group Policy (on the Windows side) make managing host firewalls easy enough.
It doesn't solve your self-service problem, though I'd argue self-service when it comes to host firewalls or otherwise shouldn't be a thing anyway.
Yep, rfc19188 addressing leads to accumulating complexity due to workarounds (end-to-end addressing is simple, there are very good reasons for that design), addressing ambiguity, and various practical security problems.
Do you prefer to install firewalls on smart light switches and kettles?
I think you're on my side in this discussion, but I have to say you can't really point at an RFC and say it settles an argument; RFCs can also be wrong about stuff, and the further you get from bits laid out on the wire, the less trustworthy they are.
> you can't really point at an RFC and say it settles an argument
This is pretty much the opposite of what I'm doing. I'm saying: look at that RFC, where they write that NAT filters incoming traffic! If even people writing RFCs say this, it is obviously an established notion of the term "NAT".
What I'm arguing against is this obsession with being technically correct; that NAT can only be literally "network address translation" and nothing else, and that you are incompetent if you think otherwise (plenty of examples for this further down).
What I'm saying is: look, things in the real world are messy, and terms can change their meaning.
Sure, I agree with you on that. I'm just fussy about authority citations to RFCs.
1. NAT is not firewall.
2. "NAT" is changing addresses. PAT (port address) is the most common type.
3. "Firewall" is dropping packets.
4. The same component can (and often does) do address translation and filtering.
5. A NAT precludes some security features: "NAT reduces the number of options for providing security." [1]
6. A NAT provides some degree of anonymity.
7. IPv6 can have (but does not require) NAT.
[1] https://www.rfc-editor.org/rfc/rfc1631.html
I see this backwards. If my machine is only secure because of the magical firewall that practically blocks everything, then it isn't really secure, especially in a world were so many devices make it physically past the NAT and can be compromised by looking at old CVEs
One more important thing to note:
If you really feel you must have NAT, there is IPv6 NAT. Unlike IPv4 NAT, V6 affords enough address space that IPv6 NAT can do 1:1 IP:IP mapping between internal and external. This eliminates entire classes of issues around port exhaustion and port remapping and allows P2P applications to work fine. P2P NAT traversal with simple 1:1 NAT has a nearly 100% success rate on the first attempt.
> V6 affords enough address space that IPv6 NAT can do 1:1 IP:IP mapping between internal and external.
That's the very thing those who consider IPv4 NAT to be a desirable feature don't want.