Meraki mesh repeater fails 802.1X because the gateway AP is missing from Windows NPS RADIUS Clients

Problem

A Cisco Meraki MR access point operating as a mesh repeater broadcasts several SSIDs successfully, but clients cannot connect to an Enterprise SSID that uses 802.1X/RADIUS authentication.

Typical symptoms include:

• Open, PSK or guest SSIDs on the same repeater work normally
• The repeater remains online in the Meraki Dashboard
• The repeater can reach internal network resources
• The affected Enterprise SSID fails during authentication
• Meraki reports RADIUS timeout, 802.1X auth failed, eapol_timeout or similar events
• The client may briefly associate but remain at 0.0.0.0 because authentication does not complete
• Other wired gateway APs may authenticate successfully against the same RADIUS server

When this pattern is limited to one repeater or one mesh path, investigate the RADIUS source path before changing the SSID, VLAN or DHCP configuration.

Environment / scope

This procedure applies to environments using:

• Cisco Meraki MR wireless
• A mesh topology with one or more repeater APs
• WPA2/WPA3 Enterprise or another 802.1X SSID
• Microsoft Network Policy Server (NPS) as the RADIUS server
• Direct RADIUS communication from the Meraki infrastructure to NPS

Example topology used throughout this article:

Wireless client
    |
    | 802.1X
    v
AP-MESH-02
Mesh repeater
    |
    | wireless mesh
    v
AP-GW-01
10.20.30.67
    |
    | wired LAN
    v
NPS01
10.20.30.20
UDP/1812

All hostnames, IP addresses, SSID names, VLAN IDs, MAC addresses and identifiers in this article are sanitized examples.

Version note

The exact source address used for RADIUS traffic can depend on MR firmware and whether Alternate Management Interface (AMI) is enabled.

Cisco documents that, on MR 32.1.x and later, RADIUS traffic originating from a repeater can use the AMI IP of the gateway AP when AMI is enabled. Do not assume the source IP blindly: verify it in NPS logs or a packet capture.

Expected behaviour

A client joining an Enterprise SSID should complete the following sequence:

Client
  -> 802.11 association
  -> EAP / 802.1X exchange
  -> AP sends RADIUS Access-Request
  -> NPS returns Access-Challenge / Access-Accept or Access-Reject
  -> 802.1X completes
  -> client receives VLAN access
  -> DHCP assigns an IP address

In Microsoft NPS terminology, the RADIUS Client is the network access server sending RADIUS requests, such as an access point or switch. It is not the laptop or phone connecting to Wi-Fi.

Observed behaviour

A common failed sequence in Meraki looks similar to:

SSID: CORP-WIFI
Authentication: WPA-Enterprise / 802.1X
Assigned VLAN: 30

RADIUS server: 10.20.30.20
Result: radius_timeout

Client:
Associated briefly
IP address: 0.0.0.0
Final state: 802.1X authentication failed

The fact that the client does not receive a DHCP address is usually a consequence, not the root cause. If 802.1X does not complete, troubleshooting DHCP first is unlikely to resolve the issue.

Likely causes

Check these in order:

1. RADIUS server unreachable from the affected AP
2. UDP/1812 blocked between the Meraki management path and NPS
3. Incorrect RADIUS server IP, port or shared secret
4. The gateway AP or actual RADIUS source IP is missing from NPS > RADIUS Clients
5. An outdated RADIUS Client entry points to an old AP management IP
6. Different AP groups or sites use different management subnets and only some are authorized in NPS
7. AMI changes the RADIUS source IP and NPS is still configured for the primary management address
8. NPS network policy, EAP or certificate problems after basic RADIUS communication is confirmed

Diagnostic workflow

1. Confirm that the failure is specific to 802.1X

Test another SSID on the same AP.

If the repeater can:

• broadcast other SSIDs,
• serve clients on those SSIDs,
• communicate with the Meraki Dashboard,

then the mesh itself is not completely down.

This does not prove that RADIUS works. It only narrows the fault domain.

2. Review the Meraki failed connection events

In the Dashboard, inspect the affected client and recent failed connections.

Look for messages such as:

