Starlink Remote Access: Reach Every Device Behind CGNAT Without Port Forwarding

Starlink has changed internet access for remote locations that could not get reliable fiber or cable — rural properties, construction sites, farms, boats, and mobile offices. But anyone who has tried to set up remote access on a Starlink network quickly runs into the same problem: you cannot port forward.

Starlink uses CGNAT — Carrier-Grade Network Address Translation. Unlike a home cable or fiber connection where the ISP assigns you a routable public IP, CGNAT pools hundreds of subscribers behind a single shared IP. The public IP belongs to Starlink's network equipment, not your router. Port forwarding rules on your router do nothing, because inbound traffic never gets that far — Starlink's equipment receives it and has no idea which subscriber to send it to.

What Fails Behind CGNAT

Most traditional remote access approaches assume you can receive inbound connections. On Starlink, they do not work:

• Port forwarding — impossible. The public IP is not yours.
• WireGuard server on your router — the listening port is unreachable from the internet.
• OpenVPN or IPsec VPN server — same problem. Inbound connection required, CGNAT blocks it.
• Direct RDP or VNC port forwarding — same problem.
• Dynamic DNS — only useful if you have a public IP to point to. With CGNAT, you do not.

TeamViewer and AnyDesk work around CGNAT by running an agent on each device that dials out to their relay servers. That means installing software on every device you want to reach — and both platforms were breached in 2024, routing your session traffic through their infrastructure in the process.

Why Outbound Tunneling Works

The restriction CGNAT creates is specifically inbound: you cannot receive unsolicited connections from the internet. Outbound connections work fine. Your router can open a connection to any public server on any port — the problem only starts when someone on the internet tries to connect to you first.

WireGuard takes advantage of this. When you configure a WireGuard tunnel with a remote endpoint and a persistent keepalive interval, the client side initiates and maintains the connection outbound. CGNAT sees it as a normal outgoing connection and allows it. The remote server — which has a real public IP — accepts the tunnel. Once the tunnel is established, traffic flows both ways through it. The server can reach devices on your LAN without ever making a raw inbound connection from the internet to your Starlink address.

One Router Tunnel, Every Device

ProxyLink's architecture is built around this model. You configure one WireGuard peer on the router at the Starlink site — MikroTik, pfSense, OPNsense, OpenWRT, or any Linux gateway. The router dials out to ProxyLink's relay server and maintains the tunnel with persistent keepalive. No static IP needed, no port forwarding, no ISP cooperation required.

From that single tunnel, every device on the LAN becomes accessible: Windows PCs and servers via browser RDP, Linux machines via browser SSH, NVRs and PBX admin panels via HTTP/HTTPS proxy links, managed switches via browser SSH. No software is installed on the individual devices — the router handles routing for the whole subnet.

For sites with multiple VLANs — a hotel with a main LAN, a PBX VLAN, and a camera VLAN — declare all three subnets on the tunnel and all of them become reachable through the single WireGuard peer. One router, one tunnel, all devices on all VLANs.

Common Use Cases

Starlink remote access comes up in a few specific contexts:

• Remote offices and construction sites — Starlink is the only viable internet option. Engineers need to reach Windows servers, NVRs, and access control systems remotely without any on-site IT staff.
• Hotels and vacation properties — rural locations without fiber. PBX and NVR management must happen remotely, and there is no static IP to work with.
• Temporary deployments — pop-up sites, events, mobile operations. Starlink goes up, the router tunnel connects automatically, access is immediate.
• MSP-managed sites at scale — many ISPs are moving away from per-subscriber public IPs entirely. The same outbound tunnel model works whether a site has a public IP or not, so one approach covers all your clients uniformly.

What Engineers Get Once the Tunnel Is Up

In ProxyLink's dashboard, each device at the Starlink site gets a browser-accessible URL. An engineer clicks a Windows PC and gets an RDP session in a browser tab — no VPN client, no mstsc.exe, no local software required. SSH sessions for Linux servers and network switches open the same way. HTTP/HTTPS proxy links open the NVR web interface or PBX admin panel directly in the browser, on any port.

Session recordings and audit logs are built in on paid plans — not add-ons, not higher-tier features within those plans. Every connection is logged: engineer identity, target device, timestamp, and session duration. For NIS2-regulated clients in the EU, this answers the access control audit questions directly.

Starlink's IP assignment is outside your control — the address can change, and with CGNAT it was never yours to begin with. With ProxyLink, none of that matters. The tunnel dials out from the router's side, so whatever IP Starlink assigns at any given moment is irrelevant to whether your access works.

Try ProxyLink free — no card required. The first Starlink site tunnel takes about 15 minutes to configure. Setup guides for MikroTik, pfSense, OPNsense, and OpenWRT are in the docs.