How To: Setting up FreeRADIUS for WPA & WPA2

Enterprise - Part 2
Equipment and Software Setup
Before we get into the nitty gritty of getting your own CA, public and private keys set up, here's the run down on the
equipment and software I'll be using and the typeface conventions I'll be following for the code listings.
When we're talking about setting up an industrial strength security implememtation, Linux is the natural choice. I've tried to
make this How To as general as I can, but you'll have to be aware of the little distro-to-distro differences. So I've included
my setup in Table 1.
My Setup

Distribution
Kernel
OpenSSL Version
FreeRADIUS Version
Wireless Router/AP

Slackware 10.2
2.6.21 Series (Custom Compiled)
0.9.8g
1.1.7
D-Link DGL-4300

I'm going to compile everything from source which will work on every distro. But I recommend you use your distro's
package management software such as APT, or portage, if you are familiar with using it (it will make the installation that
much easier).
It is very important that you use at least version 0.9.8g of OpenSSL, which was released just a few weeks before this
How To was published. You'll need this version or higher because some of the options we need to use didn't appear until
the 0.9.8g release.

Typeface Conventions
To make it easier to follow and copy/paste, I am going to provide copies of the actual shell commands that I used and their
output. They'll appear in blocks like this:
Code Goes in Here...
Everything you enter will appear in boldface. The output from the command will be in normal formatting.
~ $ openssl version
OpenSSL 0.9.8e 23 Feb 2007
Any parameters (such as filenames, passwords, etc.) that you'll need to adjust for your setup will be in bold-italic.
~ $ openssl sha1 myfile.txt
SHA1(myfile.txt)= da39a3ee5e6b4b0d3255bfef95601890afd80709
Ocassionally, I'll break up long commands onto multiple lines by "escaping" the newline at the end of the command. This
is done by typing a backslash (\), hitting return and continuing the command.
~ $ somecommand -that -has -a -million \
-options -and -you -have -to \
-use -them -all -on myfile.txt
For my bash shell I've set PS1 like this:
bash-3.1$ export PS1="\w \$ "
~ $
Some commands will require super-user privileges, so elevate yourself to super-users status by using:
~ $ su

Note: Ubuntu is slightly different here, you'll need to enter "sudo su", then, when prompted, enter your user
password and you'll have a root shell.
We're going to be digging into some pretty monstrous config files in a moment, so I'll print line numbers at the beginning of
the line and highlight what I've changed/added in bold-italic.
2123

