---

Overview

---

In this article, readers should expect to gain key troubleshooting skills for debugging 802.1X authentication on UniFi devices.

---

Table of Contents

---

1. Network Diagram
2. Common Issues
3. Troubleshooting Wired 802.1X on the USW
   1. Useful Commands from Debugging Terminal or SSH Client
4. Troubleshooting Wireless 802.1X on the UAP
5. Troubleshooting RADIUS authentication on the USG
6. Related Articles

---

Network Diagram

---

Authentication Process

---

Common Issues

---

This is a short list of common issues that can occur with RADIUS authentication.

The client device isn’t put on the correct VLAN

1. Verify that the account on the authentication server has a VLAN ID specified.

2. Verify that Enabled RADIUS assigned VLAN is enabled on the RADIUS profile.

3. Verify with tcpdump on the device that the server is sending the correct VLAN in the RADIUS accept message. 

    3.1. Use the following command in an SSH session on a UniFi device:

sudo tcpdump -npi eth0 port 1812 -vvv

An attribute named “vlan-id” will have the VLAN specified if the RADIUS server is sending it correctly.

4. Verify that “use_tunneled-reply” is enabled on a freeradius based authentication server.

Sample FreeRADIUS EAP configuration (/etc/freeradius/3.0/mods-enabled/eap):

use_tunneled_reply = yes 

The client device has an authentication timeout

1. Verify with tcpdump on the UniFi device whether the RADIUS server is responding to the RADIUS request. 

    1.1. Use the following command in an SSH session on a UniFi device:

sudo tcpdump -npi eth0 port 1812 

The transaction listed in the network diagram above should take place. If the radius-accept is returned move on in the steps below.

---

Troubleshooting Wired 802.1X on the USW

---

This process will allow a UniFi admin to see the packet-by-packet interaction between the authenticator (switch) and the RADIUS server.

Authentication

1. Use the following command in the Debugging Terminal or SSH Client

sudo tcpdump -npi eth0 port 1812 -vv

2. Plug in an 802.1X compliant client device.

3. View the output.

1. If the RADIUS process ends in an accept message from the RADIUS server the client will be authorized to send traffic on the network.
2. If the RADIUS messages timeout, check to see if there is connectivity between the USW and the RADIUS server. Check for firewalls blocking port 1812, and basic connectivity between the USW and RADIUS server.
3. If the RADIUS process ends in a reject message from the RADIUS server, ensure that the client device is using the correct credentials.

Accounting

Accounting only happens after authentication is successful.

sudo tcpdump -npi eth0 port 1813 -vv

1. Use the following command in the Debugging Terminal or SSH Client

Useful Commands from Debugging Terminal or SSH Client

USW-24P-US.v4.0.14# telnet localhost

Entering character mode
Escape character is '^]'.

Warning!
The changes may break controller settings and only be effective until reboot.

(UBNT) >enable

(UBNT) #

Key Commands

show radius

show radius servers

show radius statistics <server IP or name>

show dot1x authentication-history <slot/port number> [detail]

show dot1x clients {slot/port | all} 

---

Troubleshooting Wireless 802.1X on the UAP

---

Authentication

1. Use the following command in the Debugging Terminal or SSH Client

sudo tcpdump -npi eth0 port 1812 -vv

2. Connect an 802.1X compliant client device.

3. View the output.

1. If the RADIUS process ends in an accept message from the RADIUS server the client will be authorized to send traffic on the network.
2. If the RADIUS messages timeout, check to see if there is connectivity between the UAP and the RADIUS server. Check for firewalls blocking port 1812, and basic connectivity between the UAP and RADIUS server.
3. If the RADIUS process ends in a reject message from the RADIUS server, ensure that the client device is using the correct credentials.

Accounting

Accounting only happens after authentication is successful.

1. Use the following command in the Debugging Terminal or SSH Client

sudo tcpdump -npi eth0 port 1813 -vv

Logging

Setting the device logging level to debug can help diagnose issues with the UAP outside of packet captures. Navigate to Settings > Maintenance > Log Level if you would like to change that setting. 

 

Troubleshooting RADIUS authentication on the USG

---

 

This section will cover methods of troubleshooting RADIUS authentication on the UniFi Security Gateway. 

USG as RADIUS Server

Viewing the FreeRADIUS logs

sudo cat /var/log/freeradius/radius.log

This command will show logs from the process starting, authentication attempts along with failures, and any associated problems with the service.

Running in the foreground

This command in SSH will start FreeRADIUS in the foreground on the USG. It will allow viewing of events printed to the console in real-time. 

#Usage
sudo service freeradius restart
sudo service freeradius stop
sudo freeradius -fX

#For less verbosity use -fxx instead of -fX
sudo freeradius -fxx 

#to stop freeradius running in the foreground and return to normal operation.
ctrl+c
sudo service freeradius start

#Sample output using radtest
rad_recv: Access-Request packet from host 172.20.1.1 port 57380, id=57, length=78
 User-Name = "ubnttest"
 User-Password = "test1234"
 NAS-IP-Address = 172.20.1.1
 NAS-Port = 0
 Message-Authenticator = 0x8af0fec45c575d375c1c6ba366253feb
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "ubnttest", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry DEFAULT at line 1
[files] users: Matched entry ubnttest at line 5
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
Found Auth-Type = PAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group PAP {...}
[pap] login attempt with password "test1234"
[pap] Using clear text password "test1234"
[pap] User authenticated successfully
++[pap] returns ok
Login OK: [ubnttest] (from client client-5c2650e21876930ceb43007e port 0)
# Executing section post-auth from file /etc/freeradius/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 57 to 172.20.1.1 port 57380
 Acct-Interim-Interval = 3600
 Tunnel-Type:0 = VLAN
 Tunnel-Medium-Type:0 = IEEE-802
 Tunnel-Private-Group-Id:0 = "5"
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 0 ID 57 with timestamp +5
Ready to process requests.

USG as Authenticator to Third-party Authentication Server

Use “radtest” to send a test authentication message to a third-party RADIUS server.

#Options
sudo radtest -h

#Usage (brackets denote optional parameters)
sudo radtest username password radius-server:[port] NAS-port secret [ppphint] [nasname]

#Example command (192.168.1.2 as auth. server)
sudo radtest ubnttest testpw12! 192.168.1.2 0 thisisasecret

#Sample Output
>sudo radtest ubnttest test1234 172.20.1.1 0 JustW0rkingH3r3$
Sending Access-Request of id 100 to 172.20.1.1 port 1812
 User-Name = "ubnttest"
 User-Password = "test1234"
 NAS-IP-Address = 172.20.1.1
 NAS-Port = 0
 Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 172.20.1.1 port 1812, id=100, length=41
 Acct-Interim-Interval = 3600
 Tunnel-Type:0 = VLAN
 Tunnel-Medium-Type:0 = IEEE-802
 Tunnel-Private-Group-Id:0 = "5"

If a response comes back from the authentication server it proves that authentication is working properly. If no response is received, ensure that the authentication server is online and can process access request messages from the authenticator IP.