Wake-on-LAN Over the Internet Without Port Forwarding

Every MSP knows the scenario. A client calls at 8am: the accounting PC at a branch office is powered off, the person who sits at it is out sick, and a report is due. You could drive out, or you could send a Wake-on-LAN packet and connect. The problem is that Wake-on-LAN was designed for a local network, not the internet, and getting a magic packet across to a client LAN has always meant port forwarding, a static IP, or a machine left running as a relay. ProxyLink removes all three.

Why remote Wake-on-LAN is normally so painful

A Wake-on-LAN magic packet is simple: six bytes of 0xFF followed by the target NIC's MAC address repeated sixteen times, sent as a UDP broadcast on the local segment. A sleeping or powered-off machine with WoL enabled listens for that pattern and powers on. The catch is the word broadcast. Broadcasts do not cross routers, and they do not cross the internet. To wake a machine at a remote site the old way, you had one of these options:

• Forward a UDP port on the client's router to the LAN broadcast address, which most consumer and business routers refuse to do, and which opens an inbound hole you now have to manage
• Leave a device permanently powered on at the site to act as a WoL relay, which is one more thing to maintain and one more single point of failure
• Rely on a static public IP, which many sites do not have, and which is useless behind carrier-grade NAT such as Starlink or most 4G and 5G links

None of this scales: an MSP with fifty sites does not want fifty port-forward rules or fifty always-on relay boxes.

How ProxyLink wakes a device across the internet

ProxyLink already runs one outbound WireGuard tunnel per client site, hosted on the router or gateway (MikroTik, pfSense, OPNsense, OpenWRT, EdgeRouter, or a small Linux box). That tunnel is initiated outbound, so it works behind CGNAT, behind a dynamic IP, and with no open inbound ports. Wake-on-LAN rides that same tunnel.

When you click Wake on a device, the ProxyLink server builds the magic packet and sends it as a UDP broadcast through the WireGuard tunnel to the client LAN. The gateway forwards that directed broadcast onto the local segment, and the target NIC receives exactly the packet it would have from a machine sitting next to it. The sleeping device cannot tell a local wake from one sent across the country.

Two things make this work with no extra infrastructure:

• The packet is generated server-side. Wake-on-LAN is a NIC firmware feature, so the target needs no ProxyLink software to receive the packet. This keeps to ProxyLink's core rule: no agent on the target device.
• The broadcast is routed through the tunnel, not the public internet. No port forward, no relay box, no static IP. The one tunnel you already deployed to reach the site's RDP, SSH, cameras, and PBX also carries the wake packet.

Setting it up

On the proxy link for the device you want to wake, open the link's edit page and set the Wake-on-LAN MAC address field in the format AA:BB:CC:DD:EE:FF. The link must be tied to a LAN router tunnel, because that tunnel carries the broadcast to the correct segment. Once the MAC is saved, a Wake action becomes available on the device. Click it, wait a few seconds, then open a browser RDP, VNC, or SSH session to the same device. Wake and connect, both from the browser.

Make sure the target can actually be woken

ProxyLink delivers the packet reliably. The most common reason a machine still does not wake is on the machine itself, so check it before you blame the network. Wake-on-LAN has to be armed at three layers:

• BIOS or UEFI: enable the setting usually named "Wake on LAN" or "Power On by PCIe".
• The NIC driver in Windows: in Device Manager, under the adapter's power management, enable "Wake on Magic Packet".
• Windows Fast Startup: this one catches people out. Fast Startup is on by default in Windows 10 and Windows 11, and a "shutdown" with it enabled is really a hybrid state that leaves the NIC unarmed, so Wake-on-LAN from a full power-off does not work. Disable it with powercfg -h off in an elevated prompt, or clear the Fast Startup option under Power Options, so that shutdown becomes a true off state the NIC can wake from. This behaviour is documented by Microsoft.

Wake from sleep (S3) usually works without disabling Fast Startup; wake from a full shutdown (S5) generally requires it off. If you deploy the ProxyLink Windows one-liner to a machine, you can push these settings to it remotely rather than visiting the site.

The MSP payoff

One outbound tunnel per site now covers browser RDP, SSH, VNC, appliance web UIs, and remote power-on, with no open inbound ports and no static IP. Wake a shut-down PC to run a patch, revive a machine a user left off, or bring a site back up after a power cut, all from a browser tab. Every wake is tied to the engineer who triggered it, so it lands in the audit log like any other action.

Try ProxyLink free at app.proxylink.dev, no card required, free during early access. Full setup guides for each router platform are in the docs.