Meraki mesh repeater falha 802.1X porque o gateway AP não está configurado em Windows NPS RADIUS Clients

Problema

Um access point Cisco Meraki MR a funcionar como mesh repeater transmite vários SSIDs corretamente, mas os clientes não conseguem ligar-se a um SSID Enterprise que utiliza 802.1X/RADIUS authentication.

Sintomas típicos:

• SSIDs Open, PSK ou guest no mesmo repeater funcionam normalmente
• O repeater permanece online no Meraki Dashboard
• O repeater consegue aceder a recursos internos
• O SSID Enterprise afetado falha durante a autenticação
• O Meraki apresenta eventos como RADIUS timeout, 802.1X auth failed, eapol_timeout ou semelhantes
• O cliente pode associar-se brevemente, mas permanecer em 0.0.0.0 porque a autenticação não termina
• Outros gateway APs ligados por cabo podem autenticar corretamente contra o mesmo RADIUS server

Quando este padrão está limitado a um repeater ou a um determinado mesh path, investiga primeiro o caminho de origem RADIUS antes de alterares a configuração de SSID, VLAN ou DHCP.

Ambiente / âmbito

Este procedimento aplica-se a ambientes com:

• Cisco Meraki MR wireless
• Uma topologia mesh com um ou mais repeater APs
• WPA2/WPA3 Enterprise ou outro SSID 802.1X
• Microsoft Network Policy Server (NPS) como RADIUS server
• Comunicação RADIUS direta da infraestrutura Meraki para o NPS

Topologia de exemplo utilizada neste artigo:

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

Todos os hostnames, endereços IP, nomes de SSID, VLAN IDs, MAC addresses e identificadores apresentados neste artigo são exemplos anonimizados.

Nota sobre versões

O endereço de origem exato utilizado para tráfego RADIUS pode depender do firmware MR e de estar ou não ativa a Alternate Management Interface (AMI).

A Cisco documenta que, em MR 32.1.x e versões posteriores, tráfego RADIUS originado por um repeater pode utilizar o AMI IP of the gateway AP quando AMI está ativa. Não assumas o source IP: valida-o nos logs do NPS ou através de packet capture.

Comportamento esperado

Um cliente que entra num SSID Enterprise deve completar a seguinte sequência:

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

Na terminologia do Microsoft NPS, o RADIUS Client é o network access server que envia os pedidos RADIUS, como um access point ou switch. Não é o portátil ou telefone que se liga ao Wi-Fi.

Comportamento observado

Uma sequência de falha comum no Meraki pode ser semelhante a:

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

O facto de o cliente não receber um endereço DHCP é normalmente uma consequência e não a causa raiz. Se o 802.1X não for concluído, começar por troubleshooting de DHCP dificilmente resolverá o problema.

Causas prováveis

Verifica pela seguinte ordem:

1. RADIUS server inacessível a partir do AP afetado
2. UDP/1812 bloqueado entre o management path do Meraki e o NPS
3. IP, porta ou shared secret do RADIUS server incorretos
4. O gateway AP ou o source IP real do RADIUS não existe em NPS > RADIUS Clients
5. Uma entrada RADIUS Client desatualizada aponta para um antigo management IP do AP
6. Diferentes grupos de APs ou sites usam management subnets diferentes e apenas alguns estão autorizados no NPS
7. AMI altera o source IP do RADIUS e o NPS continua configurado para o primary management address
8. Problemas de NPS network policy, EAP ou certificado depois de confirmada a comunicação RADIUS base

Workflow de diagnóstico

1. Confirmar que a falha é específica de 802.1X

Testa outro SSID no mesmo AP.

Se o repeater consegue:

• transmitir outros SSIDs,
• servir clientes nesses SSIDs,
• comunicar com o Meraki Dashboard,

então o mesh não está completamente em baixo.

Isto não prova que RADIUS funciona. Apenas reduz o fault domain.

2. Rever os eventos de failed connection no Meraki

No Dashboard, inspeciona o cliente afetado e as ligações falhadas recentes.

Procura mensagens como:

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

reason='radius_timeout'

Outros eventos relevantes podem incluir:

802.1X auth failed
eapol_timeout
invalid_auth

Um RADIUS timeout significa que o Access-Request não chegou ao RADIUS server ou que a reply não regressou ao AP.

3. Testar conectividade RADIUS a partir da frota de APs

Vai à configuração RADIUS do SSID e executa o teste RADIUS integrado contra o servidor configurado.

Exemplo:

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

Isto é especialmente útil quando o mesmo RADIUS server funciona a partir da maioria dos APs mas falha num subconjunto.

Interpretação

Se todos os APs falharem, investiga globalmente o servidor, routing, firewall, porta e shared secret.

Se apenas alguns APs falharem, compara:

• management subnet
• physical site
• gateway AP
• mesh vs wired mode
• configuração AMI
• entradas NPS RADIUS Client

Uma falha parcial aponta fortemente para um problema específico da origem e não para credenciais de utilizador globais.

4. Identificar se o AP afetado é repeater

Abre a página de detalhes do AP.

Um repeater normalmente apresenta:

LAN IP:
—

Type:
AP is a repeater

Gateway:
AP-GW-01

A Cisco documenta que os repeaters não têm um LAN IP normal da mesma forma que os wired gateway APs e dependem de um gateway AP para conectividade mesh.

Regista o gateway AP name and management IP.

Exemplo:

Repeater:
AP-MESH-02

Gateway AP:
AP-GW-01

Gateway management IP:
10.20.30.67

5. Fazer ping ao RADIUS server a partir do AP afetado

Na página Tools do AP, faz ping ao NPS server.