Client made an 802.1X authentication request to the RADIUS server,
but it did not respond.

reason='radius_timeout'

Other supporting events can include:

802.1X auth failed
eapol_timeout
invalid_auth

A RADIUS timeout means either the Access-Request did not reach the RADIUS server or the reply did not reach the AP.

3. Test RADIUS connectivity from the AP fleet

Navigate to the SSID RADIUS configuration and run the built-in RADIUS test against the configured server.

Example result:

Total online APs tested: 24
Passed: 18
Failed: 6

This is especially useful when the same RADIUS server works from most APs but fails from a subset.

Interpretation

If all APs fail, investigate the server, routing, firewall, port and shared secret globally.

If only some APs fail, compare:

• management subnet
• physical site
• gateway AP
• mesh vs wired mode
• AMI configuration
• NPS RADIUS Client entries

A partial failure strongly suggests a source-specific problem rather than a global user credential issue.

4. Identify whether the affected AP is a repeater

Open the AP details page.

A repeater typically shows:

LAN IP:
—

Type:
AP is a repeater

Gateway:
AP-GW-01

Cisco documents that repeaters do not have a normal LAN IP in the same way as wired gateway APs and rely on a gateway AP for mesh connectivity.

Record the gateway AP name and management IP.

Example:

Repeater:
AP-MESH-02

Gateway AP:
AP-GW-01

Gateway management IP:
10.20.30.67

5. Ping the RADIUS server from the affected AP

From the AP Tools page, ping the NPS server.

Example:

Destination: 10.20.30.20
Packet loss: 0%
Average latency: 5 ms

Interpretation

If ping fails, investigate routing, management VLANs, ACLs or the mesh path.

If ping succeeds but RADIUS still times out, IP connectivity exists but this does not prove that UDP/1812 is accepted or that NPS recognizes the source as a valid RADIUS Client.

Continue with NPS validation.

6. Check the Windows NPS service

On the NPS server:

Get-Service IAS

Expected:

Status   Name   DisplayName
------   ----   -----------
Running  IAS    Network Policy Server

Optionally confirm that UDP/1812 is bound:

Get-NetUDPEndpoint | Where-Object {$_.LocalPort -eq 1812}

7. Check NPS RADIUS Clients

Open:

Network Policy Server
  -> RADIUS Clients and Servers
     -> RADIUS Clients

Search for the IP address that is actually sourcing RADIUS requests for the affected mesh path.

In the example topology, verify:

Friendly name: AP-GW-01
Address:       10.20.30.67
Status:        Enabled
Vendor:        RADIUS Standard

Also verify that the shared secret matches the secret configured for the NPS server in the Meraki Dashboard.

Important

Do not add the wireless endpoint MAC or IP as an NPS RADIUS Client.

The RADIUS Client is the network access device sending the RADIUS Access-Request.

8. Check NPS authentication events

In Event Viewer, inspect:

Windows Logs
  -> Security

Useful NPS event IDs include:

6272 - access granted
6273 - access denied
6274 - request discarded

Also inspect:

Custom Views
  -> Server Roles
     -> Network Policy and Access Services

If normal 627x events appear, inspect fields such as:

Client Friendly Name
Client IP Address
NAS IPv4 Address
Authentication Type
EAP Type
Reason Code
Reason

If the Meraki Dashboard shows repeated RADIUS timeouts but the expected NPS authentication events are absent, verify the actual source with a packet capture rather than assuming NPS is receiving a valid request.

9. Capture UDP/1812 when the source is uncertain

A packet capture is the most reliable way to verify the RADIUS path.

On the Meraki side, capture on the wired gateway AP or relevant wired segment with a filter similar to:

host 10.20.30.20 and udp port 1812

A healthy exchange should contain:

AP / NAS           -> NPS     RADIUS Access-Request
NPS                -> AP/NAS  RADIUS Access-Challenge / Access-Accept / Access-Reject

If Access-Requests leave the AP path but no reply returns, check NPS RADIUS Client authorization, shared secrets and firewall policy.

Evidence pattern

The following combination strongly indicates that the problem is associated with the RADIUS source path rather than the SSID or DHCP service:

