Erro “invalid RADIUS client IP” no Duo Authentication Proxy: como corrigir (guia completo)

Ao configurar o Duo Authentication Proxy como servidor RADIUS, é comum receber “a RADIUS message was received from invalid RADIUS client IP”. Este guia prático mostra como identificar o IP real de origem, ajustar o authproxy.cfg, validar o segredo compartilhado e normalizar portas e conectividade.

Índice

Visão geral do erro

O erro “a RADIUS message was received from invalid RADIUS client IP” indica que o Duo Authentication Proxy recebeu um pacote RADIUS de um endereço IP que não está autorizado no arquivo de configuração authproxy.cfg. Em outras palavras, o proxy está de pé, recebeu o tráfego, mas recusou o pedido por não reconhecer o emissor.

Na prática, isso acontece quando:

O IP cadastrado não corresponde ao IP que realmente chega ao Duo (comum em redes com NAT, VIP de balanceador ou múltiplas interfaces no equipamento);
O segredo RADIUS (shared secret) não coincide;
O dispositivo usa porta legada 1645/1646 enquanto o Duo aguarda em 1812/1813, ou vice-versa;
Há bloqueio de UDP 1812/1813 (ou 1645/1646) por firewall/ACL.

Como o cenário RADIUS com Duo funciona (resumo)

Um dispositivo (NAS/AAA — firewall, VPN, Wi‑Fi, switch, etc.) envia um Access-Request RADIUS ao Duo Authentication Proxy. O Proxy valida remetente e segredo; se aprovados, processa a autenticação (conforme modo auto/challenge, LDAP/AD, e integração Duo Cloud). Se o IP de origem não estiver listado, ocorre o erro de cliente inválido.

Diagnóstico e correção — passo a passo

Confirmar o IP real que chega ao Proxy

Antes de alterar qualquer coisa, confirme qual IP o Duo está vendo como origem. Verifique os logs do Authentication Proxy e, se necessário, ative depuração:

Windows: C:\Program Files\Duo Security Authentication Proxy\log\authproxy.log
Linux: /opt/duoauthproxy/log/authproxy.log

Para logs mais verbosos, no authproxy.cfg adicione debug=true e reinicie o serviço.

# Exemplo de mensagem típica nos logs (ilustrativo):
2025-09-10T12:34:56+00:00 [radiusserverauto] WARNING:
Received RADIUS request from unknown client 203.0.113.25: Access-Request

O IP mostrado nessa mensagem (203.0.113.25 no exemplo) é exatamente o que deve ser cadastrado como cliente RADIUS no authproxy.cfg. Em ambientes com NAT ou balanceador, este será o IP pós-NAT/VIP, e não o IP “interno” do dispositivo de rede.

Cadastrar o(s) IP(s) do(s) cliente(s) RADIUS no `authproxy.cfg`

Dentro do bloco do servidor RADIUS (por exemplo, [radiusserverauto] ou [radiusserverchallenge]), inclua o(s) IP(s) e o(s) segredo(s) correspondentes. Exemplo prático:

[radiusserverauto]
ikey=SEU_IKEY
skey=SEU_SKEY
apihost=SEUAPI_HOST
port=1812                    ; use 1645 se o dispositivo usar porta legada
radiusip1=10.10.10.5       ; IP que o proxy vê (pós-NAT/VIP se houver)
radiussecret1=SegredoForte
; radiusip2=10.10.20.6
; radiussecret2=OutroSegredo
debug=true

Importante: em cenários com NAT ou balanceamento, cadastre o IP pós‑NAT ou o IP do balanceador que aparece nos logs, e não o IP da interface do equipamento.

Garantir que o segredo compartilhado coincide

O segredo configurado no dispositivo/cliente (NAS/AAA) deve ser idêntico ao radiussecretX no Duo. Pequenos deslizes como espaço extra no fim, caracteres trocados ou um segredo diferente em cada lado são causas muito comuns de falha.

Copie/cole com cuidado e confirme o valor em ambos os lados;
Se possível, defina um segredo forte, com boa entropia, e guarde de forma segura.

Verificar portas e conectividade

O RADIUS utiliza UDP por padrão:

1812 Autenticação | 1813 Accounting;
Equipamentos antigos podem usar 1645/1646.

Testes úteis:

ping para reachability IP;
tracert/traceroute para rota;
radtest (Linux) para simular Access-Request:

# Em uma máquina que possa alcançar o Duo Proxy:
radtest usuario senha PROXY_IP:1812 0 SegredoForte

NTRadPing (Windows) a partir do cliente para um teste rápido de RADIUS;
Captura de pacotes (para confirmar portas/origens): # Linux (no host do Duo Proxy) sudo tcpdump -ni any udp port 1812 -vv Filtrar um cliente específico sudo tcpdump -ni any host 203.0.113.25 and udp port 1812 -vv

