Can Wake on LAN work on VPN connection?

Question

Is it true that we can’t allow any machine to sleep that may need to be accessed via a VPN connection?

(I am asking this on server fault as it is as much about VPN servers than about the end-user PCs sleeping)

Answer 1

Old thread but I wanted to chime in because it is still the top rated search result for "wol over vpn".

Yes the WOL magic packet is defined within the constrains of layer 2 but this does not mean it cannot be contained inside a network and transport protocol entity which can then be used to route it across the VPN. The reason for this is the "magic" sequence can be anywhere within the payload. So essentially it becomes a matter of getting a regular routable packet to the target host with the "magic" sequence inside its payload.

Most implementations of the magic packet use UDP port 9 although this really does not matter as long as it is routed correctly and transmitted on the same broadcast domain as the target computer. As long as the VPN client has the correct routes, it can send a broadcast packet such as 192.168.1.255 (a broadcast address) correctly to the VPN gateway across the internet.

So routing it is really straightforward, the issue may lie with broadcasting it correctly from the target VPN gateway. This means configuring the VPN gateway/finding an option, to forward broadcast traffic from VPN remote clients to the local network.

Answer 2

Typically no since the "MagicPacket" is actually at layer 2. It's not even routable without the assistance of forwarders (e.g. IP helper).

Answer 3

Yes you can, instead of sending the WoL packet to broadcast address in target network, just send it to the IP address of the machine you want to wake up. Programs tested with PPTP VPN:

• http://www.nirsoft.net/utils/wake_on_lan.html
• https://play.google.com/store/apps/details?id=com.overlook.android.fing

Answer 4

There are 2 points to analyze.

1 - Routing.
2 - Converting the ip to mac address. (arp table)

Most people know how to route. What happens is that people route packages correctly but does not know why they can´t wake on lan the device. As arp protocol (address resolution protocol - arp) is done automatically, people don´t have much knowledge on how it works, to proper understand the problem.

I´m going to use a very simple explanation without detailing too much, to be easy to understand the concept. When a router receives a package (so routing is already working ok) and needs to send the packet to the machine, it needs to translate the ip to the mac address. The package arrives, the router converts the ip to mac, and send it to the machine.

What the router do to have this mac? How does it know the mac of every machine?
It asks! So when it receives a package to the ip 192.168.1.45 for the first time, a package is sent via broadcast, and the 192.168.1.45 will answer. When the answer arrives, the address goes to the arp table. Now he knows the mac address and don´t need to ask for it again(for 6 hours). When a package for that machine arrives, it uses the mac address on the table, without asking again.

Ok. So the router needs to know the mac address of the machine to be able to send information.

For the Wake on Lan package, where is the problem?
The router will not have the mac address of the machine, that is powered off and probably it will not be on the arp table anymore (default is to hold the address on the table for 6 hours before asking again).

What is going to happen without the mac address?
The router is going to "ask" for the mac address, but the machine is powered off, and will not be able to answer to the router. Then the router, without that info, will drop the package.

How to solve the problem?
By adding a fixed arp entry on the router. This way the router will always know the mac address and will be able to send the packet to the machine even when it is powered off!

On a Openwrt router, you need to use the ip package. And you need to install it first.

For this example, we need to wake up the 192.168.1.45 ip with the 00:de:ad:be:gf:00 mac address. For this we will use this command (add it to the startup script from the router):

ip neigh add 192.168.1.45 lladdr 00:de:ad:be:gf:00 nud permanent dev br-lan

Now the mac address of the machine is known (on the br-lan network)

Now what?
Now the router will try to route the package to the powered off machine, and will be able to send the package, as it knows the mac address that is fixed on the arp table!
Now you can use several tools to be able to wake the machine properly over the vpn!

Wol software:

• Windows:
  https://www.tweaking4all.com/applications/miniwol2/
  When you open the program, it will send the wol package to the configured machines and then exits itself.

• Android:
  https://play.google.com/store/apps/details?id=co.uk.mrwebb.wakeonlan

WOL without VPN - Over the internet!
You can also send it over WAN (over the internet) without vpn, by using the same principle.

• Add the address to the arp table ("ip neigh add" stuff above)
• Make a DNAT over wan udp 9 port pointing to the machine, udp 9 port.

Answer 5

There is a fancy way to build a Layer 2 tunnel with SSH, and with this WOL should work well. Therefore I see no reason to do without sending machines to sleep.

On the basis of @slm mention I included the important parts of the source below.

Prerequisites:

1) both computers must have root login enabled. (sorry – your credentials on both computers must allow you to create the TAP device). This means: on the system level, root has a password;

2) in the sshd_config file of the host that’s running the ssh daemon, the options PermitTunnel yes and PermitRootLogin yes are set;

3) ip forwarding is enabled in the kernel. Use the sysctl command to set this option: sysctl -w net.ipv4.ip_forwarding=1 ; also, add the line net.ipv4.ip_forwarding=1 to your /etc/sysctl.conf file for the setting to stick after you reboot. Do this on both computers;

4) You have installed the bridge-utils package, or otherwise have the brctl command available to you, on both computers.

Create the tunnel:

ssh -w 1:1 -o Tunnel=ethernet hostname

the -w option sets the name of the TAP device on either host (here, tap1 will be created on both ends).

the -o option is for specifying a config file option on the command line. We use Tunnel=ethernet to set up a layer 2 tunnel.

This form will keep the ssh session open in the foreground. If you’d like it to relinquish the shell after the tunnel is established, you can use the -f option to tell it to fork into the background. It needs a command to fork, though, so you can just use a dummy command such as true to get it to work. You could also use this functionality to set up the bridge on the remote end, but I’m not getting into that right now. So, it would look like this:

ssh -f -w 1:1 -o Tunnel=ethernet hostname true

Add TAP devices to a bridge:

brctl addbr br0; brctl addif tap1; ifconfig tap1 up; ifconfig br0 up

you run this on both hosts (Notice that I didn’t assign an IP). brctl is the command to use to manipulate bridge devices. brctl addbr adds the bridge br0, and the addif command joins the tap1 device to it.

Next up would be to add physical ethernet interfaces to the bridge device. How you’d want to do that will vary, so I’ll go over a couple of scenarios. The first scenario is where your VPN peers are on the same subnet (i.e., no routing between them), and the second scenario will be over the Internet.

Shameless stolen from: http://la11111.wordpress.com/2012/09/24/layer-2-vpns-using-ssh/

Answer 6

well actually the answer is YES.

I successfully use WOL over PPTP VPN using that app: https://play.google.com/store/apps/details?id=com.benfinnigan.wol&hl=pl

Answer 7

I've tested this and the answer is YES :)

I found a tool on the internet that sends the WOL packet as uni-cast to the intended host, by which avoid passing the broadcast packet through the router issue.

One point you need to watch out with this solution, you need to put Static arp entry on the router since the host will be off and will not respond to the router ARP request. Cheers!