Inicio / Notas técnicas / Resolución de problemas de autenticación Portal

La autenticación Portal falla en routers empresariales: resolución de problemas de RADIUS y envío de página

La autenticación Portal falla de dos maneras muy distintas — la página de inicio de sesión nunca aparece, o aparece y rechaza una contraseña que en realidad es correcta — y cada una vive en un eslabón distinto de la misma cadena: terminal, dispositivo de acceso, servidor Portal, servidor RADIUS. Este es el orden que encuentra qué eslabón está realmente roto, los comandos display y debugging para cada uno, y las causas que aparecen una y otra vez en el campo.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Por qué el reporte del síntoma nunca dice qué eslabón está roto

'Autenticación fallida' puede significar cuatro cosas completamente distintas, según cuál de los cuatro eslabones de la cadena sea el que realmente falló.

Un usuario llama diciendo que el inicio de sesión Portal no funciona, y esa sola frase abarca al menos dos fallas estructuralmente distintas: la página de autenticación nunca aparece, o aparece, acepta un usuario y una contraseña, y responde con autenticación fallida aunque las credenciales sean correctas. Tratar el segundo problema con soluciones para el primero — y viceversa — desperdicia una llamada de soporte. La cadena que realmente tiene que funcionar, en orden, es el terminal, el dispositivo de acceso actuando como cliente Portal/RADIUS, el servidor Portal, y el servidor RADIUS detrás de él.

A continuación, esa cadena, las comprobaciones y los comandos exactos para cada eslabón, cuatro causas raíz que explican la mayoría de estos casos en el campo, y cinco respuestas de preguntas frecuentes extraídas de casos reales de Portal/RADIUS.

Cuatro eslabones, dos formas de falla

Todo caso de Portal/RADIUS cae primero en una de estas dos formas antes de caer en uno de los cuatro eslabones — clasifíquelo ahí primero.

El siguiente diagrama ubica la falla en el árbol antes de tocar cualquier configuración: si la página siquiera aparece, o si aparece y luego rechaza el inicio de sesión.

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Una página que no se envía y un inicio de sesión que RADIUS realmente aprobó pero el cliente sigue viendo como rechazado no son la misma falla, y no se corrigen con el mismo comando. Clasifique primero el caso en este árbol, luego trabaje el eslabón correspondiente a continuación.

Recorriendo cada eslabón

Cuatro eslabones, cuatro herramientas distintas — comandos display para lo que es básicamente verificación de configuración, debugging para lo que hay que capturar en vivo.

Eslabón 1 — Confirmar que el terminal realmente alcanza el dispositivo y el DNS

Si la página de inicio de sesión nunca aparece, no asuma todavía que Portal está roto — confirme primero el lado del terminal.

Ejecute ipconfig en el terminal para confirmar que realmente tiene una dirección IP antes de culpar a Portal en absoluto.
Haga ping al servidor DNS desde el terminal. Si falla, ninguna página Portal de ningún tipo va a cargar, porque el cliente no puede resolver la dirección que intenta alcanzar.
Revise display portal free-rule en el dispositivo. La dirección del servidor DNS tiene que estar en esa lista de reglas libres, o el tráfico no autenticado hacia ella se bloquea antes de que Portal siquiera tenga oportunidad de enviar algo.

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 page

Eslabón 2 — Del dispositivo al servidor Portal: por qué la página no se envía

El caso detrás de esta sección: un AC desplegado al margen (modo bypass), gestionando dispositivos de acceso en la capa 3, con un servidor Portal de terceros al otro lado de ese salto de capa 3.

Confirme primero la versión de software del dispositivo y el estado de carga de las tarjetas con display version y display device — este caso necesitaba ARV200R005 o posterior solo para que la autenticación Portal de capa 3 fuera compatible.
Confirme el modo de autenticación realmente desplegado: autenticación Portal de capa 3, con el AC al margen de los dispositivos de acceso en lugar de estar directamente en la ruta.
Ejecute debugging web packet mientras un cliente intenta iniciar sesión. Si los paquetes HTTP de Portal nunca se reenvían al AC en tránsito, esa es la razón por la que el terminal nunca ve la página de autenticación — escribir directamente la URL exacta de envío sigue funcionando porque no depende de esa ruta de reenvío.
Habilite tunnel-forward protocol http para que los paquetes de autenticación HTTP sobrevivan al salto de capa 3 entre el dispositivo de acceso y el AC.

<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 hop

Eslabón 3 — Del dispositivo al RADIUS: interpretar un rechazo de atributo

Los registros de RADIUS pueden decir aceptado mientras el cliente sigue viendo autenticación fallida — el dispositivo está rechazando la propia respuesta de autorización, no las credenciales.

