The server wakes up the client by generating a broadcast that contains, somewhere in the packet, a magic sequence. The magic sequence consists of six bytes of FF followed by the MAC address of the target, repeated 16 times. It has to be a broadcast because a client in standby is unaware of its IP address. It's all done with MAC addresses.
When a server is addressing a client on a remote LAN, I'm not sure whether it is intelligent enough to send its packet to the presumed directed broadcast
address of the remote LAN, but I assume not - I assume it broadcasts it splat regardless of its location. (If anyone knows otherwise, please let me know.)
So on the (V)LAN where your server resides, you need an ip helper-address to the directed broadcast address of the (V)LAN where the client resides. (If there are several remote LANs, you need one command for each. This will be forwarded to the remote (V)LAN. Once there, it will be transmitted as a broadcast, but only if ip directed-broadcast is enabled.
Yes, you can make this more secure by restricting the ip directed-broadcast on the client LAN to an access list. Make a standard access list containing just the address of the server, and attach it to the ip directed-broadcast command. That will allow the server to generate the directed-broadcast and nobody else.
Of course, it is not 100% secure because the broadcast (like almost all broadcasts) is connectionless. That makes it easy to spoof. Anybody could generate a magic packet, ostensibly from the server, to the directed broadcast address of the client's LAN, and wake up the client (if they know the MAC addresses, which is difficult from a remote location).
Hope that helps.
Kevin Dorrell
Luxembourg
