Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NAT Is the Enemy of Low Power Devices

blog.golioth.io

Post reply on HN
Print view View original

131–140 of 180 posts

Re: NAT Is the Enemy of Low Power Devices

#131

Post by timewizard »

craftkiller wrote: post #129
bluGill wrote: post #122

Earlier quoted context omitted.

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?

Re: NAT Is the Enemy of Low Power Devices

#132

Post by craftkiller »

timewizard wrote: post #131
craftkiller wrote: post #129

Earlier quoted context omitted.

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.

Re: NAT Is the Enemy of Low Power Devices

#133

Post by [deleted] »

lxgr wrote: post #100
dent9876543 wrote: post #22

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.

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).

[deleted]

Re: NAT Is the Enemy of Low Power Devices

#134

Post by deathanatos »

LegionMammal978 wrote: post #9
api wrote: post #5

Earlier quoted context omitted.

Why?

Eliminating NAT makes virtual networking much hairier. E.g., my desktop is currently connected to a big enterprise network that keeps track of all devices and will only allocate one IP address per MAC address. That leaves no IPs for any VMs on my desktop to use, so they must go through NAT if they want to communicate with the outside world.

"Doctor it hurts when I". Keep track of all devices, and alloc a static /64 per (host) MAC.

And even in the face of a supposed malicious network admin like yours, you can still adopt IPv6, and use the IPv6 private network ranges for the VMs, and then do NAT like it's 1983, same as you would have otherwise done with IPv4, except that all other uses cases get easier, while this one use case remains as hard as it was before.

Re: NAT Is the Enemy of Low Power Devices

#135

Post by timewizard »

craftkiller wrote: post #132
timewizard wrote: post #131

Earlier quoted context omitted.

> 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 i…

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."

Re: NAT Is the Enemy of Low Power Devices

#136

Post by Spivak »

lxgr wrote: post #100
dent9876543 wrote: post #22

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.

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.

Re: NAT Is the Enemy of Low Power Devices

#137

Post by procaryote »

vv_ wrote: post #72
procaryote wrote: post #39

It seems brave to let an IoT device talk to someone over an unencrypted wan though. They're often of pretty varying software quality and rarely updated. If you really want IoT wifi devices, put them on a separate wifi, and only let them talk to a local device that you can keep up to date. Assume they're vulnerable to local attacks over wifi and act accordingly, e.g. don't give the IoT wifi access to your other device…

The issue in IoT is that most people expect to be able to control their IoT (e.g. Smart Home) devices from outside of their network. This requires you to have a central server these devices communicate with or a similar deployment on-premises with a public IP address. I've always wondered how it is economically feasible to run these central services without a monthly subscription. If you stop selling devices you'll g…

Yeah, sadly, people care about convenience and not security. So you get things like this:

https://www.malwarebytes.com/blog/news/2024/04/ring-agrees-t...

and somehow they are still in business, and popular.

If you do care about security, keeping your home-automation within your own control is probably the only sane path. Homeassistant and similar open source things like openhab are pretty good if a bit fiddly, and a wireguard vpn like tailscale a fairly practical way to access it when away from home.

Re: NAT Is the Enemy of Low Power Devices

#138

Post by fc417fc802 »

eythian wrote: post #84
fc417fc802 wrote: post #60

Earlier quoted context omitted.

No, it doesn't. At least the last time I checked unless you go out of your way to implement a non-standard configuration IPv6 is a disaster for personal privacy for the typical multi-user household. Then again, the "typical" multi-user household is likely logged in to most things via SSO with Google or Facebook and probably has approximately zero fingerprinting mitigations in use so perhaps it isn't worth worrying ab…

> IPv6 is a disaster for personal privacy for the typical multi-user household Why? With privacy extensions (which are normally enabled for user devices), then all someone can do is look at the prefix. This is identical to looking at the IPv4 address in a NAT setup, and it hasn't been that much of a privacy disaster. As I see it, nothing is lost on that front.

> This is identical to looking at the IPv4 address in a NAT setup

It is not identical unless the OS uses a new IP for every new outbound connection. I believe that would qualify as a (very) nonstandard configuration.

> it hasn't been that much of a privacy disaster.

Indeed, it was tongue in cheek which is why I went on to point out SSO. The reality is most people aren't willing to sacrifice convenience to retain even a shred of privacy.

If you are one of the few who care then you can implement one of the many possible non-standard solutions.

Re: NAT Is the Enemy of Low Power Devices

#139

Post by kccqzy »

Spivak wrote: post #136
lxgr wrote: post #100

Earlier quoted context omitted.

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…

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.

Re: NAT Is the Enemy of Low Power Devices

#140

Post by kccqzy »

vollbrecht wrote: post #45
dent9876543 wrote: post #22

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.

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

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.

Post reply on HN