This guide has been based in some part on https://eko.one.pl/?p=openwrt-freeradius2. I was able to understand it through Google Translate even though Polish isn't my native language.
Using luci-app-radius to manage freeradius based enterprise WPA consists of a two parts. 1) The Radius server and user management. This is luci-app-radius and freeradius2. 2) Setting the router to use enterprise WPA for authentication.
There are many documents out there on how to set up freeradius so it can be used as a AAA (authentication, authorization, and accounting) server. If the intention is to set up a router as a public portal for, say, a coffee shop or pub, luci-app-radius is the wrong software. CoovaChili or daloRadius are better packages for setting up public portals. Luci-app-radius is really just for trusted local users.
There are two tabs on the Radius page, one for "Users" and one for "Clients". Clients are just hosts that will use the authentication provided by the radius server. The router should be in this list at a minimum. Users are just the users that need to authenticate to wi-fi.
luci-app-radius uses plain text to store the paswords, so make sure your router is well secured as it should be anyway.
Installation.
It is possible to install all the packages that luci-app-radius depends on by just installing luci-app-radius, but when luci-app-radius is installed, some files from the freeradius* packages should be backed up that will otherwise be overwritten by luci-app-radius.
Install freeradius2 and freeradius2-mod-files packages first, then copy the next three files out of the way so you have the originals when luci-app-radius overwrites them.
/etc/freeradius2/sites/default: This file gets overwritten by the installation. The version from luci-app-radius has a basic site config that specifies the authorization to EAP, authentication to use MS-CHAP, does not have any accounting or session settings.
/etc/freeradius2/users: This file gets overwritten by the installation. This file holds all the usernames and passwords for your user logins. It is generated by LuCI whenever there is an update from /etc/config/radius.
/etc/freeradius2/clients.conf: This file gets overwritten by the installation. This file holds all the client machine information. It is also included into /etc/freeradius2/radiusd.conf. It is generated by LuCI whenever there is an update from /etc/config/radius.
The installation scripts for luci-app-radius should probably move them out of the way to <filename>-opkg.
The main configuration file is /etc/freeradius2/radiusd.conf: By default freeradius will respond on br-lan, the bridged LAN interface. This interface is the wired interfaces, and often the wlan interfaces but not the loopback (localhost/127.0.0.1). To deal with this and still keep the radius server from answering questions from the general internet, there are two lines to edit, both can be found in the "listen" section.
First, comment out the interface line:
# interface = br-lan
This allows the radius server to answer on from any interface of the router.
Second, edit the address line to be the LAN IP of the router:
ipaddr = 192.168.4.1
The LuCI Radius page has two tabs, Users and Clients.
The Clients tab edits /etc/config/radius that is used to create /etc/freeradius2/clients.conf which is included in radiusd.conf. At a minimum, this will need to include your router's LAN IP.
The Users tab edits /etc/config/radius that is used to create /etc/freeradius2/users.
Testing.
To properly test the radius config, a client will need to be installed. That means installing freeradius2-utils which includes radclient.
Two ssh sessions are needed to test the configuration.
One session is used to start and monitor the server. First, make sure radiusd is not currently running.
root@omnia:~# ps | grep radiusd
If it is, then it can be stopped using /etc/init.d/radiusd stop or just kill the process.
Next, start freeeradius in diagnostic mode:
root@omnia:~# radiusd -XXX
There should be large number of messages showing and eventually it should read:
Info: Ready to process requests.
If any errors show up, re-check the configuration files.
Since the daemon is running in the foreground, a the second ssh session is used to use the client.
User-Name is an entry in the Users tab. User-Password is the associated Password for that user. 192.168.1.1 is the router's IP address (should be set in the Clients tab) testing345 is the Secret for that IP address.
root@omnia:~# echo "User-Name = testuser, User-Password = testing123" | radclient -x 192.168.1.1 auth testing345
This should result in something like this:
Sending Access-Request of id 163 to 192.168.1.1 port 1812 User-Name = "testuser" User-Password = "testing123" rad_recv: Access-Accept packet from host 192.168.1.1 port 1812, id=163, length=20
The ssh session with the server should show something like this:
rad_recv: Access-Request packet from host 192.168.1.1 port 56611, id=163, length=48
User-Name = "testuser"
User-Password = "testing123"
Wed Mar 22 12:44:33 2017 : Info: # Executing section authorize from file /etc/freeradius2/sites/default
Wed Mar 22 12:44:33 2017 : Info: +group authorize {
Wed Mar 22 12:44:33 2017 : Info: [eap] No EAP-Message, not doing EAP
Wed Mar 22 12:44:33 2017 : Info: ++[eap] = noop
Wed Mar 22 12:44:33 2017 : Info: [files] users: Matched entry testuser at line 3
Wed Mar 22 12:44:33 2017 : Info: ++[files] = ok
Wed Mar 22 12:44:33 2017 : Info: +} # group authorize = ok
Wed Mar 22 12:44:33 2017 : Info: WARNING: Please update your configuration, and remove 'Auth-Type = Local'
Wed Mar 22 12:44:33 2017 : Info: WARNING: Use the PAP or CHAP modules instead.
Wed Mar 22 12:44:33 2017 : Info: User-Password in the request is correct.
Wed Mar 22 12:44:33 2017 : Info: WARNING: Empty post-auth section. Using default return values.
Sending Access-Accept of id 163 to 192.168.1.1 port 56611
Wed Mar 22 12:44:33 2017 : Info: Finished request 0.
Wed Mar 22 12:44:33 2017 : Debug: Going to the next request
Wed Mar 22 12:44:33 2017 : Debug: Waking up in 4.9 seconds.
Wed Mar 22 12:44:38 2017 : Info: Cleaning up request 0 ID 163 with timestamp +4
Wed Mar 22 12:44:38 2017 : Info: Ready to process requests.
Watch for error messages and try to track down the reason for the error.
If the testing is successful, stop the radius server test using control-C. Then restart the radius server as a normal process and test again to make sure it is working right.
root@omnia:~# /etc/init.d/radiusd enable root@omnia:~# /etc/init.d/radiusd start
Configure Router/AP.
The main reason to set up radius with luci-app-radius is to give the router the ability to authorize wireless users using WPA2 Enterprise. This section shows how to use the radius server for that.
Configuring the AP isn't much different from the more normal configuration. This part can be done either at the command line or through the LuCI web interface. If the web interface is being used, this needs to be done for each interface.
From the command line, for both interfaces. This assumes you have already set the interfaces up for normal WPA-PSK/WPA2-PSK:
root@omnia:~# uci set wireless.@wifi-iface[0].auth_server=192.168.1.1 root@omnia:~# uci set wireless.@wifi-iface[0].auth_port=1812 root@omnia:~# uci set wireless.@wifi-iface[0].auth_secret=testing345 root@omnia:~# uci set wireless.@wifi-iface[1].auth_server=192.168.1.1 root@omnia:~# uci set wireless.@wifi-iface[1].auth_port=1812 root@omnia:~# uci set wireless.@wifi-iface[1].auth_secret=testing345 root@omnia:~# uci commit root@omnia:~# wifi