Remote Access Without Port Forwarding: Reach Any Device Behind Any ISP

Port forwarding is the answer that IT forums have given to "how do I access my home network remotely" for twenty years. Open port 3389 for RDP, point it at the PC, use DDNS for the dynamic IP, done. The problem is that in 2026, a growing percentage of internet connections do not support port forwarding at all — and the ones that do expose your devices to the internet in ways that are increasingly difficult to defend.

This post covers the specific reasons port forwarding fails and what actually works instead.

Why Port Forwarding Is Not an Option

CGNAT. Carrier-Grade NAT is the biggest blocker. When your ISP puts you behind CGNAT, the public IP your router shows is not actually yours — it is shared among hundreds or thousands of subscribers. Your router cannot receive unsolicited inbound connections because the ISP's NAT equipment has no way to route them to you specifically. Port forwarding rules on your router do nothing. CGNAT affects nearly all mobile and LTE broadband, Starlink and satellite internet, and a growing share of cable and fiber in densely populated areas.

ISP port blocks. Even on connections with a real public IP, many ISPs block inbound ports at the network level. Ports 80 and 443 are commonly blocked on residential tiers. Port 3389 (RDP) and port 22 (SSH) are blocked by some ISPs as a default measure. You cannot override these with router settings.

Corporate and managed firewalls. If the machine you need to reach is at a managed client site, an office building, or a hotel network, inbound port forwarding is not available. These networks are managed by someone else, and their firewall policy is not changing for your access requirement.

Dynamic IP churn. Even when port forwarding is technically possible, DDNS is required to track the address. There is always a propagation window when the IP rotates. Access breaks silently until the record updates — fine until it happens at 11pm during an incident.

What Actually Works: Outbound WireGuard

CGNAT, ISP blocks, and managed firewalls share a common restriction: they prevent unsolicited inbound connections. They do not prevent your router from initiating outbound connections to a server that has a real public IP address.

WireGuard exploits this asymmetry. When you configure a WireGuard peer on your router with a persistent-keepalive interval, the router opens and maintains an outbound connection to a relay server. Once the handshake completes, traffic flows both ways through the established tunnel. The relay can reach your LAN devices — but only through the pre-established tunnel, not as a raw inbound connection from the internet.

This works behind CGNAT. It works behind ISPs that block inbound ports. It works behind corporate firewalls. As long as the router can make outbound UDP connections — which almost nothing blocks — the tunnel stays up and your devices are reachable.

One Tunnel, Every Device on the LAN

The router-level WireGuard tunnel has a property that per-device VPN clients do not: it covers every device on the LAN without requiring any software on individual machines.

Once the tunnel is running on the router, the relay server can route to any IP on that LAN — including devices that cannot run software at all:

Hikvision or Dahua NVR cameras on port 80 or 443
PBX telephone systems (Matrix, Yeastar, Grandstream) on their admin port
Cisco, Ubiquiti, or MikroTik managed switches via SSH or their web UI
Windows PCs on port 3389 (RDP)
Linux servers on port 22 (SSH)
Any other device with an IP address on the network

For MSPs managing client sites, this matters. NVR cameras and PBX systems cannot run TeamViewer, AnyDesk, or any VPN client. Port forwarding was the only traditional way to reach them remotely — and it exposed those devices directly to the internet with no rate limiting, no MFA, and no audit trail. The router tunnel eliminates the exposure entirely.

ProxyLink: The Browser Layer on Top

ProxyLink provides the relay infrastructure and the browser interface on top of the WireGuard tunnel. After setting up one tunnel on your router (MikroTik, pfSense, OPNsense, OpenWRT, or any Linux gateway), each device on the LAN gets a URL in the dashboard:

HTTP/HTTPS proxy links — any web-based admin interface on the LAN becomes accessible via a public URL. NVR web UI, PBX admin panel, switch management interface, Synology DSM — open in any browser, no port forwarding, no static IP.
Browser RDP — click a Windows PC in the ProxyLink dashboard and get an RDP session in a browser tab. No mstsc.exe, no VPN client on your laptop.
Browser SSH — SSH terminal in the browser for Linux servers and network devices. Supports Cisco enable mode and optional session recording.
TCP links — raw TCP forwarding for non-HTTP protocols: RTSP streams on NVRs, proprietary PBX protocols, SIP for VoIP on UDP.

The tunnel connects outbound from the router. The LAN has zero open inbound ports. Every device is dark to the internet — reachable only through the authenticated ProxyLink tunnel.

The Security Difference

Port forwarding and an outbound tunnel solve the same access problem with opposite security profiles.

With port forwarding, the device's IP and exposed port are visible to every scanner on the internet. Shodan indexes exposed RDP servers, NVR cameras with default credentials, and PBX admin panels continuously. The attack surface exists permanently, regardless of whether you are actively using remote access at that moment.

With an outbound WireGuard tunnel, there are no inbound ports and no public attack surface. An attacker scanning your ISP's IP range finds nothing to connect to. Access requires authentication to ProxyLink, which supports two-factor authentication. Every connection is logged with engineer identity, target device, timestamp, and session duration — a requirement for NIS2-covered entities in the EU.

Multi-VLAN Sites

A hotel or office with multiple VLANs — a main LAN, a PBX VLAN, and a camera VLAN — needs exactly one WireGuard peer. Declare all three subnets when setting up the tunnel in ProxyLink. All three become reachable through the single router peer. An engineer can reach the camera NVR on VLAN 20, the PBX on VLAN 10, and a Windows server on VLAN 1 — all in the same browser session, without switching tools or reconfiguring anything on the individual devices.

Setup

One WireGuard tunnel per site. For MikroTik routers, ProxyLink has auto-configuration built in — it connects via SSH and deploys the WireGuard configuration automatically. For pfSense, OPNsense, and OpenWRT, step-by-step guides are in the docs.

A standard single-LAN site takes about 15 minutes to configure. A multi-VLAN hotel or office setup takes 20–30 minutes including testing. After that, every device on every VLAN is accessible indefinitely — no per-session setup, no per-device configuration, no open ports on the client network.

Try ProxyLink free — no card required, no limits during early access. Full access from day one.