Accueil / Notes techniques / Dépannage de l'authentification Portal

L'authentification Portal échoue sur les routeurs d'entreprise : dépannage RADIUS et push de page

L'authentification Portal échoue de deux façons très différentes — la page de connexion n'apparaît jamais, ou elle apparaît et rejette un mot de passe pourtant correct — et chacune se situe sur un maillon différent de la même chaîne : terminal, équipement d'accès, serveur Portal, serveur RADIUS. Voici l'ordre qui permet de trouver le maillon réellement en cause, les commandes display et debugging pour chacun, et les causes qui reviennent sans cesse sur le terrain.

Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026

Pourquoi le signalement du symptôme ne dit jamais quel maillon est cassé

« Authentification échouée » peut recouvrir quatre situations totalement différentes, selon lequel des quatre maillons de la chaîne est réellement en cause.

Un utilisateur appelle en disant « la connexion Portal ne fonctionne pas », et cette seule phrase recouvre au moins deux pannes structurellement différentes : la page d'authentification n'apparaît jamais, ou elle apparaît, accepte un nom d'utilisateur et un mot de passe, puis renvoie authentification échouée alors que les identifiants sont corrects. Traiter le second problème avec les correctifs du premier — et inversement — fait perdre un appel de support pour rien. La chaîne qui doit réellement fonctionner, dans l'ordre, est le terminal, l'équipement d'accès agissant comme client Portal/RADIUS, le serveur Portal, puis le serveur RADIUS derrière.

Voici cette chaîne, les vérifications et les commandes exactes pour chaque maillon, quatre causes racines qui expliquent la plupart de ces tickets sur le terrain, et cinq réponses de FAQ tirées de cas réels Portal/RADIUS.

Quatre maillons, deux formes de panne

Chaque ticket Portal/RADIUS relève d'abord de l'une de ces deux formes avant de relever de l'un des quatre maillons — commencez par ce tri.

Le schéma ci-dessous situe la panne sur l'arbre avant de toucher à la moindre configuration : la page apparaît-elle seulement, ou apparaît-elle puis rejette-t-elle la connexion.

Les légendes du schéma restent en anglais pour la clarté technique.

Une page qui ne se pousse pas et une connexion que RADIUS a réellement approuvée mais que le client voit toujours rejetée ne sont pas la même panne, et ne se corrigent pas avec la même commande. Classez d'abord le ticket sur cet arbre, puis traitez le maillon correspondant ci-dessous.

Parcourir chaque maillon

Quatre maillons, quatre outils différents — des commandes display pour les vérifications de configuration, du debugging pour ce qui doit être capturé en direct.

Maillon 1 — Confirmer que le terminal atteint bien l'équipement et le DNS

Si la page de connexion n'apparaît jamais, ne supposez pas encore que Portal est cassé — confirmez d'abord le côté terminal.

Exécutez ipconfig sur le terminal pour confirmer qu'il possède bien une adresse IP avant même de blâmer Portal.
Pinguez le serveur DNS depuis le terminal. Si cela échoue, aucune page Portal ne se chargera, quelle qu'elle soit, car le client ne peut résoudre l'adresse qu'il tente d'atteindre.
Vérifiez display portal free-rule sur l'équipement. L'adresse du serveur DNS doit figurer dans cette liste de règles sans authentification, sinon le trafic non authentifié vers elle est bloqué avant même que Portal n'ait la moindre chance de pousser quoi que ce soit.

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

Maillon 2 — De l'équipement au serveur Portal : pourquoi la page ne se pousse pas

Le cas derrière cette section : un AC déployé en dérivation (mode bypass), gérant des équipements d'accès en couche 3, avec un serveur Portal tiers de l'autre côté de ce saut de couche 3.

Confirmez d'abord la version logicielle de l'équipement et l'état de chargement des cartes avec display version et display device — ce cas nécessitait ARV200R005 ou une version ultérieure rien que pour que l'authentification Portal en couche 3 soit supportée.
Confirmez le mode d'authentification réellement déployé : authentification Portal en couche 3, avec l'AC en dérivation par rapport aux équipements d'accès plutôt que directement dans le chemin.
Exécutez debugging web packet pendant qu'un client tente de se connecter. Si les paquets HTTP de Portal ne sont jamais transmis à l'AC en transit, voilà pourquoi le terminal ne voit jamais la page d'authentification — saisir directement l'URL exacte de push fonctionne toujours car cela ne dépend pas de ce chemin de transmission.
Activez tunnel-forward protocol http pour que les paquets d'authentification HTTP survivent au saut de couche 3 entre l'équipement d'accès et l'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

Maillon 3 — De l'équipement au RADIUS : lire un rejet d'attribut

Les journaux RADIUS peuvent indiquer accepté alors que le client voit toujours authentification échouée — l'équipement rejette la réponse d'autorisation elle-même, pas les identifiants.

