Wake-on-LAN over VPN stops working? Fix the ARP entry
Magic packets cross the tunnel, but the router drops them after its ARP entry expires. Compare three delivery paths, then pin the MAC address permanently.
Send a wake packet right after shutdown and the PC comes back; the same command the next morning does nothing. Nothing in the VPN configuration changed, and the port forward still points at the right address. The difference is time: the router's neighbour table has forgotten the sleeping machine, so it has no MAC address to put on the frame. That expiry, not the tunnel, explains most Wake-on-LAN failures over a VPN.
The first wake works and the next one does not
A router forwards a frame to a private address by looking up the destination in its neighbour table. While the machine is running it answers ARP, so the mapping stays fresh. Once it powers off, nothing answers, the entry ages out after a few minutes, and later frames for that address are dropped even though the IP and the port forward remain valid.
The pattern tells you which failure you have. A wake that never works at all points at delivery: wrong port, wrong destination, or a firewall that drops the packet before it reaches the LAN. A wake that works once and then fails for hours points at the neighbour entry. A wake that works until the DHCP lease changes points at addressing, which a reservation fixes.
Confirm the address is stable before touching ARP. If the sleeping machine takes a new address after a lease expires, a pinned neighbour entry for the old address will be permanent and useless at the same time. Set a DHCP reservation first so the address survives reboots.
What the magic packet needs from the network
The payload is simple: 102 bytes made of six 0xFF bytes followed by the target MAC address sixteen times, usually sent to UDP port 9. On a flat LAN it goes out as a broadcast, every port receives it, and the powered-off network card recognizes its own address.
Across a VPN the packet arrives at the router as unicast to a private address or as a subnet-directed broadcast. In the unicast case the router must resolve the destination to a MAC address before it can put the frame on the LAN, and that resolution is exactly what fails while the host sleeps.
Some tools send to port 7 instead of 9, and some appliances block directed broadcast by default. Those are delivery failures, not ARP failures, so check the destination and port before changing the neighbour table.
Three routes to a sleeping host
You have three practical ways to get the frame onto the LAN, and the right choice depends on what you control.
| Method | What it needs | Where it breaks |
|---|---|---|
| Subnet-directed broadcast | A wake tool that accepts a broadcast address and a router that forwards it | Broadcast filtering, or a tool that only takes a MAC |
| Helper on the LAN | An always-on host such as the VPN server | No suitable host, or the host cannot reach the target VLAN |
| Permanent neighbour entry | Router shell access and the target MAC | NIC replacement or address change |
Choose the helper host when one exists, because it broadcasts on-link and needs no router exception. Choose directed broadcast when the router already permits it and the wake tool supports an address. Choose the static entry when neither is available and you can run a command on the router.
These are not mutually exclusive. A permanent entry also makes the unicast path survive sleep, which is useful when the VPN client can only send to a specific address.
Make the neighbour entry permanent
On a router with a Linux shell, one command pins the mapping. The values here belong to an example LAN and must be replaced with your own:
ip neigh replace 192.168.50.23 lladdr 3c:7c:3f:12:9a:4e dev br0 nud permanent
ip neigh show dev br0 | grep 192.168.50.23The nud permanent state keeps the entry across ARP timeouts and uses it for forwarding while the machine is off. The second command proves the entry exists and shows the interface it belongs to, which matters on routers with a separate guest bridge or VLAN.
Make it survive a reboot through whatever hook the firmware offers: a script in /jffs/scripts on Asuswrt-Merlin, a systemd oneshot unit on a Linux server acting as the gateway, a Neighbor= stanza in systemd-networkd, or an /etc/ethers entry where the local tooling reads one. A command typed into a shell disappears at the next restart, which is the most common reason a working fix appears to stop working.
Test from outside and know when to remove it
Put the machine to sleep and wait at least ten minutes, long enough for any dynamic entry to expire. Then send the wake request from the VPN client and watch both sides of the router:
tcpdump -ni tun0 udp port 9
tcpdump -ni br0 ether proto 0x0806 or udp port 9The first capture proves the packet arrived from the tunnel; the second proves the router put a frame on the LAN. A valid magic packet shows as 102 bytes with the MAC repeated, so check the length as well as the destination. If the frame leaves the LAN bridge and the machine stays off, the remaining problem is on the device: fast startup, deep sleep or a BIOS setting that cuts power to the network card.
Remove the entry when the network card changes, and update it when you move the machine to another address. A permanent mapping is a deliberate exception, and an exception nobody remembers is how a future laptop ends up receiving frames meant for a retired desktop.