The symptom
A classic Home Assistant forum thread. Somebody opens port 8123 on the router, the rule shows green, HA works fine on the LAN, but from outside the house there’s nothing. Hours go into debugging. Firewall. DDNS. Certificates. Router firmware. Everything checked, nothing found. Then somebody further down the thread asks the question that should have come first: “Do you actually have a public IPv4 address?”
Answer, usually: “I think so.”
Then the tip. Open whatismyip.com, compare what you see there with the WAN IP on your router. If the two don’t match, the mystery is solved. CGNAT. And at that point the port forwarding isn’t broken in any way you can fix on the router — it sits in a chunk of the network that the public internet was never meant to reach.
What CGNAT actually is
Carrier-Grade NAT, sometimes called Large-Scale NAT, is how ISPs deal with the IPv4 shortage. Rather than give every customer line a dedicated public IPv4, they pool a smaller number of public addresses across many customers, with a big NAT box on the provider’s side handling the translation.
For you the practical effect is this: your WAN address is suddenly private. Usually somewhere in 100.64.0.0/10, the block reserved exactly for this purpose. An inbound packet from the internet doesn’t reach your router anymore — it hits the provider’s NAT first, which has no idea which of the thousand customers behind that public IP the packet is meant for, and drops it. Outbound still works, because NAT can track the return path from a connection you initiated.
Port forwarding assumes your WAN side is reachable from outside. Behind CGNAT it isn’t. Reconfiguring the router for the fifteenth time won’t change that.
Who’s affected
CGNAT isn’t an edge case anymore:
- Mobile data: basically all of it, everywhere. If HA lives on an LTE router somewhere — a weekend cabin, a backup link — you’re behind CGNAT, guaranteed.
- New fibre lines: plenty of newer fibre ISPs hand out CGNAT addresses on the cheaper consumer tariffs by default. A static public IPv4 is an extra, usually paid.
- Cable: more and more, especially in newly built-out areas.
- DSL: historically public. Some providers are quietly switching here too.
A tariff change is enough. Sometimes just a router swap with the same provider. And the port forward that worked yesterday is dead today.
Quick check: is this me?
Three minutes:
- Read the WAN IP off your router.
- Get the public IP from the outside. whatismyip.com in a browser, or
curl ifconfig.mein a terminal. - Compare.
- Identical → public IPv4, classic port forwarding still works.
- Different, and the WAN IP starts with
100.64.through100.127.→ CGNAT. Port forwarding won’t get you there. - Different, and the WAN IP is private (
10.x,192.168.x,172.16-31.x) → you’re sitting behind multiple NAT layers, probably a second router upstream. Fixable. Not CGNAT.
Workarounds, and what’s wrong with each
Several ways exist to get remote access from behind CGNAT. Not all of them are equally good.
IPv6
Elegant on paper. IPv6 addresses are public, every device gets its own. In real life there are a few catches. Lots of ISPs roll IPv6 out opportunistically, without a stable prefix and without making any promises. DynDNS providers that handle AAAA records cleanly take some finding. And the other end of the connection — the hotel Wi-Fi, the mobile network, the corporate guest network you’re connecting from — often has no IPv6 at all.
For hobbyists it works. For dependable customer remote access it’s too flaky.
Classic VPN (WireGuard, OpenVPN)
The VPN server also needs a public IPv4 — which means hosting it elsewhere. Small cloud server, static IP. The HA host and the client both make outbound connections to that VPN server, and it brokers between them.
Battle-tested. Old. Technically under your control. The price is that you operate a second server, and a VPN typically opens the whole network. Fine for a single installation of your own. Roll it out across ten customers and you’ve signed up for maintenance debt — and at the customer side you’ve taken a trust hit, because “wait, you can now also reach my printer and my NAS, right?”
Tailscale
Mesh VPN with DERP relays. Every node connects outbound to the control plane, the relays handle brokering behind CGNAT. No server of your own.
Zero-config, dependable, CGNAT-friendly, free at small scale. Known animal, knows its job. The catch is the same one as with WireGuard: install Tailscale at a customer site and they’re now on your tailnet. Which means potentially in their printer, NAS and baby monitor. A bigger trust step than the use case actually requires.
Cloudflare Tunnel
Persistent outbound tunnel from the HA host to Cloudflare. The frontend becomes reachable under a subdomain. Very stable in practice, free TLS certificates, CGNAT-friendly, well documented.
Two things to know. The traffic flows over US infrastructure, which gets awkward to explain under GDPR when you roll it out at customer sites. And it’s a single-instance setup — ten customers means ten Cloudflare configurations, each with its own maintenance overhead.
WebSocket relay (specialised outbound tunnel)
The architecture HA Fleet Manager uses. A Home Assistant custom integration opens a long-lived outbound WebSocket to a relay server at boot. When the integrator needs remote access, a tunnel into the HA frontend is opened over that same connection — time-boxed, and only after the customer has explicitly given consent.
CGNAT-friendly, because everything originates outbound. Access stays scoped to the HA device itself, no full-LAN VPN. Multi-tenant, consent and audit baked in, EU hosting on the table. The cost is that you trust a central relay component. Easier to swallow when it’s a specialist provider with a documented architecture than a generalist black box, but it’s still a deliberate trust decision.
What this means for the architecture
CGNAT is going up, not down. ISPs save real money with it, and the IPv4 pool isn’t getting bigger. Anyone still holding a public IPv4 today shouldn’t bank on having it tomorrow.
The answer that holds up long-term for Home Assistant is always outbound. No port forwarding, no waiting for inbound packets, just a connection initiated by the HA host to a broker that handles the rest. Tailscale, Cloudflare Tunnel and specialised WebSocket relays all follow that pattern. Where they differ is who brokers, how deep the access goes, and how consent and audit get organised.
For a single private HA installation, any of these will do. As soon as multiple customer installations pile up, the case for a platform that combines that outbound tunnel with multi-tenancy, monitoring and a consent workflow becomes hard to argue with — and that’s the gap HA Fleet Manager is built to fill.