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.
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...
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?
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.
NAT is just an addressing hack, a weirdly complex way of indirectly routing to specific addresses. It only influences what is written in the envelope, not how that envelope is processed at the post office.
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.
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.
NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate).
Your definition of security is too narrow.
And saying that NAT is broken all the time, implying that NAT is not security, is ridiculous. SSH is 'broken' all the time. TLS is broken all the time.
Here's the end point: NAT effectively reduces the attack surface for a home network to the router. That is security, practically speaking.
And yet statistically I'm safer on a bus. Therefore it's reasonable to ride the bus "for safety".
This is a (dumb) NAT but has no state so it cannot possibly implement a default deny or any firewall adjacent features.
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.
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.
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
Competency crisis is not limited to just the audience.
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.
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.
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.
Security comparisons should be between proposed new tech vs. existing tech, not vs. hypothetical straw-man tech.
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.
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(!)
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.
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.
Security via obscurity will only get you so far.
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.
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.
Or if you had a script that did that and put the public v4 address in your taskbar.
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:3456fcab: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.
(;-)
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
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.
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.
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.
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".
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.)
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.
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.
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.
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.
NAT doesn't protect you from either of these.
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.
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.
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 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.
FWIW the broad IPv6 network-prefix NAT behavior ALSO EXISTS in IPv4, it's just less applicable.
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.
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.
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.
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.
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.
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.
"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.
Of course you can have default drop in your IPV6 firewall, but it's far easier to keep in your head that internal NATed IPs aren't accessible and "real" IPs are.
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.
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)
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.
Early IPv6 commonly used EUI-64 addressing, which did embed your MAC address into the IPv6 interface IDIt 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.
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.
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.
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.
would be better if it was "Lacking a NAT doesn't make IPv6 insecure".
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".
... 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.
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.
- 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?
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.
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.
There may be situations where your router can be tricked too, I can't think of one off the top of my head which wouldn't also apply to a stateful firewall sitting on a routed network segment with no nat, and it would typically be a vulnerability to patch
But your principal is right -- it's far harder to exploit than just connecting to an ip of say 2001:172:56:107:111::192.168.80.25 on port 80
For 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.
(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.