* NAT can still filter traffic (and practically always does)
* NAT can hence still provide security features
* The real world often does not care about original definitions of a term. NAT was originally meant to just do address translation, but it has evolved.
* Of course, ipv6 is not less secure because it doesn't have NAT, as the same filtering behavior can be replicated with a firewall. That may even have advantages over NAT.
RFC 4787 does not really describe how real world implementations behave. As almost all SOHO routers are Linux-based, i prefer to discuss Linux netfilter-based NAT behavior than some hypothetical RFC 4787 NAT. There are clear differences. For example, RFC 4787 says:
> REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior
While Linux netfilter behavior is "Address and Port-Dependent Mapping".
As Linux netfilter implements both NAT and firewall behavior, it is relevant for the discussion which parts of overall netfilter behavior falls into 'NAT part' and which into 'firewall part'. There is clear distinction - DNAT/SNAT rules in nat table represent NAT behavior, while REJECT/DROP rules in filter table represent firewall behavior.
As Linux-based SOHO routers are usually configured with both NAT and firewall netfilter rules to implement both NAT and firewall behavior, one cannot answer question 'Does NAT filter traffic?' based on external behavior of such SOHO routers, but has to analyze which part of the network stack is responsible for such behavior, or how the same network stack configured with just NAT rules and no firewall rules would behave. And here the answer is no, it would pass traffic (that do not match existing connections) unmodified.
The problem is: what is an implementation detail, and what is NAT as a concept? This line is very blurry. The RFC does not really distinguish this and also doesn't want to. As it says, it tries to document behavior and explicitly uses the term "NAT filtering". When we say "This box here does NAT", then we implicitly assume this behavior. You might argue that implicit is not good, and I would agree (this is the advantage of ipv6 with firewall: filtering is explicit rather than implicit). However, if someone tells me "Well actually, NAT does not do filtering, the firewall does", then to me this is similar to arguing with staff in a supermarket that the tomato belongs in the berries section.
I also want to make clear that I fully agree with the article's main point: NAT's primary purpose was and still is address conservation, and that ipv6 is no less secure than ipv4. I do disagree though with the notion that "NAT does not do filtering" or that "NAT does not provide any security".
And if I think back to my 30 years of IT, environments with NAT end up with lazy engineering from systems and application folks. It doesn't provide an environment that forces folks to understand their problems holistically. Thus, relying on perimeter firewalling and NAT as a large catch all. It's a bad security practice imo
The correct way is hard. You either have to manage firewalls on each host, or your switches need to have firewalls (I assume that’s a thing?). Hosts on the same subnet never hit layer 3 so IP-based firewalls don’t see them.
You either need very static infrastructure so you can hard-code firewalls on the hosts, or you need a system to dynamically manage the firewalls on each host, or an SDN that can sanely manage layer 2 flows. Little things like moving an app to a new server become a whole project unless you have really good tools to reconfigure the firewalls on everything that touches the app.
Then you need a way to let people self-service those rules or else security has to be involved in like everything just to do firewall rules.
It’s a good idea, but a huge pain and I’ve not seen good solutions
If you really feel you must have NAT, there is IPv6 NAT. Unlike IPv4 NAT, V6 affords enough address space that IPv6 NAT can do 1:1 IP:IP mapping between internal and external. This eliminates entire classes of issues around port exhaustion and port remapping and allows P2P applications to work fine. P2P NAT traversal with simple 1:1 NAT has a nearly 100% success rate on the first attempt.
For those of you with this handy technology, the mobile phone, in the United States: you have an IPv6 address without NAT. Some of you even exist on a network using 464XLAT to tunnel IPv4 in IPV6, because it's a pure IPV6 network (T-Mobile). These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons.
This is all to underscore the author's point: NAT may necessitate stateful tracking, but firewalls without translation has been deployed at massive scale for one of the most numerous types of device in existence.
> These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons.
FWIW, I was interested so I tested this on my phone here in Finland (Elisa, the largest carrier here): IPv6 inbound TCP connections work just fine, unlike IPv4 which is behind CGNAT.
On mobile broadband (no calls) plans they also offer optional free public IPv4 address, but not on the regular phone plans.
(I did the test by installing Termux from Play Store, then in it running "pkg install netcat-openbsd" and "nc -6 -l 9956" and then connecting to that port from internet using telnet, while phone was not connected to WiFi.)
Being allowed to serve data from your own device should be seen as a natural human right.
If the networks don't have capacity or something then we need networks that can support that.
The idea that all of that has to go in the Fediverse on a server or something is just gatekeeping.
Wait a few years as IPV6 becomes truly ubiquitous. This will become very obvious to everyone and standard. People must be allowed to communicate directly, even if they have a lot of clients.
The opinions are slightly similar to remote work. Telecommuting was an obvious next step for a long time, it just took a certain number of decades for society to realize it.
What would be the obvious reasons? (I'm not being flippant here -- I'm genuinely interested in what arguments people have to not allow servers on that network)
High concentration of technically inept users with hardware that no longer receives security updates and has plenty of well known easily exploitable vulnerabilities. Which naturally is used to run banking apps and travels with users close to 24/7 while tracking their location.
From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use. The internet APs the carriers sell get deprioritized relative to phones when necessary and the fine print generally forbids hosting any services (in noticeably stronger language than the wired ISPs I've had).
> From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use
Isn't that already the case with limited plans?
For example, mine has 40 GBs and I'm pretty sure it counts both upload and download, because I generally consume very little, except for one week when I was on holiday with no other internet access and wanted to upload my pictures to my home server and didn't otherwise use the phone more than usual.
Facebook would start listening on port X and and then their embedded SDK in other websites or app would query that IP and port, get their unique id, and track users much better.
The phone providers oversell bandwidth. They also limit the use of already purchased bandwidth when it gets legitimately used.
Similar to many industries, their business model is selling monthly usage, while simultaneously restricting the actual usage. They are not in the business of being an ISP for people running software on their phones.
I think it should vary based on the type of service being provided. Truly mobile service, I think it can make sense to not allow servers. If its being sold as a home internet solution (a more fixed kind of plan), I think it should allow servers to at least some level of hosting services.
The main difference is there's usually limited airtime capacity for clients, especially highly mobile ones. A server could easily hog quite a bit of the airtime on the network serving traffic to people not even in the area, squeezing out the usefulness of the network for all the other highly mobile people in the area. This person moves around, pretty much doing the equivalent of swinging a wrecking ball to the network performance everywhere they go.
When its being sold as a fixed endpoint though, capacity plans can be more targeted to properly support this kind of client. They're staying put, so its easier to target that particular spot for more capacity.
The most common use case for mobile data servers is probably pwned cheap/old phones forming DDoS swarms. Pure P2P over internet is very rare on mobile, no sense not blocking ingress from the perspective of ISPs.
However for that having the phone's IP not reachable has at best marginal benefits. The DDoS itself is an outgoing connection, and for command and control having the compromised phone periodically fetch instructions from a server is simpler to implement than the phone offering a port where it is reachable to receive instructions
It's sad how much of this thread of supposed hackers comes from people who are simply parroting this dogma because it has been drilled into them. People were even preaching this before IPv6 privacy extensions came into use, either downplaying the privacy issues or outright telling people they were bad for wanting privacy because IPv6 is more important.
I understand the difference between NAT and firewall perfectly well. I have deployed and configured both for many years. The strawman of "NAT without firewall" is pretty much irrelevant, because that's not what people run IRL.
Firewalls are policy-based security, NAT is namespacing. In other fields, we consider namespacing an important security mechanism. If an attacker can't even name a resource they're not allowed to access, that's quite a strong security property.
And of course, anyone can spoof IP and try to send traffic to 192.168.0.6 or whatever. But if you're anywhere in the world other than right inside my ISP's access network, you can't actually get the internet to route this to my local 192.68.0.6. On the other hand, an IPv6 firewall is one misconfigured rule away from giving anybody on the planet access.
Thank you. This is the first time that someone admits here that NAT actually adds some security. IPv4 will never go away less that an important share because of it's simplicity and NAT-level security it offers to millions of professionals and amateurs that tinker with their routers.
Except in the real world everyone is also running UPnP, so NAT is also one misconfiguration away from exposing something publicly. In the real world your ISP might enable IPv6 one day and suddenly you do have a public address. Relying on NAT is a bad idea because it's less explicit, a firewall is saying you only want to allow these things through, of course nothing is perfect, you can mess up, but NAT is just less clear, the expectation is not "nothing behind NAT should ever be exposed", it's "we don't have enough addresses and need to share".
Sure, and that's fine, but relying on it isn't, and it isn't a reason not to use IPv6 (if you want namespacing, there are tools for that outside hiding behind a single IPv4). Hence the advice is not to rely on NAT.
This is people talking past each other, and to be fair, saying "everyone" in my post made it unclear, I was being glib in response to "because that's not what people run IRL", when evidently people do, I've seen it happen.
I think this is where the disconnect is: the home users are precisely the ones being talked about, because they are the ones most likely to be treating NAT like it is a security system for their devices in the real world.
I've literally seen someone's ISP turn on IPv6, and then have their long-running VNC service compromised because they were just relying on NAT to hide their services.
You are wrong because you are being overly pedantic.
NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate).
Your definition of security is too narrow.
And saying that NAT is broken all the time, implying that NAT is not security, is ridiculous. SSH is 'broken' all the time. TLS is broken all the time.
Here's the end point: NAT effectively reduces the attack surface for a home network to the router. That is security, practically speaking.
> NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
Which NAT?
A 1:1 'basic' NAT [1] could allow stateless flow between two different address schemes. Then you have NAPT where multiple IPs can be mapped via one-IP-many-port system, in which you need state and thus have a filtering mechanism.
Similarly you can have IPv6 ULA and do a stateless address translation (NPT) without any blocking policy, which would achieve the same (lack of) security as the 1:1 scenario above.
Address translation can have the same level (or not) of security in both IPv4 and IPv6.
> And indeed, if a firewall is off NAT can still function (if NAT is separate).
Well technically you can translate your /16 to look like a different /16 from the outside. IE each internal address gets turned into its own separate external address.
But that's not how NAT gets used in practice. How it actually gets used is to but many hidden addresses behind one or a few public addresses. And that multiplexing necessarily implies that incoming connections must be specifically told where to go; ie that there's a firewall.
> NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
Any good firewall does the same, by having a default “no” rule for incoming connections.
> A firewall is not required for NAT to work
Do you have any examples of NAT that isn't implemented in a more general firewall subsystem?
> NAT effectively reduces the attack surface for a home network to the router.
While true, this doesn't add to the argument for/against IPv6. That is just security provided by default configuration, which can be provided many other ways and could be before the subset of NAT you are talking about was common.
> Do you have any examples of NAT that isn't implemented in a more general firewall subsystem?
When I was a network engineer, we did NAT on edge routers for B2B connections all the time. Like literally hundreds of thousands of them. I am 100% serious on this.
>NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
No. NAT enables internal, non-routable (cf. rfc1918[0]) actors on the inside to access external resources on the Internet. Generally, that's done via NAT masquerade[1] (one-to-many NAT), but can also be done with one-to-one NAT.
>A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate).
No. It isn't. And if you enable NAT without firewall rules, it will happily expose your internal network to external actors. In fact, that's the whole point of NAT.
In fact, not using IPv4 NAT is enormously more secure than using IPv4 NAT, assuming you're using RFC1918 addresses internally. Primarily because non-NATted RFC1918 addresses won't be forwarded by routers on the Internet (CGNAT notwithstanding).
>Here's the end point: NAT effectively reduces the attack surface for a home network to the router. That is security, practically speaking.
Again, no. Enabling NAT increases the attack surface for all networks, regardless of type. Without NAT, external actors need to compromise your router first, then get it to accept spoofed packets.
Yes, there's detail that I've ignored, as it's irrelevant to the statements made. Most of that is related to "I want to access Internet resources, but my ISP won't give me anything but a single, ephemeral, routable IPv4 address, so I need to use NAT to share that one address."
That's not an argument for the "security" of NAT, it's an argument for being mad at your ISP, especially if they won't give you a /56 block of IPv6 addresses.
This goes against Hyrum's law. NAT provides the behavior 99.9% of users want, usually by default, out of the box. True firewalls can do the same thing, but not necessarily by default, the firewall might not even by on by default, and there's more room for misconfiguration. IPv6 is a security regression for most people, regardless of its architectural merits or semantics of what's a firewall.
NAT implementations get broken all the time (NAT slipstreaming attacks). If a manufacturer is incompetent enough not to have a firewall on by default, they are probably also shipping a vulnerable NAT.
NAT slipstreaming depends on confusing fragmentation assemblers and application aware parsers. Those exist in firewalls as well. It’s not NAT specific.
I wouldn’t put the number so high. I’ve on several occasions seen not very technical people unnecessarily burn money on VPSes or dedicated hosting providers because they couldn’t expose a game server for a evening session with their friends with the spare capacity on their gaming machine, because of their ISPs NAT setup. 90% would be fairer. However we still shouldn’t be sacrificing securing agency of individual consumers for securing smoother revenue for corporations.
And that kind of NAT effectively doesn't exist in practice, so that's quite beside the point. Such a NAT doesn't scale to more than 24 devices behind it.
No, it very much does. If you want to join two network segments such that on one side all devices are on 10.1.X.X and the other all devices are 10.2.X.X, you'd use a mapping between 10.1.a.b and 10.2.a.b
The general context here is about NATting to the public internet at large, not between particular segments. And the parent of my comment was talking specifically about NAPT, which is different from the non-port-based NAT that you're talking about.
See my reply to your sibling commenter. My comment was not about NAT in general, i.e. I was not denying the very real existence of stateless NAT. Rather, I was disputing the usefulness of the NAPT solution proposed above as a solution to public IPv4 address exhaustion.
This is a terrible argument. First, NAT doesn't provide the security behavior users want. The firewall on their router is doing that, not the address translation. Second, that firewall is on by default, blocking inbound traffic by default, so why on earth would you conjecture that router manufacturers will suddenly stop doing that if NAT isn't on by default? Third, it's not remotely likely that a user will misconfigure their firewall to not secure them any more. Non-technical users won't even try to get in there, and technical users will know better because it's extremely easy to set up the basics of a default deny config. There is no security regression here, just bad arguments.
The firewall on your typical IPv4 router does basically nothing. It just drops all packets that aren’t a response to an active NAT session.
If the firewall somehow didn’t exist (not really possible, because NAT and the firewall are implemented by the same code) incoming packets wouldn’t be dropped, but they wouldn’t make it through to any of the NATed machines. From the prospective any machine behind the router, nothing changes, they get the same level of protection they always got.
So for those machines, the NAT is inherently acting as a firewall.
The only difference is the incoming packets would reach the router itself (which really shouldn’t have any ports open on the external IP) reach a closed port, and the kernel responds with a NAK. Sure, dropping is slightly more secure, but bouncing off a closed port really isn’t that problematic.
NAT gateways that utilize connection tracking are effectively stateful firewalls. Whether a separate set of ‘firewall’ rules does much good because most SNAT implementations by necessity duplicate this functionality is a bit ignorant, IMO.
Meanwhile, an IPv6 network behind your average Linux-based home router is 2-3 nftables rules to lock down in a similar fashion.
It's also trivial to roll your own version of dropbox. With IPv6 it's possible to fail to configure those nftables rules. The firewall could be turned off.
In theory you could turn off IPv4 NAT as well but in practice most ISPs will only give you a single address. That makes it functionally impossible to misconfigure. I inadvertently plugged the WAN cable directly into my LAN one time and my ISP's DHCP server promptly banned my ONT entirely.
> In theory you could turn off IPv4 NAT as well but in practice most ISPs will only give you a single address
So, I randomly discovered the other day that my ISP has given me a full /28.
But I have no idea how to actually configure my router to forward those extra IP addresses inside my network. In practice, modern routers just aren't expecting to handle this, there is no easy "turn of NAT" button.
It's possible (at least on my EdgeRouterX), but I have to configure all the routing manually, and there doesn't seem to be much documentation.
Went to double check what my static IP address was, and noticed the router was displaying it as 198.51.100.48/28 (not my real IP).
I don't think the router used to show subnets like that, but it recently got a major firmware update... Or maybe I just never noticed, I've had that static IP allocation for over 5 years. My ISP gave it to me for free after I complained about their CGNAT being broken for like the 3th time.
Guess they decided it was cheaper to just gave me a free static IPv4 address rather than actually looking at the Wireshark logs I had proving their CGNAT was doing weird things again.
Not sure if they gave me a full /28 by mistake, or as some kind of apology. Guess they have plenty of IPs now thanks to CGNAT.
More like even if they looked at the logs they aren't about to replace an expensive box on the critical path when it's working well enough for 99% of their customers.
I once had my ISP respond to a technical problem on their end by sending out a tech. The service rep wasn't capable of diagnosing and refused to escalate to a network person. The tech that came out blamed the on premise equipment (without bothering to diagnose) and started blindly swapping it out. Only after that didn't fix the issue did he finally look into the network side of things. The entire thing was fairly absurd but I guess it must work out for them on average.
Did you even read the second paragraph of the (rather short) comment you're replying to? In most residential scenarios you literally can't turn off NAT and still have things work. Either you are running NAT or you are not connected. Meanwhile the same ISP is (typically) happy to hand out unlimited globally routable IPv6 addresses to you.
I agree though, being able to depend on a safe default deny configuration would more or less make switching a drop in replacement. That would be fantastic, and maybe things have improved to that level, but then again history has a tendency to repeat itself. Most stuff related to computing isn't exactly known for a good security track record at this point.
But that's getting rather off topic. The dispute was about whether or not NAT of IPv4 is of reasonable benefit to end user security in practice, not about whether or not typical IPv6 equipment provides a suitable alternative.
>This is a terrible argument. First, NAT doesn't provide the security behavior users want.
Try breaking into my machine. Login:pass are administrator:pa$$w0rd, external ip 58.19.1.129, internal ip is 192.168.1.124, the system is Windows xp, and firewall is turned off on both the computer and the box the ISP gave me.
Instead of all my devices being behind one IP and using an internal IP subnet, now each device has a globally routable ip address that will be used... Cool great opsec.
When we say "NAT" we are specifically talking about stateful one-to-many NAT implementations as found in consumer IPv4 hardware. Such a NAT is largely isomorphic to a firewall with default-deny semantics for incoming connections and default-allow semantics for outgoing connections.
There are other possible NAT implementations that are much less like a firewall, but saying that a NAT does not provide security is a misunderstanding of the terms as they are used.
Not you specifically, but others in other threads have pointet to UPnP as proof that NATs don't provide security. If the existence of UPnP means that NATs don't provide security, then the existence of PCP means that Firewalls also don't provide security.
NAT-PMP, UPnP, PCP, et. all primarily exist because consumer networks that have to share a public IP face more issues than simply opening a port up to the internet. Destination port conflicts, port remapping, discovery of your public IP, are huge fucking headaches that these protocols also assist with.
Given most consumer routers these days can be configured with a mobile app, I could easily foresee a saner alternative where devices could simply ask the gateway if they could open up a port and have a notification sent to a mobile app to allow it.
But, that said, given how many devices are mobile these days I think the benefit of endpoint firewalls shouldn’t be underplayed either.
You on the inside can punch a hole to the outside. This is fine. There's no real difference between hole punching and a regular connection to a regular server from one side's perspective.
Of course symmetric or even carrier grade NAT is not a firewall, but it's so silly to ignore real world implications thereof in an IPv4 only deployment scenario. Firewalls aren't foolproof and in real life you average NAT is more likely to be closer to that.
It's scary how much of this thread comes from people who can't imagine a use for keeping internal traffic internal. in ipv4, if my laptop tries to use a printer with a public ipv4 address, that raises alarms. in ipv6, if my laptop tries to use a printer with an ipv6 address...
its not about the firewall. there's just a lot of extra attack vectors without a nat.
I agree with the majority of your point, but hopefully your printer hasn't been assigned IPv6 IPs that are global in nature and is instead limited to site-local.
For anyone who is reading this but hasn't use IPv6, IPv6 addresses are a large flat 128-bit contiguous address space, but they are not universally routable. The prefix of any specific address determines what group of other IPs can get to it.
We often think of a computer as having an IP address, but with IPv6, computers will have several addresses, all with different prefixes to handle different types of traffic.
If you plug your printer into your home network, and if the local DHCP server is configured to hand out globally routable addresses from your ISP provided /64, then your printer will also be globally routable (as well as your "smart" fridge, "smart" TV, "smart" thermostat, etc). In my personal experience this is the default situation with consumer ISP IPv6 setups.
This difference in theory versus practice is precisely why we see people objecting that IPv4 is more secure as far as default configurations go when it comes to home use.
That said, I expect (hope?) that all ISP gear should default to enabling a stateful firewall. Hopefully there's no difference between the default security of an IPv4 and an IPv6 setup in practice. But given the history I'm not entirely optimistic.
>This difference in theory versus practice is precisely why we see people objecting that IPv4 is more secure as far as default configurations go when it comes to home use.
I mean, I agree with them. I think people who say 'NAT is not security' are only correct in the absolute most pendantic way and that the way NAT is commonly configured is literally the only reason the internet doesn't consist mostly of botnets.
But I also suspect that if IPv6 were more common, we as a society would be better at it, and not do dumb things like hand out globally routable IPs via DHCP6
I suspect the author was trying to put into words why their technically correct world view is better, but he spends his opening arguing semantics (ineffectually, as apparent) instead of meeting the 'wrong' people where they are and explaining why his semantics are an improvement.
Competency crisis is not limited to just the audience.
If the end effect of security is dropping packets NAT and Firewalls both in effect drop packets.
Its kind of just silly pedantry to say NATs aren't security because sure you can't do things like block specific ranges of IPs spamming you (or make outbound rules to control local devices) but 99% of people don't need.
I understand ipv4 networks pretty well. And I would say that any device doing NAT is acting as a basic firewall. Do “true” firewalls do more? Sure. But saying NAT doesn’t provide security is flat out wrong.
If your router had only NAT and someone (i.e. your ISP) sends it a package addressed to somewhere inside your internal IP range, it will happily forward it. A firewall would block it.
> NAT is not for security, it does not provide security.
It’s not for security but it absolutely does provide security and pretending otherwise continues to harm discussions.
I have a pile of ipv4-only IoT devices that have no firewalls of their own that are being protected by the symmetric NAT in my home router. Kick and scream all you want but there is security there and nothing on the internet can reach those devices unsolicited, just like a stateful v4 firewall would provide.
First they will have to change their policy of only providing one IPv4 address per ONT connection. Then they will have to convince me to disable NAT on my router, disable the DHCP server on my router, and bridge the WAN port with the LAN block.
Meanwhile in IPv6 land the ISP provided router that my relative has came configured by default to hand out globally routable addresses from the ISP provided /64. Thankfully it also had a stateful firewall enabled by default so there was no difference in practice.
If your public IP from your ISP is 12.13.14.15, and your internal block is 192.168.0.0/24, then your ISP can send a packet to 12.13.14.15 destined for 192.168.0.7, and without a firewall your router will happily forward it. An attacker who can convince intervening routers to send traffic destined for 192.168.0.7 to 12.13.14.15 (and these attacks do exist, particularly over UDP) can also do that.
Okay, so not only do you have to create a bogus packet, you have to convince every piece of equipment in between you and the end user to collude with it, in the hopes that the final router is so woefully misconfigured as to act upon it?
The ISP is the primary threat vector here (do you trust yours? Along with their contractors and anyone who might have compromised them?). But like I said route-poisoning attacks do exist.
yeah but the likelihood of this is incredibly remote. It would shock me if ISPs didn't have alarms going off if RFC1918 space was suddenly routable within their BGP table.
Not to mention the return packet would be NAT'd so the attacker would have to deal with that complication.
Send packets to the device? A NAT is in it's most basic form a mapping from one IP/port set to another IP/port set describable by some function "f" and its inverse "g". The common home user case has the firewall detect a flow from inside the network and modify "f" and "g" to allow this flow. Without the firewall, and assuming you want your devices to talk to the internet in some way, the NAT would forward (with modifications) traffic based on "f" and "g" to all your devices.
I think the confusion stems from the fact that my mom's laptop with its 192.168.0.43/24 v4 address is not routable except via NAT, and people believe (rightly or wrongly) that that confers a degree of security.
UPNP and a dozen other NAT defeating tactics exist and have since the early 2000s. NAT translates addresses. Thinking a non-routable range is safe because it's behind NAT is at this point grossly ignorant of how modern network equipment works. It's kind of like port-knocking; yes it makes the attack slightly harder, but doesn't prevent it.
e.g. symmetric NAT exists and often doesn't come with a stateful firewall. Just because the linux box with iptables is protecting your network uses NAT doesn't mean NAT is doing the heavy lifting here. I can see the OMG MY PRIVACY crew is out in force here apparently misunderstanding that NAT does not do that either. I mean, we can explain things to you, but we can't understand it for you.
>UPNP and a dozen other NAT defeating tactics exist and have since the early 2000s.
I know that, and you know that, but squillions of people think that turning the UPnP setting off (if they even know what that is) is sufficient, which is why the myth persists.
UPnP is only relevant for software that's already running on your machine locally. People here aren't generally talking about outbound connections and I think you both know that. The practical effect of NAT as commonly encountered in a residential setting is to drop inbound unsolicited connection attempts.
And yes, everyone is aware that you could also do that with a stateful firewall. And no, none of us care about arguments of definition that attempt to frame NAT as technically being a firewall based on how it operates in practice. Being intentionally obtuse by refusing to acknowledge the obvious isn't going to convince anyone.
It doesn't confer much since it COULD be only NAT and no firewall.
It's INCREDIBLY unlikely to find a case of that in the wild, but possible.
A common example of a host that might have such an address but lacks that sort of security is anything as the default route for inbound packets, E.G. like you'd want your _own_ router / firewall rather than the ISP's modem.
It's scary how many supposed hackers have never even looked up an RFC before making grandiose statements. There is such a thing as "NAT filtering", see RFC 4787, section 5: https://datatracker.ietf.org/doc/html/rfc4787#section-5
A NAT is not a firewall, yes. At the same time, the NAT boxes out there in the wild absolutely do filter traffic, and yes, it is the NAT that does it, not a separate firewall. Practically all NAT boxes in the wild do stateful filtering. It is not really standardized how they do it, but this is how the real world often works. People argue that the filtering part of NAT is "actually a firewall", but what's the point? From the outside, you will not be able to tell if there's a firewall that filters traffic for which no established connection can be found, or if this is done by a NAT.
Many people are so fixated on the definition that NAT is only address translation and nothing else, they refuse to interact with the real world out there.
John, your post opens saying it's addressing the point: “the NAT-by-default of IPv4 effectively means that I get the benefit of a default-deny security strategy.”
Your title is "IPv6 is not insecure because it lacks NAT"
I'm sure anyone who understands how NAT offers the equivalent of a default block rule also understands that the absence of NAT alone doesn't make IPv6 insecure. This makes the title feel a little clickbaity-strawmanny, sorry.
Your response seems to be: "most firewalls have a default block rule too meaning they're no worse than IPv4 w/ NAT."
There's more security to be had in an intrinsic architectural feature (like IPv4 NAT being necessary due to limited IPv4 space meaning most IPv4 devices behind CANNOT be addressed from the internet without NAT) then there are in policy features (most firewalls SHOULD have the default deny IPv6 rule that will stop their address being reached from the internet.)
That doesn't make IPv6 insecure because no NAT. But it does mean - IMO - that the intrinsic block that comes with IPv4 NAT is a better security measure for making devices inaccessible than relying on default firewall rules.
What point are you trying to make here, and is it actually more useful than the point you say you're addressing?
> There's more security to be had in an intrinsic architectural feature
No, there is not. Even ignoring the question of whether the concept of an ordinal ranking in amount of security even makes sense, this claim doesn't make sense. If the invariant is that incoming connections are blocked by default, an IPv4 NAT and an IPv6 default deny rule are equivalent in security: both uphold the invariant. If the claim is that a misconfiguration of the gateway can make the system vulnerable, again, the two kinds of firewall configuration are equivalent: you can configure an IPv6 firewall to pass traffic and you can configure a DMZ host or port forwarding in the NAT case.
There's no basis for claiming the two schemes differ in the level of security provided.
> Even ignoring the question of whether the concept of an ordinal ranking in amount of security even makes sense
I must be misinterpreting this statement, are you arguing that you aren't sure whether "x is more secure than y" is inherently a valid thing to compare?
You talked right past the key point which is valid:
> There's more security to be had in an intrinsic architectural feature (like IPv4 NAT being necessary due to limited IPv4 space meaning most IPv4 devices behind CANNOT be addressed from the internet without NAT) then there are in policy features (most firewalls SHOULD have the default deny IPv6 rule that will stop their address being reached from the internet.)
One security property is architectural, one isn’t. They’re not the same.
This is the first thing that as a Network Engineer I was taught - and every formal security class I've taken (typically from Cisco - they have awesome course) - repeats the same thing.
I believe the common knowledge is somewhat more nuanced than people would have you believe
I present to you two separate high-value targets whose IP address has leaked:
Target #1 has an additional level of security in that you need to figure out how to route to that IP address, and heck - who it even belongs to.
Target #2 gives aways 90% of the game at attacking it (we even leak some device specific information, so you know precisely where it's weak points are)
Also - while IPv6 lacks NAT, it certainly has a very effective Prefix-translation mechanism which is the best of both worlds:
Here is a real world target:
FDC2:1045:3216:0001:0013:50FF:FE12:3456
You are going to have a tough time routing to it - but it can transparently access anything on the internet - either natively or through a Prefix-translation target should you wish to go that direction.
For your example, shouldn't you either present two "private" IP addresses, in which case you'd replace the IPv6 address in your example with what is likely to be an autoconfigured link-local address (though any ULA address would be valid as well),
OR present the two IP addresses that the targets would be visible as from the outside, in which case you'd replace the IPv4 address with the "public" address that 192.168.0.1 NATs to, going outbound?
Then, the stated difference is much less stark: In the first case, you'd have a local IPv6 address that's about as useless as the local IPv4 address (except that it's much more likely to be unique, but you still wouldn't know how to reach it). In the second case, unless your target is behind some massive IPv4 NAT (carrier-grade NAT probably), you'd immediately know how to route to them as well.
But presenting a local IP for IPv4, and a global one for IPv6, strikes me as a bit unfair. It would be equally bogus to present the public IPv4 address and the autoconfigured link-local address for IPv6 and asking the same question.
I do concede that carrier-grade NAT shifts the outcome again here. But it comes with all the disadvantages that carrier-grade NAT comes with, i.e. the complete inability to receive any inbound connections without NAT piercing, and you could achieve the same by just doing carrier-grade NAT for IPv6 as well (only that I don't think we want that, just how we only want IPv4 CGNAT because we don't have many other options any more).
In these contexts - neither of the addresses was intended for internet consumption. A misconfigured firewall exposes you in the case of IPv6 routable addresses, and is less relevant in the case of IPv4; the ULA IPv6 address is roughly the same as an RFC 1918 address with it's lack of routing on the Internet.
The point I was (poorly) trying to make is that non-routability is sometimes an explicit design objective (See NERC-CIP guidance for whether you should route control traffic outside of substations), and that there is some consideration that should be made when deciding whether to use globally routable IPv6 addresses.
Especially as if someone is able to capture ifconfig data, they can probably send a curl request to a malicious web server and expose the NAT IP as well.
I'm not sure I buy the "you get a leak of the address of a high value target you believe can be routed to over the internet in some fashion, but it's the internal address which leaked and you have no idea who could own said high value target either" story.
I agree if it's an actual concern then you can use NAT66 to hide the prefix, I just don't see how this achieves security when the only publicly accessible attack point is supposed to be the internet attached FW doing the translation of the public addresses in the first place.
Additionally, if that really is the leaked IPv6 address then it's formatted as a temporary one which would have expired. If you mean static services which were supposed to be inbound allowed then we're back at the "the attack point is however the internet edge exposes inbound in both cases, not the internal address".
NAT66 doesn't add much in the way of security here, because the external address is fully routable and maps 1:1 to the internal address. You are once again fully dependent on a correctly configured firewall.
The IPv6 address that I shared was, in fact, a static (and real) IPv6 address, belonging to a real device - with the possible exception of the last 3 bytes, was likely one I worked on frequently.
Put another way - to do an apples to apples comparison:
Hard to attack: FDC2:1045:3216:0001:0013:50FF:FE12:3456
Easier to attack: 2001:1868:209:FFFD:0013:50FF:FE12:3456
> NAT66 doesn't add much in the way of security here, because the external address is fully routable and maps 1:1 to the internal address. You are once again fully dependent on a correctly configured firewall.
When using the stateful firewall provided by Linux's packet filter, the IPv6 NAT66 "masquerade" works very similar to IPv4 NAT. 1:1 mapping is NOT required.
For example internal hosts are configured as follows:
inet6 fd00::200/64 scope global noprefixroute
ip -6 route add default via fd00::1
Edit:
From my understanding the NAT66 is ambiguous and it may work as a stateful port-based translation similar to IPv4 NAT, whereas NPTv6 is a stateless prefix-only translation.
It's the same difficulty to attack in both cases: hack the internet firewall, which is the only point with connectivity to both internal and external addresses regardless of method of preventing inbound traffic.
Well - I can't say they have always said this - but at least for Circa 1998 CCNP onwards that's been their position. The instructors were very adamant - to the point that I'm recalling this 27+ years later.
This probably has more to do with network engineers (and CCNP instructors) not being security engineers (or even conversant with Cisco's security SBU).
In the case of IPv4 - you almost certainly would get the external IP address of the unit doing NAT translation. In the case of IPv6 - it's quite common (outside of the enterprise world) for the Native IPv6 address of the device to be routed directly onto the internet - desirable even.
In the case of a 'leaked" address - there are all sorts of ways in which internal details of an address can leak even when it's not in the DST/SRC envelope of the packet on the Internet.
Yup, by default a Linux based router won’t forward any traffic to a IPv6 host unless you explicitly have a program running which keeps on telling the kernel you want that.
I'm sorry, this is just an elaborate argument of obscurity-as-security. You're clinging to privacy as though it were security, in stark avoidance of Kerckhoffs's principle.
You can use Shannon's maxim instead if you're going to be deliberately obtuse. The point is true for any system intended to be secure, and a network is such a system, as is the security software such as the claimed NAT software.
Or do you really want to argue that Linux Netfilter/nftables or BSD pf being open source is a security problem?
Fun fact I have actually had an sbc get hacked because I didn’t change the default password. I thought it would be reasonably safe for a few days because I knew the VLAN it was on had NAT and the associated firewall rules that deny inbound packets without outbound. But it turned out ipv6 was also enabled on that VLAN with no firewall. Left a bad taste in my mouth over a decade later even if it was a misconfigured firewall rather than an inherent issue with ipv6.
…and they did really guess an ipv6 address? Full scans of the ipv6 address space looks infeasible. Or did the sbc reach out to the internet thus having its address exposed?
Otherwise just the huge amount of addresses should make ipv6 “more secure” imho.
I don’t have any idea how they got the ip, it could certainly have been making outbound connections, though. I think it had NTP, although I might have pointed it at a local server we had for that.
I don't know how much impact this has in practice, but you do not need to scan the entirety of the ipv6 address space because you can just look at the IPs that are registered to known ISPs/ASs.
You're gonna need to scan 2^64 addresses once you've located the IPv6 network assigned to my connection before you find my phone. 2^56 if you don't get lucky guessing the network prefix it happens to be on at that moment.
Assuming a scan with a minimum 4 byte ICMP packet, that's about 73786 petabytes of network traffic for that /64. You'll need to shove it down the pipe within a day because IPv6 privacy extensions means the IPv6 address used changes after 24 hours. With only 1gbps fiber, I don't think the deanonimysation is the problem at that kind of traffic level.
I'm also not sure how much it helps, but a friend and I were just talking about how big the numbers get today.
My ISP provides my house a /56 allocation. There are 4,722,366,482,869,645,213,696 addresses. I should have enough for a couple of years, at least.
I guess you could scan it. The IPs for most devices are chosen randomly within a /64 subnet, or they're based on MAC address, but they're not sequential by any means. A /64 is still 18,446,744,073,709,551,616 possible IPs.
Unfortunately I think one of the problems with v6 is people are just unable to apply intuition to numbers this big. The minimum number of /64s an ISP will have is around 4 billion. They generally give subscribers a /56 which is 256 /64s. It's all simple power-of-2 arithmetic. Computer people used to get how big 2^64 is.
Most of the time it's going to be a /64, so even if you know the prefix you're still never going to guess a random address. But a lot of older clients will use a deterministic address based on their MAC, searching the space of MACs for known sbcs would be a lot more tractable.
In theory, IPv6 Privacy Extensions (https://datatracker.ietf.org/doc/html/rfc4941) could mitigate this. In practice, I imagine when you bind to `[::]:port`, that also means that the randomized addresses would work for new inbound connections, too. Not sure how long they typically last, but you'd be fighting against the clock at least before a new randomized address.
That being said, on a slightly less common note: it is quite possible to have each individual service running on a /128. E.g. on IPv6 k8s clusters, each pod can have a publicly addressable /128, so activities like NTP would require the container to have an NTP client in it to expose in that way. That'd mitigate a good chunk of information exposure -- that being said, I agree with the larger point about security via obscurity being insufficient.
If you have a shitty ISP that rotates prefixes like it's 2005, hosting anything public is a massive pain already. DDNS works just as well on IPv6, though.
Internally, a ULA will keep things reachable even if you move ISPs. You could even set up a NAT66 setup to translate your changing prefix to your stable ULA so you don't need to update any firewall rules, but that's a pretty terrible workaround for a problem that shouldn't be on you to fix in the first place.
In my defense I was in college at the time, and I did actually run some tests to ensure my understanding of the firewall was correct. I just didn’t even think to account for ipv6 or especially for that range having different firewall rules.
Unlike the other poster, I'm not going to blame you for getting things wrong. It happens, we all were learning at one point. But I do think it's incredibly unreasonable to use a mistake you made as an argument against IPv6. This would be like if I rm -rf'ed my Linux box into oblivion when I was first learning and then avoided Linux after that because I had bad vibes about it. Sometimes you need to accept the L and not blame the tools.
NAT causes security issues too. Reflection attacks are much harder to stop if the endpoint and its network address are decoupled.
You can provoke loops and tangles of many sorts, some at the same protocol level and others going up and down.
My memory is fading but I vaguely recall a time when all of AOL shared something like a dozen egress addresses for certain traffic -- might have been proxies as opposed to NAT/"PAT" as we know it today. Iow, you couldn't block one without blocking 1/12 of AOL users.
Stronger memories of a time when your IP address (some were nat, some were not, varied by ISP) depended on which modem bank you dialed into, which was strongly influenced by what phone number you dialed. Which diluted the identity value of a given IP for a computer or user.
> Unfortunately, NAT reduces the number of options for providing security [1]
Somehow, everyone forgot that, and it morphed into a cargo-culting security practice, even going so far as to propagate 1990s network limitations into the cloud(!)
Real world CSRF attacks into hxxp://192.168.0.1 home routers and polluting DNS and DHCP settings you could argue is caused or at least facilitated by NAT, or NAT misconceptions especially.
Though IPv6 has a similar situation with well defined unicast and multicast addresses.
True story, popular browsers won't let you load a webpage via various IPv6 local address literals for this reason. Hxxp://[ff02::] addresses won't work.
/ You can have your cake by "tying a knot" with yourself and port forwarding from 127.0.0.1 to the IPv6 literal. An ssh port forward will do this with aplomb. Then load hxxp://localhost:port and it works again.
This is going to depend on the router and on IP distribution.
My ISP does not give me an IPv6 address, only a single IPv6 which all my network devices have to NAT through.
NAT is not intended to be a security feature, for sure, but it creates security as a side effect. If I start up a web server on one of my devices, I know that it is unreachable from the Internet unless I go out of my way to set a port forward on my router.
But...if my ISP decides to start handing out IPv6, that can change. If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.
But if my ISP still gives me only a single IPv6 address and I'm still needing to use NAT, then I'm guaranteed to still effectively have a "default deny" inbound firewall policy.
> If each of my devices gets an Internet routable IPv6 address, at that point, that security-as-a-side-effect is not guaranteed unless my router has a default-deny firewall. I would hope that any routers would ship with that.
They usually do, and they also ship with the most wonderful technology ever specified within a 67 MB compressed archive [0]: UPnP! Now your attacker's job is to convince you to initiate an outgoing connection, which automatically forwards an incoming port to your device behind the NAT and bypassing the router's default-deny firewall! Nothing has ever gone wrong with a zero-configuration port-forwarding protocol from the 1990s rammed through the ISO!
That's an entirely different attack scenario. To succeed at that attack, my computer would already need to be running malware. At that point, they've already won.
I don't believe that opens a port to accept an incoming connection.
Even if it did, a web page making a request can't control the source port for the connection. They still couldn't make a local network service exposed to the Internet.
WebRTC and similar tools have existed for over a decade at this point and been abused horribly. Many common UPNP or similar daemons trust ANYTHING on the "trusted" side and will happily grant basically anything asked for because their vendors don't want customer support calls over whatever insane behavior some printer or IOT lightbulb is doing without the end user's knowledge.
Every router I’ve ever used has blocked incoming connections on v6 exactly the same as on v4. Really the only difference is you can have multiple devices on your network allowed to receive on the same port if you want.
> Every router I’ve ever used has blocked incoming connections on v6 exactly the same as on v4.
A few years back my ISP didn't properly support prefix delegation, and the only way to get IPv6 to work was in "Passthrough" mode. My router (Asus ax86u) was really unclear about what passthrough mode meant, but I think that it might also disable the IPv6 firewall (I have read conflicting reports, and was never able to find an authoritative answer). The setting is buried pretty deep in the router and off by default, so I don't think most people would enable it by accident, but a quick google search does show lots of people on forums enabling Passthrough mode to get IPv6 working. So seems pretty dangerous and there is no warning or anything [1] that you are potentially exposing every device on your network to the internet (if that is indeed what it does).
Fortunately, my ISP has since implemented proper support for prefix delegation.
I got curious about what "passthrough" might be doing and found this assertion [0], which reminded me of the existence of '6relayd' [1]. So I assume that that mode relays the RAs & etc, but replaces the link-local address in the RA & etc with that of the relaying interface.
So, what side effect of NAT is making your server unreachable here? It sounds like you could turn the NAT off and it would be exactly as unreachable as it was when the NAT was on.
(Just to double-check... have you tried DHCPv6-PD? ISPs will normally only give your router a single IP on its WAN interface, or sometimes no IP on the WAN. Getting the routed prefix for the LAN-side networks involves doing a PD request, which is separate from requesting the WAN IP.)
With NAT your device does not have a publicly routable address. Attackers have no way of contacting you at all. Without NAT you have a publicly routable address and attackers can try reaching out to your device. You rely entirely on your device's and your router's firewall.
So it's not really about NAT although it ends up being a consequence—it's about having a truly private network "air gapped" from the public internet.
No, NAT only affects which IP your connections appear to be coming from. It doesn't change which IPs your devices actually have.
The person I replied to said that they only get a single v6 address. If that's true, it doesn't matter whether they have NAT or not; their network isn't going to have publicly-routable addresses either way.
If your network is air-gapped then no connections will be happening at all, in or out... and if you connect a router to both the Internet and to your network, and enable routing on it, then it's not air-gapped any more.
> No, NAT only affects which IP your connections appear to be coming from. It doesn't change which IPs your devices actually have.
Well no shit. The NAT is a requirement for devices without a publicly routable IP because if my router just sends packets out with a source address being my 192.168.1.101 local IP, my ISP is most likely just going to drop the packets.
You know this, I'm sure, so I'm really unsure what point you're trying to make.
> The person I replied to said that they only get a single v6 address. If that's true, it doesn't matter whether they have NAT or not; their network isn't going to have publicly-routable addresses either way.
Correction: It will have ONE publicly-routable IP, and if I assign it to my router, but don't use NAT, then none of my devices on the network will be able to talk to the Internet, either in or out.
What ISP gives you a single IPv6 address? That's incredibly comical. An ISP would have at least 79 billion billion billion addresses and they are giving you one?!
If I run a webserver on my network I know it's unreachable from the internet unless I specifically allow inbound traffic to it at my firewall. I get to use the actual security features with sensible terminology instead of silly things like "port forward".
> my ISP still gives me only a single IPv6 address
This is criminal, and also incredibly uncommon. You should talk to your ISP, it's most definitely a misconfiguration of some kind, if not deliberate torture. Normally you get a /56 at least because there are so many and they cost nothing.
Datapoint of 1: With Cox as my ISP, I can get a /64 just by configuring my DHCPv6 client to request it, but if I wanted a /56 or /48 I would have to contact someone at my ISP.
> The consequence of this is that when receiving inbound traffic, the router needs needs to be configured with where to send the traffic on the local network. As a result, it will drop any traffic that doesn’t appear in the “port forwarding” table for the NAT.
As I keep trying to explain each time this comes up: no, it doesn't and it won't.
When your router receives incoming traffic that isn't matched by a NAT state table entry or static port forward, it doesn't drop it. Instead, it processes that traffic in _exactly_ the same way it would have done if there was no NAT going on: it reads the dst IP header and (in the absence of a firewall) routes the packet to whatever IP is written there. Routers don't drop packets by default, so neither will routers that also do NAT.
Of course, this just strengthens your point that NAT isn't security.
It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.
That's a great point - the packet is not dropped by the firewall as a result of NAT - but it still won't route anywhere because the IP in the packet is that of the router itself. I've updated the article as a result of your comment, thanks.
It might be the IP of the router, in which case the router itself will accept the connection if something is listening (like the web interface perhaps). But whoever sent you the L2 frame has full control over the contents of the IP in the packet, so it could be anything.
So, if you have NAT but a grossly misconfigured router, it might not be secure?
Quick question - do you think that "security by obscurity is not security"? And, as a follow-up, when you park your car do you ensure your laptop bag is out of sight, maybe locked away in the boot?
Because here's a mindblowing concept that'll change the way you see the world - you can have a door lock but it won't make you secure. You need to actually fit the lock to some sort of door.
Repeating the same wrong points doesnt make you right.
Every NAT based product will have a firewall built in also by default. And it'll be deny-all except for conn-tracked.
And that L2 attack is a martian packet. Why are you allowing reserved IPs talk on public network interfaces (hello, spoofing and obvious at that)? These are always blocked due to the reasons you describe.
That's only because your ISP won't have routed that packet to you if someone gave it to _them_. However, if someone was able to get to the ISP-side of the connection that you have with your ISP, and send a packet down the fiber/copper line from the ISP side towards your router, and that packet has a dst of your internal network (192.168.0.1 or whatever), your router will happily route that straight on to whatever internal network you have.
This means that if someone decided to be a bad actor and start tapping fiber lines on the poles in your neighborhood, NAT would do literally nothing to protect you from all the packets they start sending your way.
If somebody is wishing to tap fiber optics lines to the ISP or to hack the ISP just to get to your router, then you probably are not going to be saved by a "default deny" firewall anyway.
Invoking NAT "security" as a reason against IPv6 is a surefire indicator the person invoking it has absolutely no idea what they're talking about and should not be allowed within typing distance of any network infrastructure
As a reason not to IPv6? I guess. As a thing, not scare-quoted, but really security? No. Be careful with things like "absolutely no idea what they're talking about".
Please. _I_ invoked that argument, and I bet I know more about IPv6 than you do.
All my services and networks have IPv6. And my first operational issues with IPv6 were in 2008, when my Asterisk SIP server started failing after ~12 hours.
Culprit? Privacy addresses kept accumulating until they overflowed the SIP UDP packet size because it listed all the combinations of supported codecs/endpoints.
This has been gospel among snooty network engineers for decades, but NAT was initially introduced to the wider market as a security feature, and it is absolutely a material factor in securing networks. The network engineers are wrong about this.
(IPv6 is still good for lots of other reasons, and NAT isn't good security; just material.)
I would never debate NAT was marketed as security (as marketing is often detached from the reality of what's being sold) but I'd be interested why it's a material factor in securing networks independent of the stateful firewall mentioned, which most seem to actually rely on. The "snooty" people probably mean less what may have been marketed to consumers and more what the standards which introduced it say. E.g. https://www.rfc-editor.org/rfc/rfc1631 notes address depletion and scaling as drivers in the opening but the only mentions of security are later on in how NAT actually makes security more difficult.
I.e. it would seem whatever argument could be made about security from NAT, poor or not, intended to be security or not, would be immaterial in context of stateful session tracking with outbound originate allowed alone w/o doing the NAT on top anyways.
It was more than just "marketed" as security. It was brought to market as a security product and used that way for many years, before address depletion was a meaningful problem. People used NAT firewalls back in the eras of routable flat class-B desktop computer networks.
The first commercial NAT box was the PIX in 1994, which featured stateful session firewalling (not just NAT) in agreement with the above 1994 RFC. It was still the era of referring to classful networks, but I'm able to source documents from the time which state the opposite of your claims.
> corporate networkers are free to expand and reconfigure their TCP/IP networks without agonizing over the much publicized IP addressing crunch. It also spares them from having to upgrade all of their host and router software to run IP version 6
It does end with the aforementioned security marketing making it sound like NAT is what provides security on the PIX:
> PIX also increases network security. Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
> And what about hosts that should be recognizable from the Internet, such as mail servers?
> These either can be directly attached to the Internet and assigned a public address or can be attached through PIX. In the latter case, the translator is configured to map one of these external addresses to the device not just for the duration of the application session but on a permanent basis.
Looking past the marketing line and reading the manual, the reality was the PIX was always acting as a full stateful firewall and did not just rely on NAT itself to provide the inbound filtering. See the "PIX Firewall Adaptive Security" section on page 2 of this 1996 manual I managed to dig up as reference https://mail.employees.org/univercd/Nov-1996/data/doc/netbu/.... Rule hits that missed a state match were even loggable (what a box for the time!)
Whether people saw the marketing and assumed it was NAT that provided security is precisely the bad assumption the article talks to, but at no point in history was NAT prevalent without being paired with a normal stateful firewall to provide the security - since the intent of NAT was not to fill that role, even in the beginning, as sourced by 3 references now vs your personal claims.
The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful.
The point is that NAT was introduced as a kind of firewall. The PIX firewall was named by Network Translation, Inc., which was acquired as a security device --- and, indeed, the PIX was for many years the flagship security brand at Cisco.
I don't dispute that NAT is dispensable (though: dispensing with it in millions of residential prem deployments is another story altogether!), only that it's "not a security tool" --- it clearly is one, and a meaningful one (whether network snoots like it or not) in a huge number of networks.
> The distinction you're trying to draw here, between exclusively using NAT to provide security, versus it being one component of a stack of network controls that could just as easily be replaced with others, isn't meaningful.
That's not the distinction I, or TFA, set out to make.
It's not that NAT is a component of controls that could be replaced by others, it's that whether NAT was put in place for security or if it was always assumed you need an actual stateful firewall precisely because NAT was never intended or believed to provide meaningful security, even in the days of classful networking.
Not one of the references above makes claim that NAT was intended to provide security on its own. That the PIX launched with actual firewalling capabilities does not bolster that NAT=security, it actually bolsters that NAT was never believed or intended to provide security even further.
To turn this back around at you: The distinction you're drawing that NAT could have provided "something better than nothing" in terms of security if appliances like the PIX hadn't always shipped firewalling from day 1 isn't meaningful.
The whole point of NAT firewalls is that the devices behind it don't have routable addresses. "Statefulness" improves the situation, but the translation itself provides a material control.
I suppose we fundamentally disagree that it's meaningful or material whether NAT can provide something the stateful firewalling has handled more completely since the first shipping implementation and that this defines what the purpose and introduction of NAT to the market was supposed to be.
There's no uncertainty at all about what NAT was meant to do; you can just read Cisco's introduction to the PIX, or it's statement about the acquisition of NTI, which are online.
Network administrators (less so security engineers) don't want NAT to be a security feature, so they've retconned a principle of security engineering that doesn't exist. If people were honest about it and just said they'd prefer to work on networks where less distortive middlebox features provide the same security controls, I'd have nothing to argue about.
But this article makes the claim that "NAT isn’t actually a security feature". That's simply false. People need to stop rebroadcasting this canard.
One could see the inlined, sourced, and dated references I placed above about the PIX rather than searching online from scratch or making assumptions of others reasons or intentions.
What some people do or don't want in the 2020s has no relevance to the reasoning in the 1990s, nor does it redefine the purpose or use of NAT the same. The above is clearly and directly stated from the sourced material of the era itself: NAT was introduced in the mid 90s due to concerns about address space depletion and the need to move to IPv6. The security features of said introductory appliance never came from or were supposed to come from implementing NAT, but from implementing stateful firewalling and blocking inbound connections. There is no personal opinion or retconning in any of this, they aren't even the postings of anyone from this century.
I don't see where they do. I see them talking almost exclusively about working around address depletion.
Hell, look at Cisco's press release for its acquisition of Network Translation, Inc. [0] It's all about address depletion and resource efficiency; security is mentioned as an afterthought. I'll quote the relevant paragraphs (and leave in the line break mangling present in the original).
SAN JOSE, Calif., October 27, 1995 - Cisco Systems Inc. today announced anagreement to purchase privately-held Network Translation, Inc. (NTI), anetworking manufacturer of cost-effective, low maintenance network addresstranslation (NAT) and Internet firewall equipment. The investment isintended to broaden Cisco's offerings for security conscious networkadministrators who want to dynamically map between reusable private networkaddresses and globally unique, registered Internet addresses. Through itsacquisition, Cisco will gain NTI's Private Internet Exchange (PIX) solutionwhich helps network administrators resolve their growing need forregistered IP address space. NTI's 10 employees and products will beincorporated into Cisco's Business Development efforts reporting to VicePresident Ed Kozel. The financial terms of the purchase are not beingdisclosed. The transaction is expected to close by the end of November andis not subject to the Hart-Scott-Rodino filing.
The NTI investment is the second action by Cisco in recent months tostrengthen its expertise in resource-effective Internet access technology.NTI technology will interoperate with and integrate several functions ofthe Cisco Internetwork OperatingSystem(tm) (Cisco IOS) software,facilitating use throughout the enterprise. NTI addresses two of the morecompelling problems facing the IP Internet -- IP address depletion andInternet security. Customers using the NATalgorithm can take advantage ofa larger than assigned pool of addresses. NAT makes it possible to useeither your existing IP addresses or the addresses set aside in InternetAssigned Number Authority's (IANA) reserve pool (RFC 1597). Cisco's goal ofintegrating NTI's technology and personnel is to ease the complexity ofInternet access for applications including telecommuting and World Wide Webaccess.
Read the Data Communications article they provided:
PIX also increases network security. Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
And what about hosts that should be recognizable from the Internet, such as mail servers? These either can be directly attached to the Internet and assigned a public address or can be attached through PIX. In the latter case, the translator is config- ured to map one of the external addresses to the device not just for the duration of an application session but on a permanent basis.
At some point you're going to have to find a way to argue that the Cisco PIX was not a security device; again: it was the flagship product of the security SBU.
I was there at the time, doing IP network engineering (for a Chicagoland ISP). The PIX was a security device, and NAT was understood as a security feature (for sure, also an address depletion feature, but the argument that's being made in the post isn't merely that it was an address depletion thing, but also that it categorically wasn't a security feature, which is just obviously false.)
> At some point you're going to have to find a way to argue that the Cisco PIX was not a security device...
What? It's a firewall that can do NAT. The PIX is clearly a security device. NAT is clearly an address-depletion-mitigation technique.
> Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
Right. And you can achieve the exact same effect with a firewall on an edge router or on a host. I get that firewalls might have been much less common thirty-ish years ago and that doing packet filtering might have been pretty novel for many, leading folks to get confused when they encountered a combination firewall+NAT device.
I'm not sure I can be any clearer about the fact that NAT is both a security feature and an address management feature. I feel like people who weren't practitioners are the time are trying to reason axiomatically that every feature fits into precisely one bucket, or that a security feature isn't a true security feature if it can be replaced by one or more other "cleaner" security features. None of that is true. Practitioners at the time were not confused.
"You can achieve the same effect" doesn't mean anything in this discussion. If that's your argument, you've conceded the debate.
It's a security feature in the same way that a power-cut switch is a security feature. A power-cut switch's purpose is cut power to a machine so that it can -say- be safely worked on or relocated (or simply to not draw power when the machine's not in use), the machine also happens to be inaccessible while its power is cut.
Sure. It's not technically a lie to call a power-cut switch a security feature for most pieces of kit. I'd still laugh at the salesman that made the assertion. If I were feeling particularly cunty, I'd ask him if he injured himself from that great big stretch.
I can't emphasize enough how much of a retcon it is to say "it's not technically a lie" that NAT is a security feature. It was deployed in hundreds of networks specifically as a security feature, and it is part of the security posture of hundreds of thousands of home networks today. People who say "NAT isn't a security feature" are simply wrong.
There are lots of security features I personally don't like either. I don't claim they're not security features; I say they're bad security features.
You can repeatedly emphasize your understanding as much as you like but it does not help provide any evidence to anyone it's actually the correct understanding.
NAT does not care what anyone's personal feelings may be, which is why the above sources were not talking about what others personal feelings were supposed to be as evidence of what NAT was/wasn't is/isn't.
> Since there's no way for anyone on the Internet to know which machine on the corporate network is using a Class C address at any given time, it's impossible to establish a telnet or FTP session with any particular device.
This is a security feature ad, nothing else. And it’s 100% because of NAT, not anything else in the PIX feature set.
That came up earlier and I know it's a gray area but I agree with the idea that a line tossed into the marketing and not backed up by the manual weakens the importance. The firewall in the PIX is the security workhorse.
Also that sentence implies you can get a connection to a device, you just know less about which one it is. Is that really a meaningful security feature? To the extent that connections are actually blocked, it's not because of the NAT scrambling they quoted in the first half of that sentence. That sentence is somewhere between unhelpful and flat-out wrong.
The principle difference, IMHO, is that it makes the security visible. My home cable router has NO firewall configuration at all. Supplied by my ISP and woefully deficient in absolutely all respects. I can't (for example) configure It does have a configuration for forwarding IPv4 ports to inside machines; but none for forwarding IPv6 ports. Does it have stateful filtering of IPv6 ports? I'd like to think that it does, but if so there is no visible evidence that it does.
This is one of those occasions where people are arguing semantics, and you're like "but -- I was there!"
My first cable modem did not have a NAT, nor did my first ADSL modem. You'd use "Internet Connection Sharing" on Windows 98 SE to share the internet connection on your LAN. And you'd get badly hacked, and then also install a firewall. Sygate had a firewall and NAT combined. (Or, you'd use linux - and also get badly hacked, but for different reasons.)
As a response, ISPs started to ship modems with built-in NATs. They did not start to ship what we now call routers (modem+NAT) because they wanted to encourage people to share their internet connections out of the goodness of their hearts. They'd prefer to sell more cablemodems, or dial-up. They started shipping (NATted!) routers because it saved them a lot of support calls from hacked (and disconnected) customers. Instead they got support calls about port-forwarding, so uPnP was the next hot feature.
Was NAT originally intended to be a firewall? No. Did it effectively protect many innocents? It did. Is it still needed as an additional layer of security-through-side-effects? Let's hope not.
NAT isn't security at all, good or otherwise. If it was sold as such, then the people selling it were giving out inaccurate info. But just because some people wrongly said that NAT provides security back in the beginning doesn't somehow make those claims true today.
But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it.
The router will then do exactly the same thing it would've done if no NAT was involved at all: if the dest IP in the packet is the router itself then the router will accept or refuse the connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.
It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.
Yes, but we've just successfully rewritten the article in the comment section as "it's not having NAT that provides the security itself, but other configuration any sane person would expect on a device doing NAT to prevent unexpected inbound connections" is exactly what the article set out to separate.
Yes, of course. If NAT denied connections in the way people think it does, then it wouldn't be necessary to separately configure the router to reject inbound connections. It's possible to have configurations that don't do that precisely because NAT doesn't do that itself.
That makes no sense. If a packet comes into a public IP to a session that doesn’t exist, there is nowhere to forward the packet onto. The public IP belongs to the router.
If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.
Not wishing to undermine the central point, NAT for v6 is a thing. The point of the article is that it's not "NAT by default" the way home IPv4 is because so few places worldwide get more than a single IP per customer: The NAT is not there in v4 for security, it's to provide for multiple devices inside the home. Or, in the case of Carrier-Grade NAT, to manage multiple customers, behind a small pool of v4.
NAT doesn't exist to be secure. If it is, (and that is debatable because NAT busting is a thing) then, it's a side-effect.
NAT for v6 is not common. If you use ULA, you'd possibly use NAT for v6 in some circumstances.
Just to nitpick a bit. What people typically mean when they say "IPV4 NAT" is Network and Port translation. My 192.168.0.1 internally becomes 172.217.12.100 and my port gets converted to something that is tracked so that the return packet can find it's target.
In IPv6, Prefix-Translation is similar, in that the /64 prefix is translated 1:1 - but the /64 Host address is (in my experience) left alone - so that renumber a network becomes trivial when you change ISPs - you just just change the prefix.
I don't actually know if "IPv4 NAT" behavior even exists in the IPv6 world, except in the form of a lab experiment.
From my understanding, the "IPv4 NAT" equivalent for IPv6 is generally referred to as NAT66 (NPTv6 for Prefix-Translation). For example, Fortinet offers this on their firewalls, and I believe most firewall vendors have this option.
What they're saying is NAT66 on Fortigates is 1:1 NAT, i.e. prefix translation, not n:1 NAPT, i.e. address+port translation.
I can't imagine why one would ever intend to use NAPT over NAT when the addresses were available though (e.g. on IPv4 where having a minimum of 2^64 public addresses per connection is not assumed), which is the only reason I wouldn't expect anyone to have bothered implementing it. So sure, it's what people refer to on IPv4, but it's not materially different from 1:1 NAT or necessarily adding any additional value.
Obviously the two aren't the same (especially given the need to do routing), but I've always found it amusing that in the systems world, capability-based systems (i.e. making it impossible to address things you aren't allowed to access) are gaining traction while the philosophy in the networking world seems to be going in the opposite direction (make it possible to address everything, i.e. IPv6 vs. NATted IPv4, then add filtering).
The tension here is the difference between theory and reality. In reality, IPv4 NAT is the only thing protecting most users in their homes. If you force IPv6 on this same population, you have to give them an equivalent posture by default.
This is kind of like writing an argument that motorcycles are not unsafe because they lack 4 wheels. This is true, but if you put my grandmother on one and ask her to drive across town, she would not survive it.
No, the reality is that every modern network device running NAT for a user device network is also already a fully stateful firewall, because the software required to do one is virtually identical to the other.
You can't buy a home router with NAT and no firewall, and no home routers ship that don't also have a default deny rule on that firewall. The same is true for SOHO routers and effectively every consumer network gateway device you might buy.
You literally have to go well out of your way to find a network device capable of NAT that can't function as a stateful firewall, and when you find it, it's likely to be carrier-grade. In other words, not intended to be capable of any security at all. The amount of NAT processing it's intended to handle will challenge the hardware enough as it is.
NAT isn't protecting them. Not being on the public internet at all is protecting them.
NAT is then unprotecting them a little by letting them punch out again. It's super easy for routers to implement this behaviour by default if your LAN is publicly addressable, and removes a whole class of exploits caused by applications making NAT hacks.
This is entirely untrue. Every shitty router shipped by ISPs this side of the doctom bubble has a stateful firewall enabled by default. NAT is distinctly not the only thing protecting most home users. Not to mention every OS I know of shipping with its own firewall enabled with default deny on inbound.
You are stuck on the theory of what is protecting this population. In practice, less than 1% of these users can or will turn NAT off.
Can you imagine how great things would work out with a public IP on all your nana's computers, NAT turned off, protected by the prowess of her Arris gateway's stateful firewall?
Telstra, one of Australia's massive telcos who are the "go to" telco for nannas who don't know anything about this internet thingy, have IPv6 enabled by default on their CPE routers. Without NAT. With a stateful firewall. Works perfectly fine for their millions of customers.
It would work out just fine, because NAT was never providing any actual security to your nana. It was only ever the firewall which made her secure, not NAT.
Yes, it is the case. In the real world, there are malfunctioning ALGs, permissive defaults, and connectionless protocols that are poorly tracked by these sloppy, underpowered "SPI" devices.
It's not, because in the real world NAT only affects your outbound connections. That means that turning it off only changes the behavior of outbound connections, not inbound ones.
Any inbound connection that would have worked before you turned it off will still work afterwards, and any that wouldn't have worked before will still not work afterwards.
Think about what 99% of SOHO users have: PAT (Nat Overload). This NAT impacts the way a connection is established in BOTH directions. Inbound connection attempts from the Internet to the NAT public IP address of the SOHO router can go no further than the router. We are talking what 99% of users have installed.
Maybe this is the reason for some of the disagreement. I am focusing on what is installed at 99% of user installations (PAT). I would agree with the comments that a 1-to-1 NAT offers no EXTRA security.
That's the type of NAT I've been talking about the entire time. It doesn't do anything to inbound connections unless you explicitly tell it to.
Connections to the router's IP address go to the router, but you need to consider what happens to connections that go to IP addresses on the network behind the router too.
"Collectively, our results show that NAT has indeed acted as the de facto firewall of the Internet, and the v4-to-v6 transition of residential networks is opening up new devices to attack."
ISP hosting a virtual machine you remote desktop into from internal network as the only way to access the external internet can also work as a "de facto firewall".
But the best de facto firewall is a proper firewall.
When I was about 12 I was working on a PHP3 application, I had some issues with a MySQL query, and I pasted my code to pastebin (or whatever we used back then) and shared the link on IRC, the code included my database credentials.
Back then our ISP gave every computer a public IP.
The next thing that happened was that someone changed my MySQL password, and me being 12, I didn’t know how to change it back.
They made me beg for the password, to much amusement to the whole channel, and then they helped me secure it and taught me how to reset the password.
NAT would have saved me, but I wouldn’t have received a free, though a bit embarrassing, security lesson.
That's what the firewall on your router is for. NAT might also stop someone connecting, but it's not a guarantee. You can get given a public address and be exposed, you can find out your server actually does UPNP automatically and so is exposed, etc... a firewall is more explicit and a better defence.
That's a strange example. An unauthenticated server on a LAN wouldn't be exposed to the Internet any more than a network using NAT would be. You would need to explicitly configure your routers firewall to expose a local node, the same way you would need to explicitly configure port forwarding with a NAT based network.
I've see some argue that a hypothetically buggy router would somehow be less likely to fail if NAT was used but really, that could be equally said about bad port formatting defaults, which have in fact happened. Complexity is what increases the likelihood of bugs at the end of the day.
NAT is just an addressing hack, a weirdly complex way of indirectly routing to local addresses. It only influences what is written on the envelope, not how that envelope is processed at the post office.
With IPv4, if NAT isn't working right then I simply cannot get online and I need to fix it. Fail safe. With IPv6, when my computers being globally addressable is the norm, if my firewall is misconfigured my computers will probably still be online. Fail unsafe.
Arguing this is pointless anyway because it's not even my decision, it's my ISP. I am however quite happy with my ISP's choices in this regard.
Ok, I'll bite: why do you say that IPv6 lacking NAT (which is not true by the way) would be annoying? We can finally get rid of an ugly workaround from 30 years ago that broke one core principle of the Internet (end-to-end connectivity) and a ton of protocols that required even uglier hacks (FTP and SIP ALGs, TURN/STUN, etc.) to barely work. Why would this be annoying?
IPv6 doesn't "lack" NAT. There is nothing preventing you from using ULA addresses inside your network (IPv6's version of RFC-1918) and then running NAT for those addresses on your router. IPv6 just doesn't _need_ NAT, but it is still an option.
I think there's a philosophical difference between IPv4 and IPv6.
IPv4 is from the era of local computer networks, which feature clients and servers. Clients talk to servers, but servers are not supposed to care or even know about clients unless clients decide to reach out to them. Client-to-Client communication is generally discouraged. The IP address is just a technicality and outside of local networks, just a part of the routing strategy.
IPv6 on the other hand is like an URL - an address you can use to find any device from anywhere on the planet. It makes no distinction between client and server. Which is why its pushed in places like IoT and smartphones - a voip call has no conceptual client and server.
One could make ones smartphones Ipv6 address openly available, and anyone could initiate a voip call to their phones. Would this be wise? I'd argue there's no scenario under which this doesn't cause an unacceptable level of risk, as even if the software is perfect, they'd be still vulnerable to DDOS attacks.
This means that NAT-equivalent firewall rules are necessary, which makes the whole discussion kind of moot, but it's not a good portent for Ipv6 that it makes previously unfeasible kinds of attacks potentially practical.
NAT also allows for other neat tricks, like IP level load balancing.
I'd say one huge and unambiguous advantage of IPv6 is that it makes UDP trivial.
> IPv4 is from the era of local computer networks, which feature clients and servers.
IPv4 on the ARPANET 'went live' in January 1983,[1] but the concept of a firewall didn't really happen until about a decade later (with some protocols having to be altered[2]):
> IPv4 is from the era of local computer networks, which feature clients and servers. Clients talk to servers, but servers are not supposed to care or even know about clients unless clients decide to reach out to them. Client-to-Client communication is generally discouraged.
No, it was meant to be a global address space where anything could talk to anything. That became unworkable due to scale and the limit inherent in using only 32 bits for the address space.
Some older protocols (ftp) don't play nice with NAT and need special handling, because address multiplexing was never intended to be a thing.
I find the discussion about whether or not NAT is a security feature or not interesting. To my mind NAT was intended to make ipv4 last longer in a clever way as address space dried up. A happy accident of this solution is a basic security feature.
Ipv6 doesn't (currently, will it ever?) have the same address space problem so each device anywhere could be globally routable. But we know that's not really a good thing security-wise. But why couldn't we implement NAT for it as a security mechanism, instead of an address space solution?
Admittedly I'm not expert so I might be talking shit.
You said it yourself. NAT was introduced to solve the address space issue. At that point firewall were already a thing.
You also acknowledged correctly that IPv6 Will botnrun into the same address space limitations.
You said NAT is not a good thing Security-wise. Then you follow up the question, why we shouldn't add that to IPv6 as a security feature. It's hard to understand the train of thought.
So let me answer this. While NAT incidently does something similar to a firewall, it is not a security feature. NAT must track any outgoing network connection in order to understand where to route incoming packets. If a packet it not a reply to an established connection, it is dropped. Otherwise the NAT must look up who opened the connection. A NAT can only work if stateful.
In a routable connection, ALL of that can be based on the static routing table.
Imagine a university with 10,000 computer, all of them having opened maybe 100 concurrent connections. The NAT must track every single connection and do a lookup for every packet.
In a routable network, it just looks up the destination IP in the packet and sends it to the next hop for the destination IP.
All while hopefully a firewall is in front of it.
So why would you want to reintroduce NAT to IPv6, when both issues are efficiently solved already?
Why would you do that when a regular default-deny firewall is and has always been the security feature you need, without the complications and problems of NAT?
Like I said I'm not expert, and was likely talking shit. I was just speculating based on the discussion in this thread.
I think the complications and problems of NAT seem to add a default layer of security to the whole thing. I know next to nothing about firewalls though, which might be the point here, but would a default deny present any problems for me that NAT would allow? That is is there a situation where as a layman I might run into problems receiving data for a valid process that wouldn't happen if it was just NAT?
A firewall is the security feature you want. With a default-deny rule, which most will come configured out of the box with, it does exactly what you expect: block all unsolicited incoming traffic.
Most people are probably actually running a firewall with NAT anyway, they just don't know it because an appliance with default-deny is pretty much install and forget for most people. So, no, it doesn't cause any additional problems.
The only difference with IPv6 is you don't need to NAT any more, but you keep the firewall.
It's important to remember NAT is part of the IP routing layer. In its regular form, a router just forwards packets to where they should be going. So it's plugged in to one or more networks, receives packets on one interface and forwards them, unmolested (well, mostly), to another interface. It's almost completely analogous to letters going through the postal system. The postal service just forwards letters around by looking at the address. It doesn't modify them in any way.
NAT is a bastardisation and is like your postie scribbles out the "return to sender" address and replaces it with his own. If you were to reply to that address, your postie would remember he did that, and replace the address you wrote with the original address he scribbled out earlier. It's not how IP routing is supposed to work at all and, in fact, a device doing NAT cannot strictly be considered a router at all.
Something you can add to any device is a packet filter. A router must not filter packets as it then wouldn't be considered a router (similar to molesting the packets with NAT). But you can insert a packet filter before things get to the router. If you glue those two things together and bundle it in one device then, voila, you have a firewall. A stateful firewall is conceptually like a packet filter and router glued together and working closely together. But you can just think of it like telling your postie "I only want to receive letters from mum" and he just burns all the rest before they get to you front door. (In reality you also want to allow correspondence so it's more like "only allow letters that are replying to letters I sent, which you'll know because you're my postie, or if mum sends a letter first, allow that too").
Writing this up makes me think... why don't we just teach this stuff using the postal system as an analogy? It's an almost perfect analogy and surely even today anyone understands this concept.
NAT is just one slice of IPv4. Granted your private IP is not routable (with CGNAT now your gateway is also no longer routable), but think of other features of IPv6 that are congruent:
SLAAC basically means your routable IPv6 address changes so many times in a day (and there are multiple of those at any given instant) that even if the attackers know your prefix, its going to be very difficult to do anything meaningful. the address space is too big.
And we are assuming here that there is no firewall.
Note : macOS firewall on a new install is disabled iirc.
- 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)
Security is a state of mind. So, whatever makes you feel secure, it's your security tool. NAT can be used for security, like VLANs gets a lot used for LAN security. And BTW, NAT can alter destination of IPv4 packet, but also the source. Which is not necessarily only masquerading, and it's seen a lot as embedded security, especially for home Internet. A firewall does not provide security by itself, it has to be configured in the specific way for the situation. I've seen a lot of firewalls with 100s of rules, but the first one was accept all forward, forgotten there by an admin after a test several days/months/years ago.
We are trying too much to put things in unique and well defined boxex. Universe does'n work like this. Security is just a state of mind.
No one's complaining that IPV6 is insecure. It may as well be very secure, but no one bothers to understand it if they're not paid to do that.
Of course you can have default drop in your IPV6 firewall, but it's far easier to keep in your head that internal NATed IPs aren't accessible and "real" IPs are.
I've seen plenty of discussions here on HN where people have made that claim. Even more elsewhere on the discussion side of other news websites by sysadmins that disable IPv6 because one of their industrial routers didn't come with a default deny rule that one time which made them think that's normal.
The people who are supposed to know IPv6 never seemed to have learned it and many of them don't seem to be open to the idea of learning something new. Of course half the world runs on IPv6 now so they'll have to get with the times eventually, but the prevalence of statements like these is quite depressing.
> many of them don't seem to be open to the idea of learning something new
To the idea of learning something designed by commitee, over complex and stinking of enterprise and that you simply can't deploy "by hand".
One of the advantages of NAT by the way is that your "outside" configuration and "inside" configurations are completely independent with the exception of the snat rule.
The "inside" is your /56 or /48. You can add more local-only "inside"s if you'd like, which is useful for terrible ISPs with rotating network prefixes. The "outside" is everything on the internet.
If you can make your way through the absolute slog that is ARP+DHCP, you can get through NDP+SLAAC. Or even NDP+DHCPv6 if you're a control freak.
> One of the advantages of NAT by the way is that your "outside" configuration and "inside" configurations are completely independent with the exception of the snat rule.
If you want NAT, then set up NAT. Your fdb6:fc49:f5ae::/48 ULA is your 192.168.x.y address. Set up DHCPv6 if you'd like to pretend you control your address space. You could even just ignore the spec and use fdfd::/48 as your ULA so you can memorize addresses (fdfd::1, fdfd::2, that's even shorter than 192.168.1.2!). Use fe80::1 (a perfectly valid address) on your router as a standard gateway and have it do NAT to the outside world.
Even though it's heavily discouraged (because NAT is a massive hack after all), you can do NAT on IPv6 without any special tooling.
Been running IPv6 for years on both my home network and internet servers, and I've never had to think about NDS, DAD, RS. SLAAC is something I've only had to think about once at network setup time, less than I think about DHCP on my IPv4 network. RAs I have actually had to think about because Unifi has had some regressions in IPv6 support over the years, but that's fixed these days so it's likely going into the "don't need to think about it" bucket too.
Of course I'm sure you think about DHCP address management, DHCPDISCOVER and DHCPOFFER packets, mDNS, ACD, etc., since clearly you like to get into the weeds of your network
I have to because I have two fiber connections to the outside world :)
Nothing fancy like automatic failover or load balancing, they're just there.
With ipv4 i change the default route on a machine to the internal IP of one of the ISP provided routers, that one NATs it and i'm all set.
With ipv6 that insists on giving me an ISP assigned address internally, what do i do? It only works with that particular ISP. I'd still have to NAT and somehow disable the ISP addys, if i even can.
I suppose a $3000 Cisco box will solve all my problems, wouldn't it? Or maybe a $3000 + 150/month support contract? If Cisco even bothers for that little.
IPv6 without NAT is not insecure; I can and do have a stateful firewall that denies unwanted inbound connections. But it does not matter if my auditors think otherwise and the whole Internet tells me that arguing with them will end my career.
As someone with limited networking knowledge, I’m not really getting smarter here. Some say it adds security; others disagree. Let me ask this: does IPv6 benefit me in any way if I have multiple devices at home behind a router and I'm not running any servers or similar services?
No idea what you're doing on a daily basis, but let's grab a not-exactly random example. You and your friends are at your house trying to play an online game of King's Court (it's super checkers!) with some friends in Denmark. For whatever reason the developers decided all clients will use port 12345 to communicate. In ipv4 with NAT, local connections will be possible but only the first one to try to communicate out will ever possibly succeed. You and your friend are thwarted and have to find some NAT-defeating means or just give up on doing 10-jump moves to ruin each other's evenings and have an internet drinking game. With IPv6, all of it works fine.
Most casual users have lived with NAT so long they assume its limitations are natural. But they are not. You can achieve the same result with a firewall or ACLs or whatever on ipv6, but that's a choice and not a limitation.
Do you play video games with P2P networking? Then your choices are to pick one of the following:
- the hosting player enables upnp
- use ipv6
- the hosting player manually sets up port forwarding (consumer routers often talk about a DMZ option which takes an IP address - really this is just forwarding all ports not matched by any other rule)
Smart home and lighting standard Matter over Thread requires it. Discovered this after i bought some Ikea smart lights. Though you don't need a public IP6, a local static IP6 with SLAAC is enough.
I think two things can be true here: the article's assertion that "IPv6 is not insecure because it lacks NAT" is correct, and other peoples' assertions that NAT provides an extra layer of security are also correct.
A correctly configured IPv6 firewall provides equivalent protection to a correctly configured IPv4 firewall and NAT. Either way, connections that do not originate from within the local network are going to be rejected.
But if the firewall is misconfigured, then NAT will make it more difficult for an attacker on the internet to discover and exploit vulnerabilities on the local network.
"Defense in depth" is a valid security principle. But NAT also creates real-world problems that IPv6 solves. As with all things, there are tradeoffs, and whether or not you should enable IPv6 on your local network depends on your use case.
Ipv6 also creates real world problems that NAT solves -- multi upstream WAN with path selection for example
Dual stack introduces security problems (you now have two things to secure). There are still devices which will fail to run on an ipv6 network -- even with a 64 gateway (software which communicates to a specific IP address for example - e.g. a device which "checks internet connectivity" by pinging 1.1.1.1 and 8.8.8.8, yes it's terrible, and yes it happens)
The is a huge difference between: I assume my crappy router's firewall works and is configured safe by default. And I assume my crappy router's doesn't forward ports by default.
NAT is not inherently a security feature, however where NAT happens is somewhat important.
A local router that I can control deals with how to map from my public IP to my private IPs.
This is not security but is obfuscation of the traffic.
Obfuscation becomes almost impossible in the IPV6 context where NAT isn't necessary, it becomes optional, and given the likely trajectory that option will be exercised by sophisticated enterprise customers only.
As the article mentions, if you want to use NAT with IPv6, you can. The fact that it's optional doesn't mean that address obfuscation is suddenly impossible.
It means it is not by default, which as we know, is a powerful choice these days.
ie enterprise customers will enable it, consumers will do it if they are tech savvy and your mom/dad/granddaughter/grandson/nephew/niece will have the default option.
when you are at home you will have nat and when you are not you will be uniquely identified.
If you can be uniquely identified without NAT then you can be uniquely identified with it too, because IPs don't contain your identity. You get them from a combination of the network prefix and a random number generator.
There's generally no reason to be enabling NAT when you have enough address space to not need it. It can be a useful tool in your toolbox sometimes, but it's not something to be enabling by default.
I'd argue not about security, but transparency - when having your mac address partially included in the IPv6, you would basically allow browsers and other systems identify you without additional steps.
Early IPv6 commonly used EUI-64 addressing, which did embed your MAC address into the IPv6 interface ID
Sure, but your MAC address is easily spoofed. In fact, all major operating systems do it nowadays for public WiFi systems and you have to explicitly opt-out of randomising your MAC Address when connecting.
I hate NAT with a passion. It's a terrible technology, whose disruptive nature has probably prevented any novelty on the transport layer. But this article is oversimplifying things.
It is well known that NAT is not meant for security and that NAT is not a firewall. But one cannot deny that it implicitly brings some "default" security to the table. With NAT it's basically impossible to screw you over because there is no meaningful practical way to allow inbound connections without the client explicitly defining them (port forwarding). With IPv6, you could have a lazy vendor that does not do any firewalling or a has a default allow policy or maybe buggy firewall. With NAT that is not possible. There is no lazy/buggy NAT implementation that allows inbound connections for your entire network, because it is technically not possible. When a NATting device receives a packet with a destination port that has not previously been opened by a client, it does not decide to drop this packet because of a decision by the vendor. It drops the packet because there is simply no other option due to the nature of NAT. That is what people mean when they talk about the inherent "security" of NAT.
Again, NAT is terrible. We need to finally get rid globally of IPv4 and all the NATting that comes with it. But let's keep it to the facts.
> there is no meaningful practical way to allow inbound connections without the client explicitly defining them
This... just isn't true though. Your router knows it has one network on one interface and one network on another interface and if it receives a packet on the one interface destined for the network on the other interface will happily route it unless something (a firewall) tells it not to. All the protection comes from trusting your ISP and its peers to not route RFC1918-private networks
It's wild because saying that NAT is required kind of admits your machines are vulnerable on the LAN! You should have good firewall rules no matter what.
Maybe it’s because I don’t consider myself a super technical person, but I find it so hard to parse the title of this blog post. When I first read it, I thought it was saying something like, “The protocol is not insecure, and the reason is that it lacks a NAT”. However, after reading the blog post, it seems like it is intending a different meaning. The meaning I think is, “the protocol is not insecure just because it lacks NAT”.
Defence in depth is a valid security approach, and NAT provides another defence in depth
If you have a vulnerable ipv4 machine on 192.168.0.24 port 2345 which is hidden behind a public IP of 1.2.3.4, and you set your firewall rule to allow any inbound traffic, with no nat rules then it will be exceedingly difficult for a remote attacker to reach that vulnerable port (they have to trick your router's connection table into routing it)
If the same machine is on 2100:1234:5678:a::24 then that port is exposed.
Now sure your firewall could block the traffic, and that's great. But having multiple layers of active configuration to allow the traffic through is more secure than having a single layer as it means you need to screw up twice.
Worse than that with dual stack you may think you have set your firewall to block non-established connections at the ipv4 stage, but your device is sat there on an open ipv6 address you didn't even consider. Dual stack is certainly less secure than single stack as there are two opportunities to screw up.
It’s the same layer. On router admin panels it’s literally the same UI for firewall rules and nat port forwarding. If you went in to your router admin and allowed all ports on v4 it would be exactly the same as allowing all on v6. The router will happily forward all connections to v4 devices the same.
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.
This article may have been prompted by my (or similar) response to John's comment on [1] yesterday.
He stated:
> NAT is not a firewall: all it does is rewrite packets, it does not drop them.
I noted (without quoting at the time) that the article actually mentions this aspect of NAT, here is a quote from yesterday's article:
> Time and time again we are lectured that NATs are not a good security device, but in practice NATs offer a reasonable front-line defence against network side malware scanning and injection, so there may be a larger story behind the use of NATs and device-based networks than just a simple conservative preference to continue to use an IPv4 protocol stack.
Since I didn't state it before, I don't see any need to add NAT to IPv6 and certainly not for security reasons when a firewall is the correct way to secure networks. I don't feel that IPv6 is inherently more or less secure than IPv4, regardless of NAT. I also agree that even for IPv4, firewalls should be used and that NAT should not be relied on as a security measure for any remotely high stakes situation.
The reason I made my comment though is because I seem to share the same opinion as yesterday's article's author that people stating "NATs are not a good security device" are missing the point that in regard to IPv4, NAT may not be a "fully proper" security measure, but in practice it is "plenty good enough" for the vast majority of internet users.
People proclaiming how NAT is not a security measure seem to me to be ignoring our reality where 100s of millions of consumer routers, incidentally but nevertheless effectively, use it as one. Even without a firewall to drop packets on these devices doing NAT, they effectively block a whole class of automated malicious activity.
Is it safe to have unprotected network devices shielded only by NAT without a firewall? No, not really.
Should you use a proper firewall even if you have NAT? Yes, absolutely, but a lot of people don't and are nevertheless adequately protected considering they probably have no "open" devices on their network and have no particular reason to be targeted by a truly determined malicious actor.
nitpick on the title, the way it's worded makes it sound like "IPv6 is not insecure because it lacks a NAT, (but it's insecure because of other reasons)".
would be better if it was "Lacking a NAT doesn't make IPv6 insecure".
I’m not using any networking implementation that’s less tested and ipv6 is less tested. Network routing means there are dozens of TCPIP implementations touching traffic. The benefit of ipv6 for my case isn’t worth the risk. If you’ve never run into an ipv6 specific bug good for you.
An incoming message to an IPv4 NAT router will not be forwarded to a LAN device unless it matches a known flow (typically continuation of a conversation, typically initiated by the LAN device, which is expected), or the user set up a DMZ forward to a particular destination. There is actually no reasonable way for non-DMZ LAN devices to be exposed to the noise.
For non-NAT IPv6, sure a firewall might be on by default, but it can be turned off - and therein lies the potential exposure to every LAN device to directed traffic.
In other words, the risky zone for IPv4 NAT tends to be setting up a DMZ exposing 1 device, while the risky zone for IPv6 non-firewalled tends to be exposing all of the devices behind the router.
Disabled protection does not protect. This is UI/UX thing, not something in Internet-scale protocols.
I can "curl https://somethingshady | bash -" but won't blame RFC1738.
Discussions about NAT very often forget that it works by messing up with the transport layer. The fuzz is about hiding IP address and exposing services, but the worst thing about NAT is that technically it should not count as a connection to "the Internet".
It exploits TCP/UDP properties to fake endpoints into thinking they have a proper connection.
To visualize this, imagine we somehow are out of available email addresses. Email providers have an idea, they would make one inbox for multiple people and have an SMTP proxy that will read the message content, look at "Dear ..." heading and proxy content as new message to "internal" network. All clients would see the same internal addresses from private space (picture 192.168.1.1), but upon sending the provider proxy replaces it adding "King regards, <shared address>".
What if someone format the text differently? What if they use new format unknown to the proxy? It just won't work: https://en.wikipedia.org/wiki/Protocol_ossification
Someone would then argue it is good as it hides your real address from spam and theft, but we can clearly see the massive disadvantages in this design.
IPv4 is not secure because it requires a NAT in order to be?
Big centralized online services does not want IPv6 because it "unlocks" internet as intended, full p2p at scale. They won't let that happen easily.
And please stop with that 'computers security', we all know here it does not exist (NAT or not), it is a fantasy. Saying otherwise is engaging in bad faith.
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".
So with IPv4 with NAT you definitely have this security. According to this article with IPv6 you MIGHT have that security -we don't know. That's not secure.
I have yet to see a "NAT is not security" rebuttal that does not make either one or both of these points:
- NAT is not a security feature because it wasn't designed as one (this post), and/or
- NAT is not a security feature because it does not, without a firewall, protect against an attacker on the WAN subnet, or another difficult-to-exploit scenario.
And yet making LAN devices unroutable from the Internet does on its own makes exploitation much more difficult. It's admittedly not a perfect measure, but it's one that IPv6 deployments with routable addresses for LAN devices lack. I would wager this does make a difference in the proliferation of botnets, especially given the lackluster standards of consumer network equipment security.
You should read my other comments on this post. I've attempted, multiple times (but apparently without much success) to make the point that NAT is not a security feature because it does not, without a firewall, protect against an attacker.
You don't need a qualifier like "on the WAN subnet". It just doesn't do anything to protect you from inbound connections at all.
I think you're not technically wrong, but you're defining NAT differently than the majority of people you're arguing with (those who assume NAT also implies a firewall blocking inbound connections), and the remaining minority (the "on the WAN subnet" crowd) are dismissing outright the idea as a reasonable attack vector that an attacker close enough to be able to send packets destined for non-internet routable addresses to your router.
Is the latter something that was/is actively exploited?
Networking folks love to write this article. “NAT isn’t a security layer.” I’ve been hearing it for 20 years. But while that’s not its purpose and while there are other layers that can provide the same features, it’s still a very useful piece of a larger puzzle of defining borders in a network architecture. Sometimes it helps if those borders are obvious to the eye, via the use of a private address zone, or if opening a port on the server can never “just work”, regardless of your external firewall rules. All sorts of trivial mistakes can be avoided with This One Weird Trick. So sure, it’s not technically required, and doesn’t solve every problem. But the constant harping about “NAT isn’t security” is sorta pointless.
NAT is a trivial feature on top of a connection tracking firewall. It also provides a large number of benefits - the ability to route traffic via different routes with PBR, without having BGP upstream, to keep routing decisions in the router rather than on each device, to not have to renumber internal IP addessing when the ISP changes, to have consistent view of what happens at a network level
I actually wanted to write this article myself but every time I started writing it up I thought "fuck, this is too obvious, I'm being condescending". But then I read these comments and I'm sad again.
I wrote that comment, and you can write to yourself how many times you want that NAT is not a firewall.
The truth of the matter is that NAT absolutely _is_ a firewall in _practice_. Not in theory "because it doesn't drop packets" or "because it was not meant to be a security feature". But in the actual real-world practice.
It effectively protects most networks from most attackers without ANY additional configuration, making it inherently foolproof.
Here, I put a private key for a wallet with 0.01 bitcoin at this address: http://192.168.80.26/ Go on and take it. It's not protected by anything else I disabled everything but NAT. Heck, here's my real IPv4 even: 172.56.107.111
Is this a _good_ reason to not do IPv6? No. But it absolutely _is_ a reason and needs to be acknowledged.
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.
If you don't have RPF enabled on your router in theory your upstream peer can send traffic to 192.168.80.26 and it would pass through. Reply traffic may or may not be natted depending on how it's entered in the connection tracking table.
There may be situations where your router can be tricked too, I can't think of one off the top of my head which wouldn't also apply to a stateful firewall sitting on a routed network segment with no nat, and it would typically be a vulnerability to patch
But your principal is right -- it's far harder to exploit than just connecting to an ip of say 2001:172:56:107:111::192.168.80.25 on port 80
For 99%+ of residential users, the upstream peer is the router owner/operator, so they can just direct the router to hack you if they wished. So this NAT "vulnerability" is not useful in practice, since it can only be used by your upstream which already "owns" you.
It s true. That s not the reason it is insecure. The reason it is insecure is people who infiltrated the committee made sure to make data exfiltration possible through mandatory ICMP for everything.
Good luck setting up proper firewallimg rules for IPv6 while both respecting its specs and preventing hard-to-detect exfil through ICMPv6.
It's a rube-goldberg of a protocol and it s hard to believe it s all incompetence and there ain't t some malice involved.
NAT for IPv4 was an accidental godsend, especially useful in an era where you d hack your neighbors' computers when they where on the same subnet as yours. Don t tell me it didn't t happen for I was doing that on dial-up back in the days.
Thankfully the point is mostly moot because people are still free to use IPv4 at home/companies while having their router using IPv6.
IPv4 shall thankfully outlive me. And I don't t care if it means more work for people working in the "punch the monkey" ads industry.
Makes sense. But I’d argue NAT is still more secure because it physically breaks the connection between your internal host and the outside world. Without an existing routing table there’s no destination to route the packet to.
I disagree with this strongly. The intended use case of NAT or the existence of inbound connections being blocked by routers is irrelevant.
For NAT, of course it isn't meant for security, but it has a side-effect of creating a network boundary, and that has positive security implications.
If your router doesn't have a firewall blocking any connections, NAT still has security implications as it is deployed typically on consumer networks, which is a one-way port-address-translation for outbound traffic.
The important bit here is not NAT or firewalls, but layer 3 network segments!!!
An RFC1918 private addrerss space is not internet routable. Furthermore, routers shouldn't "default route" traffic from arbitrary connected networks by default. But "should" aside, the typical default consumer router behavior is that they don't NAT translate inbound traffic, they can't!
If a random internet IP wanted to connect to port 80 on a device at 192.168.1.200 in your home network, it doesn't know how to tell your router what IP to translate it's request to the router's public IP to. That is the essential positive security implication. In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't forward such traffic.
With IPv6, end devices in your network get a globally routed address, someone can try to connect to that same internal device as my earlier example and succeed with the same exact default behavior in place.
IPv6 is thus, by relative metrics, insecure by default. It does not mean it cannot be secured, but it is less secure than IPv4 in typical deployments where extra care isn't taken to secure it properly. If your answer to this is "well that's just because people who deploy networks are dumb" then save your self the effort or arguing that, it is irrelevant. That is how networks are deployed in the real world, period. People make mistakes in the real world. People don't know best practices in the real world. So out of the box, things need to consider real world hazards, and IPv6 does not do that.
You can support the adaption of IPv6 nonetheless and I would have no disagreement there.
The problem is, as I understand it, is this hypothetical network where there is a NAT but no firewall just does not exist.
>In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't forward such traffic.
This is typically handled by the firewall, not the NAT. You can easily come up with scenarios that without the firewall, the NAT could be trivially defeated, e.g. by port scanning.
It is not, you guys are talking from a specific american ISP perspective where you have these modem+router+gateway+firewall combo devices. Not everyone gets that.
Many get just a modem and buy a cheap router which may not have a firewall. MANY more get just a modem and their laptops are directly exposed to the internet (!!!), those you can't do much about, but many put a "router" that's just a cheap wifi access point with layer 3 routing and NAT. If you chose to "bridge" a device (like those internet exposed laptops) or port-forward, it will just work (even with ISP routers!!) there is no firewall rule change required.
I've worked in this space supporting consumer grade routers, and then worked in enterprise networking. But don't take my word for it, you all can take a trip to shodansafari, how many devices are listening port 3389 and 445 with consumer grade laptop names?
But it isn't a popular thing to say for whatever reason. I guess IPv6 is a political ideology now lol.
The nat is a belt and braces approach - especially when combined with rpf. How will your packet reach 192.168.0.1 from the internet without having a nat rule to translate the packet, even if there is a firewall rule allowing all traffic
(If you control the next hop and the router doesn't have rpf checks on the wan interfaces you can forge a packet with a destination of 192.168.0.1 and route it via the public IP of 40.50.60.70)
I basically disable all ipv6 on my routers & firewalls completely. Waiting for the day we can disable ipv4 completely instead and use only ipv6 without NAT. But then each device will need its own firewall. NAT basically forces you to use some kind of firewall, which applies to all devices behind the NAT. But if we go all-in on IPv6, the firewall-by-default becomes much harder to implement in practice. Then we will need some kind of distributed/federated firewall config to constantly keep devices usable but safe, but then that will introduce a new set attack vectors. So we are kinda screwed for now. We need that new internet, maybe one where you unify static ipv6, dhcp6, dns, firewalls, nat and a few other friends into a single thing. Or perhaps we can use ipv6 only to get a static ip address for each home/building, which then has a small vlan/vpn to group all your devices together using ipv4 internally for ease of use.. which is close to what we currently have with cgnat+ipv4+wireguard+vlans. All round we have a big mess but it works well, if you know what you are doing that is. This is all to say we can even keep net-neutrality for a while longer, we are okay for now but the american/uk/china/india govs plus entities like cloudflare will actually destroy net-neutrality in the long run. Much like email delivery has already been ruined & captured. Sorry for the rant.
Not really. I’m sure there exists some brain dead CPE without a default-deny firewall. It’s just that I’ve never physically seen once, since around 1999 or so.
Bigger commercial gear, sure, but those would be special-purpose equipment that don’t support NAT either.
To a rounding error, everything which has NAT enabled by default also has a default-deny inbound firewall enabled by default.
You seem to have misunderstood how IPv6 works. In a home setup, all the traffic still goes through a single router which typically has a restrictive firewall enabled by default.
Only if enabled for a specific interface/network/zone/grouping... easy to misconfigure. You can easily misconfigure it to work fine for ipv4 but forgot about ipv6. Depending on what router software you use, this will either be easy or hard to spot. Sometimes the router software won't tell you explicitly that a certain interface is not included or that you have a gaping hole in your network somewhere.
If you use a consumer-grade device at home that you don't have full access to (meaning root via ssh and can update packages, cute web ui's alone don't count), you are screwed in other ways either way (hello open CVE's on unpatched routers....). I literally have a brand new Asus router sitting in a box at home, cause it has 3 open CVE's and asus basically dropped support for it, but they still sell them. Oh and I have root ssh access on it - it is running ubuntu 12 underneath it all (disgusting that asus haven't bumped it). Just all garbage. So I built my own x86 dual-nic/Wifi 6E router box that runs openwrt + adguard home + unbound + wireguard (all on proxmox) and all 4 systems update nightly. This setup absolutely crushes the performance versus top spec consumer-grade routers and I get to monitor it properly and update packages daily.
It is not at all "easy to misconfigure". First of all, the manufacturer is going to configure it for you in 99% of cases, just as they do for IPv4. Second, even if you want to roll your own firewall rules, it's trivial to set up a default deny on all incoming traffic.
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.
reply