• Other SSIDs work on the same repeater
• The repeater remains connected to its mesh gateway
• Ping from the repeater to NPS succeeds
• The Enterprise SSID reports radius_timeout
• RADIUS tests pass from many APs but fail from the affected mesh path
• The gateway AP management IP is absent from the NPS RADIUS Clients list
• Adding the correct gateway/source IP to NPS restores authentication

Root cause

The confirmed root cause in the validated case was that the gateway AP used by the mesh repeater was not configured as a RADIUS Client in Microsoft NPS.

The repeater itself had no normal LAN IP. Its RADIUS authentication path depended on the gateway AP.

The gateway AP's management address was not present in:

NPS
  -> RADIUS Clients and Servers
     -> RADIUS Clients

As a result, client authentication attempts through that mesh path produced RADIUS timeouts even though:

• the AP was online,
• the mesh link worked,
• other SSIDs worked,
• the RADIUS server responded to ICMP ping.

Resolution

1. Add the correct network access device to NPS

Open:

Network Policy Server
  -> RADIUS Clients and Servers
     -> RADIUS Clients
     -> New

Create the entry using the verified RADIUS source address.

Example:

Enable this RADIUS client: Yes

Friendly name:
AP-GW-01

Address:
10.20.30.67

Vendor:
RADIUS Standard

Shared secret:
Use the same secret configured for this NPS server in Meraki

Do not copy a shared secret into tickets, screenshots or knowledge-base articles.

2. Save the configuration

After adding the client through the NPS console, retry authentication.

If the RADIUS Client is created using PowerShell instead of the GUI, follow the Microsoft documentation for the cmdlet being used, including any NPS service restart requirement.

Validation

Retry the Enterprise SSID from a client connected through the repeater.

Confirm all of the following:

• The client remains associated
• radius_timeout no longer appears for the attempt
• 802.1X completes
• The client is placed in the expected VLAN
• DHCP assigns an address
• The expected network access is available
• NPS records a normal authentication result where auditing is enabled

Example:

SSID: CORP-WIFI
VLAN: 30
Client IP: 10.30.0.54
802.1X: authenticated

Rollback / recovery

If the newly created RADIUS Client uses the wrong source IP or was added in error:

1. Remove or disable the incorrect NPS RADIUS Client entry.
2. Confirm the actual RADIUS source address with a packet capture.
3. Re-create the entry with the correct address and shared secret.

Adding an overly broad RADIUS Client range can unintentionally trust more network access servers than intended. Prefer explicit AP/NAS entries unless a range-based design is deliberate and documented.

Prevention / best practice

• Add the RADIUS/NAS requirement to the AP deployment checklist
• Document each gateway AP management IP used for RADIUS
• Update NPS whenever an AP management IP or management VLAN changes
• Check NPS RADIUS Clients after replacing or re-addressing gateway APs
• Treat mesh repeaters differently from wired APs during 802.1X troubleshooting
• Compare working and failing APs instead of testing only one endpoint
• Use the Meraki RADIUS test to identify whether failures are global or AP-specific
• Verify the actual RADIUS source IP when AMI is enabled
• Keep the RADIUS shared secret consistent and protected
• Do not troubleshoot DHCP until 802.1X authentication has completed

Quick diagnostic sequence

1. Other SSIDs on the AP work?
   Yes -> focus on 802.1X/RADIUS.

2. Meraki shows radius_timeout?
   Yes -> test RADIUS reachability.

3. Affected AP is a mesh repeater?
   Yes -> identify its gateway AP.

4. Ping from repeater to NPS succeeds?
   Yes -> inspect UDP/1812 and NPS RADIUS Clients.

5. Gateway/source IP exists in NPS RADIUS Clients?
   No -> add the correct NAS with the matching shared secret.

6. Retry authentication.
   Success -> validate VLAN, DHCP and NPS logs.

Related articles

• Cisco Meraki MR RADIUS packet capture workflow — planned
• Microsoft NPS 802.1X event interpretation — planned
• Designing resilient RADIUS authentication for multiple AP sites — planned

Sources

See the authoritative Cisco Meraki and Microsoft references in the article metadata.