Wake on LAN via Router

The VPN gives you an IP address on the target network, as well as the address on your local network — make sure the two networks are not in the same IP subnet, as VPNs are based on IP routing and IP routing gets confused when your local subnet and your VPN-connected subnet match. Last I checked, the Wake-on-LAN uses pretty much protocol to get the data to the target host including UDP (some examples), so it should work over a VPN connection. If you've configured all traffic via the VPN and have disparate subnets, you should be able to get UDP or an Ethernet multicast to the target box.

I'm not sure, but I think that the Wake-on-LAN packets that are sent, are LAN only broadcast packets sent to the nn:nn:nn:nn:nn:nn MAC (Media Access Control) address, not the Mac's IP address.

<https://en.wikipedia.org/wiki/Wake-on-LAN>

If your VPN server makes your home Mac appear on the same subnet as your work Mac, then Wake-on-LAN might work, but I would think a VPN server would not want to send all the various local LAN house keeping packets across the internet (I'm making an assumption about that).

Generally, the way remote Macs are woken up is if the remote Mac has either a "Sleep Proxy" server on the same LAN as the remote Mac, or if the remote Mac's local LAN router supports "Subnet Directed Broadcasts" or a Wake-on-LAN gateway service (I suppose Sleep Proxy falls into this catagory, but the above Wikipedia article gives more details and links).

NOTE: I am not a Wake-on-LAN expert, but I have bumped into it enough to learn a few things that make me a danger to myself. Besides, would not like to bet against Huff, as he is generally more right then I am 🙂

BobHarris wrote:

I'm not sure, but I think that the Wake-on-LAN packets that are sent, are LAN only broadcast packets sent to the nn:nn:nn:nn:nn:nn MAC (Media Access Control) address, not the Mac's IP address.

<https://en.wikipedia.org/wiki/Wake-on-LAN>

...

NOTE: I am not a Wake-on-LAN expert, but I have bumped into it enough to learn a few things that make me a danger to myself. Besides, would not like to bet against Huff, as he is generally more right then I am 🙂

It is the MAC address embedded in a specifically-formatted message — in an Ethernet "frame" — that arrives at the target network controller that matters.

An Ethernet ("layer 2") multicast packet ("frame") is the classic approach for distributing these messages on a target Ethernet network, but a UDP multicast or even unicast packet ("frame") should work fine, too — just as long as it gets to the target network and into visibility at the target network controller. Again, you don't need to use the multicast address here — just any address that the NIC on the slumbering computer is (still) listening to. If you do know the NIC IP address, then you're good to go — otherwise, you end up using a UDP or Ethernet multicast. You very likely do not want to use the broadcast address here, either.

That's what the Wikipedia text "The magic packet is a broadcast frame containing anywhere within its payload 6 bytes of all 255 (FF FF FF FF FF FF in hexadecimal), followed by sixteen repetitions of the target computer's 48-bit MAC address, for a total of 102 bytes." is trying to impart.

See the Python examples in comments.

Now there are various things within the network connection that might conspire against the desired result here, which is what makes this more interesting — VPN subnet routing, Wi-Fi networks and many switches are not fond of distributing packets "unnecessarily", for instance. A unicast or multicast UDP packet should get to the target network, if VPN and subnet routing is configured correctly. (Or if it doesn't, try sending it again. This is UDP, and the U is for Unreliable, after all.)

The sleep proxy is a box that wakes up the (sleeping) target box, when there's network activity that might matter to the target box. Though I've not checked the implementation, I'd very much expect that wake-up from the proxy does use WoL, too.

It'd be nice to have an Apple LOM-analog or HP iLO-style or Dell DRAC-style management processor available for at least some OS X systems (and with remote power management and other services), but that's not been a feature of any Apple hardware since Xserve days.