Skip to content

Outbound-only connectivity behind CGNAT

RG Platform reaches devices behind CGNAT, cellular networks, and strict firewalls because every connection is device-initiated and outbound. There are zero inbound ports, no port forwarding, no UPnP, no public IPs, and no VPN. A device dials out to its cluster, holds one encrypted channel open, and becomes manageable — no matter whose network it sits on.

Why inbound approaches fail behind CGNAT

Carrier-grade NAT gives a device a private address shared behind the ISP's translation layer, with no publicly routable address of its own. Any technique that depends on reaching the device inbound — port forwarding, UPnP, a static public IP, or a hole-punched VPN endpoint — has nothing to forward to, because the device is not addressable from outside. The same is true on cellular links and on firewalled sites the operator does not administer: inbound is denied by default. Traditional remote access works around this with VPN concentrators or bastion hosts, which add credentials, per-site network changes, and inbound attack surface. RG avoids the problem class entirely by never requiring an inbound path.

The outbound-only invariant

RG's core connectivity rule is an invariant: no managed device or bridge ever accepts an internet-inbound connection. Every channel is opened by the device, outward, to its cluster. The security consequence is direct — there is no listening port to scan, no inbound service to exploit, and no exposed management interface at the edge. Even a device whose own web GUI would normally be a liability is safe, because that GUI is only reachable through the tunnel the device itself established, gated by RG permissions. The invariant holds across all deployment modes: an agent embedded on a device and a standalone bridge appliance both connect the same way — outbound only.

What the operator experiences

From the operator's side, connectivity is not something to configure. After a device is paired, it opens its outbound channel and appears in the dashboard, and it stays manageable regardless of the network it lives on — office LAN, cellular backup, a customer site behind an unknown firewall, or CGNAT. When the link drops, the device reconnects on its own with backoff, and the cluster reclaims any stale endpoint it left behind. The operator never allocates a public IP, never opens a firewall rule inbound, and never touches the remote site's network. Reachability follows the device, not the address.

What the site owner must allow

The site owner has to permit exactly one thing: a single outbound encrypted connection from the device to its cluster. There is no inbound rule to add, no port to forward, no DMZ to build, and no VPN client to install and maintain. On networks with egress filtering, this is easy to allow precisely because it is one predictable outbound flow per device rather than an inbound exception. Nothing about the device becomes reachable from the public internet as a result — the device gains a way out, not a way in.