Active debugging aaa all y observe qué regresa en el momento en que el dispositivo recibe la respuesta de autorización del servidor RADIUS.
Un AAA ERROR que reporta que la IP correspondiente es inválida o no está configurada significa que el dispositivo rechazó de plano la dirección IP de esa respuesta. En estos dispositivos de acceso, Framed-IP-Netmask solo es válido junto con Framed-IP-Address — nunca solo.
Si la respuesta RADIUS lleva Framed-IP-Netmask sin Framed-IP-Address, agregue el atributo faltante en el servidor RADIUS, o indique al dispositivo que deje de analizar Framed-IP-Netmask en la respuesta por completo.
Confirme la corrección con display access-user — una dirección IP asignada real y una sesión activa confirman que el cliente realmente pasó esta vez.

<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

Eslabón 4 — Hardware del dispositivo: tarjetas compatibles con NAC y el ack del servidor Portal

A veces RADIUS está bien, los paquetes de Portal fluyen, y el cliente aun así ve autenticación fallida — porque la propia tarjeta de interfaz no puede completar el intercambio.

Confirme con display web-auth-server configuration que la IP del servidor Portal y la interfaz local que lo alcanza realmente coinciden con lo esperado.
Si los propios registros del servidor RADIUS ya muestran el inicio de sesión como aceptado, las credenciales y el enlace RADIUS están bien — la falla está más adelante, entre el dispositivo y el servidor Portal.
Active juntos debugging portal all, debugging web all, debugging cm all, debugging aaa all y debugging radius all, junto con terminal monitor, terminal debugging y debugging timeout 0, y luego vuelva a iniciar sesión desde el cliente.
Busque un paquete Type: authentication ack que el dispositivo envió hacia el servidor Portal. Si nunca llega un ack of authentication ack correspondiente, el dispositivo considera que el intercambio expiró y reporta autenticación fallida — aunque RADIUS ya había aprobado el inicio de sesión.
Revise display device para ver la tarjeta que realmente termina la sesión Portal. 4GE-2S, 4ES2G-S, 4ES2GP-S y 9ES2 no admiten NAC en absoluto, y la autenticación Portal simplemente no puede completarse en ellas sin importar qué tan correcta sea el resto de la configuración.

<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 all

4 causas raíz que aparecen una y otra vez

Una vez que el eslabón anterior le indica hacia dónde mirar, estas cuatro explican la mayoría de lo que realmente está mal.

1. Los paquetes de autenticación HTTP no se reenvían por túnel en un despliegue AC de capa 3

SÍNTOMALa página de inicio de sesión aparece bien cuando un cliente accede directamente a la URL exacta de envío, pero nunca aparece por sí sola cuando el cliente simplemente abre un navegador e intenta llegar a cualquier dirección.

CAUSAEn un despliegue AC en modo bypass que gestiona dispositivos de acceso a través de un verdadero salto de capa 3, los paquetes de autenticación HTTP de Portal se encapsulan por defecto para reenvío de capa 2. Esa encapsulación no sobrevive una frontera real de capa 3, así que los paquetes nunca llegan al AC y la redirección a la página de autenticación nunca ocurre.

SOLUCIÓNHabilite el reenvío por túnel de los paquetes de autenticación HTTP para que sobrevivan al salto de capa 3 entre el dispositivo de acceso y el AC.

[Huawei] tunnel-forward protocol http

2. RADIUS envía Framed-IP-Netmask sin Framed-IP-Address

SÍNTOMAdebugging aaa all muestra un AAA ERROR en el momento en que el dispositivo procesa la respuesta de autorización del servidor RADIUS, y el cliente ve autenticación fallida aunque el usuario y la contraseña fueran correctos.

CAUSAEn estos dispositivos de acceso, Framed-IP-Netmask solo es válido junto con Framed-IP-Address en la misma respuesta. Un servidor RADIUS diseñado principalmente para equipos de otro fabricante puede enviar la máscara sin la dirección — perfectamente válido allá, inválido aquí — y el dispositivo trata toda la autorización como portadora de una IP inválida.

SOLUCIÓNAgregue el Framed-IP-Address faltante en el servidor RADIUS, o indique al dispositivo que ignore Framed-IP-Netmask al recibirlo.

[Huawei-radius-test1] radius-attribute disable Framed-IP-Netmask receive

3. La tarjeta de acceso no admite NAC — Portal no puede completarse sin importar qué más esté bien

SÍNTOMAEl propio registro del servidor RADIUS confirma que el inicio de sesión fue aceptado, el dispositivo incluso envía un authentication-ack hacia el servidor Portal, pero el cliente igual termina viendo autenticación fallida.