Exemplo:

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

Interpretação

Se o ping falhar, investiga routing, management VLANs, ACLs ou o mesh path.

Se o ping funcionar mas RADIUS continuar em timeout, existe conectividade IP, mas isso não prova que UDP/1812 é aceite ou que o NPS reconhece a origem como RADIUS Client válido.

Continua com validação no NPS.

6. Verificar o serviço Windows NPS

No NPS server:

Get-Service IAS

Esperado:

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

Opcionalmente confirma que UDP/1812 está em listening:

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

7. Verificar NPS RADIUS Clients

Abre:

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

Procura o endereço IP que está realmente a originar os pedidos RADIUS para o mesh path afetado.

Na topologia de exemplo, valida:

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

Confirma também que o shared secret corresponde ao configurado para o NPS server no Meraki Dashboard.

Importante

Não adiciones o MAC ou IP do wireless endpoint como NPS RADIUS Client.

O RADIUS Client é o network access device que envia o RADIUS Access-Request.

8. Verificar eventos de autenticação NPS

No Event Viewer, consulta:

Windows Logs
  -> Security

Event IDs NPS úteis:

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

Consulta também:

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

Se aparecerem eventos 627x normais, inspeciona campos como:

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

Se o Meraki Dashboard mostrar RADIUS timeouts repetidos mas não existirem os eventos NPS esperados, valida a origem real através de packet capture em vez de assumires que o NPS está a receber um pedido válido.

9. Capturar UDP/1812 quando a origem é incerta

Um packet capture é a forma mais fiável de validar o caminho RADIUS.

No lado Meraki, captura no wired gateway AP ou segmento wired relevante com um filtro semelhante a:

host 10.20.30.20 and udp port 1812

Uma troca saudável deve conter:

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

Se os Access-Requests saírem pelo caminho do AP mas não existir reply, verifica autorização do NPS RADIUS Client, shared secrets e firewall policy.

Padrão de evidência

A seguinte combinação indica fortemente que o problema está associado ao RADIUS source path e não ao SSID ou serviço DHCP:

• Outros SSIDs funcionam no mesmo repeater
• O repeater permanece ligado ao mesh gateway
• O ping do repeater para o NPS funciona
• O Enterprise SSID apresenta radius_timeout
• Os testes RADIUS passam em vários APs mas falham no mesh path afetado
• O management IP do gateway AP não está na lista NPS RADIUS Clients
• Adicionar o gateway/source IP correto ao NPS restaura a autenticação

Causa raiz

A causa raiz confirmada no caso validado foi que o gateway AP utilizado pelo mesh repeater não estava configurado como RADIUS Client no Microsoft NPS.

O próprio repeater não tinha um LAN IP normal. O seu caminho de autenticação RADIUS dependia do gateway AP.

O management address do gateway AP não estava presente em:

NPS
  -> RADIUS Clients and Servers
     -> RADIUS Clients

Como resultado, as tentativas de autenticação através desse mesh path produziam RADIUS timeouts apesar de:

• o AP estar online,
• o mesh link funcionar,
• outros SSIDs funcionarem,
• o RADIUS server responder a ICMP ping.

Resolução

1. Adicionar o network access device correto ao NPS

Abre:

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

Cria a entrada utilizando o RADIUS source address validado.

Exemplo:

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

Não copies um shared secret para tickets, screenshots ou artigos da Knowledge Base.

2. Guardar a configuração

Depois de adicionares o client através da consola NPS, volta a testar a autenticação.

Se o RADIUS Client for criado via PowerShell em vez da GUI, segue a documentação Microsoft do cmdlet utilizado, incluindo qualquer requisito de restart do serviço NPS.

Validação

Volta a testar o Enterprise SSID com um cliente ligado através do repeater.

Confirma:

• O cliente permanece associado
• radius_timeout deixa de aparecer para a tentativa
• 802.1X é concluído
• O cliente é colocado na VLAN esperada
• DHCP atribui um endereço
• O acesso de rede esperado fica disponível
• NPS regista um resultado normal de autenticação quando auditing está ativo

Exemplo:

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

Rollback / recovery

Se o novo RADIUS Client utilizar o source IP errado ou tiver sido criado por engano:

1. Remove ou desativa a entrada NPS RADIUS Client incorreta.
2. Confirma o RADIUS source address real através de packet capture.
3. Recria a entrada com o endereço e shared secret corretos.

Adicionar um range demasiado amplo de RADIUS Clients pode confiar involuntariamente em mais network access servers do que o pretendido. Prefere entradas explícitas de AP/NAS, a menos que um desenho por range seja deliberado e documentado.

Prevenção / boas práticas

• Adiciona o requisito RADIUS/NAS ao checklist de deployment dos APs
• Documenta cada gateway AP management IP utilizado para RADIUS
• Atualiza o NPS sempre que um AP management IP ou management VLAN muda
• Verifica NPS RADIUS Clients depois de substituir ou reendereçar gateway APs
• Trata mesh repeaters de forma diferente de wired APs durante troubleshooting 802.1X
• Compara APs que funcionam com APs que falham, em vez de testar apenas um endpoint
• Utiliza o teste RADIUS do Meraki para perceber se as falhas são globais ou específicas de alguns APs
• Valida o source IP RADIUS real quando AMI está ativa
• Mantém o RADIUS shared secret consistente e protegido
• Não faças troubleshooting de DHCP antes de a autenticação 802.1X estar concluída

Sequência rápida de diagnóstico

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.

Artigos relacionados

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

Fontes

Consulta as referências oficiais da Cisco Meraki e Microsoft indicadas nos metadados do artigo.