As we saw in a previous article, Wake on LAN is a network protocol that allows a computer to be remotely booted by sending a special packet called Magic Packet.

Trying to be vaguely technical, it is important to remember that this protocol operates on layer 2 of the OSI model. In other words, Wake on LAN packets are transmitted as Broadcast UDP and are therefore limited to the local network in which they are generated.

This means that in more complex network environments, such as those with VLANs and routers, if we want to ensure that WoL packets can reach the desired destination, even cross-network, we will have to make specific configurations. Let’s look at some options from real use cases.

WoL Cisco with IP directed broadcast

Quoting Cisco:

An IP directed broadcast is an IP packet whose destination address is a valid broadcast address for some IP subnet but which originates from a node that is not itself part of that destination subnet

Take the case of the image in the figure where Host A from Vlan 100 has to send the WoL packet to Host B on Vlan 200.

cisco ip directed-broadcast

The first thing we notice is the L3 switch SW 1 acting as a router for our Vlan, in fact it will be in charge of routing the WoL packet through its SVI (Switched Virtual Interface). SW 2 and SW 3 can also be simple unmanaged distribution switches, each working exclusively in its assignment VLAN.

This is the configuration:

SW1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#ip routing

!--- Routing must be enabled

SW1(config)#access-list 100 permit udp host any eq 7

!--- This accepts directed broadcasts only from Host A.

SW1(config)#ip forward-protocol udp 7 

!--- Specifies the protocol and port to be forwarded. 
!--- The port number may vary with the WOL utility used.

SW1(config-if)#interface vlan 100
SW1(config-if)#ip address
SW1(config-if)#ip helper-address

!-- Enables forwarding of WoL IP broadcast packets (dst= to clients. 
!-- Works in conjunction with the ip forward-protocol command.

SW1(config-if)#interface vlan 200
SW1(config-if)#ip address
SW1(config-if)#ip directed-broadcast 100

!--- Enables the translation of a directed broadcast to physical broadcasts.
!--- Here 100 is the acl


With this setup, the destination to be entered in the Wake on Lan program is

What actually happens

Continuing with the example given earlier at Layer 3 WoL packets can be of two types:

  • IP broadcast, with src=<sender_ip> and dst=
  • IP directed broadcast, with src=<sender_ip> and dst=

From the perspective of the switch, however, Layer 2 looks like this:

  • IP broadcast, with src=<sender_mac> and dst=ff:ff:ff:ff:ff:ff.
  • IP directed broadcast, with src=<sender_mac> and dst=ff:ff:ff:ff:ff:ff.

This means that at the switching level both packets are Ethernet broadcasts to be forwarded on all ports of the same LAN/VLAN, at the routing level only an IP directed broadcast packet can be accepted and will be forwarded only if the router is configured to do so.

The interesting thing, now that we know more about what happens behind the scenes, is that we can find alternative ways to deliver WoL packets to remote destinations.

WoL with static ARP

With a static ARP record, a broadcast layer 2 can be generated using a layer 3 unicast packet.

Consider two networks interconnected as in the figure through their respective routers

routed wakeonlan

We can use a dummy IP, say, to generate the layer 2 broadcast. We will just configure on R2 a static ARP record like this one

arp ffff.ffff.ffff
and…we are done! Any WoL packet sent to will be received by all hosts on the network.

WoL unicast with Layer 2 flooding and static ARP

Not all routers allow the configuration of an ARP record with MAC ff:ff:ff:ff:ff:ff, but in such cases we can partially recycle this configuration and rely on the standard operation of switches, flooding.

Put in simple terms, Layer 2 flooding is what happens on switches when they receive a frame with a destination MAC address that is not in their memory. To ensure that the frame reaches the recipient, the switch then broadcasts the frame on all ports except the one it came from.

Do you see where I’m going with this? Let’s try it on this network in the figure.

wol watchguard helper

WoL WatchGuard without Directed Broadcast

Say we need to send our WoL packet at Layer 3, WatchGuard for example does not support IP Directed Broadcast or even static ARPs with MAC ff:ff:ff:ff:ff:ff. Let us see how to exploit Layer 2 flooding to our advantage.

First we set a static dummy ARP record for with a MAC like ff:ff:ff:ff:ff:fe. Without this, the WoL packet would be discarded on the Firewall since it would attempt, in vain, an ARP response from the host (which does not exist).

wol watchguard directed broadcast

Then… then that’s it, we’re done: sending the WoL packet to the IP this will be forwarded on the switch which, not knowing the MAC ff:ff:ff:ff:ff:fe, will trigger a layer 2 flooding by forwarding it on all ports and thus reaching the target host as well.

Little tip: if you don’t like to reserve an address on the production network for this purpose (our you can configure a Secondary IP on the target network, perhaps with a reduced subnet, e.g. a, the only fictitious IP that can be configured becomes at this point the which will have to be entered in static ARP.

wol watchguard directed broadcast secondary ip


The beauty of these techniques, at least for me, is that although not very popular they are based on the application of the theoretical concepts underlying networking. As is often the case, solutions, even if they are not immediate, can be found by shuffling the cards we already have.

What about you, did you know these techniques? My advice, of course, is to consider well which ones to use and before putting them into production delve into some concepts that in no particular order can be: smurf attacks, acl, storm control.
Have a good in-depth study!