Sean Convery

Earlier this year I wrote about the basics of 802.1X with the default VLAN. I still believe it provides a great way to slowly coax users to 802.1X without forcing an instant migration as well as a nice way to integrate guests onto your network. Here’s an additional tip for how to work with the default VLAN when using a captive portal, I recommend reading my earlier post first if you haven’t already.

One wrinkle with the default VLAN has to do with DHCP and how tightly coupled it is with the 802.1X process. Ideally the 802.1X supplicant you use would automatically do a DHCP release / renew each time the 802.1X status changes on a port. This isn’t always the case though. I haven’t tested all supplicants yet but certainly some of them (Mac’s built-in supplicant for example) don’t do this. This leaves you with a sequence like this:

1. Host connects to the network and is challenged with an EAPoL-Start message
2. Host does not respond or user does not respond to the authentication request dialogue
3. Authenticator places the host on the default VLAN at which point the host requests a DHCP address
4. The user initiates the 802.1X authentication manually (after getting his morning coffee, etc.) and succeeds in authenticating
5. The authenticator puts the host on a different VLAN since now a trusted user has authenticated
6. The host now has no network connectivity because it still has the old DHCP address for the other VLAN

This is an example of the nascent nature of 802.1X supplicants in general. I can’t think of a valid reason why you wouldn’t do a release renew yet some still don’t. This has been a known issue for quite some time now. In fact I describe a more pernicious variation of this issue in my book:

During my testing, I found a lack of integration between the 802.1x client and the DHCP client in Microsoft Windows 2000 … By the time authentication by 802.1x occurred, the PC had already timed out its DHCP request and opted instead for a link local address (169.254.0.0/16). Though the user could manually go in and restart the DHCP process, for most users this will be infuriating. (343)

There is a reasonable workaround here though it isn’t quite ideal. When the user is placed on a default VLAN–as described in my earlier post–they can be sent through a captive portal device. This captive portal generally provides local DHCP services for the default VLAN as well. So one approach is to simply set the DHCP lease time quite short for these guest systems. Something between one and two minutes is probably appropriate. So now if you start up your 802.1X supplicant after being temporarily placed on the default VLAN, you will only have a short time to wait before the DHCP client gets the proper address.

If you wanted to get really slick you might increase the time of the lease based on the number of times it has been renewed–each renew increases your confidence that the host is actually a guest user. That may add more complexity than it is worth plus it isn’t like the DHCP process is particularly compute intensive, especially if the short lease only applies to guest users. (As an aside, I’m no DHCP expert so I’m not certain if this lease scaling can even be done.)

Regardless of the DHCP particulars this approach will provide a safety net for less than optimal supplicants when working in a network that implements the default VLAN. If you’ve had experience working with this in the field, I’d love to hear about how it went. We’re using this technique in the office here for guest users and according to IT and the guests I’ve talked with it works fairly well.

Technorati Tags: 802.1X, Supplicant, DHCP, VLAN

This entry was posted on Wednesday, August 2nd, 2006 at 1:45 pm and is filed under 802.1X, Network Authentication. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.