A autenticação Portal falha de duas formas muito diferentes — a página de login nunca aparece, ou aparece e rejeita uma senha que na verdade está correta — e cada uma vive em um elo diferente da mesma cadeia: terminal, dispositivo de acesso, servidor Portal, servidor RADIUS. Esta é a ordem que encontra qual elo está realmente quebrado, os comandos display e debugging para cada um, e as causas que aparecem repetidamente em campo.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026
'Autenticação falhou' pode significar quatro coisas completamente diferentes, dependendo de qual dos quatro elos da cadeia realmente quebrou.
Um usuário liga dizendo que o login do Portal não funciona, e essa única frase cobre pelo menos duas falhas estruturalmente diferentes: a página de autenticação nunca aparece, ou aparece, aceita um usuário e senha, e retorna autenticação falhou mesmo com as credenciais corretas. Tratar o segundo problema com correções para o primeiro — e vice-versa — desperdiça uma chamada de suporte. A cadeia que realmente precisa funcionar, em ordem, é o terminal, o dispositivo de acesso atuando como cliente Portal/RADIUS, o servidor Portal, e o servidor RADIUS por trás dele.
A seguir está essa cadeia, as verificações e os comandos exatos para cada elo, quatro causas raiz que respondem pela maioria desses chamados em campo, e cinco respostas de perguntas frequentes tiradas de casos reais de Portal/RADIUS.
Todo chamado de Portal/RADIUS cai primeiro em uma dessas duas formas antes de cair em um dos quatro elos — classifique isso primeiro.
O diagrama abaixo situa a falha na árvore antes de mexer em qualquer configuração: se a página sequer aparece, ou se aparece e depois rejeita o login.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Uma página que não é enviada e um login que o RADIUS realmente aprovou mas o cliente ainda vê como rejeitado não são a mesma falha, e não se corrigem com o mesmo comando. Classifique primeiro o chamado nesta árvore, depois trabalhe o elo correspondente abaixo.
Quatro elos, quatro ferramentas diferentes — comandos display para o que é basicamente verificação de configuração, debugging para o que precisa ser capturado ao vivo.
Se a página de login nunca aparece, não presuma ainda que o Portal está quebrado — confirme primeiro o lado do terminal.
C:\Users\****> ipconfig
// confirms the terminal actually has an IP address before Portal is even in the picture
C:\Users\****> ping <dns-server-address>
// if this fails, no Portal page can load -- the client can't resolve anything yet
<Huawei> display portal free-rule
// confirm the DNS server's address is in the free-rule list, or unauthenticated
// traffic to it gets blocked before Portal ever gets a chance to push the pageO caso por trás desta seção: um AC implantado à parte (modo bypass), gerenciando dispositivos de acesso na camada 3, com um servidor Portal de terceiros do outro lado desse salto de camada 3.
<Huawei> display version
<Huawei> display device
// confirms software version ARV200R005+ and board-loading status before anything else
# AC-side Portal server configuration for this case:
web-auth-server portal
server-ip 192.168.6.16
port 50100
shared-key cipher %^%#4R7w%QsKY9F#4DJUyq]V}$V-%^%#
url http://192.168.6.16:8080/portal
source-ip 192.168.11.1
<Huawei> debugging web packet
// HTTP auth packets never reaching the AC in a Layer-3 access deployment
// is exactly what stops the page from popping up on its own
[Huawei] tunnel-forward protocol http
// enables tunnel forwarding for HTTP authentication packets across the L3 hopOs logs do RADIUS podem dizer aceito enquanto o cliente ainda vê autenticação falhou — o dispositivo está rejeitando a própria resposta de autorização, não as credenciais.
<Huawei> debugging aaa all
2014 03:51:21.199.3+00:00 Huawei AAA/7/DEBUG:
[AAA ERROR]The corresponding ip is invalid or not configured.
// device rejected the RADIUS server's authorization response outright
<Huawei> system-view
[Huawei] radius-server template test1
[Huawei-radius-test1] radius-server attribute translate
[Huawei-radius-test1] radius-attribute disable Framed-IP-Netmask receive
// stop the device from parsing Framed-IP-Netmask out of the RADIUS response
<Huawei> display access-user user-id 1099
Basic:
User ID: 1099
User name: test011
Domain-name: 123
User MAC: 4487-fc40-f05b
User IP address: 13.13.13.250
User access Interface: Wlan-Bss1
User access time: 2014/09/20 10:05:39
User access type: WEB
AAA:
User authentication type: WEB authentication
Current authentication method: RADIUS
Current accounting method: RADIUS
// a real IP address and an active session confirm the fix workedÀs vezes o RADIUS está certo, os pacotes do Portal estão fluindo, e o cliente ainda vê autenticação falhou — porque a própria placa de interface não consegue concluir a troca.
<Huawei> display web-auth-server configuration
// confirms Portal server IP and which local interface reaches it
#
radius-server template rd1
radius-server shared-key cipher %^%#%f&o@nS,(WOKb5L-g0:(>}(l%^%#
radius-server authentication 192.168.30.250 1812 weight 80
radius-server accounting 192.168.30.250 1813 weight 80
radius-server retransmit 2
undo radius-server user-name domain-included
#
web-auth-server portal server-ip 192.168.30.250 port 50100 shared-key cipher %^%#0w/^)`Wj-S&rq\1da@)S>xG)%^%# url http://192.168.30.250:9098
<Huawei> debugging portal all
<Huawei> debugging web all
<Huawei> debugging cm all
<Huawei> debugging aaa all
<Huawei> debugging radius all
<Huawei> terminal monitor
<Huawei> terminal debugging
<Huawei> debugging timeout 0
Sep 17 2015 12:37:08.925.31+00:00 Huawei WEB/7/DEBUG:
Sent packet to socket (length = 16 ):
Version : 1
Type : authentication ack
Method : chap
SerialNo : 14223
RequestID : 22
UserIP : 192.168.20.245
ErrorCode : 4
AttributeNumber : 0
// device sent this ack toward the Portal server -- no ack of authentication ack
// ever came back, so the device times out the exchange and reports failure
<Huawei> display device
// board type on this interface was 4ES2G-S -- doesn't support NAC/Portal at allDepois que o elo acima indicar para onde olhar, essas quatro respondem pela maior parte do que realmente está errado.
SINTOMAA página de login aparece bem quando um cliente acessa diretamente a URL exata de envio, mas nunca aparece sozinha quando o cliente simplesmente abre um navegador e tenta acessar qualquer endereço.
CAUSAEm uma implantação AC em modo bypass gerenciando dispositivos de acesso através de um verdadeiro salto de camada 3, os pacotes de autenticação HTTP do Portal são encapsulados por padrão para encaminhamento de camada 2. Esse encapsulamento não sobrevive a uma fronteira real de camada 3, então os pacotes nunca chegam ao AC e o redirecionamento para a página de autenticação nunca acontece.
SOLUÇÃOHabilite o encaminhamento em túnel dos pacotes de autenticação HTTP para que sobrevivam ao salto de camada 3 entre o dispositivo de acesso e o AC.
[Huawei] tunnel-forward protocol httpSINTOMAdebugging aaa all mostra um AAA ERROR no momento em que o dispositivo processa a resposta de autorização do servidor RADIUS, e o cliente vê autenticação falhou mesmo com usuário e senha corretos.
CAUSANesses dispositivos de acesso, Framed-IP-Netmask só é válido em conjunto com Framed-IP-Address na mesma resposta. Um servidor RADIUS construído principalmente para equipamentos de outro fabricante pode enviar a máscara sem o endereço — perfeitamente válido lá, inválido aqui — e o dispositivo trata toda a autorização como portadora de um IP inválido.
SOLUÇÃOAdicione o Framed-IP-Address ausente no servidor RADIUS, ou diga ao dispositivo para ignorar Framed-IP-Netmask ao receber.
[Huawei-radius-test1] radius-attribute disable Framed-IP-Netmask receiveSINTOMAO próprio log do servidor RADIUS confirma o login como aceito, o dispositivo até envia um authentication-ack para o servidor Portal, mas o cliente ainda assim acaba vendo autenticação falhou.
CAUSAUm punhado de placas de acesso — 4GE-2S, 4ES2G-S, 4ES2GP-S, 9ES2 — não suporta NAC, o framework sobre o qual a autenticação Portal roda. Encerrar uma sessão Portal em uma delas significa que o servidor Portal nunca recebe um ack sobre o qual agir, por mais correta que seja a configuração de RADIUS e Portal.
SOLUÇÃOMova a interface autenticada pelo Portal para uma placa que suporte NAC, como 8FE1GE ou 24GE.
<Huawei> display device
// confirm the board type behind the Portal-authenticated interface before ordering a swapSINTOMAO terminal não consegue alcançar absolutamente nada antes de autenticar, incluindo a própria página de login, e um ping ao servidor DNS a partir do terminal expira.
CAUSATudo o que um cliente envia antes de autenticar é bloqueado, exceto o que está explicitamente listado na regra livre do Portal. Se o endereço do servidor DNS não estiver nessa lista, o terminal não consegue resolver o endereço necessário para alcançar a URL de envio, então o redirecionamento nem sequer obtém um destino.
SOLUÇÃOAdicione o endereço do servidor DNS à lista de regras livres para que a resolução DNS funcione antes de a autenticação ser concluída.
<Huawei> display portal free-rule
// confirm the DNS server's address is present before looking anywhere elseTiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Esse é um problema de roteamento do envio de página, não de credenciais — quase sempre pacotes de autenticação HTTP que não sobrevivem a um salto de camada 3 entre o dispositivo de acesso e o AC em uma implantação bypass. Confirme com debugging web packet, depois habilite o encaminhamento em túnel dos pacotes HTTP.
A jusante do RADIUS, entre o dispositivo e o servidor Portal. Ative juntos debugging portal all, debugging web all, debugging cm all, debugging aaa all e debugging radius all e procure um authentication-ack enviado pelo dispositivo que nunca recebeu confirmação — é isso que o cliente vê como falha. Se esse lado parecer limpo, verifique se a placa que encerra a sessão sequer suporta NAC.
Porque o dispositivo verificou o endereço IP com o qual o servidor RADIUS autorizou a sessão, e o rejeitou — não as credenciais em si. Nesses dispositivos de acesso, Framed-IP-Netmask só funciona em conjunto com Framed-IP-Address; uma resposta RADIUS com a máscara e sem o endereço é marcada como inválida, e parece exatamente uma falha de login do lado do terminal.
4GE-2S, 4ES2G-S, 4ES2GP-S e 9ES2 não suportam NAC, do qual a autenticação Portal depende. Se uma sessão Portal termina em uma delas, nenhuma configuração correta de RADIUS ou Portal fará ela se completar — a solução é mover a interface para uma placa como 8FE1GE ou 24GE que suporte NAC.
Se a página aparece ou não, e se digitar diretamente a URL exata de envio muda isso; o próprio log do servidor RADIUS para essa tentativa de login; e — se a página apareceu — uma captura de debugging aaa all / debugging portal all a partir do momento em que as credenciais são enviadas. Esses três respondem quase todas as perguntas de roteamento antes mesmo de alguém abrir a configuração do dispositivo.
Esta nota se baseia em roteadores Huawei série AR atuando como dispositivos de acesso Portal/RADIUS, e nos casos de campo por trás de display access-user, debugging aaa/portal/web/cm/radius all, e na regra de pareamento específica da AR Framed-IP-Netmask / Framed-IP-Address. Se o seu dispositivo de acesso for de outro fabricante, os comandos exatos e as particularidades de atributos mudam, mas a ordem de diagnóstico de quatro elos — terminal, dispositivo, servidor Portal, RADIUS — se aplica diretamente. Não cobre em profundidade 802.1X ou bypass de autenticação MAC, nem servidores Portal rodando totalmente na nuvem em vez de on-premises.
Conte-nos se a página aparece ou não, o que o próprio log do servidor RADIUS diz sobre a tentativa, e ajudamos você a encontrar qual elo realmente quebrou.