Unifi USG: Troubleshooting RADIUS Authentication

Obtained from: https://help.ubnt.com/hc/en-us/articles/360006455793-UniFi-Troubleshooting-RADIUS-Authentication

 

Overview


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

NOTES & REQUIREMENTS: Before proceeding with this article please make sure you are familiar with the contents of the Related Articles for USG, USW, and UAP. It will be helpful in understanding what each section of configuration entails and requires.

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

USW-RADIUS.png


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
NOTE: You can also issue IP addresses the local subnet (192.168.1.0/24 in this case).

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 
NOTE: use_tunneled_reply is enabled by default on the USG settings.

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.

ATTENTION: When using the USG as the RADIUS server accounting is not enabled.
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

ATTENTION: To input these commands you must first type telnet localhost proceeded by enable in the CLI. Example below. 
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

Click Here to Expand the Output Definitions

show radius servers

Click Here to Expand the Output Definitions

show radius statistics <server IP or name>

Click Here to Expand the Output Definitions

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

Click Here to Expand the Output Definitions

show dot1x clients {slot/port | all} 

Click Here to Expand the Output Definitions

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.

ATTENTION: When using the USG as the RADIUS server accounting is not enabled. 
 

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


 

CLI: Access the command line interface (CLI). You can do this using by using an SSH client program.

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. 

NOTE: The radtest command used below will not work with mschapv2.
#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.

 

You may also like...

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: