> 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.
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 POSTROUTING -o wan0 -j MASQUERADE
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 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 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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
That's the very thing those who consider IPv4 NAT to be a desirable feature don't want.
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.
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.)
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.
https://www.kaspersky.com/blog/blackhat-jeep-cherokee-hack-e...
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).
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.
Sounds farfetched? https://www.theregister.com/2025/06/03/meta_pauses_android_t...
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.
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.
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.
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:
IPv4 Target: 192.168.0.1
IPv6 Target: 2001:1868:209:FFFD:0013:50FF:FE12:3456
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
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).
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.
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.
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.
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.
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 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".
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:3456When 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.
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.
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.
(;-)
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.
TIL that IPv6 is a cryptosystem
Or do you really want to argue that Linux Netfilter/nftables or BSD pf being open source is a security problem?
NAT is not for security, it does not provide security. It is often bundled with a firewall. The firewall provides security. Firewall=\=NAT
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.
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.
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.
Besides, NAT isn't a security feature.
Assign a /56, firewall in place already dropping anything not explicitly allowed, done.
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 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'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.
...and goes on to ignore enterprise businesses, which consume most of the v4 space and are among the biggest resisters of v6.
Definitely not. I've been disabling that for years.
It's only been drilled into people because it's true:
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.
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.
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.
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.
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.
(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)
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...
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.
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.
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
And yet statistically I'm safer on a bus. Therefore it's reasonable to ride the bus "for safety".
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.
This is all behavior that happens even with no firewall whatsoever.
> 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.
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.
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.
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.
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.
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.
> 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.
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...
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.
No one (at least not me) said anything about a "direct connection" (which I assume means using globally routable IPv4 addresses on your internal systems).
Nor did anyone say anything about not forwarding any ports. In fact, much of the discussion has been about how "secure" NAT is when forwarding ports, with some folks claiming that doing so is all you need. Or did you miss those 80-100 comments?
>This statement makes no sense. If you are not using NAT of some kind, and your machines only have RFC1918 addresses, then your machines can't access the Internet at all.
Exactly. That was my point. And if you add NAT without stateful firewall rules to limit access, your internal systems are exposed.
I tell you what: post the IP address/range of your home network, turn off the firewall you're using and just leave NAT enabled as it is right now and we can see for ourselves just how "secure" bare NAT is. What do you say?
Unsecured NAT (i.e., without, at a minimum, firewall rules limiting connectivity -- a default deny rule at least) is not secure at all.
I've said (now twice) what I had to say. Feel free to disagree (again) and/or downmod my post, but my decades of experience professionally implementing networks, the security infrastructure which attempts to secure them, at the perimeter as well as at the LAN, server and endpoint informs my opinion.
Don't agree? That's fine with me. It's no skin off my nose. I have no axe to grind with you or anyone else around this or anything else.
Have a good day.
Edit: Clarified the "Globally routable" addresses as IPv4.
1. 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 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 […]
Anyone using IPv6 ULA and NPT would disagree.
* https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Tr...
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.
See https://en.wikipedia.org/wiki/Network_address_translation#Me...
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.
Meanwhile, an IPv6 network behind your average Linux-based home router is 2-3 nftables rules to lock down in a similar fashion.
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.
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.
Where is this? Here new ISP customers don't even get a single IPv4 unless you beg for it.
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.
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.
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.
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.
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.
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!
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.
Assume eth0 is WAN, eth1 is LAN
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;
}
}
* 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 };
}
}
* 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
That's equivalent to default-deny.
I think either you're just trying to "well-actually" us or you're confused.
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.
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.
its not about the firewall. there's just a lot of extra attack vectors without a nat.
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
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.
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
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.
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.
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.
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.
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.
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.
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
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.
Not to mention the return packet would be NAT'd so the attacker would have to deal with that complication.
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.
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”.
If there's nothing to connect to, is there really an incoming connection?
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.
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.
> 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.
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.
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.
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.
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.
Meanwhile with IPv6 it's the other way around, everything is wide open unless you have a working and properly configured firewall.
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.
Competency crisis is not limited to just the audience.
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.
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.
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'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.
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.
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.
The GP is talking about 1:1 'basic' NAT:
* https://datatracker.ietf.org/doc/html/rfc2663#section-4.1.1
Security comparisons should be between proposed new tech vs. existing tech, not vs. hypothetical straw-man tech.
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.
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.
Otherwise just the huge amount of addresses should make ipv6 “more secure” imho.
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.
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.
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.
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.
How many digits is that? Woah, I can barely count the commas!
Security via obscurity will only get you so far.
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.
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.
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.
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.
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...
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.
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.
[0] <https://www.snbforums.com/threads/ipv6-passthrough-disadvant...>
(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.)
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.
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.
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.
> 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?
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.
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.
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?
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.
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
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?
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".
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.
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(!)
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
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.
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.
NAT doesn't protect you from either of these.
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.
Well that's the point of the article isn't it? That the firewall is the important part, not the NAT.
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.
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?
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.
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.
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.
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.
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.
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.
> 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.
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?
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.
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.
But it _is_ a reason, and it _is_ true.
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.
(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
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.
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 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.
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.
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.
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.
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.)
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.
"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.
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.
This is a security feature ad, nothing else. And it’s 100% because of NAT, not anything else in the PIX feature set.
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.)
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?
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.
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.
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.
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.
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.
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.
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.
> 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 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 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.
What you’re describing would happen if NAT were completely disabled. You’re just describing an open router
> 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.
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.
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.
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.
FWIW the broad IPv6 network-prefix NAT behavior ALSO EXISTS in IPv4, it's just less applicable.
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.
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.
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 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.
An ipv6 lan with default ingress deny is more secure than ipv4+nat
I suppose I will distill my thought into the assertion that the author should have prefixed his title with "In capable hands,"...
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.
"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."
But the best de facto firewall is a proper firewall.
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.
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?
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.
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.
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.
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.
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 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 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?
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?
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".
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.
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
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.
So you are willing to message me your credentials then?
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.
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.
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.
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.
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
> 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.
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?
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.
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.
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.
VMs work fine without NAT too -- DHCPv6-PD lets the VM software automatically request a routed prefix.
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.
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.
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
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.
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 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.
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.
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.
Early IPv6 commonly used EUI-64 addressing, which did embed your MAC address into the IPv6 interface IDOf 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.
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.
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.
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.
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.
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.
Works if you rely on the ISP provided box?
And why pick on ARP and not on SLAAC, NDS, DAD, RS, RA... ?
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.
> 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.
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.
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.
- 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)
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.
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
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.
No it's not. NAT is not ever a firewall. By definition it is not.
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.
And yes, this has happened to me when I forgot to compile the IPv6 conntrack module.
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.
And IPv4 NAT is actually possible to penetrate sometimes. So for some networks, IPv4 provides better P2P connectivity, than IPv6.
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.
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.
... 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.
would be better if it was "Lacking a NAT doesn't make IPv6 insecure".
- 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 don't need a qualifier like "on the WAN subnet". It just doesn't do anything to protect you from inbound connections at all.
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)
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.
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.
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.
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.
>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.
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.
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.
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.
(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)
> 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.
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.
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.
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.