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.
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 192.168.100.5 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 192.168.100.254 255.255.255.0
SW1(config-if)#ip helper-address 192.168.200.255
!-- Enables forwarding of WoL IP broadcast packets (dst=255.255.255.255) to clients.
!-- Works in conjunction with the ip forward-protocol command.
SW1(config-if)#interface vlan 200
SW1(config-if)#ip address 192.168.200.254 255.255.255.0
SW1(config-if)#ip directed-broadcast 100
!--- Enables the translation of a directed broadcast to physical broadcasts.
!--- Here 100 is the acl
SW1(config)#^ZWith this setup, the destination to be entered in the Wake on Lan program is 192.168.200.255.
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>anddst=255.255.255.255. - IP directed broadcast, with
src=<sender_ip>anddst=192.168.200.255.
From the perspective of the switch, however, Layer 2 looks like this:
- IP broadcast, with
src=<sender_mac>anddst=ff:ff:ff:ff:ff:ff. - IP directed broadcast, with
src=<sender_mac>anddst=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
We can use a dummy IP, say 192.168.200.200, to generate the layer 2 broadcast.
We will just configure on R2 a static ARP record like this one
arp 192.168.200.200 ffff.ffff.ffff192.168.200.200 will be received by all hosts on the 192.168.200.0/24 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 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 192.168.200.200 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 192.168.200.200 host (which does not exist).
Then… then that’s it, we’re done: sending the WoL packet to the IP 192.168.200.200 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 192.168.200.200) you can configure a Secondary IP on the target network, perhaps with a reduced subnet, e.g. a 172.16.31.254/30, the only fictitious IP that can be configured becomes at this point the 172.16.31.253 which will have to be entered in static ARP.
Conclusions
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!