Using 802.1X authentication with WPA2-Enterprise offers the greatest Wi-Fi security possible today. However, some legacy and even newer Wi-Fi devices can lack 802.1X support. Thus, some computers or devices might not be able to connect to the Enterprise wireless network. Nevertheless, there are ways to still provide connectivity to non–802.1X devices.
In this article, you'll discover some techniques that can be used by both network administrators and end users.
If you're just a user of the Enterprise network, you should first check with the administrators before using the methods we'll discuss in the latter part of the article. This is because they can lessen the overall security of the network and potentially open access to unauthorized users.
This is also a good time to mention to administrators that they should do regular thorough network audits and Wi-Fi site surveys to catch users who are using these methods without permission. As an administrator, you should also look into implementing network intrusion solutions to help catch these types of vulnerabilities.
MAC Authentication Bypass
If you're the network administrator, you might consider implementing the MAC address authentication bypass feature of your RADIUS server, if supported by the server and switches. This method essentially lets non–802.1X devices bypass the traditional 802.1X process altogether, but still lets them connect.
A list of authorized MAC addresses of client NICs would be maintained on the RADIUS server. Then when a non–802.1X client tries to connect, the server would then check the MAC address of the client NIC against the list of authorized addresses.
The issue with this method is the lack of security. It's possible that if someone knows the list of authorized MAC addresses or sniffs the network and detects them, they could easily spoof the MAC address of their wireless NIC so they could connect.
Multiple SSIDs and VLANs
Another option for administrators is to configure multiple SSIDs and/or VLANs for non–802.1X clients if the access points and switches support these functionalities. The most basic approach would be to create a separate virtual SSID configured with the Personal (PSK) mode of WPA or WPA2 security. Then to segregate this less-secure wireless network, you could assign this SSID to another VLAN from the main network. Thus if the PSK passphrase is compromised and access is gained by unauthorized users, damage would be minimal.
You should check if your RADIUS server and switches support guest VLANs and/or failed authentication VLANs. These features could be used to automatically allow non–802.1X clients network access, but to a particular VLAN that could be segregated from the main one.
Add Additional APs
If you're an administrator or user, you could consider adding additional access points to the network configured with the Personal (PSK) mode of WPA or WPA2 security. Thus at least non–802.1X devices that support WPA/WPA2-Personal can connect.
Again, this lessens the overall security of the network. However, if the access point and your switches support VLANs, you may be able to assign users connecting through this less-secure access point to segregated VLAN.
Use a Wireless Ethernet Bridge
Whether you are an administrator or just plain user of the Enterprise network, you may be able to use a wireless bridge to connect your non–802.1X devices. The computer or device must have an Ethernet port, and the wireless bridge must support WPA/WPA2-Enterprise (not just WPA/WPA2-Personal or PSK). If this is the case, you could configure the bridge with the authentication and encryption settings so it connects to the Enterprise network and then plug it into the non–802.1X device to give it network access.
If you don't want to purchase a wireless bride, you may be able to turn a wireless router into a bridge by using the aftermarket DD-WRT firmware. But keep in mind, WPA/WPA2-Enterprise is supported only in the Client Mode of DD-WRT if the router is loaded with an Atheros Wi-Fi chipset. You can check the compatibility of routers with DD-WRT and the chipset used via DD-WRT's Router Database.
If the router is supported and is using an Atheros chipset, you could flash the router with the firmware using their instructions. Then you could configure the DD-WRT router in Client Mode to connect to the Enterprise network.
Finally, you could connect non–802.1X computers and devices to the Ethernet ports of the DD-WRT router. Since NAT is used, they would be on a separate subnet of the Enterprise network. Thus the Enterprise network only thinks the DD-WRT router is connected as a client and doesn't know there are multiple clients connected through it.
Use a Computer with ICS as a Bridge
This would be a similar approach to the wireless bridge method and could be used by administrators or users. You'd use a computer that's connected to the Enterprise network as a wireless or wired bridge by using the built-in Internet connection sharing (ICS) feature of Windows, included since back with Windows 98 Second Edition. Keep in mind that the computer that's connected to the Enterprise network and the non–802.1X device must both have an Ethernet port, so you can connect the two together.
After the host computer has successfully connected to the Enterprise network, you'd enable ICS on that network connection/adapter. To do this you'd bring up the Network Connections window via the Control Panel or Network and Sharing Center. Then you'd right-click the connection/adapter that's connected to the Enterprise network and select Properties.
On the Connection Properties dialog, you'd select the Sharing tab and check the Allow other network users to connect through this computer's Internet connection option. If you have more than one Ethernet adapter on the computer, you'd have to choose which one you want to share the connection with.
Once ICS is set up, any computers or devices you plug into the computer hosting ICS will receive an IP address that's on a different subnet from the Enterprise network. Like the wireless bridge method using DD-WRT, NAT would be used. Thus the Enterprise network is not aware of these non–802.1X devices, and the traffic appears to be only from the host computer.