Hacker News new | ask | show | jobs
by dent9876543 485 days ago
That NAT is a problem presumes that we actually want our IoT devices reaching out to the out-of-intranet zone.

NAT gets the blame, and the intranet as a concept is generally a big corp term.

But I prefer my IoT devices not to need to reach out of my network. For me, NAT is an unwitting ally in the fight against such nonsense.

7 comments

The mere existence of Tailscale should give a hint that NAT is only a speedbump and not any protection whatsoever. It protects you against nothing. Every method that Tailscale uses to traverse NAT can be in isolation used by any other piece of software. For more info about that you can read the following article.

https://tailscale.com/blog/how-nat-traversal-works

What people really want is a firewall, and since NAT acts as a firewall, they confuse it with that.

My university has a public IP for every computer, but you could still only connect to the servers, not random computers, from the outside. Because they had a firewall.

What ordinary people (as opposed to IT departments) really want is firewall that can't be accidentally disabled by pushing an overly permissive firewall rule.

NAT/port forwarding, for all their faults make it rather difficult to write rules allowing traffic to a machine you didn't intend to expose to the world.

Consumer routers have very similar UI for managing an IPv6 firewall as IPv4 NAT port forwarding.

This is not in any way a benefit of NAT.

Then... make the firewall UI so that you can't accidentally push an overly permissive firewall rule?

Just because NAT accidentally achieves some good outcomes doesn't in any way imply that said good outcomes are somehow exclusive to NAT.

Yeah but the average person wouldn't know to set up a firewall (and can't count on their ISP to have their best interests at heart.) Therefore the general public benefits from the degree of protection that NAT provides.
Almost 50% of internet traffic is IPv6.

Obviously, those average people have a suitable firewall provided by default on their routers.

I think the vast majority of that is from phones?
It will vary by country, but for example all but one of the large broadband ISPs in the UK use IPv6.
Do they?
Then just enable the firewall by default, or don't even provide a way to disable it unless the user enters "developer/advanced/Pro (tm)" mode. None of these are valid excuses for NAT.
"not any protection whatsoever" is way too strong a statement. NAT does raise the bar to exploiting a random smart lightbulb in your house significantly higher.
The big distinction is that for Tailscale both endpoints know they want to talk to each other, and that both have Internet access. That's not the usual case firewalls are designed for.

Tailscale doesn't strictly need NAT traversal. They can run only their DERP servers and still continue to work. If your firewall tries to block two devices from communicating and yet allows both devices internet access, you have already lost.

Sounds like you like the idea of a stateful firewall, and good news: There are stateful firewalls for IPv6!

They have all the upsides of NATs (i.e. an option to block inbound connections by default), with none of the downsides (they preserve port numbers, can be implemented statelessly, they greatly simplify cooperative firewall traversal, you can allow inbound connections for some hosts).

I found it weird that IPv6 folks are so against NAT as a cultural thing when it works perfectly well on IPv6. They're not fundamentally opposed.

I could have all of my servers in public subnets and give them all public IP addresses, but I still prefer to put everything I can in private. Not only does the firewall not allow traffic in, but you can't even route to them. It now becomes really hard to accidentally grant more access than you intended.

I would hazard that most devices on there internet are in the boat of want to talk to the internet but not be reachable on it.

Yea IPv6 folks are indeed against NAT philosophically because it's considered one of the big mistakes of IPv4.

There is a distinction between being publicly addressable and publicly routable. You can have the former without having the latter.

If you want more private addresses, IPv6 has a solution too: use ULAs and not GUAs. Design your internal network so it has mostly ULAs for application servers, database servers and the like, except for the reverse proxy having both publicly accessible GUAs as well as ULAs for talking to the rest of the network.

I personally use ULAs and GUAs concurrently on my network, because I have a residential ISP where my GUA prefix is not fixed.

I'm not opposed to anyone voluntarily using a NAT at all. I just hate it when somebody makes that decision for me, and that unfortunately still happens all the time.

If it's a well-reasoned decision, sure, but I do suspect that more often than not it's a lack of knowledge about alternatives that makes people still opt for NATs, and that just makes me sad on top of being annoyed with the inconvenience of having to tunnel when a direct connection seems so close at hand.

> I would hazard that most devices on there internet are in the boat of want to talk to the internet but not be reachable on it.

I highly doubt that. One big example is VoIP: Incredibly common these days, yet so much of it is going through centralized relays, and often for absolutely no technical reason.

How do you feel about NPT?
For a personal network where you decide to use NAT on ipv6? Sure, go ahead.

Being forced into a CGNAT on ipv6 is just a dick move though. And I believe that's the kinda NAT that has coloured the opinions of most NAT for ipv6 detractors.

If you don't want that, then complain about a lacking a configuration as such and configure your firewall so that that they can't. But don't cheer on something that's breaking functionality that others might want (especially if it doesn't actually achieve your own goals reliably).
Oh, I do that too.

But to your point about not cheering on NAT, well I will because I see NAT as useful tool.

It is not an opinion well aligned with the preferences of the IETF. But the purist model of transparent end-to-end networking has never sat well with me. It’s just not a thing we want.

So because you don't want it means that nobody can get it?

Because that's what happens if you advocate for NAT by default. Conversely, with "IPv6 + inbound-blocking-firewall on CPEs by default", everybody gets the same behavior by default, and people that want something else can get that instead.

A telematics tracker in a vehicle that logistic companies use (e.g. Amazon, FedEx) is also considered as an IoT device. I don't believe that the author is talking about Smart Home appliances exclusively.
What NAT are you using that doesn’t have a firewall? I haven’t personally used one of those since the ‘90s.
The first NAT I used in the middle 90's was IP Masquerading in the Linux kernel, by Pauline Middelink. That had a firewall.
Same, but ISTR we had some Cisco gear where NAT (or PAT as they insisted; yes, I know difference; no, no one cared) had a different license or hardware requirement or something from firewall rules.
I agree until I discover I'm doing something where I want to access/change that device. It is really nice when I'm returning home early that I can change my thermostat out of vacation mode. I've often wished I had a way to tell if I left a door unlocked.

Security and privacy is of course critical to all this, but the concept of internet itself is not wrong.

That's what a VPN is for. Every router I've had in the past decade has had support for running a VPN server so you can have one running 24/7 without any additional hardware. Even my retired elderly parents run a VPN server on their home router.
> retired elderly parents run a VPN

Does that VPN use certificates or a pre shared key? Do they understand the different security implications between those two choices?

I hope you're not implying that allowing IoT devices access to the internet is not a massive security vulnerability. IoT devices are notoriously insecure and poorly maintained. I'd much rather have LAN-only IoT devices and an internet-accessible VPN server than letting IoT devices access the internet.

But theirs uses certificates (the router UI generates the openvpn client config files with the certificate embedded inside it) and no, they do not understand the security implications between those two choices.

Mine is a wireguard VPN with both the pub/priv keypair and PSK.

I'm implying that a VPN is not a "silver bullet." In particular since they don't understand the model, are stuck with a vendor implementation, and probably never update their router firmware.

There's a reason IoT vendors try to do this all "in device."

Especially if the data is unencrypted and only authenticated by source ip and a long lived token-like thing