[soebbing]

I am quite happy that all those shady IoT devices cannot be reached from the internet directly when I am using IPv4 and NAT - what would be the best way forward to keep it that way in a IPv6-only future?

The best idea I can come up with (at least right now) is: put all less trustworthy (read: Closed source) devices into a special legacy IPv4 network and only use IPv6 on my workstation and little Raspis?

[wolrah]

> I am quite happy that all those shady IoT devices cannot be reached from the internet directly when I am using IPv4 and NAT - what would be the best way forward to keep it that way in a IPv6-only future?

The same exact way you do it right now.

Think of NAT as an implicit default-deny firewall rule, that's all it's doing.

Basically any firewall worth using will do exactly the same thing in IPv6, deny unsolicited inbound traffic unless explicitly allowed.

For some reason there's this belief out there that a device having a globally routable IP address inherently means it's globally reachable, and that's just not true. Your firewall still works exactly the same way.

[jiggawatts]

Not to mention that 99.99% of IoT devices connect to the mothership using an outbound connection, which is permitted by default on both IPv6 and IPv4+NAT.

[martinald]

But how does eg a device programmatically tell the firewall to allow traffic in in this case? This is done via UPNP on ipv4 NAT.

If you're going to say there isn't a way and you need to add the firewall rules manually, then this is absolutely no improvement for 99%+ of consumer users who have absolutely no chance of understanding how to configure that.

Think of for example Xbox users. On ipv4 with NAT it automatically configures it for serving games using upnp. If you had ipv6 only with a default deny rule and no upnp equivalent then the Xbox cannot open itself up to incoming connections. It's actually a downgrade in terms of "P2P" connectivity from NAT.

[jeroenhd]

Every guide I see tells you to disable Upnp (or IGD, the part of UPNP that lets you open ports), for good reason. It's a protocol that just disables the security you thought you had before.

The reason Xboxes need port forwarding in the first place is that IPv4 relies on NAT. The unreliability and unpredictability of NAT means remote devices won't know what ports to talk to or if those ports will even be mapped to the right device. IPv6 removes that problem all together! It alleviates the need for 99% of the port forwarding cases that UPNP provides, assuming you've manually enabled it in the first place.

If port forwards are really necessary for Xboxes to work, then IPv6 brings another advantage: you can run multiple Xboxes behind the same IPv4 address. That IPv4 address can be your home connection, or it can be a thousand people behind CGNAT. In countries where CGNAT is the norm (India comes to mind) you can't possibly expect UPNP to be a requirement for Xbox to work!

[martinald]

UPNP is just fine assuming a secure implementation (some of the early ones were awful, but that doesn't make the concept bad). It doesn't reduce security anywhere near like what is made out. If you already have a device on your network that is compromised and is able to do UPNP requests, then you have a much bigger problem (in a home setting).

But IPv6 doesn't solve the problem at all if all incoming connections are blocked on the firewall - which they have to be for security! You need some protocol for the xbox to be able to tell the firewall to open ports, which doesn't exist. Or users have to manually set the firewall rules, which is the same as port forwarding on NAT from a users perspective (ie impossibly complicated)

You can run multiple xboxes behind NAT right now, they get different ports.

Again, for a non technical user there is no major difference between being behind CGNAT IPv4 (impossible to get incoming connections), and firewalled IPv6 (possible to get incoming connections, but the firewall is too complicated to use so it may as well be impossible). If there was a protocol which would allow devices to open ports on IPv6 firewalls programmatically similar to UPNP it would be entirely different, but there isn't.

[jeroenhd]

libupnp/miniupnp seem to support IPv6 pinholes just fine through WANIPv6FirewallControl. I don't sell routers so I don't know how up to date the libraries on your average router firmware are (most likely "ancient") but this isn't a protocol problem. If you run firmware like OpenWRT you've had support for it for at least five years now.

Most consumer routers I've seen these days come with UPNP disabled by default, though.

For most P2P traffic (which includes a third party handshake server) you can probably skip port forwarding entirely; just send UDP packets both ways and the firewall will figure it out. For stateful protocols like TCP and friends (SCTP etc.) that's harder to accomplish this, that's where you need pinholing.

It's possible that your router simply doesn't support IPv6 pinholing but I think the more likely scenario for breakages is that client software doesn't bother implementing it.

[zoredache]

Lots router have UPNP disabled or blocked, and thing still work. UPNP isn't great.

First The firewalls are stateful. Client inside your network attempts to connect to some system outside. The firewall adds an entry to the state table with client ip, destination ip, protocol, ports, and so on. If an incoming packet is received by the firewall, the state table is checked. If there is an matching entry for the ips, proto, ports, etc, then the packet is forwarded. If there is no match the packet is dropped or rejected depending on your config. So it is easy to permit packets based on the interface it was received or transmitted on.

Ports can be opened for some incoming traffic pretty much the same with as IPv4 using STUN, TURN, and so on.

Past that, you can do manual port forwards the same way you do with IPv4.

[martinald]

I understand how stateful firewalls work. But to allow game servers etc to run, you need to explicitly accept incoming connections somewhere, as you don't know the IPs in advance that will connect.

Then if you're using STUN and TURN (which you'll have to, because non technical users do not find configuring firewalls easy) then what is the advantage of IPv6 to a consumer? There is no real p2p benefits.

