* 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".
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state INVALID -j DROP
iptables -A FORWARD -i lan0 -j ACCEPT
iptables -A FORWARD -j REJECT --reject-with icmp-admin-prohibited
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.
LAN IP address spoofing is indeed a valid attack vector, if the ISP is compromised.
Internal daemons on machines other than the router itself in the LAN network listening on 0.0.0.0 are not insecure (unless you have the problem from point 1, malicious/compromised ISP). The router won't route packets with IPs that are not in its LAN to them. Of course, the router itself could be compromised if it accidentally listens on 0.0.0.0 and accepts malicious packets.
Not sure what you mean by reflection amplification attacks, but unless they are attacking the router itself, or they are arriving on WAN with LAN IPs (again, compromised/malicious ISP), I don't see how they would reach LAN machines.
Whichever machine has the NAT's external IP assigned to it will accept or refuse the connection, depending on whether they have a server running on that port or not.
The machine that has the NAT's external IP to it is, well, the NAT, by definition. So you admit that the NAT box will act almost exactly like a connection tracking firewall, even if only NAT is enabled.
No, I'm not going to "admit" that, because I know full well that it won't.
It's not like I'm sat here thinking "I know it does block traffic, but I'm going to lie to everyone that it won't". NAT in fact, actually, really and honestly, doesn't block traffic, and I think I've been pretty consistent in saying as much.
You've been consistently wrong, yes. A NAT router box will NOT translate a packet coming from the Internet (so, a packet with a globally routable IPv4 address) arriving on its WAN to the RFC1918 IPv4 address of any box sitting behind it on the LAN side, unless it is arriving on a previously open connection, or on a port the user explicitly asked to be allowed and forwarded - exactly the same behavior of a regular stateful firewall.
Of course it won't do that -- when did I ever claim it would? But that's not the same behavior as a stateful firewall at all.
A stateful firewall would block packets addressed to the router, or to machines behind it. NAT not translating a packet won't do either of those things.
I can only repeat myself: you are talking about the NAT module in the Linux netfilter. I, and the RFC, are talking about NAT as a concept: what behavior do you expect when you say "this device does NAT". Of course you can still have "pure NAT", but if someone tells you "set up a device that does NAT" and you omit that first line and later explain that this is historically and technically accurate, well, good luck with that.
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.
That whole section is talking about outbound connections:
When an internal endpoint opens an outgoing session through a NAT,
the NAT assigns a filtering rule for the mapping between an internal
IP:port (X:x) and external IP:port (Y:y) tuple.
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
The key behavior to describe is what criteria are used by the NAT to
filter packets originating from specific external endpoints.
and then, on "Address-Dependent Filtering", it says
Additionally, the NAT will filter out packets
from Y:y destined for the internal endpoint X:x if X:x has not
sent packets to Y:any previously [...]. In other words, for receiving packets from a
specific external endpoint, it is necessary for the internal
endpoint to send packets first to that specific external
endpoint's IP address.
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.
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.
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
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.
For those of you with this handy technology, the mobile phone, in the United States: you have an IPv6 address without NAT. Some of you even exist on a network using 464XLAT to tunnel IPv4 in IPV6, because it's a pure IPV6 network (T-Mobile). These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons.
This is all to underscore the author's point: NAT may necessitate stateful tracking, but firewalls without translation has been deployed at massive scale for one of the most numerous types of device in existence.
> These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons.
FWIW, I was interested so I tested this on my phone here in Finland (Elisa, the largest carrier here): IPv6 inbound TCP connections work just fine, unlike IPv4 which is behind CGNAT.
On mobile broadband (no calls) plans they also offer optional free public IPv4 address, but not on the regular phone plans.
(I did the test by installing Termux from Play Store, then in it running "pkg install netcat-openbsd" and "nc -6 -l 9956" and then connecting to that port from internet using telnet, while phone was not connected to WiFi.)
In the case of T-Mobile, unsolicited inbound IPv6 connections are blocked, but direct P2P is still possible. I successfully established a WireGuard tunnel over IPv6 between 2 phones. With IPv6, since the internal addresses and ports and the same end-to-end, all that is needed is a dynamic DNS service; STUN isn't necessary. I did need to set a persistent keepalive of 25 seconds on both sides of the tunnel to keep the firewall holes open.
Interestingly, Verizon Wireless blocks connections to other Verizon Wireless IPv6 addresses. T-Mobile-to-T-Mobile connections work, Verizon-to-T-Mobile connections work, but Verizon-to-Verizon connections do not work. Given the way Verizon's network has stagnated while T-Mobile's network has been rapidly improving, it may be time to move away from Verizon.
Slightly off-topic, but if you have a modern Google Pixel phone, Google includes "free" VPN service (which probably collects/sells your data). This service uses Endpoint-Independent filtering, so if you send an outbound packet with the source port you want to map, regardless of the destination IP/port, you can effectively receive unsolicited inbound connections from any host on the internet that contacts your IP:port, so long as you send a periodic keepalive packet from the source port you are using to anywhere.
This is how researchers were able to remotely hack several Chrysler models. They used a Sprint hotspot to get an IP on the cell network and were able to connect to any other Sprint device. The cellular modems on these cars were on Sprint so they just had to be on the same network. I wonder if Verizon intentionally blocks this.
What would be the obvious reasons? (I'm not being flippant here -- I'm genuinely interested in what arguments people have to not allow servers on that network)
High concentration of technically inept users with hardware that no longer receives security updates and has plenty of well known easily exploitable vulnerabilities. Which naturally is used to run banking apps and travels with users close to 24/7 while tracking their location.
From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use. The internet APs the carriers sell get deprioritized relative to phones when necessary and the fine print generally forbids hosting any services (in noticeably stronger language than the wired ISPs I've had).
> From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use
Isn't that already the case with limited plans?
For example, mine has 40 GBs and I'm pretty sure it counts both upload and download, because I generally consume very little, except for one week when I was on holiday with no other internet access and wanted to upload my pictures to my home server and didn't otherwise use the phone more than usual.
Facebook would start listening on port X and and then their embedded SDK in other websites or app would query that IP and port, get their unique id, and track users much better.
The most common use case for mobile data servers is probably pwned cheap/old phones forming DDoS swarms. Pure P2P over internet is very rare on mobile, no sense not blocking ingress from the perspective of ISPs.
However for that having the phone's IP not reachable has at best marginal benefits. The DDoS itself is an outgoing connection, and for command and control having the compromised phone periodically fetch instructions from a server is simpler to implement than the phone offering a port where it is reachable to receive instructions
I kind of doubt this, as the rapidly changing nature of mobile IP addresses would mean that a periodic outbound connection would still be necessary to keep the attack up-to-date on the compromised devices current IP address. At that point, you may as well have the compromised device periodically poll an attacker-controlled server for instructions rather than jump through a bunch of hoops by getting things to work over inbound connections.
I think it should vary based on the type of service being provided. Truly mobile service, I think it can make sense to not allow servers. If its being sold as a home internet solution (a more fixed kind of plan), I think it should allow servers to at least some level of hosting services.
The main difference is there's usually limited airtime capacity for clients, especially highly mobile ones. A server could easily hog quite a bit of the airtime on the network serving traffic to people not even in the area, squeezing out the usefulness of the network for all the other highly mobile people in the area. This person moves around, pretty much doing the equivalent of swinging a wrecking ball to the network performance everywhere they go.
When its being sold as a fixed endpoint though, capacity plans can be more targeted to properly support this kind of client. They're staying put, so its easier to target that particular spot for more capacity.
The phone providers oversell bandwidth. They also limit the use of already purchased bandwidth when it gets legitimately used.
Similar to many industries, their business model is selling monthly usage, while simultaneously restricting the actual usage. They are not in the business of being an ISP for people running software on their phones.
Being allowed to serve data from your own device should be seen as a natural human right.
If the networks don't have capacity or something then we need networks that can support that.
The idea that all of that has to go in the Fediverse on a server or something is just gatekeeping.
Wait a few years as IPV6 becomes truly ubiquitous. This will become very obvious to everyone and standard. People must be allowed to communicate directly, even if they have a lot of clients.
The opinions are slightly similar to remote work. Telecommuting was an obvious next step for a long time, it just took a certain number of decades for society to realize it.
This is the first thing that as a Network Engineer I was taught - and every formal security class I've taken (typically from Cisco - they have awesome course) - repeats the same thing.
I believe the common knowledge is somewhat more nuanced than people would have you believe
I present to you two separate high-value targets whose IP address has leaked:
Target #1 has an additional level of security in that you need to figure out how to route to that IP address, and heck - who it even belongs to.
Target #2 gives aways 90% of the game at attacking it (we even leak some device specific information, so you know precisely where it's weak points are)
Also - while IPv6 lacks NAT, it certainly has a very effective Prefix-translation mechanism which is the best of both worlds:
Here is a real world target:
FDC2:1045:3216:0001:0013:50FF:FE12:3456
You are going to have a tough time routing to it - but it can transparently access anything on the internet - either natively or through a Prefix-translation target should you wish to go that direction.
For your example, shouldn't you either present two "private" IP addresses, in which case you'd replace the IPv6 address in your example with what is likely to be an autoconfigured link-local address (though any ULA address would be valid as well),
OR present the two IP addresses that the targets would be visible as from the outside, in which case you'd replace the IPv4 address with the "public" address that 192.168.0.1 NATs to, going outbound?
Then, the stated difference is much less stark: In the first case, you'd have a local IPv6 address that's about as useless as the local IPv4 address (except that it's much more likely to be unique, but you still wouldn't know how to reach it). In the second case, unless your target is behind some massive IPv4 NAT (carrier-grade NAT probably), you'd immediately know how to route to them as well.
But presenting a local IP for IPv4, and a global one for IPv6, strikes me as a bit unfair. It would be equally bogus to present the public IPv4 address and the autoconfigured link-local address for IPv6 and asking the same question.
I do concede that carrier-grade NAT shifts the outcome again here. But it comes with all the disadvantages that carrier-grade NAT comes with, i.e. the complete inability to receive any inbound connections without NAT piercing, and you could achieve the same by just doing carrier-grade NAT for IPv6 as well (only that I don't think we want that, just how we only want IPv4 CGNAT because we don't have many other options any more).
In these contexts - neither of the addresses was intended for internet consumption. A misconfigured firewall exposes you in the case of IPv6 routable addresses, and is less relevant in the case of IPv4; the ULA IPv6 address is roughly the same as an RFC 1918 address with it's lack of routing on the Internet.
The point I was (poorly) trying to make is that non-routability is sometimes an explicit design objective (See NERC-CIP guidance for whether you should route control traffic outside of substations), and that there is some consideration that should be made when deciding whether to use globally routable IPv6 addresses.
Mac address is absolutely safe in IPv4 world - the only info it gives is the network card manufacturer.
And people don't usually share "curl ipinfo.io" output unless they plan to share their external IP (unlike "ifconfig" output, which is one of the first things you want to share for any sort of networking problems)
Target #2 [IPv6] gives aways 90% of the game at attacking it (we even leak some device specific information, so you know precisely where it's weak points are)
You may not consider Mac address to he important, but the context of this conversation did bring it up. Of course they forgot the fact that most v6 addressing doesn't expose Mac addresses anymore.
Especially as if someone is able to capture ifconfig data, they can probably send a curl request to a malicious web server and expose the NAT IP as well.
Just because you can think of scenarios where the IPv4 setup doesn't make a different doesn't discount that there are scenarios where it does.
Someone being able to observer some state is a different model from someone being able to perform actions on the system and the former has many more realistic scenarios in addition to the ones of the latter.
I'm not sure I buy the "you get a leak of the address of a high value target you believe can be routed to over the internet in some fashion, but it's the internal address which leaked and you have no idea who could own said high value target either" story.
I agree if it's an actual concern then you can use NAT66 to hide the prefix, I just don't see how this achieves security when the only publicly accessible attack point is supposed to be the internet attached FW doing the translation of the public addresses in the first place.
Additionally, if that really is the leaked IPv6 address then it's formatted as a temporary one which would have expired. If you mean static services which were supposed to be inbound allowed then we're back at the "the attack point is however the internet edge exposes inbound in both cases, not the internal address".
NAT66 doesn't add much in the way of security here, because the external address is fully routable and maps 1:1 to the internal address. You are once again fully dependent on a correctly configured firewall.
The IPv6 address that I shared was, in fact, a static (and real) IPv6 address, belonging to a real device - with the possible exception of the last 3 bytes, was likely one I worked on frequently.
Put another way - to do an apples to apples comparison:
Hard to attack: FDC2:1045:3216:0001:0013:50FF:FE12:3456
Easier to attack: 2001:1868:209:FFFD:0013:50FF:FE12:3456
> NAT66 doesn't add much in the way of security here, because the external address is fully routable and maps 1:1 to the internal address. You are once again fully dependent on a correctly configured firewall.
When using the stateful firewall provided by Linux's packet filter, the IPv6 NAT66 "masquerade" works very similar to IPv4 NAT. 1:1 mapping is NOT required.
For example internal hosts are configured as follows:
inet6 fd00::200/64 scope global noprefixroute
ip -6 route add default via fd00::1
Edit:
From my understanding the NAT66 is ambiguous and it may work as a stateful port-based translation similar to IPv4 NAT, whereas NPTv6 is a stateless prefix-only translation.
It's the same difficulty to attack in all 3 cases: hack the internet firewall, which the only point providing connectivity between both internal and external addresses regardless of what the address itself is.
You don't need to change the prefix to prevent an address from being routed to from the internet, but you do need a firewall if you want an address to be securely reachable from the internet. If you don't want an address to be reachable, what the address is whatsoever doesn't matter so long as you've implemented any possible way of making it unreachable.
Not true, 2001:1868:209:FFFD:0013:50FF:FE12:3456 provides some amount of geographic information about the target that the other addresses do not. No firewall is going to protect you from that. Of course that is only going to matter in the specific scenario where your internal IP is leaked but the attacker has not other way of getting your external IP.
Well - I can't say they have always said this - but at least for Circa 1998 CCNP onwards that's been their position. The instructors were very adamant - to the point that I'm recalling this 27+ years later.
This probably has more to do with network engineers (and CCNP instructors) not being security engineers (or even conversant with Cisco's security SBU).
In the case of IPv4 - you almost certainly would get the external IP address of the unit doing NAT translation. In the case of IPv6 - it's quite common (outside of the enterprise world) for the Native IPv6 address of the device to be routed directly onto the internet - desirable even.
In the case of a 'leaked" address - there are all sorts of ways in which internal details of an address can leak even when it's not in the DST/SRC envelope of the packet on the Internet.
Yup, by default a Linux based router won’t forward any traffic to a IPv6 host unless you explicitly have a program running which keeps on telling the kernel you want that.
I'm sorry, this is just an elaborate argument of obscurity-as-security. You're clinging to privacy as though it were security, in stark avoidance of Kerckhoffs's principle.
You can use Shannon's maxim instead if you're going to be deliberately obtuse. The point is true for any system intended to be secure, and a network is such a system, as is the security software such as the claimed NAT software.
Or do you really want to argue that Linux Netfilter/nftables or BSD pf being open source is a security problem?
It's sad how much of this thread of supposed hackers comes from people who are simply parroting this dogma because it has been drilled into them. People were even preaching this before IPv6 privacy extensions came into use, either downplaying the privacy issues or outright telling people they were bad for wanting privacy because IPv6 is more important.
I understand the difference between NAT and firewall perfectly well. I have deployed and configured both for many years. The strawman of "NAT without firewall" is pretty much irrelevant, because that's not what people run IRL.
Firewalls are policy-based security, NAT is namespacing. In other fields, we consider namespacing an important security mechanism. If an attacker can't even name a resource they're not allowed to access, that's quite a strong security property.
And of course, anyone can spoof IP and try to send traffic to 192.168.0.6 or whatever. But if you're anywhere in the world other than right inside my ISP's access network, you can't actually get the internet to route this to my local 192.68.0.6. On the other hand, an IPv6 firewall is one misconfigured rule away from giving anybody on the planet access.
Yeah, I think it is a bit more subtle of an issue than this flamewar always descends into.
There's people upthread arguing that every cellphone in the country is on IPv6 and nobody worries about it, but I'm certain there are thousands of people getting paid salaries to worry about that for you.
Meanwhile, the problem is about the level of trust in the consumer grade router sitting on my desk over there. With IPv4 NAT it is more likely that the router will break in such a way that I won't be able to access the internet. Having NAT break in such a way that it accidentally port forwards all incoming connection attempts to my laptop sitting behind it is not a likely bug or failure mode. If it does happen, it would likely only happen to a single machine sitting behind it.
OTOH, if my laptop and every other machine on my local subnet has a public IPv6 address on it, then I'm trusting that consumer grade router to never break in such a way that the firewall default allows all for some reason--opening up every single machine on my local subnet and every single listening port. A default deny flipping to a default allow is absolutely the kind of security bug that really happens and would keep me awake at night. And even if I don't go messing around with it and screw it up myself, there's always the possibility that a software bug in a firmware upgrade causes the problem.
I'd like to know what the solution to this is, other than blind trust in the router/firewall manufacturer or setting up your own external monitoring (and testing that monitoring periodically).
Instead of just screaming about how "NAT ISN'T SECURITY" over and over, I'd like someone to just explain how to mitigate the security concerns of firewall rulesets--when so very many of us have seen firewall rulesets be misconfigured by "professionals" at our $DAYJOBs. Just telling me that every IPv6 router should have default deny rules and nobody would be that incompetent to sell a router that wouldn't be that insecure doesn't give me warm fuzzies.
I don't necessarily trust NAT more, but a random port forward rule for all ports appearing against a given target host behind it is going to be a much more unusual kind of bug than just having a default firewall rule flipped to allow.
You could set up a monitoring solution that alerts you if one of your devices is suddenly reachable from the internet via IPv6. It will probably never fire an alert but in your case might help you sleep better. IPv6 privacy extensions could help you too.
In practice I don't think it's really an issue. The IPv6 firewall will probably not break in a way that makes your device reachable from the internet. Even if it would, someone would have to know the IPv6 address of the device they want to target - which means that you have to connect to a system that they have control of first, otherwise it's unlikely they'll ever get it. Lastly, you'd have to run some kind of software on that device that has a vulnerability which can be exploited via network. Combine all that and it gets so unlikely that you'll get hacked this way that it's not worth worrying about.
Thank you. This is the first time that someone admits here that NAT actually adds some security. IPv4 will never go away less that an important share because of it's simplicity and NAT-level security it offers to millions of professionals and amateurs that tinker with their routers.
> SLAAC is more complex than IPv4 w/ NAT w/ DHCPv4? Serious?
Yes? Has this ever been in question?
Stateful DHCP provides a _reliable_ way to configure clients, while SLAAC is anything but. It's also insufficient in itself if you want to configure things like NTP servers.
But that's not the main issue. The main issue is that with SLAAC you are supposed to hand out real routable addresses. That are _not_ controlled by you, so the end devices need to be able to handle prefix withdrawals and deprecations. This can lead to your printer not working if your ISP connection goes down and it has no more active IPv6 prefixes.
So you also need a stable ULA. But even that is not a guarantee because source IP selection rules are, shall we say, not the best.
But wait, there's more! You can trivially load-balance/failover NAT-ed IPv4 network over two WAN connections. Now try to do that with IPv6. Go on. I'll wait.
Except in the real world everyone is also running UPnP, so NAT is also one misconfiguration away from exposing something publicly. In the real world your ISP might enable IPv6 one day and suddenly you do have a public address. Relying on NAT is a bad idea because it's less explicit, a firewall is saying you only want to allow these things through, of course nothing is perfect, you can mess up, but NAT is just less clear, the expectation is not "nothing behind NAT should ever be exposed", it's "we don't have enough addresses and need to share".
Sure, and that's fine, but relying on it isn't, and it isn't a reason not to use IPv6 (if you want namespacing, there are tools for that outside hiding behind a single IPv4). Hence the advice is not to rely on NAT.
This is people talking past each other, and to be fair, saying "everyone" in my post made it unclear, I was being glib in response to "because that's not what people run IRL", when evidently people do, I've seen it happen.
I think this is where the disconnect is: the home users are precisely the ones being talked about, because they are the ones most likely to be treating NAT like it is a security system for their devices in the real world.
I've literally seen someone's ISP turn on IPv6, and then have their long-running VNC service compromised because they were just relying on NAT to hide their services.
> If an attacker can't even name a resource they're not allowed to access, that's quite a strong security property.
This is entirely incorrect. An attacker can still name a resource, it only has to guess the right port number that is mapped to that resource.
That's how NAT fundamentally works after all, it allows you to use the additional 16-bits of the port number to extend the IP address space. Any blocking of incoming traffic on a port already mapped to a local address is a firewall rule.
The reason that it offers protection is because attackers aren't going to try every single port. Compared to that IPv6 will offer more protection as an attacker would have to guess the right address in a 64-bit namespace rather than just a 16-bit one.
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.
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)
In an enterprise network, it's very, very unlikely that an edge router is doing any firewalling. They can do it, but it's not only cumbersome to do it there, but also a massive resource drain.
Often they do basic stateless packet filtering, but definitely nothing akin to stateful, connection-oriented firewalling. It's important to make the distinction, because filtering in this case is completely uni-directional and if you want bi-directional equivalence you have to write an inverse rule for it. Filtering polices are applied per interface, so generally you apply them on the outside only.
Think of it as sort of a reverse of an inbound Internet policy - you write all the drop stuff first (e.g. drop any any eq snmp) and the last rule is a permit ip any any. Next hop is your firewall which does the rest.
For site-tos-site b2b connections, we performed NAT (of the untrusted network space) on the border/edge b2b router, and then the traffic was immediately routed to the firewall. So in this instance, NAT was happening on the router for the customer IP range, and on the firewall for our enterprise IP range.
As a convenience to our customers/partners we always presented ourselves as one of our public IP blocks that wasn't Internet-routed. This prevented them from having any overlapping IP space.
Otherwise, NAT is simply a question of configuring it. And at least in the cisco IOS world (I'm a dinosaur) the two features (NAT vs. firewall) are utterly independent.
> but definitely nothing akin to stateful, connection-oriented firewalling
This is where my confusion comes in, I think.
Surely the variety of NAT that significantly improves the IPv4 address starvation problem (IP Masq by its various names) requires a connection oriented approach to be effective? Maybe not as far as more advanced conntrack rules (trying to get connect-back based protocols to work) but even just a basic stream-over-one port protocol needs basic connection tracking so return packets get back to the right host? If you have enough resource to do that then you have more than enough resource to do the basic “block all external apart from these configured addr+port->addr+port combinations” for IPv6 that is all the protection NAT affords you by accident for IPv4.
> Surely the variety of NAT that significantly improves the IPv4 address starvation problem (IP Masq by its various names) requires a connection oriented approach to be effective?
Actually it doesn't. Well, not really.
With NAT you're generally talking about either 1:1 or 1:many (Masquerading).
In all cases the device doing the NAT maintains a table which is referenced for every matching packet that arrives or leaves.
In 1:1 NAT, the IP in the packet header (Layer-3) is simply rewritten from one address to the other whenever a packet matching both addresses in the NAT table leaves or arrives.
In 1:many NAT, the source port is randomized because you can run into collisions when multiple clients are connecting to the same server:port. So in that case the NAT table contains IP addresses as well as ports. When a return packet arrives, it checks the NAT table and rewrites both the L3 and L4 (port) info before passing it along.
Often times firewalls will randomize the source port when doing 1:1 NAT as a security measure, but after all these years I don't really remember why that's helpful. :-\
But that's really the extent of tracking connections with NAT.
Now when you're talking about firewalling, there's a lot more to track, such as connection start/stop/timeouts/lifetimes, total throughput, TCP state (handshakes, sequence numbers, etc.), closing open sessions when seeing things like TCP RSTs or FINs or ICMP unreachables. The amount of data and CPU is dramatically higher, and tailored to the software doing the firewalling. I believe in many cases simple L3/L4 rewrites can happen in hardware.
I haven't talked about any of this in several years so I hope I'm making sense.
> 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.
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.
If you don't initiate a corresponding outbound connection first then any attempt at an inbound connection will be dropped (unless you have a DMZ configured ofc). The router literally can't forward the traffic because it doesn't know where it should go.
No, the router doesn't forward it because it doesn't get there in the first place. Your 192.168.1.0/24 private network is not going to be routed across the internet.
Sure, but the Internet will not route packets going to RFC1918 addresses. So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped. And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused.
This is all behavior that happens even with no firewall whatsoever.
Because this is exactly what the GP was claiming, and you denied: even without a firewall, packets that don't correspond to an open connection will get dropped by a NAT, even without a firewall. Sure, maybe "dropped" is wrong, as the NAT box will probably instead send a RST packet, but this is almost entirely irrelevant.
Right, we were talking about NAT. So how is any of that non-NAT-related stuff relevant?
> Sure, but the Internet will not route packets going to RFC1918 addresses
This is about RFC1918, not NAT.
> So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped.
This is about reverse path filtering, not NAT.
> And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused.
And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.
> And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.
Fine. Packets that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection, an explicit port forwarding rule, OR the port of a service on the router itself listening on the WAN IP will also get refused.
The point is that any LAN box sitting behind the NAT will not get that packet, same as if the router had a stateful firewall running.
And sure, this is not purely a property of the NAT itself, it's a combination of the Internet not routing private IP addresses, reverse path filtering, and NAT. That still doesn't need any firewall to achieve this.
Well no, it's purely a property of the fact that the packet is addressed to the router.
If the packet is addressed to a machine on the LAN, neither RPF or NAT will protect you from it. "The Internet won't route to private IPs" only protects you if you have private IPs on the LAN, and even then it only protects you from people who can't get access to the network on your WAN interface.
Any way you dice it, NAT isn't providing any protection.
Neither of them prevent inbound connections, on their own or together.
I don't really think that "inbound connections work fine and you're basically just praying that the people that can do them simply won't" counts as being secure, but I'll admit that using RFC1918 does limit the set of people that can do them. If you made that your argument, you'd have more of a point than an argument based around NAT.
Okay! I didn't say it was absolutely secure. A firewall is obviously preferred. I'm just saying it's shades of gray... non-routeable addresses provides a level of security.
> 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.
So, assuming the router doesn't have any server running, the connection will be reset, thus protecting all of the machines behind the router from any incoming connection, almost exactly like a firewall (sure, a firewall might just drop the packet instead of responding with a RST). So, in other words, NAT alone can act like a security perimeter, even with no firewall present.
Because no one on the Internet can reach my 192.168.0.7 machine if the NAT router doesn't translate the packet. And the NAT router won't send a packet that arrives with its public IP as dstIP to any machine behind it, unless the port its ports correspond to an open connection, or to an explicitly forwarded port.
>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.
> 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.
I've explained before, in many threads, that pure consumer NAT, without a firewall, has exactly the same behavior as a consumer stateful firewall, except for two cases :
1. The ISP is malicious/compromised, and sends packets with RFC1918 addresses on the router's WAN port.
2. The router itself has admin services that are listening on public IPs (eg HTTP server listening on 0.0.0.0 instead of 192.168.0.1), so it itself could be compromised from outside the ISP network.
Except for these two points, there is no difference between the security characteristics of a consumer NAT and a consumer firewall:
1. LAN machines can't be reached over the internet other than through the NAT, since a packet addressed to 192.168.0.7 from Google will not be routed by any ISP.
2. When a packet arrives to the NAT with a destination IP set to the NAT public IP, the packet will not be delivered to any box on the LAN unless (a) its ports match an active connection from a LAN box, or (b) its destination port matches an explicit port forward rule an admin added.
Case (a) above is exactly what a stateful firewall with a default deny rule does. Case (b) is also exactly the same, as if you explicitly open a port in this type of consumer firewall, it will allow any packet matching that port.
Now, I wouldn't disable my firewall, because I don't trust that my consumer router is itself well enough secured, and I don't necessarily trust my ISP's network either. But this doesn't mean that my laptop is exactly as secure if it were to sit behind this router with no firewall as it would be if I disabled both firewall and NAT entirely and gave my laptop a publicly routable IPv4.
This goes against Hyrum's law. NAT provides the behavior 99.9% of users want, usually by default, out of the box. True firewalls can do the same thing, but not necessarily by default, the firewall might not even by on by default, and there's more room for misconfiguration. IPv6 is a security regression for most people, regardless of its architectural merits or semantics of what's a firewall.
I wouldn’t put the number so high. I’ve on several occasions seen not very technical people unnecessarily burn money on VPSes or dedicated hosting providers because they couldn’t expose a game server for a evening session with their friends with the spare capacity on their gaming machine, because of their ISPs NAT setup. 90% would be fairer. However we still shouldn’t be sacrificing securing agency of individual consumers for securing smoother revenue for corporations.
I brought up CGNAT because my American ISP does use CGNAT. We are now paying an extra monthly fee for a static IP, which I believe is the only option they have for getting a public IP (i.e. no intermediate fee amount for a public non-static IP).
It might be more fair to say that most American residential ISPs don't have to do that because they have access to giant legacy IPv4 allocations. Comcast alone has 65 million IPv4 addresses, for example (including a /8, /9, and /10 and several /11s).
I think they could make more money using CGNAT and leasing those IPs out to data centers. Also another comment in this thread mentions that their cellular plan sold as a residential internet connection doesn't use CGNAT, but their phone plan from the same company does..
Maybe! CGNAT isn't free, of course, you need pretty beefy machines to handle ISP numbers of clients. So, is the capex for the machines, engineering time to set them up, and opex for keeping them running more or less than they'd make back from leasing their net blocks? Hard to say.
NAT implementations get broken all the time (NAT slipstreaming attacks). If a manufacturer is incompetent enough not to have a firewall on by default, they are probably also shipping a vulnerable NAT.
NAT slipstreaming depends on confusing fragmentation assemblers and application aware parsers. Those exist in firewalls as well. It’s not NAT specific.
And that kind of NAT effectively doesn't exist in practice, so that's quite beside the point. Such a NAT doesn't scale to more than 24 devices behind it.
See my reply to your sibling commenter. My comment was not about NAT in general, i.e. I was not denying the very real existence of stateless NAT. Rather, I was disputing the usefulness of the NAPT solution proposed above as a solution to public IPv4 address exhaustion.
> proposed above as a solution to public IPv4 address exhaustion.
It was not proposed as a solution (although, it would work). I'm pointing out that in networking many names are conflated/used generally against their specific definition. NAT/Firewall; Router/Access Point/Gateway; etc.
No, it very much does. If you want to join two network segments such that on one side all devices are on 10.1.X.X and the other all devices are 10.2.X.X, you'd use a mapping between 10.1.a.b and 10.2.a.b
The general context here is about NATting to the public internet at large, not between particular segments. And the parent of my comment was talking specifically about NAPT, which is different from the non-port-based NAT that you're talking about.
This is a terrible argument. First, NAT doesn't provide the security behavior users want. The firewall on their router is doing that, not the address translation. Second, that firewall is on by default, blocking inbound traffic by default, so why on earth would you conjecture that router manufacturers will suddenly stop doing that if NAT isn't on by default? Third, it's not remotely likely that a user will misconfigure their firewall to not secure them any more. Non-technical users won't even try to get in there, and technical users will know better because it's extremely easy to set up the basics of a default deny config. There is no security regression here, just bad arguments.
The firewall on your typical IPv4 router does basically nothing. It just drops all packets that aren’t a response to an active NAT session.
If the firewall somehow didn’t exist (not really possible, because NAT and the firewall are implemented by the same code) incoming packets wouldn’t be dropped, but they wouldn’t make it through to any of the NATed machines. From the prospective any machine behind the router, nothing changes, they get the same level of protection they always got.
So for those machines, the NAT is inherently acting as a firewall.
The only difference is the incoming packets would reach the router itself (which really shouldn’t have any ports open on the external IP) reach a closed port, and the kernel responds with a NAK. Sure, dropping is slightly more secure, but bouncing off a closed port really isn’t that problematic.
NAT gateways that utilize connection tracking are effectively stateful firewalls. Whether a separate set of ‘firewall’ rules does much good because most SNAT implementations by necessity duplicate this functionality is a bit ignorant, IMO.
Meanwhile, an IPv6 network behind your average Linux-based home router is 2-3 nftables rules to lock down in a similar fashion.
It's also trivial to roll your own version of dropbox. With IPv6 it's possible to fail to configure those nftables rules. The firewall could be turned off.
In theory you could turn off IPv4 NAT as well but in practice most ISPs will only give you a single address. That makes it functionally impossible to misconfigure. I inadvertently plugged the WAN cable directly into my LAN one time and my ISP's DHCP server promptly banned my ONT entirely.
> In theory you could turn off IPv4 NAT as well but in practice most ISPs will only give you a single address
So, I randomly discovered the other day that my ISP has given me a full /28.
But I have no idea how to actually configure my router to forward those extra IP addresses inside my network. In practice, modern routers just aren't expecting to handle this, there is no easy "turn of NAT" button.
It's possible (at least on my EdgeRouterX), but I have to configure all the routing manually, and there doesn't seem to be much documentation.
You should be able to disable the firewall from the GUI or CLI for Ubiquiti routers. If you don't want to deal with configuring static IPs for each individual device, you can keep DHCP enabled in the router but set the /28 as your lease pool.
In the US many large companies (not just ISPs) still have fairly large historic IPv4 allocations. Thus most residential ISPs will hand you a single publicly routable IPv4 regardless of if you're using IPv6 or not.
We'll probably still be writing paper checks, using magnetic stripe credit cards, and routing IPv4 well past 2050 if things go how they usually do.
Went to double check what my static IP address was, and noticed the router was displaying it as 198.51.100.48/28 (not my real IP).
I don't think the router used to show subnets like that, but it recently got a major firmware update... Or maybe I just never noticed, I've had that static IP allocation for over 5 years. My ISP gave it to me for free after I complained about their CGNAT being broken for like the 3th time.
Guess they decided it was cheaper to just gave me a free static IPv4 address rather than actually looking at the Wireshark logs I had proving their CGNAT was doing weird things again.
Not sure if they gave me a full /28 by mistake, or as some kind of apology. Guess they have plenty of IPs now thanks to CGNAT.
More like even if they looked at the logs they aren't about to replace an expensive box on the critical path when it's working well enough for 99% of their customers.
I once had my ISP respond to a technical problem on their end by sending out a tech. The service rep wasn't capable of diagnosing and refused to escalate to a network person. The tech that came out blamed the on premise equipment (without bothering to diagnose) and started blindly swapping it out. Only after that didn't fix the issue did he finally look into the network side of things. The entire thing was fairly absurd but I guess it must work out for them on average.
Did you even read the second paragraph of the (rather short) comment you're replying to? In most residential scenarios you literally can't turn off NAT and still have things work. Either you are running NAT or you are not connected. Meanwhile the same ISP is (typically) happy to hand out unlimited globally routable IPv6 addresses to you.
I agree though, being able to depend on a safe default deny configuration would more or less make switching a drop in replacement. That would be fantastic, and maybe things have improved to that level, but then again history has a tendency to repeat itself. Most stuff related to computing isn't exactly known for a good security track record at this point.
But that's getting rather off topic. The dispute was about whether or not NAT of IPv4 is of reasonable benefit to end user security in practice, not about whether or not typical IPv6 equipment provides a suitable alternative.
> But that's getting rather off topic. The dispute was about whether or not NAT of IPv4 is of reasonable benefit to end user security in practice, not about whether or not typical IPv6 equipment provides a suitable alternative.
And, my argument, is that the only substantial difference is the action of a netfilter rule being MASQUERADE instead of ALLOW.
This is what literally everyone here, including yourself, continues to miss. Dynamic source NAT is literally a set of stateful firewall rules that have an action to modify src_ip and src_port in a packet header, and add the mapping to a connecting tracking table so that return packets can be identified and then mapped on the way back.
There's no need to do address and port translation with IPv6, so the only difference to secure an IPv6 network is your masquerade rule turns into "accept established, related". That's it, that's the magic! There's no magical extra security from "NAT" - in fact, there are ways to implement SNAT that do not properly validate that traffic is coming from an established connection; which, ironically, we routinely rely on to make things like STUN/TURN work!
> Dynamic source NAT is literally a set of stateful firewall rules that have an action to modify src_ip and src_port in a packet header, and add the mapping to a connecting tracking table so that return packets can be identified and then mapped on the way back.
Yes, and that _provides security_. Thus NAT provides security. You can say "well really that's a stateful firewall providing security because that's how you implement NAT" and you would be technically correct but rather missing the point that turning NAT on has provided the user with security benefits thus being forced to turn it on is preventing a less secure configuration. Thus in common parlance, IPv4 is more secure because of NAT.
I will acknowledge that NAT is not the only player here. In a world that wasn't suffering from address exhaustion ISPs wouldn't have any particular reason to force NAT on their customers thus there would be nothing stopping you from turning it off. In that scenario consumer hardware could well ship with less secure defaults (ie NAT disabled, stateful firewall disabled). So I suppose it would not be unreasonable to observe that really it is usage of IPv4 that is providing (or rather forcing) the security here due to address exhaustion. But at the end of the day the mechanism providing that security is NAT thus being forced to use NAT is increasing security.
Suppose there were vehicles that handled buckling your seatbelt for you and those that were manual (as they are today). Someone says "auto seatbelts improve safety" and someone else objects "actually it's wearing the seatbelt that improves safety, both auto and manual are themselves equivalent". That's technically correct but (as technicalities tend to go) entirely misses the point. Owning a car with an auto seatbelt means you will be forced to wear your seatbelt at all times thus you will statistically be safer because for whatever reason the people in this analogy are pretty bad about bothering to put on their seatbelts when left to their own devices.
> in fact, there are ways to implement SNAT that do not properly validate that traffic is coming from an established connection; which, ironically, we routinely rely on to make things like STUN/TURN work!
There are ways to bypass the physical lock on my front door. Nonetheless I believe locking my deadbolt increases my physical security at least somewhat, even if not by as much as I'd like to imagine it does.
The difference is that with IPv4 you know that you have that security because there is no other way for the system to work while with the IPv6 router you need to be a network expert to make that conclusion.
Look at this nftables setup for a standard IPv4 masquerade setup
table ip global {
chain inbound-wan {
# Add rules here if external devices need to access services on the router
}
chain inbound-lan {
# Add rules here to allow local devices to access DNS, DHCP, etc, that are running on the router
}
chain input {
type filter hook input priority 0; policy drop
ct state vmap { established : accept, related : accept, invalid : drop };
iifname vmap { lo : accept, eth0 : jump inbound-wan, eth1 : jump inbound-lan };
}
chain forward {
type filter hook forward priority 0; policy drop;
iifname eth1 accept;
ct state vmap { established : accept, related : accept, invalid : drop };
}
chain inbound-nat {
type nat hook prerouting priority -100;
# DNAT port 80 and 443 to our internal web server
iifname eth0 tcp dport { 80, 443 } dnat to 192.168.100.10;
}
chain outbound-nat {
type nat hook postrouting priority 100;
ip saddr 192.168.0.0/16 oiname eth0 masquerade;
}
}
Note, we have explicit rules in the forward chain that only forward packets that either:
* Were sent to the LAN-side interface, meaning traffic from within our network that wants to go somewhere else
* Are part of an established packet flow that is tracked, that means return packets from the internet in this simple setup
Everything else is dropped. Without this rule, if I was on the same physical network segment as the WAN interface of your router, I could simply send packets to it destined to hosts on your internal network, and they would happily be forwarded on to it!
NAT itself is not providing the security here. Yes, the attack surface here is limited, because I need to be able to address this box at layer 2 (just ignore ARP, send the TCP packet with the internal dst_ip address I want addressed to the ethernet MAC of your router), but if I compromised routers from other customers on your ISP I could start fishing around quite easily.
Now, what's it look like to secure IPv6, as well?
# The vast majority of this is the same. We're using the inet table type here
# so there's only one set of rules for both IPv4 and IPv6.
table inet global {
chain inbound-wan {
# Add rules here if external devices need to access services on the router
}
chain inbound-lan {
# Add rules here to allow local devices to access DNS, DHCP, etc, that are running on the router
}
chain inbound-nat {
type nat hook prerouting priority -100;
# DNAT port 80 and 443 to our internal web server
# Note, we now only apply this rule to IPv4 traffic
meta nfproto ipv4 iifname eth0 tcp dport { 80, 443 } dnat to 192.168.100.10;
}
chain outbound-nat {
type nat hook postrouting priority 100;
# Note, we now only apply this rule to IPv4 traffic
meta nfproto ipv4 ip saddr 192.168.0.0/16 oiname eth0 masquerade;
}
chain input {
type filter hook input priority 0; policy drop
ct state vmap { established : accept, related : accept, invalid : drop };
# A new rule here to allow ICMPv6 traffic, because it's not required for IPv6 to function correctly
icmpv6 type { echo-request, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept;
iifname vmap { lo : accept, eth0 : jump inbound-wan, eth1 : jump inbound-lan };
}
chain forward {
type filter hook forward priority 0; policy drop;
iifname eth1 accept;
# A new rule here to allow ICMPv6 traffic, because it's not required for IPv6 to function correctly
icmpv6 type { echo-request, echo-reply, destination-unreachable, packet-too-big, time-exceeded } accept;
# We will allow access to our internal web server via IP6 even if the traffic is coming from an
# external interface
ip6 daddr 2602:dead:beef::1 tcp dport { 80, 443 } accept;
ct state vmap { established : accept, related : accept, invalid : drop };
}
}
Note, there's only three new rules added here, the other changes are just so we can use a dual-stack table so there's no duplication of the shared rules in separate ip and ip6 tables.
* 1 & 2: We allow ICMPv6 traffic in the forward and input chains. This is technically more permissive than needs to be, we could block echo-request traffic coming from outside our network if desired. destination-unreachable, packet-too-big, and time-exceeded are mandatory for IPv6 to work correctly.
* 3: Since we don't need NAT, we just add a rule to the forward chain that allows access to our web server (2602:dead:beef::1) on port 80 and 443 regardless of what interface the traffic came in on.
None of this requires being a "network expert", the only functional difference in an actually secure IPv4 SNAT configuration and a secure IPv6 firewall is...not needing a masquerade rule to handle SNAT, and you add traffic you want to let in to forwarding rules instead of DNAT rules.
Consumers would never need to see the guts like this. This is basic shit that modern consumer routers should do for you, so all you need to think about is what you want to expose (if anything) to the public internet.
Instead of all my devices being behind one IP and using an internal IP subnet, now each device has a globally routable ip address that will be used... Cool great opsec.
>This is a terrible argument. First, NAT doesn't provide the security behavior users want.
Try breaking into my machine. Login:pass are administrator:pa$$w0rd, external ip 58.19.1.129, internal ip is 192.168.1.124, the system is Windows xp, and firewall is turned off on both the computer and the box the ISP gave me.
Sure, okay. You're using RFC1918 on the internal network, so I'll need to connect to your router's WAN interface to do it, but after that it's just a matter of doing `ip route add 192.168.1.0/24 via 58.19.1.129` and then connecting to whatever I want.
How do you want to get me onto your WAN interface? Unless you happen to live near me it'd probably be easiest if you give me a tunnel. Alternately, if you change the internal network to a properly-routed non-RFC1918 range, I can demonstrate this over the Internet too.
I offered to do this once before, and the person I was talking to replied with "so, you're refusing to do it then" and blocked me. So just for the avoidance of doubt: I'm offering to do this, but if you're going to provide the test environment, you're responsible for making sure I can actually reach the test environment. Otherwise you aren't going to learn anything about NAT.
Right, and in a similar situation, if the internal device was given a routable ipv6 address by the ISP's cable modem, you could directly access that device.
This isn't a hypothetical. There are ISPs who do this out of the box. I plugged a linux box into my ISP's cable modem/router in Amsterdam and immediately noticed my ssh port was getting hammered by port scanners. This isn't what most customers, especially those who aren't technically sophisticated, expect.
I could do it if it was using a routable v4 address too, and I can do it with either RFC1918 or ULA as well (which are both routable, just not over the Internet) if I can get close enough to send the relevant packets. NAT provides no protection against any of these.
You don't normally see many SSH brute force attempts on v6, let alone getting hammered by them. I do see some, but it's mostly to obvious addresses like <prefix>::2, ::3 etc which I don't use, or to IPs you can scrape from TLS cert logs. If you set an ssh server up on an IP that you don't publicize, finding it is hard.
>How do you want to get me onto your WAN interface?
I've already given you _all_ information you could have realistically squeezed from me. The only thing left for you is to prove that NAT is not a security measure and break into my machine, given that you already have both login and pass.
If you had exactly those parameters with ipv6, you would have already broken in.
And like I said, I can do that if you get me into a place where I can demonstrate it.
If you want me to demonstrate that the lock on your safe isn't doing anything, you have to let me into the room where the safe is. Otherwise you won't learn anything about the lock on the safe.
When we say "NAT" we are specifically talking about stateful one-to-many NAT implementations as found in consumer IPv4 hardware. Such a NAT is largely isomorphic to a firewall with default-deny semantics for incoming connections and default-allow semantics for outgoing connections.
There are other possible NAT implementations that are much less like a firewall, but saying that a NAT does not provide security is a misunderstanding of the terms as they are used.
Not you specifically, but others in other threads have pointet to UPnP as proof that NATs don't provide security. If the existence of UPnP means that NATs don't provide security, then the existence of PCP means that Firewalls also don't provide security.
NAT-PMP, UPnP, PCP, et. all primarily exist because consumer networks that have to share a public IP face more issues than simply opening a port up to the internet. Destination port conflicts, port remapping, discovery of your public IP, are huge fucking headaches that these protocols also assist with.
Given most consumer routers these days can be configured with a mobile app, I could easily foresee a saner alternative where devices could simply ask the gateway if they could open up a port and have a notification sent to a mobile app to allow it.
But, that said, given how many devices are mobile these days I think the benefit of endpoint firewalls shouldn’t be underplayed either.
It's not isomorphic to a firewall, because it doesn't have default-deny semantics for incoming connections.
Think about it for a second. These NAT implementations change the apparent source IP of your outbound connections. How does that block inbound connections? Changing the IP isn't blocking, and outbound connections are the wrong ones.
If a connection comes into your router with a dest IP set to one of your LAN machines, no amount of changing the IPs on your outbound connections will block it.
You literally can't access the internal devices with the NAT implementation on most consumer level router/access points except for packets addressed to the port mapped to an already open connection originating from the inside. This is almost guaranteed to be a random high port. There's no way to access any other port on an internal ip address.
That's equivalent to default-deny.
I think either you're just trying to "well-actually" us or you're confused.
I'm not. You literally can do this, provided there's no firewall. All you need to do is send the router a packet that's already addressed to a LAN machine, and in it goes. "NAT won't translate the packet" doesn't matter if the address is already set to an IP from the LAN.
Most consumer-level routers do have a firewall to prevent it from happening, and if they don't then people describe that router as being "grossly misconfigured" or as having a security vulnerability and similar things, so in practice it'll be blocked. But that's my point: they need the firewall to do the job precisely because NAT doesn't do it.
I think understand what GP is saying; if you manage to get a packet to the internet port of the NAT router with a destination IP of e.g. 192.168.0.123, and the NAT router is running a generic IPv4 routing stack, it will dutifully route it to the internal network.
This can be done by compromising another host on the same link. It can also be done if anything on the same link (including the router itself) is running an improperly configured tunneling setup that lets the attacker send e.g. an IP-in-IP packet that gets unwrapped. The NAT has made it much harder to get a packet establishing an inbound connection to the router, but doesn't actually prevent the establishment of a connection should such a packet get there.
Compare to a default-deny firewall with public addresses on the LAN. Any inbound connections will be dropped, by definition; the lack of NAT makes it trivial to get a packet to the firewall itself, but once it's there, it won't get through.
1. How did a packet with a RFC1918 address reach router; it would require an attacker able to generate packets (or get something to e.g. unwrap an IP-in-IP packet) on the same link, since the router isn't going to ARP any of those addresses. Limiting inbound connections to originate on the same link does provide some measure of security.
2. Will the router even do anything with a packet coming in on the inbound port that doesn't target the public IP? This is implementation dependent.
Of course symmetric or even carrier grade NAT is not a firewall, but it's so silly to ignore real world implications thereof in an IPv4 only deployment scenario. Firewalls aren't foolproof and in real life you average NAT is more likely to be closer to that.
It's scary how much of this thread comes from people who can't imagine a use for keeping internal traffic internal. in ipv4, if my laptop tries to use a printer with a public ipv4 address, that raises alarms. in ipv6, if my laptop tries to use a printer with an ipv6 address...
its not about the firewall. there's just a lot of extra attack vectors without a nat.
I agree with the majority of your point, but hopefully your printer hasn't been assigned IPv6 IPs that are global in nature and is instead limited to site-local.
For anyone who is reading this but hasn't use IPv6, IPv6 addresses are a large flat 128-bit contiguous address space, but they are not universally routable. The prefix of any specific address determines what group of other IPs can get to it.
We often think of a computer as having an IP address, but with IPv6, computers will have several addresses, all with different prefixes to handle different types of traffic.
If you plug your printer into your home network, and if the local DHCP server is configured to hand out globally routable addresses from your ISP provided /64, then your printer will also be globally routable (as well as your "smart" fridge, "smart" TV, "smart" thermostat, etc). In my personal experience this is the default situation with consumer ISP IPv6 setups.
This difference in theory versus practice is precisely why we see people objecting that IPv4 is more secure as far as default configurations go when it comes to home use.
That said, I expect (hope?) that all ISP gear should default to enabling a stateful firewall. Hopefully there's no difference between the default security of an IPv4 and an IPv6 setup in practice. But given the history I'm not entirely optimistic.
Note that DHCPv6 is really uncommon for IPv6, especially on consumer routers - so uncommon that Android doesn't even support it. But your point stands, even more so, with SLAAC.
>This difference in theory versus practice is precisely why we see people objecting that IPv4 is more secure as far as default configurations go when it comes to home use.
I mean, I agree with them. I think people who say 'NAT is not security' are only correct in the absolute most pendantic way and that the way NAT is commonly configured is literally the only reason the internet doesn't consist mostly of botnets.
But I also suspect that if IPv6 were more common, we as a society would be better at it, and not do dumb things like hand out globally routable IPs via DHCP6
The whole premise of IPv6 is that every device should have a globally routable IP. This thread went into DHCP for some reason, but that is uncommon and not recommended for IPv6, where you're supposed to use SLAAC. With SLAAC, I'm not even sure you could realistically disable the ability to get a public IP. And if you did, I'm not sure you could allow a device to access the Internet over IPv6 with a consumer router without it having a publicly routable IPv6.
>The whole premise of IPv6 is that every device should have a globally routable IP
I would agree with the small adjustment of, 'every device should be able to have a globally routable IP'.
There are a lot of devices, like the ones we're talking about, that should not be accessible to the internet at large. You're not preventing them from getting a public IP because you don't have enough, you're preventing them from having a public IP as part of the belt-and-suspenders approach because there's no need to have one.
> in ipv4, if my laptop tries to use a printer with a public ipv4 address, that raises alarms.
The only way that’s possible is that you have a firewall rule blocking outbound connections to common printer ports like 631. NAT couldn’t care less what outbound port you’re connecting to, so it has to be a firewall doing that work.
> in ipv6, if my laptop tries to use a printer with an ipv6 address...
…so enable that same rule you manually configured on IPv4 on the IPv6 firewall, too.
What you’re describing is not default or inherent behavior. If you went out of your way to enable it, you have the skills to do it twice. That’s assuming your firewall is more complicated that “block outbound port <631> to <any IP>”, which covers both protocols on most firewalls I’ve used.
You on the inside can punch a hole to the outside. This is fine. There's no real difference between hole punching and a regular connection to a regular server from one side's perspective.
> NAT is not for security, it does not provide security.
It’s not for security but it absolutely does provide security and pretending otherwise continues to harm discussions.
I have a pile of ipv4-only IoT devices that have no firewalls of their own that are being protected by the symmetric NAT in my home router. Kick and scream all you want but there is security there and nothing on the internet can reach those devices unsolicited, just like a stateful v4 firewall would provide.
I don’t think you understand symmetric NAT. Requiring an entry in the port address translation table to propagate a packet is not the same thing as a stateful firewall.
You absolutely can have a port address translation implementation without a stateful v4 firewall that wouldn’t forward packets destined for inner IPs on the outer interface. Just put an ACL on the external interface to not allow traffic to the inner IP block.
If your public IP from your ISP is 12.13.14.15, and your internal block is 192.168.0.0/24, then your ISP can send a packet to 12.13.14.15 destined for 192.168.0.7, and without a firewall your router will happily forward it. An attacker who can convince intervening routers to send traffic destined for 192.168.0.7 to 12.13.14.15 (and these attacks do exist, particularly over UDP) can also do that.
You're using somewhat sloppy terminology that will confuse things. An IP packet can't be addressed both to 12.13.14.15 AND to 192.168.0.7.
The realistic attack here is that your ISP sends a packet with destination address 192.168.0.7 to the MAC of your router (the MAC that corresponds to 12.13.14.15). This is a realistic attack scenario if the device that your router connects directly to gets compromised (either by an attacker or by the ISP itself).
Getting a public route that would take packets destined for 192.168.0.7 to reach your router over the Internet is far more unlikely.
True, the frame is addressed to the router's hw interface but I'm talking to people who think NAT drops traffic so I figured keep it simple
But, yes, the ISP (or whoever has compromised/suborned/social engineered the ISP) is absolutely the main worry here and I don't understand how people are dismissing that so easily
> I don't understand how people are dismissing that so easily
Because that’s not where 99.9999% of attacks come from
Fire up a web server on a public ipv4 address and you’ll get hundreds of requests per day from bots probing endpoints for vulnerabilities. Same thing goes for weak passwords on an SSH endpoint.
Okay, so not only do you have to create a bogus packet, you have to convince every piece of equipment in between you and the end user to collude with it, in the hopes that the final router is so woefully misconfigured as to act upon it?
The ISP is the primary threat vector here (do you trust yours? Along with their contractors and anyone who might have compromised them?). But like I said route-poisoning attacks do exist.
yeah but the likelihood of this is incredibly remote. It would shock me if ISPs didn't have alarms going off if RFC1918 space was suddenly routable within their BGP table.
Not to mention the return packet would be NAT'd so the attacker would have to deal with that complication.
The return packet wouldn't be NATed, because stateful NAT tracks connections and only applies NAT to packets that belong to outbound connections.
Arguing over how likely this is is missing the point. If it can happen at all when you're running NAT, then it should be clear that NAT isn't providing security.
“if it protects 99.999% of attackers from reaching you but not this one specific attacker in this one case of misconfiguration, it’s not providing security”…
Dude, that’s a really shitty take and this is why people that do care about security end up ignoring advice from anyone who thinks this way.
You’re in the camp of “don’t use condoms because they can break”.
NAT doesn't protect you from 99.999% of attackers though. It doesn't do anything to incoming connections, so it actually protects you from 0% of attackers.
Okay, but unless you've poked a hole through NAT (and if you have, presumably you know what you're doing), what are those incoming connections going to connect to?
If there's nothing to connect to, is there really an incoming connection?
They connect to whatever IP is specified in the packet's "destination IP" header field. It's exactly the same behavior as if there was no NAT going on.
No, it might belong to the router. If it does then the connection goes to the router, but if it's set to a LAN machine's IP then the packet gets routed to the LAN machine.
You aren't in control of the contents of inbound packets, and NAT won't filter them to enforce anything about the destination IPs in them either.
Nobody on the Internet can send a packet to an internal IP on your network except for immediate L2 neighbors (I.e. your ISP).
Symmetric NAT 100% stops inbound unsolicited connections to the public IP. And using the public IP is the only way 99.999% can address you.
I implore you to write down (even if just for yourself) what the packet headers would be for you to get a packet from Starbucks WiFi to the device at your home at 192.168.0.5 that has made no egress connections.
You’ll quickly find what you’re suggesting is nonsense. port address translation requires an entry to function. It’s not some optional security feature. It’s required information to get the packet header rewritten to reach private devices.
You can't get a packet from a random store wifi network to your home network when your home network is using 192.168.* (barring something like routing headers, which most routers wouldn't process). You said that yourself in the first part of your post, and I don't think I ever argued otherwise.
> Symmetric NAT 100% stops inbound unsolicited connections to the public IP
No, it doesn't. If it did it wouldn't be possible for routers to accidentally make their web admin or UPnP interfaces available to the Internet.
It doesn't stop connections to your router, and it doesn't stop connections through your router either. It just plain doesn't stop connections, which is why it protects you from 0% of attackers.
Or more likely, network engineers who’ve been subpoenaed to collect the information?
Your scenario is plausible for high value targets. Like, what country wouldn’t want to have a friendly tech working at the ISP most politicians use in DC? That doesn’t seem improbable.
For the regular Joe Schmoe, I’d be more concerned with court-ordered monitoring.
Ah, that sounds like an American problem. If you're in the US, you're living in a hostile surveillance state that makes North Korea look like a hippy commune.
No, the router will only forward it with specific implementations that don’t isolate routing tables between the external and internal. Or an easier approach is just a stateless ACL on the external interface. Neither are a stateful firewall.
Send packets to the device? A NAT is in it's most basic form a mapping from one IP/port set to another IP/port set describable by some function "f" and its inverse "g". The common home user case has the firewall detect a flow from inside the network and modify "f" and "g" to allow this flow. Without the firewall, and assuming you want your devices to talk to the internet in some way, the NAT would forward (with modifications) traffic based on "f" and "g" to all your devices.
First they will have to change their policy of only providing one IPv4 address per ONT connection. Then they will have to convince me to disable NAT on my router, disable the DHCP server on my router, and bridge the WAN port with the LAN block.
Meanwhile in IPv6 land the ISP provided router that my relative has came configured by default to hand out globally routable addresses from the ISP provided /64. Thankfully it also had a stateful firewall enabled by default so there was no difference in practice.
> First they will have to change their policy of only providing one IPv4 address per ONT connection. Then they will have to convince me to disable NAT on my router, disable the DHCP server on my router, and bridge the WAN port with the LAN block.
No. They may be able to directly reach your internal addresses with source addresses that are outside your internal ranges through the WAN interface. For example: if you use 10.0.0.0/24 internally, and your special secret webserver is at 10.0.0.2, I might be able to reach it from 10.1.0.1 through your router's WAN interface.
It doesn't matter what the public IP is: the WAN interface is the default route, Linux will forward the traffic unless something is explicitly configured to block it.
Even if outbound traffic on the WAN interface is unconditionally SNAT'd to the public IP, and the replies have the wrong source address/port, I can still use a promiscuous mode AF_PACKET socket to receive them and interact with the internal server (the destination address will be correct, so the L2 frame will be addressed to the attacker's MAC). Or even just install my own SNAT rule to rewrite them again for me, I suppose.
Some ISPs have multiple subscribers on the same L2 segment, it's possible they can do this to each other.
Of course, I'd imagine many consumer grade routers out there do block this, but I've personally seen some that don't.
Yes, but NAT combined with RFC1918 private addresses does provide a layer of security. This is the most common NAT configuration for 99.99% of residential users. It is what most people mean by "NAT."
If your address cannot be routed across the Internet, it can't be accessed, firewall or not.
I have worked in corporate environments where we NAT'd public, route-able addresses for historical reasons. That would be insecure without a firewall and is not what most people are discussing.
The whole discussion is confused from the start. When people talk about the "security of NAT" they are not talking about NAT at all, but about what happens when NAT is misconfigured or switched off. In the case of IPv4 it means nothing works and your computer isn't reachable. The system is fail safe.
Meanwhile with IPv6 it's the other way around, everything is wide open unless you have a working and properly configured firewall.
It's scary how many supposed hackers have never even looked up an RFC before making grandiose statements. There is such a thing as "NAT filtering", see RFC 4787, section 5: https://datatracker.ietf.org/doc/html/rfc4787#section-5
A NAT is not a firewall, yes. At the same time, the NAT boxes out there in the wild absolutely do filter traffic, and yes, it is the NAT that does it, not a separate firewall. Practically all NAT boxes in the wild do stateful filtering. It is not really standardized how they do it, but this is how the real world often works. People argue that the filtering part of NAT is "actually a firewall", but what's the point? From the outside, you will not be able to tell if there's a firewall that filters traffic for which no established connection can be found, or if this is done by a NAT.
Many people are so fixated on the definition that NAT is only address translation and nothing else, they refuse to interact with the real world out there.
I suspect the author was trying to put into words why their technically correct world view is better, but he spends his opening arguing semantics (ineffectually, as apparent) instead of meeting the 'wrong' people where they are and explaining why his semantics are an improvement.
Competency crisis is not limited to just the audience.
I think the confusion stems from the fact that my mom's laptop with its 192.168.0.43/24 v4 address is not routable except via NAT, and people believe (rightly or wrongly) that that confers a degree of security.
UPNP and a dozen other NAT defeating tactics exist and have since the early 2000s. NAT translates addresses. Thinking a non-routable range is safe because it's behind NAT is at this point grossly ignorant of how modern network equipment works. It's kind of like port-knocking; yes it makes the attack slightly harder, but doesn't prevent it.
e.g. symmetric NAT exists and often doesn't come with a stateful firewall. Just because the linux box with iptables is protecting your network uses NAT doesn't mean NAT is doing the heavy lifting here. I can see the OMG MY PRIVACY crew is out in force here apparently misunderstanding that NAT does not do that either. I mean, we can explain things to you, but we can't understand it for you.
>UPNP and a dozen other NAT defeating tactics exist and have since the early 2000s.
I know that, and you know that, but squillions of people think that turning the UPnP setting off (if they even know what that is) is sufficient, which is why the myth persists.
UPnP is only relevant for software that's already running on your machine locally. People here aren't generally talking about outbound connections and I think you both know that. The practical effect of NAT as commonly encountered in a residential setting is to drop inbound unsolicited connection attempts.
And yes, everyone is aware that you could also do that with a stateful firewall. And no, none of us care about arguments of definition that attempt to frame NAT as technically being a firewall based on how it operates in practice. Being intentionally obtuse by refusing to acknowledge the obvious isn't going to convince anyone.
It doesn't confer much since it COULD be only NAT and no firewall.
It's INCREDIBLY unlikely to find a case of that in the wild, but possible.
A common example of a host that might have such an address but lacks that sort of security is anything as the default route for inbound packets, E.G. like you'd want your _own_ router / firewall rather than the ISP's modem.
If the end effect of security is dropping packets NAT and Firewalls both in effect drop packets.
Its kind of just silly pedantry to say NATs aren't security because sure you can't do things like block specific ranges of IPs spamming you (or make outbound rules to control local devices) but 99% of people don't need.
I understand ipv4 networks pretty well. And I would say that any device doing NAT is acting as a basic firewall. Do “true” firewalls do more? Sure. But saying NAT doesn’t provide security is flat out wrong.
If your router had only NAT and someone (i.e. your ISP) sends it a package addressed to somewhere inside your internal IP range, it will happily forward it. A firewall would block it.
The same problem applies to masquerading. Routers are happy to route packets they receive, and NAT (in whatever form) isn't the tool you use to drop those packets.
If there is more than one machine behind the NAT which one would it forward it to? This hypothetical simple NAT without firewall AFAICT doesn’t exist in reality, even if it exists in specs. I don’t see how it actually could.
Ugh, this is part of the reason why I left them, but https://free.fr still does this AFAIR. They were deploying IPv6 to all their consumers well before the other ISPs (more than 15 tears ago), but they have stagnated since.
IPv6 firewall disabled by default. There is only one config for the firewall: on / off. Accept all inbound or reject all inbounding.
To think that they used to brand themselves as "for the geeks", with reverse DNS customization, built-in user-configurable server on the router (all of their routers offer a Wireguard VPN, torrent client, audio output with DLNA & others), a m3u for IPTV, etc. I wouldn't advise anyone to use them due to this issue.
Their basic firewall dates back to 2019: https://dev.freebox.fr/bugs/task/27268 (a lot of spam in the replies there). There was none before, and it is still off by default.
This is no small ISP either, they have more than 50 millions clients (including mobile), and are in the top 10 ISPs in Europe. Baffling.
Fun fact I have actually had an sbc get hacked because I didn’t change the default password. I thought it would be reasonably safe for a few days because I knew the VLAN it was on had NAT and the associated firewall rules that deny inbound packets without outbound. But it turned out ipv6 was also enabled on that VLAN with no firewall. Left a bad taste in my mouth over a decade later even if it was a misconfigured firewall rather than an inherent issue with ipv6.
…and they did really guess an ipv6 address? Full scans of the ipv6 address space looks infeasible. Or did the sbc reach out to the internet thus having its address exposed?
Otherwise just the huge amount of addresses should make ipv6 “more secure” imho.
I don’t have any idea how they got the ip, it could certainly have been making outbound connections, though. I think it had NTP, although I might have pointed it at a local server we had for that.
In IA_NA mode, you're at the mercy of the DHCPv6 server for any kind of address privacy. And good luck getting a second address if you want to run a CLAT for 464. You don't want this in a home network.
As for servers, you mostly won't want it either, considering (a) you might rather configure things statically, and (b) it's easier to just deal out whole /64s per server, especially since that gives space for VMs.
So where's the niche for DHCPv6? Maybe assigning addresses for telco or OOB equipment… idk.
And just to be clear: DHCPv6 information-only ("stateless") and DHCPv6 prefix delegation modes are perfectly fine. It's the individual address assignment (IA_NA) mode that should just never have been invented.
I don't know how much impact this has in practice, but you do not need to scan the entirety of the ipv6 address space because you can just look at the IPs that are registered to known ISPs/ASs.
You're gonna need to scan 2^64 addresses once you've located the IPv6 network assigned to my connection before you find my phone. 2^56 if you don't get lucky guessing the network prefix it happens to be on at that moment.
Assuming a scan with a minimum 4 byte ICMP packet, that's about 73786 petabytes of network traffic for that /64. You'll need to shove it down the pipe within a day because IPv6 privacy extensions means the IPv6 address used changes after 24 hours. With only 1gbps fiber, I don't think the deanonimysation is the problem at that kind of traffic level.
I'm also not sure how much it helps, but a friend and I were just talking about how big the numbers get today.
My ISP provides my house a /56 allocation. There are 4,722,366,482,869,645,213,696 addresses. I should have enough for a couple of years, at least.
I guess you could scan it. The IPs for most devices are chosen randomly within a /64 subnet, or they're based on MAC address, but they're not sequential by any means. A /64 is still 18,446,744,073,709,551,616 possible IPs.
Unfortunately I think one of the problems with v6 is people are just unable to apply intuition to numbers this big. The minimum number of /64s an ISP will have is around 4 billion. They generally give subscribers a /56 which is 256 /64s. It's all simple power-of-2 arithmetic. Computer people used to get how big 2^64 is.
Most of the time it's going to be a /64, so even if you know the prefix you're still never going to guess a random address. But a lot of older clients will use a deterministic address based on their MAC, searching the space of MACs for known sbcs would be a lot more tractable.
That will only give the NTP server the IP you use for outbound connections. If you use privacy extensions, they'll get a temporary address.
If you don't configure your firewall to allow inbound connections to the temporary address, knowing your temporary address doesn't help them connect back to you. (Also, it's temporary, so their logs of IPs will be useless after a small window.)
Compare this to v4, where connecting out to someone gives them enough information to exhaustively port scan your whole network and trivially find every server you're running.
In theory, IPv6 Privacy Extensions (https://datatracker.ietf.org/doc/html/rfc4941) could mitigate this. In practice, I imagine when you bind to `[::]:port`, that also means that the randomized addresses would work for new inbound connections, too. Not sure how long they typically last, but you'd be fighting against the clock at least before a new randomized address.
That being said, on a slightly less common note: it is quite possible to have each individual service running on a /128. E.g. on IPv6 k8s clusters, each pod can have a publicly addressable /128, so activities like NTP would require the container to have an NTP client in it to expose in that way. That'd mitigate a good chunk of information exposure -- that being said, I agree with the larger point about security via obscurity being insufficient.
If you have a shitty ISP that rotates prefixes like it's 2005, hosting anything public is a massive pain already. DDNS works just as well on IPv6, though.
Internally, a ULA will keep things reachable even if you move ISPs. You could even set up a NAT66 setup to translate your changing prefix to your stable ULA so you don't need to update any firewall rules, but that's a pretty terrible workaround for a problem that shouldn't be on you to fix in the first place.
In my defense I was in college at the time, and I did actually run some tests to ensure my understanding of the firewall was correct. I just didn’t even think to account for ipv6 or especially for that range having different firewall rules.
Unlike the other poster, I'm not going to blame you for getting things wrong. It happens, we all were learning at one point. But I do think it's incredibly unreasonable to use a mistake you made as an argument against IPv6. This would be like if I rm -rf'ed my Linux box into oblivion when I was first learning and then avoided Linux after that because I had bad vibes about it. Sometimes you need to accept the L and not blame the tools.
This is going to depend on the router and on IP distribution.
My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.
NAT is not intended to be a security feature, for sure, but it creates security as a side effect. If I start up a web server on one of my devices, I know that it is unreachable from the Internet unless I go out of my way to set a port forward on my router.
But...if my ISP decides to start handing out IPv6, that can change. If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.
But if my ISP still gives me only a single IPv6 address and I'm still needing to use NAT, then I'm guaranteed to still effectively have a "default deny" inbound firewall policy.
> If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.
They usually do, and they also ship with the most wonderful technology ever specified within a 67 MB compressed archive [0]: UPnP! Now your attacker's job is to convince you to initiate an outgoing connection, which automatically forwards an incoming port to your device behind the NAT and bypassing the router's default-deny firewall! Nothing has ever gone wrong with a zero-configuration port-forwarding protocol from the 1990s rammed through the ISO!
That's an entirely different attack scenario. To succeed at that attack, my computer would already need to be running malware. At that point, they've already won.
I don't believe that opens a port to accept an incoming connection.
Even if it did, a web page making a request can't control the source port for the connection. They still couldn't make a local network service exposed to the Internet.
WebRTC and similar tools have existed for over a decade at this point and been abused horribly. Many common UPNP or similar daemons trust ANYTHING on the "trusted" side and will happily grant basically anything asked for because their vendors don't want customer support calls over whatever insane behavior some printer or IOT lightbulb is doing without the end user's knowledge.
Every router I’ve ever used has blocked incoming connections on v6 exactly the same as on v4. Really the only difference is you can have multiple devices on your network allowed to receive on the same port if you want.
> Every router I’ve ever used has blocked incoming connections on v6 exactly the same as on v4.
A few years back my ISP didn't properly support prefix delegation, and the only way to get IPv6 to work was in "Passthrough" mode. My router (Asus ax86u) was really unclear about what passthrough mode meant, but I think that it might also disable the IPv6 firewall (I have read conflicting reports, and was never able to find an authoritative answer). The setting is buried pretty deep in the router and off by default, so I don't think most people would enable it by accident, but a quick google search does show lots of people on forums enabling Passthrough mode to get IPv6 working. So seems pretty dangerous and there is no warning or anything [1] that you are potentially exposing every device on your network to the internet (if that is indeed what it does).
Fortunately, my ISP has since implemented proper support for prefix delegation.
I got curious about what "passthrough" might be doing and found this assertion [0], which reminded me of the existence of '6relayd' [1]. So I assume that that mode relays the RAs & etc, but replaces the link-local address in the RA & etc with that of the relaying interface.
So, what side effect of NAT is making your server unreachable here? It sounds like you could turn the NAT off and it would be exactly as unreachable as it was when the NAT was on.
(Just to double-check... have you tried DHCPv6-PD? ISPs will normally only give your router a single IP on its WAN interface, or sometimes no IP on the WAN. Getting the routed prefix for the LAN-side networks involves doing a PD request, which is separate from requesting the WAN IP.)
With NAT your device does not have a publicly routable address. Attackers have no way of contacting you at all. Without NAT you have a publicly routable address and attackers can try reaching out to your device. You rely entirely on your device's and your router's firewall.
So it's not really about NAT although it ends up being a consequence—it's about having a truly private network "air gapped" from the public internet.
No, NAT only affects which IP your connections appear to be coming from. It doesn't change which IPs your devices actually have.
The person I replied to said that they only get a single v6 address. If that's true, it doesn't matter whether they have NAT or not; their network isn't going to have publicly-routable addresses either way.
If your network is air-gapped then no connections will be happening at all, in or out... and if you connect a router to both the Internet and to your network, and enable routing on it, then it's not air-gapped any more.
> No, NAT only affects which IP your connections appear to be coming from. It doesn't change which IPs your devices actually have.
Well no shit. The NAT is a requirement for devices without a publicly routable IP because if my router just sends packets out with a source address being my 192.168.1.101 local IP, my ISP is most likely just going to drop the packets.
You know this, I'm sure, so I'm really unsure what point you're trying to make.
> The person I replied to said that they only get a single v6 address. If that's true, it doesn't matter whether they have NAT or not; their network isn't going to have publicly-routable addresses either way.
Correction: It will have ONE publicly-routable IP, and if I assign it to my router, but don't use NAT, then none of my devices on the network will be able to talk to the Internet, either in or out.
The point was that turning NAT on or off doesn't affect whether your LAN is reachable or not. NAT just edits the source address of your outbound connections. It's irrelevant to how your inbound connections behave.
> Correction: It will have ONE publicly-routable IP, and if I assign it to my router, but don't use NAT, then none of my devices on the network will be able to talk to the Internet, either in or out.
Right, and then if you add NAT you'll be able to make outbound connections, but inbound connections will be unaffected and will still not work. So what is NAT doing here to prevent inbound connections, given that the exact same connections already didn't work before you were NATing?
Turn fireball off. Keep NAT on, internal addresses are still not reachable. You are protected against firewall misconfigurations as well as the outside world. Defense in depth.
NAT in its customary usage is a bit of a historical accident that as a side effect happens to make it basically impossible for non-technical people to expose their devices.
Again, I ask: what is NAT doing to make those internal addresses unreachable? What side effect of NAT is making it basically impossible to expose your devices?
In the post I was replying to, the hosts were already unreachable (or... mostly unreachable, not completely unreachable) before NAT was even in the picture.
I think the problem is that everyone else is operating under the assumption that all the computers on the network still to be able to make outgoing connections to the Internet and you're not.
If I want all the computer on my network to have Internet access, I have two options: Each gets a publicly routable IP, which results in all computers being exposed to incoming connections unless I have a firewall, or I get a single IP which gets assigned to my router, use NAT, and all my devices are no longer exposed to incoming connections unless I go out of my way to configure port forwarding on the router.
So when I talk about the "side effect of using NAT", I really mean "side effect of using NAT instead of assigning public IPs to each computer on my network".
> my ISP still gives me only a single IPv6 address
This is criminal, and also incredibly uncommon. You should talk to your ISP, it's most definitely a misconfiguration of some kind, if not deliberate torture. Normally you get a /56 at least because there are so many and they cost nothing.
Datapoint of 1: With Cox as my ISP, I can get a /64 just by configuring my DHCPv6 client to request it, but if I wanted a /56 or /48 I would have to contact someone at my ISP.
What ISP gives you a single IPv6 address? That's incredibly comical. An ISP would have at least 79 billion billion billion addresses and they are giving you one?!
If I run a webserver on my network I know it's unreachable from the internet unless I specifically allow inbound traffic to it at my firewall. I get to use the actual security features with sensible terminology instead of silly things like "port forward".
NAT causes security issues too. Reflection attacks are much harder to stop if the endpoint and its network address are decoupled.
You can provoke loops and tangles of many sorts, some at the same protocol level and others going up and down.
My memory is fading but I vaguely recall a time when all of AOL shared something like a dozen egress addresses for certain traffic -- might have been proxies as opposed to NAT/"PAT" as we know it today. Iow, you couldn't block one without blocking 1/12 of AOL users.
Stronger memories of a time when your IP address (some were nat, some were not, varied by ISP) depended on which modem bank you dialed into, which was strongly influenced by what phone number you dialed. Which diluted the identity value of a given IP for a computer or user.
> Unfortunately, NAT reduces the number of options for providing security [1]
Somehow, everyone forgot that, and it morphed into a cargo-culting security practice, even going so far as to propagate 1990s network limitations into the cloud(!)
Real world CSRF attacks into hxxp://192.168.0.1 home routers and polluting DNS and DHCP settings you could argue is caused or at least facilitated by NAT, or NAT misconceptions especially.
Though IPv6 has a similar situation with well defined unicast and multicast addresses.
True story, popular browsers won't let you load a webpage via various IPv6 local address literals for this reason. Hxxp://[ff02::] addresses won't work.
/ You can have your cake by "tying a knot" with yourself and port forwarding from 127.0.0.1 to the IPv6 literal. An ssh port forward will do this with aplomb. Then load hxxp://localhost:port and it works again.
> The consequence of this is that when receiving inbound traffic, the router needs needs to be configured with where to send the traffic on the local network. As a result, it will drop any traffic that doesn’t appear in the “port forwarding” table for the NAT.
As I keep trying to explain each time this comes up: no, it doesn't and it won't.
When your router receives incoming traffic that isn't matched by a NAT state table entry or static port forward, it doesn't drop it. Instead, it processes that traffic in _exactly_ the same way it would have done if there was no NAT going on: it reads the dst IP header and (in the absence of a firewall) routes the packet to whatever IP is written there. Routers don't drop packets by default, so neither will routers that also do NAT.
Of course, this just strengthens your point that NAT isn't security.
It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.
That's a great point - the packet is not dropped by the firewall as a result of NAT - but it still won't route anywhere because the IP in the packet is that of the router itself. I've updated the article as a result of your comment, thanks.
That's only because your ISP won't have routed that packet to you if someone gave it to _them_. However, if someone was able to get to the ISP-side of the connection that you have with your ISP, and send a packet down the fiber/copper line from the ISP side towards your router, and that packet has a dst of your internal network (192.168.0.1 or whatever), your router will happily route that straight on to whatever internal network you have.
This means that if someone decided to be a bad actor and start tapping fiber lines on the poles in your neighborhood, NAT would do literally nothing to protect you from all the packets they start sending your way.
Yes, physical tapping of lines / ISP attacks were outside of the threat vector I was discussing. At this point, I think any discussion of NAT starts to look a little orthogonal.
If somebody is wishing to tap fiber optics lines to the ISP or to hack the ISP just to get to your router, then you probably are not going to be saved by a "default deny" firewall anyway.
It might be the IP of the router, in which case the router itself will accept the connection if something is listening (like the web interface perhaps). But whoever sent you the L2 frame has full control over the contents of the IP in the packet, so it could be anything.
Repeating the same wrong points doesnt make you right.
Every NAT based product will have a firewall built in also by default. And it'll be deny-all except for conn-tracked.
And that L2 attack is a martian packet. Why are you allowing reserved IPs talk on public network interfaces (hello, spoofing and obvious at that)? These are always blocked due to the reasons you describe.
So, if you have NAT but a grossly misconfigured router, it might not be secure?
Quick question - do you think that "security by obscurity is not security"? And, as a follow-up, when you park your car do you ensure your laptop bag is out of sight, maybe locked away in the boot?
Because here's a mindblowing concept that'll change the way you see the world - you can have a door lock but it won't make you secure. You need to actually fit the lock to some sort of door.
If you have NAT, that doesn't tell you anything about whether the router is secure. All it tells you is that outbound connections made through the router will appear to come from the router's own IP; it doesn't tell you whether inbound connections will work or not.
John, your post opens saying it's addressing the point: “the NAT-by-default of IPv4 effectively means that I get the benefit of a default-deny security strategy.”
Your title is "IPv6 is not insecure because it lacks NAT"
I'm sure anyone who understands how NAT offers the equivalent of a default block rule also understands that the absence of NAT alone doesn't make IPv6 insecure. This makes the title feel a little clickbaity-strawmanny, sorry.
Your response seems to be: "most firewalls have a default block rule too meaning they're no worse than IPv4 w/ NAT."
There's more security to be had in an intrinsic architectural feature (like IPv4 NAT being necessary due to limited IPv4 space meaning most IPv4 devices behind CANNOT be addressed from the internet without NAT) then there are in policy features (most firewalls SHOULD have the default deny IPv6 rule that will stop their address being reached from the internet.)
That doesn't make IPv6 insecure because no NAT. But it does mean - IMO - that the intrinsic block that comes with IPv4 NAT is a better security measure for making devices inaccessible than relying on default firewall rules.
What point are you trying to make here, and is it actually more useful than the point you say you're addressing?
> There's more security to be had in an intrinsic architectural feature
No, there is not. Even ignoring the question of whether the concept of an ordinal ranking in amount of security even makes sense, this claim doesn't make sense. If the invariant is that incoming connections are blocked by default, an IPv4 NAT and an IPv6 default deny rule are equivalent in security: both uphold the invariant. If the claim is that a misconfiguration of the gateway can make the system vulnerable, again, the two kinds of firewall configuration are equivalent: you can configure an IPv6 firewall to pass traffic and you can configure a DMZ host or port forwarding in the NAT case.
There's no basis for claiming the two schemes differ in the level of security provided.
> an IPv4 NAT and an IPv6 default deny rule are equivalent in security: both uphold the invariant
Yes, you're correct, on some level, they are equivalent: in both cases, packets don't reach the target machine. That is one of the few levels on which they are equivalent.
> There's no basis for claiming the two schemes differ in the level of security provided.
Yes there is, this is basic secure architecture and secure by design principals. If you understand these principals, you will understand that the equivalence level you're talking about above leaves space for other security issues to creep in.
> you can configure an IPv6 firewall to pass traffic and you can configure a DMZ host or port forwarding in the NAT case.
IPv4 & NAT config: takes effort to accidentally expose things behind it. It's not even physically possible to fully expose all the ports of more than 1 host behind it, assuming it's only got 1 public IP. For IPv6 and firewalls, you've just pointed out how easy it is to configure it to not have this security property.
I'm not arguing that IPv6 is not secure because it lacks NAT. My point was that this entire discussion is silly engagement bait: there's no clear right answer, but it's an easy topic for dogma and engagement. A holywars topic like NAT, IPv6 and security is prime for that. The author and submitter muddies the waters further by - probably not intentionally - choosing a strawman submission title.
> Yes there is, this is basic secure architecture and secure by design principals
The only principles at work here are the ones of superstition and magical thinking. The existence of a "disable security" button doesn't weaken the theoretical security properties of a system when that button isn't pressed, and NAT systems and pure firewalls alike have this button.
If anything, NAT systems are sometimes worse due to things like uPNP automating the button-pushing.
Look: I just don't accept the premise that making a system more flexible makes it less secure. If your threat model includes user error, then you have to be against user freedom to achieve security guarantees.
The amount of "effort" it takes to disable security measures has no bearing on the security of the system when properly configured, and how easy you make it to disable safeguards is a matter of UX design and the tolerance your users have for your paternalism, not something that we should put in a threat model.
I think most of the comments on this thread crystallise two different conception of security: the intended one and the effective one.
The second one is messy to measure, it requires making statistics on how often NAT saved the day by accident, which is hard if not impossible.
I personally think that statistics always win, even if they are unexplainable. My bet (zero proof) is, IPv4 is statistically (maybe by accident) more secure than IPv6, just because of NAT.
I have seen so many horrors in terms of multiple NATs I will always prefer IPv6, also because I think the benefits outweigh by far the difference in _effective_ security.
Summary: yes, IPv4 is more secure, but the difference is so marginal that IPv6 is still way better. Security is not the only metric in my world and theoretical discussions obsessing about a single metric are pointless.
I see the split too. I'll add that each camp is frustrated and feels the other is missing the point and would make information security worse if its worldview won.
You can do some empirical analysis. Someone downthread linked to a paper claiming to being able to reach a few million vulnerable devices over IPv6 and not IPv4. This kind of analysis isn't dispositive, though, because there are all sorts of second-order effects and underlying philosophical differences. Facts seldom change minds when you can build multiple competing true stories around these facts.
I'll call one camp the "veterans". They see security mostly as a matter of increasing the costs incurred by attackers relative to defenders, looking at the system holistically. Anything that increases attacker workload is good, even if it's an unintentional side effect of something else or interacts with software architecture in a cumbersome way. It's vibes-bases: whether a give intervention is "worth it" is an output of a learned function that gives in the stomach of a seasoned security researcher who's seen shit.
The other camp I'll call the "philosophers". (My camp.) The perspective here is to build security like Euclid's elements, proving one invariant at a time, using earlier proofs to make progressively more capable systems, each proven secure against a class of threat so long as enumerated assumptions hold. They read security as an integral part of system architecture. Security comes from simplicity, as complexity and corner cases are the enemy of assurance.
The veterans see the philosophers as incoherent. There's no such thing as a safe system: only one not yet compromised. You can't solve problems for good anyway, so there's no use trying to come up with axioms. Throw away the damn compass and strait edge and just draw siege map in the dirt with a stick.
The philosophers see the veterans as short-term-oriented defeatists who make it harder to reach levels of provable security that can solve problems once and for all so we don't have to worry about them anymore. You have to approach complex systems piece by piece or you can't understand them at all -- and worse, you'll do things in the name of security gutfeels that compromise other goals without payoff that feels worth it to them. They say, "Without my compass and straightedge, how can I design my star fort with firing lines I know cover every possible approach?"
The divide shows up in various projects. TLS is a philosopher project. Certificate transparency is a veteran project. Stack canaries are a veteran project. Shadow call stacks are a philosopher project. I think you get the point.
This thread reveals a surprising split between veterans and philosophers on NAT. In retrospect, it's kinda obvious that the veterans would insist that "duh, of course IPv4 prevents inbound connections and it must because otherwise the Internet won't work", and the philosopher camp is "Hold up. One thing at a time. What's the actual goal? How can we achieve this goal minimally without side effects on Internet routing?"
My camp sees the NAT configuration issue as a red herring. We see "the UX makes it too easy to run unsafe" as an HCI issue distinct from the underlying network architecture. The veterans say "Well, you can't build that button if you have NAT, so we are led not into temptation."
Both camps have something to contribute, I think, but the divide will never fully disappear.
I understand your view, I just disagree with the value you're putting on it, and I feel you're straying into accidentally insulting people to justify yourself:
You called yourself a philosopher and then proclaimed philosophers are the only ones who read security as an integral part of system architecture, whilst veterans are essentially vibe coding and surviving on the lucky mess they create.
I find your position that misconfiguration is a red herring in security as completely unjustifiable and untenable.
It's probably that I'm just a puny brained veteran seeing your big complex philosopher smarts as incoherent though.
Anyway, I digress from the key point I've been trying to make in this entire thread:
I'm not arguing that IPv6 is not secure because it lacks NAT. My point was that this entire discussion is silly engagement bait: there's no clear right answer, but it's an easy topic for dogma and engagement. A holywars topic like NAT, IPv6 and security is prime for that. The author and submitter muddies the waters further by - probably not intentionally - choosing a strawman submission title.
You talked right past the key point which is valid:
> There's more security to be had in an intrinsic architectural feature (like IPv4 NAT being necessary due to limited IPv4 space meaning most IPv4 devices behind CANNOT be addressed from the internet without NAT) then there are in policy features (most firewalls SHOULD have the default deny IPv6 rule that will stop their address being reached from the internet.)
One security property is architectural, one isn’t. They’re not the same.
> Even ignoring the question of whether the concept of an ordinal ranking in amount of security even makes sense
I must be misinterpreting this statement, are you arguing that you aren't sure whether "x is more secure than y" is inherently a valid thing to compare?
"X is more secure than Y" is usually an ill-formed statement. Secure against what threats? Does X provide every security guarantee Y does? Every single one? Then there's no proper superset relationship, and the best we can do is say that X and Y provide different security guarantees.
If we model security as a lattice, lots of systems end up being incommensurable. You have to talk about the specific threats.
Okay, suppose you want to flatten the lattice into a scalar score so we can apply the usual relational operators and statements like "more secure" make sense. How do we do that? Do we apply some kind of weighted average over security feature presence? With what coefficients? Are these coefficients invariant over time and between people? What if my use-case is different from yours and I have to model the "amount" of security differently?
If my router is written in 100% memory safe code but has a default password of "hunter2", is it more or less secure than your router, which might be a normal OpenWRT installation?
When people argue over whether something is "more" or "less" secure without specifying a use-case, they're haphazardly mixing feature matrix comparisons and (usually tacit) disagreements on prior probabilities of various attacks. The result is seldom a conversation that enlightens.
I can see what you're saying, but I don't think the existence of situations that aren't comparable means we should do away with idea of comparison. You could make that argument about almost anything (not just security): almost always in engineering (and life) there are tradeoffs. Sometimes those tradeoffs are clear-cut. Sometimes they aren't.
There may be a long tail, but I don't think that should exclude sensible statements like "deny-by-default is safer"...that promotes situations where software doesn't select opinionated defaults and so you end up with publicly accessible Mongo and Redis and S3 resources as we've seen over the years.
I'm calling for linguistic precision. What does it mean for a SOHO router to be "secure"? If we taboo this word "secure" for the moment and instead ask how effectively these devices, e.g. prevent unauthorized inbound connections to bottable IoT devices, we can start to get a concrete sense of the landscape and directions in which we can move across it. By focusing on the specific thing we want to accomplish, we can avoid getting distracted by considerations relevant only to other scenarios and better approximate a "meeting of the minds" on terminology and goals
Invoking NAT "security" as a reason against IPv6 is a surefire indicator the person invoking it has absolutely no idea what they're talking about and should not be allowed within typing distance of any network infrastructure
As a reason not to IPv6? I guess. As a thing, not scare-quoted, but really security? No. Be careful with things like "absolutely no idea what they're talking about".
Please. _I_ invoked that argument, and I bet I know more about IPv6 than you do.
All my services and networks have IPv6. And my first operational issues with IPv6 were in 2008, when my Asterisk SIP server started failing after ~12 hours.
Culprit? Privacy addresses kept accumulating until they overflowed the SIP UDP packet size because it listed all the combinations of supported codecs/endpoints.
This has been gospel among snooty network engineers for decades, but NAT was initially introduced to the wider market as a security feature, and it is absolutely a material factor in securing networks. The network engineers are wrong about this.
(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
I would never debate NAT was marketed as security (as marketing is often detached from the reality of what's being sold) but I'd be interested why it's a material factor in securing networks independent of the stateful firewall mentioned, which most seem to actually rely on. The "snooty" people probably mean less what may have been marketed to consumers and more what the standards which introduced it say. E.g. https://www.rfc-editor.org/rfc/rfc1631 notes address depletion and scaling as drivers in the opening but the only mentions of security are later on in how NAT actually makes security more difficult.
I.e. it would seem whatever argument could be made about security from NAT, poor or not, intended to be security or not, would be immaterial in context of stateful session tracking with outbound originate allowed alone w/o doing the NAT on top anyways.
It was more than just "marketed" as security. It was brought to market as a security product and used that way for many years, before address depletion was a meaningful problem. People used NAT firewalls back in the eras of routable flat class-B desktop computer networks.
The first commercial NAT box was the PIX in 1994, which featured stateful session firewalling (not just NAT) in agreement with the above 1994 RFC. It was still the era of referring to classful networks, but I'm able to source documents from the time which state the opposite of your claims.
> corporate networkers are free to expand and reconfigure their TCP/IP networks without agonizing over the much publicized IP addressing crunch. It also spares them from having to upgrade all of their host and router software to run IP version 6
It does end with the aforementioned security marketing making it sound like NAT is what provides security on the PIX:
> PIX also increases network security. Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
> And what about hosts that should be recognizable from the Internet, such as mail servers?
> These either can be directly attached to the Internet and assigned a public address or can be attached through PIX. In the latter case, the translator is configured to map one of these external addresses to the device not just for the duration of the application session but on a permanent basis.
Looking past the marketing line and reading the manual, the reality was the PIX was always acting as a full stateful firewall and did not just rely on NAT itself to provide the inbound filtering. See the "PIX Firewall Adaptive Security" section on page 2 of this 1996 manual I managed to dig up as reference https://mail.employees.org/univercd/Nov-1996/data/doc/netbu/.... Rule hits that missed a state match were even loggable (what a box for the time!)
Whether people saw the marketing and assumed it was NAT that provided security is precisely the bad assumption the article talks to, but at no point in history was NAT prevalent without being paired with a normal stateful firewall to provide the security - since the intent of NAT was not to fill that role, even in the beginning, as sourced by 3 references now vs your personal claims.
The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful.
The point is that NAT was introduced as a kind of firewall. The PIX firewall was named by Network Translation, Inc., which was acquired as a security device --- and, indeed, the PIX was for many years the flagship security brand at Cisco.
I don't dispute that NAT is dispensable (though: dispensing with it in millions of residential prem deployments is another story altogether!), only that it's "not a security tool" --- it clearly is one, and a meaningful one (whether network snoots like it or not) in a huge number of networks.
> The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful.
That's not the distinction I, or TFA, set out to make.
It's not that NAT is a component of controls that could be replaced by others, it's that whether NAT was put in place for security or if it was always assumed you need an actual stateful firewall precisely because NAT was never intended or believed to provide meaningful security, even in the days of classful networking.
Not one of the references above makes claim that NAT was intended to provide security on its own. That the PIX launched with actual firewalling capabilities does not bolster that NAT=security, it actually bolsters that NAT was never believed or intended to provide security even further.
To turn this back around at you: The distinction you're drawing that NAT could have provided "something better than nothing" in terms of security if appliances like the PIX hadn't always shipped firewalling from day 1 isn't meaningful.
The whole point of NAT firewalls is that the devices behind it don't have routable addresses. "Statefulness" improves the situation, but the translation itself provides a material control.
I suppose we fundamentally disagree that it's meaningful or material whether NAT can provide something the stateful firewalling has handled more completely since the first shipping implementation and that this defines what the purpose and introduction of NAT to the market was supposed to be.
There's no uncertainty at all about what NAT was meant to do; you can just read Cisco's introduction to the PIX, or it's statement about the acquisition of NTI, which are online.
Network administrators (less so security engineers) don't want NAT to be a security feature, so they've retconned a principle of security engineering that doesn't exist. If people were honest about it and just said they'd prefer to work on networks where less distortive middlebox features provide the same security controls, I'd have nothing to argue about.
But this article makes the claim that "NAT isn’t actually a security feature". That's simply false. People need to stop rebroadcasting this canard.
One could see the inlined, sourced, and dated references I placed above about the PIX rather than searching online from scratch or making assumptions of others reasons or intentions.
What some people do or don't want in the 2020s has no relevance to the reasoning in the 1990s, nor does it redefine the purpose or use of NAT the same. The above is clearly and directly stated from the sourced material of the era itself: NAT was introduced in the mid 90s due to concerns about address space depletion and the need to move to IPv6. The security features of said introductory appliance never came from or were supposed to come from implementing NAT, but from implementing stateful firewalling and blocking inbound connections. There is no personal opinion or retconning in any of this, they aren't even the postings of anyone from this century.
I don't see where they do. I see them talking almost exclusively about working around address depletion.
Hell, look at Cisco's press release for its acquisition of Network Translation, Inc. [0] It's all about address depletion and resource efficiency; security is mentioned as an afterthought. I'll quote the relevant paragraphs (and leave in the line break mangling present in the original).
SAN JOSE, Calif., October 27, 1995 - Cisco Systems Inc. today announced anagreement to purchase privately-held Network Translation, Inc. (NTI), anetworking manufacturer of cost-effective, low maintenance network addresstranslation (NAT) and Internet firewall equipment. The investment isintended to broaden Cisco's offerings for security conscious networkadministrators who want to dynamically map between reusable private networkaddresses and globally unique, registered Internet addresses. Through itsacquisition, Cisco will gain NTI's Private Internet Exchange (PIX) solutionwhich helps network administrators resolve their growing need forregistered IP address space. NTI's 10 employees and products will beincorporated into Cisco's Business Development efforts reporting to VicePresident Ed Kozel. The financial terms of the purchase are not beingdisclosed. The transaction is expected to close by the end of November andis not subject to the Hart-Scott-Rodino filing.
The NTI investment is the second action by Cisco in recent months tostrengthen its expertise in resource-effective Internet access technology.NTI technology will interoperate with and integrate several functions ofthe Cisco Internetwork OperatingSystem(tm) (Cisco IOS) software,facilitating use throughout the enterprise. NTI addresses two of the morecompelling problems facing the IP Internet -- IP address depletion andInternet security. Customers using the NATalgorithm can take advantage ofa larger than assigned pool of addresses. NAT makes it possible to useeither your existing IP addresses or the addresses set aside in InternetAssigned Number Authority's (IANA) reserve pool (RFC 1597). Cisco's goal ofintegrating NTI's technology and personnel is to ease the complexity ofInternet access for applications including telecommuting and World Wide Webaccess.
Read the Data Communications article they provided:
PIX also increases network security. Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
And what about hosts that should be recognizable from the Internet, such as mail servers? These either can be directly attached to the Internet and assigned a public address or can be attached through PIX. In the latter case, the translator is config- ured to map one of the external addresses to the device not just for the duration of an application session but on a permanent basis.
At some point you're going to have to find a way to argue that the Cisco PIX was not a security device; again: it was the flagship product of the security SBU.
I was there at the time, doing IP network engineering (for a Chicagoland ISP). The PIX was a security device, and NAT was understood as a security feature (for sure, also an address depletion feature, but the argument that's being made in the post isn't merely that it was an address depletion thing, but also that it categorically wasn't a security feature, which is just obviously false.)
> At some point you're going to have to find a way to argue that the Cisco PIX was not a security device...
What? It's a firewall that can do NAT. The PIX is clearly a security device. NAT is clearly an address-depletion-mitigation technique.
> Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
Right. And you can achieve the exact same effect with a firewall on an edge router or on a host. I get that firewalls might have been much less common thirty-ish years ago and that doing packet filtering might have been pretty novel for many, leading folks to get confused when they encountered a combination firewall+NAT device.
I'm not sure I can be any clearer about the fact that NAT is both a security feature and an address management feature. I feel like people who weren't practitioners are the time are trying to reason axiomatically that every feature fits into precisely one bucket, or that a security feature isn't a true security feature if it can be replaced by one or more other "cleaner" security features. None of that is true. Practitioners at the time were not confused.
"You can achieve the same effect" doesn't mean anything in this discussion. If that's your argument, you've conceded the debate.
It's a security feature in the same way that a power-cut switch is a security feature. A power-cut switch's purpose is cut power to a machine so that it can -say- be safely worked on or relocated (or simply to not draw power when the machine's not in use), the machine also happens to be inaccessible while its power is cut.
Sure. It's not technically a lie to call a power-cut switch a security feature for most pieces of kit. I'd still laugh at the salesman that made the assertion. If I were feeling particularly cunty, I'd ask him if he injured himself from that great big stretch.
I can't emphasize enough how much of a retcon it is to say "it's not technically a lie" that NAT is a security feature. It was deployed in hundreds of networks specifically as a security feature, and it is part of the security posture of hundreds of thousands of home networks today. People who say "NAT isn't a security feature" are simply wrong.
There are lots of security features I personally don't like either. I don't claim they're not security features; I say they're bad security features.
> Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
This is a security feature ad, nothing else. And it’s 100% because of NAT, not anything else in the PIX feature set.
That came up earlier and I know it's a gray area but I agree with the idea that a line tossed into the marketing and not backed up by the manual weakens the importance. The firewall in the PIX is the security workhorse.
Also that sentence implies you can get a connection to a device, you just know less about which one it is. Is that really a meaningful security feature? To the extent that connections are actually blocked, it's not because of the NAT scrambling they quoted in the first half of that sentence. That sentence is somewhere between unhelpful and flat-out wrong.
...okay? I didn't say you can. I said that line in the marketing implies you can, as part of how it's wrong.
If that wrong line in the marketing is the strongest evidence for NAT being initially understood as a security feature, that's very weak evidence for the pile.
(If the way I worded things needs more clarification, let me try to elaborate. There is a way in which NAT would prevent the connection, but that aspect of NAT is not what the marketing sentence talked about. It incorrectly talked about a different aspect of NAT. While there could theoretically be a device that uses NAT for protection, this device uses the firewall for protection. Just like basically every other device that can do NAT.)
Im not sure why you’re digging in this way. The marketing material is clearly making security arguments. Whether or not you agree with them is entirely irrelevant because the statement was that NAT was marketed as a security feature.
> Im not sure why you’re digging in this way. The marketing material is clearly making security arguments.
Oh, I see where you're misunderstanding the claim I'm making, continued from what simoncion was saying.
Yes, the marketing is making security arguments. The PIX is a security device as one of its main functions.
The feature that was put in specifically for security is its firewall. The NAT isn't adding anything on top of that, security-wise.
> Whether or not you agree with them is entirely irrelevant because the statement was that NAT was marketed as a security feature.
The original claim is that companies generally saw NAT itself as a security feature. That goes beyond a single incoherent sentence in a piece of marketing about a device that had NAT and a firewall. Again, I accept that the sentence is some evidence for the idea but it's so weak. This is something that happened just a couple decades ago, there should be plenty of evidence of actual decisionmaking.
Also it occurs to me that the phrase "know which machine on the corporate network is using a Class C address" might be talking about NATing entire IPs, every port at once. In which case that's very much not a security feature. NAT like that puts the machine naked on the internet. It's about as secure as having your devices get publicly routable addresses out of DHCP. So if that's what they meant, that sentence is making unjustified claims. Did one easily disproven line in a pamphlet convince an industry?
I don’t know what to tell you dude. Back in 06 as an admin for campuses where more than half of the machines were XP pre service-pack 2, NAT was 100% used as a security feature.
For public WiFi networks and labs where we couldn’t control software on end devices, we put them behind NAT pools purely for security (we still had enough public v4 IPs to give them to printers).
You can hand wave however you want, but back then NAT was used for an easy first level of security.
“There existed a better thing in a pure stateful firewall” is not an argument against people using NAT instead.
"I have personal experience using it that way" is a much better argument than anything you said in previous posts. Thank you for saying that, no sarcasm.
Was there a reason you didn't firewall those devices? I mean, a basic firewall has to do less work to attain the same security, and needs less configuration.
You've repeatedly re-emphasized your personal claim "this is how it was" while continually refusing to provide any external evidence, yet have the gumption to continue repeating it must be others letting their personal feelings get in the way of looking at what NAT was that leads to the disagreement about the history.
NAT does not care about anyone's personal feelings, one way or the other. Bringing up what you think other's personal feelings are does not help you redefine the original purpose and usage of NAT to be about security.
If you were solely arguing pure NAT could possibly be used today as (or that a few had eventually made poor attempts to use pure NAT as) a way to have better-than-nothing security then I'd agree. Instead you're insisting to rewrite history to make it sound like that's the way NAT was always intended to be used or what it was widely deployed for based on your personal recollection alone, other evidence be damned. If, e.g., the RFC had given more to say about being for security instead of address exhaustion, I highly doubt you would have completely ignored any reference to it in these ~dozen messages.
The principle difference, IMHO, is that it makes the security visible. My home cable router has NO firewall configuration at all. Supplied by my ISP and woefully deficient in absolutely all respects. I can't (for example) configure It does have a configuration for forwarding IPv4 ports to inside machines; but none for forwarding IPv6 ports. Does it have stateful filtering of IPv6 ports? I'd like to think that it does, but if so there is no visible evidence that it does.
This is one of those occasions where people are arguing semantics, and you're like "but -- I was there!"
My first cable modem did not have a NAT, nor did my first ADSL modem. You'd use "Internet Connection Sharing" on Windows 98 SE to share the internet connection on your LAN. And you'd get badly hacked, and then also install a firewall. Sygate had a firewall and NAT combined. (Or, you'd use linux - and also get badly hacked, but for different reasons.)
As a response, ISPs started to ship modems with built-in NATs. They did not start to ship what we now call routers (modem+NAT) because they wanted to encourage people to share their internet connections out of the goodness of their hearts. They'd prefer to sell more cablemodems, or dial-up. They started shipping (NATted!) routers because it saved them a lot of support calls from hacked (and disconnected) customers. Instead they got support calls about port-forwarding, so uPnP was the next hot feature.
Was NAT originally intended to be a firewall? No. Did it effectively protect many innocents? It did. Is it still needed as an additional layer of security-through-side-effects? Let's hope not.
NAT isn't security at all, good or otherwise. If it was sold as such, then the people selling it were giving out inaccurate info. But just because some people wrongly said that NAT provides security back in the beginning doesn't somehow make those claims true today.
In my experience, consumer grade routers will often happily route packets with rfc1918 destination addresses from the WAN to the LAN interface all day. The "firewall" is only that nobody can get packets with those destination addresses to the home router's WAN interface through the internet. Your ISP can, and in some cases other ISP subscribers on the same L2 segment as your router can.
But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it.
The router will then do exactly the same thing it would've done if no NAT was involved at all: if the dest IP in the packet is the router itself then the router will accept or refuse the connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.
It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.
Yes, but we've just successfully rewritten the article in the comment section as "it's not having NAT that provides the security itself, but other configuration any sane person would expect on a device doing NAT to prevent unexpected inbound connections" is exactly what the article set out to separate.
Yes, of course. If NAT denied connections in the way people think it does, then it wouldn't be necessary to separately configure the router to reject inbound connections. It's possible to have configurations that don't do that precisely because NAT doesn't do that itself.
That makes no sense. If a packet comes into a public IP to a session that doesn’t exist, there is nowhere to forward the packet onto. The public IP belongs to the router.
If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.
I’m not sure you understand how NAT implementations work.
I recommend you setup a basic iptables NAT set of rules on linux to reflect what a home router does (masquerade) with ip forwarding enabled.
The inbound packets from the internet are to a public IP that belongs to the device performing NAT. If there is no entry in the conntrack table from a connection to translate that public IP to a private IP, there is nowhere it can be forwarded to. It’s already at the device that owns that destination IP.
Even if it spit the packet out a private interface (which makes no sense given the routing table), the destination IP would be a public IP that both cannot be ARPed for on the local network and will not be honored by any private device.
I'm reasonably sure I do. I've done that exact test literally half a dozen times now due to people telling me that I'm wrong, and each time I test it turns out that I'm right. What other conclusion am I supposed to come to?
I think it's someone else's turn to do the test now.
> The inbound packets from the internet are to a public IP that belongs to the device performing NAT.
If the inbound packets are addressed to the router, they get delivered to the router. But you cannot just declare that that's where they'll be addressed. You aren't in control of what packets show up to your router, you're only in control of how you process them after they show up.
There's no inherent ACL in NAT, and adding one would just demonstrate that ACLs can block packets, which we already knew.
> What you’re describing would happen if NAT were completely disabled. You’re just describing an open router
Yep. It also happens when NAT is enabled. A router doing NAT is exactly the same thing as an open router -- it just has the additional property of editing outbound connections to appear to come from the IP of the router itself.
If NAT on its own blocked inbound connections, I would have seen that in my tests.
Not wishing to undermine the central point, NAT for v6 is a thing. The point of the article is that it's not "NAT by default" the way home IPv4 is because so few places worldwide get more than a single IP per customer: The NAT is not there in v4 for security, it's to provide for multiple devices inside the home. Or, in the case of Carrier-Grade NAT, to manage multiple customers, behind a small pool of v4.
NAT doesn't exist to be secure. If it is, (and that is debatable because NAT busting is a thing) then, it's a side-effect.
NAT for v6 is not common. If you use ULA, you'd possibly use NAT for v6 in some circumstances.
Just to nitpick a bit. What people typically mean when they say "IPV4 NAT" is Network and Port translation. My 192.168.0.1 internally becomes 172.217.12.100 and my port gets converted to something that is tracked so that the return packet can find it's target.
In IPv6, Prefix-Translation is similar, in that the /64 prefix is translated 1:1 - but the /64 Host address is (in my experience) left alone - so that renumber a network becomes trivial when you change ISPs - you just just change the prefix.
I don't actually know if "IPv4 NAT" behavior even exists in the IPv6 world, except in the form of a lab experiment.
From my understanding, the "IPv4 NAT" equivalent for IPv6 is generally referred to as NAT66 (NPTv6 for Prefix-Translation). For example, Fortinet offers this on their firewalls, and I believe most firewall vendors have this option.
What they're saying is NAT66 on Fortigates is 1:1 NAT, i.e. prefix translation, not n:1 NAPT, i.e. address+port translation.
I can't imagine why one would ever intend to use NAPT over NAT when the addresses were available though (e.g. on IPv4 where having a minimum of 2^64 public addresses per connection is not assumed), which is the only reason I wouldn't expect anyone to have bothered implementing it. So sure, it's what people refer to on IPv4, but it's not materially different from 1:1 NAT or necessarily adding any additional value.
Discussions about NAT very often forget that it works by messing up with the transport layer. The fuzz is about hiding IP address and exposing services, but the worst thing about NAT is that technically it should not count as a connection to "the Internet".
It exploits TCP/UDP properties to fake endpoints into thinking they have a proper connection.
To visualize this, imagine we somehow are out of available email addresses. Email providers have an idea, they would make one inbox for multiple people and have an SMTP proxy that will read the message content, look at "Dear ..." heading and proxy content as new message to "internal" network. All clients would see the same internal addresses from private space (picture 192.168.1.1), but upon sending the provider proxy replaces it adding "King regards, <shared address>".
What if someone format the text differently? What if they use new format unknown to the proxy? It just won't work: https://en.wikipedia.org/wiki/Protocol_ossification
Someone would then argue it is good as it hides your real address from spam and theft, but we can clearly see the massive disadvantages in this design.
The tension here is the difference between theory and reality. In reality, IPv4 NAT is the only thing protecting most users in their homes. If you force IPv6 on this same population, you have to give them an equivalent posture by default.
This is kind of like writing an argument that motorcycles are not unsafe because they lack 4 wheels. This is true, but if you put my grandmother on one and ask her to drive across town, she would not survive it.
No, the reality is that every modern network device running NAT for a user device network is also already a fully stateful firewall, because the software required to do one is virtually identical to the other.
You can't buy a home router with NAT and no firewall, and no home routers ship that don't also have a default deny rule on that firewall. The same is true for SOHO routers and effectively every consumer network gateway device you might buy.
You literally have to go well out of your way to find a network device capable of NAT that can't function as a stateful firewall, and when you find it, it's likely to be carrier-grade. In other words, not intended to be capable of any security at all. The amount of NAT processing it's intended to handle will challenge the hardware enough as it is.
NAT isn't protecting them. Not being on the public internet at all is protecting them.
NAT is then unprotecting them a little by letting them punch out again. It's super easy for routers to implement this behaviour by default if your LAN is publicly addressable, and removes a whole class of exploits caused by applications making NAT hacks.
I think you missing my point. My point is not that IPv6 cannot be secured, it is that the author's take is controversial because people are skeptical about whether networks ARE being secured when NAT is not present. This skepticism is backed up by the research paper that I quoted and real world experience. IPv6 is deployed in many places incorrectly and without the good defaults. IPv4 NAPT in residential networks acts as a last line of defense because most users have been incapable of turning it off.
I suppose I will distill my thought into the assertion that the author should have prefixed his title with "In capable hands,"...
"Collectively, our results show that NAT has indeed acted as the de facto firewall of the Internet, and the v4-to-v6 transition of residential networks is opening up new devices to attack."
ISP hosting a virtual machine you remote desktop into from internal network as the only way to access the external internet can also work as a "de facto firewall".
But the best de facto firewall is a proper firewall.
I don't disagree with your comment that the best de facto firewall is a proper firewall. I think you are reacting against the idea that I am saying IPv6 is less secure than IPv4. I am not saying that.
The point of my original post is that the author's take is controversial because people are skeptical about whether networks ARE being secured when NAPT is not present.
They are right to be skeptical, in my opinion, because the rollout of IPv6 has been bungled over and over again. That is not a problem with IPv6, its a problem with the adoption of IPv6.
This is entirely untrue. Every shitty router shipped by ISPs this side of the doctom bubble has a stateful firewall enabled by default. NAT is distinctly not the only thing protecting most home users. Not to mention every OS I know of shipping with its own firewall enabled with default deny on inbound.
You are stuck on the theory of what is protecting this population. In practice, less than 1% of these users can or will turn NAT off.
Can you imagine how great things would work out with a public IP on all your nana's computers, NAT turned off, protected by the prowess of her Arris gateway's stateful firewall?
Telstra, one of Australia's massive telcos who are the "go to" telco for nannas who don't know anything about this internet thingy, have IPv6 enabled by default on their CPE routers. Without NAT. With a stateful firewall. Works perfectly fine for their millions of customers.
It would work out just fine, because NAT was never providing any actual security to your nana. It was only ever the firewall which made her secure, not NAT.
Yes, it is the case. In the real world, there are malfunctioning ALGs, permissive defaults, and connectionless protocols that are poorly tracked by these sloppy, underpowered "SPI" devices.
It's not, because in the real world NAT only affects your outbound connections. That means that turning it off only changes the behavior of outbound connections, not inbound ones.
Any inbound connection that would have worked before you turned it off will still work afterwards, and any that wouldn't have worked before will still not work afterwards.
Think about what 99% of SOHO users have: PAT (Nat Overload). This NAT impacts the way a connection is established in BOTH directions. Inbound connection attempts from the Internet to the NAT public IP address of the SOHO router can go no further than the router. We are talking what 99% of users have installed.
Maybe this is the reason for some of the disagreement. I am focusing on what is installed at 99% of user installations (PAT). I would agree with the comments that a 1-to-1 NAT offers no EXTRA security.
That's the type of NAT I've been talking about the entire time. It doesn't do anything to inbound connections unless you explicitly tell it to.
Connections to the router's IP address go to the router, but you need to consider what happens to connections that go to IP addresses on the network behind the router too.
I think two things can be true here: the article's assertion that "IPv6 is not insecure because it lacks NAT" is correct, and other peoples' assertions that NAT provides an extra layer of security are also correct.
A correctly configured IPv6 firewall provides equivalent protection to a correctly configured IPv4 firewall and NAT. Either way, connections that do not originate from within the local network are going to be rejected.
But if the firewall is misconfigured, then NAT will make it more difficult for an attacker on the internet to discover and exploit vulnerabilities on the local network.
"Defense in depth" is a valid security principle. But NAT also creates real-world problems that IPv6 solves. As with all things, there are tradeoffs, and whether or not you should enable IPv6 on your local network depends on your use case.
Ipv6 also creates real world problems that NAT solves -- multi upstream WAN with path selection for example
Dual stack introduces security problems (you now have two things to secure). There are still devices which will fail to run on an ipv6 network -- even with a 64 gateway (software which communicates to a specific IP address for example - e.g. a device which "checks internet connectivity" by pinging 1.1.1.1 and 8.8.8.8, yes it's terrible, and yes it happens)
IPv6 without NAT is not insecure; I can and do have a stateful firewall that denies unwanted inbound connections. But it does not matter if my auditors think otherwise and the whole Internet tells me that arguing with them will end my career.
I find the discussion about whether or not NAT is a security feature or not interesting. To my mind NAT was intended to make ipv4 last longer in a clever way as address space dried up. A happy accident of this solution is a basic security feature.
Ipv6 doesn't (currently, will it ever?) have the same address space problem so each device anywhere could be globally routable. But we know that's not really a good thing security-wise. But why couldn't we implement NAT for it as a security mechanism, instead of an address space solution?
Admittedly I'm not expert so I might be talking shit.
You said it yourself. NAT was introduced to solve the address space issue. At that point firewall were already a thing.
You also acknowledged correctly that IPv6 Will botnrun into the same address space limitations.
You said NAT is not a good thing Security-wise. Then you follow up the question, why we shouldn't add that to IPv6 as a security feature. It's hard to understand the train of thought.
So let me answer this. While NAT incidently does something similar to a firewall, it is not a security feature. NAT must track any outgoing network connection in order to understand where to route incoming packets. If a packet it not a reply to an established connection, it is dropped. Otherwise the NAT must look up who opened the connection. A NAT can only work if stateful.
In a routable connection, ALL of that can be based on the static routing table.
Imagine a university with 10,000 computer, all of them having opened maybe 100 concurrent connections. The NAT must track every single connection and do a lookup for every packet.
In a routable network, it just looks up the destination IP in the packet and sends it to the next hop for the destination IP.
All while hopefully a firewall is in front of it.
So why would you want to reintroduce NAT to IPv6, when both issues are efficiently solved already?
Why would you do that when a regular default-deny firewall is and has always been the security feature you need, without the complications and problems of NAT?
Like I said I'm not expert, and was likely talking shit. I was just speculating based on the discussion in this thread.
I think the complications and problems of NAT seem to add a default layer of security to the whole thing. I know next to nothing about firewalls though, which might be the point here, but would a default deny present any problems for me that NAT would allow? That is is there a situation where as a layman I might run into problems receiving data for a valid process that wouldn't happen if it was just NAT?
A firewall is the security feature you want. With a default-deny rule, which most will come configured out of the box with, it does exactly what you expect: block all unsolicited incoming traffic.
Most people are probably actually running a firewall with NAT anyway, they just don't know it because an appliance with default-deny is pretty much install and forget for most people. So, no, it doesn't cause any additional problems.
The only difference with IPv6 is you don't need to NAT any more, but you keep the firewall.
It's important to remember NAT is part of the IP routing layer. In its regular form, a router just forwards packets to where they should be going. So it's plugged in to one or more networks, receives packets on one interface and forwards them, unmolested (well, mostly), to another interface. It's almost completely analogous to letters going through the postal system. The postal service just forwards letters around by looking at the address. It doesn't modify them in any way.
NAT is a bastardisation and is like your postie scribbles out the "return to sender" address and replaces it with his own. If you were to reply to that address, your postie would remember he did that, and replace the address you wrote with the original address he scribbled out earlier. It's not how IP routing is supposed to work at all and, in fact, a device doing NAT cannot strictly be considered a router at all.
Something you can add to any device is a packet filter. A router must not filter packets as it then wouldn't be considered a router (similar to molesting the packets with NAT). But you can insert a packet filter before things get to the router. If you glue those two things together and bundle it in one device then, voila, you have a firewall. A stateful firewall is conceptually like a packet filter and router glued together and working closely together. But you can just think of it like telling your postie "I only want to receive letters from mum" and he just burns all the rest before they get to you front door. (In reality you also want to allow correspondence so it's more like "only allow letters that are replying to letters I sent, which you'll know because you're my postie, or if mum sends a letter first, allow that too").
Writing this up makes me think... why don't we just teach this stuff using the postal system as an analogy? It's an almost perfect analogy and surely even today anyone understands this concept.
I profit from NAT-less network, can connect to my home device from a VPS without thinking it's sitting behind 2 routers. No port forwarding needed, just connect and it works. Well, I guess I still need to enable connection to this device on a firewall, but that's obvious.
We really should move on from IPv4.
By the way, IPv6 also supports NAT if that's what you want. But using NAT in IPv6 is like saying "i want to have my own personal universe so I can put 2 Raspberry PIs in it".
NAT is just one slice of IPv4. Granted your private IP is not routable (with CGNAT now your gateway is also no longer routable), but think of other features of IPv6 that are congruent:
SLAAC basically means your routable IPv6 address changes so many times in a day (and there are multiple of those at any given instant) that even if the attackers know your prefix, its going to be very difficult to do anything meaningful. the address space is too big.
And we are assuming here that there is no firewall.
Note : macOS firewall on a new install is disabled iirc.
Ok, I'll bite: why do you say that IPv6 lacking NAT (which is not true by the way) would be annoying? We can finally get rid of an ugly workaround from 30 years ago that broke one core principle of the Internet (end-to-end connectivity) and a ton of protocols that required even uglier hacks (FTP and SIP ALGs, TURN/STUN, etc.) to barely work. Why would this be annoying?
At my previous place IPv6 was useable (I was getting /60 prefix rather than /64 I’m getting now) but the prefix was changing often - several times per day. This was annoying because every prefix change all addresses of my devices changed too. So in practice I always used private IPv4 addresses to connect to them.
A NAT would solve this issue.
Well, delegated IPv6 prefixes are supposed[1] to be static or somewhat persistent, but some ISPs do this, yes. This is most likely a practice carried over from IPv4 where there is a small pool of addresses. Fortunately in my experience it's not too common: most ISPs that deployed IPv6 did it the right way.
Anyway, to get persistent addresses you can set up a ULA prefix (the equivalent of RFC 1918 addresses) and a simple prefix translation[3]. This is a form of NAT, but unlike the usual IPv4 NAT (actually NAPT) it doesn't deal with ports, so it's slightly less annoying problematic. There also are a few more techniques, like using mDNS and writing firewall rules that match the suffix of the client addresses, but not many CPE allows for this.
Right, the ULA prefix theoretically has lower preference, so it should only be selected to reach hosts in the LAN and the GUA for everything else, but I don't know how well softwares handle this in practice.
Source address selection is usually left to the kernel, so that part should be okay. It'll pick a GUA source for a GUA destination unless you've changed the labels with `ip addrlabel`.
IPv6 doesn't "lack" NAT. There is nothing preventing you from using ULA addresses inside your network (IPv6's version of RFC-1918) and then running NAT for those addresses on your router. IPv6 just doesn't _need_ NAT, but it is still an option.
IPv4 is not secure because it requires a NAT in order to be?
Big centralized online services does not want IPv6 because it "unlocks" internet as intended, full p2p at scale. They won't let that happen easily.
And please stop with that 'computers security', we all know here it does not exist (NAT or not), it is a fantasy. Saying otherwise is engaging in bad faith.
> And please stop with that 'computers security', we all know here it does not exist (NAT or not), it is a fantasy. Saying otherwise is engaging in bad faith.
So you are willing to message me your credentials then?
NAT is not inherently a security feature, however where NAT happens is somewhat important.
A local router that I can control deals with how to map from my public IP to my private IPs.
This is not security but is obfuscation of the traffic.
Obfuscation becomes almost impossible in the IPV6 context where NAT isn't necessary, it becomes optional, and given the likely trajectory that option will be exercised by sophisticated enterprise customers only.
As the article mentions, if you want to use NAT with IPv6, you can. The fact that it's optional doesn't mean that address obfuscation is suddenly impossible.
It means it is not by default, which as we know, is a powerful choice these days.
ie enterprise customers will enable it, consumers will do it if they are tech savvy and your mom/dad/granddaughter/grandson/nephew/niece will have the default option.
when you are at home you will have nat and when you are not you will be uniquely identified.
If you can be uniquely identified without NAT then you can be uniquely identified with it too, because IPs don't contain your identity. You get them from a combination of the network prefix and a random number generator.
There's generally no reason to be enabling NAT when you have enough address space to not need it. It can be a useful tool in your toolbox sometimes, but it's not something to be enabling by default.
Networking folks love to write this article. “NAT isn’t a security layer.” I’ve been hearing it for 20 years. But while that’s not its purpose and while there are other layers that can provide the same features, it’s still a very useful piece of a larger puzzle of defining borders in a network architecture. Sometimes it helps if those borders are obvious to the eye, via the use of a private address zone, or if opening a port on the server can never “just work”, regardless of your external firewall rules. All sorts of trivial mistakes can be avoided with This One Weird Trick. So sure, it’s not technically required, and doesn’t solve every problem. But the constant harping about “NAT isn’t security” is sorta pointless.
I hate NAT with a passion. It's a terrible technology, whose disruptive nature has probably prevented any novelty on the transport layer. But this article is oversimplifying things.
It is well known that NAT is not meant for security and that NAT is not a firewall. But one cannot deny that it implicitly brings some "default" security to the table. With NAT it's basically impossible to screw you over because there is no meaningful practical way to allow inbound connections without the client explicitly defining them (port forwarding). With IPv6, you could have a lazy vendor that does not do any firewalling or a has a default allow policy or maybe buggy firewall. With NAT that is not possible. There is no lazy/buggy NAT implementation that allows inbound connections for your entire network, because it is technically not possible. When a NATting device receives a packet with a destination port that has not previously been opened by a client, it does not decide to drop this packet because of a decision by the vendor. It drops the packet because there is simply no other option due to the nature of NAT. That is what people mean when they talk about the inherent "security" of NAT.
Again, NAT is terrible. We need to finally get rid globally of IPv4 and all the NATting that comes with it. But let's keep it to the facts.
> there is no meaningful practical way to allow inbound connections without the client explicitly defining them
This... just isn't true though. Your router knows it has one network on one interface and one network on another interface and if it receives a packet on the one interface destined for the network on the other interface will happily route it unless something (a firewall) tells it not to. All the protection comes from trusting your ISP and its peers to not route RFC1918-private networks
Obviously the two aren't the same (especially given the need to do routing), but I've always found it amusing that in the systems world, capability-based systems (i.e. making it impossible to address things you aren't allowed to access) are gaining traction while the philosophy in the networking world seems to be going in the opposite direction (make it possible to address everything, i.e. IPv6 vs. NATted IPv4, then add filtering).
No, NAT requires state tracking, not a stateful firewall. If you want a firewall when NATing, you have to configure that separately. You can absolutely NAT without a firewall, and it won't act like one by itself.
When I was about 12 I was working on a PHP3 application, I had some issues with a MySQL query, and I pasted my code to pastebin (or whatever we used back then) and shared the link on IRC, the code included my database credentials.
Back then our ISP gave every computer a public IP.
The next thing that happened was that someone changed my MySQL password, and me being 12, I didn’t know how to change it back.
They made me beg for the password, to much amusement to the whole channel, and then they helped me secure it and taught me how to reset the password.
NAT would have saved me, but I wouldn’t have received a free, though a bit embarrassing, security lesson.
That's what the firewall on your router is for. NAT might also stop someone connecting, but it's not a guarantee. You can get given a public address and be exposed, you can find out your server actually does UPNP automatically and so is exposed, etc... a firewall is more explicit and a better defence.
That's a strange example. An unauthenticated server on a LAN wouldn't be exposed to the Internet any more than a network using NAT would be. You would need to explicitly configure your routers firewall to expose a local node, the same way you would need to explicitly configure port forwarding with a NAT based network.
I've see some argue that a hypothetically buggy router would somehow be less likely to fail if NAT was used but really, that could be equally said about bad port formatting defaults, which have in fact happened. Complexity is what increases the likelihood of bugs at the end of the day.
NAT is just an addressing hack, a weirdly complex way of indirectly routing to local addresses. It only influences what is written on the envelope, not how that envelope is processed at the post office.
We haven't forgotten that, but we're also aware that non-IT people can't run NAT either. They can plug in a box that already has NAT configured though, and if they can manage that then they can also plug in a box that already has a firewall configured.
VMs work fine without NAT too -- DHCPv6-PD lets the VM software automatically request a routed prefix.
With IPv4, if NAT isn't working right then I simply cannot get online and I need to fix it. Fail safe. With IPv6, when my computers being globally addressable is the norm, if my firewall is misconfigured my computers will probably still be online. Fail unsafe.
Arguing this is pointless anyway because it's not even my decision, it's my ISP. I am however quite happy with my ISP's choices in this regard.
Maybe it’s because I don’t consider myself a super technical person, but I find it so hard to parse the title of this blog post. When I first read it, I thought it was saying something like, “The protocol is not insecure, and the reason is that it lacks a NAT”. However, after reading the blog post, it seems like it is intending a different meaning. The meaning I think is, “the protocol is not insecure just because it lacks NAT”.
Defence in depth is a valid security approach, and NAT provides another defence in depth
If you have a vulnerable ipv4 machine on 192.168.0.24 port 2345 which is hidden behind a public IP of 1.2.3.4, and you set your firewall rule to allow any inbound traffic, with no nat rules then it will be exceedingly difficult for a remote attacker to reach that vulnerable port (they have to trick your router's connection table into routing it)
If the same machine is on 2100:1234:5678:a::24 then that port is exposed.
Now sure your firewall could block the traffic, and that's great. But having multiple layers of active configuration to allow the traffic through is more secure than having a single layer as it means you need to screw up twice.
Worse than that with dual stack you may think you have set your firewall to block non-established connections at the ipv4 stage, but your device is sat there on an open ipv6 address you didn't even consider. Dual stack is certainly less secure than single stack as there are two opportunities to screw up.
It’s the same layer. On router admin panels it’s literally the same UI for firewall rules and nat port forwarding. If you went in to your router admin and allowed all ports on v4 it would be exactly the same as allowing all on v6. The router will happily forward all connections to v4 devices the same.
> If you went in to your router admin and allowed all ports on v4 it would be exactly the same as allowing all on v6. The router will happily forward all connections to v4 devices the same.
Forward to where?
You have to actively say "forward port 80 to 192.168.0.2". Port 80 can't be forwarded to 192.168.0.2 and 192.168.0.3.
Where allowing all traffic means you can talk to 2100:xxx::192.168.0.2 and 2100:xxx::192.168.0.3
Yes, you can't expose multiple computers at the same time on v4, but you certainly can expose one, in exactly the same UI you exposed v6. And then that one you exposed has full access to the local network beyond the firewall to expose the rest.
The argument seems silly almost like "I deliberately shot myself in the foot, but with v4 I could only shoot one foot at a time while v6 lets me shoot both". The answer is to just not shoot yourself in the foot, since you have to make a deliberate effort to do this in the first place, just not doing that is the answer.
NAT is a trivial feature on top of a connection tracking firewall. It also provides a large number of benefits - the ability to route traffic via different routes with PBR, without having BGP upstream, to keep routing decisions in the router rather than on each device, to not have to renumber internal IP addessing when the ISP changes, to have consistent view of what happens at a network level
I think there's a philosophical difference between IPv4 and IPv6.
IPv4 is from the era of local computer networks, which feature clients and servers. Clients talk to servers, but servers are not supposed to care or even know about clients unless clients decide to reach out to them. Client-to-Client communication is generally discouraged. The IP address is just a technicality and outside of local networks, just a part of the routing strategy.
IPv6 on the other hand is like an URL - an address you can use to find any device from anywhere on the planet. It makes no distinction between client and server. Which is why its pushed in places like IoT and smartphones - a voip call has no conceptual client and server.
One could make ones smartphones Ipv6 address openly available, and anyone could initiate a voip call to their phones. Would this be wise? I'd argue there's no scenario under which this doesn't cause an unacceptable level of risk, as even if the software is perfect, they'd be still vulnerable to DDOS attacks.
This means that NAT-equivalent firewall rules are necessary, which makes the whole discussion kind of moot, but it's not a good portent for Ipv6 that it makes previously unfeasible kinds of attacks potentially practical.
NAT also allows for other neat tricks, like IP level load balancing.
I'd say one huge and unambiguous advantage of IPv6 is that it makes UDP trivial.
> IPv4 is from the era of local computer networks, which feature clients and servers.
IPv4 on the ARPANET 'went live' in January 1983,[1] but the concept of a firewall didn't really happen until about a decade later (with some protocols having to be altered[2]):
> IPv4 is from the era of local computer networks, which feature clients and servers. Clients talk to servers, but servers are not supposed to care or even know about clients unless clients decide to reach out to them. Client-to-Client communication is generally discouraged.
No, it was meant to be a global address space where anything could talk to anything. That became unworkable due to scale and the limit inherent in using only 32 bits for the address space.
Some older protocols (ftp) don't play nice with NAT and need special handling, because address multiplexing was never intended to be a thing.
I could get behind this argument if commodity ISP gateways required special rules for IPv6 (from what I have seen - they do not).
As far as I can tell, this is just pedantry, until those features are implemented in most ISP gateways. Akamai has been warning that IPv6 scanning attacks are on the rise.
I'd argue not about security, but transparency - when having your mac address partially included in the IPv6, you would basically allow browsers and other systems identify you without additional steps.
Early IPv6 commonly used EUI-64 addressing, which did embed your MAC address into the IPv6 interface ID
Sure, but your MAC address is easily spoofed. In fact, all major operating systems do it nowadays for public WiFi systems and you have to explicitly opt-out of randomising your MAC Address when connecting.
No one's complaining that IPV6 is insecure. It may as well be very secure, but no one bothers to understand it if they're not paid to do that.
Of course you can have default drop in your IPV6 firewall, but it's far easier to keep in your head that internal NATed IPs aren't accessible and "real" IPs are.
I've seen plenty of discussions here on HN where people have made that claim. Even more elsewhere on the discussion side of other news websites by sysadmins that disable IPv6 because one of their industrial routers didn't come with a default deny rule that one time which made them think that's normal.
The people who are supposed to know IPv6 never seemed to have learned it and many of them don't seem to be open to the idea of learning something new. Of course half the world runs on IPv6 now so they'll have to get with the times eventually, but the prevalence of statements like these is quite depressing.
> many of them don't seem to be open to the idea of learning something new
To the idea of learning something designed by commitee, over complex and stinking of enterprise and that you simply can't deploy "by hand".
One of the advantages of NAT by the way is that your "outside" configuration and "inside" configurations are completely independent with the exception of the snat rule.
The "inside" is your /56 or /48. You can add more local-only "inside"s if you'd like, which is useful for terrible ISPs with rotating network prefixes. The "outside" is everything on the internet.
If you can make your way through the absolute slog that is ARP+DHCP, you can get through NDP+SLAAC. Or even NDP+DHCPv6 if you're a control freak.
> One of the advantages of NAT by the way is that your "outside" configuration and "inside" configurations are completely independent with the exception of the snat rule.
If you want NAT, then set up NAT. Your fdb6:fc49:f5ae::/48 ULA is your 192.168.x.y address. Set up DHCPv6 if you'd like to pretend you control your address space. You could even just ignore the spec and use fdfd::/48 as your ULA so you can memorize addresses (fdfd::1, fdfd::2, that's even shorter than 192.168.1.2!). Use fe80::1 (a perfectly valid address) on your router as a standard gateway and have it do NAT to the outside world.
Even though it's heavily discouraged (because NAT is a massive hack after all), you can do NAT on IPv6 without any special tooling.
Been running IPv6 for years on both my home network and internet servers, and I've never had to think about NDS, DAD, RS. SLAAC is something I've only had to think about once at network setup time, less than I think about DHCP on my IPv4 network. RAs I have actually had to think about because Unifi has had some regressions in IPv6 support over the years, but that's fixed these days so it's likely going into the "don't need to think about it" bucket too.
Of course I'm sure you think about DHCP address management, DHCPDISCOVER and DHCPOFFER packets, mDNS, ACD, etc., since clearly you like to get into the weeds of your network
I have to because I have two fiber connections to the outside world :)
Nothing fancy like automatic failover or load balancing, they're just there.
With ipv4 i change the default route on a machine to the internal IP of one of the ISP provided routers, that one NATs it and i'm all set.
With ipv6 that insists on giving me an ISP assigned address internally, what do i do? It only works with that particular ISP. I'd still have to NAT and somehow disable the ISP addys, if i even can.
I suppose a $3000 Cisco box will solve all my problems, wouldn't it? Or maybe a $3000 + 150/month support contract? If Cisco even bothers for that little.
I’m not using any networking implementation that’s less tested and ipv6 is less tested. Network routing means there are dozens of TCPIP implementations touching traffic. The benefit of ipv6 for my case isn’t worth the risk. If you’ve never run into an ipv6 specific bug good for you.
I’m not sure what you mean by this. In other words, there is code that is specifically written for ipv6 handling which in some cases isn’t tested as thoroughly as ipv4. Less of an issue as ipv6 adoption grows but it’s non zero. I don’t like the address format, I prefer NAT by default, routing by prefix, like everything ipv6 offers I don’t feel comfortable with even without that. But it’s the most technical reason I don’t like it, the rest is a personal/vibes thing.
As someone with limited networking knowledge, I’m not really getting smarter here. Some say it adds security; others disagree. Let me ask this: does IPv6 benefit me in any way if I have multiple devices at home behind a router and I'm not running any servers or similar services?
No idea what you're doing on a daily basis, but let's grab a not-exactly random example. You and your friends are at your house trying to play an online game of King's Court (it's super checkers!) with some friends in Denmark. For whatever reason the developers decided all clients will use port 12345 to communicate. In ipv4 with NAT, local connections will be possible but only the first one to try to communicate out will ever possibly succeed. You and your friend are thwarted and have to find some NAT-defeating means or just give up on doing 10-jump moves to ruin each other's evenings and have an internet drinking game. With IPv6, all of it works fine.
Most casual users have lived with NAT so long they assume its limitations are natural. But they are not. You can achieve the same result with a firewall or ACLs or whatever on ipv6, but that's a choice and not a limitation.
Do you play video games with P2P networking? Then your choices are to pick one of the following:
- the hosting player enables upnp
- use ipv6
- the hosting player manually sets up port forwarding (consumer routers often talk about a DMZ option which takes an IP address - really this is just forwarding all ports not matched by any other rule)
Smart home and lighting standard Matter over Thread requires it. Discovered this after i bought some Ikea smart lights. Though you don't need a public IP6, a local static IP6 with SLAAC is enough.
I wrote that comment, and you can write to yourself how many times you want that NAT is not a firewall.
The truth of the matter is that NAT absolutely _is_ a firewall in _practice_. Not in theory "because it doesn't drop packets" or "because it was not meant to be a security feature". But in the actual real-world practice.
It effectively protects most networks from most attackers without ANY additional configuration, making it inherently foolproof.
Here, I put a private key for a wallet with 0.01 bitcoin at this address: http://192.168.80.26/ Go on and take it. It's not protected by anything else I disabled everything but NAT. Heck, here's my real IPv4 even: 172.56.107.111
Is this a _good_ reason to not do IPv6? No. But it absolutely _is_ a reason and needs to be acknowledged.
If you don't have RPF enabled on your router in theory your upstream peer can send traffic to 192.168.80.26 and it would pass through. Reply traffic may or may not be natted depending on how it's entered in the connection tracking table.
There may be situations where your router can be tricked too, I can't think of one off the top of my head which wouldn't also apply to a stateful firewall sitting on a routed network segment with no nat, and it would typically be a vulnerability to patch
But your principal is right -- it's far harder to exploit than just connecting to an ip of say 2001:172:56:107:111::192.168.80.25 on port 80
For 99%+ of residential users, the upstream peer is the router owner/operator, so they can just direct the router to hack you if they wished. So this NAT "vulnerability" is not useful in practice, since it can only be used by your upstream which already "owns" you.
Yes, the upstream can hack my private wallet. But it's a CGNAT device somewhere in the TMobile network, and hacking it is not at all trivial.
And it's true for most NAT users. Even with the cheapest possible devices.
Of course, in practice most NAT devices _are_ firewalls because they do block incoming packets that are not a part of an established connection. After all, it adds only an insignificant overhead because a NAT device has to track connections anyway.
With IPv6 this is not the case. A router with misconfigured connection tracking will still work. And I actually have seen this in practice on a device that had a missing IPv6 conntrack kernel module.
And it doesn't really matter. You can call it "alksjfaliskdfgh" if you wish. The fact is, NAT adds a security barrier that is incredibly effective in practice.
Wrong. If I turn off the NAT on my router, my computers will not be able to get online. If I turn off the IPv6 firewall on my router, I won't see anything unusual.
And yes, this has happened to me when I forgot to compile the IPv6 conntrack module.
Security is a state of mind. So, whatever makes you feel secure, it's your security tool. NAT can be used for security, like VLANs gets a lot used for LAN security. And BTW, NAT can alter destination of IPv4 packet, but also the source. Which is not necessarily only masquerading, and it's seen a lot as embedded security, especially for home Internet. A firewall does not provide security by itself, it has to be configured in the specific way for the situation. I've seen a lot of firewalls with 100s of rules, but the first one was accept all forward, forgotten there by an admin after a test several days/months/years ago.
We are trying too much to put things in unique and well defined boxex. Universe does'n work like this. Security is just a state of mind.
With IPv6 you might have to use a hack to make firewall allow incoming packets (like sending a dummy UDP packet to the peer first). The firewall only read, allow or deny these packets. While NAT must mess with the message IP//TCP//UDP headers to work.
The is a huge difference between: I assume my crappy router's firewall works and is configured safe by default. And I assume my crappy router's doesn't forward ports by default.
I actually wanted to write this article myself but every time I started writing it up I thought "fuck, this is too obvious, I'm being condescending". But then I read these comments and I'm sad again.
So with IPv4 with NAT you definitely have this security. According to this article with IPv6 you MIGHT have that security -we don't know. That's not secure.
Also with IPv6 with NAT you definitely have this security, but with IPv4 without NAT you MIGHT have that security...
Disabling security features makes them disabled. Also security of NAT is a side effect because of that the devices behind it are not connected to the internet just tricks them into thinking they are.
It's wild because saying that NAT is required kind of admits your machines are vulnerable on the LAN! You should have good firewall rules no matter what.
An incoming message to an IPv4 NAT router will not be forwarded to a LAN device unless it matches a known flow (typically continuation of a conversation, typically initiated by the LAN device, which is expected), or the user set up a DMZ forward to a particular destination. There is actually no reasonable way for non-DMZ LAN devices to be exposed to the noise.
For non-NAT IPv6, sure a firewall might be on by default, but it can be turned off - and therein lies the potential exposure to every LAN device to directed traffic.
In other words, the risky zone for IPv4 NAT tends to be setting up a DMZ exposing 1 device, while the risky zone for IPv6 non-firewalled tends to be exposing all of the devices behind the router.
Disabled protection does not protect. This is UI/UX thing, not something in Internet-scale protocols.
I can "curl https://somethingshady | bash -" but won't blame RFC1738.
nitpick on the title, the way it's worded makes it sound like "IPv6 is not insecure because it lacks a NAT, (but it's insecure because of other reasons)".
would be better if it was "Lacking a NAT doesn't make IPv6 insecure".
I have yet to see a "NAT is not security" rebuttal that does not make either one or both of these points:
- NAT is not a security feature because it wasn't designed as one (this post), and/or
- NAT is not a security feature because it does not, without a firewall, protect against an attacker on the WAN subnet, or another difficult-to-exploit scenario.
And yet making LAN devices unroutable from the Internet does on its own makes exploitation much more difficult. It's admittedly not a perfect measure, but it's one that IPv6 deployments with routable addresses for LAN devices lack. I would wager this does make a difference in the proliferation of botnets, especially given the lackluster standards of consumer network equipment security.
You should read my other comments on this post. I've attempted, multiple times (but apparently without much success) to make the point that NAT is not a security feature because it does not, without a firewall, protect against an attacker.
You don't need a qualifier like "on the WAN subnet". It just doesn't do anything to protect you from inbound connections at all.
I think you're not technically wrong, but you're defining NAT differently than the majority of people you're arguing with (those who assume NAT also implies a firewall blocking inbound connections), and the remaining minority (the "on the WAN subnet" crowd) are dismissing outright the idea as a reasonable attack vector that an attacker close enough to be able to send packets destined for non-internet routable addresses to your router.
Is the latter something that was/is actively exploited?
- share a precious IP address at the NAT gateway border
- hide your internal LAN from external network mapper
Last point becomes moot when internal mapping software kicks in, legitimately or not, JavaScript or disingenuous application/daemon/app.
Welcome to Cybersecurity SecOP.
Now this is where Carrier-Grade NAT really shines: added functionality of handling mobile devices' changing IP addresses as it hops from one subnet to another (switching between G5/CSM/WiFi/personal-hotspot)
> handling mobile devices' changing IP addresses as it hops from one subnet to another
We could create TCP/UDP alternative that would handle mobile IP addresses or even make traffic take multiple of those paths at once (look up MPTCP). But we cannot apply it in real scenarios mostly because of middleboxes (like CGNAT) messing up and limiting the messages that should be taken care of on the endpoint.
This article may have been prompted by my (or similar) response to John's comment on [1] yesterday.
He stated:
> NAT is not a firewall: all it does is rewrite packets, it does not drop them.
I noted (without quoting at the time) that the article actually mentions this aspect of NAT, here is a quote from yesterday's article:
> Time and time again we are lectured that NATs are not a good security device, but in practice NATs offer a reasonable front-line defence against network side malware scanning and injection, so there may be a larger story behind the use of NATs and device-based networks than just a simple conservative preference to continue to use an IPv4 protocol stack.
Since I didn't state it before, I don't see any need to add NAT to IPv6 and certainly not for security reasons when a firewall is the correct way to secure networks. I don't feel that IPv6 is inherently more or less secure than IPv4, regardless of NAT. I also agree that even for IPv4, firewalls should be used and that NAT should not be relied on as a security measure for any remotely high stakes situation.
The reason I made my comment though is because I seem to share the same opinion as yesterday's article's author that people stating "NATs are not a good security device" are missing the point that in regard to IPv4, NAT may not be a "fully proper" security measure, but in practice it is "plenty good enough" for the vast majority of internet users.
People proclaiming how NAT is not a security measure seem to me to be ignoring our reality where 100s of millions of consumer routers, incidentally but nevertheless effectively, use it as one. Even without a firewall to drop packets on these devices doing NAT, they effectively block a whole class of automated malicious activity.
Is it safe to have unprotected network devices shielded only by NAT without a firewall? No, not really.
Should you use a proper firewall even if you have NAT? Yes, absolutely, but a lot of people don't and are nevertheless adequately protected considering they probably have no "open" devices on their network and have no particular reason to be targeted by a truly determined malicious actor.
It s true. That s not the reason it is insecure. The reason it is insecure is people who infiltrated the committee made sure to make data exfiltration possible through mandatory ICMP for everything.
Good luck setting up proper firewallimg rules for IPv6 while both respecting its specs and preventing hard-to-detect exfil through ICMPv6.
It's a rube-goldberg of a protocol and it s hard to believe it s all incompetence and there ain't t some malice involved.
NAT for IPv4 was an accidental godsend, especially useful in an era where you d hack your neighbors' computers when they where on the same subnet as yours. Don t tell me it didn't t happen for I was doing that on dial-up back in the days.
Thankfully the point is mostly moot because people are still free to use IPv4 at home/companies while having their router using IPv6.
IPv4 shall thankfully outlive me. And I don't t care if it means more work for people working in the "punch the monkey" ads industry.
Makes sense. But I’d argue NAT is still more secure because it physically breaks the connection between your internal host and the outside world. Without an existing routing table there’s no destination to route the packet to.
I disagree with this strongly. The intended use case of NAT or the existence of inbound connections being blocked by routers is irrelevant.
For NAT, of course it isn't meant for security, but it has a side-effect of creating a network boundary, and that has positive security implications.
If your router doesn't have a firewall blocking any connections, NAT still has security implications as it is deployed typically on consumer networks, which is a one-way port-address-translation for outbound traffic.
The important bit here is not NAT or firewalls, but layer 3 network segments!!!
An RFC1918 private addrerss space is not internet routable. Furthermore, routers shouldn't "default route" traffic from arbitrary connected networks by default. But "should" aside, the typical default consumer router behavior is that they don't NAT translate inbound traffic, they can't!
If a random internet IP wanted to connect to port 80 on a device at 192.168.1.200 in your home network, it doesn't know how to tell your router what IP to translate it's request to the router's public IP to. That is the essential positive security implication. In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't forward such traffic.
With IPv6, end devices in your network get a globally routed address, someone can try to connect to that same internal device as my earlier example and succeed with the same exact default behavior in place.
IPv6 is thus, by relative metrics, insecure by default. It does not mean it cannot be secured, but it is less secure than IPv4 in typical deployments where extra care isn't taken to secure it properly. If your answer to this is "well that's just because people who deploy networks are dumb" then save your self the effort or arguing that, it is irrelevant. That is how networks are deployed in the real world, period. People make mistakes in the real world. People don't know best practices in the real world. So out of the box, things need to consider real world hazards, and IPv6 does not do that.
You can support the adaption of IPv6 nonetheless and I would have no disagreement there.
The problem is, as I understand it, is this hypothetical network where there is a NAT but no firewall just does not exist.
>In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't forward such traffic.
This is typically handled by the firewall, not the NAT. You can easily come up with scenarios that without the firewall, the NAT could be trivially defeated, e.g. by port scanning.
It is not, you guys are talking from a specific american ISP perspective where you have these modem+router+gateway+firewall combo devices. Not everyone gets that.
Many get just a modem and buy a cheap router which may not have a firewall. MANY more get just a modem and their laptops are directly exposed to the internet (!!!), those you can't do much about, but many put a "router" that's just a cheap wifi access point with layer 3 routing and NAT. If you chose to "bridge" a device (like those internet exposed laptops) or port-forward, it will just work (even with ISP routers!!) there is no firewall rule change required.
I've worked in this space supporting consumer grade routers, and then worked in enterprise networking. But don't take my word for it, you all can take a trip to shodansafari, how many devices are listening port 3389 and 445 with consumer grade laptop names?
But it isn't a popular thing to say for whatever reason. I guess IPv6 is a political ideology now lol.
>Many get just a modem and buy a cheap router which may not have a firewall
What cheap router are you buying that doesn't have a firewall. I think the problem is when people hear "firewall" they think the router is running pfSense or something. Even cheap routers will have a basic, non-configurable, firewall that will block inbound connections. That is separate from NAT and has nothing to do with IPv4/IPv6.
It's an AP that serves DHCP addresses on the lan port. that's it. It has some port forwarding too if you set it up, no firewalling there. For modems, most cable ISPs let you buy a DOCSIS modem, there is no router, whatever device you connect gets a DHCP lease right on the internet (and ipv6), most people buy cheap "routers" like that one to add "wifi" to it, and it works great for the money. And honestly, I have yet to see one that does have a firewall, but then again I've never tried the $500 router options or seen someone who did.
These devices are not meant to firewall, they have no need to firewall. if you do "bridge" or "portforward" they assume you want everything forwarded, they don't let you configure any firewalling by design, and they don't have any firewalling because it isn't needed. They have a dedicated WAN port, the management interface doesn't listen on that port and LAN devices are NAT'ed with IPv4 so there is no need to firewall anything even behind the scenes. Their main use is to either extend wifi coverage or add wifi capability to modems.
Most people with fiber or *DSL get an ISP provided gateway which has a firewall,that's not the same as what I'm talking about.
I hate to complain about downvotes, but you all need to realize that it is the poorest and most vulnerable around the world that get hurt over this stuff. yes, ipv6 can cause unintended internet exposure of internal devices. period. that's not a dismissal or disapproval of ipv6, it is what it is, and that needs to be considered when deploying it. It assumes you'll configure your network properly, unfortunately the people who made ipv6 didn't consider consumers or people who screw up, they wanted to force people to configure firewalls, that works for corporations (until it doesn't) but not for most regular internet users.
The nat is a belt and braces approach - especially when combined with rpf. How will your packet reach 192.168.0.1 from the internet without having a nat rule to translate the packet, even if there is a firewall rule allowing all traffic
(If you control the next hop and the router doesn't have rpf checks on the wan interfaces you can forge a packet with a destination of 192.168.0.1 and route it via the public IP of 40.50.60.70)
I basically disable all ipv6 on my routers & firewalls completely. Waiting for the day we can disable ipv4 completely instead and use only ipv6 without NAT. But then each device will need its own firewall. NAT basically forces you to use some kind of firewall, which applies to all devices behind the NAT. But if we go all-in on IPv6, the firewall-by-default becomes much harder to implement in practice. Then we will need some kind of distributed/federated firewall config to constantly keep devices usable but safe, but then that will introduce a new set attack vectors. So we are kinda screwed for now. We need that new internet, maybe one where you unify static ipv6, dhcp6, dns, firewalls, nat and a few other friends into a single thing. Or perhaps we can use ipv6 only to get a static ip address for each home/building, which then has a small vlan/vpn to group all your devices together using ipv4 internally for ease of use.. which is close to what we currently have with cgnat+ipv4+wireguard+vlans. All round we have a big mess but it works well, if you know what you are doing that is. This is all to say we can even keep net-neutrality for a while longer, we are okay for now but the american/uk/china/india govs plus entities like cloudflare will actually destroy net-neutrality in the long run. Much like email delivery has already been ruined & captured. Sorry for the rant.
Not really. I’m sure there exists some brain dead CPE without a default-deny firewall. It’s just that I’ve never physically seen once, since around 1999 or so.
Bigger commercial gear, sure, but those would be special-purpose equipment that don’t support NAT either.
To a rounding error, everything which has NAT enabled by default also has a default-deny inbound firewall enabled by default.
You seem to have misunderstood how IPv6 works. In a home setup, all the traffic still goes through a single router which typically has a restrictive firewall enabled by default.
Only if enabled for a specific interface/network/zone/grouping... easy to misconfigure. You can easily misconfigure it to work fine for ipv4 but forgot about ipv6. Depending on what router software you use, this will either be easy or hard to spot. Sometimes the router software won't tell you explicitly that a certain interface is not included or that you have a gaping hole in your network somewhere.
If you use a consumer-grade device at home that you don't have full access to (meaning root via ssh and can update packages, cute web ui's alone don't count), you are screwed in other ways either way (hello open CVE's on unpatched routers....). I literally have a brand new Asus router sitting in a box at home, cause it has 3 open CVE's and asus basically dropped support for it, but they still sell them. Oh and I have root ssh access on it - it is running ubuntu 12 underneath it all (disgusting that asus haven't bumped it). Just all garbage. So I built my own x86 dual-nic/Wifi 6E router box that runs openwrt + adguard home + unbound + wireguard (all on proxmox) and all 4 systems update nightly. This setup absolutely crushes the performance versus top spec consumer-grade routers and I get to monitor it properly and update packages daily.
It is not at all "easy to misconfigure". First of all, the manufacturer is going to configure it for you in 99% of cases, just as they do for IPv4. Second, even if you want to roll your own firewall rules, it's trivial to set up a default deny on all incoming traffic.
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.
And if you have only the first line, what will happen if someone sends a request to the NAT's external IP on some random port?
Without at least some filtering a Gateway NAT appliance is vulnerable to:
* LAN IP address spoofing from the WAN
* Potential for misconfigured "internal" daemons to accept WAN traffic (listening on 0.0.0.0 instead of the LAN or localhost)
* Reflection amplification attacks
LAN IP address spoofing is indeed a valid attack vector, if the ISP is compromised.
Internal daemons on machines other than the router itself in the LAN network listening on 0.0.0.0 are not insecure (unless you have the problem from point 1, malicious/compromised ISP). The router won't route packets with IPs that are not in its LAN to them. Of course, the router itself could be compromised if it accidentally listens on 0.0.0.0 and accepts malicious packets.
Not sure what you mean by reflection amplification attacks, but unless they are attacking the router itself, or they are arriving on WAN with LAN IPs (again, compromised/malicious ISP), I don't see how they would reach LAN machines.
You do not need compromised ISP for spoofed LAN IP traffic, the attack could came from other clients on the same WAN segment.
Whichever machine has the NAT's external IP assigned to it will accept or refuse the connection, depending on whether they have a server running on that port or not.
The machine that has the NAT's external IP to it is, well, the NAT, by definition. So you admit that the NAT box will act almost exactly like a connection tracking firewall, even if only NAT is enabled.
No, I'm not going to "admit" that, because I know full well that it won't.
It's not like I'm sat here thinking "I know it does block traffic, but I'm going to lie to everyone that it won't". NAT in fact, actually, really and honestly, doesn't block traffic, and I think I've been pretty consistent in saying as much.
You've been consistently wrong, yes. A NAT router box will NOT translate a packet coming from the Internet (so, a packet with a globally routable IPv4 address) arriving on its WAN to the RFC1918 IPv4 address of any box sitting behind it on the LAN side, unless it is arriving on a previously open connection, or on a port the user explicitly asked to be allowed and forwarded - exactly the same behavior of a regular stateful firewall.
Of course it won't do that -- when did I ever claim it would? But that's not the same behavior as a stateful firewall at all.
A stateful firewall would block packets addressed to the router, or to machines behind it. NAT not translating a packet won't do either of those things.
I can only repeat myself: you are talking about the NAT module in the Linux netfilter. I, and the RFC, are talking about NAT as a concept: what behavior do you expect when you say "this device does NAT". Of course you can still have "pure NAT", but if someone tells you "set up a device that does NAT" and you omit that first line and later explain that this is historically and technically accurate, well, good luck with that.
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.
For those of you with this handy technology, the mobile phone, in the United States: you have an IPv6 address without NAT. Some of you even exist on a network using 464XLAT to tunnel IPv4 in IPV6, because it's a pure IPV6 network (T-Mobile). These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons.
This is all to underscore the author's point: NAT may necessitate stateful tracking, but firewalls without translation has been deployed at massive scale for one of the most numerous types of device in existence.
> These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons.
FWIW, I was interested so I tested this on my phone here in Finland (Elisa, the largest carrier here): IPv6 inbound TCP connections work just fine, unlike IPv4 which is behind CGNAT.
On mobile broadband (no calls) plans they also offer optional free public IPv4 address, but not on the regular phone plans.
(I did the test by installing Termux from Play Store, then in it running "pkg install netcat-openbsd" and "nc -6 -l 9956" and then connecting to that port from internet using telnet, while phone was not connected to WiFi.)
When you say no ipv4 on regular phone plan, you mean no routable ipv4 on the internet, or no ipv4 at all?
Regular phone plans on my carrier have a private IPv4 address behind CGNAT.
Right, that makes sense and the way all providers that I've seen, work.
In the case of T-Mobile, unsolicited inbound IPv6 connections are blocked, but direct P2P is still possible. I successfully established a WireGuard tunnel over IPv6 between 2 phones. With IPv6, since the internal addresses and ports and the same end-to-end, all that is needed is a dynamic DNS service; STUN isn't necessary. I did need to set a persistent keepalive of 25 seconds on both sides of the tunnel to keep the firewall holes open.
Interestingly, Verizon Wireless blocks connections to other Verizon Wireless IPv6 addresses. T-Mobile-to-T-Mobile connections work, Verizon-to-T-Mobile connections work, but Verizon-to-Verizon connections do not work. Given the way Verizon's network has stagnated while T-Mobile's network has been rapidly improving, it may be time to move away from Verizon.
Slightly off-topic, but if you have a modern Google Pixel phone, Google includes "free" VPN service (which probably collects/sells your data). This service uses Endpoint-Independent filtering, so if you send an outbound packet with the source port you want to map, regardless of the destination IP/port, you can effectively receive unsolicited inbound connections from any host on the internet that contacts your IP:port, so long as you send a periodic keepalive packet from the source port you are using to anywhere.
This is how researchers were able to remotely hack several Chrysler models. They used a Sprint hotspot to get an IP on the cell network and were able to connect to any other Sprint device. The cellular modems on these cars were on Sprint so they just had to be on the same network. I wonder if Verizon intentionally blocks this.
https://www.kaspersky.com/blog/blackhat-jeep-cherokee-hack-e...
What would be the obvious reasons? (I'm not being flippant here -- I'm genuinely interested in what arguments people have to not allow servers on that network)
High concentration of technically inept users with hardware that no longer receives security updates and has plenty of well known easily exploitable vulnerabilities. Which naturally is used to run banking apps and travels with users close to 24/7 while tracking their location.
From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use. The internet APs the carriers sell get deprioritized relative to phones when necessary and the fine print generally forbids hosting any services (in noticeably stronger language than the wired ISPs I've had).
> From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use
Isn't that already the case with limited plans?
For example, mine has 40 GBs and I'm pretty sure it counts both upload and download, because I generally consume very little, except for one week when I was on holiday with no other internet access and wanted to upload my pictures to my home server and didn't otherwise use the phone more than usual.
Facebook would start listening on port X and and then their embedded SDK in other websites or app would query that IP and port, get their unique id, and track users much better.
Sounds farfetched? https://www.theregister.com/2025/06/03/meta_pauses_android_t...
This is local to the device though. Nothing to do with the WAN. Would still work even on the "serverless" ipv6 network.
The most common use case for mobile data servers is probably pwned cheap/old phones forming DDoS swarms. Pure P2P over internet is very rare on mobile, no sense not blocking ingress from the perspective of ISPs.
However for that having the phone's IP not reachable has at best marginal benefits. The DDoS itself is an outgoing connection, and for command and control having the compromised phone periodically fetch instructions from a server is simpler to implement than the phone offering a port where it is reachable to receive instructions
I kind of doubt this, as the rapidly changing nature of mobile IP addresses would mean that a periodic outbound connection would still be necessary to keep the attack up-to-date on the compromised devices current IP address. At that point, you may as well have the compromised device periodically poll an attacker-controlled server for instructions rather than jump through a bunch of hoops by getting things to work over inbound connections.
[dead]
I think it should vary based on the type of service being provided. Truly mobile service, I think it can make sense to not allow servers. If its being sold as a home internet solution (a more fixed kind of plan), I think it should allow servers to at least some level of hosting services.
The main difference is there's usually limited airtime capacity for clients, especially highly mobile ones. A server could easily hog quite a bit of the airtime on the network serving traffic to people not even in the area, squeezing out the usefulness of the network for all the other highly mobile people in the area. This person moves around, pretty much doing the equivalent of swinging a wrecking ball to the network performance everywhere they go.
When its being sold as a fixed endpoint though, capacity plans can be more targeted to properly support this kind of client. They're staying put, so its easier to target that particular spot for more capacity.
The phone providers oversell bandwidth. They also limit the use of already purchased bandwidth when it gets legitimately used.
Similar to many industries, their business model is selling monthly usage, while simultaneously restricting the actual usage. They are not in the business of being an ISP for people running software on their phones.
In China you need a license to run a server.
Being allowed to serve data from your own device should be seen as a natural human right.
If the networks don't have capacity or something then we need networks that can support that.
The idea that all of that has to go in the Fediverse on a server or something is just gatekeeping.
Wait a few years as IPV6 becomes truly ubiquitous. This will become very obvious to everyone and standard. People must be allowed to communicate directly, even if they have a lot of clients.
The opinions are slightly similar to remote work. Telecommuting was an obvious next step for a long time, it just took a certain number of decades for society to realize it.
What about hotspotting? Do the client pc's get the same IPv6 address as the mobile phone?
[dead]
Mobile phones are also heavily sandboxed.
This is the first thing that as a Network Engineer I was taught - and every formal security class I've taken (typically from Cisco - they have awesome course) - repeats the same thing.
I believe the common knowledge is somewhat more nuanced than people would have you believe
I present to you two separate high-value targets whose IP address has leaked:
Target #1 has an additional level of security in that you need to figure out how to route to that IP address, and heck - who it even belongs to.Target #2 gives aways 90% of the game at attacking it (we even leak some device specific information, so you know precisely where it's weak points are)
Also - while IPv6 lacks NAT, it certainly has a very effective Prefix-translation mechanism which is the best of both worlds:
Here is a real world target:
You are going to have a tough time routing to it - but it can transparently access anything on the internet - either natively or through a Prefix-translation target should you wish to go that direction.For your example, shouldn't you either present two "private" IP addresses, in which case you'd replace the IPv6 address in your example with what is likely to be an autoconfigured link-local address (though any ULA address would be valid as well),
OR present the two IP addresses that the targets would be visible as from the outside, in which case you'd replace the IPv4 address with the "public" address that 192.168.0.1 NATs to, going outbound?
Then, the stated difference is much less stark: In the first case, you'd have a local IPv6 address that's about as useless as the local IPv4 address (except that it's much more likely to be unique, but you still wouldn't know how to reach it). In the second case, unless your target is behind some massive IPv4 NAT (carrier-grade NAT probably), you'd immediately know how to route to them as well.
But presenting a local IP for IPv4, and a global one for IPv6, strikes me as a bit unfair. It would be equally bogus to present the public IPv4 address and the autoconfigured link-local address for IPv6 and asking the same question.
I do concede that carrier-grade NAT shifts the outcome again here. But it comes with all the disadvantages that carrier-grade NAT comes with, i.e. the complete inability to receive any inbound connections without NAT piercing, and you could achieve the same by just doing carrier-grade NAT for IPv6 as well (only that I don't think we want that, just how we only want IPv4 CGNAT because we don't have many other options any more).
In these contexts - neither of the addresses was intended for internet consumption. A misconfigured firewall exposes you in the case of IPv6 routable addresses, and is less relevant in the case of IPv4; the ULA IPv6 address is roughly the same as an RFC 1918 address with it's lack of routing on the Internet.
The point I was (poorly) trying to make is that non-routability is sometimes an explicit design objective (See NERC-CIP guidance for whether you should route control traffic outside of substations), and that there is some consideration that should be made when deciding whether to use globally routable IPv6 addresses.
No, that's the whole point.
Imagine I've shared output of "ifconfig" on my machine, or "netstat" output, or logs for some network service which listed local addresses.
For IPv4, this will is totally fine and leaks minimal information. For IPv6, it'll be a global, routable address.
That's a pretty weird threat model. Like, yeah commands you run on your machine can expose information about that machine.
Only in IPv6 world... in IPv4, it's all safe
Nope, iproute can still show your Mac address. And a curl ipinfo.io can show your public v4 address.
Mac address is absolutely safe in IPv4 world - the only info it gives is the network card manufacturer.
And people don't usually share "curl ipinfo.io" output unless they plan to share their external IP (unlike "ifconfig" output, which is one of the first things you want to share for any sort of networking problems)
See the top comment in this thread:
Target #2 [IPv6] gives aways 90% of the game at attacking it (we even leak some device specific information, so you know precisely where it's weak points are)
You may not consider Mac address to he important, but the context of this conversation did bring it up. Of course they forgot the fact that most v6 addressing doesn't expose Mac addresses anymore.
Especially as if someone is able to capture ifconfig data, they can probably send a curl request to a malicious web server and expose the NAT IP as well.
Just because you can think of scenarios where the IPv4 setup doesn't make a different doesn't discount that there are scenarios where it does.
Someone being able to observer some state is a different model from someone being able to perform actions on the system and the former has many more realistic scenarios in addition to the ones of the latter.
People post their ifconfig data all the time, example: https://forums.linuxmint.com/viewtopic.php?t=402315
Or if you happened to curl ipinfo
Or if you had a script that did that and put the public v4 address in your taskbar.
> Or if you had a script that did that and put the public v4 address in your taskbar.
do people still do that? Dynamic DNS is offered by so many providers now...
I'm not sure I buy the "you get a leak of the address of a high value target you believe can be routed to over the internet in some fashion, but it's the internal address which leaked and you have no idea who could own said high value target either" story.
I agree if it's an actual concern then you can use NAT66 to hide the prefix, I just don't see how this achieves security when the only publicly accessible attack point is supposed to be the internet attached FW doing the translation of the public addresses in the first place.
Additionally, if that really is the leaked IPv6 address then it's formatted as a temporary one which would have expired. If you mean static services which were supposed to be inbound allowed then we're back at the "the attack point is however the internet edge exposes inbound in both cases, not the internal address".
NAT66 doesn't add much in the way of security here, because the external address is fully routable and maps 1:1 to the internal address. You are once again fully dependent on a correctly configured firewall.
The IPv6 address that I shared was, in fact, a static (and real) IPv6 address, belonging to a real device - with the possible exception of the last 3 bytes, was likely one I worked on frequently.
Put another way - to do an apples to apples comparison:
> NAT66 doesn't add much in the way of security here, because the external address is fully routable and maps 1:1 to the internal address. You are once again fully dependent on a correctly configured firewall.
When using the stateful firewall provided by Linux's packet filter, the IPv6 NAT66 "masquerade" works very similar to IPv4 NAT. 1:1 mapping is NOT required.
For example internal hosts are configured as follows:
inet6 fd00::200/64 scope global noprefixroute
ip -6 route add default via fd00::1
Edit: From my understanding the NAT66 is ambiguous and it may work as a stateful port-based translation similar to IPv4 NAT, whereas NPTv6 is a stateless prefix-only translation.
Hardest to attack:
fcab:cdef:1234:5678:9abc:def0:1234:5678
The whole point is that your devices on the inside of your network can't be routed to at all.
It's the same difficulty to attack in all 3 cases: hack the internet firewall, which the only point providing connectivity between both internal and external addresses regardless of what the address itself is.
You don't need to change the prefix to prevent an address from being routed to from the internet, but you do need a firewall if you want an address to be securely reachable from the internet. If you don't want an address to be reachable, what the address is whatsoever doesn't matter so long as you've implemented any possible way of making it unreachable.
Not true, 2001:1868:209:FFFD:0013:50FF:FE12:3456 provides some amount of geographic information about the target that the other addresses do not. No firewall is going to protect you from that. Of course that is only going to matter in the specific scenario where your internal IP is leaked but the attacker has not other way of getting your external IP.
Okay - I'll bite - Why is FC/7 harder to attack than FD/8?
It took me less than 1 second to access that 192.168.0.1 address! It wasn't that hard to find.
(;-)
Fast, too, isn't it? Must be on at least a 1Gbps connection.
Deeply ironic that Cisco would teach this, because it's the opposite of what they said when they introduced NAT.
Well - I can't say they have always said this - but at least for Circa 1998 CCNP onwards that's been their position. The instructors were very adamant - to the point that I'm recalling this 27+ years later.
This probably has more to do with network engineers (and CCNP instructors) not being security engineers (or even conversant with Cisco's security SBU).
[dead]
If the IP address was leaked, wouldn't it be the address of the unit doing the NAT translation instead of the standard-gateway?
In the case of IPv4 - you almost certainly would get the external IP address of the unit doing NAT translation. In the case of IPv6 - it's quite common (outside of the enterprise world) for the Native IPv6 address of the device to be routed directly onto the internet - desirable even.
In the case of a 'leaked" address - there are all sorts of ways in which internal details of an address can leak even when it's not in the DST/SRC envelope of the packet on the Internet.
NAT66 is evil but it is a necessary evil. There are certainly situations where using NAT66 is the best way.
Yup, by default a Linux based router won’t forward any traffic to a IPv6 host unless you explicitly have a program running which keeps on telling the kernel you want that.
I'm sorry, this is just an elaborate argument of obscurity-as-security. You're clinging to privacy as though it were security, in stark avoidance of Kerckhoffs's principle.
> You're clinging to privacy as though it were security, in stark avoidance of Kerckhoffs's principle.
TIL that IPv6 is a cryptosystem
You can use Shannon's maxim instead if you're going to be deliberately obtuse. The point is true for any system intended to be secure, and a network is such a system, as is the security software such as the claimed NAT software.
Or do you really want to argue that Linux Netfilter/nftables or BSD pf being open source is a security problem?
It's scary how much of this thread of supposed hackers comes from people who clearly don't understand the difference between a NAT and a firewall.
NAT is not for security, it does not provide security. It is often bundled with a firewall. The firewall provides security. Firewall=\=NAT
It's sad how much of this thread of supposed hackers comes from people who are simply parroting this dogma because it has been drilled into them. People were even preaching this before IPv6 privacy extensions came into use, either downplaying the privacy issues or outright telling people they were bad for wanting privacy because IPv6 is more important.
I understand the difference between NAT and firewall perfectly well. I have deployed and configured both for many years. The strawman of "NAT without firewall" is pretty much irrelevant, because that's not what people run IRL.
Firewalls are policy-based security, NAT is namespacing. In other fields, we consider namespacing an important security mechanism. If an attacker can't even name a resource they're not allowed to access, that's quite a strong security property. And of course, anyone can spoof IP and try to send traffic to 192.168.0.6 or whatever. But if you're anywhere in the world other than right inside my ISP's access network, you can't actually get the internet to route this to my local 192.68.0.6. On the other hand, an IPv6 firewall is one misconfigured rule away from giving anybody on the planet access.
Yeah, I think it is a bit more subtle of an issue than this flamewar always descends into.
There's people upthread arguing that every cellphone in the country is on IPv6 and nobody worries about it, but I'm certain there are thousands of people getting paid salaries to worry about that for you.
Meanwhile, the problem is about the level of trust in the consumer grade router sitting on my desk over there. With IPv4 NAT it is more likely that the router will break in such a way that I won't be able to access the internet. Having NAT break in such a way that it accidentally port forwards all incoming connection attempts to my laptop sitting behind it is not a likely bug or failure mode. If it does happen, it would likely only happen to a single machine sitting behind it.
OTOH, if my laptop and every other machine on my local subnet has a public IPv6 address on it, then I'm trusting that consumer grade router to never break in such a way that the firewall default allows all for some reason--opening up every single machine on my local subnet and every single listening port. A default deny flipping to a default allow is absolutely the kind of security bug that really happens and would keep me awake at night. And even if I don't go messing around with it and screw it up myself, there's always the possibility that a software bug in a firmware upgrade causes the problem.
I'd like to know what the solution to this is, other than blind trust in the router/firewall manufacturer or setting up your own external monitoring (and testing that monitoring periodically).
Instead of just screaming about how "NAT ISN'T SECURITY" over and over, I'd like someone to just explain how to mitigate the security concerns of firewall rulesets--when so very many of us have seen firewall rulesets be misconfigured by "professionals" at our $DAYJOBs. Just telling me that every IPv6 router should have default deny rules and nobody would be that incompetent to sell a router that wouldn't be that insecure doesn't give me warm fuzzies.
I don't necessarily trust NAT more, but a random port forward rule for all ports appearing against a given target host behind it is going to be a much more unusual kind of bug than just having a default firewall rule flipped to allow.
You could set up a monitoring solution that alerts you if one of your devices is suddenly reachable from the internet via IPv6. It will probably never fire an alert but in your case might help you sleep better. IPv6 privacy extensions could help you too.
In practice I don't think it's really an issue. The IPv6 firewall will probably not break in a way that makes your device reachable from the internet. Even if it would, someone would have to know the IPv6 address of the device they want to target - which means that you have to connect to a system that they have control of first, otherwise it's unlikely they'll ever get it. Lastly, you'd have to run some kind of software on that device that has a vulnerability which can be exploited via network. Combine all that and it gets so unlikely that you'll get hacked this way that it's not worth worrying about.
Thank you. This is the first time that someone admits here that NAT actually adds some security. IPv4 will never go away less that an important share because of it's simplicity and NAT-level security it offers to millions of professionals and amateurs that tinker with their routers.
NAT introduces complexity, not simplicity.
Besides, NAT isn't a security feature.
Secure and reliable IPv6 deployment has _more_ complexity than IPv4.
SLAAC is more complex than IPv4 w/ NAT w/ DHCPv4? Serious?
Assign a /56, firewall in place already dropping anything not explicitly allowed, done.
> SLAAC is more complex than IPv4 w/ NAT w/ DHCPv4? Serious?
Yes? Has this ever been in question?
Stateful DHCP provides a _reliable_ way to configure clients, while SLAAC is anything but. It's also insufficient in itself if you want to configure things like NTP servers.
But that's not the main issue. The main issue is that with SLAAC you are supposed to hand out real routable addresses. That are _not_ controlled by you, so the end devices need to be able to handle prefix withdrawals and deprecations. This can lead to your printer not working if your ISP connection goes down and it has no more active IPv6 prefixes.
So you also need a stable ULA. But even that is not a guarantee because source IP selection rules are, shall we say, not the best.
But wait, there's more! You can trivially load-balance/failover NAT-ed IPv4 network over two WAN connections. Now try to do that with IPv6. Go on. I'll wait.
This is 100% correct, something the (dim) author of the article can't seem to understand.
Except in the real world everyone is also running UPnP, so NAT is also one misconfiguration away from exposing something publicly. In the real world your ISP might enable IPv6 one day and suddenly you do have a public address. Relying on NAT is a bad idea because it's less explicit, a firewall is saying you only want to allow these things through, of course nothing is perfect, you can mess up, but NAT is just less clear, the expectation is not "nothing behind NAT should ever be exposed", it's "we don't have enough addresses and need to share".
UPnP is not tied to NAT, where do you have this from? UPnP is used to request direct connections, a firewall can implement UPnP just as well as a NAT.
UPnP won't expose my SMB to the world on its own. For that you'd need an attacker already inside the NAT. So already on that side of the hatchway.
[dead]
It's not "relying on NAT" to have it as a layer in the swiss cheese. Relying on any one thing is a bad strategy.
Sure, and that's fine, but relying on it isn't, and it isn't a reason not to use IPv6 (if you want namespacing, there are tools for that outside hiding behind a single IPv4). Hence the advice is not to rely on NAT.
This is people talking past each other, and to be fair, saying "everyone" in my post made it unclear, I was being glib in response to "because that's not what people run IRL", when evidently people do, I've seen it happen.
No, not everyone is running UPnP. Maybe on most home networks, but that’s not the audience that even knows or cares about NAT.
I think this is where the disconnect is: the home users are precisely the ones being talked about, because they are the ones most likely to be treating NAT like it is a security system for their devices in the real world.
I've literally seen someone's ISP turn on IPv6, and then have their long-running VNC service compromised because they were just relying on NAT to hide their services.
> Except in the real world everyone
...and goes on to ignore enterprise businesses, which consume most of the v4 space and are among the biggest resisters of v6.
>Except in the real world everyone is also running UPnP
Definitely not. I've been disabling that for years.
Upnp on cgnat machines? Lol.
> It's sad how much of this thread of supposed hackers comes from people who are simply parroting this dogma because it has been drilled into them.
It's only been drilled into people because it's true:
* https://blog.ipspace.net/2011/12/is-nat-security-feature/
> If an attacker can't even name a resource they're not allowed to access, that's quite a strong security property.
This is entirely incorrect. An attacker can still name a resource, it only has to guess the right port number that is mapped to that resource.
That's how NAT fundamentally works after all, it allows you to use the additional 16-bits of the port number to extend the IP address space. Any blocking of incoming traffic on a port already mapped to a local address is a firewall rule.
The reason that it offers protection is because attackers aren't going to try every single port. Compared to that IPv6 will offer more protection as an attacker would have to guess the right address in a 64-bit namespace rather than just a 16-bit one.
That's absolutely not true, because forwarding rules don't exist by default. You can try all ports and will get no answer.
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)
In an enterprise network, it's very, very unlikely that an edge router is doing any firewalling. They can do it, but it's not only cumbersome to do it there, but also a massive resource drain.
Often they do basic stateless packet filtering, but definitely nothing akin to stateful, connection-oriented firewalling. It's important to make the distinction, because filtering in this case is completely uni-directional and if you want bi-directional equivalence you have to write an inverse rule for it. Filtering polices are applied per interface, so generally you apply them on the outside only.
Think of it as sort of a reverse of an inbound Internet policy - you write all the drop stuff first (e.g. drop any any eq snmp) and the last rule is a permit ip any any. Next hop is your firewall which does the rest.
For site-tos-site b2b connections, we performed NAT (of the untrusted network space) on the border/edge b2b router, and then the traffic was immediately routed to the firewall. So in this instance, NAT was happening on the router for the customer IP range, and on the firewall for our enterprise IP range.
As a convenience to our customers/partners we always presented ourselves as one of our public IP blocks that wasn't Internet-routed. This prevented them from having any overlapping IP space.
Otherwise, NAT is simply a question of configuring it. And at least in the cisco IOS world (I'm a dinosaur) the two features (NAT vs. firewall) are utterly independent.
https://community.cisco.com/legacyfs/online/legacy/0/8/0/600... https://www.cisco.com/c/en/us/support/docs/ip/network-addres...
> but definitely nothing akin to stateful, connection-oriented firewalling
This is where my confusion comes in, I think.
Surely the variety of NAT that significantly improves the IPv4 address starvation problem (IP Masq by its various names) requires a connection oriented approach to be effective? Maybe not as far as more advanced conntrack rules (trying to get connect-back based protocols to work) but even just a basic stream-over-one port protocol needs basic connection tracking so return packets get back to the right host? If you have enough resource to do that then you have more than enough resource to do the basic “block all external apart from these configured addr+port->addr+port combinations” for IPv6 that is all the protection NAT affords you by accident for IPv4.
> Surely the variety of NAT that significantly improves the IPv4 address starvation problem (IP Masq by its various names) requires a connection oriented approach to be effective?
Actually it doesn't. Well, not really.
With NAT you're generally talking about either 1:1 or 1:many (Masquerading).
In all cases the device doing the NAT maintains a table which is referenced for every matching packet that arrives or leaves.
In 1:1 NAT, the IP in the packet header (Layer-3) is simply rewritten from one address to the other whenever a packet matching both addresses in the NAT table leaves or arrives.
In 1:many NAT, the source port is randomized because you can run into collisions when multiple clients are connecting to the same server:port. So in that case the NAT table contains IP addresses as well as ports. When a return packet arrives, it checks the NAT table and rewrites both the L3 and L4 (port) info before passing it along.
Often times firewalls will randomize the source port when doing 1:1 NAT as a security measure, but after all these years I don't really remember why that's helpful. :-\
But that's really the extent of tracking connections with NAT.
Now when you're talking about firewalling, there's a lot more to track, such as connection start/stop/timeouts/lifetimes, total throughput, TCP state (handshakes, sequence numbers, etc.), closing open sessions when seeing things like TCP RSTs or FINs or ICMP unreachables. The amount of data and CPU is dramatically higher, and tailored to the software doing the firewalling. I believe in many cases simple L3/L4 rewrites can happen in hardware.
I haven't talked about any of this in several years so I hope I'm making sense.
> 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.
If you don't initiate a corresponding outbound connection first then any attempt at an inbound connection will be dropped (unless you have a DMZ configured ofc). The router literally can't forward the traffic because it doesn't know where it should go.
No, the router doesn't forward it because it doesn't get there in the first place. Your 192.168.1.0/24 private network is not going to be routed across the internet.
It might be dropped by a firewall, but not by NAT.
IP packets have a "destination IP" field in the header. The router knows where to forward packets because it reads that IP out of the header.
Sure, but the Internet will not route packets going to RFC1918 addresses. So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped. And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused.
This is all behavior that happens even with no firewall whatsoever.
So? How is any of that relevant?
Because this is exactly what the GP was claiming, and you denied: even without a firewall, packets that don't correspond to an open connection will get dropped by a NAT, even without a firewall. Sure, maybe "dropped" is wrong, as the NAT box will probably instead send a RST packet, but this is almost entirely irrelevant.
Right, we were talking about NAT. So how is any of that non-NAT-related stuff relevant?
> Sure, but the Internet will not route packets going to RFC1918 addresses
This is about RFC1918, not NAT.
> So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped.
This is about reverse path filtering, not NAT.
> And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused.
And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.
> And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.
Fine. Packets that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection, an explicit port forwarding rule, OR the port of a service on the router itself listening on the WAN IP will also get refused.
The point is that any LAN box sitting behind the NAT will not get that packet, same as if the router had a stateful firewall running.
And sure, this is not purely a property of the NAT itself, it's a combination of the Internet not routing private IP addresses, reverse path filtering, and NAT. That still doesn't need any firewall to achieve this.
Well no, it's purely a property of the fact that the packet is addressed to the router.
If the packet is addressed to a machine on the LAN, neither RPF or NAT will protect you from it. "The Internet won't route to private IPs" only protects you if you have private IPs on the LAN, and even then it only protects you from people who can't get access to the network on your WAN interface.
Any way you dice it, NAT isn't providing any protection.
Because that is the most common NAT configuration for 99.99% of residential users. Anything else is academic discussion.
And in this common configuration, NAT does nothing to prevent inbound connections.
Do you admit using RFC-1918 + NAT provides some security even with no firewall for the majority of residential users?
Neither of them prevent inbound connections, on their own or together.
I don't really think that "inbound connections work fine and you're basically just praying that the people that can do them simply won't" counts as being secure, but I'll admit that using RFC1918 does limit the set of people that can do them. If you made that your argument, you'd have more of a point than an argument based around NAT.
Okay! I didn't say it was absolutely secure. A firewall is obviously preferred. I'm just saying it's shades of gray... non-routeable addresses provides a level of security.
> 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.
So, assuming the router doesn't have any server running, the connection will be reset, thus protecting all of the machines behind the router from any incoming connection, almost exactly like a firewall (sure, a firewall might just drop the packet instead of responding with a RST). So, in other words, NAT alone can act like a security perimeter, even with no firewall present.
How does the router rejecting a connection to the router protect the machines behind the router? That doesn't make any sense.
Because no one on the Internet can reach my 192.168.0.7 machine if the NAT router doesn't translate the packet. And the NAT router won't send a packet that arrives with its public IP as dstIP to any machine behind it, unless the port its ports correspond to an open connection, or to an explicitly forwarded port.
You could turn NAT off completely and still no-one on the Internet could reach your 192.168.0.7. There's no security perimeter coming from NAT here.
> And the NAT router won't send a packet that arrives with its public IP as dstIP to any machine behind it
Yes, of course. The problem is when a packet arrives with the IP of a LAN machine.
>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.
I've explained before, in many threads, that pure consumer NAT, without a firewall, has exactly the same behavior as a consumer stateful firewall, except for two cases :
1. The ISP is malicious/compromised, and sends packets with RFC1918 addresses on the router's WAN port.
2. The router itself has admin services that are listening on public IPs (eg HTTP server listening on 0.0.0.0 instead of 192.168.0.1), so it itself could be compromised from outside the ISP network.
Except for these two points, there is no difference between the security characteristics of a consumer NAT and a consumer firewall:
1. LAN machines can't be reached over the internet other than through the NAT, since a packet addressed to 192.168.0.7 from Google will not be routed by any ISP.
2. When a packet arrives to the NAT with a destination IP set to the NAT public IP, the packet will not be delivered to any box on the LAN unless (a) its ports match an active connection from a LAN box, or (b) its destination port matches an explicit port forward rule an admin added.
Case (a) above is exactly what a stateful firewall with a default deny rule does. Case (b) is also exactly the same, as if you explicitly open a port in this type of consumer firewall, it will allow any packet matching that port.
Now, I wouldn't disable my firewall, because I don't trust that my consumer router is itself well enough secured, and I don't necessarily trust my ISP's network either. But this doesn't mean that my laptop is exactly as secure if it were to sit behind this router with no firewall as it would be if I disabled both firewall and NAT entirely and gave my laptop a publicly routable IPv4.
This goes against Hyrum's law. NAT provides the behavior 99.9% of users want, usually by default, out of the box. True firewalls can do the same thing, but not necessarily by default, the firewall might not even by on by default, and there's more room for misconfiguration. IPv6 is a security regression for most people, regardless of its architectural merits or semantics of what's a firewall.
I wouldn’t put the number so high. I’ve on several occasions seen not very technical people unnecessarily burn money on VPSes or dedicated hosting providers because they couldn’t expose a game server for a evening session with their friends with the spare capacity on their gaming machine, because of their ISPs NAT setup. 90% would be fairer. However we still shouldn’t be sacrificing securing agency of individual consumers for securing smoother revenue for corporations.
Dynamic DNS and port forwarding work fine if you really do want to run a server from your residential IPv4 connection. I've done it many times.
Until you run into CGNAT...
Sure, but American residential ISPs don't run with that, probably for this reason.
I brought up CGNAT because my American ISP does use CGNAT. We are now paying an extra monthly fee for a static IP, which I believe is the only option they have for getting a public IP (i.e. no intermediate fee amount for a public non-static IP).
It might be more fair to say that most American residential ISPs don't have to do that because they have access to giant legacy IPv4 allocations. Comcast alone has 65 million IPv4 addresses, for example (including a /8, /9, and /10 and several /11s).
I think they could make more money using CGNAT and leasing those IPs out to data centers. Also another comment in this thread mentions that their cellular plan sold as a residential internet connection doesn't use CGNAT, but their phone plan from the same company does..
Maybe! CGNAT isn't free, of course, you need pretty beefy machines to handle ISP numbers of clients. So, is the capex for the machines, engineering time to set them up, and opex for keeping them running more or less than they'd make back from leasing their net blocks? Hard to say.
NAT implementations get broken all the time (NAT slipstreaming attacks). If a manufacturer is incompetent enough not to have a firewall on by default, they are probably also shipping a vulnerable NAT.
NAT slipstreaming depends on confusing fragmentation assemblers and application aware parsers. Those exist in firewalls as well. It’s not NAT specific.
It’s still conflating things. You can have a stateless NAT: device x.x.x.y will get outbound source ports rewritten to (orignal port) << 8 + y.
This is a (dumb) NAT but has no state so it cannot possibly implement a default deny or any firewall adjacent features.
And that kind of NAT effectively doesn't exist in practice, so that's quite beside the point. Such a NAT doesn't scale to more than 24 devices behind it.
>> You can have a stateless NAT: device x.x.x.y will get outbound source ports rewritten to (orignal port) << 8 + y.
> And that kind of NAT effectively doesn't exist in practice […]
Anyone using IPv6 ULA and NPT would disagree.
* https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Tr...
See my reply to your sibling commenter. My comment was not about NAT in general, i.e. I was not denying the very real existence of stateless NAT. Rather, I was disputing the usefulness of the NAPT solution proposed above as a solution to public IPv4 address exhaustion.
> proposed above as a solution to public IPv4 address exhaustion.
It was not proposed as a solution (although, it would work). I'm pointing out that in networking many names are conflated/used generally against their specific definition. NAT/Firewall; Router/Access Point/Gateway; etc.
No, it very much does. If you want to join two network segments such that on one side all devices are on 10.1.X.X and the other all devices are 10.2.X.X, you'd use a mapping between 10.1.a.b and 10.2.a.b
See https://en.wikipedia.org/wiki/Network_address_translation#Me...
The general context here is about NATting to the public internet at large, not between particular segments. And the parent of my comment was talking specifically about NAPT, which is different from the non-port-based NAT that you're talking about.
For "most people" the router/gateway has a firewall by default. And there isn't any reason why you can't have a NAT for ipv6, it just isn't necessary.
You can still have firewalls on IPv6.....
This is a terrible argument. First, NAT doesn't provide the security behavior users want. The firewall on their router is doing that, not the address translation. Second, that firewall is on by default, blocking inbound traffic by default, so why on earth would you conjecture that router manufacturers will suddenly stop doing that if NAT isn't on by default? Third, it's not remotely likely that a user will misconfigure their firewall to not secure them any more. Non-technical users won't even try to get in there, and technical users will know better because it's extremely easy to set up the basics of a default deny config. There is no security regression here, just bad arguments.
The firewall on your typical IPv4 router does basically nothing. It just drops all packets that aren’t a response to an active NAT session.
If the firewall somehow didn’t exist (not really possible, because NAT and the firewall are implemented by the same code) incoming packets wouldn’t be dropped, but they wouldn’t make it through to any of the NATed machines. From the prospective any machine behind the router, nothing changes, they get the same level of protection they always got.
So for those machines, the NAT is inherently acting as a firewall.
The only difference is the incoming packets would reach the router itself (which really shouldn’t have any ports open on the external IP) reach a closed port, and the kernel responds with a NAK. Sure, dropping is slightly more secure, but bouncing off a closed port really isn’t that problematic.
NAT gateways that utilize connection tracking are effectively stateful firewalls. Whether a separate set of ‘firewall’ rules does much good because most SNAT implementations by necessity duplicate this functionality is a bit ignorant, IMO.
Meanwhile, an IPv6 network behind your average Linux-based home router is 2-3 nftables rules to lock down in a similar fashion.
It's also trivial to roll your own version of dropbox. With IPv6 it's possible to fail to configure those nftables rules. The firewall could be turned off.
In theory you could turn off IPv4 NAT as well but in practice most ISPs will only give you a single address. That makes it functionally impossible to misconfigure. I inadvertently plugged the WAN cable directly into my LAN one time and my ISP's DHCP server promptly banned my ONT entirely.
> In theory you could turn off IPv4 NAT as well but in practice most ISPs will only give you a single address
So, I randomly discovered the other day that my ISP has given me a full /28.
But I have no idea how to actually configure my router to forward those extra IP addresses inside my network. In practice, modern routers just aren't expecting to handle this, there is no easy "turn of NAT" button.
It's possible (at least on my EdgeRouterX), but I have to configure all the routing manually, and there doesn't seem to be much documentation.
You should be able to disable the firewall from the GUI or CLI for Ubiquiti routers. If you don't want to deal with configuring static IPs for each individual device, you can keep DHCP enabled in the router but set the /28 as your lease pool.
> So, I randomly discovered the other day that my ISP has given me a full /28.
Where is this? Here new ISP customers don't even get a single IPv4 unless you beg for it.
Not even CGNAT?
In the US many large companies (not just ISPs) still have fairly large historic IPv4 allocations. Thus most residential ISPs will hand you a single publicly routable IPv4 regardless of if you're using IPv6 or not.
We'll probably still be writing paper checks, using magnetic stripe credit cards, and routing IPv4 well past 2050 if things go how they usually do.
Out of curiosity how did you discover this?
Went to double check what my static IP address was, and noticed the router was displaying it as 198.51.100.48/28 (not my real IP).
I don't think the router used to show subnets like that, but it recently got a major firmware update... Or maybe I just never noticed, I've had that static IP allocation for over 5 years. My ISP gave it to me for free after I complained about their CGNAT being broken for like the 3th time.
Guess they decided it was cheaper to just gave me a free static IPv4 address rather than actually looking at the Wireshark logs I had proving their CGNAT was doing weird things again.
Not sure if they gave me a full /28 by mistake, or as some kind of apology. Guess they have plenty of IPs now thanks to CGNAT.
More like even if they looked at the logs they aren't about to replace an expensive box on the critical path when it's working well enough for 99% of their customers.
I once had my ISP respond to a technical problem on their end by sending out a tech. The service rep wasn't capable of diagnosing and refused to escalate to a network person. The tech that came out blamed the on premise equipment (without bothering to diagnose) and started blindly swapping it out. Only after that didn't fix the issue did he finally look into the network side of things. The entire thing was fairly absurd but I guess it must work out for them on average.
> With IPv6 it's possible to fail to configure those nftables rules. The firewall could be turned off.
So what? It's not like you get SNAT without a couple netfilter rules either.
This argument doesn't pass muster, sorry. Consumer and SOHO gear should come with a safe configuration out of the box, it's not rocket science.
Did you even read the second paragraph of the (rather short) comment you're replying to? In most residential scenarios you literally can't turn off NAT and still have things work. Either you are running NAT or you are not connected. Meanwhile the same ISP is (typically) happy to hand out unlimited globally routable IPv6 addresses to you.
I agree though, being able to depend on a safe default deny configuration would more or less make switching a drop in replacement. That would be fantastic, and maybe things have improved to that level, but then again history has a tendency to repeat itself. Most stuff related to computing isn't exactly known for a good security track record at this point.
But that's getting rather off topic. The dispute was about whether or not NAT of IPv4 is of reasonable benefit to end user security in practice, not about whether or not typical IPv6 equipment provides a suitable alternative.
> But that's getting rather off topic. The dispute was about whether or not NAT of IPv4 is of reasonable benefit to end user security in practice, not about whether or not typical IPv6 equipment provides a suitable alternative.
And, my argument, is that the only substantial difference is the action of a netfilter rule being MASQUERADE instead of ALLOW.
This is what literally everyone here, including yourself, continues to miss. Dynamic source NAT is literally a set of stateful firewall rules that have an action to modify src_ip and src_port in a packet header, and add the mapping to a connecting tracking table so that return packets can be identified and then mapped on the way back.
There's no need to do address and port translation with IPv6, so the only difference to secure an IPv6 network is your masquerade rule turns into "accept established, related". That's it, that's the magic! There's no magical extra security from "NAT" - in fact, there are ways to implement SNAT that do not properly validate that traffic is coming from an established connection; which, ironically, we routinely rely on to make things like STUN/TURN work!
> Dynamic source NAT is literally a set of stateful firewall rules that have an action to modify src_ip and src_port in a packet header, and add the mapping to a connecting tracking table so that return packets can be identified and then mapped on the way back.
Yes, and that _provides security_. Thus NAT provides security. You can say "well really that's a stateful firewall providing security because that's how you implement NAT" and you would be technically correct but rather missing the point that turning NAT on has provided the user with security benefits thus being forced to turn it on is preventing a less secure configuration. Thus in common parlance, IPv4 is more secure because of NAT.
I will acknowledge that NAT is not the only player here. In a world that wasn't suffering from address exhaustion ISPs wouldn't have any particular reason to force NAT on their customers thus there would be nothing stopping you from turning it off. In that scenario consumer hardware could well ship with less secure defaults (ie NAT disabled, stateful firewall disabled). So I suppose it would not be unreasonable to observe that really it is usage of IPv4 that is providing (or rather forcing) the security here due to address exhaustion. But at the end of the day the mechanism providing that security is NAT thus being forced to use NAT is increasing security.
Suppose there were vehicles that handled buckling your seatbelt for you and those that were manual (as they are today). Someone says "auto seatbelts improve safety" and someone else objects "actually it's wearing the seatbelt that improves safety, both auto and manual are themselves equivalent". That's technically correct but (as technicalities tend to go) entirely misses the point. Owning a car with an auto seatbelt means you will be forced to wear your seatbelt at all times thus you will statistically be safer because for whatever reason the people in this analogy are pretty bad about bothering to put on their seatbelts when left to their own devices.
> in fact, there are ways to implement SNAT that do not properly validate that traffic is coming from an established connection; which, ironically, we routinely rely on to make things like STUN/TURN work!
There are ways to bypass the physical lock on my front door. Nonetheless I believe locking my deadbolt increases my physical security at least somewhat, even if not by as much as I'd like to imagine it does.
The difference is that with IPv4 you know that you have that security because there is no other way for the system to work while with the IPv6 router you need to be a network expert to make that conclusion.
Except, you don't.
Assume eth0 is WAN, eth1 is LAN
Look at this nftables setup for a standard IPv4 masquerade setup
Note, we have explicit rules in the forward chain that only forward packets that either:* Were sent to the LAN-side interface, meaning traffic from within our network that wants to go somewhere else
* Are part of an established packet flow that is tracked, that means return packets from the internet in this simple setup
Everything else is dropped. Without this rule, if I was on the same physical network segment as the WAN interface of your router, I could simply send packets to it destined to hosts on your internal network, and they would happily be forwarded on to it!
NAT itself is not providing the security here. Yes, the attack surface here is limited, because I need to be able to address this box at layer 2 (just ignore ARP, send the TCP packet with the internal dst_ip address I want addressed to the ethernet MAC of your router), but if I compromised routers from other customers on your ISP I could start fishing around quite easily.
Now, what's it look like to secure IPv6, as well?
Note, there's only three new rules added here, the other changes are just so we can use a dual-stack table so there's no duplication of the shared rules in separate ip and ip6 tables.* 1 & 2: We allow ICMPv6 traffic in the forward and input chains. This is technically more permissive than needs to be, we could block echo-request traffic coming from outside our network if desired. destination-unreachable, packet-too-big, and time-exceeded are mandatory for IPv6 to work correctly.
* 3: Since we don't need NAT, we just add a rule to the forward chain that allows access to our web server (2602:dead:beef::1) on port 80 and 443 regardless of what interface the traffic came in on.
None of this requires being a "network expert", the only functional difference in an actually secure IPv4 SNAT configuration and a secure IPv6 firewall is...not needing a masquerade rule to handle SNAT, and you add traffic you want to let in to forwarding rules instead of DNAT rules.
Consumers would never need to see the guts like this. This is basic shit that modern consumer routers should do for you, so all you need to think about is what you want to expose (if anything) to the public internet.
Instead of all my devices being behind one IP and using an internal IP subnet, now each device has a globally routable ip address that will be used... Cool great opsec.
>This is a terrible argument. First, NAT doesn't provide the security behavior users want.
Try breaking into my machine. Login:pass are administrator:pa$$w0rd, external ip 58.19.1.129, internal ip is 192.168.1.124, the system is Windows xp, and firewall is turned off on both the computer and the box the ISP gave me.
Sure, okay. You're using RFC1918 on the internal network, so I'll need to connect to your router's WAN interface to do it, but after that it's just a matter of doing `ip route add 192.168.1.0/24 via 58.19.1.129` and then connecting to whatever I want.
How do you want to get me onto your WAN interface? Unless you happen to live near me it'd probably be easiest if you give me a tunnel. Alternately, if you change the internal network to a properly-routed non-RFC1918 range, I can demonstrate this over the Internet too.
I offered to do this once before, and the person I was talking to replied with "so, you're refusing to do it then" and blocked me. So just for the avoidance of doubt: I'm offering to do this, but if you're going to provide the test environment, you're responsible for making sure I can actually reach the test environment. Otherwise you aren't going to learn anything about NAT.
Right, and in a similar situation, if the internal device was given a routable ipv6 address by the ISP's cable modem, you could directly access that device.
This isn't a hypothetical. There are ISPs who do this out of the box. I plugged a linux box into my ISP's cable modem/router in Amsterdam and immediately noticed my ssh port was getting hammered by port scanners. This isn't what most customers, especially those who aren't technically sophisticated, expect.
I could do it if it was using a routable v4 address too, and I can do it with either RFC1918 or ULA as well (which are both routable, just not over the Internet) if I can get close enough to send the relevant packets. NAT provides no protection against any of these.
You don't normally see many SSH brute force attempts on v6, let alone getting hammered by them. I do see some, but it's mostly to obvious addresses like <prefix>::2, ::3 etc which I don't use, or to IPs you can scrape from TLS cert logs. If you set an ssh server up on an IP that you don't publicize, finding it is hard.
>How do you want to get me onto your WAN interface?
I've already given you _all_ information you could have realistically squeezed from me. The only thing left for you is to prove that NAT is not a security measure and break into my machine, given that you already have both login and pass.
If you had exactly those parameters with ipv6, you would have already broken in.
And like I said, I can do that if you get me into a place where I can demonstrate it.
If you want me to demonstrate that the lock on your safe isn't doing anything, you have to let me into the room where the safe is. Otherwise you won't learn anything about the lock on the safe.
When we say "NAT" we are specifically talking about stateful one-to-many NAT implementations as found in consumer IPv4 hardware. Such a NAT is largely isomorphic to a firewall with default-deny semantics for incoming connections and default-allow semantics for outgoing connections.
There are other possible NAT implementations that are much less like a firewall, but saying that a NAT does not provide security is a misunderstanding of the terms as they are used.
Not you specifically, but others in other threads have pointet to UPnP as proof that NATs don't provide security. If the existence of UPnP means that NATs don't provide security, then the existence of PCP means that Firewalls also don't provide security.
NAT-PMP, UPnP, PCP, et. all primarily exist because consumer networks that have to share a public IP face more issues than simply opening a port up to the internet. Destination port conflicts, port remapping, discovery of your public IP, are huge fucking headaches that these protocols also assist with.
Given most consumer routers these days can be configured with a mobile app, I could easily foresee a saner alternative where devices could simply ask the gateway if they could open up a port and have a notification sent to a mobile app to allow it.
But, that said, given how many devices are mobile these days I think the benefit of endpoint firewalls shouldn’t be underplayed either.
It's not isomorphic to a firewall, because it doesn't have default-deny semantics for incoming connections.
Think about it for a second. These NAT implementations change the apparent source IP of your outbound connections. How does that block inbound connections? Changing the IP isn't blocking, and outbound connections are the wrong ones.
If a connection comes into your router with a dest IP set to one of your LAN machines, no amount of changing the IPs on your outbound connections will block it.
You literally can't access the internal devices with the NAT implementation on most consumer level router/access points except for packets addressed to the port mapped to an already open connection originating from the inside. This is almost guaranteed to be a random high port. There's no way to access any other port on an internal ip address.
That's equivalent to default-deny.
I think either you're just trying to "well-actually" us or you're confused.
I'm not. You literally can do this, provided there's no firewall. All you need to do is send the router a packet that's already addressed to a LAN machine, and in it goes. "NAT won't translate the packet" doesn't matter if the address is already set to an IP from the LAN.
Most consumer-level routers do have a firewall to prevent it from happening, and if they don't then people describe that router as being "grossly misconfigured" or as having a security vulnerability and similar things, so in practice it'll be blocked. But that's my point: they need the firewall to do the job precisely because NAT doesn't do it.
I think understand what GP is saying; if you manage to get a packet to the internet port of the NAT router with a destination IP of e.g. 192.168.0.123, and the NAT router is running a generic IPv4 routing stack, it will dutifully route it to the internal network.
This can be done by compromising another host on the same link. It can also be done if anything on the same link (including the router itself) is running an improperly configured tunneling setup that lets the attacker send e.g. an IP-in-IP packet that gets unwrapped. The NAT has made it much harder to get a packet establishing an inbound connection to the router, but doesn't actually prevent the establishment of a connection should such a packet get there.
Compare to a default-deny firewall with public addresses on the LAN. Any inbound connections will be dropped, by definition; the lack of NAT makes it trivial to get a packet to the firewall itself, but once it's there, it won't get through.
I said "largely isomorphic" Note:
1. How did a packet with a RFC1918 address reach router; it would require an attacker able to generate packets (or get something to e.g. unwrap an IP-in-IP packet) on the same link, since the router isn't going to ARP any of those addresses. Limiting inbound connections to originate on the same link does provide some measure of security.
2. Will the router even do anything with a packet coming in on the inbound port that doesn't target the public IP? This is implementation dependent.
Of course symmetric or even carrier grade NAT is not a firewall, but it's so silly to ignore real world implications thereof in an IPv4 only deployment scenario. Firewalls aren't foolproof and in real life you average NAT is more likely to be closer to that.
It's scary how much of this thread comes from people who can't imagine a use for keeping internal traffic internal. in ipv4, if my laptop tries to use a printer with a public ipv4 address, that raises alarms. in ipv6, if my laptop tries to use a printer with an ipv6 address...
its not about the firewall. there's just a lot of extra attack vectors without a nat.
I agree with the majority of your point, but hopefully your printer hasn't been assigned IPv6 IPs that are global in nature and is instead limited to site-local.
For anyone who is reading this but hasn't use IPv6, IPv6 addresses are a large flat 128-bit contiguous address space, but they are not universally routable. The prefix of any specific address determines what group of other IPs can get to it.
We often think of a computer as having an IP address, but with IPv6, computers will have several addresses, all with different prefixes to handle different types of traffic.
This site does a decent job of explaining - https://networklessons.com/ipv6/ipv6-address-types
If you plug your printer into your home network, and if the local DHCP server is configured to hand out globally routable addresses from your ISP provided /64, then your printer will also be globally routable (as well as your "smart" fridge, "smart" TV, "smart" thermostat, etc). In my personal experience this is the default situation with consumer ISP IPv6 setups.
This difference in theory versus practice is precisely why we see people objecting that IPv4 is more secure as far as default configurations go when it comes to home use.
That said, I expect (hope?) that all ISP gear should default to enabling a stateful firewall. Hopefully there's no difference between the default security of an IPv4 and an IPv6 setup in practice. But given the history I'm not entirely optimistic.
Note that DHCPv6 is really uncommon for IPv6, especially on consumer routers - so uncommon that Android doesn't even support it. But your point stands, even more so, with SLAAC.
>This difference in theory versus practice is precisely why we see people objecting that IPv4 is more secure as far as default configurations go when it comes to home use.
I mean, I agree with them. I think people who say 'NAT is not security' are only correct in the absolute most pendantic way and that the way NAT is commonly configured is literally the only reason the internet doesn't consist mostly of botnets.
But I also suspect that if IPv6 were more common, we as a society would be better at it, and not do dumb things like hand out globally routable IPs via DHCP6
The whole premise of IPv6 is that every device should have a globally routable IP. This thread went into DHCP for some reason, but that is uncommon and not recommended for IPv6, where you're supposed to use SLAAC. With SLAAC, I'm not even sure you could realistically disable the ability to get a public IP. And if you did, I'm not sure you could allow a device to access the Internet over IPv6 with a consumer router without it having a publicly routable IPv6.
>The whole premise of IPv6 is that every device should have a globally routable IP
I would agree with the small adjustment of, 'every device should be able to have a globally routable IP'.
There are a lot of devices, like the ones we're talking about, that should not be accessible to the internet at large. You're not preventing them from getting a public IP because you don't have enough, you're preventing them from having a public IP as part of the belt-and-suspenders approach because there's no need to have one.
> in ipv4, if my laptop tries to use a printer with a public ipv4 address, that raises alarms.
The only way that’s possible is that you have a firewall rule blocking outbound connections to common printer ports like 631. NAT couldn’t care less what outbound port you’re connecting to, so it has to be a firewall doing that work.
> in ipv6, if my laptop tries to use a printer with an ipv6 address...
…so enable that same rule you manually configured on IPv4 on the IPv6 firewall, too.
What you’re describing is not default or inherent behavior. If you went out of your way to enable it, you have the skills to do it twice. That’s assuming your firewall is more complicated that “block outbound port <631> to <any IP>”, which covers both protocols on most firewalls I’ve used.
> its not about the firewall. there's just a lot of extra attack vectors without a nat.
Not if your firewall is dropping packets. It doesn't matter if your internal network has routable public IPs or not.
Apple used to have all (most?) workstations on publicly routable IPs since they jumped on the A class networks early.
Difference between NAT and firewall? You can punch a hole in one of them https://en.wikipedia.org/wiki/Hole_punching_(networking)
You on the inside can punch a hole to the outside. This is fine. There's no real difference between hole punching and a regular connection to a regular server from one side's perspective.
Just like a load balancer is a kind of NAT, but I don’t think people would conflate this with a security measure / FW.
> NAT is not for security, it does not provide security.
It’s not for security but it absolutely does provide security and pretending otherwise continues to harm discussions.
I have a pile of ipv4-only IoT devices that have no firewalls of their own that are being protected by the symmetric NAT in my home router. Kick and scream all you want but there is security there and nothing on the internet can reach those devices unsolicited, just like a stateful v4 firewall would provide.
If you really don't have a stateful v4 firewall, your ISP can happily connect to all of your devices.
I don’t think you understand symmetric NAT. Requiring an entry in the port address translation table to propagate a packet is not the same thing as a stateful firewall.
You absolutely can have a port address translation implementation without a stateful v4 firewall that wouldn’t forward packets destined for inner IPs on the outer interface. Just put an ACL on the external interface to not allow traffic to the inner IP block.
How do they manage that?
If your public IP from your ISP is 12.13.14.15, and your internal block is 192.168.0.0/24, then your ISP can send a packet to 12.13.14.15 destined for 192.168.0.7, and without a firewall your router will happily forward it. An attacker who can convince intervening routers to send traffic destined for 192.168.0.7 to 12.13.14.15 (and these attacks do exist, particularly over UDP) can also do that.
You're using somewhat sloppy terminology that will confuse things. An IP packet can't be addressed both to 12.13.14.15 AND to 192.168.0.7.
The realistic attack here is that your ISP sends a packet with destination address 192.168.0.7 to the MAC of your router (the MAC that corresponds to 12.13.14.15). This is a realistic attack scenario if the device that your router connects directly to gets compromised (either by an attacker or by the ISP itself).
Getting a public route that would take packets destined for 192.168.0.7 to reach your router over the Internet is far more unlikely.
True, the frame is addressed to the router's hw interface but I'm talking to people who think NAT drops traffic so I figured keep it simple
But, yes, the ISP (or whoever has compromised/suborned/social engineered the ISP) is absolutely the main worry here and I don't understand how people are dismissing that so easily
> I don't understand how people are dismissing that so easily
Because that’s not where 99.9999% of attacks come from
Fire up a web server on a public ipv4 address and you’ll get hundreds of requests per day from bots probing endpoints for vulnerabilities. Same thing goes for weak passwords on an SSH endpoint.
Okay, so not only do you have to create a bogus packet, you have to convince every piece of equipment in between you and the end user to collude with it, in the hopes that the final router is so woefully misconfigured as to act upon it?
The ISP is the primary threat vector here (do you trust yours? Along with their contractors and anyone who might have compromised them?). But like I said route-poisoning attacks do exist.
yeah but the likelihood of this is incredibly remote. It would shock me if ISPs didn't have alarms going off if RFC1918 space was suddenly routable within their BGP table.
Not to mention the return packet would be NAT'd so the attacker would have to deal with that complication.
You're missing the part where the ISP is the one doing it
Mm. Can you give an example of that happening in real life?
Google "Eagerbee"
Not finding anything saying that ISPs have anything to do with Eagerbee.
ISPs were the vector for Eagerbee. Don't trust your next-hop router.
There's nothing on Google about that.
The return packet wouldn't be NATed, because stateful NAT tracks connections and only applies NAT to packets that belong to outbound connections.
Arguing over how likely this is is missing the point. If it can happen at all when you're running NAT, then it should be clear that NAT isn't providing security.
“if it protects 99.999% of attackers from reaching you but not this one specific attacker in this one case of misconfiguration, it’s not providing security”…
Dude, that’s a really shitty take and this is why people that do care about security end up ignoring advice from anyone who thinks this way.
You’re in the camp of “don’t use condoms because they can break”.
NAT doesn't protect you from 99.999% of attackers though. It doesn't do anything to incoming connections, so it actually protects you from 0% of attackers.
Okay, but unless you've poked a hole through NAT (and if you have, presumably you know what you're doing), what are those incoming connections going to connect to?
If there's nothing to connect to, is there really an incoming connection?
They connect to whatever IP is specified in the packet's "destination IP" header field. It's exactly the same behavior as if there was no NAT going on.
The destination IP header from the internet belongs to the router. There is nothing internal to connect to without NAT.
No, it might belong to the router. If it does then the connection goes to the router, but if it's set to a LAN machine's IP then the packet gets routed to the LAN machine.
You aren't in control of the contents of inbound packets, and NAT won't filter them to enforce anything about the destination IPs in them either.
Nobody on the Internet can send a packet to an internal IP on your network except for immediate L2 neighbors (I.e. your ISP).
Symmetric NAT 100% stops inbound unsolicited connections to the public IP. And using the public IP is the only way 99.999% can address you.
I implore you to write down (even if just for yourself) what the packet headers would be for you to get a packet from Starbucks WiFi to the device at your home at 192.168.0.5 that has made no egress connections.
You’ll quickly find what you’re suggesting is nonsense. port address translation requires an entry to function. It’s not some optional security feature. It’s required information to get the packet header rewritten to reach private devices.
You can't get a packet from a random store wifi network to your home network when your home network is using 192.168.* (barring something like routing headers, which most routers wouldn't process). You said that yourself in the first part of your post, and I don't think I ever argued otherwise.
> Symmetric NAT 100% stops inbound unsolicited connections to the public IP
No, it doesn't. If it did it wouldn't be possible for routers to accidentally make their web admin or UPnP interfaces available to the Internet.
It doesn't stop connections to your router, and it doesn't stop connections through your router either. It just plain doesn't stop connections, which is why it protects you from 0% of attackers.
Yes, I trust everyone who works at it, mostly because I know where they live.
Do you trust the state actors who have compromised it?
Or more likely, network engineers who’ve been subpoenaed to collect the information?
Your scenario is plausible for high value targets. Like, what country wouldn’t want to have a friendly tech working at the ISP most politicians use in DC? That doesn’t seem improbable.
For the regular Joe Schmoe, I’d be more concerned with court-ordered monitoring.
Ah, that sounds like an American problem. If you're in the US, you're living in a hostile surveillance state that makes North Korea look like a hippy commune.
Oh yes, subpoenas are a uniquely American problem. eyeroll.png
I know all the people that work at it.
No, the router will only forward it with specific implementations that don’t isolate routing tables between the external and internal. Or an easier approach is just a stateless ACL on the external interface. Neither are a stateful firewall.
Send packets to the device? A NAT is in it's most basic form a mapping from one IP/port set to another IP/port set describable by some function "f" and its inverse "g". The common home user case has the firewall detect a flow from inside the network and modify "f" and "g" to allow this flow. Without the firewall, and assuming you want your devices to talk to the internet in some way, the NAT would forward (with modifications) traffic based on "f" and "g" to all your devices.
First they will have to change their policy of only providing one IPv4 address per ONT connection. Then they will have to convince me to disable NAT on my router, disable the DHCP server on my router, and bridge the WAN port with the LAN block.
Meanwhile in IPv6 land the ISP provided router that my relative has came configured by default to hand out globally routable addresses from the ISP provided /64. Thankfully it also had a stateful firewall enabled by default so there was no difference in practice.
> First they will have to change their policy of only providing one IPv4 address per ONT connection. Then they will have to convince me to disable NAT on my router, disable the DHCP server on my router, and bridge the WAN port with the LAN block.
No. They may be able to directly reach your internal addresses with source addresses that are outside your internal ranges through the WAN interface. For example: if you use 10.0.0.0/24 internally, and your special secret webserver is at 10.0.0.2, I might be able to reach it from 10.1.0.1 through your router's WAN interface.
It doesn't matter what the public IP is: the WAN interface is the default route, Linux will forward the traffic unless something is explicitly configured to block it.
Even if outbound traffic on the WAN interface is unconditionally SNAT'd to the public IP, and the replies have the wrong source address/port, I can still use a promiscuous mode AF_PACKET socket to receive them and interact with the internal server (the destination address will be correct, so the L2 frame will be addressed to the attacker's MAC). Or even just install my own SNAT rule to rewrite them again for me, I suppose.
Some ISPs have multiple subscribers on the same L2 segment, it's possible they can do this to each other.
Of course, I'd imagine many consumer grade routers out there do block this, but I've personally seen some that don't.
Yes, but NAT combined with RFC1918 private addresses does provide a layer of security. This is the most common NAT configuration for 99.99% of residential users. It is what most people mean by "NAT."
If your address cannot be routed across the Internet, it can't be accessed, firewall or not.
I have worked in corporate environments where we NAT'd public, route-able addresses for historical reasons. That would be insecure without a firewall and is not what most people are discussing.
The whole discussion is confused from the start. When people talk about the "security of NAT" they are not talking about NAT at all, but about what happens when NAT is misconfigured or switched off. In the case of IPv4 it means nothing works and your computer isn't reachable. The system is fail safe.
Meanwhile with IPv6 it's the other way around, everything is wide open unless you have a working and properly configured firewall.
It quacks like a duck though.
RFC 4787 is useful in distinguishing NAT mapping vs filtering. Surprisingly symmetric NAT actually seems quite rare today.
It's absolutely common in enterprise networks.
It's not surprising. Symmetric nat breaks some software.
It's scary how somebody posting on hackernews thinks that this site is about hackers in the sense of security.
It's scary how many supposed hackers have never even looked up an RFC before making grandiose statements. There is such a thing as "NAT filtering", see RFC 4787, section 5: https://datatracker.ietf.org/doc/html/rfc4787#section-5
A NAT is not a firewall, yes. At the same time, the NAT boxes out there in the wild absolutely do filter traffic, and yes, it is the NAT that does it, not a separate firewall. Practically all NAT boxes in the wild do stateful filtering. It is not really standardized how they do it, but this is how the real world often works. People argue that the filtering part of NAT is "actually a firewall", but what's the point? From the outside, you will not be able to tell if there's a firewall that filters traffic for which no established connection can be found, or if this is done by a NAT.
Many people are so fixated on the definition that NAT is only address translation and nothing else, they refuse to interact with the real world out there.
The competency crisis is very real.
I suspect the author was trying to put into words why their technically correct world view is better, but he spends his opening arguing semantics (ineffectually, as apparent) instead of meeting the 'wrong' people where they are and explaining why his semantics are an improvement.
Competency crisis is not limited to just the audience.
I think the confusion stems from the fact that my mom's laptop with its 192.168.0.43/24 v4 address is not routable except via NAT, and people believe (rightly or wrongly) that that confers a degree of security.
UPNP and a dozen other NAT defeating tactics exist and have since the early 2000s. NAT translates addresses. Thinking a non-routable range is safe because it's behind NAT is at this point grossly ignorant of how modern network equipment works. It's kind of like port-knocking; yes it makes the attack slightly harder, but doesn't prevent it.
e.g. symmetric NAT exists and often doesn't come with a stateful firewall. Just because the linux box with iptables is protecting your network uses NAT doesn't mean NAT is doing the heavy lifting here. I can see the OMG MY PRIVACY crew is out in force here apparently misunderstanding that NAT does not do that either. I mean, we can explain things to you, but we can't understand it for you.
>UPNP and a dozen other NAT defeating tactics exist and have since the early 2000s.
I know that, and you know that, but squillions of people think that turning the UPnP setting off (if they even know what that is) is sufficient, which is why the myth persists.
UPnP is only relevant for software that's already running on your machine locally. People here aren't generally talking about outbound connections and I think you both know that. The practical effect of NAT as commonly encountered in a residential setting is to drop inbound unsolicited connection attempts.
And yes, everyone is aware that you could also do that with a stateful firewall. And no, none of us care about arguments of definition that attempt to frame NAT as technically being a firewall based on how it operates in practice. Being intentionally obtuse by refusing to acknowledge the obvious isn't going to convince anyone.
It doesn't confer much since it COULD be only NAT and no firewall.
It's INCREDIBLY unlikely to find a case of that in the wild, but possible.
A common example of a host that might have such an address but lacks that sort of security is anything as the default route for inbound packets, E.G. like you'd want your _own_ router / firewall rather than the ISP's modem.
I've managed networks where a publicly-routable block was NATed behind their router
rightly
If the end effect of security is dropping packets NAT and Firewalls both in effect drop packets.
Its kind of just silly pedantry to say NATs aren't security because sure you can't do things like block specific ranges of IPs spamming you (or make outbound rules to control local devices) but 99% of people don't need.
I understand ipv4 networks pretty well. And I would say that any device doing NAT is acting as a basic firewall. Do “true” firewalls do more? Sure. But saying NAT doesn’t provide security is flat out wrong.
If your router had only NAT and someone (i.e. your ISP) sends it a package addressed to somewhere inside your internal IP range, it will happily forward it. A firewall would block it.
Who exactly is going to route/send an RFC1918 address to an Internet gateway?
Are you implying your ISP itself is going to do this? Because the Internet at-large doesn't have routes for your internal address space.
> Who exactly is going to route/send an RFC1918 address to an Internet gateway?
The GP is talking about 1:1 'basic' NAT:
* https://datatracker.ietf.org/doc/html/rfc2663#section-4.1.1
The same problem applies to masquerading. Routers are happy to route packets they receive, and NAT (in whatever form) isn't the tool you use to drop those packets.
If there is more than one machine behind the NAT which one would it forward it to? This hypothetical simple NAT without firewall AFAICT doesn’t exist in reality, even if it exists in specs. I don’t see how it actually could.
Does your ISP attack you often?
Find me a consumer IPv4 router sold in the last ~10 years that does that by default.
Security comparisons should be between proposed new tech vs. existing tech, not vs. hypothetical straw-man tech.
Find me a consumer IPv6 router sold in the last ~10 years without a restrictive firewall enabled by default. I have never seen one.
Ugh, this is part of the reason why I left them, but https://free.fr still does this AFAIR. They were deploying IPv6 to all their consumers well before the other ISPs (more than 15 tears ago), but they have stagnated since.
IPv6 firewall disabled by default. There is only one config for the firewall: on / off. Accept all inbound or reject all inbounding.
To think that they used to brand themselves as "for the geeks", with reverse DNS customization, built-in user-configurable server on the router (all of their routers offer a Wireguard VPN, torrent client, audio output with DLNA & others), a m3u for IPTV, etc. I wouldn't advise anyone to use them due to this issue.
This ticket said they would reopen an internal ticket, back in 2022: https://dev.freebox.fr/bugs/task/27613
Their basic firewall dates back to 2019: https://dev.freebox.fr/bugs/task/27268 (a lot of spam in the replies there). There was none before, and it is still off by default.
This is no small ISP either, they have more than 50 millions clients (including mobile), and are in the top 10 ISPs in Europe. Baffling.
Mine lol. My ISP sent a Nokia Beacon 3.1. When I first logged into its web GUI, it had a "Security" tab with these dropdowns.
Security level
High: Traffic denied inbound and minimally permit common service outbound.
Low: All outbound traffic and pinhole-defined inbound traffic is allowed.
Off: All inbound and outbound traffic is allowed.
It was actually set to "Off" interestingly enough.
That's not the same thing: does it actually forward martian packets? Because that's what's required for this to be exploited.
Consumer IPv4 router has both firewall and NAT enabled by default, and such packet is blocked by its firewall functionality.
Okay, I'm running tcpdump on my desktop. Send me some packets to 192.168.1.127 and I'll watch out for them.
Fun fact I have actually had an sbc get hacked because I didn’t change the default password. I thought it would be reasonably safe for a few days because I knew the VLAN it was on had NAT and the associated firewall rules that deny inbound packets without outbound. But it turned out ipv6 was also enabled on that VLAN with no firewall. Left a bad taste in my mouth over a decade later even if it was a misconfigured firewall rather than an inherent issue with ipv6.
…and they did really guess an ipv6 address? Full scans of the ipv6 address space looks infeasible. Or did the sbc reach out to the internet thus having its address exposed?
Otherwise just the huge amount of addresses should make ipv6 “more secure” imho.
I don’t have any idea how they got the ip, it could certainly have been making outbound connections, though. I think it had NTP, although I might have pointed it at a local server we had for that.
Another possible explanation is that the IP was not random enough. For example: network_prefix::1
> I don’t have any idea how they got the ip,
You might've been using DHCPv6 assigning sequential addresses starting at 1?
Remember: friends don't let friends use DHCPv6[*]. Help out, uninstall DHCPv6 today.
[*] in IA_NA mode (address assignment). PD and stateless info-only are fine.
What's so bad about DHCPv6?
In IA_NA mode, you're at the mercy of the DHCPv6 server for any kind of address privacy. And good luck getting a second address if you want to run a CLAT for 464. You don't want this in a home network.
As for servers, you mostly won't want it either, considering (a) you might rather configure things statically, and (b) it's easier to just deal out whole /64s per server, especially since that gives space for VMs.
So where's the niche for DHCPv6? Maybe assigning addresses for telco or OOB equipment… idk.
And just to be clear: DHCPv6 information-only ("stateless") and DHCPv6 prefix delegation modes are perfectly fine. It's the individual address assignment (IA_NA) mode that should just never have been invented.
More useless crap to remember for a useless protocol.
I don't know how much impact this has in practice, but you do not need to scan the entirety of the ipv6 address space because you can just look at the IPs that are registered to known ISPs/ASs.
You're gonna need to scan 2^64 addresses once you've located the IPv6 network assigned to my connection before you find my phone. 2^56 if you don't get lucky guessing the network prefix it happens to be on at that moment.
Assuming a scan with a minimum 4 byte ICMP packet, that's about 73786 petabytes of network traffic for that /64. You'll need to shove it down the pipe within a day because IPv6 privacy extensions means the IPv6 address used changes after 24 hours. With only 1gbps fiber, I don't think the deanonimysation is the problem at that kind of traffic level.
I'm also not sure how much it helps, but a friend and I were just talking about how big the numbers get today.
My ISP provides my house a /56 allocation. There are 4,722,366,482,869,645,213,696 addresses. I should have enough for a couple of years, at least.
I guess you could scan it. The IPs for most devices are chosen randomly within a /64 subnet, or they're based on MAC address, but they're not sequential by any means. A /64 is still 18,446,744,073,709,551,616 possible IPs.
Unfortunately I think one of the problems with v6 is people are just unable to apply intuition to numbers this big. The minimum number of /64s an ISP will have is around 4 billion. They generally give subscribers a /56 which is 256 /64s. It's all simple power-of-2 arithmetic. Computer people used to get how big 2^64 is.
I agree. Writing out the whole number is intentional.
How many digits is that? Woah, I can barely count the commas!
Most of the time it's going to be a /64, so even if you know the prefix you're still never going to guess a random address. But a lot of older clients will use a deterministic address based on their MAC, searching the space of MACs for known sbcs would be a lot more tractable.
There was a report a few years back about people running NTP servers to harvest IPv6 addresses.
Security via obscurity will only get you so far.
That will only give the NTP server the IP you use for outbound connections. If you use privacy extensions, they'll get a temporary address.
If you don't configure your firewall to allow inbound connections to the temporary address, knowing your temporary address doesn't help them connect back to you. (Also, it's temporary, so their logs of IPs will be useless after a small window.)
Compare this to v4, where connecting out to someone gives them enough information to exhaustively port scan your whole network and trivially find every server you're running.
In theory, IPv6 Privacy Extensions (https://datatracker.ietf.org/doc/html/rfc4941) could mitigate this. In practice, I imagine when you bind to `[::]:port`, that also means that the randomized addresses would work for new inbound connections, too. Not sure how long they typically last, but you'd be fighting against the clock at least before a new randomized address.
That being said, on a slightly less common note: it is quite possible to have each individual service running on a /128. E.g. on IPv6 k8s clusters, each pod can have a publicly addressable /128, so activities like NTP would require the container to have an NTP client in it to expose in that way. That'd mitigate a good chunk of information exposure -- that being said, I agree with the larger point about security via obscurity being insufficient.
It's a pain in the ass to configure the /128 setup, particularly when your ISP can change your /64 at any point in time.
If you have a shitty ISP that rotates prefixes like it's 2005, hosting anything public is a massive pain already. DDNS works just as well on IPv6, though.
Internally, a ULA will keep things reachable even if you move ISPs. You could even set up a NAT66 setup to translate your changing prefix to your stable ULA so you don't need to update any firewall rules, but that's a pretty terrible workaround for a problem that shouldn't be on you to fix in the first place.
That's pretty embarrassing lol
In my defense I was in college at the time, and I did actually run some tests to ensure my understanding of the firewall was correct. I just didn’t even think to account for ipv6 or especially for that range having different firewall rules.
Unlike the other poster, I'm not going to blame you for getting things wrong. It happens, we all were learning at one point. But I do think it's incredibly unreasonable to use a mistake you made as an argument against IPv6. This would be like if I rm -rf'ed my Linux box into oblivion when I was first learning and then avoided Linux after that because I had bad vibes about it. Sometimes you need to accept the L and not blame the tools.
Have you tried setting up an IPv6-only LAN?
No. Why would I want that? What does that make easier?
[flagged]
Nah, happened frequently at ipv6 early days. Some devices shipped with ipv6 enabled but no firewall out of the box.
[dead]
This is going to depend on the router and on IP distribution.
My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.
NAT is not intended to be a security feature, for sure, but it creates security as a side effect. If I start up a web server on one of my devices, I know that it is unreachable from the Internet unless I go out of my way to set a port forward on my router.
But...if my ISP decides to start handing out IPv6, that can change. If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.
But if my ISP still gives me only a single IPv6 address and I'm still needing to use NAT, then I'm guaranteed to still effectively have a "default deny" inbound firewall policy.
> If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.
They usually do, and they also ship with the most wonderful technology ever specified within a 67 MB compressed archive [0]: UPnP! Now your attacker's job is to convince you to initiate an outgoing connection, which automatically forwards an incoming port to your device behind the NAT and bypassing the router's default-deny firewall! Nothing has ever gone wrong with a zero-configuration port-forwarding protocol from the 1990s rammed through the ISO!
[0]: https://openconnectivity.org/developer/specifications/upnp-r...
That's an entirely different attack scenario. To succeed at that attack, my computer would already need to be running malware. At that point, they've already won.
Or you visit a webpage that makes a request to an arbitrary server on an arbitrary port while not running a default-deny application firewall
I don't believe that opens a port to accept an incoming connection.
Even if it did, a web page making a request can't control the source port for the connection. They still couldn't make a local network service exposed to the Internet.
WebRTC and similar tools have existed for over a decade at this point and been abused horribly. Many common UPNP or similar daemons trust ANYTHING on the "trusted" side and will happily grant basically anything asked for because their vendors don't want customer support calls over whatever insane behavior some printer or IOT lightbulb is doing without the end user's knowledge.
Every router I’ve ever used has blocked incoming connections on v6 exactly the same as on v4. Really the only difference is you can have multiple devices on your network allowed to receive on the same port if you want.
> Every router I’ve ever used has blocked incoming connections on v6 exactly the same as on v4.
A few years back my ISP didn't properly support prefix delegation, and the only way to get IPv6 to work was in "Passthrough" mode. My router (Asus ax86u) was really unclear about what passthrough mode meant, but I think that it might also disable the IPv6 firewall (I have read conflicting reports, and was never able to find an authoritative answer). The setting is buried pretty deep in the router and off by default, so I don't think most people would enable it by accident, but a quick google search does show lots of people on forums enabling Passthrough mode to get IPv6 working. So seems pretty dangerous and there is no warning or anything [1] that you are potentially exposing every device on your network to the internet (if that is indeed what it does).
Fortunately, my ISP has since implemented proper support for prefix delegation.
[1] https://www.asus.com/support/faq/113990/
I got curious about what "passthrough" might be doing and found this assertion [0], which reminded me of the existence of '6relayd' [1]. So I assume that that mode relays the RAs & etc, but replaces the link-local address in the RA & etc with that of the relaying interface.
[0] <https://www.snbforums.com/threads/ipv6-passthrough-disadvant...>
[1] <https://github.com/Yamatohimemiya/6relayd>
The Apple AirPort Extreme didn't by default until recently: https://support.apple.com/en-nz/103996
More like Extreme-ly bad router.
So, what side effect of NAT is making your server unreachable here? It sounds like you could turn the NAT off and it would be exactly as unreachable as it was when the NAT was on.
(Just to double-check... have you tried DHCPv6-PD? ISPs will normally only give your router a single IP on its WAN interface, or sometimes no IP on the WAN. Getting the routed prefix for the LAN-side networks involves doing a PD request, which is separate from requesting the WAN IP.)
With NAT your device does not have a publicly routable address. Attackers have no way of contacting you at all. Without NAT you have a publicly routable address and attackers can try reaching out to your device. You rely entirely on your device's and your router's firewall.
So it's not really about NAT although it ends up being a consequence—it's about having a truly private network "air gapped" from the public internet.
No, NAT only affects which IP your connections appear to be coming from. It doesn't change which IPs your devices actually have.
The person I replied to said that they only get a single v6 address. If that's true, it doesn't matter whether they have NAT or not; their network isn't going to have publicly-routable addresses either way.
If your network is air-gapped then no connections will be happening at all, in or out... and if you connect a router to both the Internet and to your network, and enable routing on it, then it's not air-gapped any more.
> No, NAT only affects which IP your connections appear to be coming from. It doesn't change which IPs your devices actually have.
Well no shit. The NAT is a requirement for devices without a publicly routable IP because if my router just sends packets out with a source address being my 192.168.1.101 local IP, my ISP is most likely just going to drop the packets.
You know this, I'm sure, so I'm really unsure what point you're trying to make.
> The person I replied to said that they only get a single v6 address. If that's true, it doesn't matter whether they have NAT or not; their network isn't going to have publicly-routable addresses either way.
Correction: It will have ONE publicly-routable IP, and if I assign it to my router, but don't use NAT, then none of my devices on the network will be able to talk to the Internet, either in or out.
The point was that turning NAT on or off doesn't affect whether your LAN is reachable or not. NAT just edits the source address of your outbound connections. It's irrelevant to how your inbound connections behave.
> Correction: It will have ONE publicly-routable IP, and if I assign it to my router, but don't use NAT, then none of my devices on the network will be able to talk to the Internet, either in or out.
Right, and then if you add NAT you'll be able to make outbound connections, but inbound connections will be unaffected and will still not work. So what is NAT doing here to prevent inbound connections, given that the exact same connections already didn't work before you were NATing?
Turn fireball off. Keep NAT on, internal addresses are still not reachable. You are protected against firewall misconfigurations as well as the outside world. Defense in depth.
NAT in its customary usage is a bit of a historical accident that as a side effect happens to make it basically impossible for non-technical people to expose their devices.
Again, I ask: what is NAT doing to make those internal addresses unreachable? What side effect of NAT is making it basically impossible to expose your devices?
In the post I was replying to, the hosts were already unreachable (or... mostly unreachable, not completely unreachable) before NAT was even in the picture.
I think the problem is that everyone else is operating under the assumption that all the computers on the network still to be able to make outgoing connections to the Internet and you're not.
If I want all the computer on my network to have Internet access, I have two options: Each gets a publicly routable IP, which results in all computers being exposed to incoming connections unless I have a firewall, or I get a single IP which gets assigned to my router, use NAT, and all my devices are no longer exposed to incoming connections unless I go out of my way to configure port forwarding on the router.
So when I talk about the "side effect of using NAT", I really mean "side effect of using NAT instead of assigning public IPs to each computer on my network".
Does that help clear things up?
> my ISP still gives me only a single IPv6 address
This is criminal, and also incredibly uncommon. You should talk to your ISP, it's most definitely a misconfiguration of some kind, if not deliberate torture. Normally you get a /56 at least because there are so many and they cost nothing.
Not at all. In China, where I live, this is often the case.
Many Huawei routers do it by default: they serve ULAs on LAN and do nat6 to a single public v6 address.
Is not "deliberate torture", it's just the easiest way to implement things
> they serve ULAs on LAN and do nat6 to a single public v6 address
I've never seen this and I'm curious: do they actually pick a random /48 out of fd00::/8 like they're supposed to?
Datapoint of 1: With Cox as my ISP, I can get a /64 just by configuring my DHCPv6 client to request it, but if I wanted a /56 or /48 I would have to contact someone at my ISP.
I'm beginning to think it might be a US thing. Every time there's an ISP horror story, it's always the US.
There are exceptions, my ISP is Sonic and /56 prefix delegation works flawlessly with them.
Nah, we have the same thing in China.
Same at my place. I get a /64 prefix and my router simply cannot work with that at all.
What does IPv6 /56 cost if I would like to buy one for a server?
AWS will give you a "permanent" /56 for free in each region (in their address space, obviously)
What ISP gives you a single IPv6 address? That's incredibly comical. An ISP would have at least 79 billion billion billion addresses and they are giving you one?!
If I run a webserver on my network I know it's unreachable from the internet unless I specifically allow inbound traffic to it at my firewall. I get to use the actual security features with sensible terminology instead of silly things like "port forward".
> My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.
Interesting how that works in your case. Is your router gives your devices IPv6 from fc00::/7 and then NAT them? It would be a rather rare case.
I'm really curious too. It's probably fd00::/8 though right? fc00::/8 is technically still reserved, although everyone seems to ignore that...
NAT causes security issues too. Reflection attacks are much harder to stop if the endpoint and its network address are decoupled.
You can provoke loops and tangles of many sorts, some at the same protocol level and others going up and down.
My memory is fading but I vaguely recall a time when all of AOL shared something like a dozen egress addresses for certain traffic -- might have been proxies as opposed to NAT/"PAT" as we know it today. Iow, you couldn't block one without blocking 1/12 of AOL users.
Stronger memories of a time when your IP address (some were nat, some were not, varied by ISP) depended on which modem bank you dialed into, which was strongly influenced by what phone number you dialed. Which diluted the identity value of a given IP for a computer or user.
The RFC introducing NAT -- RFC 1631 -- says:
> Unfortunately, NAT reduces the number of options for providing security [1]
Somehow, everyone forgot that, and it morphed into a cargo-culting security practice, even going so far as to propagate 1990s network limitations into the cloud(!)
[1] https://www.rfc-editor.org/rfc/rfc1631.html
Real world CSRF attacks into hxxp://192.168.0.1 home routers and polluting DNS and DHCP settings you could argue is caused or at least facilitated by NAT, or NAT misconceptions especially.
Though IPv6 has a similar situation with well defined unicast and multicast addresses.
True story, popular browsers won't let you load a webpage via various IPv6 local address literals for this reason. Hxxp://[ff02::] addresses won't work.
/ You can have your cake by "tying a knot" with yourself and port forwarding from 127.0.0.1 to the IPv6 literal. An ssh port forward will do this with aplomb. Then load hxxp://localhost:port and it works again.
// Browser logic
[dead]
Thanks for that quote. Finally something to slap into the faces of those who just refuse to acknowledge that NAT is not a security feature.
> The consequence of this is that when receiving inbound traffic, the router needs needs to be configured with where to send the traffic on the local network. As a result, it will drop any traffic that doesn’t appear in the “port forwarding” table for the NAT.
As I keep trying to explain each time this comes up: no, it doesn't and it won't.
When your router receives incoming traffic that isn't matched by a NAT state table entry or static port forward, it doesn't drop it. Instead, it processes that traffic in _exactly_ the same way it would have done if there was no NAT going on: it reads the dst IP header and (in the absence of a firewall) routes the packet to whatever IP is written there. Routers don't drop packets by default, so neither will routers that also do NAT.
Of course, this just strengthens your point that NAT isn't security.
It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.
That's a great point - the packet is not dropped by the firewall as a result of NAT - but it still won't route anywhere because the IP in the packet is that of the router itself. I've updated the article as a result of your comment, thanks.
That's only because your ISP won't have routed that packet to you if someone gave it to _them_. However, if someone was able to get to the ISP-side of the connection that you have with your ISP, and send a packet down the fiber/copper line from the ISP side towards your router, and that packet has a dst of your internal network (192.168.0.1 or whatever), your router will happily route that straight on to whatever internal network you have.
This means that if someone decided to be a bad actor and start tapping fiber lines on the poles in your neighborhood, NAT would do literally nothing to protect you from all the packets they start sending your way.
Yes, physical tapping of lines / ISP attacks were outside of the threat vector I was discussing. At this point, I think any discussion of NAT starts to look a little orthogonal.
If somebody is wishing to tap fiber optics lines to the ISP or to hack the ISP just to get to your router, then you probably are not going to be saved by a "default deny" firewall anyway.
It might be the IP of the router, in which case the router itself will accept the connection if something is listening (like the web interface perhaps). But whoever sent you the L2 frame has full control over the contents of the IP in the packet, so it could be anything.
NAT doesn't protect you from either of these.
Repeating the same wrong points doesnt make you right.
Every NAT based product will have a firewall built in also by default. And it'll be deny-all except for conn-tracked.
And that L2 attack is a martian packet. Why are you allowing reserved IPs talk on public network interfaces (hello, spoofing and obvious at that)? These are always blocked due to the reasons you describe.
https://en.wikipedia.org/wiki/Martian_packet
> Every NAT based product will have a firewall built in also by default.
Well that's the point of the article isn't it? That the firewall is the important part, not the NAT.
So, if you have NAT but a grossly misconfigured router, it might not be secure?
Quick question - do you think that "security by obscurity is not security"? And, as a follow-up, when you park your car do you ensure your laptop bag is out of sight, maybe locked away in the boot?
Because here's a mindblowing concept that'll change the way you see the world - you can have a door lock but it won't make you secure. You need to actually fit the lock to some sort of door.
If you have NAT, that doesn't tell you anything about whether the router is secure. All it tells you is that outbound connections made through the router will appear to come from the router's own IP; it doesn't tell you whether inbound connections will work or not.
John, your post opens saying it's addressing the point: “the NAT-by-default of IPv4 effectively means that I get the benefit of a default-deny security strategy.”
Your title is "IPv6 is not insecure because it lacks NAT"
I'm sure anyone who understands how NAT offers the equivalent of a default block rule also understands that the absence of NAT alone doesn't make IPv6 insecure. This makes the title feel a little clickbaity-strawmanny, sorry.
Your response seems to be: "most firewalls have a default block rule too meaning they're no worse than IPv4 w/ NAT."
There's more security to be had in an intrinsic architectural feature (like IPv4 NAT being necessary due to limited IPv4 space meaning most IPv4 devices behind CANNOT be addressed from the internet without NAT) then there are in policy features (most firewalls SHOULD have the default deny IPv6 rule that will stop their address being reached from the internet.)
That doesn't make IPv6 insecure because no NAT. But it does mean - IMO - that the intrinsic block that comes with IPv4 NAT is a better security measure for making devices inaccessible than relying on default firewall rules.
What point are you trying to make here, and is it actually more useful than the point you say you're addressing?
> There's more security to be had in an intrinsic architectural feature
No, there is not. Even ignoring the question of whether the concept of an ordinal ranking in amount of security even makes sense, this claim doesn't make sense. If the invariant is that incoming connections are blocked by default, an IPv4 NAT and an IPv6 default deny rule are equivalent in security: both uphold the invariant. If the claim is that a misconfiguration of the gateway can make the system vulnerable, again, the two kinds of firewall configuration are equivalent: you can configure an IPv6 firewall to pass traffic and you can configure a DMZ host or port forwarding in the NAT case.
There's no basis for claiming the two schemes differ in the level of security provided.
> an IPv4 NAT and an IPv6 default deny rule are equivalent in security: both uphold the invariant
Yes, you're correct, on some level, they are equivalent: in both cases, packets don't reach the target machine. That is one of the few levels on which they are equivalent.
> There's no basis for claiming the two schemes differ in the level of security provided.
Yes there is, this is basic secure architecture and secure by design principals. If you understand these principals, you will understand that the equivalence level you're talking about above leaves space for other security issues to creep in.
> you can configure an IPv6 firewall to pass traffic and you can configure a DMZ host or port forwarding in the NAT case.
IPv4 & NAT config: takes effort to accidentally expose things behind it. It's not even physically possible to fully expose all the ports of more than 1 host behind it, assuming it's only got 1 public IP. For IPv6 and firewalls, you've just pointed out how easy it is to configure it to not have this security property.
I'm not arguing that IPv6 is not secure because it lacks NAT. My point was that this entire discussion is silly engagement bait: there's no clear right answer, but it's an easy topic for dogma and engagement. A holywars topic like NAT, IPv6 and security is prime for that. The author and submitter muddies the waters further by - probably not intentionally - choosing a strawman submission title.
> Yes there is, this is basic secure architecture and secure by design principals
The only principles at work here are the ones of superstition and magical thinking. The existence of a "disable security" button doesn't weaken the theoretical security properties of a system when that button isn't pressed, and NAT systems and pure firewalls alike have this button.
If anything, NAT systems are sometimes worse due to things like uPNP automating the button-pushing.
Look: I just don't accept the premise that making a system more flexible makes it less secure. If your threat model includes user error, then you have to be against user freedom to achieve security guarantees.
The amount of "effort" it takes to disable security measures has no bearing on the security of the system when properly configured, and how easy you make it to disable safeguards is a matter of UX design and the tolerance your users have for your paternalism, not something that we should put in a threat model.
I think most of the comments on this thread crystallise two different conception of security: the intended one and the effective one.
The second one is messy to measure, it requires making statistics on how often NAT saved the day by accident, which is hard if not impossible.
I personally think that statistics always win, even if they are unexplainable. My bet (zero proof) is, IPv4 is statistically (maybe by accident) more secure than IPv6, just because of NAT.
I have seen so many horrors in terms of multiple NATs I will always prefer IPv6, also because I think the benefits outweigh by far the difference in _effective_ security.
Summary: yes, IPv4 is more secure, but the difference is so marginal that IPv6 is still way better. Security is not the only metric in my world and theoretical discussions obsessing about a single metric are pointless.
I see the split too. I'll add that each camp is frustrated and feels the other is missing the point and would make information security worse if its worldview won.
You can do some empirical analysis. Someone downthread linked to a paper claiming to being able to reach a few million vulnerable devices over IPv6 and not IPv4. This kind of analysis isn't dispositive, though, because there are all sorts of second-order effects and underlying philosophical differences. Facts seldom change minds when you can build multiple competing true stories around these facts.
I'll call one camp the "veterans". They see security mostly as a matter of increasing the costs incurred by attackers relative to defenders, looking at the system holistically. Anything that increases attacker workload is good, even if it's an unintentional side effect of something else or interacts with software architecture in a cumbersome way. It's vibes-bases: whether a give intervention is "worth it" is an output of a learned function that gives in the stomach of a seasoned security researcher who's seen shit.
The other camp I'll call the "philosophers". (My camp.) The perspective here is to build security like Euclid's elements, proving one invariant at a time, using earlier proofs to make progressively more capable systems, each proven secure against a class of threat so long as enumerated assumptions hold. They read security as an integral part of system architecture. Security comes from simplicity, as complexity and corner cases are the enemy of assurance.
The veterans see the philosophers as incoherent. There's no such thing as a safe system: only one not yet compromised. You can't solve problems for good anyway, so there's no use trying to come up with axioms. Throw away the damn compass and strait edge and just draw siege map in the dirt with a stick.
The philosophers see the veterans as short-term-oriented defeatists who make it harder to reach levels of provable security that can solve problems once and for all so we don't have to worry about them anymore. You have to approach complex systems piece by piece or you can't understand them at all -- and worse, you'll do things in the name of security gutfeels that compromise other goals without payoff that feels worth it to them. They say, "Without my compass and straightedge, how can I design my star fort with firing lines I know cover every possible approach?"
The divide shows up in various projects. TLS is a philosopher project. Certificate transparency is a veteran project. Stack canaries are a veteran project. Shadow call stacks are a philosopher project. I think you get the point.
This thread reveals a surprising split between veterans and philosophers on NAT. In retrospect, it's kinda obvious that the veterans would insist that "duh, of course IPv4 prevents inbound connections and it must because otherwise the Internet won't work", and the philosopher camp is "Hold up. One thing at a time. What's the actual goal? How can we achieve this goal minimally without side effects on Internet routing?"
My camp sees the NAT configuration issue as a red herring. We see "the UX makes it too easy to run unsafe" as an HCI issue distinct from the underlying network architecture. The veterans say "Well, you can't build that button if you have NAT, so we are led not into temptation."
Both camps have something to contribute, I think, but the divide will never fully disappear.
I understand your view, I just disagree with the value you're putting on it, and I feel you're straying into accidentally insulting people to justify yourself:
You called yourself a philosopher and then proclaimed philosophers are the only ones who read security as an integral part of system architecture, whilst veterans are essentially vibe coding and surviving on the lucky mess they create.
I find your position that misconfiguration is a red herring in security as completely unjustifiable and untenable.
It's probably that I'm just a puny brained veteran seeing your big complex philosopher smarts as incoherent though.
Anyway, I digress from the key point I've been trying to make in this entire thread:
I'm not arguing that IPv6 is not secure because it lacks NAT. My point was that this entire discussion is silly engagement bait: there's no clear right answer, but it's an easy topic for dogma and engagement. A holywars topic like NAT, IPv6 and security is prime for that. The author and submitter muddies the waters further by - probably not intentionally - choosing a strawman submission title.
You talked right past the key point which is valid:
> There's more security to be had in an intrinsic architectural feature (like IPv4 NAT being necessary due to limited IPv4 space meaning most IPv4 devices behind CANNOT be addressed from the internet without NAT) then there are in policy features (most firewalls SHOULD have the default deny IPv6 rule that will stop their address being reached from the internet.)
One security property is architectural, one isn’t. They’re not the same.
> Even ignoring the question of whether the concept of an ordinal ranking in amount of security even makes sense
I must be misinterpreting this statement, are you arguing that you aren't sure whether "x is more secure than y" is inherently a valid thing to compare?
"X is more secure than Y" is usually an ill-formed statement. Secure against what threats? Does X provide every security guarantee Y does? Every single one? Then there's no proper superset relationship, and the best we can do is say that X and Y provide different security guarantees.
If we model security as a lattice, lots of systems end up being incommensurable. You have to talk about the specific threats.
Okay, suppose you want to flatten the lattice into a scalar score so we can apply the usual relational operators and statements like "more secure" make sense. How do we do that? Do we apply some kind of weighted average over security feature presence? With what coefficients? Are these coefficients invariant over time and between people? What if my use-case is different from yours and I have to model the "amount" of security differently?
If my router is written in 100% memory safe code but has a default password of "hunter2", is it more or less secure than your router, which might be a normal OpenWRT installation?
When people argue over whether something is "more" or "less" secure without specifying a use-case, they're haphazardly mixing feature matrix comparisons and (usually tacit) disagreements on prior probabilities of various attacks. The result is seldom a conversation that enlightens.
I can see what you're saying, but I don't think the existence of situations that aren't comparable means we should do away with idea of comparison. You could make that argument about almost anything (not just security): almost always in engineering (and life) there are tradeoffs. Sometimes those tradeoffs are clear-cut. Sometimes they aren't.
There may be a long tail, but I don't think that should exclude sensible statements like "deny-by-default is safer"...that promotes situations where software doesn't select opinionated defaults and so you end up with publicly accessible Mongo and Redis and S3 resources as we've seen over the years.
I'm calling for linguistic precision. What does it mean for a SOHO router to be "secure"? If we taboo this word "secure" for the moment and instead ask how effectively these devices, e.g. prevent unauthorized inbound connections to bottable IoT devices, we can start to get a concrete sense of the landscape and directions in which we can move across it. By focusing on the specific thing we want to accomplish, we can avoid getting distracted by considerations relevant only to other scenarios and better approximate a "meeting of the minds" on terminology and goals
Invoking NAT "security" as a reason against IPv6 is a surefire indicator the person invoking it has absolutely no idea what they're talking about and should not be allowed within typing distance of any network infrastructure
As a reason not to IPv6? I guess. As a thing, not scare-quoted, but really security? No. Be careful with things like "absolutely no idea what they're talking about".
I don't think that the inherent security of NATs is a _good_ reason to not do IPv6.
But it _is_ a reason, and it _is_ true.
Please. _I_ invoked that argument, and I bet I know more about IPv6 than you do.
All my services and networks have IPv6. And my first operational issues with IPv6 were in 2008, when my Asterisk SIP server started failing after ~12 hours.
Culprit? Privacy addresses kept accumulating until they overflowed the SIP UDP packet size because it listed all the combinations of supported codecs/endpoints.
Oh, btw, do try to answer this message: https://www.reddit.com/r/VOIP/comments/131ex1x/ipv6_sip_trun... - it's still relevant to this day.
You should have just disabled temporary addresses, they don't make a lot of sense on a server.
Well, I know that now. They were enabled by default, and I did not think they could _harm_ anything.
Having read and considered your position I see no reason to update my opinion.
This has been gospel among snooty network engineers for decades, but NAT was initially introduced to the wider market as a security feature, and it is absolutely a material factor in securing networks. The network engineers are wrong about this.
(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
I would never debate NAT was marketed as security (as marketing is often detached from the reality of what's being sold) but I'd be interested why it's a material factor in securing networks independent of the stateful firewall mentioned, which most seem to actually rely on. The "snooty" people probably mean less what may have been marketed to consumers and more what the standards which introduced it say. E.g. https://www.rfc-editor.org/rfc/rfc1631 notes address depletion and scaling as drivers in the opening but the only mentions of security are later on in how NAT actually makes security more difficult.
I.e. it would seem whatever argument could be made about security from NAT, poor or not, intended to be security or not, would be immaterial in context of stateful session tracking with outbound originate allowed alone w/o doing the NAT on top anyways.
It was more than just "marketed" as security. It was brought to market as a security product and used that way for many years, before address depletion was a meaningful problem. People used NAT firewalls back in the eras of routable flat class-B desktop computer networks.
The first commercial NAT box was the PIX in 1994, which featured stateful session firewalling (not just NAT) in agreement with the above 1994 RFC. It was still the era of referring to classful networks, but I'm able to source documents from the time which state the opposite of your claims.
Here's an ad for it from Jan 1995 https://www.jma.com/The_History_of_the_PIX_Firewall/NTI_file.... Note by the 3rd paragraph it's saying
> corporate networkers are free to expand and reconfigure their TCP/IP networks without agonizing over the much publicized IP addressing crunch. It also spares them from having to upgrade all of their host and router software to run IP version 6
It does end with the aforementioned security marketing making it sound like NAT is what provides security on the PIX:
> PIX also increases network security. Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
> And what about hosts that should be recognizable from the Internet, such as mail servers?
> These either can be directly attached to the Internet and assigned a public address or can be attached through PIX. In the latter case, the translator is configured to map one of these external addresses to the device not just for the duration of the application session but on a permanent basis.
Looking past the marketing line and reading the manual, the reality was the PIX was always acting as a full stateful firewall and did not just rely on NAT itself to provide the inbound filtering. See the "PIX Firewall Adaptive Security" section on page 2 of this 1996 manual I managed to dig up as reference https://mail.employees.org/univercd/Nov-1996/data/doc/netbu/.... Rule hits that missed a state match were even loggable (what a box for the time!)
Whether people saw the marketing and assumed it was NAT that provided security is precisely the bad assumption the article talks to, but at no point in history was NAT prevalent without being paired with a normal stateful firewall to provide the security - since the intent of NAT was not to fill that role, even in the beginning, as sourced by 3 references now vs your personal claims.
The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful.
The point is that NAT was introduced as a kind of firewall. The PIX firewall was named by Network Translation, Inc., which was acquired as a security device --- and, indeed, the PIX was for many years the flagship security brand at Cisco.
I don't dispute that NAT is dispensable (though: dispensing with it in millions of residential prem deployments is another story altogether!), only that it's "not a security tool" --- it clearly is one, and a meaningful one (whether network snoots like it or not) in a huge number of networks.
> The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful.
That's not the distinction I, or TFA, set out to make.
It's not that NAT is a component of controls that could be replaced by others, it's that whether NAT was put in place for security or if it was always assumed you need an actual stateful firewall precisely because NAT was never intended or believed to provide meaningful security, even in the days of classful networking.
Not one of the references above makes claim that NAT was intended to provide security on its own. That the PIX launched with actual firewalling capabilities does not bolster that NAT=security, it actually bolsters that NAT was never believed or intended to provide security even further.
To turn this back around at you: The distinction you're drawing that NAT could have provided "something better than nothing" in terms of security if appliances like the PIX hadn't always shipped firewalling from day 1 isn't meaningful.
The whole point of NAT firewalls is that the devices behind it don't have routable addresses. "Statefulness" improves the situation, but the translation itself provides a material control.
I suppose we fundamentally disagree that it's meaningful or material whether NAT can provide something the stateful firewalling has handled more completely since the first shipping implementation and that this defines what the purpose and introduction of NAT to the market was supposed to be.
There's no uncertainty at all about what NAT was meant to do; you can just read Cisco's introduction to the PIX, or it's statement about the acquisition of NTI, which are online.
Network administrators (less so security engineers) don't want NAT to be a security feature, so they've retconned a principle of security engineering that doesn't exist. If people were honest about it and just said they'd prefer to work on networks where less distortive middlebox features provide the same security controls, I'd have nothing to argue about.
But this article makes the claim that "NAT isn’t actually a security feature". That's simply false. People need to stop rebroadcasting this canard.
One could see the inlined, sourced, and dated references I placed above about the PIX rather than searching online from scratch or making assumptions of others reasons or intentions.
What some people do or don't want in the 2020s has no relevance to the reasoning in the 1990s, nor does it redefine the purpose or use of NAT the same. The above is clearly and directly stated from the sourced material of the era itself: NAT was introduced in the mid 90s due to concerns about address space depletion and the need to move to IPv6. The security features of said introductory appliance never came from or were supposed to come from implementing NAT, but from implementing stateful firewalling and blocking inbound connections. There is no personal opinion or retconning in any of this, they aren't even the postings of anyone from this century.
Your own sources confirm what I'm saying.
> Your own sources confirm what I'm saying.
I don't see where they do. I see them talking almost exclusively about working around address depletion.
Hell, look at Cisco's press release for its acquisition of Network Translation, Inc. [0] It's all about address depletion and resource efficiency; security is mentioned as an afterthought. I'll quote the relevant paragraphs (and leave in the line break mangling present in the original).
[0] <https://newsroom.cisco.com/c/r/newsroom/en/us/a/y1995/m10/ci...>Read the Data Communications article they provided:
PIX also increases network security. Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
And what about hosts that should be recognizable from the Internet, such as mail servers? These either can be directly attached to the Internet and assigned a public address or can be attached through PIX. In the latter case, the translator is config- ured to map one of the external addresses to the device not just for the duration of an application session but on a permanent basis.
At some point you're going to have to find a way to argue that the Cisco PIX was not a security device; again: it was the flagship product of the security SBU.
I was there at the time, doing IP network engineering (for a Chicagoland ISP). The PIX was a security device, and NAT was understood as a security feature (for sure, also an address depletion feature, but the argument that's being made in the post isn't merely that it was an address depletion thing, but also that it categorically wasn't a security feature, which is just obviously false.)
> At some point you're going to have to find a way to argue that the Cisco PIX was not a security device...
What? It's a firewall that can do NAT. The PIX is clearly a security device. NAT is clearly an address-depletion-mitigation technique.
> Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
Right. And you can achieve the exact same effect with a firewall on an edge router or on a host. I get that firewalls might have been much less common thirty-ish years ago and that doing packet filtering might have been pretty novel for many, leading folks to get confused when they encountered a combination firewall+NAT device.
I'm not sure I can be any clearer about the fact that NAT is both a security feature and an address management feature. I feel like people who weren't practitioners are the time are trying to reason axiomatically that every feature fits into precisely one bucket, or that a security feature isn't a true security feature if it can be replaced by one or more other "cleaner" security features. None of that is true. Practitioners at the time were not confused.
"You can achieve the same effect" doesn't mean anything in this discussion. If that's your argument, you've conceded the debate.
Ah, I see what you're driving at.
It's a security feature in the same way that a power-cut switch is a security feature. A power-cut switch's purpose is cut power to a machine so that it can -say- be safely worked on or relocated (or simply to not draw power when the machine's not in use), the machine also happens to be inaccessible while its power is cut.
Sure. It's not technically a lie to call a power-cut switch a security feature for most pieces of kit. I'd still laugh at the salesman that made the assertion. If I were feeling particularly cunty, I'd ask him if he injured himself from that great big stretch.
I can't emphasize enough how much of a retcon it is to say "it's not technically a lie" that NAT is a security feature. It was deployed in hundreds of networks specifically as a security feature, and it is part of the security posture of hundreds of thousands of home networks today. People who say "NAT isn't a security feature" are simply wrong.
There are lots of security features I personally don't like either. I don't claim they're not security features; I say they're bad security features.
The PIX evidence above doesn't make it look like a retcon. Do you have something better to show about those hundreds of networks?
> Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
This is a security feature ad, nothing else. And it’s 100% because of NAT, not anything else in the PIX feature set.
That came up earlier and I know it's a gray area but I agree with the idea that a line tossed into the marketing and not backed up by the manual weakens the importance. The firewall in the PIX is the security workhorse.
Also that sentence implies you can get a connection to a device, you just know less about which one it is. Is that really a meaningful security feature? To the extent that connections are actually blocked, it's not because of the NAT scrambling they quoted in the first half of that sentence. That sentence is somewhere between unhelpful and flat-out wrong.
No, you cannot get a connection to the device. It’s an un-routable block of RFC 1918 addresses.
> No, you cannot get a connection to the device.
...okay? I didn't say you can. I said that line in the marketing implies you can, as part of how it's wrong.
If that wrong line in the marketing is the strongest evidence for NAT being initially understood as a security feature, that's very weak evidence for the pile.
(If the way I worded things needs more clarification, let me try to elaborate. There is a way in which NAT would prevent the connection, but that aspect of NAT is not what the marketing sentence talked about. It incorrectly talked about a different aspect of NAT. While there could theoretically be a device that uses NAT for protection, this device uses the firewall for protection. Just like basically every other device that can do NAT.)
Im not sure why you’re digging in this way. The marketing material is clearly making security arguments. Whether or not you agree with them is entirely irrelevant because the statement was that NAT was marketed as a security feature.
> Im not sure why you’re digging in this way. The marketing material is clearly making security arguments.
Oh, I see where you're misunderstanding the claim I'm making, continued from what simoncion was saying.
Yes, the marketing is making security arguments. The PIX is a security device as one of its main functions.
The feature that was put in specifically for security is its firewall. The NAT isn't adding anything on top of that, security-wise.
> Whether or not you agree with them is entirely irrelevant because the statement was that NAT was marketed as a security feature.
The original claim is that companies generally saw NAT itself as a security feature. That goes beyond a single incoherent sentence in a piece of marketing about a device that had NAT and a firewall. Again, I accept that the sentence is some evidence for the idea but it's so weak. This is something that happened just a couple decades ago, there should be plenty of evidence of actual decisionmaking.
Also it occurs to me that the phrase "know which machine on the corporate network is using a Class C address" might be talking about NATing entire IPs, every port at once. In which case that's very much not a security feature. NAT like that puts the machine naked on the internet. It's about as secure as having your devices get publicly routable addresses out of DHCP. So if that's what they meant, that sentence is making unjustified claims. Did one easily disproven line in a pamphlet convince an industry?
I don’t know what to tell you dude. Back in 06 as an admin for campuses where more than half of the machines were XP pre service-pack 2, NAT was 100% used as a security feature.
For public WiFi networks and labs where we couldn’t control software on end devices, we put them behind NAT pools purely for security (we still had enough public v4 IPs to give them to printers).
You can hand wave however you want, but back then NAT was used for an easy first level of security.
“There existed a better thing in a pure stateful firewall” is not an argument against people using NAT instead.
"I have personal experience using it that way" is a much better argument than anything you said in previous posts. Thank you for saying that, no sarcasm.
Was there a reason you didn't firewall those devices? I mean, a basic firewall has to do less work to attain the same security, and needs less configuration.
You've repeatedly re-emphasized your personal claim "this is how it was" while continually refusing to provide any external evidence, yet have the gumption to continue repeating it must be others letting their personal feelings get in the way of looking at what NAT was that leads to the disagreement about the history.
NAT does not care about anyone's personal feelings, one way or the other. Bringing up what you think other's personal feelings are does not help you redefine the original purpose and usage of NAT to be about security.
If you were solely arguing pure NAT could possibly be used today as (or that a few had eventually made poor attempts to use pure NAT as) a way to have better-than-nothing security then I'd agree. Instead you're insisting to rewrite history to make it sound like that's the way NAT was always intended to be used or what it was widely deployed for based on your personal recollection alone, other evidence be damned. If, e.g., the RFC had given more to say about being for security instead of address exhaustion, I highly doubt you would have completely ignored any reference to it in these ~dozen messages.
Which, again, only helps you against attackers who are on the other side of a router you trust. Do you trust your ISP?
The principle difference, IMHO, is that it makes the security visible. My home cable router has NO firewall configuration at all. Supplied by my ISP and woefully deficient in absolutely all respects. I can't (for example) configure It does have a configuration for forwarding IPv4 ports to inside machines; but none for forwarding IPv6 ports. Does it have stateful filtering of IPv6 ports? I'd like to think that it does, but if so there is no visible evidence that it does.
This is one of those occasions where people are arguing semantics, and you're like "but -- I was there!"
My first cable modem did not have a NAT, nor did my first ADSL modem. You'd use "Internet Connection Sharing" on Windows 98 SE to share the internet connection on your LAN. And you'd get badly hacked, and then also install a firewall. Sygate had a firewall and NAT combined. (Or, you'd use linux - and also get badly hacked, but for different reasons.)
As a response, ISPs started to ship modems with built-in NATs. They did not start to ship what we now call routers (modem+NAT) because they wanted to encourage people to share their internet connections out of the goodness of their hearts. They'd prefer to sell more cablemodems, or dial-up. They started shipping (NATted!) routers because it saved them a lot of support calls from hacked (and disconnected) customers. Instead they got support calls about port-forwarding, so uPnP was the next hot feature.
Was NAT originally intended to be a firewall? No. Did it effectively protect many innocents? It did. Is it still needed as an additional layer of security-through-side-effects? Let's hope not.
NAT isn't security at all, good or otherwise. If it was sold as such, then the people selling it were giving out inaccurate info. But just because some people wrongly said that NAT provides security back in the beginning doesn't somehow make those claims true today.
This argument boils down to "it's a bad security feature", but that's not what's being argued.
In my experience, consumer grade routers will often happily route packets with rfc1918 destination addresses from the WAN to the LAN interface all day. The "firewall" is only that nobody can get packets with those destination addresses to the home router's WAN interface through the internet. Your ISP can, and in some cases other ISP subscribers on the same L2 segment as your router can.
NAT absolutely does provide good security. It denies all incoming traffic that is not part of an established connection.
Of course, that can be accomplished trivially without NAT. It can be done in IPv4 and in IPv6 with the simplest of routing rules.
So there is nothing about a lack of NAT in IPv6 that makes it less secure.
But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it.
The router will then do exactly the same thing it would've done if no NAT was involved at all: if the dest IP in the packet is the router itself then the router will accept or refuse the connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.
It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.
Yes, but we've just successfully rewritten the article in the comment section as "it's not having NAT that provides the security itself, but other configuration any sane person would expect on a device doing NAT to prevent unexpected inbound connections" is exactly what the article set out to separate.
Fair point!
Yes, of course. If NAT denied connections in the way people think it does, then it wouldn't be necessary to separately configure the router to reject inbound connections. It's possible to have configurations that don't do that precisely because NAT doesn't do that itself.
That makes no sense. If a packet comes into a public IP to a session that doesn’t exist, there is nowhere to forward the packet onto. The public IP belongs to the router.
If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.
There's always somewhere to forward a packet to. The router looks at the dest IP field in the packet header, and that's where it goes.
> If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.
This is generally going to be true, but it's not relevant to how NAT behaves when it receives inbound connections.
I’m not sure you understand how NAT implementations work.
I recommend you setup a basic iptables NAT set of rules on linux to reflect what a home router does (masquerade) with ip forwarding enabled.
The inbound packets from the internet are to a public IP that belongs to the device performing NAT. If there is no entry in the conntrack table from a connection to translate that public IP to a private IP, there is nowhere it can be forwarded to. It’s already at the device that owns that destination IP.
Even if it spit the packet out a private interface (which makes no sense given the routing table), the destination IP would be a public IP that both cannot be ARPed for on the local network and will not be honored by any private device.
I'm reasonably sure I do. I've done that exact test literally half a dozen times now due to people telling me that I'm wrong, and each time I test it turns out that I'm right. What other conclusion am I supposed to come to?
I think it's someone else's turn to do the test now.
> The inbound packets from the internet are to a public IP that belongs to the device performing NAT.
If the inbound packets are addressed to the router, they get delivered to the router. But you cannot just declare that that's where they'll be addressed. You aren't in control of what packets show up to your router, you're only in control of how you process them after they show up.
you missed the part about an ACL. You’re whole shtick depends on a bad implementation of routing rules.
What you’re describing would happen if NAT were completely disabled. You’re just describing an open router
There's no inherent ACL in NAT, and adding one would just demonstrate that ACLs can block packets, which we already knew.
> What you’re describing would happen if NAT were completely disabled. You’re just describing an open router
Yep. It also happens when NAT is enabled. A router doing NAT is exactly the same thing as an open router -- it just has the additional property of editing outbound connections to appear to come from the IP of the router itself.
If NAT on its own blocked inbound connections, I would have seen that in my tests.
[dead]
Not wishing to undermine the central point, NAT for v6 is a thing. The point of the article is that it's not "NAT by default" the way home IPv4 is because so few places worldwide get more than a single IP per customer: The NAT is not there in v4 for security, it's to provide for multiple devices inside the home. Or, in the case of Carrier-Grade NAT, to manage multiple customers, behind a small pool of v4.
NAT doesn't exist to be secure. If it is, (and that is debatable because NAT busting is a thing) then, it's a side-effect.
NAT for v6 is not common. If you use ULA, you'd possibly use NAT for v6 in some circumstances.
https://datatracker.ietf.org/doc/html/rfc6296
Just to nitpick a bit. What people typically mean when they say "IPV4 NAT" is Network and Port translation. My 192.168.0.1 internally becomes 172.217.12.100 and my port gets converted to something that is tracked so that the return packet can find it's target.
In IPv6, Prefix-Translation is similar, in that the /64 prefix is translated 1:1 - but the /64 Host address is (in my experience) left alone - so that renumber a network becomes trivial when you change ISPs - you just just change the prefix.
I don't actually know if "IPv4 NAT" behavior even exists in the IPv6 world, except in the form of a lab experiment.
From my understanding, the "IPv4 NAT" equivalent for IPv6 is generally referred to as NAT66 (NPTv6 for Prefix-Translation). For example, Fortinet offers this on their firewalls, and I believe most firewall vendors have this option.
What they're saying is NAT66 on Fortigates is 1:1 NAT, i.e. prefix translation, not n:1 NAPT, i.e. address+port translation.
I can't imagine why one would ever intend to use NAPT over NAT when the addresses were available though (e.g. on IPv4 where having a minimum of 2^64 public addresses per connection is not assumed), which is the only reason I wouldn't expect anyone to have bothered implementing it. So sure, it's what people refer to on IPv4, but it's not materially different from 1:1 NAT or necessarily adding any additional value.
You can do the many-to-few (or one) NAT behavior with port rewrites in IPv6 if you want to, there are just few circumstances it makes any sense.
FWIW the broad IPv6 network-prefix NAT behavior ALSO EXISTS in IPv4, it's just less applicable.
Why would you not use ULA if you have a network with multiple machines?
[dead]
Discussions about NAT very often forget that it works by messing up with the transport layer. The fuzz is about hiding IP address and exposing services, but the worst thing about NAT is that technically it should not count as a connection to "the Internet". It exploits TCP/UDP properties to fake endpoints into thinking they have a proper connection.
To visualize this, imagine we somehow are out of available email addresses. Email providers have an idea, they would make one inbox for multiple people and have an SMTP proxy that will read the message content, look at "Dear ..." heading and proxy content as new message to "internal" network. All clients would see the same internal addresses from private space (picture 192.168.1.1), but upon sending the provider proxy replaces it adding "King regards, <shared address>". What if someone format the text differently? What if they use new format unknown to the proxy? It just won't work: https://en.wikipedia.org/wiki/Protocol_ossification Someone would then argue it is good as it hides your real address from spam and theft, but we can clearly see the massive disadvantages in this design.
The tension here is the difference between theory and reality. In reality, IPv4 NAT is the only thing protecting most users in their homes. If you force IPv6 on this same population, you have to give them an equivalent posture by default.
This is kind of like writing an argument that motorcycles are not unsafe because they lack 4 wheels. This is true, but if you put my grandmother on one and ask her to drive across town, she would not survive it.
No, the reality is that every modern network device running NAT for a user device network is also already a fully stateful firewall, because the software required to do one is virtually identical to the other.
You can't buy a home router with NAT and no firewall, and no home routers ship that don't also have a default deny rule on that firewall. The same is true for SOHO routers and effectively every consumer network gateway device you might buy.
You literally have to go well out of your way to find a network device capable of NAT that can't function as a stateful firewall, and when you find it, it's likely to be carrier-grade. In other words, not intended to be capable of any security at all. The amount of NAT processing it's intended to handle will challenge the hardware enough as it is.
Nope, I agree with the findings here:
https://arxiv.org/abs/2509.04792?
NAT isn't protecting them. Not being on the public internet at all is protecting them.
NAT is then unprotecting them a little by letting them punch out again. It's super easy for routers to implement this behaviour by default if your LAN is publicly addressable, and removes a whole class of exploits caused by applications making NAT hacks.
This is splitting hairs. The point stands that PAT is the de facto firewall for most soho users.
Not in the context of claiming NAT offers protection.
An ipv6 lan with default ingress deny is more secure than ipv4+nat
I think you missing my point. My point is not that IPv6 cannot be secured, it is that the author's take is controversial because people are skeptical about whether networks ARE being secured when NAT is not present. This skepticism is backed up by the research paper that I quoted and real world experience. IPv6 is deployed in many places incorrectly and without the good defaults. IPv4 NAPT in residential networks acts as a last line of defense because most users have been incapable of turning it off.
I suppose I will distill my thought into the assertion that the author should have prefixed his title with "In capable hands,"...
The point is that NAT offers no security, so it doesn't make sense to be skeptical about the security of a network just because it doesn't have NAT.
The only way to be confident is to have a firewall, and you can do that on v6 just as well as you already do on v4.
France with >85% IPv6 adoption mostly made of grandmothers driving a motorcycles across the town manually delivering packets like in their youth.
https://arxiv.org/abs/2509.04792?
"Collectively, our results show that NAT has indeed acted as the de facto firewall of the Internet, and the v4-to-v6 transition of residential networks is opening up new devices to attack."
ISP hosting a virtual machine you remote desktop into from internal network as the only way to access the external internet can also work as a "de facto firewall".
But the best de facto firewall is a proper firewall.
I don't disagree with your comment that the best de facto firewall is a proper firewall. I think you are reacting against the idea that I am saying IPv6 is less secure than IPv4. I am not saying that.
The point of my original post is that the author's take is controversial because people are skeptical about whether networks ARE being secured when NAPT is not present.
They are right to be skeptical, in my opinion, because the rollout of IPv6 has been bungled over and over again. That is not a problem with IPv6, its a problem with the adoption of IPv6.
This is entirely untrue. Every shitty router shipped by ISPs this side of the doctom bubble has a stateful firewall enabled by default. NAT is distinctly not the only thing protecting most home users. Not to mention every OS I know of shipping with its own firewall enabled with default deny on inbound.
You are stuck on the theory of what is protecting this population. In practice, less than 1% of these users can or will turn NAT off.
Can you imagine how great things would work out with a public IP on all your nana's computers, NAT turned off, protected by the prowess of her Arris gateway's stateful firewall?
Telstra, one of Australia's massive telcos who are the "go to" telco for nannas who don't know anything about this internet thingy, have IPv6 enabled by default on their CPE routers. Without NAT. With a stateful firewall. Works perfectly fine for their millions of customers.
It would work out just fine, because NAT was never providing any actual security to your nana. It was only ever the firewall which made her secure, not NAT.
With NAT turned on nana's computer is still protected by the same Arris gateway.
That's not the case at all. You could disable their NAT and they wouldn't lose any protection whatsoever.
Yes, it is the case. In the real world, there are malfunctioning ALGs, permissive defaults, and connectionless protocols that are poorly tracked by these sloppy, underpowered "SPI" devices.
It's not, because in the real world NAT only affects your outbound connections. That means that turning it off only changes the behavior of outbound connections, not inbound ones.
Any inbound connection that would have worked before you turned it off will still work afterwards, and any that wouldn't have worked before will still not work afterwards.
Think about what 99% of SOHO users have: PAT (Nat Overload). This NAT impacts the way a connection is established in BOTH directions. Inbound connection attempts from the Internet to the NAT public IP address of the SOHO router can go no further than the router. We are talking what 99% of users have installed.
Maybe this is the reason for some of the disagreement. I am focusing on what is installed at 99% of user installations (PAT). I would agree with the comments that a 1-to-1 NAT offers no EXTRA security.
That's the type of NAT I've been talking about the entire time. It doesn't do anything to inbound connections unless you explicitly tell it to.
Connections to the router's IP address go to the router, but you need to consider what happens to connections that go to IP addresses on the network behind the router too.
[dead]
I think two things can be true here: the article's assertion that "IPv6 is not insecure because it lacks NAT" is correct, and other peoples' assertions that NAT provides an extra layer of security are also correct.
A correctly configured IPv6 firewall provides equivalent protection to a correctly configured IPv4 firewall and NAT. Either way, connections that do not originate from within the local network are going to be rejected.
But if the firewall is misconfigured, then NAT will make it more difficult for an attacker on the internet to discover and exploit vulnerabilities on the local network.
"Defense in depth" is a valid security principle. But NAT also creates real-world problems that IPv6 solves. As with all things, there are tradeoffs, and whether or not you should enable IPv6 on your local network depends on your use case.
Ipv6 also creates real world problems that NAT solves -- multi upstream WAN with path selection for example
Dual stack introduces security problems (you now have two things to secure). There are still devices which will fail to run on an ipv6 network -- even with a 64 gateway (software which communicates to a specific IP address for example - e.g. a device which "checks internet connectivity" by pinging 1.1.1.1 and 8.8.8.8, yes it's terrible, and yes it happens)
IPv6 without NAT is not insecure; I can and do have a stateful firewall that denies unwanted inbound connections. But it does not matter if my auditors think otherwise and the whole Internet tells me that arguing with them will end my career.
[dead]
I find the discussion about whether or not NAT is a security feature or not interesting. To my mind NAT was intended to make ipv4 last longer in a clever way as address space dried up. A happy accident of this solution is a basic security feature.
Ipv6 doesn't (currently, will it ever?) have the same address space problem so each device anywhere could be globally routable. But we know that's not really a good thing security-wise. But why couldn't we implement NAT for it as a security mechanism, instead of an address space solution?
Admittedly I'm not expert so I might be talking shit.
You said it yourself. NAT was introduced to solve the address space issue. At that point firewall were already a thing.
You also acknowledged correctly that IPv6 Will botnrun into the same address space limitations.
You said NAT is not a good thing Security-wise. Then you follow up the question, why we shouldn't add that to IPv6 as a security feature. It's hard to understand the train of thought.
So let me answer this. While NAT incidently does something similar to a firewall, it is not a security feature. NAT must track any outgoing network connection in order to understand where to route incoming packets. If a packet it not a reply to an established connection, it is dropped. Otherwise the NAT must look up who opened the connection. A NAT can only work if stateful.
In a routable connection, ALL of that can be based on the static routing table.
Imagine a university with 10,000 computer, all of them having opened maybe 100 concurrent connections. The NAT must track every single connection and do a lookup for every packet.
In a routable network, it just looks up the destination IP in the packet and sends it to the next hop for the destination IP.
All while hopefully a firewall is in front of it.
So why would you want to reintroduce NAT to IPv6, when both issues are efficiently solved already?
Why would you do that when a regular default-deny firewall is and has always been the security feature you need, without the complications and problems of NAT?
Like I said I'm not expert, and was likely talking shit. I was just speculating based on the discussion in this thread.
I think the complications and problems of NAT seem to add a default layer of security to the whole thing. I know next to nothing about firewalls though, which might be the point here, but would a default deny present any problems for me that NAT would allow? That is is there a situation where as a layman I might run into problems receiving data for a valid process that wouldn't happen if it was just NAT?
A firewall is the security feature you want. With a default-deny rule, which most will come configured out of the box with, it does exactly what you expect: block all unsolicited incoming traffic.
Most people are probably actually running a firewall with NAT anyway, they just don't know it because an appliance with default-deny is pretty much install and forget for most people. So, no, it doesn't cause any additional problems.
The only difference with IPv6 is you don't need to NAT any more, but you keep the firewall.
It's important to remember NAT is part of the IP routing layer. In its regular form, a router just forwards packets to where they should be going. So it's plugged in to one or more networks, receives packets on one interface and forwards them, unmolested (well, mostly), to another interface. It's almost completely analogous to letters going through the postal system. The postal service just forwards letters around by looking at the address. It doesn't modify them in any way.
NAT is a bastardisation and is like your postie scribbles out the "return to sender" address and replaces it with his own. If you were to reply to that address, your postie would remember he did that, and replace the address you wrote with the original address he scribbled out earlier. It's not how IP routing is supposed to work at all and, in fact, a device doing NAT cannot strictly be considered a router at all.
Something you can add to any device is a packet filter. A router must not filter packets as it then wouldn't be considered a router (similar to molesting the packets with NAT). But you can insert a packet filter before things get to the router. If you glue those two things together and bundle it in one device then, voila, you have a firewall. A stateful firewall is conceptually like a packet filter and router glued together and working closely together. But you can just think of it like telling your postie "I only want to receive letters from mum" and he just burns all the rest before they get to you front door. (In reality you also want to allow correspondence so it's more like "only allow letters that are replying to letters I sent, which you'll know because you're my postie, or if mum sends a letter first, allow that too").
Writing this up makes me think... why don't we just teach this stuff using the postal system as an analogy? It's an almost perfect analogy and surely even today anyone understands this concept.
I'm on ipv6 since 2 years and I am very happy.
I profit from NAT-less network, can connect to my home device from a VPS without thinking it's sitting behind 2 routers. No port forwarding needed, just connect and it works. Well, I guess I still need to enable connection to this device on a firewall, but that's obvious.
We really should move on from IPv4.
By the way, IPv6 also supports NAT if that's what you want. But using NAT in IPv6 is like saying "i want to have my own personal universe so I can put 2 Raspberry PIs in it".
NAT is just one slice of IPv4. Granted your private IP is not routable (with CGNAT now your gateway is also no longer routable), but think of other features of IPv6 that are congruent:
SLAAC basically means your routable IPv6 address changes so many times in a day (and there are multiple of those at any given instant) that even if the attackers know your prefix, its going to be very difficult to do anything meaningful. the address space is too big.
And we are assuming here that there is no firewall.
Note : macOS firewall on a new install is disabled iirc.
[dead]
Right, IPv6 is annoying because it lacks NAT. There's a big difference between something being a huge pain to deal with (IPv6) and being insecure.
Ok, I'll bite: why do you say that IPv6 lacking NAT (which is not true by the way) would be annoying? We can finally get rid of an ugly workaround from 30 years ago that broke one core principle of the Internet (end-to-end connectivity) and a ton of protocols that required even uglier hacks (FTP and SIP ALGs, TURN/STUN, etc.) to barely work. Why would this be annoying?
At my previous place IPv6 was useable (I was getting /60 prefix rather than /64 I’m getting now) but the prefix was changing often - several times per day. This was annoying because every prefix change all addresses of my devices changed too. So in practice I always used private IPv4 addresses to connect to them. A NAT would solve this issue.
Well, delegated IPv6 prefixes are supposed[1] to be static or somewhat persistent, but some ISPs do this, yes. This is most likely a practice carried over from IPv4 where there is a small pool of addresses. Fortunately in my experience it's not too common: most ISPs that deployed IPv6 did it the right way.
Anyway, to get persistent addresses you can set up a ULA prefix (the equivalent of RFC 1918 addresses) and a simple prefix translation[3]. This is a form of NAT, but unlike the usual IPv4 NAT (actually NAPT) it doesn't deal with ports, so it's slightly less annoying problematic. There also are a few more techniques, like using mDNS and writing firewall rules that match the suffix of the client addresses, but not many CPE allows for this.
[1]: https://www.ripe.net/publications/docs/ripe-690/#53-why-pers...
[2]: https://en.wikipedia.org/wiki/Unique_local_address
[3]: https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6
You don't need prefix translation to use a ULA prefix. You just configure both the ULA and the ISP-delegated GUA prefixes simultaneously.
Right, the ULA prefix theoretically has lower preference, so it should only be selected to reach hosts in the LAN and the GUA for everything else, but I don't know how well softwares handle this in practice.
Source address selection is usually left to the kernel, so that part should be okay. It'll pick a GUA source for a GUA destination unless you've changed the labels with `ip addrlabel`.
IPv6 doesn't "lack" NAT. There is nothing preventing you from using ULA addresses inside your network (IPv6's version of RFC-1918) and then running NAT for those addresses on your router. IPv6 just doesn't _need_ NAT, but it is still an option.
I just want to go to my devices and set an easy human-readable address. I don't want to setup ULAs.
fd00:1337::1, here you go! This address is the equivalent to a private IPv4 address and human-readable.
IPv4 is not secure because it requires a NAT in order to be?
Big centralized online services does not want IPv6 because it "unlocks" internet as intended, full p2p at scale. They won't let that happen easily.
And please stop with that 'computers security', we all know here it does not exist (NAT or not), it is a fantasy. Saying otherwise is engaging in bad faith.
> And please stop with that 'computers security', we all know here it does not exist (NAT or not), it is a fantasy. Saying otherwise is engaging in bad faith.
So you are willing to message me your credentials then?
Bad faith using a deviation on "social engineering", unrelated here.
NAT is not inherently a security feature, however where NAT happens is somewhat important.
A local router that I can control deals with how to map from my public IP to my private IPs.
This is not security but is obfuscation of the traffic.
Obfuscation becomes almost impossible in the IPV6 context where NAT isn't necessary, it becomes optional, and given the likely trajectory that option will be exercised by sophisticated enterprise customers only.
As the article mentions, if you want to use NAT with IPv6, you can. The fact that it's optional doesn't mean that address obfuscation is suddenly impossible.
It means it is not by default, which as we know, is a powerful choice these days.
ie enterprise customers will enable it, consumers will do it if they are tech savvy and your mom/dad/granddaughter/grandson/nephew/niece will have the default option.
when you are at home you will have nat and when you are not you will be uniquely identified.
If you can be uniquely identified without NAT then you can be uniquely identified with it too, because IPs don't contain your identity. You get them from a combination of the network prefix and a random number generator.
There's generally no reason to be enabling NAT when you have enough address space to not need it. It can be a useful tool in your toolbox sometimes, but it's not something to be enabling by default.
Networking folks love to write this article. “NAT isn’t a security layer.” I’ve been hearing it for 20 years. But while that’s not its purpose and while there are other layers that can provide the same features, it’s still a very useful piece of a larger puzzle of defining borders in a network architecture. Sometimes it helps if those borders are obvious to the eye, via the use of a private address zone, or if opening a port on the server can never “just work”, regardless of your external firewall rules. All sorts of trivial mistakes can be avoided with This One Weird Trick. So sure, it’s not technically required, and doesn’t solve every problem. But the constant harping about “NAT isn’t security” is sorta pointless.
I hate NAT with a passion. It's a terrible technology, whose disruptive nature has probably prevented any novelty on the transport layer. But this article is oversimplifying things.
It is well known that NAT is not meant for security and that NAT is not a firewall. But one cannot deny that it implicitly brings some "default" security to the table. With NAT it's basically impossible to screw you over because there is no meaningful practical way to allow inbound connections without the client explicitly defining them (port forwarding). With IPv6, you could have a lazy vendor that does not do any firewalling or a has a default allow policy or maybe buggy firewall. With NAT that is not possible. There is no lazy/buggy NAT implementation that allows inbound connections for your entire network, because it is technically not possible. When a NATting device receives a packet with a destination port that has not previously been opened by a client, it does not decide to drop this packet because of a decision by the vendor. It drops the packet because there is simply no other option due to the nature of NAT. That is what people mean when they talk about the inherent "security" of NAT.
Again, NAT is terrible. We need to finally get rid globally of IPv4 and all the NATting that comes with it. But let's keep it to the facts.
> there is no meaningful practical way to allow inbound connections without the client explicitly defining them
This... just isn't true though. Your router knows it has one network on one interface and one network on another interface and if it receives a packet on the one interface destined for the network on the other interface will happily route it unless something (a firewall) tells it not to. All the protection comes from trusting your ISP and its peers to not route RFC1918-private networks
Obviously the two aren't the same (especially given the need to do routing), but I've always found it amusing that in the systems world, capability-based systems (i.e. making it impossible to address things you aren't allowed to access) are gaining traction while the philosophy in the networking world seems to be going in the opposite direction (make it possible to address everything, i.e. IPv6 vs. NATted IPv4, then add filtering).
> NAT isn’t actually a security feature—it’s an address conservation mechanism that became necessary because we ran out of IPv4 addresses.
> But the security benefits people attribute to NAT actually come from the stateful firewall that’s typically bundled with NAT routers.
1. It requires a stateful firewall.
2. It isn't possible to accidentally a default-allow rule on that firewall.
It may not be intended as a security feature, but it can't not act as one in practice.
No, NAT requires state tracking, not a stateful firewall. If you want a firewall when NATing, you have to configure that separately. You can absolutely NAT without a firewall, and it won't act like one by itself.
>NAT isn’t actually a security feature
Perhaps not in the high brow network security world, but in practice it really is used that way.
Who here has never launched an unauthenticated server on their LAN?
When I was about 12 I was working on a PHP3 application, I had some issues with a MySQL query, and I pasted my code to pastebin (or whatever we used back then) and shared the link on IRC, the code included my database credentials.
Back then our ISP gave every computer a public IP.
The next thing that happened was that someone changed my MySQL password, and me being 12, I didn’t know how to change it back.
They made me beg for the password, to much amusement to the whole channel, and then they helped me secure it and taught me how to reset the password.
NAT would have saved me, but I wouldn’t have received a free, though a bit embarrassing, security lesson.
That's what the firewall on your router is for. NAT might also stop someone connecting, but it's not a guarantee. You can get given a public address and be exposed, you can find out your server actually does UPNP automatically and so is exposed, etc... a firewall is more explicit and a better defence.
That's a strange example. An unauthenticated server on a LAN wouldn't be exposed to the Internet any more than a network using NAT would be. You would need to explicitly configure your routers firewall to expose a local node, the same way you would need to explicitly configure port forwarding with a NAT based network.
I've see some argue that a hypothetically buggy router would somehow be less likely to fail if NAT was used but really, that could be equally said about bad port formatting defaults, which have in fact happened. Complexity is what increases the likelihood of bugs at the end of the day.
NAT is just an addressing hack, a weirdly complex way of indirectly routing to local addresses. It only influences what is written on the envelope, not how that envelope is processed at the post office.
What does NAT do for security that a firewall doesn't?
If you do not have any communication though this firewall - nothing. But then why having a connection in the first place?
Of course it's not insecure because of NAT.
NAT (in all its forms) is just a very convenient technology for many people and niche situations.
And adoption of IPv6 will be hindered as long as NAT is not a first class citizen.
And of course, mostly NAT should not be used as "firewall replacement". But what many firewall proponents forget here:
NON-IT People at home cannot run and manage a firewall (and proxies). For them, NAT is a convenient and mostly okayish replacements.
Another niche would be IP Packet Handling of VMs.
We haven't forgotten that, but we're also aware that non-IT people can't run NAT either. They can plug in a box that already has NAT configured though, and if they can manage that then they can also plug in a box that already has a firewall configured.
VMs work fine without NAT too -- DHCPv6-PD lets the VM software automatically request a routed prefix.
With IPv4, if NAT isn't working right then I simply cannot get online and I need to fix it. Fail safe. With IPv6, when my computers being globally addressable is the norm, if my firewall is misconfigured my computers will probably still be online. Fail unsafe.
Arguing this is pointless anyway because it's not even my decision, it's my ISP. I am however quite happy with my ISP's choices in this regard.
Maybe it’s because I don’t consider myself a super technical person, but I find it so hard to parse the title of this blog post. When I first read it, I thought it was saying something like, “The protocol is not insecure, and the reason is that it lacks a NAT”. However, after reading the blog post, it seems like it is intending a different meaning. The meaning I think is, “the protocol is not insecure just because it lacks NAT”.
The lack of NAT has no bearing on security. Despite an old mistaken belief.
Defence in depth is a valid security approach, and NAT provides another defence in depth
If you have a vulnerable ipv4 machine on 192.168.0.24 port 2345 which is hidden behind a public IP of 1.2.3.4, and you set your firewall rule to allow any inbound traffic, with no nat rules then it will be exceedingly difficult for a remote attacker to reach that vulnerable port (they have to trick your router's connection table into routing it)
If the same machine is on 2100:1234:5678:a::24 then that port is exposed.
Now sure your firewall could block the traffic, and that's great. But having multiple layers of active configuration to allow the traffic through is more secure than having a single layer as it means you need to screw up twice.
Worse than that with dual stack you may think you have set your firewall to block non-established connections at the ipv4 stage, but your device is sat there on an open ipv6 address you didn't even consider. Dual stack is certainly less secure than single stack as there are two opportunities to screw up.
It’s the same layer. On router admin panels it’s literally the same UI for firewall rules and nat port forwarding. If you went in to your router admin and allowed all ports on v4 it would be exactly the same as allowing all on v6. The router will happily forward all connections to v4 devices the same.
> If you went in to your router admin and allowed all ports on v4 it would be exactly the same as allowing all on v6. The router will happily forward all connections to v4 devices the same.
Forward to where?
You have to actively say "forward port 80 to 192.168.0.2". Port 80 can't be forwarded to 192.168.0.2 and 192.168.0.3.
Where allowing all traffic means you can talk to 2100:xxx::192.168.0.2 and 2100:xxx::192.168.0.3
Yes, you can't expose multiple computers at the same time on v4, but you certainly can expose one, in exactly the same UI you exposed v6. And then that one you exposed has full access to the local network beyond the firewall to expose the rest.
The argument seems silly almost like "I deliberately shot myself in the foot, but with v4 I could only shoot one foot at a time while v6 lets me shoot both". The answer is to just not shoot yourself in the foot, since you have to make a deliberate effort to do this in the first place, just not doing that is the answer.
NAT is a trivial feature on top of a connection tracking firewall. It also provides a large number of benefits - the ability to route traffic via different routes with PBR, without having BGP upstream, to keep routing decisions in the router rather than on each device, to not have to renumber internal IP addessing when the ISP changes, to have consistent view of what happens at a network level
I think there's a philosophical difference between IPv4 and IPv6.
IPv4 is from the era of local computer networks, which feature clients and servers. Clients talk to servers, but servers are not supposed to care or even know about clients unless clients decide to reach out to them. Client-to-Client communication is generally discouraged. The IP address is just a technicality and outside of local networks, just a part of the routing strategy.
IPv6 on the other hand is like an URL - an address you can use to find any device from anywhere on the planet. It makes no distinction between client and server. Which is why its pushed in places like IoT and smartphones - a voip call has no conceptual client and server.
One could make ones smartphones Ipv6 address openly available, and anyone could initiate a voip call to their phones. Would this be wise? I'd argue there's no scenario under which this doesn't cause an unacceptable level of risk, as even if the software is perfect, they'd be still vulnerable to DDOS attacks.
This means that NAT-equivalent firewall rules are necessary, which makes the whole discussion kind of moot, but it's not a good portent for Ipv6 that it makes previously unfeasible kinds of attacks potentially practical.
NAT also allows for other neat tricks, like IP level load balancing.
I'd say one huge and unambiguous advantage of IPv6 is that it makes UDP trivial.
> IPv4 is from the era of local computer networks, which feature clients and servers.
IPv4 on the ARPANET 'went live' in January 1983,[1] but the concept of a firewall didn't really happen until about a decade later (with some protocols having to be altered[2]):
* https://en.wikipedia.org/wiki/Firewalls_and_Internet_Securit...
Some of us still remember open (SMTP) relays and the openness of the early Internet:
* https://en.wikipedia.org/wiki/Open_mail_relay
IPv4 has always not been only about local computer networks: end-to-end connectivity was there at the start and only got choked off later.
[1] https://en.wikipedia.org/wiki/Flag_day_(computing)
[2] https://datatracker.ietf.org/doc/html/rfc1579
> IPv4 is from the era of local computer networks, which feature clients and servers. Clients talk to servers, but servers are not supposed to care or even know about clients unless clients decide to reach out to them. Client-to-Client communication is generally discouraged.
No, it was meant to be a global address space where anything could talk to anything. That became unworkable due to scale and the limit inherent in using only 32 bits for the address space.
Some older protocols (ftp) don't play nice with NAT and need special handling, because address multiplexing was never intended to be a thing.
I could get behind this argument if commodity ISP gateways required special rules for IPv6 (from what I have seen - they do not).
As far as I can tell, this is just pedantry, until those features are implemented in most ISP gateways. Akamai has been warning that IPv6 scanning attacks are on the rise.
Maybe someone knows better than I about this.
I'd argue not about security, but transparency - when having your mac address partially included in the IPv6, you would basically allow browsers and other systems identify you without additional steps.
Sure, but your MAC address is easily spoofed. In fact, all major operating systems do it nowadays for public WiFi systems and you have to explicitly opt-out of randomising your MAC Address when connecting.
Still it's really convenient to be hidden behind NAT not being unique in the constantly-growing list of gathered data
[dead]
No one's complaining that IPV6 is insecure. It may as well be very secure, but no one bothers to understand it if they're not paid to do that.
Of course you can have default drop in your IPV6 firewall, but it's far easier to keep in your head that internal NATed IPs aren't accessible and "real" IPs are.
I've seen plenty of discussions here on HN where people have made that claim. Even more elsewhere on the discussion side of other news websites by sysadmins that disable IPv6 because one of their industrial routers didn't come with a default deny rule that one time which made them think that's normal.
The people who are supposed to know IPv6 never seemed to have learned it and many of them don't seem to be open to the idea of learning something new. Of course half the world runs on IPv6 now so they'll have to get with the times eventually, but the prevalence of statements like these is quite depressing.
> many of them don't seem to be open to the idea of learning something new
To the idea of learning something designed by commitee, over complex and stinking of enterprise and that you simply can't deploy "by hand".
One of the advantages of NAT by the way is that your "outside" configuration and "inside" configurations are completely independent with the exception of the snat rule.
The "inside" is your /56 or /48. You can add more local-only "inside"s if you'd like, which is useful for terrible ISPs with rotating network prefixes. The "outside" is everything on the internet.
If you can make your way through the absolute slog that is ARP+DHCP, you can get through NDP+SLAAC. Or even NDP+DHCPv6 if you're a control freak.
> One of the advantages of NAT by the way is that your "outside" configuration and "inside" configurations are completely independent with the exception of the snat rule.
If you want NAT, then set up NAT. Your fdb6:fc49:f5ae::/48 ULA is your 192.168.x.y address. Set up DHCPv6 if you'd like to pretend you control your address space. You could even just ignore the spec and use fdfd::/48 as your ULA so you can memorize addresses (fdfd::1, fdfd::2, that's even shorter than 192.168.1.2!). Use fe80::1 (a perfectly valid address) on your router as a standard gateway and have it do NAT to the outside world.
Even though it's heavily discouraged (because NAT is a massive hack after all), you can do NAT on IPv6 without any special tooling.
> The "inside" is your /56 or /48.
No it's not mine. It's the ISPs.
> which is useful for terrible ISPs with rotating network prefixes
... which is what you said :)
> If you can make your way through the absolute slog that is ARP+DHCP, you can get through NDP+SLAAC. Or even NDP+DHCPv6 if you're a control freak.
Oo enterprise. I believe you missed another 5 or 6 acronyms that are also required for having ipv6 internally.
> Oo enterprise. I believe you missed another 5 or 6 acronyms that are also required for having ipv6 internally.
It's not 2010 anymore, IPv6 works internally out of the box. If you don't know what ARP means then you will have no problems using IPv6.
> IPv6 works internally out of the box
Works if you rely on the ISP provided box?
And why pick on ARP and not on SLAAC, NDS, DAD, RS, RA... ?
Been running IPv6 for years on both my home network and internet servers, and I've never had to think about NDS, DAD, RS. SLAAC is something I've only had to think about once at network setup time, less than I think about DHCP on my IPv4 network. RAs I have actually had to think about because Unifi has had some regressions in IPv6 support over the years, but that's fixed these days so it's likely going into the "don't need to think about it" bucket too.
Of course I'm sure you think about DHCP address management, DHCPDISCOVER and DHCPOFFER packets, mDNS, ACD, etc., since clearly you like to get into the weeds of your network
> you like to get into the weeds of your network
I have to because I have two fiber connections to the outside world :)
Nothing fancy like automatic failover or load balancing, they're just there.
With ipv4 i change the default route on a machine to the internal IP of one of the ISP provided routers, that one NATs it and i'm all set.
With ipv6 that insists on giving me an ISP assigned address internally, what do i do? It only works with that particular ISP. I'd still have to NAT and somehow disable the ISP addys, if i even can.
I suppose a $3000 Cisco box will solve all my problems, wouldn't it? Or maybe a $3000 + 150/month support contract? If Cisco even bothers for that little.
A $60 MikroTik hEX refresh will also solve your issues.
I always disable ipv6 on all devices first because there is no point in using it.
it's faster on most networks
I’m not using any networking implementation that’s less tested and ipv6 is less tested. Network routing means there are dozens of TCPIP implementations touching traffic. The benefit of ipv6 for my case isn’t worth the risk. If you’ve never run into an ipv6 specific bug good for you.
How is nearly 50% of modern Internet infrastructure not well tested enough? Also, IPv6 is not an implementation by itself.
> Network routing means there are dozens of TCPIP implementations touching traffic.
One reason why routers should not fiddle with TCP and stay on IP layer.
> IPv6 is not an implementation by itself.
I’m not sure what you mean by this. In other words, there is code that is specifically written for ipv6 handling which in some cases isn’t tested as thoroughly as ipv4. Less of an issue as ipv6 adoption grows but it’s non zero. I don’t like the address format, I prefer NAT by default, routing by prefix, like everything ipv6 offers I don’t feel comfortable with even without that. But it’s the most technical reason I don’t like it, the rest is a personal/vibes thing.
As someone with limited networking knowledge, I’m not really getting smarter here. Some say it adds security; others disagree. Let me ask this: does IPv6 benefit me in any way if I have multiple devices at home behind a router and I'm not running any servers or similar services?
No idea what you're doing on a daily basis, but let's grab a not-exactly random example. You and your friends are at your house trying to play an online game of King's Court (it's super checkers!) with some friends in Denmark. For whatever reason the developers decided all clients will use port 12345 to communicate. In ipv4 with NAT, local connections will be possible but only the first one to try to communicate out will ever possibly succeed. You and your friend are thwarted and have to find some NAT-defeating means or just give up on doing 10-jump moves to ruin each other's evenings and have an internet drinking game. With IPv6, all of it works fine.
Most casual users have lived with NAT so long they assume its limitations are natural. But they are not. You can achieve the same result with a firewall or ACLs or whatever on ipv6, but that's a choice and not a limitation.
Do you play video games with P2P networking? Then your choices are to pick one of the following:
- the hosting player enables upnp
- use ipv6
- the hosting player manually sets up port forwarding (consumer routers often talk about a DMZ option which takes an IP address - really this is just forwarding all ports not matched by any other rule)
STUN
Smart home and lighting standard Matter over Thread requires it. Discovered this after i bought some Ikea smart lights. Though you don't need a public IP6, a local static IP6 with SLAAC is enough.
No
I wrote that comment, and you can write to yourself how many times you want that NAT is not a firewall.
The truth of the matter is that NAT absolutely _is_ a firewall in _practice_. Not in theory "because it doesn't drop packets" or "because it was not meant to be a security feature". But in the actual real-world practice.
It effectively protects most networks from most attackers without ANY additional configuration, making it inherently foolproof.
Here, I put a private key for a wallet with 0.01 bitcoin at this address: http://192.168.80.26/ Go on and take it. It's not protected by anything else I disabled everything but NAT. Heck, here's my real IPv4 even: 172.56.107.111
Is this a _good_ reason to not do IPv6? No. But it absolutely _is_ a reason and needs to be acknowledged.
If you don't have RPF enabled on your router in theory your upstream peer can send traffic to 192.168.80.26 and it would pass through. Reply traffic may or may not be natted depending on how it's entered in the connection tracking table.
There may be situations where your router can be tricked too, I can't think of one off the top of my head which wouldn't also apply to a stateful firewall sitting on a routed network segment with no nat, and it would typically be a vulnerability to patch
But your principal is right -- it's far harder to exploit than just connecting to an ip of say 2001:172:56:107:111::192.168.80.25 on port 80
For 99%+ of residential users, the upstream peer is the router owner/operator, so they can just direct the router to hack you if they wished. So this NAT "vulnerability" is not useful in practice, since it can only be used by your upstream which already "owns" you.
Yes, the upstream can hack my private wallet. But it's a CGNAT device somewhere in the TMobile network, and hacking it is not at all trivial.
And it's true for most NAT users. Even with the cheapest possible devices.
Of course, in practice most NAT devices _are_ firewalls because they do block incoming packets that are not a part of an established connection. After all, it adds only an insignificant overhead because a NAT device has to track connections anyway.
With IPv6 this is not the case. A router with misconfigured connection tracking will still work. And I actually have seen this in practice on a device that had a missing IPv6 conntrack kernel module.
RPF wouldn't help, because the reverse route for 192.168.80.26 is going to be the LAN interface, not the WAN interface. You need a firewall.
> The truth of the matter is that NAT absolutely _is_ a firewall in _practice_.
No it's not. NAT is not ever a firewall. By definition it is not.
What is the definition of a "firewall"?
And it doesn't really matter. You can call it "alksjfaliskdfgh" if you wish. The fact is, NAT adds a security barrier that is incredibly effective in practice.
But it really doesn't. If you turned off NAT your computers would have the exact same security as they do with NAT.
Wrong. If I turn off the NAT on my router, my computers will not be able to get online. If I turn off the IPv6 firewall on my router, I won't see anything unusual.
And yes, this has happened to me when I forgot to compile the IPv6 conntrack module.
I didn't say they would have the same capabilities, I said they would have the same security
Security is a state of mind. So, whatever makes you feel secure, it's your security tool. NAT can be used for security, like VLANs gets a lot used for LAN security. And BTW, NAT can alter destination of IPv4 packet, but also the source. Which is not necessarily only masquerading, and it's seen a lot as embedded security, especially for home Internet. A firewall does not provide security by itself, it has to be configured in the specific way for the situation. I've seen a lot of firewalls with 100s of rules, but the first one was accept all forward, forgotten there by an admin after a test several days/months/years ago.
We are trying too much to put things in unique and well defined boxex. Universe does'n work like this. Security is just a state of mind.
If IPv6 is behind firewall, apps can't use it for P2P connections, so the major point of IPv6 network becomes moot.
And IPv4 NAT is actually possible to penetrate sometimes. So for some networks, IPv4 provides better P2P connectivity, than IPv6.
Not really, look at a great post on Tailscale blog how such P2P connection can be established: https://tailscale.com/blog/how-nat-traversal-works
With IPv6 you might have to use a hack to make firewall allow incoming packets (like sending a dummy UDP packet to the peer first). The firewall only read, allow or deny these packets. While NAT must mess with the message IP//TCP//UDP headers to work.
[dead]
The is a huge difference between: I assume my crappy router's firewall works and is configured safe by default. And I assume my crappy router's doesn't forward ports by default.
I actually wanted to write this article myself but every time I started writing it up I thought "fuck, this is too obvious, I'm being condescending". But then I read these comments and I'm sad again.
So with IPv4 with NAT you definitely have this security. According to this article with IPv6 you MIGHT have that security -we don't know. That's not secure.
Also with IPv6 with NAT you definitely have this security, but with IPv4 without NAT you MIGHT have that security...
Disabling security features makes them disabled. Also security of NAT is a side effect because of that the devices behind it are not connected to the internet just tricks them into thinking they are.
It's wild because saying that NAT is required kind of admits your machines are vulnerable on the LAN! You should have good firewall rules no matter what.
Agreed with the main message.
... but
An incoming message to an IPv4 NAT router will not be forwarded to a LAN device unless it matches a known flow (typically continuation of a conversation, typically initiated by the LAN device, which is expected), or the user set up a DMZ forward to a particular destination. There is actually no reasonable way for non-DMZ LAN devices to be exposed to the noise.
For non-NAT IPv6, sure a firewall might be on by default, but it can be turned off - and therein lies the potential exposure to every LAN device to directed traffic.
In other words, the risky zone for IPv4 NAT tends to be setting up a DMZ exposing 1 device, while the risky zone for IPv6 non-firewalled tends to be exposing all of the devices behind the router.
Disabled protection does not protect. This is UI/UX thing, not something in Internet-scale protocols. I can "curl https://somethingshady | bash -" but won't blame RFC1738.
There's no such thing as secure or insecure, only more secure or less secure.
nitpick on the title, the way it's worded makes it sound like "IPv6 is not insecure because it lacks a NAT, (but it's insecure because of other reasons)".
would be better if it was "Lacking a NAT doesn't make IPv6 insecure".
Is it fair to say IPV6 with ULA (Unique Local Addresses) is best of both worlds?
I don't understand, after all this time, why ipv4 still dominates
Security is not a binary. NAT is (slightly?) more secure.
Carriers dropping legacy IP network and providing only direct connection to few popular CDNs would be natural next step for this security strategy.
I have yet to see a "NAT is not security" rebuttal that does not make either one or both of these points:
- NAT is not a security feature because it wasn't designed as one (this post), and/or
- NAT is not a security feature because it does not, without a firewall, protect against an attacker on the WAN subnet, or another difficult-to-exploit scenario.
And yet making LAN devices unroutable from the Internet does on its own makes exploitation much more difficult. It's admittedly not a perfect measure, but it's one that IPv6 deployments with routable addresses for LAN devices lack. I would wager this does make a difference in the proliferation of botnets, especially given the lackluster standards of consumer network equipment security.
You should read my other comments on this post. I've attempted, multiple times (but apparently without much success) to make the point that NAT is not a security feature because it does not, without a firewall, protect against an attacker.
You don't need a qualifier like "on the WAN subnet". It just doesn't do anything to protect you from inbound connections at all.
I think you're not technically wrong, but you're defining NAT differently than the majority of people you're arguing with (those who assume NAT also implies a firewall blocking inbound connections), and the remaining minority (the "on the WAN subnet" crowd) are dismissing outright the idea as a reasonable attack vector that an attacker close enough to be able to send packets destined for non-internet routable addresses to your router.
Is the latter something that was/is actively exploited?
There's an implicit trust of ISPs in the comments that I find concerning
NAT's only functions are:
- share a precious IP address at the NAT gateway border
- hide your internal LAN from external network mapper
Last point becomes moot when internal mapping software kicks in, legitimately or not, JavaScript or disingenuous application/daemon/app.
Welcome to Cybersecurity SecOP.
Now this is where Carrier-Grade NAT really shines: added functionality of handling mobile devices' changing IP addresses as it hops from one subnet to another (switching between G5/CSM/WiFi/personal-hotspot)
> handling mobile devices' changing IP addresses as it hops from one subnet to another
We could create TCP/UDP alternative that would handle mobile IP addresses or even make traffic take multiple of those paths at once (look up MPTCP). But we cannot apply it in real scenarios mostly because of middleboxes (like CGNAT) messing up and limiting the messages that should be taken care of on the endpoint.
This article may have been prompted by my (or similar) response to John's comment on [1] yesterday.
He stated:
> NAT is not a firewall: all it does is rewrite packets, it does not drop them.
I noted (without quoting at the time) that the article actually mentions this aspect of NAT, here is a quote from yesterday's article:
> Time and time again we are lectured that NATs are not a good security device, but in practice NATs offer a reasonable front-line defence against network side malware scanning and injection, so there may be a larger story behind the use of NATs and device-based networks than just a simple conservative preference to continue to use an IPv4 protocol stack.
Since I didn't state it before, I don't see any need to add NAT to IPv6 and certainly not for security reasons when a firewall is the correct way to secure networks. I don't feel that IPv6 is inherently more or less secure than IPv4, regardless of NAT. I also agree that even for IPv4, firewalls should be used and that NAT should not be relied on as a security measure for any remotely high stakes situation.
The reason I made my comment though is because I seem to share the same opinion as yesterday's article's author that people stating "NATs are not a good security device" are missing the point that in regard to IPv4, NAT may not be a "fully proper" security measure, but in practice it is "plenty good enough" for the vast majority of internet users.
People proclaiming how NAT is not a security measure seem to me to be ignoring our reality where 100s of millions of consumer routers, incidentally but nevertheless effectively, use it as one. Even without a firewall to drop packets on these devices doing NAT, they effectively block a whole class of automated malicious activity.
Is it safe to have unprotected network devices shielded only by NAT without a firewall? No, not really.
Should you use a proper firewall even if you have NAT? Yes, absolutely, but a lot of people don't and are nevertheless adequately protected considering they probably have no "open" devices on their network and have no particular reason to be targeted by a truly determined malicious actor.
[1] https://news.ycombinator.com/item?id=46691835
It s true. That s not the reason it is insecure. The reason it is insecure is people who infiltrated the committee made sure to make data exfiltration possible through mandatory ICMP for everything.
Good luck setting up proper firewallimg rules for IPv6 while both respecting its specs and preventing hard-to-detect exfil through ICMPv6.
It's a rube-goldberg of a protocol and it s hard to believe it s all incompetence and there ain't t some malice involved.
NAT for IPv4 was an accidental godsend, especially useful in an era where you d hack your neighbors' computers when they where on the same subnet as yours. Don t tell me it didn't t happen for I was doing that on dial-up back in the days.
Thankfully the point is mostly moot because people are still free to use IPv4 at home/companies while having their router using IPv6.
IPv4 shall thankfully outlive me. And I don't t care if it means more work for people working in the "punch the monkey" ads industry.
Makes sense. But I’d argue NAT is still more secure because it physically breaks the connection between your internal host and the outside world. Without an existing routing table there’s no destination to route the packet to.
I disagree with this strongly. The intended use case of NAT or the existence of inbound connections being blocked by routers is irrelevant.
For NAT, of course it isn't meant for security, but it has a side-effect of creating a network boundary, and that has positive security implications.
If your router doesn't have a firewall blocking any connections, NAT still has security implications as it is deployed typically on consumer networks, which is a one-way port-address-translation for outbound traffic.
The important bit here is not NAT or firewalls, but layer 3 network segments!!!
An RFC1918 private addrerss space is not internet routable. Furthermore, routers shouldn't "default route" traffic from arbitrary connected networks by default. But "should" aside, the typical default consumer router behavior is that they don't NAT translate inbound traffic, they can't!
If a random internet IP wanted to connect to port 80 on a device at 192.168.1.200 in your home network, it doesn't know how to tell your router what IP to translate it's request to the router's public IP to. That is the essential positive security implication. In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't forward such traffic.
With IPv6, end devices in your network get a globally routed address, someone can try to connect to that same internal device as my earlier example and succeed with the same exact default behavior in place.
IPv6 is thus, by relative metrics, insecure by default. It does not mean it cannot be secured, but it is less secure than IPv4 in typical deployments where extra care isn't taken to secure it properly. If your answer to this is "well that's just because people who deploy networks are dumb" then save your self the effort or arguing that, it is irrelevant. That is how networks are deployed in the real world, period. People make mistakes in the real world. People don't know best practices in the real world. So out of the box, things need to consider real world hazards, and IPv6 does not do that.
You can support the adaption of IPv6 nonetheless and I would have no disagreement there.
The problem is, as I understand it, is this hypothetical network where there is a NAT but no firewall just does not exist.
>In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't forward such traffic.
This is typically handled by the firewall, not the NAT. You can easily come up with scenarios that without the firewall, the NAT could be trivially defeated, e.g. by port scanning.
It is not, you guys are talking from a specific american ISP perspective where you have these modem+router+gateway+firewall combo devices. Not everyone gets that.
Many get just a modem and buy a cheap router which may not have a firewall. MANY more get just a modem and their laptops are directly exposed to the internet (!!!), those you can't do much about, but many put a "router" that's just a cheap wifi access point with layer 3 routing and NAT. If you chose to "bridge" a device (like those internet exposed laptops) or port-forward, it will just work (even with ISP routers!!) there is no firewall rule change required.
I've worked in this space supporting consumer grade routers, and then worked in enterprise networking. But don't take my word for it, you all can take a trip to shodansafari, how many devices are listening port 3389 and 445 with consumer grade laptop names?
But it isn't a popular thing to say for whatever reason. I guess IPv6 is a political ideology now lol.
>Many get just a modem and buy a cheap router which may not have a firewall
What cheap router are you buying that doesn't have a firewall. I think the problem is when people hear "firewall" they think the router is running pfSense or something. Even cheap routers will have a basic, non-configurable, firewall that will block inbound connections. That is separate from NAT and has nothing to do with IPv4/IPv6.
what most people call "router" in that context are APs. Good ones are proper router/AP/Firewall combos, but my cheap ones don't.
Here is a good example with the user guide: https://www.tp-link.com/us/document/107360/
It's an AP that serves DHCP addresses on the lan port. that's it. It has some port forwarding too if you set it up, no firewalling there. For modems, most cable ISPs let you buy a DOCSIS modem, there is no router, whatever device you connect gets a DHCP lease right on the internet (and ipv6), most people buy cheap "routers" like that one to add "wifi" to it, and it works great for the money. And honestly, I have yet to see one that does have a firewall, but then again I've never tried the $500 router options or seen someone who did.
These devices are not meant to firewall, they have no need to firewall. if you do "bridge" or "portforward" they assume you want everything forwarded, they don't let you configure any firewalling by design, and they don't have any firewalling because it isn't needed. They have a dedicated WAN port, the management interface doesn't listen on that port and LAN devices are NAT'ed with IPv4 so there is no need to firewall anything even behind the scenes. Their main use is to either extend wifi coverage or add wifi capability to modems.
Most people with fiber or *DSL get an ISP provided gateway which has a firewall,that's not the same as what I'm talking about.
I hate to complain about downvotes, but you all need to realize that it is the poorest and most vulnerable around the world that get hurt over this stuff. yes, ipv6 can cause unintended internet exposure of internal devices. period. that's not a dismissal or disapproval of ipv6, it is what it is, and that needs to be considered when deploying it. It assumes you'll configure your network properly, unfortunately the people who made ipv6 didn't consider consumers or people who screw up, they wanted to force people to configure firewalls, that works for corporations (until it doesn't) but not for most regular internet users.
The nat is a belt and braces approach - especially when combined with rpf. How will your packet reach 192.168.0.1 from the internet without having a nat rule to translate the packet, even if there is a firewall rule allowing all traffic
(If you control the next hop and the router doesn't have rpf checks on the wan interfaces you can forge a packet with a destination of 192.168.0.1 and route it via the public IP of 40.50.60.70)
I basically disable all ipv6 on my routers & firewalls completely. Waiting for the day we can disable ipv4 completely instead and use only ipv6 without NAT. But then each device will need its own firewall. NAT basically forces you to use some kind of firewall, which applies to all devices behind the NAT. But if we go all-in on IPv6, the firewall-by-default becomes much harder to implement in practice. Then we will need some kind of distributed/federated firewall config to constantly keep devices usable but safe, but then that will introduce a new set attack vectors. So we are kinda screwed for now. We need that new internet, maybe one where you unify static ipv6, dhcp6, dns, firewalls, nat and a few other friends into a single thing. Or perhaps we can use ipv6 only to get a static ip address for each home/building, which then has a small vlan/vpn to group all your devices together using ipv4 internally for ease of use.. which is close to what we currently have with cgnat+ipv4+wireguard+vlans. All round we have a big mess but it works well, if you know what you are doing that is. This is all to say we can even keep net-neutrality for a while longer, we are okay for now but the american/uk/china/india govs plus entities like cloudflare will actually destroy net-neutrality in the long run. Much like email delivery has already been ruined & captured. Sorry for the rant.
The article says:
> Modern routers ship with firewall policies that deny inbound traffic by default, even when a NAT is not being used.
So no, not every device needs its own firewall. You can have a single firewall at the entrance of your network.
Though just like with IPv4 most of the time you shouldn't build on assumed-secure internal networks.
Not always the case and differs by router software.
Not really. I’m sure there exists some brain dead CPE without a default-deny firewall. It’s just that I’ve never physically seen once, since around 1999 or so.
Bigger commercial gear, sure, but those would be special-purpose equipment that don’t support NAT either.
To a rounding error, everything which has NAT enabled by default also has a default-deny inbound firewall enabled by default.
You seem to have misunderstood how IPv6 works. In a home setup, all the traffic still goes through a single router which typically has a restrictive firewall enabled by default.
Only if enabled for a specific interface/network/zone/grouping... easy to misconfigure. You can easily misconfigure it to work fine for ipv4 but forgot about ipv6. Depending on what router software you use, this will either be easy or hard to spot. Sometimes the router software won't tell you explicitly that a certain interface is not included or that you have a gaping hole in your network somewhere.
If you use a consumer-grade device at home that you don't have full access to (meaning root via ssh and can update packages, cute web ui's alone don't count), you are screwed in other ways either way (hello open CVE's on unpatched routers....). I literally have a brand new Asus router sitting in a box at home, cause it has 3 open CVE's and asus basically dropped support for it, but they still sell them. Oh and I have root ssh access on it - it is running ubuntu 12 underneath it all (disgusting that asus haven't bumped it). Just all garbage. So I built my own x86 dual-nic/Wifi 6E router box that runs openwrt + adguard home + unbound + wireguard (all on proxmox) and all 4 systems update nightly. This setup absolutely crushes the performance versus top spec consumer-grade routers and I get to monitor it properly and update packages daily.
It is not at all "easy to misconfigure". First of all, the manufacturer is going to configure it for you in 99% of cases, just as they do for IPv4. Second, even if you want to roll your own firewall rules, it's trivial to set up a default deny on all incoming traffic.