TP-Link Omada WireGuard Remote Access: Browser RDP and SSH to the Whole LAN
Configure native WireGuard on a TP-Link Omada gateway (ER605 v2, ER707-M2) for ProxyLink: browser RDP, SSH and HTTP to every LAN device, no port forwarding.
TP-Link Omada is one of the most common platforms in small business and MSP networks: an OC200 or OC300 hardware controller, or the Omada Cloud Controller, managing gateways, switches and access points across dozens of client sites from a single pane. If you already run Omada, you can turn a WireGuard-capable Omada gateway into a ProxyLink tunnel host. One outbound WireGuard peer on the gateway gives your engineers browser-based RDP, SSH, VNC and HTTP access to every device on the LAN, with nothing installed on the target machines and no inbound ports open on the site.
Which Omada gateways support WireGuard
WireGuard is a native VPN type in Omada, but not on every model or every hardware revision. The ER605 supports WireGuard on hardware revision v2 and later; the original ER605 v1 does not. The ER707-M2 supports it. Check the label on the device or the model string in the controller before you plan a deployment, because ER605 v1 and v2 look identical and only the v2 exposes the WireGuard configuration. Keep the gateway on current firmware, since TP-Link has shipped several WireGuard fixes and additions, including domain-name endpoints, across firmware updates.
Create the tunnel in ProxyLink first
In ProxyLink, create a new tunnel for the client site. ProxyLink builds the relay side of the WireGuard connection and shows you three things you need on the Omada side: the relay public key, the endpoint (46.225.153.241:51820), and the peer address it has assigned your gateway in the 10.100.0.0/16 range. The Omada controller generates the gateway private key for you, so copy the matching public key back into ProxyLink.
Configure WireGuard in the Omada Controller
In the Omada Controller, go to Settings > VPN > WireGuard and add a WireGuard interface. The fields map directly onto a standard WireGuard config:
- Listen Port: leave the default
51820 - MTU: leave the default
1420 - Private Key: the controller generates this automatically. Copy the matching public key into ProxyLink
Then add a Peer for the ProxyLink relay:
- Public Key: the relay public key from ProxyLink
- Endpoint:
46.225.153.241:51820 - Allowed IPs:
10.100.0.0/16, the relay range, and nothing else - Persistent Keepalive:
25, so the gateway holds the outbound NAT session open and re-initiates the handshake after a reboot or WAN blip
The single most common mistake here is putting your own LAN subnets into the peer's Allowed IPs. Do not. The peer's Allowed IPs only needs the relay range. Your site's LAN and VLAN subnets are declared on the ProxyLink side, not on the gateway.
Standalone mode and the multi-subnet caveat
On an ER605 v2 or ER707-M2 run without a controller, WireGuard lives under VPN > WireGuard in the standalone web UI. The exact tabs were reworked in firmware v2.3.2 and later, but the parameters are the same. Standalone mode has historically limited a peer to a single subnet in Allowed IPs, which is not a problem for ProxyLink, because you only ever enter the single relay range. If you manage several client sites, the controller is the better fit regardless: one Omada Cloud Controller holds the WireGuard config for every gateway, and ProxyLink holds one tunnel per site.
Multi-VLAN sites
A typical Omada site runs several VLANs: a main LAN, a voice VLAN for the PBX, a camera VLAN for the NVR. You still need exactly one WireGuard peer on the gateway. Declare each VLAN subnet in ProxyLink under Additional Subnets when you create the tunnel, and ProxyLink routes all of them through that single peer. Nothing about the gateway's WireGuard config changes as you add VLANs.
What your engineers get
Once the handshake is up, create a proxy link per device and service: RDP on 3389 to Windows servers in the browser, SSH on 22 to Linux boxes and to the Omada gateway itself, HTTP or HTTPS to NVR and camera UIs, PBX admin panels, and the web UIs of the Omada switches. The client LAN keeps zero open inbound ports. Every session is logged with engineer identity, target IP and port, and duration, and RDP and SSH sessions can be recorded per link on paid plans.
Try ProxyLink free at app.proxylink.dev, no card required. An Omada site takes about ten minutes once the gateway is on WireGuard-capable firmware. If the site runs a consumer TP-Link router rather than an Omada gateway, the TP-Link Archer and Deco guide covers the stock-firmware VPN client path instead. Step-by-step guides are also published for MikroTik, pfSense, OPNsense, EdgeRouter and GL.iNet.