MX/MS RADIUS Troubleshooting
Overview
MS Switches, and MX/Z Security Appliances (Meraki devices) provide the ability to configure an external server for RADIUS authentication. This article outlines the general methodology for RADIUS troubleshooting, and provides a flow to isolate and fix the issue in a systematic manner.
For RADIUS configurations or initial setup, refer to the following articles:
Troubleshooting Flow for RADIUS Authentication
The following flow chart contains steps for isolating and troubleshooting common RADIUS authentication issues. Follow the chartfrom top to bottom in any given scenario. This article is outlined to solve most common RADIUS issues or to isolate the issue to a specific point in the network.
Dashboard Configuration
The first thing to verify is if the RADIUS configurations are made correctly on the Meraki dashboard. The RADIUS configurations can be accessed by navigating to the following:
Switching > Configure > Access Policies > Radius Servers
Security & SD-WAN/Teleworker Gateway > Configure > Access Policies > RADIUS for Splash Page
The following parameters must be verified:
- The IP address of the RADIUS server is added correctly
- Port is configured the same on dashboard as well as the RADIUS server
- Secret is identical on the dashboard as well as the RADIUS server
RADIUS Server Ping Test
During a RADIUS authentication, the Meraki devices will try to reach out to the RADIUS server with RADIUS packets. In order for this to be successful, the RADIUS server should be reachable from the Meraki source. Hence, we will test the RADIUS server reachability via the following steps:
- Navigate to the Device Status Page:
- MS: Switching > Switches > Select Switch > Tools > Ping
- MX: Security & SD-WAN > Appliance Status > Tools > Ping
- Z-Series: Teleworker Gateway > Appliance Status > Tools > Ping
- Use the ping tool and ping the IP of the RADIUS server
- If the pings are failing, verify the routing to the RADIUS server
Dashboard RADIUS Test Tool
The dashboard configuration provides a test tool to verify the connectivity with the RADIUS server as shown above. Clicking on “Begin test” with the RADIUS credentials can result in either “Test = Pass” or “Test = Fail”. The test tool triggers a RADIUS Access-Request/Challenge exchange between the switches and the RADIUS server. It is designed to confirm that the server is reachable from the switches and that the credentials supplied are valid only. If using an EAP type that requires a client-side certificate such as EAP-TLS, the test will fail because the switch does not have the certificate installed. It is recommended to test with a real client device.
Note: The RADIUS Test Tool is currently available for MS switches and MR access points. The RADIUS Test Tool is not available for MX appliances or Z-Series gateways at this time.
Test = Pass
If the dashboard RADIUS test passes, look into the following steps:
- When the test passes, the RADIUS server is reachable and is configured for authentication. If a client is unable to connect, check if the client device is generating an EAP session.
- Check the logs that will be generated on the RADIUS server after a failed client authentication.
Test = Fail
If the RADIUS server is ping-able but the test is failing, continue ahead with the Dashboard Packet Captures section below.
Dashboard Packet Captures
The Meraki dashboard provides the ability to take packet captures directly on all RADIUS-capable Meraki devices in the network. This feature can be accessed by navigating to Network Wide > Monitor > Packet Capture.
The packet capture must be taken on the wired interface of the Meraki device through which the RADIUS server can be reached. It is highly recommended to download the output as a .pcap file for Wireshark.
Once a packet capture is initiated, have a failed client attempt to connect to RADIUS again and let the packet capture run while this process is being completed. The packet capture can be opened in Wireshark and a filter can be applied as shown below:
Wireshark Filter for RADIUS:
For example: ip.addr==192.168.128.254 && radius (192.168.128.254 is the IP of the RADIUS server)
A generic filtered RADIUS packet capture is shown below for reference:
The above screenshot is for a successful RADIUS authentication, as you can see bi-directional communication with Access-Requests, Access-Challenges and Access-Accept. Download a sample packet capture for reference.
RADIUS Traffic Flow
In case of a RADIUS authentication failure, the traffic flow would be different. You may observe one of the three possible outcomes:
- No RADIUS protocol traffic
- Unidirectional Access-Requests
- RADIUS server sending Access-Reject
No RADIUS Protocol traffic
With the Wireshark filter mentioned above, only the RADIUS traffic will be filtered in the output. Also, if there is no RADIUS protocol traffic being sent out to the RADIUS server from the Meraki devices, the output will be empty. If there is traffic seen, make sure to verify the username to make sure the traffic has been seen for the correct client device.
In case of no RADIUS protocol traffic seen from the Meraki device, follow the steps below:
- Verify if the client is attempting to connect to the correct port and generating an EAP session.
- Verify the configurations on the client device to make sure they match with the requirements for RADIUS authentication.
- Take a wireless or wired packet capture on the client device to check if the traffic is being sent out of the client device.
- After confirming that the client device is sending the required traffic, if the authentication fails, take another packet capture and follow the flow chart.
When a client generates an EAP session and sends traffic to a Meraki device, the Meraki device will forward an Access-Request to the RADIUS server.
Unidirectional Access-Request(s)
If the client device is generating EAP session traffic and we see unidirectional Access-Requests in the packet capture, the RADIUS authentication will fail as the responses were not received from the server. This can be an outcome due to multiple failure reasons listed below:
- Routing to RADIUS server:
- Because the Access-Requests are being sent to the RADIUS server and no responses are noticed, the traffic might be getting dropped before reaching the RADIUS server.
- If the pings are successful, you would need to verify where the RADIUS traffic is being dropped and fix the routing.
- RADIUS services:
- If the routing is correct and the RADIUS packets are being delivered to the RADIUS server, you would need to verify if the RADIUS services are turned ON on the RADIUS server.
- RADIUS clients:
- If the EAP session traffic being generated by a client is not authorized in the RADIUS server configurations, the RADIUS server will drop the packets.
- Make sure the Meraki device is added as a RADIUS client and is authorized.
Once these settings and configurations are verified and correct, and if the authentication is still failing, take another packet capture and follow the flow chart.
RADIUS Server Responds with Access-Reject
Once the Access-Request is received by the RADIUS server, it can either send an Access-Accept to authenticate the client or send a Access-Reject to deny authentication.
If an Access-Reject is received from the RADIUS server, there are multiple possible reasons, some of which are listed below:
- No certificate installed on the RADIUS Server or the certificate has expired:
- Verify if the digital certificate installed on the RADIUS server is still valid.
- If the certificate has expired or is missing, a renewal or an installation of the digital certificate would be needed.
- Incorrect username or password:
- If a client logs in using incorrect credentials (username or password or both), the RADIUS server will deny the authentication using an Access-Reject.
- Incorrect secret on the dashboard:
- The secret configured in dashboard should match the secret key added on the RADIUS server while configuring the RADIUS clients.
There are some factors that can cause the RADIUS server to deny an authentication and some of them are listed below:
- Network Policy is misconfigured
- Connection Request Policy is misconfigured
- Mismatch in Authentication Settings
- If using Active Directory on the server, the client may not be a member of the domain
- Root Certificate is not added to the client device(s)
- Incorrect EAP method used on server or client
RADIUS Traffic Verification
Once the mentioned steps are verified and the configurations are as required, another packet capture can be taken using the Dashboard Packet Capture tool, and the RADIUS traffic flow can be verified.
At this point, the client should get authenticated and we should see the server sending the client an Access-Accept message. If the server still sends an Access-Reject, it is most likely a server issue and you would need to access the RADIUS server to verify the logs that are generated.