802.1x and WOL (wake-on-lan)

[martin.belisle]

Hello everybody,  anybody here has ever configured 802.1x and WOL?

I have this configuration:

interface FastEthernet0/34

switchport access vlan 5
switchport mode access
no logging event link-status
duplex full
authentication control-direction in
authentication event fail retry 1 action authorize vlan 301
authentication event no-response action authorize vlan 301
authentication order dot1x
authentication port-control auto
authentication violation protect
no snmp trap link-status
dot1x pae authenticator
dot1x timeout quiet-period 5
dot1x timeout tx-period 20
dot1x timeout supp-timeout 10
storm-control broadcast level 30.00 15.00
storm-control action shutdown
storm-control action trap
spanning-tree portfast
spanning-tree bpduguard enable
ip dhcp snooping limit rate 30

dot1x is working but I can't get WOL to work.  What is even stranger is that with "authentication control-direction in" the interface becomes up/up even if the device is shut down and it puts the interface in VLAN 301instead of leaving it in VLAN 5.  I can live with that but I don't understand the up/up and WOL not working.

If anyone has an idea or pointers that would be greatly appreciated.

thank you.

[Giuseppe Larosa]

Hello Martin,

the two features are not good companions:

wake on lan would like to awake a standby device

802.1X wants to give network access after 802.1X authentication

or one or the other not both

Hope to help

Giuseppe

[bvj197222]

I have the same problem. According to the Cisco documentation it is possible to use WOL and 802.1x. I read the doc for 12.2.55SE and they kept referring to the commands "dot1x control-direction in" and "dot1x control-direction both" - but these commands was dropped long time ago!!! Cisco should have a better documentation QA if you ask me... The correct commands are "authentication control-direction in" or "authentication control-direction both".

both: Enable bidirectional control on port. The port cannot receive packets from or send packets to the host.
in: Enable unidirectional control on port. The port can send packets to the host but cannot receive packets from the host.

In other words the command should be "authentication control-direction in", verified by typing "show dot1x interface .....":

Dot1x Info for FastEthernet2/0/48
-----------------------------------
PAE                       = AUTHENTICATOR
PortControl               = AUTO
ControlDirection          = In
HostMode                  = SINGLE_HOST
QuietPeriod               = 20
ServerTimeout             = 0
SuppTimeout               = 30
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 10

My port configuration:

switchport access vlan 123
switchport mode access
switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict
ip arp inspection limit rate 15 burst interval 5
authentication control-direction in
authentication event fail action authorize vlan 666
authentication event server dead action authorize vlan 123
authentication event no-response action authorize vlan 666
authentication event server alive action reinitialize
authentication port-control auto
snmp trap mac-notification change added
snmp trap mac-notification change removed
no snmp trap link-status
dot1x pae authenticator
dot1x timeout quiet-period 20
dot1x timeout tx-period 10
storm-control broadcast level 5.00
storm-control multicast level 30.00
macro description desktop
no cdp enable
spanning-tree portfast
spanning-tree bpduguard enable
spanning-tree guard root
ip dhcp snooping limit rate 10

Still WOL does not work. By typing "no authentication port-control auto" WOL works, but then you turn off dot1x so that's no point. Help please??

[bvj197222]

I found out why it didn't work for me, and maybe that's the reason why it didn't work for the guy who started this thread.

The configuration of the VLAN where my WOL-server is;

ip helper-address 172.17.20.255
ip helper-address 172.17.21.255

The first time I changed the config on the port it ended up in the guest vlan, which is IP 192.168.17.xx. So the WOL-packet was never received as my WOL VLAN wasn't set up to broadcast to the guest VLAN. I had to do a shut/no shut to get the port back to the right vlan. I haven't checked enough to see if the "authentication control-direction in" command makes dot1x more unstable. We have problems with enterprise pc's ending up in the guest vlan for some reason, and we have to reboot them to get them back to the enterprise vlan.

[jp.savaria]

Guys,

with IBNS 2.0 the "authentication" command has been replaced by access-session

so the access-session control-direction in will do the same

Thanks

[PaulSmith]

You have done the correct thing by enabling 'auth control direction in'. This stops out going packets having to be authenticated and WoL will not work without it. I am wondering if the issue is further upstream? I noticed you are using VLAN 5 for your AUTH-FAIL VLAN. HAve you configured and SVI for VLAN 5 on your router? You may also need to use 'ip directed broadcast' on your VLAN 5 SVI to make sure the WoL packets travel along VLAN 5 to wake your device.

[BHAGEMANN]

Hello!

We faced this issue too. 

Our officebuilding is going through a big renovation and because of that many networkdevices like computer, printer and so on are moving round and round and from port to port.

Because of those hardwaremovements the Cisco ISE had to be ready for productive use so that we won´t have to configure the V-LAN on every port for every movement per hand. 

After some hundred movements the numbers of reports about PCs starting softwareupdates and installations on monday morning after the user bootet them and not on the weekend, rose up. 

The following is what we figured out: 

The ISE + WOL-config was right, like yours. 

Our softwaremanagement- and installation tool sends magic packets that don´t get to most of the PCs that were moved. 

We tested and found out, if PC thath was moved to another port had another V-LAN than the Port had set he would boot and get his IP when started per hand, when started per WOL nothing will happen. 

Sp long story short end: The thing was that the installation-software only sent the magic packets to the MAC-Adress. A Subnet-Mask had to be added ( f.e. 123.255.255.255 or 255.255.255.255). Somehow the reports then dropped but problem wasn´t 100% finished.

After some tests we also came to the conclusion that the UDP-Port which the software uses had to be put configured in the V-LAN where the software-server is resides because the software uses a non-standard-port for WOL.

The last change was adding the UDP-Port to the V-LAN of the software-server and couldn´t be testet yet. 

So one can say, it isnßt the ISEs fault but the ISE is involved.