I'm trying to call out this contradiction:

1) You need a firewall on IPv6 instead of relying on NAT, otherwise everything is routable globally and insecure 2) There will be this glorious new p2p world for consumers with ipv6

If you need a firewall, then really for non technical users you cannot have this p2p world. It is too complicated.

[wolrah]

> But how does eg a device programmatically tell the firewall to allow traffic in in this case? This is done via UPNP on ipv4 NAT.

https://en.wikipedia.org/wiki/Port_Control_Protocol, which also allows for UPnP-like functionality when NAT64 is in play.

That said most "P2P" traffic is still mediated by a central server though and does not need this. The lack of port remapping from NAT means that tricks like UDP hole punching work simply and reliably rather than the semi-random performance seen through NAT. Multiplayer gaming, VoIP, voice/video chat, etc. where a central server does the setup doesn't need ports opened to the world, it just needs to punch a hole for that specific session. A SIP phone opening a port forward on 5060 for itself is a bad thing, but it's sometimes needed in the NAT world.

True unsolicited incoming traffic will still need an allow rule but that's a lot more rare.

> If you're going to say there isn't a way and you need to add the firewall rules manually, then this is absolutely no improvement for 99%+ of consumer users who have absolutely no chance of understanding how to configure that.

I disagree. These days the sorts of things normal people do that deal with P2P connections are pretty good at dealing with NAT, but far from perfect. You don't have to look far in to the gaming world to find people complaining about not being able to join a session, not being able to connect to voice, etc.

Any VoIP provider serving users on their own internet connections is going to be doing things like regular keepalives, setting their media systems to accept RTP from and send it back to whatever port it comes out of the user's NAT on instead of the one it's supposed to be on, etc.

All these things work pretty well, most of the time. But they're not perfectly reliable because every NAT implementation is different in subtle ways.

> Think of for example Xbox users. On ipv4 with NAT it automatically configures it for serving games using upnp. If you had ipv6 only with a default deny rule and no upnp equivalent then the Xbox cannot open itself up to incoming connections. It's actually a downgrade in terms of "P2P" connectivity from NAT.

As noted previously, in IPv6 it doesn't need to open the port at all. Anything the Xbox, or any other modern game console, will be doing is server-mediated P2P for which standard basic UDP hole punching is a perfect fit.

Basically anything that definitely always requires a port forward in IPv4 NAT will probably still require an allow rule in the firewall, but anything where port forwards aren't supposed to be required but sometimes they help some people more reliably connect is a problem caused entirely by the NAT and those problems go away. Hosting a dedicated game server is in the former category, playing games is in the latter category.

There's a reason all the modern consoles include NAT tests in their network diagnostics, but can only offer vague suggestions at the fix, because how the NAT is breaking things varies by the NAT and may or may not be fixable. The only real fix is to eliminate the NAT.

FWIW Xbox prefers IPv6 when available and Xbox Support specifically recommends having it enabled if you can. That tells me that it works either equally well or better than IPv4 in the real world, which fits my view of things.

[vel0city]

> what would be the best way forward to keep it that way in a IPv6-only future?

Firewalls. You configure what traffic should be allowed from who to who. Default deny incoming traffic, and its the same behavior as when you had a NAT.

Something having a routable IP address doesn't mean it needs to receive all traffic addressed to it.

[candiddevmike]

The problem I have had with this setup is allowing inbound traffic to things that need it becomes tricky. Some devices don't support DHCPv6 like Android) and some firewalls don't let you do suffix matching. With a dynamic block via PD, the rules to allow inbound traffic to say an Xbox become quite complicated.

[nrabulinski]

