Solved: Client not requesting DHCP when on dot1x auth-fail vlan

jason.eberhard · ‎03-19-2009

Switching vlans works fine when the user is authenticated. The machine is on vlan X, user logs in, port changes to vlan Y and then receives an ip address from vlan Y. When user logs off, machine reauths and goes back to vlan X.

However, when I use the dot1x auth-fail vlan on the port the switch will change to vlan Z, but the computer (XP) still has an ip address from vlan X. XP still shows as "trying to authenticate" which I'm guessing might be the problem with it not requesting DHCP (it normally doesn't do it till after auth).

Is there an authentication timeout setting somewhere in XP? Or is there another way around this issue? This is XP with SP3.

jafrazie · ‎03-19-2009

There's not another way around the issue. The "problem" here is that the machine already has an IP.

Fundamentally, the Auth-Fail-VLAN operates as if a network administrator logged into a switch, watched x-number of failures happen consecutively, and the admin enables the port anyway in force-authorized mode, and hard-sets it into a specific VLAN. At this point, it's up to the supplicant on how/if it needs to get on the network.

IOW, it's much like if you just changed the VLAN on a port on the fly for any other reason .. same issue.

Only workaround could be to of course make sure it fails at initial plugin time, when the machine requests an IP to begin with (assuming Windows platform anyway).

Hope this helps,

View solution in original post

jafrazie · ‎03-19-2009

There's not another way around the issue. The "problem" here is that the machine already has an IP.

Fundamentally, the Auth-Fail-VLAN operates as if a network administrator logged into a switch, watched x-number of failures happen consecutively, and the admin enables the port anyway in force-authorized mode, and hard-sets it into a specific VLAN. At this point, it's up to the supplicant on how/if it needs to get on the network.

IOW, it's much like if you just changed the VLAN on a port on the fly for any other reason .. same issue.

Only workaround could be to of course make sure it fails at initial plugin time, when the machine requests an IP to begin with (assuming Windows platform anyway).

Hope this helps,

jason.eberhard · ‎03-19-2009

Ahh, I gotcha.

So for a vendor coming in that might have 802.1x enabled it would fail right away, but for a domain machine that auths and then someone tries to log in locally it won't.

I can probably live with that. People aren't supposed to log in locally anyway. =]

And I can create a local account in ACS that matching the local admin on machines to authenticate and authorize the ports.

Thanks.