TS-flow-radius
This document is not meant to be used on it's own, as it contains troubleshooting steps in random order.
Please follow the RADIUS Issue Resolution Guide instead.
Is the SSID configured to use My RADIUS servers?
Navigate to Wireless > Configure > Access Control: Select (SSID) >
|
Legacy Access Control Page > Association requirements |
New Access Control Page > Security |
 |
 |
Take note of the configuration and continue to the next step in the troubleshooting flow.
Is Dashboard Configuration Correct?
Navigate to Wireless > Configure > Access Control: Select (SSID) > RADIUS
| Legacy Access Control page | New Access Control 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
If the configuration is correct, please proceed to the next step in the RADIUS troubleshooting flow.
Can you Ping the RADIUS Server from the Access Point?
-
Navigate to Wireless > Monitor > Access Points > Select Access Point > Tools > Ping, type RADIUS server's IP address and click Ping.
Example successful ping:
Failing ping:
Take note of the results and proceed to the next step in the RADIUS troubleshooting flow.
Perform a wired capture on the access point port while reproducing the issue
-
Disable the wireless adapter of your testing device
-
Navigate to Network Wide > Monitor > Packet Capture > for access points > Access point name > Interface = Wired > click Start capture
- Re-enable the wireless adapter of your device and reproduce the issue
- Stop the capture
Open the capture with Wireshark. Use this filter:
ip.addr==192.168.128.254 && radius
(replace 192.168.128.254 with your RADIUS server IP)
Continue to the next step of the troubleshooting flow.
Do you see access-accept, access-reject or none?
Example of access-accept:
If you see an Access-Accept in your capture and you still have issues connecting to the SSID, please continue to the Access-Accept received troubleshooting section.
Example of access-reject:
If you see an access-reject on your packet capture, please continue to the Access-Reject received troubleshooting section.
None:
When you don't get either access-reject or access-accept, you may either see only Access-request packet like this one:
Or the process may get stuck after an access-challenge or an access-request:
Take note of the behavior that you see and continue to the next troubleshooting step.
Are there many access-request retries?
Even when you see access-accept packets, if your capture has noticeable number of duplicate requests (retries) could cause many clients to not be able to connect to the SSID.
Take note of the behavior and continue to the next troubleshooting step in the diagram.
Does the access-accept contain a group policy override?
You may see a group policy override with any of these 4 attributes:
Filter-ID: The RADIUS server uses the AVP Filter-ID to assign the group policy called Ntw Admins.
Reply-Message: The client received the group policy Policy-X through the reply-message attribute.
Airespace-ACL-Name: The group policy Policy-Y was assigned to the client through the Airespace-ACL-Name attribute.
Aruba-User-Role: The RADIUS server uses Aruba-User-Role to assign the group policy Policy-Z.
If the access-accept seen in the capture contain one of the attributes mentioned before, take note of it and continue to the next troubleshooting step.
Does the SSID expects group policy override for the right attribute?
- Navigate to Wireless > Configure > Access control and select the appropriate SSID
- Under RADIUS attribute specifying group policy name, ensure the right attribute is selected
Now that you confirmed if the right attribute is used, go back to the troubleshooting flow.
Does the group policy exist?
Navigate to Network-wide > Configure > Group Policies, and ensure that the desired policy exists. The name should exactly match with the name received from the RADIUS server.
Now that you confirmed if the policy exists or not, go back to the troubleshooting flow.
Is the group policy blocking the client?
Navigate to Network-wide > Configure > Group Policies > Policy Name and ensure the policy doesn't have firewall rules or umbrella policies that may be inadvertently blocking the client.
Take note of the config and continue to the next troubleshooting step in the diagram.
Does it contain a VLAN override?
A correct VLAN override must contain Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802 and Tunnel-Private-Group-ID = <vlan--to-be-assigned>. If any of these three attributes is missing, the VLAN override won't work.
In this example, RADIUS is assigning VLAN 200 to the user.
If the access-accept contains a VLAN override, take note of it and go back to the TS flow to continue to the next troubleshooting step.
Does the SSID accept VLAN override?
Navigate to Wireless > Configure > Access control > SSID-name
|
New access control page > Client IP and VLAN > RADIUS override = Override VLAN tag |
Legacy Access control page > Addressing and traffic > RADIUS override = RADIUS response can override VLAN tag |
 |
 |