You can still have a firewall on the router level, just as you do with IPv4. You shouldn’t allow any external traffic by default anyway and NAT shouldn’t be a security measure.

[candiddevmike]

I know, I'm saying that when you want to embrace global routable addresses for outbound AND inbound, it's hard with Prefix Delegation and spotty DHCPv6 support.

ISPs should be forced to let customers get IPv6 prefix reservations. Yes, PD doesn't change for most, but I'd rather not use PD at all.

[groestl]

My ISP does not allow BYOM (bring your own modem) and assigns me a /64 net, so I have a hard time running an (ipv6) router behind it that would do the firewalling.. I guess I'm stuck with ipv4 for the time being...

[aaronax]

A firewall can be run "in-line" and not have IP addresses on the interfaces. On a Palo Alto firewall this would be a "virtual wire", and "transparent firewall" or "bridging firewall" would be other common terms.

Examples: https://docs.opnsense.org/manual/how-tos/transparent_bridge.... https://docs.netgate.com/pfsense/en/latest/bridges/index.htm... https://www.fortinet.com/resources/cyberglossary/transparent...

[groestl]

Thanks for the hints. Currently, I have a fully routed setup with two routers behind the IPSs box, multiple wireless networks and VPN uplinks (via wireguard) to my servers. It's just that all of this is ipv4, because I don't see any way of doing that using a single /64 network.

[throwaway742]

https://www.fortinet.com/resources/cyberglossary/transparent...

[cassianoleal]

Doesn't it let you put it in bridge mode (i.e. modem only)?

[groestl]

ISP uses DS-Lite: ipv6 is native, ipv4 is 4-in-6/CG-NAT. When I switch to bridge mode, it loses ipv6 connectivity, so sadly, that's not an option if ipv6 is the goal.

[cassianoleal]

I see. Or rather, I don't quite. :D

I'm not very familiar with DS-Lite. My ISP also uses CG-NAT but I get my connection details over DHCP - both native v6 with /56 PD and the v4 CG-NAT 100.x.x.x IP. That means I connect my OpenWRT router directly to the ISP's plug in the flat.

You said v6 is native for you, but if you put the modem in bridge mode you lose v6 connectivity. Why is that so? Shouldn't you lose v4 instead, which relies on tunneling?

[justeleblanc]

Does your ISP's router not have a firewall?

[groestl]

A very very inconvenient one.

[screamingninja]

It's worth noting that NAT is not a security feature in itself, but rather a way of conserving public IP addresses and hiding the internal network structure. The best way is to use a stateful firewall that is built into nearly every router.

Another option is to use IPv6 Unique Local Addresses (ULA), which are similar to private IPv4 addresses and can only be used within a specific site. This approach enables internal connectivity for devices that do not require direct access to the Internet. I use it for several IoT devices that I do not want reaching out to the mothership.

[nijave]

>cannot be reached from the internet directly

Stateful firewall that allows outgoing connections and blocks incoming (or maybe blocks both)

In general, you probably don't want to allow unsolicited incoming connections to any devices, regardless of IoT.

[wyager]

Put internet of shit devices on their own VLAN(s). Almost all wifi APs today support multiple SSIDs with separate VLANs. Have your firewall block inbound connections to devices on that VLAN. Every OS firewall has built-in support for this.

I spent a lot of time figuring out how to do all this in the most efficient way (in terms of my time and effort) during covid, and I suggest getting any arbitrary box with 2 ethernet ports and putting freebsd on it.

[soebbing]

I actually thought about that for a minute when I set up my home network a while ago, but that seems to be a pretty hard (or at least inconvenient) problem.