post-proxy {

2124
2125

If you want to have a log of replies from a home server,

2126

un-comment the following line, and the 'detail post_proxy_log'

2127

section, above.

2128

post_proxy_log

attr_rewrite

2129
2130
2131
2132

Uncomment the following line if you want to filter replies from

2133

remote proxies based on the rules defined in the 'attrs' file.

2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149

attr_filter
#
#
#
#
#
#
#
#
#
#
#

If you are proxying LEAP, you MUST configure the EAP

module, and you MUST list it here, in the post-proxy
stage.
You MUST also use the 'nostrip' option in the 'realm'
configuration. Otherwise, the User-Name attribute
in the proxied request will not match the user name
hidden inside of the EAP packet, and the end server will
reject the EAP request.
eap

And I'll occasionally abbreviate long uninteresting output with an ellipsis.

~ $ command
Uninteresting output that keeps going.
...
So, without further ado, let's lock down our wireless network.

Setting up OpenSSL
The first step in getting the razor-wire set up around your wireless AP is to generate your very own CA (Certificate
Authority).
First, download the latest version of OpenSSL. As noted earlier, this is 0.9.8g as I write this.
~ $ wget http://www.openssl.org/source/openssl-0.9.8g.tar.gz
It's always good practice to verify the checksum of any source download (especially with security related software). For
some odd reason OpenSSL doesn't list a properly formatted md5 checksum file, so you'll have to eye-ball it.
~ $ cat openssl-0.9.8g.tar.gz.md5
acf70a16359bf3658bdfb74bda1c4419
~ $ md5sum openssl-0.9.8g.tar.gz
acf70a16359bf3658bdfb74bda1c4419 openssl-0.9.8g.tar.gz
Next, extract OpenSSL from the tarball.
~ $ tar xvzf openssl-0.9.8g.tar.gz
Move into the newly extracted OpenSSL directory and run the config script.
~ $ cd openssl-0.9.8g
~/openssl-0.9.8g $ ./config
Finally, compile and install OpenSSL.
~/openssl-0.9.8g $ make
...
~/openssl-0.9.8g $ su -c "make install"
Password: pA55w0Rd
...
Ok, now that we've got OpenSSL installed, we need to set up a few directories to organize the keys we're about to create.
Depending on where you look and who you ask, there are numerous ways to do this. I'm a fan of the KISS approach, so
here is how I set it up.
Change back into your home directory and create a "CA" directory with a "signed_certs" sub directory and a "private" sub
directory.
~/openssl-0.9.8g $ cd
~ $ mkdir CA
~ $ mkdir CA/signed_certs
~ $ mkdir CA/private
~ $ chmod 700 CA/private
"signed_certs" will hold copies of all the certificates that we sign with our CA. That way, if we need to revoke a certificate,
we'll have a copy locally. "private" will hold the CA's private key. It's very important to keep the CA key secret. Because if it
gets compromised, it could be used to sign untrusted certificates that might be used to trick clients into unknowingly
sharing sensitive information with a untrusted machine. I've locked it down above, by changing the permissions so that
only I can read, write and execute it.
There are quite a few command line options and even more infomation required in prompts that are pretty redundant. So
it's easiest to create a local copy of the OpenSSL config, modify it and force OpenSSL to use it with the "-config" option.
(Note: the location of the original openssl.cnf file may be different if you didn't build from source.)
~ $ cp /etc/ssl/openssl.cnf /home/brandon/CA/

Open up openssl.cnf with your favorite text editor and change the following in the "CA_default" section: (Remember that
the numbers that appear first on each line are line numbers, don't enter them into the config file.)
35
36
37

[ CA_default ]
dir

= /home/brandon/CA

38

certs

= $dir/

# Where the issued certs are kept

39

crl_dir

= $dir/crl

# Where the issued crl are kept

40

database

= $dir/index.txt

# database index file.

41

#unique_subject = no

42
43

# Where everything is kept

# Set to 'no' to allow creation of

# several ctificates with same subject.

new_certs_dir

= $dir/signed_certs

# default place for new certs.

45

certificate

= $dir/cacert.pem

# The CA certificate

46

serial

= $dir/serial

# The current serial number

47

crlnumber

= $dir/crlnumber

# the current crl number

44

48

# must be commented out to leave a V1 CRL

49

crl

= $dir/crl.pem

50

private_key

= $dir/private/cakey.pem# The private key

# The current CRL

51

RANDFILE

= $dir/private/.rand

# private random number file

52
53

x509_extensions = usr_cert

# The extentions to add to the cert

If you're planning on using Windows to manage the wireless network on the clients, we need to add some additional
extensions to the end of the config file. Add the following sections to the end of "openssl.cnf" (this happens to be line 316
for me):
316

# Windows XP TLS Extenstions

317

[ xpclient_ext ]

318

extendedKeyUsage=1.3.6.1.5.5.7.3.2

319

[ xpserver_ext ]

320

extendedKeyUsage=1.3.6.1.5.5.7.3.1

Next, head on down to line 123 and change the defaults for the "distinguished name" to suit your application. The
"distinguished name" section contains little bits of useful information for labeling public keys. As we'll see in a moment, the
keys themselves are pretty ugly (even when encoded in ASCII). To help keep track of them, they're labeled with some
information, and at this point the public key is referred to as a certificate. I'll use certificate to stay consistent with how
OpenSSL refers to them, but functionally they're equivalent.
123

[ req_distinguished_name ]

124

countryName

= Country Name (2 letter code)

125
126
127
...

countryName_default
countryName_min
countryName_max

= US
= 2
= 2

You can set a default value for any of the parameters listed here by adding "_default" to the end of the variable name. In
the example above, "countryName_default" is the default value for "countryName".Finally, touch "index.txt", a simple textbased database used to track signed certificates.
~/CA $ touch index.txt

Respect My (Certificate) Authority!

Now that we've got our environment set up, it's time to create the CA and issue some keys. Since OpenSSL is so
complex, it works a little bit differently than the usual *NIX commands. Most notably, it has a handful of sub-commands
(the first argument) that handle the details. \
To create a new key pair, first we create a "certificate request" (sub-command "req"). The certificate request is then sent
off to be signed by the CA and becomes a bonafide public key. Creating the CA key pair starts off the same way we'd
create a regular key pair, using the command below.
For most of the responses, you just hit the Enter key to accept the defaults we set up in the config file. Make sure to use
a strong password for the CA key; it's the only thing standing between the hacker and your CA key if it's ever
compromised.
~/CA $ openssl req -new -keyout private/cakey.pem -out careq.pem \
-config ./openssl.cnf
Generating a 2048 bit RSA private key
..........................................+++
...+++
writing new private key to 'private/cakey.pem'
Enter PEM pass phrase: pA55w0rD
Verifying - Enter PEM pass phrase: pA55w0rD
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
----Country Name (2 letter code) [US]:
State or Province Name (full name) [The Great State You Live In]:
Locality Name (eg, city) [My Town USA]:
Organization Name (eg, company) [SmallNetBuilder]:
Organizational Unit Name (eg, section) [Security Division]:
Common Name (eg, YOUR name) []:CA
Email Address []:you@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Next, we need to "self-sign" the certificate to turn it into a CA.

~/CA $ openssl ca -create_serial -out cacert.pem -keyfile private/cakey.pem \
-selfsign -extensions v3_ca -config ./openssl.cnf -in careq.pem
Using configuration from ./openssl.cnf
Enter pass phrase for private/cakey.pem: pA55w0rD
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:

f2:c8:4a:d0:f5:09:28:b7
Validity
Not Before: Oct 24 03:17:49 2007 GMT
Not After : Oct 23 03:17:49 2008 GMT
Subject:
countryName

= US

stateOrProvinceName

= The Great State You Live In

organizationName

= SmallNetBuilder

organizationalUnitName

= Security Division

commonName

= CA

emailAddress

= you@example.com

X509v3 extensions:
X509v3 Subject Key Identifier:
D0:1E:BF:7B:A8:26:B9:98:B0:81:98:2E:E7:96:CA:57:3D:76:F3:02
X509v3 Authority Key Identifier:
keyid:D0:1E:BF:7B:A8:26:B9:98:B0:81:98:2E:E7:96:CA:57:3D:76:F3:02
DirName:/C=US/ST=The Great State You Live In/O ...
serial:F2:C8:4A:D0:F5:09:28:B7
X509v3 Basic Constraints:
CA:TRUE
Certificate is to be certified until Oct 23 03:17:49 2008 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

(Note that the DirName: line above was truncated [...] because it was too wide for most browser screens!)
In the command above, "-create_serial" (new in recent versions of OpenSSL) creates a hex serial number for this key. "extensions" specifies the section of the openssl.cnf config file to look in for specific extensions to append to the newly
created certificate (public key). In this case, we're using the v3_ca section which, among other things, contains this setting
on line 234:
basicConstraints = CA:true
This allows the key to be used to sign other keys, acting as the CA.
The last step is to create a copy of the CA certificate encoded in the DER format, because Windows likes only binary
encoded certificates.
~/CA $ openssl x509 -inform PEM -outform DER -in cacert.pem -out cacert.der

Creating the Client and Server Keys

Now that we've got our CA all set up, we need to issue key pairs for the server and all of our clients. Start by creating a
new key pair:
~/CA $ openssl req -new -config ./openssl.cnf -keyout server_key.pem \
-out server_req.pem
Generating a 2048 bit RSA private key
.......+++
.................................+++
writing new private key to 'server_key.pem'

Enter PEM pass phrase: pA55w0rD

Verifying - Enter PEM pass phrase: pA55w0rD
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
----Country Name (2 letter code) [US]:
State or Province Name (full name) [The Great State You Live In]:
Locality Name (eg, city) [My Town USA]:
Organization Name (eg, company) [SmallNetBuilder]:
Organizational Unit Name (eg, section) [Security Division]:
Common Name (eg, YOUR name) []: server
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Now sign the key with our newly created CA:

~/CA $ openssl ca -config ./openssl.cnf -in server_req.pem -out server_cert.pem
Using configuration from ./openssl.cnf
Enter pass phrase for /home/brandon/CA/private/cakey.pem: pA55w0rD
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:
f2:c8:4a:d0:f5:09:28:b8
Validity
Not Before: Nov

1 02:32:07 2007 GMT

Not After : Oct 31 02:32:07 2008 GMT

Subject:
countryName

= US

stateOrProvinceName

= The Great State You Live In

organizationName

= SmallNetBuilder

organizationalUnitName

= Security Division

commonName

= server

X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
71:A0:FB:1C:35:B7:B8:1D:1C:A4:C6:DF:A5:BA:80:6E:89:09:B7:CE
X509v3 Authority Key Identifier:
keyid:D0:1E:BF:7B:A8:26:B9:98:B0:81:98:2E:E7:96:CA:57:3D:76:F3:02

Certificate is to be certified until Oct 31 02:32:07 2008 GMT (365 days)

Sign the certificate? [y/n]: y
1 out of 1 certificate requests certified, commit? [y/n] y
Write out database with 1 new entries
Data Base Updated

Note: If you're planning on using Windows to manage the wireless connection on the clients use the X509v3 extensions
we added earlier instead:
~/CA $ openssl ca -config ./openssl.cnf -extensions xpserver_ext \
-in server_req.pem -out server_cert.pem

Create key pairs for your clients using the exact same command. Just change the key filenames and the "Common
Name" to something meaningful for your application. Here's what I used for this set up:
~/CA $ openssl req -new -config ./openssl.cnf -keyout linux_laptop_key.pem \
-out linux_laptop_req.pem
...
Common Name (eg, YOUR name) []: linux_laptop

And:
~/CA $ openssl req -new -config ./openssl.cnf -keyout winxp_laptop_key.pem \
-out winxp_laptop_req.pem
...
Common Name (eg, YOUR name) []: winxp_laptop

Sign both certificate requests the same way we signed the server's certificate. Here's the command for my Linux laptop
key:
~/CA $ openssl ca -config ./openssl.cnf -in linux_laptop_req.pem \
-out linux_laptop_cert.pem

Again, use the X509v3 extensions if Windows is managing wireless on the clients:
~/CA $ openssl ca -config ./openssl.cnf -extensions xpclient_ext \
-in winxp_laptop_req.pem -out winxp_laptop_cert.pem

Now we've got both pairs of keys created and signed. Windows needs a little help to understand all this security, so we
have to package the client certificate coresponding private key into a PKCS#12 file. Linux is happy working with them
either way, so we'll package them both for consistency.
~/CA $ openssl pkcs12 -export -clcerts -in winxp_laptop_cert.pem \
-inkey winxp_laptop_key.pem -out winxp_laptop.p12
Enter pass phrase for winxp_laptop_key.pem: pA55w0rD
Enter Export Password: pA55w0rD
Verifying - Enter Export Password: pA55w0rD

The command above uses OpenSSL's pkcs12 utility to "-export" a new PKCS#12 file. "-clcerts" tells OpenSSL to only
export the client certificate and private key (in other configurations, multiple certificates and keys can be packaged into a
single PKCS#12 file). Package the Linux certificate and private key using the same command. Generating good keys
relies on having a good set of "random" data to seed the key generation. While not strictly related to generating PKI keys,
we'll need this data later on for FreeRAIDUS. We'll use OpenSSL to generate Diffie-Hellman parameters for symmetric
key generation.

First, elevate yourself to superuser and create a directory that will house the CA certificate, server public and private keys,
a dh file for Diffie-Hellman parameters and a random date file. I chose to put these in /etc/wireless; anywhere readable to
FreeRADIUS is fine.
~/CA $ su
Password: pA55w0rD
/home/brandon/CA # mkdir /etc/wireless
Now, copy the server's public and private key and the CA's certificate to /etc/wireless:
/home/brandon/CA # cp cacert.pem server_cert.pem server_key.pem /etc/wireless/

Create 1024-bit Diffie-Hellman parameters with the following:

/etc/wireless # openssl dhparam -out dh 1024
Next create a random file to seed key generation:
/etc/wireless # dd if=/dev/urandom of=random count=2

Installing and Configuring FreeRADIUS

Now it's time to install FreeRADIUS. Download FreeRADIUS and unpack.
~ $ tar xvzf freeradius-1.1.7.tar.gz
Configure, install and update your dynamic linked libraries after the install. By default, FreeRADIUS installs in /usr/local
and reads its configuration files from /usr/local/etc/raddb.
~ $ cd freeradius-1.1.7
~/freeradius-1.1.7 $ ./configure
~/freeradius-1.1.7 $ make
~/freeradius-1.1.7 $ su -c "make install"
Password: pA55w0rD
...
~/freeradius-1.1.7 $ su -c ldconfig
Password: pA55w0rD
...
FreeRADIUS comes packaged with a pretty monstrous, but well documented set of config files. Setting up WPA2
authentication really only scratches the surface of what FreeRADIUS is capable of. Since the default settings get us pretty
close, we just need to make a few minor changes to some config files to get RADIUS authentication up and running.Open
up radiusd.conf with your favorite text editor and adjust the directory pointers (lines 23 through 40) to suit your system.
23

prefix = /usr/local

24
25
26
27
28
29
30
31
32
33

exec_prefix = ${prefix}
sysconfdir = ${prefix}/etc
localstatedir = ${prefix}/var
sbindir = ${exec_prefix}/sbin
logdir = ${localstatedir}/log/radius
raddbdir = ${sysconfdir}/raddb
radacctdir = ${logdir}/radacct
# Location of config and logfiles.
confdir = ${raddbdir}

34
35
36
37
38
39
40

run_dir = ${localstatedir}/run/radiusd
#
# The logging messages for the server are appended to the
# tail of this file.
#
log_file = ${logdir}/radius.log

The location of the log file on line 40 is especially important. FreeRADIUS usually isn't very informative about runtime
errors, instead writing everything the log. So if you have any problems with FreeRADIUS, take a look at the log.The rest of
this config file is huge2149 lines huge. The good news is we don't need 90% of the options FreeRADIUS has for WPA2.
So we can distill the whole config file down to around 200 lines.
You can safely comment out (or delete) just about anything that doesn't have to do with TLS or EAP (such as the module
sections dealing with PEAP, CHAP, MSCHAP, etc.). Instead of walking you through every change, here is a copy of what I
use (this is likely more than the absolute minimum even with all the comments removed).
One big change that needs to be made is changing to an unprivileged user and group on lines 109 and 110:
109
110

user = nobody
group = nobody

Next, open up clients.conf and add a section for your router. The router is the only true "client" to the RADIUS server; the
computers that connect are called users. Use the IP address of your router and a strong secret (this is the "password" that
the router will use to talk to the RADIUS server).The "shortname" variable is used only for logging, so it can be whatever
makes the most sense for you. Unless your NAS (Network Access Server) type is explicitly listed above in the clients.conf
file, use "other" for the NAS type.
client 10.20.7.1 {
secret
shortname
nastype
}

=
=
=

smallnetbuilder
wireless_ap
other

Next, edit the users file. Add the default line and lines for each of the client keys we created using the common name
supplied for the key as the user name. Have some fun with the default rejection message.
# users file for FreeRADIUS
winxp_laptop
linux_laptop
DEFAULT

Auth-type := EAP
Auth-type := EAP
Auth-type := Reject
Reply-Message := "Your Computer Ain't Welcome Here!"

Now we'll need to edit eap.conf. Change default_eap_type to TLS on line 23: default_eap_type = tls
Adjust the TLS configuration to suit your set up:
123

tls {

124

private_key_password = pA55w0rD

125

private_key_file = /etc/wireless/server_key.pem

126
127

If Private key & Certificate are located in

128

the same file, then private_key_file &

129

certificate_file must contain the same file

130

name.

131

certificate_file = /etc/wireless/server_cert.pem

132
133

Trusted Root CA list

134

CA_file = /etc/wireless/cacert.pem

135
136
137

138

For DH cipher suites to work, you have to

139

run OpenSSL to create the DH file first:

140

141

142

143

dh_file = /etc/wireless/dh

144

random_file = /etc/wireless/random

openssl dhparam -out certs/dh 1024

Configuring the Router

I used a D-Link DGL-4300 [reviewed], so your setup pages may differ. Open up your wireless router or AP's wireless
configuration section and find the Wireless Security settings. Change the security mode to WPA-Enterprise or WPA2Enterprise mode, add the RADIUS server's IP address and the shared secret (Figures 1 and 2).

Configuring a Linux Client

Connecting a Linux client using WPA or WPA2 security requires wpa_supplicant. Configure wpa_supplicant with the
following options set in ".config" file in addition to the drivers and interfaces you need for your setup:
CONFIG_IEEE8021X_EAPOL=y
CONFIG_EAP_TLS=y
CONFIG_PKCS12=y
#Make sure to include any other options you need as well
Re-compile and re-install wpa_supplicant. Now create a folder on the Linux client to house the client public and private
keys (PKCS#12 file) and the CA certificate. In my case, I set it up in /etc/wireless.
Next edit "wpa_supplicant.conf" and add a section similar to the following, to point to your new WPA2-Enterprise setup.
# WPA2-EAP/AES using EAP-TLS
network={
ssid="smallnetbuilder"
key_mgmt=WPA-EAP
eap=TLS
identity="linux_laptop"
ca_cert="/etc/wireless/cacert.pem"
private_key="/etc/wireless/linux_laptop.p12"
private_key_passwd="pA55w0rD"
}

The "identity" field should match the common name on the client certificate and the user we set up in FreeRADIUS' users
file. Restart wpa_supplicant and connect to the network.

Configuring a Windows XP Client

Windows users will require the WPA2 patch, if it's not already installed. A quick way to check for this is to open up the
advanced properties on any wireless network. If WPA2 is not an option available from the Network Authentication
dropdown, you need the patch.
After installing the patch, transfer the CA certificate and the p12 file containing the client certificate and key securely from
the server (via a USB flash drive is the easiest).
First, install the CA certificate as a trusted authority by double-clicking on it.

Figure 3: Installing the CA

Click "Install Certificate" and complete the wizard. Next, double-click on the p12 file that contains the client certificate and
key to install it.

Figure 4: Installing the Client Keys

Enter the password for the client's private key. (You can optionally require that the password is entered everytime the key
is used, this gets annoying real quick, so I usually leave that unchecked.)

Figure 5: Client Password

Let Windows automatically store the certificate where it thinks it should go.

Figure 6: Storing the Client Keys

Configuring a Windows XP Client - more

Finish the wizard, and view the wireless networks by double-clicking on the wireless network icon in the taskbar. Select
the your network and click on "Change Advanced Settings".

Figure 7: Wireless Networks

On the "Wireless Networks" tab, click "Add" under Preferred Networks.

Figure 7: Advanced Configuration

Enter the SSID of your router and change the Network Authentication to WPA2.

Figure 8: WPA2 Configuration

On the "Authentication" tab, click Properties under EAP Type.

Figure 9: EAP Configuration

Select your CA from the list, and check "Use a different username for this connection".

Figure 10: Certificate Selection

Hit OK to finish. Open up the wireless networks again and connect to your newly secured network.

Troubleshooting
There are quite a few pieces that have to play nicely together to get WPA2-Enterprise working. Here are a few tools that
come in handy if things don't work smoothly on the first try:

Check the FreeRADIUS log.

There is a lot of good information in the log that can point you right to the problem. This is especially handy when tweaking
the config files, as anything that doesn't parse correctly will log an error.

Run FreeRADIUS in debug mode in the foreground with "radiusd -X".

This will show you just what FreeRADIUS is thinking. Not all the errors show up here, but the major ones that cause
FreeRADIUS to quit do.

Test local connectivity with "radtest test test localhost 0 testing123".

This one comes straight out of the INSTALL file. If you runFreeRADIUS in the foreground with "radiusd -X" in another
terminal you should be able to see the FreeRAIDUS dump all kinds of messages when "radtest" runs.

Conclusion
With a little extra hardware, you can add the extra level of security that authentication provides to your wireless network.
This gives you better control over the clients that can connect to your network and also helps to keep clients from
connecting to untrusted networks. The combination of AES Encryption in WPA2 and secure authentication of clients will
help protect your network and keep your data secured from prying eyes.