/build/static/layout/Breadcrumb_cap_w.png

K1000 WakeOnLan - Some knowledge and a little bit of troubleshooting please!

Introduction

Wake-On-LAN (WOL) allows properly configured machines to resume operation from a powered-off state in response to a network request. The network request comes in the form of a magic packet which is a specially formatted network packet. An example where it becomes very useful would be a Security Patch or Service Pack that needs to be implemented as fast as possible for a set of vulnerable machines. By combining all the pieces to create a WOL-ready infrastructure, you'll end up with an environment that allows networked PCs to be both responsive 24x7 and efficient from a power consumption perspective if a form of power management solution is implemented in your environment.


This article assumes that the following is in place, working and configured properly:

All machines have a WOL compliant NIC and BIOS
A properly configured network infrastructure Wink *likeitsnotabigdeal*


Here is a great Cisco article upfront which describes steps to allow WOL traffic to pass VLANs:

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_example09186a008084b55c.shtml

Overview on the K1000 side


The above screenshot shows the Wake On LAN page. In the “Wake Multiple Devices” section you can specify / target the WOL magic packet to a group of machines which are part of the chosen label. The “Wake a Computer” section allows you to choose machines from the drop-down box. This drop-down box is based on machines that are listed in the KBOX Inventory. The “Wake a Network Device” section allows you to choose machines from the drop-down box. However, this drop-down box is based on the devices / machines which were by default successfully enumerated via the “IP-Scan” within the KBOX which you can find in the “Inventory” section. The last section which is “Manual Entry” allows you to specify a single MAC address in combination with an IP address.


How the K1000 performs WakeOnLAN

The KBOX sends out two types of WOL requests / packets, Unicast and Subnet Directed Broadcast. However, we are mainly using and succeeding with Subnet Directed Broadcast since Unicast requires the network infrastructure to be supported and set up properly. I have seen 1x out of 5x environment where Unicast requests woke up the machines!

We have seen cases where Unicast packages arrived on the client side, but it did not wake up all clients in the list of machines even though every machine received a Unicast packet from the K1000 after further checks. Subnet Directed Broadcast works for the majority of customers just fine but not in all cases.

Please see the below article which also describes how K1000 WOL works:
http://www.kace.com/support/kb/index.php?action=artikel&cat=3&id=564&artlang=en


Unicast

The screenshot below shows a Unicast packet. I am using Network Monitor from Microsoft, why not Wireshark? I don't know, I think I just like Microsoft and got used to it. Anyhow, this packet, it is a UDP packet sent over port 7 from the K1000 (192.168.44.251). It appears to be the same as the subnet-directed broadcast, but with one major exception. The Unicast packet can be identified by the 4th part of the destination address being not the broadcast address (192.168.44.112). In my case, since I set up aliases in my Network Monitor, we could see the host name which sent the packet and received the packet. The packet travels the network and is processed by only the single client on the subnet for which it was dedicated for. In this example the subnet is 192.168.44.0/24 for client IP address of .207 (see 4th part of IP address / in my case it is the WIN7CLIENT that gets that packet).

In some environments / in a routed or non-routed environment magic packets may not be successfully delivered using the unicast method. What can happen is that when the local ARP cache on the K1000 or on the router doesn’t contain an entry for a WOL target, the K1000 or the router performs and ARP request. Since the target device is in an inactive state (sleep, standby, hibernate or powered off), the ARP reply never comes back and the WOL packet is never sent. This is why in general, using the Subnet Directed Broadcast method is recommended.



Subnet Directed Broadcast

The screenshot below shows a subnet directed broadcast inside our Network Monitor. The K1000 sends another UDP packet over port 7 (192.168.44.251). The broadcast can be identified by the "255" in the 4th part of the destination address (192.168.44.255) as this is the broadcast address for my network. The packet travels the network and is processed by each client on the subnet for which it was directed to. In this example the subnet is 192.168.44.0/24 with 254 possible hosts. Again, in my case, aliases in Network Monitor show us the host names instead.