Revisar sintaxe e reiniciar o serviço

Após editar o authproxy.cfg, valide a sintaxe e reinicie o Duo Authentication Proxy.

Linux: sudo /opt/duoauthproxy/bin/authproxyctl restart
Windows: reinicie o serviço “Duo Security Authentication Proxy” (via services.msc).

Manter o Duo Authentication Proxy atualizado

Execute versões recentes do Proxy para garantir correções de bugs e compatibilidade com novos recursos. Planeje janela de manutenção e faça backup do authproxy.cfg antes de atualizar.

Checklist de correção rápida

Identifique no log o IP de origem real que chega ao Proxy;
Cadastre esse IP (pós‑NAT/VIP se houver) no authproxy.cfg com o segredo correto;
Confirme portas UDP abertas (1812/1813 ou 1645/1646 se legado);
Reinicie o serviço e repita o teste (radtest ou NTRadPing);
Monitore o authproxy.log para validar o aceite do cliente.

Tabela de referência rápida

Item	Valor/Exemplo	Observações
Log (Windows)	`C:\Program Files\Duo Security Authentication Proxy\log\authproxy.log`	Ative `debug=true` no `authproxy.cfg` para mais verbosidade.
Log (Linux)	`/opt/duoauthproxy/log/authproxy.log`	Verifique “unknown client” para descobrir o IP que chegou.
Portas padrão	UDP 1812 (Auth), UDP 1813 (Acct)	Legado: UDP 1645/1646.
Teste Linux	`radtest usuario senha PROXY_IP:1812 0 Segredo`	Útil para validar segredo e reachability.
Captura de pacotes	`tcpdump -ni any udp port 1812 -vv`	Confirma IP e porta realmente vistos pelo Proxy.
Reinício (Linux)	`/opt/duoauthproxy/bin/authproxyctl restart`	Após editar o arquivo de configuração.
Reinício (Windows)	Serviço “Duo Security Authentication Proxy”	Use services.msc ou PowerShell.

Entenda o papel do NAT e do balanceamento

Em muitas implantações, o dispositivo que origina o RADIUS (por exemplo, um firewall VPN) fica atrás de NAT ou envia tráfego via um balanceador de carga (L4/L7). Nesses casos, o IP de origem que chega ao Duo é alterado:

NAT de saída (SNAT): o IP que o Duo verá é o IP público/externo do gateway de saída;
Balanceador L4: normalmente o tráfego chega com IP de origem do próprio balanceador (Self-IP);
VIP: se o balanceador envia do VIP, será esse o IP visto nos logs.

Matriz de decisão — qual IP cadastrar

Cenário	IP a cadastrar	Dica
Dispositivo sem NAT direto ao Proxy	IP da interface do dispositivo	Confirme nos logs do Duo para evitar erros.
SNAT no firewall/roteador	IP pós‑NAT (endereço de saída)	O Duo verá o IP traduzido; cadastre esse.
Balanceador L4/L7	Self-IP do balanceador ou VIP (o que os logs mostrarem)	Use `tcpdump` para confirmar a origem real.
Equipamento com múltiplas interfaces	IP da interface usada para falar com o Proxy	O roteamento pode escolher outra interface; valide no log.

Exemplos completos de configuração

Modo automático com múltiplos clientes

[radiusserverauto]
ikey=SEU_IKEY
skey=SEU_SKEY
apihost=SEUAPI_HOST
port=1812

; Cliente 1 — pós-NAT (conforme log)
radius\ip\1=203.0.113.25
radius\secret\1=SegredoMuitoForte

; Cliente 2 — VPN concentrator
radius\ip\2=10.20.30.40
radius\secret\2=OutroSegredoForte

; Cliente 3 — Balanceador L4 (Self-IP)
radius\ip\3=198.51.100.10
radius\secret\3=TerceiroSegredo

; Mais parâmetros de integração (LDAP/AD) podem ser adicionados aqui.
debug=true

Modo challenge com porta legada

[radiusserverchallenge]
ikey=SEU_IKEY
skey=SEU_SKEY
apihost=SEUAPI_HOST
port=1645  ; dispositivo legado usando 1645

radius\ip\1=192.0.2.55
radius\secret\1=SegredoChallenge
debug=true

Verificações adicionais que evitam armadilhas

DNS reverso não é requisito para o aceite do cliente; a decisão é por IP literal cadastrado;
Não use hostname no campo radiusipX; cadastre o IP numérico;
Contagem de clientes: é possível cadastrar múltiplos radiusipX/radiussecretX (liste todos os necessários);
Firewall local: verifique políticas no host do Proxy (Windows Defender Firewall, iptables/ufw) permitindo UDP 1812/1813 (ou 1645/1646);
Roteamento/VRF: em servidores com múltiplas rotas/VRFs, confirme que a interface correta recebe e responde aos pacotes;
Persistência no LB: se existir, prefira afinar afinidade por IP/porta para reduzir intermitências.