CAUSAUn puñado de tarjetas de acceso — 4GE-2S, 4ES2G-S, 4ES2GP-S, 9ES2 — no admiten NAC, el marco sobre el que corre la autenticación Portal. Terminar una sesión Portal en una de ellas significa que el servidor Portal nunca recibe un ack sobre el cual actuar, sin importar cuán correcta sea la configuración de RADIUS y Portal.

SOLUCIÓNTraslade la interfaz autenticada por Portal a una tarjeta que admita NAC, como 8FE1GE o 24GE.

<Huawei> display device
// confirm the board type behind the Portal-authenticated interface before ordering a swap

4. A la lista de reglas libres le falta el servidor DNS — la página nunca tiene oportunidad de cargar

SÍNTOMAEl terminal no puede alcanzar absolutamente nada antes de autenticarse, incluyendo la propia página de inicio de sesión, y un ping al servidor DNS desde el terminal expira.

CAUSATodo lo que un cliente envía antes de autenticarse se bloquea excepto lo que figura explícitamente en la regla libre de Portal. Si la dirección del servidor DNS no está en esa lista, el terminal no puede resolver la dirección que necesita para alcanzar la URL de envío, así que la redirección ni siquiera obtiene un destino.

SOLUCIÓNAgregue la dirección del servidor DNS a la lista de reglas libres para que la resolución DNS funcione antes de completar la autenticación.

<Huawei> display portal free-rule
// confirm the DNS server's address is present before looking anywhere else

Cinco preguntas que surgen constantemente

Extraídas directamente del campo — las que vale la pena tener respondidas de antemano.

La página aparece bien si escribo la URL de envío directamente, pero nunca aparece por sí sola — ¿qué está pasando?

Ese es un problema de enrutamiento del envío de página, no de credenciales — casi siempre paquetes de autenticación HTTP que no sobreviven un salto de capa 3 entre el dispositivo de acceso y el AC en un despliegue bypass. Confirme con debugging web packet, luego habilite el reenvío por túnel de los paquetes HTTP.

Los registros de RADIUS muestran el inicio de sesión como aceptado, pero el cliente sigue viendo autenticación fallida — ¿dónde debo mirar?

Aguas abajo de RADIUS, entre el dispositivo y el servidor Portal. Active juntos debugging portal all, debugging web all, debugging cm all, debugging aaa all y debugging radius all y busque un authentication-ack enviado por el dispositivo que nunca recibió confirmación — eso es lo que el cliente ve como fallo. Si ese lado se ve limpio, revise si la tarjeta que termina la sesión siquiera admite NAC.

¿Por qué un usuario y contraseña escritos correctamente devolverían un error de IP inválida?

Porque el dispositivo verificó la dirección IP con la que el servidor RADIUS autorizó la sesión, y la rechazó — no las credenciales en sí. En estos dispositivos de acceso, Framed-IP-Netmask solo funciona junto con Framed-IP-Address; una respuesta RADIUS con la máscara y sin dirección se marca como inválida, y se ve exactamente como un fallo de inicio de sesión desde el lado del terminal.

¿Qué tarjetas de acceso no pueden hacer autenticación Portal en absoluto?

4GE-2S, 4ES2G-S, 4ES2GP-S y 9ES2 no admiten NAC, del cual depende la autenticación Portal. Si una sesión Portal termina en una de ellas, ninguna configuración correcta de RADIUS o Portal la hará completarse — la solución es trasladar la interfaz a una tarjeta como 8FE1GE o 24GE que sí admita NAC.

¿Qué debo capturar realmente antes de abrir un caso de autenticación Portal?

Si la página aparece o no, y si escribir directamente la URL exacta de envío cambia eso; el propio registro del servidor RADIUS para ese intento de inicio de sesión; y — si la página sí apareció — una captura de debugging aaa all / debugging portal all desde el momento en que se envían las credenciales. Esos tres elementos responden casi todas las preguntas de enrutamiento antes de que alguien abra siquiera la configuración del dispositivo.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se basa en routers Huawei serie AR actuando como dispositivos de acceso Portal/RADIUS, y en los casos de campo detrás de display access-user, debugging aaa/portal/web/cm/radius all, y la regla de emparejamiento específica de AR Framed-IP-Netmask / Framed-IP-Address. Si su dispositivo de acceso es de otro fabricante, los comandos exactos y las particularidades de atributos cambian, pero el orden de diagnóstico de cuatro eslabones — terminal, dispositivo, servidor Portal, RADIUS — se traslada directamente. No cubre en profundidad 802.1X ni la omisión de autenticación MAC, ni servidores Portal que funcionen completamente en la nube en lugar de en sitio.

¿Atascado con un inicio de sesión Portal que no autentica?

Cuéntenos si la página aparece o no, qué dice el propio registro del servidor RADIUS sobre el intento, y le ayudaremos a encontrar qué eslabón realmente falló.

WhatsApp con un ingeniero →