Activez debugging aaa all et observez ce qui revient dès que l'équipement reçoit la réponse d'autorisation du serveur RADIUS.
Une AAA ERROR signalant que l'IP correspondante est invalide ou non configurée signifie que l'équipement a purement rejeté l'adresse IP de cette réponse. Sur ces équipements d'accès, Framed-IP-Netmask n'est valide qu'associé à Framed-IP-Address — jamais seul.
Si la réponse RADIUS porte Framed-IP-Netmask sans Framed-IP-Address, ajoutez l'attribut manquant sur le serveur RADIUS, ou demandez à l'équipement de cesser complètement d'analyser Framed-IP-Netmask dans la réponse.
Confirmez la correction avec display access-user — une véritable adresse IP attribuée et une session active confirment que le client est bien passé cette fois.

<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

Maillon 4 — Matériel de l'équipement : cartes compatibles NAC et l'accusé du serveur Portal

Parfois RADIUS est correct, les paquets Portal circulent, et le client voit quand même authentification échouée — parce que la carte d'interface elle-même ne peut pas terminer l'échange.

Confirmez avec display web-auth-server configuration que l'IP du serveur Portal et l'interface locale qui l'atteint correspondent bien à ce que vous attendez.
Si les journaux du serveur RADIUS montrent déjà la connexion comme acceptée, les identifiants et la liaison RADIUS sont corrects — la panne se situe en aval, entre l'équipement et le serveur Portal.
Activez ensemble debugging portal all, debugging web all, debugging cm all, debugging aaa all et debugging radius all, avec terminal monitor, terminal debugging et debugging timeout 0, puis reconnectez-vous depuis le client.
Cherchez un paquet Type: authentication ack envoyé par l'équipement vers le serveur Portal. Si aucun ack of authentication ack correspondant ne revient jamais, l'équipement considère l'échange comme expiré et signale authentification échouée — même si RADIUS avait déjà approuvé la connexion.
Vérifiez display device pour la carte qui termine réellement la session Portal. 4GE-2S, 4ES2G-S, 4ES2GP-S et 9ES2 ne supportent pas du tout NAC, et l'authentification Portal ne peut silencieusement pas s'y terminer, aussi correcte que soit le reste de la configuration.

<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 causes racines qui reviennent sans cesse

Une fois que le maillon ci-dessus vous a dit où regarder, ces quatre causes expliquent l'essentiel de ce qui ne va pas.

1. Les paquets d'authentification HTTP ne sont pas transmis en tunnel dans un déploiement AC en couche 3

SYMPTÔMELa page de connexion apparaît sans problème quand un client accède directement à l'URL exacte de push, mais n'apparaît jamais d'elle-même quand le client ouvre simplement un navigateur et tente d'atteindre une adresse quelconque.

CAUSEDans un déploiement AC en dérivation gérant des équipements d'accès via un véritable saut de couche 3, les paquets d'authentification HTTP de Portal sont par défaut encapsulés pour une transmission en couche 2. Cette encapsulation ne survit pas à une véritable frontière de couche 3, donc les paquets n'atteignent jamais l'AC et la redirection vers la page d'authentification ne se produit jamais.

SOLUTIONActivez la transmission en tunnel des paquets d'authentification HTTP pour qu'ils survivent au saut de couche 3 entre l'équipement d'accès et l'AC.

[Huawei] tunnel-forward protocol http

2. RADIUS envoie Framed-IP-Netmask sans Framed-IP-Address

SYMPTÔMEdebugging aaa all affiche une AAA ERROR dès que l'équipement traite la réponse d'autorisation du serveur RADIUS, et le client voit authentification échouée alors même que le nom d'utilisateur et le mot de passe étaient corrects.

CAUSESur ces équipements d'accès, Framed-IP-Netmask n'est valide que jumelé avec Framed-IP-Address dans la même réponse. Un serveur RADIUS conçu principalement pour l'équipement d'un autre fournisseur peut envoyer le masque sans l'adresse — parfaitement valide là-bas, invalide ici — et l'équipement traite toute l'autorisation comme portant une IP invalide.

SOLUTIONAjoutez le Framed-IP-Address manquant sur le serveur RADIUS, ou demandez à l'équipement d'ignorer Framed-IP-Netmask à la réception.

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

3. La carte d'accès ne supporte pas NAC — Portal ne peut aboutir, quoi que le reste soit correct

SYMPTÔMELe journal du serveur RADIUS lui-même confirme la connexion comme acceptée, l'équipement envoie même un authentication-ack vers le serveur Portal, mais le client finit quand même par voir authentification échouée.