When doing the Subnet Directed Broadcast the K1000 retrieves the MAC address and IP subnet of the target computer from its inventory which is stored in the database. The Subnet Directed Broadcast is sent to the computer's subnet. Because this is a broadcast, all computers on the subnet will be targeted with the packet but only the computer that has the MAC address specified within the packet will respond/wake up. The “magic packet” makes this possible.

This transmission method uses the subnet address rather than the individual clients IP address. It will succeed, if the target computer has changed IP addresses but remained in the same subnet. The use of Subnet Directed Broadcasts is the more traditional method of sending wake up packets, so this transmission method might be more compatible with a wider range of computer network adapters than transmitting wake up packets using unicast. For subnet directed broadcasts to be successful, all intervening routers must be configured to forward broadcast appropriately.


Additional Information on the "Magic Packet"
 

The difference between the transmission methods is that the unicast packets are easily passed by routers and the subnet directed broadcast packets are not. The reason for this is the routers are normally configured to reject broadcast traffic for security reasons. Rules will need to be applied to the Routers and Layer-3 Switches (VLANs) to pass through each broadcast domain (also known as a hop) from the source (K1000) to the destination subnet (Machines which you want to wake up).


More details on the "Magic Packet"

The screen dump below shows a Magic Packet. This is the data inside the unicast data frame which is processed by the target computers NIC. The WOL compatible NIC in a powered off machine computer is constantly processing all data frames searching for this magic sequence of bytes. The unique WOL packet consists of a header of 6x 0xff (FF-FF-FF-FF-FF-FF) followed by the physical address of the card (48-bit MAC address 00-0C-29-6F-3B-40) repeated 16 times. By matching to its own MAC address, the client is able to determine if it is the magic packet or if it is supposed to wake up.

The second screenshot below shows a Magic Packet. This is the data inside the Subnet Directed Broadcast packet which is processed by the target computers NIC. We make the same experience as with the Unicast packet, however the first bytes contain the broadcast address (FF-FF-FF-FF-FF-FF) which you can also use to identify this frame as Subnet Directed Broadcast. The reason why only the desired machines wake up, is the fact that the frames also contains the machines NIC’s MAC address repeated 16 times.

Note that WOL magic packets are delivered to the computer’s IP address that is stored in the K1 database. There should not be any issues with desktop class devices being woken up since their IP address should rarely change, but it is possible for a laptop to be connected in a new network location in-between K1 hardware inventory cycles. This would result in the K1 sending the magic packet to the wrong subnet.


Subnet Directed Broadcast  - Security concerns

This broadcast traffic type can be used to specify hosts on a network as a method for a denial of service (DOS) attack. For example, by blocking specific source addresses, you prevent malicious echo requests from causing cascading ping floods.

Directed broadcasts are used in the standard "Smurf" DOS attack, and can also be used in associated attacks as well. In a "Smurf" DOS attack, ICMP echo requests are sent from an erroneous source address to a directed broadcast address, causing all the hosts on the target subnet to send replies to the inaccurate source. Transmitting a constant stream of ICMP echo requests can render the hosts on the subnet useless.

Subnet Directed Broadcast - Security mitigation

Broadcasts are now and then used for valid purposes, such as in this systems management solution (K1000). In order to lower the vulnerability exposure of a DOS attack, routers need to have security access controls assigned (ACLs). These access controls would only allow subnet directed broadcasts that originated from the address of the K1000. In the event of a security issue / vulnurability the K1000 can be isolated from the network easily and remediation can be performed quickly.


Simply Troubleshooting K1000 WOL

1. Install Network Monitor or Wireshark on the client system

2. Capture the traffic while the machine is online

3. Filter the traffic for UDP traffic and the K1 IP as the source and find the magic packet

4. Verify if you see similar packets as shown above arriving perhaps with focus on the Subnet Directed Broadcast depending on your network infrastructure.

If the Subnet Directed Broadcast will not arrive, configure your network infrastructure for Subnet Directed Broadcast unless Unicast will do it for you. For instructions you can refer to the network device vendor or consult your local networking team. If there is anyone out there that can provide more input and some hints, or even correcting what I got wrong with my mini-networking-knowhow, please knock yourself out!


Cheers,
Rasko


Comments

This post is locked
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