Documentation
Remote access behind CGNAT: Starlink, 4G/5G and shared-IP fiber
You opened the port on the router, set up dynamic DNS, checked everything twice — and from outside, nothing answers. If your Internet access runs through Starlink, a 4G/5G connection or some recent fiber plans, it is not a mistake on your part : your ISP shares a single public IP address among many subscribers (CGNAT), and the NAT blocking your inbound connections does not belong to you. This page explains why every classic recipe fails, then how VIGIL-MESH restores remote access to your machines using outbound connections only — no public IP, no open port, nothing to ask your ISP for.
CGNAT: one public address shared among subscribers
Public IPv4 addresses are an exhausted resource : there are not enough of them to give every subscriber their own. Many ISPs answer the problem with Carrier-Grade NAT (CGNAT) : an extra address-translation layer, installed inside their own network, that makes dozens or hundreds of subscribers share the same public address. Your router already does NAT between your machines and itself ; the ISP does it again on top, between your router and the Internet.
The practical consequence is blunt : the public address the world sees is not yours. It belongs to the ISP, it is shared with other customers, and the equipment that decides what gets in is not your router — it is the operator’s NAT, over which you have no control. Starlink, most 4G/5G access and some fiber providers put their subscribers behind CGNAT by default.
- The router’s WAN address gives CGNAT away : if your router shows an address in 100.64.x.x (the range reserved for CGNAT), or in 10.x.x.x or 192.168.x.x on the WAN side, it has no public address of its own.
- Two addresses that don’t match : the address a “what’s my IP” site sees differs from the one your router displays — a sign that an extra translation happens at the ISP.
- Forwarding rules that never answer : the port-forwarding rule is correct, the service listens locally, and yet nothing gets through from outside. The block is upstream of your home.
Why port forwarding, DDNS and UPnP all fail
Remote-access tutorials all rest on the same implicit premise : your router holds the public address, so configuring your router is enough. Behind CGNAT that premise is false — and every recipe fails for the same reason, dressed up differently.
Port forwarding opens the wrong door
Your forwarding rule acts on your router : “whatever arrives on this port, send it to this machine”. But behind CGNAT, inbound traffic never reaches your router in the first place : it is dropped one level up, at the operator’s NAT, which has no way of knowing which subscriber an unsolicited connection to the shared address is meant for.
Dynamic DNS points at a shared address
Dynamic DNS maps a name to your current public address. Behind CGNAT, that name points at an address shared by many subscribers : even perfectly up to date, it designates a door nobody can walk through. DDNS solves the problem of an address that changes — not the problem of an address that isn’t yours.
UPnP negotiates with the wrong device
UPnP lets an application request a port opening… from your router. The router complies, the application believes the port is open, and the operator’s NAT — which was never consulted — keeps blocking everything. It is the most misleading trap : everything looks configured, nothing gets through.
The DMZ changes nothing either
Putting a machine “in the DMZ” amounts to forwarding every port of the router to it. It is an extreme version of port forwarding — and it fails for the same reason : the router never receives the traffic it is supposed to forward.
The partial workarounds: IPv6 and paid public IP
Two options come up all the time, and they deserve an honest answer : they can work, but with conditions and trade-offs you are rarely told about.
IPv6 first. CGNAT only affects IPv4 ; if your ISP provides routable IPv6, your machines can have a globally reachable address, with no NAT at all. But the workaround is partial : IPv6 must actually be enabled and routed on your side, every remote machine that wants to reach you must also have IPv6 — far from guaranteed from a hotel, a corporate network or a mobile connection — and you must configure the firewall to let in exactly the right thing. You end up with a service exposed to the Internet again, with the risks that come with it.
The paid public IP next. Some ISPs offer, as a paid option or on certain plans, a dedicated public IPv4 address. Where it exists, that option restores classic port forwarding — but it costs money, it depends on the plan and the operator, it is not available everywhere (notably on many mobile connections), and it puts you back at square one : a service exposed on the Internet, scanned around the clock, to maintain and protect.
| Option | Why it breaks down behind CGNAT | Verdict |
|---|---|---|
| Port forwarding / DMZ | Inbound traffic is dropped at the ISP, before your router | Doesn't work |
| Dynamic DNS | The name points at an address shared among subscribers | Doesn't work |
| UPnP | Negotiates with your router, not the operator's NAT | Doesn't work |
| IPv6 | Requires IPv6 on both ends and exposes the service | Partial |
| Paid public IP | Costs extra, plan-dependent, re-exposes a server to the Internet | Partial |
| Outbound connections + rendezvous (mesh) | CGNAT lets traffic out — that's all it takes | Works |
What works: going outbound on both sides and meeting up
CGNAT blocks everything inbound, but lets everything outbound through — otherwise you could not even load this page. So the solution is not to force a way in : it is to arrange things so that nobody has to accept an inbound connection. Both machines each establish an outbound connection to a rendezvous point, which puts them in touch ; from the perspective of every NAT — yours as much as the operator’s — there is only outbound traffic and its replies, i.e. the normal use of the network.
That is exactly the VIGIL-MESH model. Each machine emits only a single outbound flow, on 443 UDP — the same port as the modern web. The connection between two machines is established immediately through a relay (the vigie), then, in the background, the nodes attempt NAT traversal ; if a direct path exists, the session migrates to it without interruption. Neither side needed a public IP, an open port, or any cooperation from the ISP.
- Zero inbound ports, nothing to ask your ISP for — CGNAT stops being an obstacle, because nothing needs to get in anymore.
- Stable address and MagicDNS name — each machine keeps the same address on the mesh and a readable name, whatever physical network it sits on. No more DDNS : the name follows the machine, not the operator’s address.
- End-to-end encryption — sessions are QUIC/TLS 1.3 connections between the two nodes, with a hybrid post-quantum key exchange. Relayed or direct, the path changes nothing about the encryption.
- Sessions that survive a bumpy link — a session is not tied to a pair of IP addresses : if the connection changes address or network, it re-establishes itself on the best available path without an application-level reconnect.
What if both sides are behind CGNAT?
An increasingly common textbook case : the machine you need to reach sits behind Starlink, and you are reaching it… from a phone on 5G. Two CGNATs facing each other. The outbound connections from both sides reach the rendezvous without difficulty, so the connection always works. The real question is whether a direct path can be established — and there, honesty is in order.
Carrier CGNATs often behave as symmetric NATs : they allocate a different mapping per destination, which generally makes direct traversal impossible when both ends are in that situation. Traffic then flows permanently through the vigie — for VIGIL-MESH as for any other NAT-traversal system. The difference lies in what that relay can see, and who it belongs to.
- The relay is structurally blind : it does not hold the session keys and carries QUIC/TLS 1.3 flows encrypted end to end, whose content it never sees.
- You can host your own vigie : a private relay, dedicated to your workspace — the relayed path then goes through a machine of yours.
- If a network blocks even outbound UDP (some corporate or hotel networks), the node automatically falls back to a tcp-only profile towards the vigie, on port 443 : connectivity is preserved.
Real-world cases: Starlink, 4G worksite, boat
CGNAT affects precisely the situations where remote access matters most : places without classic fiber, temporary sites, vehicles. A few typical scenarios :
The home server, on Starlink
A NAS, a media server or a remote-desktop machine in a house connected through Starlink. Install the VIGIL-MESH client on the server and on your mobile devices : each goes outbound on 443 UDP, and you reach the server by its name, just like at home — with no extra subscription option on the ISP side.
The worksite camera or PLC, on 4G
A construction site often has only a 4G/5G router — hence CGNAT. An on-site gateway (a mini-PC, a Jetson) enrolled in the mesh makes cameras and equipment reachable from the office, as private access : nothing is published on the Internet, and the ACL restricts who can reach them.
The boat or the camper van
Starlink or 4G depending on the area, an address that changes along the journey : the worst case for dynamic DNS, a normal case for the mesh. The machine on board keeps its stable address and its name on the network, and sessions recover on their own when the link changes.
The small office on shared-IP fiber
Some fiber plans also put their customers behind CGNAT. To reach the office machine from home, there is no need to negotiate a public IP with the ISP : two clients enrolled in the same workspace are enough.
Setting it up, step by step
The procedure is identical whatever the Internet access — Starlink, 4G/5G, shared-IP fiber or a regular home router. No step involves the router or the ISP.
- 1Create an account and a workspaceIt is free for personal use. The workspace will hold your machines and your access rules.
- 2Install the client on the machines involvedOn the machine behind CGNAT (the server, the worksite gateway, the boat’s PC) and on the devices that will need to reach it.
- 3Enroll each machineNetworks page → Machines → “Add a machine” : a single-use key enrolls the machine into your workspace.
- 4Verify connectivityEach machine gets a stable address and a MagicDNS name. A ping to the address or the name confirms the link is up — including across CGNAT.
- 5Reach your services as if you were localRemote desktop, SSH, the NAS or camera web interface : point at the machine’s address or name, exactly as if you were on site.