CAUSEUne poignée de cartes d'accès — 4GE-2S, 4ES2G-S, 4ES2GP-S, 9ES2 — ne supportent pas NAC, le cadre sur lequel repose l'authentification Portal. Terminer une session Portal sur l'une d'elles signifie que le serveur Portal ne reçoit jamais d'accusé sur lequel agir, aussi correcte que soit la configuration RADIUS et Portal.

SOLUTIONDéplacez l'interface authentifiée par Portal vers une carte qui supporte NAC, comme 8FE1GE ou 24GE.

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

4. La liste des règles sans authentification omet le serveur DNS — la page n'a jamais l'occasion de se charger

SYMPTÔMELe terminal ne peut rien atteindre du tout avant l'authentification, y compris la page de connexion elle-même, et un ping vers le serveur DNS depuis le terminal expire.

CAUSETout ce qu'un client envoie avant l'authentification est bloqué, sauf ce qui figure explicitement dans la règle sans authentification de Portal. Si l'adresse du serveur DNS n'y figure pas, le terminal ne peut résoudre l'adresse dont il a besoin pour atteindre l'URL de push, donc la redirection n'a même pas de cible.

SOLUTIONAjoutez l'adresse du serveur DNS à la liste des règles sans authentification pour que la résolution DNS fonctionne avant la fin de l'authentification.

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

Cinq questions qui reviennent sans cesse

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.

La page apparaît bien si je saisis directement l'URL de push, mais jamais d'elle-même — que se passe-t-il ?

C'est un problème de routage du push de page, pas un problème d'identifiants — presque toujours des paquets d'authentification HTTP qui ne survivent pas au saut de couche 3 entre l'équipement d'accès et l'AC en déploiement bypass. Confirmez avec debugging web packet, puis activez la transmission en tunnel des paquets HTTP.

Les journaux RADIUS montrent la connexion comme acceptée, mais le client voit toujours authentification échouée — où dois-je regarder ?

En aval de RADIUS, entre l'équipement et le serveur Portal. Activez ensemble debugging portal all, debugging web all, debugging cm all, debugging aaa all et debugging radius all et cherchez un authentication-ack envoyé par l'équipement qui n'a jamais reçu d'accusé en retour — c'est ce que le client voit comme un échec. Si ce côté paraît propre, vérifiez si la carte terminaison supporte même NAC.

Pourquoi un nom d'utilisateur et un mot de passe correctement saisis renverraient-ils une erreur d'IP invalide ?

Parce que l'équipement a vérifié l'adresse IP avec laquelle le serveur RADIUS a autorisé la session, et l'a rejetée — pas les identifiants eux-mêmes. Sur ces équipements d'accès, Framed-IP-Netmask ne fonctionne qu'associé à Framed-IP-Address ; une réponse RADIUS avec le masque et sans adresse est signalée comme invalide, et cela ressemble exactement à un échec de connexion du point de vue du terminal.

Quelles cartes d'accès ne peuvent absolument pas faire d'authentification Portal ?

4GE-2S, 4ES2G-S, 4ES2GP-S et 9ES2 ne supportent pas NAC, dont dépend l'authentification Portal. Si une session Portal se termine sur l'une d'elles, aucune configuration RADIUS ou Portal, aussi correcte soit-elle, ne la fera aboutir — la solution est de déplacer l'interface vers une carte comme 8FE1GE ou 24GE qui supporte NAC.

Que faut-il réellement capturer avant d'ouvrir un ticket d'authentification Portal ?

Si la page apparaît ou non, et si saisir directement l'URL exacte de push change cela ; le propre journal du serveur RADIUS pour cette tentative de connexion ; et — si la page est bien apparue — une capture debugging aaa all / debugging portal all à partir du moment où les identifiants sont soumis. Ces trois éléments répondent à presque toutes les questions de routage avant même que quiconque n'ouvre la configuration de l'équipement.

Limites honnêtes de cette note

Limites honnêtes de cette note

Cette note s'appuie sur des routeurs Huawei série AR agissant comme équipements d'accès Portal/RADIUS, et sur les cas de terrain derrière display access-user, debugging aaa/portal/web/cm/radius all, et la règle d'association spécifique AR Framed-IP-Netmask / Framed-IP-Address. Si votre équipement d'accès est d'un autre fournisseur, les commandes exactes et les particularités d'attributs changent, mais l'ordre de diagnostic en quatre maillons — terminal, équipement, serveur Portal, RADIUS — s'applique directement. Elle ne couvre pas en profondeur le 802.1X ou le contournement d'authentification MAC, ni les serveurs Portal fonctionnant entièrement dans le cloud plutôt que sur site.

Bloqué sur une connexion Portal qui refuse de s'authentifier ?

Dites-nous si la page apparaît ou non, ce que dit le journal du serveur RADIUS sur la tentative, et nous vous aiderons à trouver quel maillon est réellement cassé.

WhatsApp avec un ingénieur →