Procedimento sugerido de teste ponta a ponta

Ativar debug=true e reiniciar o serviço;
Executar tcpdump (ou Wireshark) no servidor do Duo por 2–3 minutos;
Iniciar uma autenticação no cliente (por exemplo, tentativa de VPN);
Verificar no log a origem: “unknown client IP” (se aparecer);
Cadastrar esse IP em authproxy.cfg com o segredo correto;
Reiniciar o Duo Proxy e repetir a autenticação;
Confirmar nos logs Access-Accept ou fluxo de desafio Duo conforme o modo.

Erros comuns e como evitá-los

IP errado: equipamento com várias interfaces ou roteamento assimétrico; sempre valide o IP visto nos logs do Duo;
NAT em silêncio: o administrador cadastra o IP “real”, mas o pacote chega SNATado; cadastre o IP pós‑NAT;
Porta trocada: cliente fala 1645/1646, Proxy escuta 1812/1813; alinhe portas nos dois lados;
Segredo divergente: erro de digitação ou cópia parcial; recadastre o segredo de forma coordenada;
ACL bloqueando UDP: libere tráfego bidirecional entre cliente e Proxy nas portas corretas.

Comandos úteis e observabilidade

Linux

# Reiniciar o serviço
sudo /opt/duoauthproxy/bin/authproxyctl restart

Ver status

sudo /opt/duoauthproxy/bin/authproxyctl status

Seguir o log

sudo tail -f /opt/duoauthproxy/log/authproxy.log

Windows

# Reiniciar serviço (PowerShell elevado)
Restart-Service -Name "Duo Security Authentication Proxy" -Force

Ver estado

Get-Service -Name "Duo Security Authentication Proxy"

FAQ — perguntas frequentes

Posso cadastrar uma faixa (CIDR) de IPs?
Não. Cadastre IPs individuais com radiusip1, radiusip2, etc. Liste somente os endereços realmente necessários.

O segredo pode ter caracteres especiais?
Sim, mas evite espaços à direita e cuidado ao copiar/colar. Garanta que o valor seja idêntico nos dois lados.

Preciso abrir TCP 1812/1813?
O RADIUS usa UDP por padrão. Algumas ferramentas de teste verificam apenas TCP; para UDP, prefira captura de pacotes e testes RADIUS reais.

O Duo suporta IPv6 neste contexto?
Na maioria dos cenários práticos usa-se IPv4. Se adotar IPv6, padronize o design e valide cuidadosamente origem/rotas/ACL.

Boas práticas para produção

Documente cada radiusipX com o sistema correspondente (VPN, Wi‑Fi, etc.);
Padronize o segredo por cliente e rotacione periodicamente; evite reaproveitar o mesmo em todos os dispositivos;
Implemente monitoramento dos logs do Duo (ingestão centralizada) para alertar sobre “unknown client” e queda de respostas;
Planeje redundância do Proxy (ativos em pares) e persistência no LB, quando aplicável;
Mantenha o Proxy atualizado, com authproxy.cfg versionado/backup.

Exemplo de playbook de mudança

Backup do authproxy.cfg e dos segredos (cofre);
Janela de manutenção aprovada;
Log em nível debug=true temporariamente;
Aplicar cadastros radiusipX/radiussecretX conforme IPs observados;
Reiniciar o serviço e executar baterias de teste (radtest e autenticações reais);
Reverter debug=false após estabilizar;
Atualizar documentação e diagrama de fluxo RADIUS/NAT/LB.

Resultado esperado

Depois de cadastrar o IP correto do cliente (levando em conta NAT/LB), alinhar o segredo compartilhado e liberar as portas UDP adequadas, o Duo Authentication Proxy passará a aceitar as mensagens RADIUS e as autenticações ocorrerão normalmente. Os logs deixarão de exibir “unknown client” e apresentarão registros de Access-Request seguidos de respostas esperadas (Access-Accept / desafios Duo conforme a configuração).

Resumo executivo

A raiz do problema está quase sempre no IP de origem incorreto listado no authproxy.cfg — típico de ambientes com NAT/balanceadores ou dispositivos com múltiplas interfaces. O caminho seguro é: olhe o log → descubra o IP que realmente chegou → cadastre esse IP com o segredo certo → valide portas → reinicie e teste. Seguindo este roteiro, a mensagem “invalid RADIUS client IP” desaparece e o ambiente volta a autenticar sem fricção.