Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

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

share|improve this question

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 (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.

share|improve this answer

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

share|improve this answer
I was hoping the VPN servers would have some sort of build in surport for this... – Ian Ringrose Jun 29 '11 at 15:43
Typically that's not the "norm" with the VPN clients. From the VPN session itself, you can setup an intermediary system/equipment to assist with launching the "MagicPacket" against the targeted system/device. – user48838 Jun 29 '11 at 15:59

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.


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:

share|improve this answer
Welcome to Server Fault! Generally we like answers on the site to be able to stand on their own - Links are great, but if that link ever breaks the answer should have enough information to still be helpful. Please consider editing your answer to include more detail. See the FAQ for more info. – slm Apr 25 '13 at 9:57
where do I find sshd_config on a windows 7 system? – Ian Ringrose Apr 27 '13 at 17:14
@IanRingrose I have no idea cause I only work with Linux – Sir l33tname Apr 28 '13 at 9:03

I agree with user48838 - by definition the magic packet is sent only over the local subnet. However, I previously used a script written by jpo that worked from a different subnet via a normal router. Try this - YMMV

share|improve this answer

well actually the answer is YES.

I successfully use WOL over PPTP VPN using that app:

share|improve this answer
Welcome to Server Fault! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – slm Aug 22 '13 at 0:36

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:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.