Thursday, 6 December 2018

Wake on LAN in ConfigMgr 1810 and 802.1x authentication

I recently carried out some testing on the new Wake on LAN feature of ConfigMgr 1810 and published the result in this blog post. One of the things I pointed out was that the feature was not supported using 802.1x authentication. I wondered why so I carried out some additional research.

As with all Microsoft support statements, just because something is not supported doesn't mean that it will not work. It's either untested or will not work in all scenarios. This is the case with WoL and 802.1x authentication.

802.1x is a standard for port-based network access control that provides authenticated network access to 802.11 wireless networks and wired Ethernet networks. Port-based network access control uses the physical characteristics of a switched LAN infrastructure to authenticate devices that are attached to a LAN port and to prevent access to that port in cases where the authentication process fails. One of the features of 802.1x is that devices are quarantined when they are turned off. Therefore the switch ports becomes blocked in both directions and prevents the WoL magic packet from being delivered - a chicken and egg situation. 

I figured that this couldn't a new problem and that it would be possible to overcome this in the enterprise. I was right. I researched the main networking vendors and found that they had solutions.


The 802.1X authentication with Wake-on-LAN (WoL) feature solves the problem. When a host that uses WoL is attached through an 802.1X port and the host powers off, the 802.1X port becomes unauthorized. The port can only receive and send EAPOL packets, and WoL magic packets cannot reach the host. When the PC is powered off, it is not authorized, and the switch port is not opened.

When the switch uses 802.1X authentication with WoL, the switch forwards traffic to unauthorized 802.1X ports, including magic packets. While the port is unauthorized, the switch continues to block ingress traffic other than EAPOL packets. The host can receive packets but cannot send packets to other devices in the network. 
  • When you configure a port as unidirectional by using the dot1x control-direction in interface configuration command, the port changes to the spanning-tree forwarding state. The port can send packets to the host but cannot receive packets from the host. 
  • When you configure a port as bidirectional by using the dot1x control-direction both interface configuration command, the port is access-controlled in both directions. The port does not receive packets from or send packets to the host.
Note: If PortFast is not enabled on the port, the port is forced to the bidirectional state.


The aaa port-access controlled-direction in command allows Wake-on-LAN traffic to be transmitted on an 802.1X-aware egress port that has not yet transitioned to the 802.1X authenticated state; the controlled-direction both setting prevents Wake-on-LAN traffic to be transmitted on an 802.1X-aware egress port until authentication occurs.

Note: Although the controlled-direction in setting allows Wake-on-LAN traffic to traverse the switch through unauthenticated 802.1X-aware egress ports, it does not guarantee that the Wake-on-LAN packets will arrive at their destination. For example, firewall rules on other network devices and VLAN rules may prevent these packets from traversing the network.

Aruba Networks (not Procurve)

In Aruba AOS (not Procurve) there is a MAC pinning feature which basically adds a static MAC address to the port and associates it to the authentication as a pinned-MAC. All traffic to that MAC address would be pre-authenticated and anything else would need to be authenticated.


For enterprise grade edge switches I would expect a solution for this problem. You may not be so lucky with low end switches and your mileage may vary. That's why this solution is not officially supported by Microsoft.  
I hope this helps. Until next time.......

No comments:

Post a Comment