802.1x EAP-TLS (Machine Cert) WoL

DM812 · ‎08-31-2023

Wondering if anyone can help. We have 802.1x setup with authentication using Machine Certificates (EAP-TLS) but coming across an issue when machines are powered off.

We have Wake on LAN enabled on our devices so when a device is powered off the NIC is still up. This is causing issues as when the authentication timer is up and the device try's to reauthenticate, it fails 802.1x due to the machine not being powered on and goes into a segregated VLAN (registration VLAN) instead of the production VLAN. When the machine is then powered on it's in the wrong VLAN as won't reauthenticate again until the timer has expired or the machine is fully restarted.

Has anyone come across this before and found a solution?

ahollifield · ‎08-31-2023

Why are you changing VLANs at all? Why not do enforcement with a dACL or SGT instead?

DM812 · ‎08-31-2023

For our trusted devices we authenticate using the machine cert which then get's the production VLAN assigned to it. Because the device is switched off, this method of auth will fail. Any device that does not auth using cert then get's hit by one of the other matching MAB rules, then failing that, get's put into a segregated VLAN. We use dACL's on specific roles/devices but this doesn't apply when the machine is powered off and failing to use it's primary auth method.

ahollifield · ‎08-31-2023

But why? Why not use dACLs for this scenario as well? If you fail authentication, apply a dACL that blocks all network access, all internal access, or whatever your requirement is. Then if you pass EAP-TLS authentication, apply a dACL that is a full permit or whatever access you need. This would avoid the VLAN change. The issue here is the machine doesn't know its VLAN has been changed and that it need to go back through DHCP again.

hslai · ‎09-01-2023

@DM812 This seems to me more an issue with either the network driver, the 802.1X client supplicant, the device OS, or any combination of them. When the device wakes up or powers ON, we expect the supplicant to initiate EAP-Request Identity to the switch as the authenticator. This does not seem to be happening.