Often I need to access a device from my local network (think: use my phone to control Wi-Fi LED Strips, Sonos speakers, etc.), which makes it impossible (I guess?) to separate these devices into their own network completely (if they aren't controlled by an online service in general). Or is it possible to allow access from my trusted network INTO the restricted network, but not the other way around?

Total network noob here, in case you haven't figured that out yet. :)

[wyager]

> Or is it possible to allow access from my trusted network INTO the restricted network

Yes, my home network works exactly like this. I have a vlan called "trusted" which can connect to any other vlan. One line in pf.conf.

My VLANs are something like: trusted, guest, media, cameras, printer, etc.

Many of these aren't allowed inbound or outbound connections (e.g. cameras and printer can only talk to things on their subnet).

Only downside is that stuff that works off broadcast packets (like bonjour) does not work across subnets.

[kube-system]

There are mDNS repeaters that can in some cases make bonjour work across different networks. In my experience I spend more time fighting with mDNS than I do enjoying it.

[cassianoleal]

I have avahi running on my router repeating mDNS across all VLANs. I can't recall the last time I had an issue with it.

[labcomputer]

Each of the VLAN is (or can be) just another network from the router’s and firewall’s perspective. So you just have to set up appropriate firewall rules to allow traffic between the networks that you want to communicate.

You could, for example, allow only TCP traffic initiated by hosts in the “normal” VLAN to hosts the IoT VLAN. So IoT stuff can’t initiate outgoing connections to any other network, and can only receive TCP connections from one network.

You can also set up an MDNS reflector on your router if your IoT devices use that (e.g. HomeKit) to send data proactively back to “normal network” hosts.

[throwaway742]

>Or is it possible to allow access from my trusted network INTO the restricted network, but not the other way around?

Yes

[philjohn]

I go one further - the IoT VLAN (Sonos, Philips Hue, wifi controlled light strips, TV's) is hard segmented from my "trusted" VLAN (except for some specific holes punched so things like SSDP and streaming from a media server work).

[cnorthwood]

You'd probably do it in the same way you'd do it with NAT, by using a stateful firewall blocking inbound connections (it's just that you get this for "free" with NAT)

[adriancr]

Although I'm going to get comments saying this is wrong...

What I did was:

- IPv6 DHPC - private address range within: fc00::/7

- IPv6 NAT, same as for IPv4.

- Firewall.

Why:

- digital ocean only allowed ~16 IPv6 addresses.

- I wanted a local IPv6 network exiting through digital ocean.

- I see no reason to give public route-able addresses to each device in my home (allows remote websites to determine who is calling it and set up profiles/target each remote device).

- Sure, privacy extensions which cycle unique addresses, but it still allows profiling based on source address, even if a bit of work is needed for each new addresses.

[Xelynega]

Why would your firewall allow your ipv6 IoT devices to receive inbound connections from the internet? Whats the difference between "ipv6 Nat" and a firewall when theres not likely to be any address overlap.

[adriancr]

> Why would your firewall allow your ipv6 IoT devices to receive inbound connections from the internet?

It does not, problem is with outbound connections.

> Whats the difference between "ipv6 Nat" and a firewall when theres not likely to be any address overlap.

Outbound connections can be profiled by remote websites.

With NAT (Well... Port-address-translation to be fair, so single outgoing address), traffic can't as easily be profiled.

Imagine ISPs/Ad providers having easier time identifying you, your spouse, your kids, etc. (and device, and so on just by observing addresses)

With initial SLAAC it is even nicer as MAC address is included in the address... Can look up device much easier just cross reference manufacturer database...

[xnyanta]

Digital Ocean has horrible IPv6 support, I would just move to another provider. Most VPS providers will, at the very least, provide you with a /64.

[jhoelzel]

You can configure your local ipv6 net without SLAAC (Stateless Address Autoconfiguration).

Or differently put, you don't need to use the net your isp provides everywhere, ipv6 can still use NAT if you want it to: https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6

[nickstinemates]

Network segmentation, i.e use of vlans is the traditional way to solve this.

[Godel_unicode]

Not sure why you’re being downvoted, this is a very good answer. Maybe because you left out the implied “and then firewall off that vlan”?

[soebbing]

Yeah, it seems to be the common consensus to just block everything going in and just make exceptions, where you really want to offer a service to the internet.

Makes total sense, thinking about it. I guess, all those years of just sitting behind a NAT makes one forget all these networking basics if you're not using them regularly.

Moving closed-source IoT devices into a special vlan, with some even more rigid rules (something like: only allow http/https traffic into the internal network) might be an additional level of security.

Thank all of you for your replies!

[gnramires]

I think NAT is a bit of an unfortunate "janky" solution of addressing protocols (giving some security and some address expansion, and sacrificing interoperability and connectivity). I think the security part should be fixed by proper firewalls and/or authentication -- in fact some kind of security mechanism should be default for home routers and such.

I think ideally we should also think of new interoperable defenses that fill the NAT gap. Perhaps each device should have an authentication key apart from its IP, which it could pass onto trusted devices like local network routers, which would only allow authenticated incoming data. Maybe even better would be a global scheme including this authentication and also more private addressed (than IP), although that would probably require a redesign of IP and might be a project for the far future.

[samcat116]

Most consumer routers will disable inbound connections for the IPv6 prefix by default from what I've seen. If not thats easy to enable.