I recently read Low-cost RADIUS servers for Wi-Fi security, a review of four RADIUS servers with an emphasis on Wi-Fi network security use cases. The main complaint about FreeRADIUS, the only no-cost option mentioned, is the difficulty of configuration. To see this for myself, I decided to try setting up a Wi-Fi network secured with PEAP using FreeRADIUS on CentOS for authentication.
PEAP Requirements
To configure a Wi-Fi network to use PEAP, the main requirements are:
- A wireless AP that supports 802.1x. I’ll be using an old (circa 2005) Linksys WRT54GS running DD-WRT (v24-sp2 build 13064).
- A RADIUS server. I’ll use FreeRADIUS (version 2.1.12) running on CentOS 6.3.
- A certificate for the RADIUS server signed by a CA trusted by Wi-Fi clients.
Other requirements, such as client devices (laptop, phone, tablet), DHCP server, router, an Internet connection, and so on, already exist on the typical home or business network. So let’s get started!
FreeRADIUS Installation
Installing FreeRADIUS is simple on CentOS 6.x. It can be done with a single command.
yum install freeradius freeradius-utils
FreeRADIUS Configuration
I am new to FreeRADIUS, but I am familiar with CentOS. Many common services (e.g. Apache web server, MySQL database) are packaged with a minimal but functional configuration. After installation, I considered starting FreeRADIUS to see if it Just Works™, but I figured certificates and users wouldn’t be configured by default, so I opted to check the configuration first. I used the Setting up FreeRADIUS article on TLDP as a guide. In /etc/raddb/certs/ I found certificates that (based on the time stamp) apparently were generated automatically during installation. /etc/raddb/radiusd.conf didn’t seem to need any changes, in /etc/raddb/eap.conf I set “default_eap_type = peap” under the “eap” section, and in /etc/raddb/clients.conf I added an entry for my AP.
client 172.20.0.245 { secret = nomoresecrets shortname = dd-wrt }
In /etc/raddb/users I added a user:
kirk Cleartext-Password := "somepassword"
I updated the iptables rules to allow FreeRADIUS using system-config-firewall-tui and selecting the “RADIUS” option under “Trusted Services”. Lastly, I started FreeRADIUS:
service radiusd start
Access Point Configuration
Configuring an AP for PEAP is usually quite simple as long as it supports PEAP. You simply need to enable WPA2 security with EAP and input the RADIUS server, port, and secret. In DD-WRT the configuration is done in the “Wireless Security” section as shown in the following screenshot. No other configuration seems to be necessary (consider that before doing this, I had to reset the WRT54GS back to factory defaults since I had forgotten the password).
Even though the AP configuration is simple, the actual functionality varies in my experience. This may be due to WEP or WPA2 with a pre-shared key (WPA2-PSK) being more common and resulting in less QA testing being done for “advanced” security schemes. I am currently using Ubiquiti APs on my home network and they are rock solid when using PEAP. I’ve also used Symbol (now Motorola) APs with PEAP successfully, but I prefer Ubiquiti because (unlike Motorola) they don’t charge for something as basic as downloading software updates. Using “enterprise-grade” APs is by no means a guarantee that PEAP will work, though. Before implementing PEAP I had 3Com 7760 APs (now the HP A7760) which worked fine with WPA2-PSK but were unusable with PEAP due to bugs.
Client Configuration
Each type of client will have different configuration requirements to enable access to the PEAP-secured Wi-Fi network. The biggest downside of PEAP and 802.1X is that not all clients support it. PEAP or 802.1X might not even be listed in the specifications for some devices, such as “smart” TVs, printers, and game consoles, even if they do support it, so be careful about assuming a particular client will support PEAP. Devices I know to be supported include Linux, Windows, and OS X PCs, and Android and iOS phones and tablets. I’ve read that Google TV supports it, which would be useful for those in the market for a smart TV.
For the FreeRADIUS configuration I’m using, the main annoyance is importing the CA certificate to the client. This is not strictly required as you can configure the client to not verify the certificate used to secure the RADIUS connection, but it is highly recommended to get the strongest security out of PEAP (and why bother implementing PEAP, only to undermine the security?). The format the certificate must be in will vary by client. Android devices require DER or PKCS#12 (see Work with certificates), while Windows and Linux machines support a variety of formats.
On my laptop running Gentoo Linux, the process was simple. WPA and 802.1X are configured by wpa_supplicant, so I used wpa_gui to generate the configuration. There is no need to “install” the CA certificate since the certificate can simply be copied to the file system. Here is a screenshot of the configuration I used.
I have another laptop running Windows 7, and the process of setting up PEAP with the default Wi-Fi configuration utility is similar to doing so for other RADIUS servers such as IAS or NPS on Windows Server. That is to say, it is a hassle compared to Wi-Fi security schemes such as WPA2-PSK. The various required settings are split up into many dialogs and sub-dialogs. Some Wi-Fi adapters include their own configuration utility which may or may not improve upon the default option.
Anyway, before proceeding with configuring the network, the CA certificate must be imported to the Trusted Root Certification Authorities store for the user. This is done by copying ca.der to the machine, renaming it to ca.crt, and following the Adding certificates to the Trusted Root Certification Authorities store for a local computer section of the Manage Trusted Root Certificates TechNet article. Once that is done, the Wi-Fi network can be added manually with the configuration shown in the following screenshots.
At one point I was presented with the warning message in the following screenshot.
Besides this error, I didn’t notice any other problem and the connection works fine.
Troubleshooting FreeRADIUS
The /var/log/radius/radius.log log file can be viewed or monitored for errors.
tail -f /var/log/radius/radius.log
Besides that, I personally like using tcpdump to troubleshoot. The FreeRADIUS defaults will result in traffic being on 1812/udp, so monitor the traffic on this port. The following command will show basic traffic analysis, which is often enough to identify a problem.
tcpdump -ni eth0 udp port 1812
The following example tcpdump output shows a successful RADIUS authentication.
RADIUS, Access Challenge (11), id: 0x01 length: 101 RADIUS, Access Request (1), id: 0x01 length: 173 RADIUS, Access Accept (2), id: 0x01 length: 166
For deeper analysis, additional switches or filters can be used, such as the “-v” switch. Or, you can save a packet capture (.e.g add “-w capture.pkt”) and analyze it in Wireshark. If you’re not familiar with Wireshark I highly recommend learning to use it. I’ve been using it for over 10 years (back when it was known as Ethereal) and I think Wireshark 101 by Laura Chappell is a good book to read to learn it.
Next Steps
The CA certificate generated by default during installation has a validity of only 60 days, so it is only suitable for testing purposes. Once the FreeRADIUS and PEAP configuration is tested and confirmed as working, it is advisable to buy a certificate for FreeRADIUS to use instead of dealing with importing the CA certificate on clients, or to set up a proper PKI environment to issue certificates to FreeRADIUS and other internal services. Additionally, it may make sense to use a real user database such as LDAP instead of the default users file. Lastly, investigate and consider implementing some of the many features FreeRADIUS offers.
Conclusion
I found the process of setting up a basic FreeRADIUS installation for PEAP to be relatively simple. With no prior FreeRADIUS experience I had it up and running in an hour, including AP and client configuration. Obviously it requires Linux knowledge, and having prior PEAP experience with other RADIUS servers is helpful. If you try it, feel free to share your experience and results.
Note that you should NOT use a globally known CA here!
e.g. using a Verisign cert as a “known CA” means that ANYONE who has a certificate signed by them can authenticate via EAP-TLS! This is likely not what you want.
I guess they’d also need a username and password but it eliminates one factor of auth…
Nice article, easy to read and follow. Best quick one I found without ldap/sql.
Hi, Bob. Thanks for the comment. I don’t understand your point about the CA cert, though. For this configuration the cert on the server is meant to authenticate the RADIUS server with the client (similar to a SSL-secured web server), not the other way around. The username and password is what authenticates the client with the RADIUS server. AFAIK the configuration here doesn’t allow certificate-based authentication of clients.
Using a “global CA” will allow anyone with a certificate signed by the same CA to spoof your network. If you look in your “Protected EAP Properties” screenshot, you’ll notice that you select a trusted root CA for that profile, and this verification of the root CA is the ONLY VERIFICATION done. Note this is much different than using a cert for HTTPS authentication, where the web browser verifies the common name on the cert ITSELF matches the URL entered into the browser. Imagine this scenario – You have a wifi network setup with RADIUS. I see this network and try to connect. I enter the wrong credentials and the connection fails, but I’ll still get that “Windows Security Alert”, where I can click “details” and see your cert info (including the root CA that signed it). I now setup my own wifi using your SSID and buy a cert from the same root CA. Your clients will try connecting to my network (because you trust the root CA) and their credentials will be sent to MY RADIUS server. Hope that helps you understand the security concern.
Hi, Thomas. I believe this problem can be averted by including the RADIUS server hostname in the “Connect to these servers” field. While someone can buy a cert from the same public CA, presumably they can’t get one with the hostname of your particular RADIUS server.
hi
could u please mail me.how to configure the ca certificate. i had installed free radius in cent os
i want to configure peap .
Hi Kirk,
I’m implementing EAP-PEAP and EAP-TTLS for out college, using FreeRADIUS, and having problems understanding how to install the certificate from carver. I mean do the supplicants automatically download it from RADIUS server when they connect to the SSID or it it should be preinstalled on the client prior to connecting and authenticating on that SSID ?
Also, do I just copy the FreeRadius server CA certificate and upload it to the NAS/AP for so that TLS channel is established?
I would appreciate your help on installing certificates.
Ideally the CA cert should be installed on the clients. However, it is not strictly required since clients can be configured to not verify the certificate. This can be a hassle depending on the infrastructure and clients. The best case scenario would be an Active Directory environment and domain-joined Windows laptops since the CA cert can be automatically installed on clients. If clients include a mix of phones, tablets, and laptops with different OSs, it might be difficult or impossible.
The APs don’t do anything with the certs so don’t worry about them. They authenticate with the RADIUS server using only the secret. They then pass-through traffic between clients and RADIUS. Microsoft has an excellent guide, Securing Wireless LANs with PEAP and Passwords, that explains it thoroughly. Here’s a quote: