Environmental protection IS about survival for poor countries. YOU can afford to not care and burn gas because you won't have your life completely and permanently destroyed by global warming. Poor people don't have that luxury.
Rethink your position because it's completely upside down
While I get why, it bugs me that they have comparison images between jxl and other formats, yet it doesn't actually use jxl, as evidenced by all images displaying correctly on my chrome browser.
This is standard practice. They need to use current lossless formats to display examples to people who don't have the format yet. They are still showing accurate examples of compression artifacts. I'm not sure what else you'd expect them to do.
It's sad how much of this thread of supposed hackers comes from people who are simply parroting this dogma because it has been drilled into them. People were even preaching this before IPv6 privacy extensions came into use, either downplaying the privacy issues or outright telling people they were bad for wanting privacy because IPv6 is more important.
I understand the difference between NAT and firewall perfectly well. I have deployed and configured both for many years. The strawman of "NAT without firewall" is pretty much irrelevant, because that's not what people run IRL.
Firewalls are policy-based security, NAT is namespacing. In other fields, we consider namespacing an important security mechanism. If an attacker can't even name a resource they're not allowed to access, that's quite a strong security property.
And of course, anyone can spoof IP and try to send traffic to 192.168.0.6 or whatever. But if you're anywhere in the world other than right inside my ISP's access network, you can't actually get the internet to route this to my local 192.68.0.6. On the other hand, an IPv6 firewall is one misconfigured rule away from giving anybody on the planet access.
Yeah, I think it is a bit more subtle of an issue than this flamewar always descends into.
There's people upthread arguing that every cellphone in the country is on IPv6 and nobody worries about it, but I'm certain there are thousands of people getting paid salaries to worry about that for you.
Meanwhile, the problem is about the level of trust in the consumer grade router sitting on my desk over there. With IPv4 NAT it is more likely that the router will break in such a way that I won't be able to access the internet. Having NAT break in such a way that it accidentally port forwards all incoming connection attempts to my laptop sitting behind it is not a likely bug or failure mode. If it does happen, it would likely only happen to a single machine sitting behind it.
OTOH, if my laptop and every other machine on my local subnet has a public IPv6 address on it, then I'm trusting that consumer grade router to never break in such a way that the firewall default allows all for some reason--opening up every single machine on my local subnet and every single listening port. A default deny flipping to a default allow is absolutely the kind of security bug that really happens and would keep me awake at night. And even if I don't go messing around with it and screw it up myself, there's always the possibility that a software bug in a firmware upgrade causes the problem.
I'd like to know what the solution to this is, other than blind trust in the router/firewall manufacturer or setting up your own external monitoring (and testing that monitoring periodically).
Instead of just screaming about how "NAT ISN'T SECURITY" over and over, I'd like someone to just explain how to mitigate the security concerns of firewall rulesets--when so very many of us have seen firewall rulesets be misconfigured by "professionals" at our $DAYJOBs. Just telling me that every IPv6 router should have default deny rules and nobody would be that incompetent to sell a router that wouldn't be that insecure doesn't give me warm fuzzies.
I don't necessarily trust NAT more, but a random port forward rule for all ports appearing against a given target host behind it is going to be a much more unusual kind of bug than just having a default firewall rule flipped to allow.
You could set up a monitoring solution that alerts you if one of your devices is suddenly reachable from the internet via IPv6. It will probably never fire an alert but in your case might help you sleep better. IPv6 privacy extensions could help you too.
In practice I don't think it's really an issue. The IPv6 firewall will probably not break in a way that makes your device reachable from the internet. Even if it would, someone would have to know the IPv6 address of the device they want to target - which means that you have to connect to a system that they have control of first, otherwise it's unlikely they'll ever get it. Lastly, you'd have to run some kind of software on that device that has a vulnerability which can be exploited via network. Combine all that and it gets so unlikely that you'll get hacked this way that it's not worth worrying about.
Thank you. This is the first time that someone admits here that NAT actually adds some security. IPv4 will never go away less that an important share because of it's simplicity and NAT-level security it offers to millions of professionals and amateurs that tinker with their routers.
> SLAAC is more complex than IPv4 w/ NAT w/ DHCPv4? Serious?
Yes? Has this ever been in question?
Stateful DHCP provides a _reliable_ way to configure clients, while SLAAC is anything but. It's also insufficient in itself if you want to configure things like NTP servers.
But that's not the main issue. The main issue is that with SLAAC you are supposed to hand out real routable addresses. That are _not_ controlled by you, so the end devices need to be able to handle prefix withdrawals and deprecations. This can lead to your printer not working if your ISP connection goes down and it has no more active IPv6 prefixes.
So you also need a stable ULA. But even that is not a guarantee because source IP selection rules are, shall we say, not the best.
But wait, there's more! You can trivially load-balance/failover NAT-ed IPv4 network over two WAN connections. Now try to do that with IPv6. Go on. I'll wait.
Except in the real world everyone is also running UPnP, so NAT is also one misconfiguration away from exposing something publicly. In the real world your ISP might enable IPv6 one day and suddenly you do have a public address. Relying on NAT is a bad idea because it's less explicit, a firewall is saying you only want to allow these things through, of course nothing is perfect, you can mess up, but NAT is just less clear, the expectation is not "nothing behind NAT should ever be exposed", it's "we don't have enough addresses and need to share".
Sure, and that's fine, but relying on it isn't, and it isn't a reason not to use IPv6 (if you want namespacing, there are tools for that outside hiding behind a single IPv4). Hence the advice is not to rely on NAT.
This is people talking past each other, and to be fair, saying "everyone" in my post made it unclear, I was being glib in response to "because that's not what people run IRL", when evidently people do, I've seen it happen.
I think this is where the disconnect is: the home users are precisely the ones being talked about, because they are the ones most likely to be treating NAT like it is a security system for their devices in the real world.
I've literally seen someone's ISP turn on IPv6, and then have their long-running VNC service compromised because they were just relying on NAT to hide their services.
> If an attacker can't even name a resource they're not allowed to access, that's quite a strong security property.
This is entirely incorrect. An attacker can still name a resource, it only has to guess the right port number that is mapped to that resource.
That's how NAT fundamentally works after all, it allows you to use the additional 16-bits of the port number to extend the IP address space. Any blocking of incoming traffic on a port already mapped to a local address is a firewall rule.
The reason that it offers protection is because attackers aren't going to try every single port. Compared to that IPv6 will offer more protection as an attacker would have to guess the right address in a 64-bit namespace rather than just a 16-bit one.
You are wrong because you are being overly pedantic.
NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate).
Your definition of security is too narrow.
And saying that NAT is broken all the time, implying that NAT is not security, is ridiculous. SSH is 'broken' all the time. TLS is broken all the time.
Here's the end point: NAT effectively reduces the attack surface for a home network to the router. That is security, practically speaking.
> And indeed, if a firewall is off NAT can still function (if NAT is separate).
Well technically you can translate your /16 to look like a different /16 from the outside. IE each internal address gets turned into its own separate external address.
But that's not how NAT gets used in practice. How it actually gets used is to but many hidden addresses behind one or a few public addresses. And that multiplexing necessarily implies that incoming connections must be specifically told where to go; ie that there's a firewall.
Let's say your LAN is using 192.0.2.0/24, and your router has 203.0.113.42 on its WAN interface. With NAT, outbound connections from 192.0.2.x will appear to be coming from 203.0.113.42 -- in your words, the 192.0.2.x addresses on the LAN are hidden behind 203.0.113.42.
Now imagine an inbound connection to 192.0.2.10. Does this connection need to be told where to go? It already clearly states where it needs to go in the packet itself: to 192.0.2.10, and the fact that your outbound connections all appear to be coming from 203.0.113.42 didn't prevent that at all.
So no, NAT doesn't necessarily imply that incoming connections need to be told where to go. The packets themselves can specify that.
> NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
Any good firewall does the same, by having a default “no” rule for incoming connections.
> A firewall is not required for NAT to work
Do you have any examples of NAT that isn't implemented in a more general firewall subsystem?
> NAT effectively reduces the attack surface for a home network to the router.
While true, this doesn't add to the argument for/against IPv6. That is just security provided by default configuration, which can be provided many other ways and could be before the subset of NAT you are talking about was common.
> Do you have any examples of NAT that isn't implemented in a more general firewall subsystem?
When I was a network engineer, we did NAT on edge routers for B2B connections all the time. Like literally hundreds of thousands of them. I am 100% serious on this.
My understanding is that almost all edge routers provide at least basic firewalling, not just pure routing. How were you “doing NAT” on the edge routers you were using otherwise?
(Baring in mind that what most people are referring to as NAT here and elsewhere is “IP masquerading with connection tracking” rather than simple static SNAT & DNAT)
In an enterprise network, it's very, very unlikely that an edge router is doing any firewalling. They can do it, but it's not only cumbersome to do it there, but also a massive resource drain.
Often they do basic stateless packet filtering, but definitely nothing akin to stateful, connection-oriented firewalling. It's important to make the distinction, because filtering in this case is completely uni-directional and if you want bi-directional equivalence you have to write an inverse rule for it. Filtering polices are applied per interface, so generally you apply them on the outside only.
Think of it as sort of a reverse of an inbound Internet policy - you write all the drop stuff first (e.g. drop any any eq snmp) and the last rule is a permit ip any any. Next hop is your firewall which does the rest.
For site-tos-site b2b connections, we performed NAT (of the untrusted network space) on the border/edge b2b router, and then the traffic was immediately routed to the firewall. So in this instance, NAT was happening on the router for the customer IP range, and on the firewall for our enterprise IP range.
As a convenience to our customers/partners we always presented ourselves as one of our public IP blocks that wasn't Internet-routed. This prevented them from having any overlapping IP space.
Otherwise, NAT is simply a question of configuring it. And at least in the cisco IOS world (I'm a dinosaur) the two features (NAT vs. firewall) are utterly independent.
> but definitely nothing akin to stateful, connection-oriented firewalling
This is where my confusion comes in, I think.
Surely the variety of NAT that significantly improves the IPv4 address starvation problem (IP Masq by its various names) requires a connection oriented approach to be effective? Maybe not as far as more advanced conntrack rules (trying to get connect-back based protocols to work) but even just a basic stream-over-one port protocol needs basic connection tracking so return packets get back to the right host? If you have enough resource to do that then you have more than enough resource to do the basic “block all external apart from these configured addr+port->addr+port combinations” for IPv6 that is all the protection NAT affords you by accident for IPv4.
> Surely the variety of NAT that significantly improves the IPv4 address starvation problem (IP Masq by its various names) requires a connection oriented approach to be effective?
Actually it doesn't. Well, not really.
With NAT you're generally talking about either 1:1 or 1:many (Masquerading).
In all cases the device doing the NAT maintains a table which is referenced for every matching packet that arrives or leaves.
In 1:1 NAT, the IP in the packet header (Layer-3) is simply rewritten from one address to the other whenever a packet matching both addresses in the NAT table leaves or arrives.
In 1:many NAT, the source port is randomized because you can run into collisions when multiple clients are connecting to the same server:port. So in that case the NAT table contains IP addresses as well as ports. When a return packet arrives, it checks the NAT table and rewrites both the L3 and L4 (port) info before passing it along.
Often times firewalls will randomize the source port when doing 1:1 NAT as a security measure, but after all these years I don't really remember why that's helpful. :-\
But that's really the extent of tracking connections with NAT.
Now when you're talking about firewalling, there's a lot more to track, such as connection start/stop/timeouts/lifetimes, total throughput, TCP state (handshakes, sequence numbers, etc.), closing open sessions when seeing things like TCP RSTs or FINs or ICMP unreachables. The amount of data and CPU is dramatically higher, and tailored to the software doing the firewalling. I believe in many cases simple L3/L4 rewrites can happen in hardware.
I haven't talked about any of this in several years so I hope I'm making sense.
> NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
Which NAT?
A 1:1 'basic' NAT [1] could allow stateless flow between two different address schemes. Then you have NAPT where multiple IPs can be mapped via one-IP-many-port system, in which you need state and thus have a filtering mechanism.
Similarly you can have IPv6 ULA and do a stateless address translation (NPT) without any blocking policy, which would achieve the same (lack of) security as the 1:1 scenario above.
Address translation can have the same level (or not) of security in both IPv4 and IPv6.
It doesn't though. NAT edits your outbound connections to appear to come from the router's IP; it doesn't do anything to make inbound connections harder.
If you don't initiate a corresponding outbound connection first then any attempt at an inbound connection will be dropped (unless you have a DMZ configured ofc). The router literally can't forward the traffic because it doesn't know where it should go.
No, the router doesn't forward it because it doesn't get there in the first place. Your 192.168.1.0/24 private network is not going to be routed across the internet.
Sure, but the Internet will not route packets going to RFC1918 addresses. So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped. And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused.
This is all behavior that happens even with no firewall whatsoever.
Because this is exactly what the GP was claiming, and you denied: even without a firewall, packets that don't correspond to an open connection will get dropped by a NAT, even without a firewall. Sure, maybe "dropped" is wrong, as the NAT box will probably instead send a RST packet, but this is almost entirely irrelevant.
Right, we were talking about NAT. So how is any of that non-NAT-related stuff relevant?
> Sure, but the Internet will not route packets going to RFC1918 addresses
This is about RFC1918, not NAT.
> So, if you're using an RFC1918 address on the LAN side of the router like every sane admin, packets that actually arrive to the router from the Internet with an IP address other than the router's own IP address will get dropped.
This is about reverse path filtering, not NAT.
> And those that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection or an explicit port forwarding rule will also get refused.
And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.
> And this is... actually not true. If there's a server listening on the relevant port, the connection is accepted.
Fine. Packets that arrive at the router with the router's own IP address and a port that doesn't correspond to either an open connection, an explicit port forwarding rule, OR the port of a service on the router itself listening on the WAN IP will also get refused.
The point is that any LAN box sitting behind the NAT will not get that packet, same as if the router had a stateful firewall running.
And sure, this is not purely a property of the NAT itself, it's a combination of the Internet not routing private IP addresses, reverse path filtering, and NAT. That still doesn't need any firewall to achieve this.
Well no, it's purely a property of the fact that the packet is addressed to the router.
If the packet is addressed to a machine on the LAN, neither RPF or NAT will protect you from it. "The Internet won't route to private IPs" only protects you if you have private IPs on the LAN, and even then it only protects you from people who can't get access to the network on your WAN interface.
Any way you dice it, NAT isn't providing any protection.
> NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
No... it doesn't do that.
NAT edits your packets so that your outbound connections appear to come from your router's IP. If you set up a port forward rule, then it edits matching inbound connections so they appear to be coming to a different destination IP.
Notice how no part of that description involves blocking or preventing inbound connections. That's because that's just not something NAT does.
Non-routeable internal addresses are pretty effective at preventing external actors. When most people say "NAT", that is what they mean.
You are technically correct in that 1) disallowing external actors is not a property of "NAT" itself, 2) theoretically someone could establish routing to your RFC-1918 network if they had ISP control or had layer-2 adjacency.
Practically speaking, this is not a problem. NAT + RFC-1918 addressing provides a layer of security. Is a firewall better? Of course.
So what do you think will happen with a packet that arrives at the router with destination IP set to the router's IP, and destination port set to some port for which there is no port forward rule (and no currently open TCP connection)? Will it reach some machine on the network, or will it get dropped/NACKed?
It will reach the router, obviously. If it's a TCP SYN packet and there's a server listening on that port, you'll connect to that server. If there's no listener then you get a RST.
So, assuming the router doesn't have any server running, the connection will be reset, thus protecting all of the machines behind the router from any incoming connection, almost exactly like a firewall (sure, a firewall might just drop the packet instead of responding with a RST). So, in other words, NAT alone can act like a security perimeter, even with no firewall present.
Because no one on the Internet can reach my 192.168.0.7 machine if the NAT router doesn't translate the packet. And the NAT router won't send a packet that arrives with its public IP as dstIP to any machine behind it, unless the port its ports correspond to an open connection, or to an explicitly forwarded port.
>NAT provides security because normally it disallows external actors on the outside from accessing resources on the inside side.
No. NAT enables internal, non-routable (cf. rfc1918[0]) actors on the inside to access external resources on the Internet. Generally, that's done via NAT masquerade[1] (one-to-many NAT), but can also be done with one-to-one NAT.
>A firewall is not required for NAT to work, although many firewalls have NAT built-in. And indeed, if a firewall is off NAT can still function (if NAT is separate).
No. It isn't. And if you enable NAT without firewall rules, it will happily expose your internal network to external actors. In fact, that's the whole point of NAT.
In fact, not using IPv4 NAT is enormously more secure than using IPv4 NAT, assuming you're using RFC1918 addresses internally. Primarily because non-NATted RFC1918 addresses won't be forwarded by routers on the Internet (CGNAT notwithstanding).
>Here's the end point: NAT effectively reduces the attack surface for a home network to the router. That is security, practically speaking.
Again, no. Enabling NAT increases the attack surface for all networks, regardless of type. Without NAT, external actors need to compromise your router first, then get it to accept spoofed packets.
Yes, there's detail that I've ignored, as it's irrelevant to the statements made. Most of that is related to "I want to access Internet resources, but my ISP won't give me anything but a single, ephemeral, routable IPv4 address, so I need to use NAT to share that one address."
That's not an argument for the "security" of NAT, it's an argument for being mad at your ISP, especially if they won't give you a /56 block of IPv6 addresses.
> No. It isn't. And if you enable NAT without firewall rules, it will happily expose your internal network to external actors. In fact, that's the whole point of NAT.
How exactly would a regular NAT implementation, such as s consumer router's NAT, remove security compared to a direct connection? Assuming there is no port forwarding configured, the NAT will drop (or NACK) any packets addressed to the router's IP on any port that doesn't correspond to a currently open connection.
Since the machines behind the NAT have RFC1918 addresses, remote actors will not be able to send a packet to them, other than by sending packets to the router's IP.
So, overall, a NAT box with no firewall rules configured still acts like a stateful firewall for remote attackers. It's true that attackers that have access to the WAN port of the router, such as someone infecting your ISP, can still send traffic directly to the RFC1918 addresses behind the router, and the router would deliver them (whereas with a firewall, those would also get dropped). So a firewall is still preferable, but the difference in security is actually quite low.
> In fact, not using IPv4 NAT is enormously more secure than using IPv4 NAT, assuming you're using RFC1918 addresses internally. Primarily because non-NATted RFC1918 addresses won't be forwarded by routers on the Internet (CGNAT notwithstanding).
This statement makes no sense. If you are not using NAT of some kind, and your machines only have RFC1918 addresses, then your machines can't access the Internet at all. Now, sure, that is quite secure - but you can get the exact same security by disconnecting the WAN port of the router, with the exact same effects - so this is quite irrelevant to the use-cases being discussed.
>How exactly would a regular NAT implementation, such as s consumer router's NAT, remove security compared to a direct connection? Assuming there is no port forwarding configured, the NAT will drop (or NACK) any packets addressed to the router's IP on any port that doesn't correspond to a currently open connection.
No one (at least not me) said anything about a "direct connection" (which I assume means using globally routable IPv4 addresses on your internal systems).
Nor did anyone say anything about not forwarding any ports. In fact, much of the discussion has been about how "secure" NAT is when forwarding ports, with some folks claiming that doing so is all you need. Or did you miss those 80-100 comments?
>This statement makes no sense. If you are not using NAT of some kind, and your machines only have RFC1918 addresses, then your machines can't access the Internet at all.
Exactly. That was my point. And if you add NAT without stateful firewall rules to limit access, your internal systems are exposed.
I tell you what: post the IP address/range of your home network, turn off the firewall you're using and just leave NAT enabled as it is right now and we can see for ourselves just how "secure" bare NAT is. What do you say?
Unsecured NAT (i.e., without, at a minimum, firewall rules limiting connectivity -- a default deny rule at least) is not secure at all.
I've said (now twice) what I had to say. Feel free to disagree (again) and/or downmod my post, but my decades of experience professionally implementing networks, the security infrastructure which attempts to secure them, at the perimeter as well as at the LAN, server and endpoint informs my opinion.
Don't agree? That's fine with me. It's no skin off my nose. I have no axe to grind with you or anyone else around this or anything else.
Have a good day.
Edit: Clarified the "Globally routable" addresses as IPv4.
I've explained before, in many threads, that pure consumer NAT, without a firewall, has exactly the same behavior as a consumer stateful firewall, except for two cases :
1. The ISP is malicious/compromised, and sends packets with RFC1918 addresses on the router's WAN port.
2. The router itself has admin services that are listening on public IPs (eg HTTP server listening on 0.0.0.0 instead of 192.168.0.1), so it itself could be compromised from outside the ISP network.
Except for these two points, there is no difference between the security characteristics of a consumer NAT and a consumer firewall:
1. LAN machines can't be reached over the internet other than through the NAT, since a packet addressed to 192.168.0.7 from Google will not be routed by any ISP.
2. When a packet arrives to the NAT with a destination IP set to the NAT public IP, the packet will not be delivered to any box on the LAN unless (a) its ports match an active connection from a LAN box, or (b) its destination port matches an explicit port forward rule an admin added.
Case (a) above is exactly what a stateful firewall with a default deny rule does. Case (b) is also exactly the same, as if you explicitly open a port in this type of consumer firewall, it will allow any packet matching that port.
Now, I wouldn't disable my firewall, because I don't trust that my consumer router is itself well enough secured, and I don't necessarily trust my ISP's network either. But this doesn't mean that my laptop is exactly as secure if it were to sit behind this router with no firewall as it would be if I disabled both firewall and NAT entirely and gave my laptop a publicly routable IPv4.
This goes against Hyrum's law. NAT provides the behavior 99.9% of users want, usually by default, out of the box. True firewalls can do the same thing, but not necessarily by default, the firewall might not even by on by default, and there's more room for misconfiguration. IPv6 is a security regression for most people, regardless of its architectural merits or semantics of what's a firewall.
I wouldn’t put the number so high. I’ve on several occasions seen not very technical people unnecessarily burn money on VPSes or dedicated hosting providers because they couldn’t expose a game server for a evening session with their friends with the spare capacity on their gaming machine, because of their ISPs NAT setup. 90% would be fairer. However we still shouldn’t be sacrificing securing agency of individual consumers for securing smoother revenue for corporations.
It might be more fair to say that most American residential ISPs don't have to do that because they have access to giant legacy IPv4 allocations. Comcast alone has 65 million IPv4 addresses, for example (including a /8, /9, and /10 and several /11s).
I think they could make more money using CGNAT and leasing those IPs out to data centers. Also another comment in this thread mentions that their cellular plan sold as a residential internet connection doesn't use CGNAT, but their phone plan from the same company does..
Maybe! CGNAT isn't free, of course, you need pretty beefy machines to handle ISP numbers of clients. So, is the capex for the machines, engineering time to set them up, and opex for keeping them running more or less than they'd make back from leasing their net blocks? Hard to say.
NAT implementations get broken all the time (NAT slipstreaming attacks). If a manufacturer is incompetent enough not to have a firewall on by default, they are probably also shipping a vulnerable NAT.
NAT slipstreaming depends on confusing fragmentation assemblers and application aware parsers. Those exist in firewalls as well. It’s not NAT specific.
And that kind of NAT effectively doesn't exist in practice, so that's quite beside the point. Such a NAT doesn't scale to more than 24 devices behind it.
See my reply to your sibling commenter. My comment was not about NAT in general, i.e. I was not denying the very real existence of stateless NAT. Rather, I was disputing the usefulness of the NAPT solution proposed above as a solution to public IPv4 address exhaustion.
> proposed above as a solution to public IPv4 address exhaustion.
It was not proposed as a solution (although, it would work). I'm pointing out that in networking many names are conflated/used generally against their specific definition. NAT/Firewall; Router/Access Point/Gateway; etc.
No, it very much does. If you want to join two network segments such that on one side all devices are on 10.1.X.X and the other all devices are 10.2.X.X, you'd use a mapping between 10.1.a.b and 10.2.a.b
The general context here is about NATting to the public internet at large, not between particular segments. And the parent of my comment was talking specifically about NAPT, which is different from the non-port-based NAT that you're talking about.
This is a terrible argument. First, NAT doesn't provide the security behavior users want. The firewall on their router is doing that, not the address translation. Second, that firewall is on by default, blocking inbound traffic by default, so why on earth would you conjecture that router manufacturers will suddenly stop doing that if NAT isn't on by default? Third, it's not remotely likely that a user will misconfigure their firewall to not secure them any more. Non-technical users won't even try to get in there, and technical users will know better because it's extremely easy to set up the basics of a default deny config. There is no security regression here, just bad arguments.
The firewall on your typical IPv4 router does basically nothing. It just drops all packets that aren’t a response to an active NAT session.
If the firewall somehow didn’t exist (not really possible, because NAT and the firewall are implemented by the same code) incoming packets wouldn’t be dropped, but they wouldn’t make it through to any of the NATed machines. From the prospective any machine behind the router, nothing changes, they get the same level of protection they always got.
So for those machines, the NAT is inherently acting as a firewall.
The only difference is the incoming packets would reach the router itself (which really shouldn’t have any ports open on the external IP) reach a closed port, and the kernel responds with a NAK. Sure, dropping is slightly more secure, but bouncing off a closed port really isn’t that problematic.
NAT gateways that utilize connection tracking are effectively stateful firewalls. Whether a separate set of ‘firewall’ rules does much good because most SNAT implementations by necessity duplicate this functionality is a bit ignorant, IMO.
Meanwhile, an IPv6 network behind your average Linux-based home router is 2-3 nftables rules to lock down in a similar fashion.
It's also trivial to roll your own version of dropbox. With IPv6 it's possible to fail to configure those nftables rules. The firewall could be turned off.
In theory you could turn off IPv4 NAT as well but in practice most ISPs will only give you a single address. That makes it functionally impossible to misconfigure. I inadvertently plugged the WAN cable directly into my LAN one time and my ISP's DHCP server promptly banned my ONT entirely.
> In theory you could turn off IPv4 NAT as well but in practice most ISPs will only give you a single address
So, I randomly discovered the other day that my ISP has given me a full /28.
But I have no idea how to actually configure my router to forward those extra IP addresses inside my network. In practice, modern routers just aren't expecting to handle this, there is no easy "turn of NAT" button.
It's possible (at least on my EdgeRouterX), but I have to configure all the routing manually, and there doesn't seem to be much documentation.
You should be able to disable the firewall from the GUI or CLI for Ubiquiti routers. If you don't want to deal with configuring static IPs for each individual device, you can keep DHCP enabled in the router but set the /28 as your lease pool.
In the US many large companies (not just ISPs) still have fairly large historic IPv4 allocations. Thus most residential ISPs will hand you a single publicly routable IPv4 regardless of if you're using IPv6 or not.
We'll probably still be writing paper checks, using magnetic stripe credit cards, and routing IPv4 well past 2050 if things go how they usually do.
Went to double check what my static IP address was, and noticed the router was displaying it as 198.51.100.48/28 (not my real IP).
I don't think the router used to show subnets like that, but it recently got a major firmware update... Or maybe I just never noticed, I've had that static IP allocation for over 5 years. My ISP gave it to me for free after I complained about their CGNAT being broken for like the 3th time.
Guess they decided it was cheaper to just gave me a free static IPv4 address rather than actually looking at the Wireshark logs I had proving their CGNAT was doing weird things again.
Not sure if they gave me a full /28 by mistake, or as some kind of apology. Guess they have plenty of IPs now thanks to CGNAT.
More like even if they looked at the logs they aren't about to replace an expensive box on the critical path when it's working well enough for 99% of their customers.
I once had my ISP respond to a technical problem on their end by sending out a tech. The service rep wasn't capable of diagnosing and refused to escalate to a network person. The tech that came out blamed the on premise equipment (without bothering to diagnose) and started blindly swapping it out. Only after that didn't fix the issue did he finally look into the network side of things. The entire thing was fairly absurd but I guess it must work out for them on average.
Did you even read the second paragraph of the (rather short) comment you're replying to? In most residential scenarios you literally can't turn off NAT and still have things work. Either you are running NAT or you are not connected. Meanwhile the same ISP is (typically) happy to hand out unlimited globally routable IPv6 addresses to you.
I agree though, being able to depend on a safe default deny configuration would more or less make switching a drop in replacement. That would be fantastic, and maybe things have improved to that level, but then again history has a tendency to repeat itself. Most stuff related to computing isn't exactly known for a good security track record at this point.
But that's getting rather off topic. The dispute was about whether or not NAT of IPv4 is of reasonable benefit to end user security in practice, not about whether or not typical IPv6 equipment provides a suitable alternative.
> But that's getting rather off topic. The dispute was about whether or not NAT of IPv4 is of reasonable benefit to end user security in practice, not about whether or not typical IPv6 equipment provides a suitable alternative.
And, my argument, is that the only substantial difference is the action of a netfilter rule being MASQUERADE instead of ALLOW.
This is what literally everyone here, including yourself, continues to miss. Dynamic source NAT is literally a set of stateful firewall rules that have an action to modify src_ip and src_port in a packet header, and add the mapping to a connecting tracking table so that return packets can be identified and then mapped on the way back.
There's no need to do address and port translation with IPv6, so the only difference to secure an IPv6 network is your masquerade rule turns into "accept established, related". That's it, that's the magic! There's no magical extra security from "NAT" - in fact, there are ways to implement SNAT that do not properly validate that traffic is coming from an established connection; which, ironically, we routinely rely on to make things like STUN/TURN work!
> Dynamic source NAT is literally a set of stateful firewall rules that have an action to modify src_ip and src_port in a packet header, and add the mapping to a connecting tracking table so that return packets can be identified and then mapped on the way back.
Yes, and that _provides security_. Thus NAT provides security. You can say "well really that's a stateful firewall providing security because that's how you implement NAT" and you would be technically correct but rather missing the point that turning NAT on has provided the user with security benefits thus being forced to turn it on is preventing a less secure configuration. Thus in common parlance, IPv4 is more secure because of NAT.
I will acknowledge that NAT is not the only player here. In a world that wasn't suffering from address exhaustion ISPs wouldn't have any particular reason to force NAT on their customers thus there would be nothing stopping you from turning it off. In that scenario consumer hardware could well ship with less secure defaults (ie NAT disabled, stateful firewall disabled). So I suppose it would not be unreasonable to observe that really it is usage of IPv4 that is providing (or rather forcing) the security here due to address exhaustion. But at the end of the day the mechanism providing that security is NAT thus being forced to use NAT is increasing security.
Suppose there were vehicles that handled buckling your seatbelt for you and those that were manual (as they are today). Someone says "auto seatbelts improve safety" and someone else objects "actually it's wearing the seatbelt that improves safety, both auto and manual are themselves equivalent". That's technically correct but (as technicalities tend to go) entirely misses the point. Owning a car with an auto seatbelt means you will be forced to wear your seatbelt at all times thus you will statistically be safer because for whatever reason the people in this analogy are pretty bad about bothering to put on their seatbelts when left to their own devices.
> in fact, there are ways to implement SNAT that do not properly validate that traffic is coming from an established connection; which, ironically, we routinely rely on to make things like STUN/TURN work!
There are ways to bypass the physical lock on my front door. Nonetheless I believe locking my deadbolt increases my physical security at least somewhat, even if not by as much as I'd like to imagine it does.
The difference is that with IPv4 you know that you have that security because there is no other way for the system to work while with the IPv6 router you need to be a network expert to make that conclusion.
Look at this nftables setup for a standard IPv4 masquerade setup
table ip global {
chain inbound-wan {
# Add rules here if external devices need to access services on the router
}
chain inbound-lan {
# Add rules here to allow local devices to access DNS, DHCP, etc, that are running on the router
}
chain input {
type filter hook input priority 0; policy drop
ct state vmap { established : accept, related : accept, invalid : drop };
iifname vmap { lo : accept, eth0 : jump inbound-wan, eth1 : jump inbound-lan };
}
chain forward {
type filter hook forward priority 0; policy drop;
iifname eth1 accept;
ct state vmap { established : accept, related : accept, invalid : drop };
}
chain inbound-nat {
type nat hook prerouting priority -100;
# DNAT port 80 and 443 to our internal web server
iifname eth0 tcp dport { 80, 443 } dnat to 192.168.100.10;
}
chain outbound-nat {
type nat hook postrouting priority 100;
ip saddr 192.168.0.0/16 oiname eth0 masquerade;
}
}
Note, we have explicit rules in the forward chain that only forward packets that either:
* Were sent to the LAN-side interface, meaning traffic from within our network that wants to go somewhere else
* Are part of an established packet flow that is tracked, that means return packets from the internet in this simple setup
Everything else is dropped. Without this rule, if I was on the same physical network segment as the WAN interface of your router, I could simply send packets to it destined to hosts on your internal network, and they would happily be forwarded on to it!
NAT itself is not providing the security here. Yes, the attack surface here is limited, because I need to be able to address this box at layer 2 (just ignore ARP, send the TCP packet with the internal dst_ip address I want addressed to the ethernet MAC of your router), but if I compromised routers from other customers on your ISP I could start fishing around quite easily.
Now, what's it look like to secure IPv6, as well?
# The vast majority of this is the same. We're using the inet table type here
# so there's only one set of rules for both IPv4 and IPv6.
table inet global {
chain inbound-wan {
# Add rules here if external devices need to access services on the router
}
chain inbound-lan {
# Add rules here to allow local devices to access DNS, DHCP, etc, that are running on the router
}
chain inbound-nat {
type nat hook prerouting priority -100;
# DNAT port 80 and 443 to our internal web server
# Note, we now only apply this rule to IPv4 traffic
meta nfproto ipv4 iifname eth0 tcp dport { 80, 443 } dnat to 192.168.100.10;
}
chain outbound-nat {
type nat hook postrouting priority 100;
# Note, we now only apply this rule to IPv4 traffic
meta nfproto ipv4 ip saddr 192.168.0.0/16 oiname eth0 masquerade;
}
chain input {
type filter hook input priority 0; policy drop
ct state vmap { established : accept, related : accept, invalid : drop };
# A new rule here to allow ICMPv6 traffic, because it's not required for IPv6 to function correctly
icmpv6 type { echo-request, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept;
iifname vmap { lo : accept, eth0 : jump inbound-wan, eth1 : jump inbound-lan };
}
chain forward {
type filter hook forward priority 0; policy drop;
iifname eth1 accept;
# A new rule here to allow ICMPv6 traffic, because it's not required for IPv6 to function correctly
icmpv6 type { echo-request, echo-reply, destination-unreachable, packet-too-big, time-exceeded } accept;
# We will allow access to our internal web server via IP6 even if the traffic is coming from an
# external interface
ip6 daddr 2602:dead:beef::1 tcp dport { 80, 443 } accept;
ct state vmap { established : accept, related : accept, invalid : drop };
}
}
Note, there's only three new rules added here, the other changes are just so we can use a dual-stack table so there's no duplication of the shared rules in separate ip and ip6 tables.
* 1 & 2: We allow ICMPv6 traffic in the forward and input chains. This is technically more permissive than needs to be, we could block echo-request traffic coming from outside our network if desired. destination-unreachable, packet-too-big, and time-exceeded are mandatory for IPv6 to work correctly.
* 3: Since we don't need NAT, we just add a rule to the forward chain that allows access to our web server (2602:dead:beef::1) on port 80 and 443 regardless of what interface the traffic came in on.
None of this requires being a "network expert", the only functional difference in an actually secure IPv4 SNAT configuration and a secure IPv6 firewall is...not needing a masquerade rule to handle SNAT, and you add traffic you want to let in to forwarding rules instead of DNAT rules.
Consumers would never need to see the guts like this. This is basic shit that modern consumer routers should do for you, so all you need to think about is what you want to expose (if anything) to the public internet.
Instead of all my devices being behind one IP and using an internal IP subnet, now each device has a globally routable ip address that will be used... Cool great opsec.
>This is a terrible argument. First, NAT doesn't provide the security behavior users want.
Try breaking into my machine. Login:pass are administrator:pa$$w0rd, external ip 58.19.1.129, internal ip is 192.168.1.124, the system is Windows xp, and firewall is turned off on both the computer and the box the ISP gave me.
Sure, okay. You're using RFC1918 on the internal network, so I'll need to connect to your router's WAN interface to do it, but after that it's just a matter of doing `ip route add 192.168.1.0/24 via 58.19.1.129` and then connecting to whatever I want.
How do you want to get me onto your WAN interface? Unless you happen to live near me it'd probably be easiest if you give me a tunnel. Alternately, if you change the internal network to a properly-routed non-RFC1918 range, I can demonstrate this over the Internet too.
I offered to do this once before, and the person I was talking to replied with "so, you're refusing to do it then" and blocked me. So just for the avoidance of doubt: I'm offering to do this, but if you're going to provide the test environment, you're responsible for making sure I can actually reach the test environment. Otherwise you aren't going to learn anything about NAT.
Right, and in a similar situation, if the internal device was given a routable ipv6 address by the ISP's cable modem, you could directly access that device.
This isn't a hypothetical. There are ISPs who do this out of the box. I plugged a linux box into my ISP's cable modem/router in Amsterdam and immediately noticed my ssh port was getting hammered by port scanners. This isn't what most customers, especially those who aren't technically sophisticated, expect.
>How do you want to get me onto your WAN interface?
I've already given you _all_ information you could have realistically squeezed from me. The only thing left for you is to prove that NAT is not a security measure and break into my machine, given that you already have both login and pass.
If you had exactly those parameters with ipv6, you would have already broken in.
And like I said, I can do that if you get me into a place where I can demonstrate it.
If you want me to demonstrate that the lock on your safe isn't doing anything, you have to let me into the room where the safe is. Otherwise you won't learn anything about the lock on the safe.
When we say "NAT" we are specifically talking about stateful one-to-many NAT implementations as found in consumer IPv4 hardware. Such a NAT is largely isomorphic to a firewall with default-deny semantics for incoming connections and default-allow semantics for outgoing connections.
There are other possible NAT implementations that are much less like a firewall, but saying that a NAT does not provide security is a misunderstanding of the terms as they are used.
Not you specifically, but others in other threads have pointet to UPnP as proof that NATs don't provide security. If the existence of UPnP means that NATs don't provide security, then the existence of PCP means that Firewalls also don't provide security.
NAT-PMP, UPnP, PCP, et. all primarily exist because consumer networks that have to share a public IP face more issues than simply opening a port up to the internet. Destination port conflicts, port remapping, discovery of your public IP, are huge fucking headaches that these protocols also assist with.
Given most consumer routers these days can be configured with a mobile app, I could easily foresee a saner alternative where devices could simply ask the gateway if they could open up a port and have a notification sent to a mobile app to allow it.
But, that said, given how many devices are mobile these days I think the benefit of endpoint firewalls shouldn’t be underplayed either.
It's not isomorphic to a firewall, because it doesn't have default-deny semantics for incoming connections.
Think about it for a second. These NAT implementations change the apparent source IP of your outbound connections. How does that block inbound connections? Changing the IP isn't blocking, and outbound connections are the wrong ones.
If a connection comes into your router with a dest IP set to one of your LAN machines, no amount of changing the IPs on your outbound connections will block it.
You literally can't access the internal devices with the NAT implementation on most consumer level router/access points except for packets addressed to the port mapped to an already open connection originating from the inside. This is almost guaranteed to be a random high port. There's no way to access any other port on an internal ip address.
That's equivalent to default-deny.
I think either you're just trying to "well-actually" us or you're confused.
I'm not. You literally can do this, provided there's no firewall. All you need to do is send the router a packet that's already addressed to a LAN machine, and in it goes. "NAT won't translate the packet" doesn't matter if the address is already set to an IP from the LAN.
Most consumer-level routers do have a firewall to prevent it from happening, and if they don't then people describe that router as being "grossly misconfigured" or as having a security vulnerability and similar things, so in practice it'll be blocked. But that's my point: they need the firewall to do the job precisely because NAT doesn't do it.
I think understand what GP is saying; if you manage to get a packet to the internet port of the NAT router with a destination IP of e.g. 192.168.0.123, and the NAT router is running a generic IPv4 routing stack, it will dutifully route it to the internal network.
This can be done by compromising another host on the same link. It can also be done if anything on the same link (including the router itself) is running an improperly configured tunneling setup that lets the attacker send e.g. an IP-in-IP packet that gets unwrapped. The NAT has made it much harder to get a packet establishing an inbound connection to the router, but doesn't actually prevent the establishment of a connection should such a packet get there.
Compare to a default-deny firewall with public addresses on the LAN. Any inbound connections will be dropped, by definition; the lack of NAT makes it trivial to get a packet to the firewall itself, but once it's there, it won't get through.
1. How did a packet with a RFC1918 address reach router; it would require an attacker able to generate packets (or get something to e.g. unwrap an IP-in-IP packet) on the same link, since the router isn't going to ARP any of those addresses. Limiting inbound connections to originate on the same link does provide some measure of security.
2. Will the router even do anything with a packet coming in on the inbound port that doesn't target the public IP? This is implementation dependent.
Of course symmetric or even carrier grade NAT is not a firewall, but it's so silly to ignore real world implications thereof in an IPv4 only deployment scenario. Firewalls aren't foolproof and in real life you average NAT is more likely to be closer to that.
It's scary how much of this thread comes from people who can't imagine a use for keeping internal traffic internal. in ipv4, if my laptop tries to use a printer with a public ipv4 address, that raises alarms. in ipv6, if my laptop tries to use a printer with an ipv6 address...
its not about the firewall. there's just a lot of extra attack vectors without a nat.
I agree with the majority of your point, but hopefully your printer hasn't been assigned IPv6 IPs that are global in nature and is instead limited to site-local.
For anyone who is reading this but hasn't use IPv6, IPv6 addresses are a large flat 128-bit contiguous address space, but they are not universally routable. The prefix of any specific address determines what group of other IPs can get to it.
We often think of a computer as having an IP address, but with IPv6, computers will have several addresses, all with different prefixes to handle different types of traffic.
If you plug your printer into your home network, and if the local DHCP server is configured to hand out globally routable addresses from your ISP provided /64, then your printer will also be globally routable (as well as your "smart" fridge, "smart" TV, "smart" thermostat, etc). In my personal experience this is the default situation with consumer ISP IPv6 setups.
This difference in theory versus practice is precisely why we see people objecting that IPv4 is more secure as far as default configurations go when it comes to home use.
That said, I expect (hope?) that all ISP gear should default to enabling a stateful firewall. Hopefully there's no difference between the default security of an IPv4 and an IPv6 setup in practice. But given the history I'm not entirely optimistic.
Note that DHCPv6 is really uncommon for IPv6, especially on consumer routers - so uncommon that Android doesn't even support it. But your point stands, even more so, with SLAAC.
>This difference in theory versus practice is precisely why we see people objecting that IPv4 is more secure as far as default configurations go when it comes to home use.
I mean, I agree with them. I think people who say 'NAT is not security' are only correct in the absolute most pendantic way and that the way NAT is commonly configured is literally the only reason the internet doesn't consist mostly of botnets.
But I also suspect that if IPv6 were more common, we as a society would be better at it, and not do dumb things like hand out globally routable IPs via DHCP6
The whole premise of IPv6 is that every device should have a globally routable IP. This thread went into DHCP for some reason, but that is uncommon and not recommended for IPv6, where you're supposed to use SLAAC. With SLAAC, I'm not even sure you could realistically disable the ability to get a public IP. And if you did, I'm not sure you could allow a device to access the Internet over IPv6 with a consumer router without it having a publicly routable IPv6.
>The whole premise of IPv6 is that every device should have a globally routable IP
I would agree with the small adjustment of, 'every device should be able to have a globally routable IP'.
There are a lot of devices, like the ones we're talking about, that should not be accessible to the internet at large. You're not preventing them from getting a public IP because you don't have enough, you're preventing them from having a public IP as part of the belt-and-suspenders approach because there's no need to have one.
> in ipv4, if my laptop tries to use a printer with a public ipv4 address, that raises alarms.
The only way that’s possible is that you have a firewall rule blocking outbound connections to common printer ports like 631. NAT couldn’t care less what outbound port you’re connecting to, so it has to be a firewall doing that work.
> in ipv6, if my laptop tries to use a printer with an ipv6 address...
…so enable that same rule you manually configured on IPv4 on the IPv6 firewall, too.
What you’re describing is not default or inherent behavior. If you went out of your way to enable it, you have the skills to do it twice. That’s assuming your firewall is more complicated that “block outbound port <631> to <any IP>”, which covers both protocols on most firewalls I’ve used.
You on the inside can punch a hole to the outside. This is fine. There's no real difference between hole punching and a regular connection to a regular server from one side's perspective.
> NAT is not for security, it does not provide security.
It’s not for security but it absolutely does provide security and pretending otherwise continues to harm discussions.
I have a pile of ipv4-only IoT devices that have no firewalls of their own that are being protected by the symmetric NAT in my home router. Kick and scream all you want but there is security there and nothing on the internet can reach those devices unsolicited, just like a stateful v4 firewall would provide.
I don’t think you understand symmetric NAT. Requiring an entry in the port address translation table to propagate a packet is not the same thing as a stateful firewall.
You absolutely can have a port address translation implementation without a stateful v4 firewall that wouldn’t forward packets destined for inner IPs on the outer interface. Just put an ACL on the external interface to not allow traffic to the inner IP block.
If your public IP from your ISP is 12.13.14.15, and your internal block is 192.168.0.0/24, then your ISP can send a packet to 12.13.14.15 destined for 192.168.0.7, and without a firewall your router will happily forward it. An attacker who can convince intervening routers to send traffic destined for 192.168.0.7 to 12.13.14.15 (and these attacks do exist, particularly over UDP) can also do that.
You're using somewhat sloppy terminology that will confuse things. An IP packet can't be addressed both to 12.13.14.15 AND to 192.168.0.7.
The realistic attack here is that your ISP sends a packet with destination address 192.168.0.7 to the MAC of your router (the MAC that corresponds to 12.13.14.15). This is a realistic attack scenario if the device that your router connects directly to gets compromised (either by an attacker or by the ISP itself).
Getting a public route that would take packets destined for 192.168.0.7 to reach your router over the Internet is far more unlikely.
True, the frame is addressed to the router's hw interface but I'm talking to people who think NAT drops traffic so I figured keep it simple
But, yes, the ISP (or whoever has compromised/suborned/social engineered the ISP) is absolutely the main worry here and I don't understand how people are dismissing that so easily
Okay, so not only do you have to create a bogus packet, you have to convince every piece of equipment in between you and the end user to collude with it, in the hopes that the final router is so woefully misconfigured as to act upon it?
The ISP is the primary threat vector here (do you trust yours? Along with their contractors and anyone who might have compromised them?). But like I said route-poisoning attacks do exist.
yeah but the likelihood of this is incredibly remote. It would shock me if ISPs didn't have alarms going off if RFC1918 space was suddenly routable within their BGP table.
Not to mention the return packet would be NAT'd so the attacker would have to deal with that complication.
The return packet wouldn't be NATed, because stateful NAT tracks connections and only applies NAT to packets that belong to outbound connections.
Arguing over how likely this is is missing the point. If it can happen at all when you're running NAT, then it should be clear that NAT isn't providing security.
“if it protects 99.999% of attackers from reaching you but not this one specific attacker in this one case of misconfiguration, it’s not providing security”…
Dude, that’s a really shitty take and this is why people that do care about security end up ignoring advice from anyone who thinks this way.
You’re in the camp of “don’t use condoms because they can break”.
NAT doesn't protect you from 99.999% of attackers though. It doesn't do anything to incoming connections, so it actually protects you from 0% of attackers.
Okay, but unless you've poked a hole through NAT (and if you have, presumably you know what you're doing), what are those incoming connections going to connect to?
If there's nothing to connect to, is there really an incoming connection?
They connect to whatever IP is specified in the packet's "destination IP" header field. It's exactly the same behavior as if there was no NAT going on.
Or more likely, network engineers who’ve been subpoenaed to collect the information?
Your scenario is plausible for high value targets. Like, what country wouldn’t want to have a friendly tech working at the ISP most politicians use in DC? That doesn’t seem improbable.
For the regular Joe Schmoe, I’d be more concerned with court-ordered monitoring.
Ah, that sounds like an American problem. If you're in the US, you're living in a hostile surveillance state that makes North Korea look like a hippy commune.
No, the router will only forward it with specific implementations that don’t isolate routing tables between the external and internal. Or an easier approach is just a stateless ACL on the external interface. Neither are a stateful firewall.
Send packets to the device? A NAT is in it's most basic form a mapping from one IP/port set to another IP/port set describable by some function "f" and its inverse "g". The common home user case has the firewall detect a flow from inside the network and modify "f" and "g" to allow this flow. Without the firewall, and assuming you want your devices to talk to the internet in some way, the NAT would forward (with modifications) traffic based on "f" and "g" to all your devices.
First they will have to change their policy of only providing one IPv4 address per ONT connection. Then they will have to convince me to disable NAT on my router, disable the DHCP server on my router, and bridge the WAN port with the LAN block.
Meanwhile in IPv6 land the ISP provided router that my relative has came configured by default to hand out globally routable addresses from the ISP provided /64. Thankfully it also had a stateful firewall enabled by default so there was no difference in practice.
> First they will have to change their policy of only providing one IPv4 address per ONT connection. Then they will have to convince me to disable NAT on my router, disable the DHCP server on my router, and bridge the WAN port with the LAN block.
No. They may be able to directly reach your internal addresses with source addresses that are outside your internal ranges through the WAN interface. For example: if you use 10.0.0.0/24 internally, and your special secret webserver is at 10.0.0.2, I might be able to reach it from 10.1.0.1 through your router's WAN interface.
It doesn't matter what the public IP is: the WAN interface is the default route, Linux will forward the traffic unless something is explicitly configured to block it.
Even if outbound traffic on the WAN interface is unconditionally SNAT'd to the public IP, and the replies have the wrong source address/port, I can still use a promiscuous mode AF_PACKET socket to receive them and interact with the internal server (the destination address will be correct, so the L2 frame will be addressed to the attacker's MAC). Or even just install my own SNAT rule to rewrite them again for me, I suppose.
Some ISPs have multiple subscribers on the same L2 segment, it's possible they can do this to each other.
Of course, I'd imagine many consumer grade routers out there do block this, but I've personally seen some that don't.
Yes, but NAT combined with RFC1918 private addresses does provide a layer of security. This is the most common NAT configuration for 99.99% of residential users. It is what most people mean by "NAT."
If your address cannot be routed across the Internet, it can't be accessed, firewall or not.
I have worked in corporate environments where we NAT'd public, route-able addresses for historical reasons. That would be insecure without a firewall and is not what most people are discussing.
The whole discussion is confused from the start. When people talk about the "security of NAT" they are not talking about NAT at all, but about what happens when NAT is misconfigured or switched off. In the case of IPv4 it means nothing works and your computer isn't reachable. The system is fail safe.
Meanwhile with IPv6 it's the other way around, everything is wide open unless you have a working and properly configured firewall.
It's scary how many supposed hackers have never even looked up an RFC before making grandiose statements. There is such a thing as "NAT filtering", see RFC 4787, section 5: https://datatracker.ietf.org/doc/html/rfc4787#section-5
A NAT is not a firewall, yes. At the same time, the NAT boxes out there in the wild absolutely do filter traffic, and yes, it is the NAT that does it, not a separate firewall. Practically all NAT boxes in the wild do stateful filtering. It is not really standardized how they do it, but this is how the real world often works. People argue that the filtering part of NAT is "actually a firewall", but what's the point? From the outside, you will not be able to tell if there's a firewall that filters traffic for which no established connection can be found, or if this is done by a NAT.
Many people are so fixated on the definition that NAT is only address translation and nothing else, they refuse to interact with the real world out there.
I suspect the author was trying to put into words why their technically correct world view is better, but he spends his opening arguing semantics (ineffectually, as apparent) instead of meeting the 'wrong' people where they are and explaining why his semantics are an improvement.
Competency crisis is not limited to just the audience.
I think the confusion stems from the fact that my mom's laptop with its 192.168.0.43/24 v4 address is not routable except via NAT, and people believe (rightly or wrongly) that that confers a degree of security.
UPNP and a dozen other NAT defeating tactics exist and have since the early 2000s. NAT translates addresses. Thinking a non-routable range is safe because it's behind NAT is at this point grossly ignorant of how modern network equipment works. It's kind of like port-knocking; yes it makes the attack slightly harder, but doesn't prevent it.
e.g. symmetric NAT exists and often doesn't come with a stateful firewall. Just because the linux box with iptables is protecting your network uses NAT doesn't mean NAT is doing the heavy lifting here. I can see the OMG MY PRIVACY crew is out in force here apparently misunderstanding that NAT does not do that either. I mean, we can explain things to you, but we can't understand it for you.
>UPNP and a dozen other NAT defeating tactics exist and have since the early 2000s.
I know that, and you know that, but squillions of people think that turning the UPnP setting off (if they even know what that is) is sufficient, which is why the myth persists.
UPnP is only relevant for software that's already running on your machine locally. People here aren't generally talking about outbound connections and I think you both know that. The practical effect of NAT as commonly encountered in a residential setting is to drop inbound unsolicited connection attempts.
And yes, everyone is aware that you could also do that with a stateful firewall. And no, none of us care about arguments of definition that attempt to frame NAT as technically being a firewall based on how it operates in practice. Being intentionally obtuse by refusing to acknowledge the obvious isn't going to convince anyone.
It doesn't confer much since it COULD be only NAT and no firewall.
It's INCREDIBLY unlikely to find a case of that in the wild, but possible.
A common example of a host that might have such an address but lacks that sort of security is anything as the default route for inbound packets, E.G. like you'd want your _own_ router / firewall rather than the ISP's modem.
If the end effect of security is dropping packets NAT and Firewalls both in effect drop packets.
Its kind of just silly pedantry to say NATs aren't security because sure you can't do things like block specific ranges of IPs spamming you (or make outbound rules to control local devices) but 99% of people don't need.
I understand ipv4 networks pretty well. And I would say that any device doing NAT is acting as a basic firewall. Do “true” firewalls do more? Sure. But saying NAT doesn’t provide security is flat out wrong.
If your router had only NAT and someone (i.e. your ISP) sends it a package addressed to somewhere inside your internal IP range, it will happily forward it. A firewall would block it.
The same problem applies to masquerading. Routers are happy to route packets they receive, and NAT (in whatever form) isn't the tool you use to drop those packets.
Ugh, this is part of the reason why I left them, but https://free.fr still does this AFAIR. They were deploying IPv6 to all their consumers well before the other ISPs (more than 15 tears ago), but they have stagnated since.
IPv6 firewall disabled by default. There is only one config for the firewall: on / off. Accept all inbound or reject all inbounding.
To think that they used to brand themselves as "for the geeks", with reverse DNS customization, built-in user-configurable server on the router (all of their routers offer a Wireguard VPN, torrent client, audio output with DLNA & others), a m3u for IPTV, etc. I wouldn't advise anyone to use them due to this issue.
Their basic firewall dates back to 2019: https://dev.freebox.fr/bugs/task/27268 (a lot of spam in the replies there). There was none before, and it is still off by default.
This is no small ISP either, they have more than 50 millions clients (including mobile), and are in the top 10 ISPs in Europe. Baffling.
If there is more than one machine behind the NAT which one would it forward it to? This hypothetical simple NAT without firewall AFAICT doesn’t exist in reality, even if it exists in specs. I don’t see how it actually could.
At this point, nobody trusts the US to pay anything. I don't have an opinion on whether they'll be able to pay their debts, but that's largely irrelevant. I wouldn't bet on them actually paying anything. You can't trust America
I have a sneaking suspicion that AI use isn't as easy as it's made out to be. There certainly seem to be a lot of people who fail to use it effectively, while others have great success. That indicates either a luck or a skill factor. The latter seems more likely.
> The notorious “you are absolutely right”, which no living human ever used before, at least not that I know of
If no human ever used that phrase, I wonder where the ai's learned it from? Have they invented new mannerisms? That seems to imply they're far more capable than I thought they were
To get political points from the anti nuclear crowd, which is huge in Europe. I think proximity to Chernobyl is probably the reason why that movement has grown so badly out of proportion
It’s a shockingly strong movement even still in the US. A lot of education growing up was about how nuclear sludge would ruin everything and basically every “green” movement would still fight nuclear tooth and nail through all sorts of scare tactics.
It’s only in the post climate change world that some are coming around to the reality that France exists and isn’t a smoking radioactive crater.
The German Green party, which has taken part in national governments and is the biggest party in several states, has basically founded to oppose nuclear power.
Something about this painting is reminiscent of the way I(and I'm sure many others) would paint my comic-book heroes at around that age, albeit perhaps lacking some of Michelangelo's talents and skills.
This painting makes me feel like the bible was pretty much a comic book to the adolescent Michelangelo, and I like that thought. He later went on to paint the ceiling of a huge temple dedicated to his equivalent of Charles Xavier.
He hated painting the Sistine Chapel ceiling because he saw himself primarily as a sculptor. You can read some of the graphic language he used to describe his perspective of having to do it. Also, he was constantly in pain and would go temporarily blind from holding his head in certain positions for hours at a time.
This painting is a masterstudy of Schongauer's engraving "Saint Anthony Tormented by Demons". If you look closely you can see how its a study but not a 1:1 copy, but aside from some color and light all of this "style" was michaelangelo copying Schongauer as he learned.
my father made reading The Agony and The Ecstasy a requirement to go to Italy when I was a sophomore in high school. It's a thick tome, but a great read if you're a curious kid.
as the others said Michelangelo hated doing that painting. He's a very tragic, albeit heroic to me, man. I'd recommend that book if you're at all fascinated by him.
There were two St. Anthony's. The one in this painting is the first St. Anthony. He was celebrated by Athanasius in a widely read biography and was famous for fighting off demons in the Egyptian desert. He lived from ~251-356 AD. (But yes, a post-Biblical figure.)
Rethink your position because it's completely upside down
reply