Wake-on-LAN over VPN not working? The broadcast never crosses

You put the office machine to sleep, dial the VPN from home, and it stays off. The tunnel is up, file shares answer, and the router's wake-on-LAN page reports that it sent the request. Every visible signal says the network is fine, which is exactly why this one is confusing: the frame that would wake the machine never reaches the segment it lives on.

The symptoms point at the subnet, not the tunnel

Ping fails for the sleeping host, and that part is normal. A machine in standby has no running IP stack, so it cannot answer ARP or ICMP, and no amount of tunnel configuration changes that. The useful test is whether a second machine on the same LAN wakes, and whether the router's own wake page works for a host plugged into it.

Once the same-segment test passes, the failure is scope. The sender you are using lives on the VPN interface, and the packet it builds is a broadcast for the local link, so it goes out of the wrong interface or nowhere at all. The tunnel is not broken; it is carrying the wrong kind of traffic. Find out which interface the sender picks before you change a single router setting.

A magic packet is a frame, not a service

The payload begins with a fixed header of six 0xFF bytes, then the target card's hardware address repeated sixteen times, then an optional four-byte SecureOn password. Senders conventionally wrap that in UDP to port 7 or port 9, but the port number is a convention shared between sender and card, not a listener you can connect to. Nothing is listening, and nothing replies.

What wakes the machine is the network interface, which keeps a small amount of circuitry powered from the standby rail while the rest of the system is off. That is why the setting has to survive a full power loss as well as a sleep: a board that drops standby power on shutdown has no card left to receive anything.

Why a routed tunnel cannot deliver it

A routed VPN interface is a point-to-point IP link between two tunnel addresses. It exists to carry packets addressed to the peer, which is why ping, SSH and file shares behave normally through it. A broadcast frame is not addressed to that peer, and the limited broadcast address is never forwarded by a router as a matter of course.

Forwarding a subnet-directed broadcast is a deliberate router capability that most default configurations disable, and even then it delivers to that subnet rather than to a specific sleeping card. A sleeping host also cannot answer ARP, so a router that tries to resolve the target address before forwarding drops the frame while it waits for a reply that will never come. A static binding entry fixes that part and still leaves the broadcast scope problem untouched. Two separate restrictions, then, and clearing one does nothing for the other.

Three placements that actually reach the card

Every workable arrangement puts the frame on the target's segment, and they differ in how much of the network they disturb:

1. Put an always-on device on the target segment. A router, NAS or small Linux box that stays powered can emit the frame locally once you reach it through the tunnel, and nothing about the VPN changes.
2. Let the router emit the frame itself. Many firmwares offer a wake page that sends from the LAN bridge, which works as long as the target sits on that bridge rather than behind a second router.
3. Bridge the sites with a TAP-style tunnel when broadcasts genuinely must cross. That merges two broadcast domains, bringing broadcast storms, a single address plan, and every discovery protocol seeing both sites at once.

The first option is the one to prefer for a single machine. The third is a network design decision with ongoing cost, so treat it as such rather than as a quick fix for one desktop.

Record which helper sends the frame and which bridge or VLAN it sits on. A helper that emits on the wrong interface produces a perfect capture and a machine that never wakes, and that combination wastes an afternoon.

Verify the send before you blame the client

Check the target card first, because no sender can wake a card that is not armed. The command below reads the supported and current wake modes, where a current value of g means magic packet is enabled:

ethtool enp3s0 | grep -A1 'Wake-on'
ip neigh show 192.168.1.50
tcpdump -ni br0 -e 'ether broadcast and udp dst port 9'
etherwake -i br0 3c:7c:3f:00:11:22

Run the capture on the helper while the send happens, and read it rather than assuming success. A frame leaving the correct bridge with the broadcast destination MAC is the only evidence that the send worked; if the capture is empty, the sender chose another interface and the rest of the test is meaningless. A sender that builds a raw frame instead of a UDP datagram will not match that filter, so check which form your tool uses before concluding that nothing was sent.

On Windows the equivalent card check is powercfg /devicequery wake_armed, which lists the devices allowed to wake the system. A network adapter missing from that list will ignore every packet sent to it, however correct the frame looks on the wire.

Then confirm the wake itself and the follow-up. A machine that powers on but stays unreachable by name needs a static address and a DNS record, because broadcast name resolution still will not cross the tunnel. Wireless wake is a separate and far less dependable capability than the wired version, so test it on the same segment before involving the VPN at all. Write the interface name and the helper host into the ticket, since the next failure usually involves the same two facts.