Wake a Sleeping Home PC Over VPN: Where the Packet Comes From

You connect, the router answers, and the desktop stays dark. The tunnel is fine; the packet that would have woken the machine never reached the segment where the machine listens. Walking the path backwards from the router shows where it dies.

Three devices have three jobs. Mixing them up is the usual reason a wake attempt loops forever.

Start at the Remote Client and Follow the Path

From a hotel network you connect to the home router, which is the only always-on endpoint in the picture. A wake request typed on your laptop becomes ordinary tunnel traffic, addressed to whatever destination you named. That destination decides everything that follows.

If you sent it to the home router's LAN address on the magic-packet port, the router may accept the datagram and never emit a frame on the home segment, because nothing there is listening for that port. If you broadcast it inside the tunnel, it stops at the tunnel interface. A routed tunnel is not a Layer 2 extension of the house wiring. Follow the path hop by hop and the dead end becomes obvious.

The check that settles it takes one command from the remote side and one from the home side. Send the request, then watch the home segment for the frame.

Move the Sender Onto the Home Segment

The router can do the waking itself once you are authenticated through the tunnel. OpenWrt documents a Wake-on-LAN service that runs on the device and emits the frame locally, which is exactly the shape needed: remote authentication outside, local broadcast inside.

That arrangement also keeps the wake function off the public internet. Nothing new is exposed to the internet, because the trigger rides the VPN you already trust. The alternative, a port-forwarded wake service, trades a small convenience for an internet-facing endpoint that anyone can probe.

The circular dependency is worth naming plainly. A VPN client installed on the desktop cannot wake that desktop, since the client process needs the machine to be running. Keep the remote entry point on the router or another always-on box, and let the desktop be only a target.

Confirm the Target Before Blaming the Tunnel

Hardware decides this part, not the VPN, and the power state decides it first. The adapter has to support wake, the firmware has to leave the adapter powered in sleep, and the operating system has to be configured to allow it. A machine that is suspended is a different case from one that was shut down, and both differ from a machine whose power supply is switched off at the wall. Settle that state before working through the rest of the list.

Read the hardware address from the adapter that will actually receive the frame. A desktop with both Ethernet and Wi-Fi often has two addresses, and only one of them may be wake-capable. Wireless wake is a separate capability with its own firmware requirements, so a working Ethernet wake says nothing about waking over Wi-Fi.

Prove the local path first. Send the magic packet from another device on the same switch and watch the machine come up. If that fails, no amount of tunnel debugging will help, and the fault is in firmware, adapter settings or the power state.

After Resume, Connect to the Service You Wanted

Waking is not remote access. Once the machine resumes it still has to boot its services, acquire an address, and accept the session you actually need. Give it time to reach that state before concluding the wake failed.

# remote side: trigger the wake through the already-authenticated tunnel
ssh [email protected] 'wol -i br-lan 3c:7a:8f:2b:11:04'

# home side: is the target answering on the LAN?
ping -c 3 10.10.0.42
arp -n 10.10.0.42

The arp line is the useful one. An entry that flips from incomplete to a real hardware address means the machine resumed and answered; a request that never resolves points back at the wake step rather than at the service you were trying to reach.

Separate the stages in your notes: wake, boot, service. A failure at stage two looks identical to a failure at stage one from a chat window, and only the local evidence tells them apart.