The problem with a central WOL deployment is the network security part. Why? WOL mostly uses broadcast frames to send the Magic Packet to the MAC-Address of the this client. Broadcasts are blocked by the first router in the network (usually the default gateway of the subnet the WOL server is connected to). Every routing hop in a corporate network specifies a separate broadcast-domain. Broadcasts are limited to these subnets between 2 routing hops.
How to pass this first boundary?
On Cisco routers or layer-3 (and up) switches you can use the ‘ip helper-address ip-address’ command to specify an ip address to forward broadcast frames transformed to unicasts.
The ‘ip helper-address’ command is mostly used to enable local subnets to receive DHCP-leases from a remote DHCP server. The picture below shows this setup:
The configuration on the Cisco device functioning as the default-gateway is limited to:
> interface fastethernet0/0
> ip helper-address 10.0.0.10
In this scenario it’s the client who’s sending the broadcast onto the local subnet, which is picked up by the Cisco router. The Cisco router transforms the broadcast into an unicast and sends it to de DHCP-server.
By default a Cisco router will forward the following eight broadcasts to the addresses specified by the ‘ip helper-address’ command:
1) Time Protocol (port 37)
2) TACACS (port 47)
3) DNS (port 53)
4) BOOTP Client (port 67)
5) BOOTP Server (port 68)
6) TFTP (port 69)
7) NetBios (port 137)
8) NetBios Datagram (port 138)
Now let’s see what is needed to get WOL working from the Datacenter to the remote locations is the scenario presented below:
Like we’ve seen with the DHCP setup. In order to forward a broadcast frame to another ip address we’ll have to use to ‘ip helper-address’ on the local subnet, but a WOL frame doesn’t come with an ip-address. It’s a broadcast frame which contains the MAC address of the system we want to wake-up. This is the reason why we’ll have to specify the broadcast address of the remote subnet as the ‘ip helper-address’. This way, the frame will be forwarded to the broadcast address of the local subnet and all thin clients will receive the frame, but only the system with the MAC-address specified in the payload will be woken-up.
So in order to forward the WOL frames to the two remote subnet’s we’ll use the following config:
> configure terminal
> interface fastethernet0/0
> ip helper-address 10.1.1.255
> ip helper-address 10.2.2.255
But there’s one more thing that needs to be done on the central side of the corporate network. Remember that there are only eight types of broadcasts that are forwarded by default? Well, WOL isn’t (in most cases) one of them.
We’ll have to specify to UDP-port that the WOL packet will be transmitted to. In some cases this port is 0 (discard) or 7 (echo), but it could be any port depending on the type of software used. For example, the utility ‘wol.exe’ uses UDP port 12287. In order to find out which port is being used you can use Wireshark to sniff some WOL packets and check the UDP Layer header information:
Note: For this blog I generated a WOL packet to a non-existing MAC-Address (Green Circle)
Now that we know which port (Red Circle) the WOL packets are transmitted to, we can use the ‘ip forward-protocol’ global config command to enable the forwarding of broadcast frames on that specified port.
> configure terminal
> ip forward-protocol udp 12287
The central part of the configuration is done, all WOL packets on port 12287 are forwarded to ip-addresses 10.1.1.255 and 10.2.2.255. Still, we’ll have to make sure that on the remote location the forwarded broadcasts are transmitted out onto the local subnet where the thin clients are located. Because the x.x.x.255 addresses are broadcast addresses this will not work by default. ‘ip directed-broadcasts’ have to be enabled on the local interface in order to transmit the WOL frames as broadcasts onto the local subnet. To secure this behavior we will add an access-list to the command specifying which systems are allowed to send directed broadcasts.
On the remote locations we’ll add the following configuration:
> configure terminal
> access-list 101 permit udp host 10.0.0.10 any eq 12287
> interface fastethernet0/0
> ip directed-broadcast 101
That’s it! Thin clients on the remote locations can now be woken-up with WOL frames originating from the central WOL server.
