802.1X and the Default VLAN
When discussing 802.1X, authenticated networks, and RADIUS with customers I’m often confronted with a small bit on confusion with regard to the deployment options. The standard way of thinking about 802.1X is that it represents an all or nothing proposition. You either configure and install supplicants on all endpoints (with standard exceptions for printers and the like) or you use an overlay (non-802.1X) authentication technology which typically employs some variation of a captive portal. The captive portal is a device that forces traffic through itself and can force authentication at that step (just like hotel broadband). However, a nice feature on most switches enables smoother 802.1X migration as well as long term interoperability with non-802.1X systems (like guest or contractor machines). This feature is the default VLAN and what it basically says is if the client does not respond to the EAPoL challenge it is placed on a default VLAN. One viable deployment choice has this default VLAN routing traffic through a captive portal where web-based authentication can take the place of the 802.1X authentication step. Some network devices support this web authentication on their hardware directly which represents yet another choice.
Regardless of which technique you choose this gives IT departments the ability to roll-out authenticated networks without managing massive exception lists or maintaining support for 802.1X supplicants on outdated client OSs. It also gives a natural incentive in places like universities to encourage migration. Because the 802.1X route can be considered “fast-path” as it doesn’t involve sending traffic through an unnecessary intermediary device, students can be encouraged to deploy a supplicant to get faster network access.
June 22nd, 2006 at 7:42 am
“One viable deployment choice has this default VLAN routing traffic through a captive portal where web-based authentication can take the place of the 802.1X authentication step. Some network devices support this web authentication on their hardware directly which represents yet another choice.”
Do you have any suggestions for devices that provide that functionality?
June 22nd, 2006 at 9:42 am
Quite a wide variety of devices support captive portal authentication. Many commercial firewalls such as Netscreen and Sonicwall support captive portal as well as newer inline security gateways from companies like Caymas. On the network infrastructure side some Cisco switches support web authentication directly instead of deploying a separate captive portal device. Additionally Airespace (now part of Cisco) has web authentication on their WLAN APs as well. There are other infrastructure players with this capability too. Lastly I’ll gratuitously plug my company (Identity Engines) which has some captive portal technology for when an organization doesn’t have an existing vendor of choice.
July 3rd, 2006 at 10:38 am
We are interested in implementing this dual-layer functionality on a community wireless network using OpenSource solutions. Is it possible to implement this by running HostAPd 802.1x and NoCat (examples) on Linux APs? Any hardware could be considered, ie. WRAP boards with miniPCI radios, or all-in-one solutions like Linksys WRT54G with OpenWRT linux.
July 7th, 2006 at 4:48 pm
I’m not sure specifically about HostAPd but there are a few different ways folks approach this with wireless. Most of my post had to do with wired 802.1X. For wireless many just choose to implement multiple SSIDs with one SSID for the 802.1X folks and another for the non-EAP capable clients. Some wireless vendors can automate this a bit more though their specific approaches are not completely consistent. Last I checked Cisco needed the multiple SSIDs but Trapeze could do the mapping in a more automated form. I haven’t looked into HostAPd yet.
November 22nd, 2007 at 2:52 am
I want to implement some captive portal-based solution but with the use of 802.1x, in order to assign different VLAN-IDs according to the user credentials.
Do you know about some captive portal that works with 802.1x?
November 26th, 2007 at 9:26 am
A number of companies make captive portal solutions that work with 802.1X including Identity Engines. The basic idea is if you don’t respond to the 802.1X query the endpoint is placed on a default VLAN that forces all traffic through the portal.