Portal authentication breaks in two very different ways — the login page never appears, or it appears and rejects a password that's actually correct — and each one lives in a different link of the same chain: terminal, access device, Portal server, RADIUS server. This is the order that finds which link is actually broken, the display and debugging commands for each, and the causes that show up again and again in the field.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Authentication failed can mean four completely different things depending on which of the four links in the chain actually broke.
A user calls in with "Portal login doesn't work," and that one sentence covers at least two structurally different faults: the authentication page never appears at all, or it appears, takes a username and password, and comes back with authentication failed even though the credentials are correct. Chasing the second problem with fixes for the first — and vice versa — wastes a support call. The chain that has to actually work, in order, is the terminal, the access device acting as Portal/RADIUS client, the Portal server, and the RADIUS server behind it.
What follows is that chain, the checks and the exact commands for each link, four root causes that account for most of these tickets in the field, and five FAQ answers pulled from real Portal/RADIUS cases.
Every Portal/RADIUS ticket lands in one of two shapes before it lands in one of four links — sort it there first.
The diagram below places the fault on the tree before any configuration gets touched: does the page even appear, or does it appear and then reject the login.
Diagram labels are kept in English for engineering clarity.
A page that won't push and a login RADIUS actually approved but the client still sees rejected are not the same fault, and they're not fixed by the same command. Sort the ticket onto this tree first, then work the matching link below.
Four links, four different tools — display commands for the ones that are basically configuration checks, debugging for the ones that need to be caught live.
If the login page never shows up at all, don't assume Portal is broken yet — confirm the terminal side first.
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 pageThe case behind this section: an AC deployed off to the side (bypass mode), managing access devices at Layer 3, with a third-party Portal server across that Layer 3 hop.
<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 hopRADIUS logs can say accepted while the client still sees authentication failed — the device is rejecting the authorization response itself, not the credentials.
<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 workedSometimes RADIUS is right, the Portal packets are flowing, and the client still sees authentication failed — because the interface board itself can't finish the exchange.
<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 allOnce the link above has told you where to look, these four account for most of what's actually wrong.
SYMPTOMThe login page pops up fine when a client hits the exact push URL directly, but never appears on its own when the client just opens a browser and tries to reach any address.
CAUSEIn a bypass AC deployment managing access devices across a genuine Layer-3 hop, Portal's HTTP authentication packets are encapsulated for Layer-2 forwarding by default. That encapsulation doesn't survive a real Layer-3 boundary, so the packets never reach the AC and the redirect to the auth page never happens.
FIXEnable tunnel forwarding for HTTP authentication packets so they survive the Layer-3 hop between access device and AC.
[Huawei] tunnel-forward protocol httpSYMPTOMdebugging aaa all shows an AAA ERROR the moment the device processes the RADIUS server's authorization response, and the client sees authentication failed even though the username and password were correct.
CAUSEOn these access devices, Framed-IP-Netmask is only valid paired with Framed-IP-Address in the same response. A RADIUS server built primarily for a different vendor's equipment can send the mask without the address — perfectly valid there, invalid here — and the device treats the whole authorization as carrying an invalid IP.
FIXAdd the missing Framed-IP-Address on the RADIUS server, or tell the device to ignore Framed-IP-Netmask on receipt.
[Huawei-radius-test1] radius-attribute disable Framed-IP-Netmask receiveSYMPTOMThe RADIUS server's own log confirms the login as accepted, the device even sends an authentication-ack toward the Portal server, but the client still ends up seeing authentication failed.
CAUSEA handful of access boards — 4GE-2S, 4ES2G-S, 4ES2GP-S, 9ES2 — don't support NAC, the framework Portal authentication runs on. Terminating a Portal session on one of them means the Portal server never gets an ack it can act on, no matter how correct the RADIUS and Portal configuration are.
FIXMove the Portal-authenticated interface to a board that supports NAC, such as 8FE1GE or 24GE.
<Huawei> display device
// confirm the board type behind the Portal-authenticated interface before ordering a swapSYMPTOMThe terminal can't reach anything at all before authenticating, including the login page itself, and a ping to the DNS server from the terminal times out.
CAUSEEverything a client sends before authenticating gets blocked except what's explicitly listed in the Portal free-rule. If the DNS server's address isn't on that list, the terminal can't resolve the address it needs to reach the push URL, so the redirect never even gets a target.
FIXAdd the DNS server's address to the free-rule list so DNS resolution works before authentication completes.
<Huawei> display portal free-rule
// confirm the DNS server's address is present before looking anywhere elsePulled straight from the field — the ones worth having an answer ready for.
That's a page-push routing problem, not a credentials problem — almost always HTTP authentication packets not surviving a Layer-3 hop between the access device and the AC in a bypass deployment. Confirm with debugging web packet, then enable tunnel forwarding for HTTP packets.
Downstream of RADIUS, between the device and the Portal server. Turn on debugging portal all, debugging web all, debugging cm all, debugging aaa all and debugging radius all together and look for an authentication-ack the device sent that never got acked back — that's what the client sees as failure. If that side looks clean, check whether the terminating board even supports NAC in the first place.
Because the device checked the IP address the RADIUS server authorized the session with, and rejected it — not the credentials themselves. On these access devices, Framed-IP-Netmask only works paired with Framed-IP-Address; a RADIUS response with the mask and no address gets flagged as invalid, and it reads exactly like a login failure from the terminal's side.
4GE-2S, 4ES2G-S, 4ES2GP-S and 9ES2 don't support NAC, which Portal authentication depends on. If a Portal session terminates on one of these, no amount of correct RADIUS or Portal server configuration will make it complete — the fix is moving the interface to a board like 8FE1GE or 24GE that does support NAC.
Whether the page appears at all, and whether typing the exact push URL directly changes that; the RADIUS server's own log for that login attempt; and — if the page did appear — a debugging aaa all / debugging portal all capture from the moment credentials are submitted. Those three answer almost every routing question before anyone even opens the device configuration.
This note is built around Huawei AR-series routers acting as Portal/RADIUS access devices, and the field cases behind display access-user, debugging aaa/portal/web/cm/radius all, and the AR-specific Framed-IP-Netmask / Framed-IP-Address pairing rule. If your access device is a different vendor, the exact commands and attribute quirks change, but the four-link diagnostic order — terminal, device, Portal server, RADIUS — carries over directly. It doesn't cover 802.1X or MAC-authentication-bypass in depth, or Portal servers running fully in the cloud rather than on-premises.
Tell us whether the page appears at all, what the RADIUS server's own log says about the attempt, and we'll help you find which link actually broke.