Take note of the config and continue to the next troubleshooting step in the diagram.
Collect a wireless capture while reproducing the issue
Choose one of these tools to collect a wireless capture. They are listed in their easiness, so select the first one you have available.
- A Macbook
- Other Meraki Acess points installed closed to the access point selected to reproduce the problem
- Cisco access points
- A linux device with a wireless card (Can be a laptop live boot linux)
Meraki Support most likely will need a wireless capture, so try to gather one before reaching out.
Collect wireless captures when only Meraki Access Points are available
If you have a spare Meraki access point that can be installed in the room where the problem is seen, jump to step 4. If you are going to use a neighbor access point (like an access point installed in the next room) start here:
Step 1. Choose the access point where the problem will be reproduced.
Step 2. Navigate to Wireless > Monitor > RF spectrum > select Access point
Select the band where the problem is reproduced, 2.4GHz/5GHz.
Take note of the channels used by the access point, in this example the access point is using channels 11 for the 2.4GHz band and 100 for the 5GHz band.
Click Interfering APs, order by dBm descending and take note of the BSSID that corresponds to one of the local SSIDs, seen with the strongest signal.
The SSID *p broadcasted by the access point MR-36-2 is the one experiencing the problem. This access point can hear to another access point with the BSSID 92:18:98:fc:13:3a strongly:
Step 3. Identify the access point that is broadcasting the strong BSSID
From above example, the BSSID ends with 13:3a, so we can use it to filter the access points
Click the access point name and then click BSSID Details, confirm that in fact, MR-46-2 is the strong neighbor of MR-36-2.
Step 4. Configure the strong neighbor (or the spare access point) to use the same channel as the access point that'll be used to reproduce the issue
Navigate to Wireless > Configure > Radio settings > Access point name row > click channel > click Change channel setting
Select Manual, the desired channel, Save.
If you are not sure which radio band will be used by the access point, match both 2.4 and 5GHz bands to use the same channel as the repro-access point.
Step 5. Once both repro-access point and neighbor access point are using the same channel, start the wireless capture.
Navigate to Network-wide > Monitor > Packet capture. In Access point: select both the repro-access point and its strongest neighbor.
Click Start capture and reproduce the problem.
Does the GP override the VLAN?
Navigate to Network-wide > Configure > Group policies > Policy-name > VLAN and check the status of the setting. If it's set to either Do not tag VLAN, or Tag VLAN, then the group policy is modifying the default VLAN assigned to the client.
Take note of the configuration and continue to the next step in the troubleshooting flow.
Confirm the neighbor device has the correct VLAN configuration
Depending on where your access points are connected, you can use these documents to ensure they are handling the correct VLANs:
Do you see the complete 4-way-handshake process?
On the wireless capture, apply this filter:
wlan.addr == <client-mac-address> and eapol
You should see Message 1 through 4.
If you ran the capture using multiple Meraki access points and see some duplicates, that may be expected and nothing to worry about.
Take note of the behavior and continue to the next step.
Do you see any data traffic coming from the wireless client?
On the wireless capture, apply this filter:
wlan.addr == <client-mac-address> and wlan.fc.type_subtype == 0x028
Ensure you see QoS Data frames to/from the client mac address:
Take note of the behavior and continue to the next step.
Is the client traffic forwarded to the LAN?
Go back the wired capture taken before, and using this filter confirm you see traffic sourced by the client MAC. If you see it, that means the access point is forwarding the client traffic from the wireless medium to the LAN.
eth.addr == <client-mac-addr> and (dhcp or arp or dns)
Take note of the result and go back to the TS flow.
Which device sends the last packet over the air?
Use this filter in the wireless capture:
wlan.addr == <client-mac-address> and eap
Check the source mac address of the last packet to check if the last packet was sent by the wireless client or the access point.
In this example, the last packet was sent by 96:18:88:bc:c8:9c and received by 8a:43:15:a1:05:6f. Meaning that the last packet was sent by the access point.
Take note of the behavior and continue to the next step.
Potential reasons the client stops the 802.1x authentication
Client doesn't trust the RADIUS server certificate
If the capture ends after the Server Hello, certificate packet, most likely the wireless client doesn't trust the RADIUS server certificate. You'll need to install the RADIUS server certificate in your client or modify the client configuration to trust it.
The certificate is expired
Expand the Server Hello and confirm the certificate is still valid
Potential access-reject reasons
Your Meraki access points are working as expected and your RADIUS server is preventing the client from connecting to the network. To understand better why RADIUS is rejecting the client, try expanding the access-reject packet. As a next step, look into your RADIUS server logs and investigate why it's rejecting the client.
These reasons are offered as a best effort. If you still need help please contact your RADIUS server support.
RADIUS server and clients don't support the same EAP method
Adjust either your RADIUS server configuration or your client to match at least one EAP method.