Guest WLAN with Web Authentication (WebAuth)
Most organisations need to provide internet access to visitors, contractors, and personal devices without granting them access to the internal corporate network. A guest WLAN with Web Authentication (WebAuth) achieves this by broadcasting a separate SSID that places connecting clients into an isolated VLAN, then intercepting all HTTP/HTTPS traffic and redirecting the client's browser to a captive portal login page before any internet access is granted. Authentication can be as simple as accepting a terms-of-use page (click-through) or as sophisticated as username/password validation against a RADIUS server.
WebAuth is enforced entirely by the Cisco Wireless LAN Controller (WLC). When a guest client associates with the SSID, the WLC places it in a pre-authentication state — the client receives a DHCP address but all traffic is intercepted by a redirect ACL. Only DNS lookups and HTTPS traffic to the portal are allowed through; everything else is blocked until the client completes the portal login. Once authenticated, the WLC moves the client to a post-authentication state where normal internet access is permitted. For how the WLC and APs communicate, see Controller-Based Networking.
Before starting this lab, ensure you understand WLC fundamentals at WLC Getting Started and SSID-to-VLAN mapping at WLC SSID & VLAN Mapping. For the switch trunk configuration that carries the guest VLAN from the WLC to the distribution switch, see Trunk Port Configuration and VLAN Creation & Management. For RADIUS-based authentication that can back the WebAuth portal, see AAA RADIUS Configuration. For the broader WLC and AP ecosystem, see Access Points & WLC and Lightweight vs Autonomous APs.
1. Guest WLAN & WebAuth — Core Concepts
WebAuth Client State Machine
Every guest client passes through three states from association to full internet access:
State 1 — ASSOCIATED (pre-auth)
┌──────────────────────────────────────────────────────────────┐
│ Client associates to GUEST-SSID (open, no WPA key) │
│ Client obtains IP via DHCP from Guest VLAN (192.168.100.x) │
│ WLC marks client: WebAuth Required │
│ Redirect ACL applied — only DNS + portal HTTPS pass │
└──────────────────────────────────────────────────────────────┘
│ Client opens browser → any URL
▼
State 2 — REDIRECT (captive portal intercept)
┌──────────────────────────────────────────────────────────────┐
│ WLC intercepts HTTP GET / HTTPS request │
│ Sends HTTP 302 redirect to captive portal URL │
│ Browser displays: https://1.1.1.1:8443/login.html │
│ Client enters credentials (or clicks Accept) │
└──────────────────────────────────────────────────────────────┘
│ Credentials submitted to WLC (or RADIUS)
▼
State 3 — AUTHENTICATED (post-auth)
┌──────────────────────────────────────────────────────────────┐
│ WLC validates credentials │
│ Redirect ACL removed — full internet access permitted │
│ WLC optionally redirects browser to success URL │
│ Client state: RUN (normal forwarding) │
└──────────────────────────────────────────────────────────────┘
WebAuth Types — Internal vs External
| Type | Portal Hosted By | Customisation | Authentication Backend | Best For |
|---|---|---|---|---|
| Internal WebAuth | WLC built-in HTTPS server (port 8443) | Limited — logo and text only via WLC GUI | WLC local user database or RADIUS | Small deployments, labs, simple guest access |
| External WebAuth | Separate web server (ISE, ClearPass, custom) | Full HTML/CSS control — branded portal | ISE, RADIUS, AD, social login | Enterprise deployments, branded portals, ISE Guest |
| Passthrough (Splash Page) | WLC built-in | Limited | None — terms acceptance only, no credentials | Coffee shop / hotel style click-through |
Key Components of a Guest WebAuth Deployment
| Component | Purpose | Configuration Location |
|---|---|---|
| Guest VLAN | Isolates guest traffic from the corporate LAN — guest clients get IPs in a separate subnet routed only to internet, not internal resources | WLC → Controller → Interfaces; Switch VLAN database and trunk |
| Guest SSID | Open (no WPA pre-shared key) SSID broadcast for visitors — mapped to the guest VLAN interface | WLC → WLANs → Create New |
| Redirect ACL | Pre-auth ACL applied to guest clients — permits DNS and portal HTTPS, denies all other traffic (the deny is what triggers the redirect to the portal). See ACL Overview | WLC → Security → Access Control Lists |
| WebAuth Policy | Selects WebAuth type (internal/external/passthrough), portal URL, success redirect URL, and credential source | WLC → WLANs → [WLAN] → Security → Layer 3 |
| Guest Local Users | Username/password accounts stored on the WLC for internal WebAuth credential validation | WLC → Security → Local Net Users |
| Virtual Interface (VIP) | Dummy IP address used as the redirect destination — all guest browsers are redirected here. Must be a non-routable address (conventionally 1.1.1.1) so the WLC is always the only device that responds to it | WLC → Controller → Interfaces → Virtual |
Guest Traffic Flow Through the Network
Guest Laptop
|
| 802.11 (open SSID: NetsTuts-Guest)
▼
Access Point (LAP)
|
| CAPWAP tunnel (all guest frames encapsulated back to WLC)
▼
Cisco WLC
| Guest VLAN 100 interface: 192.168.100.2/24
| DHCP scope: 192.168.100.10–200 (served by switch SVI)
| Redirect ACL applied (pre-auth state)
▼
Distribution Switch
| VLAN 100 SVI: 192.168.100.1 (default gateway + DHCP)
| VLAN 100 has NO route to 10.0.0.0/24 (corporate)
| VLAN 100 routes to internet only via firewall
▼
Firewall / Router
|
▼
Internet
Corporate LAN (10.0.0.0/24) — UNREACHABLE from VLAN 100
─────────────────────────────────────────────────────────
Separation is enforced at Layer 3 — no route from VLAN 100
to internal subnets, plus an explicit firewall deny rule.
Traffic isolation between the guest VLAN (100) and the corporate LAN
must be enforced at Layer 3. For how SVIs and inter-VLAN routing work
on multilayer switches, see
Inter-VLAN Routing
on a Layer 3 Switch.
2. Lab Topology & Scenario
The NetsTuts organisation needs a guest WLAN for visitors. Guests must accept a terms-of-use page and enter credentials before accessing the internet. Guest traffic must be completely isolated from the corporate LAN (10.0.0.0/24). The WLC already manages lightweight APs on the corporate WLAN (VLAN 10). This lab adds a second SSID — NetsTuts-Guest — on VLAN 100 with internal WebAuth.
┌──────────────────────────────────────────────────────────────┐
│ NetsTuts WLC │
│ Management Interface: VLAN 10 — 10.0.0.50/24 │
│ AP-Manager Interface: VLAN 10 — 10.0.0.51/24 │
│ Guest Interface: VLAN 100 — 192.168.100.2/24 │
│ Virtual Interface: 1.1.1.1 (redirect VIP) │
└───────────────────────────┬──────────────────────────────────┘
│ Trunk (VLAN 10 native + VLAN 100)
│
┌────────────▼────────────┐
│ Distribution Switch │
│ VLAN 10 SVI: 10.0.0.1 │
│ VLAN 100 SVI: 192.168.100.1 (GW + DHCP) │
└────────────┬────────────┘
│
┌─────▼──────┐
│ Firewall │ Routes VLAN 100 → internet
│ │ Denies VLAN 100 → 10.0.0.0/24
└────────────┘
Wireless SSIDs:
┌──────────────────────┬───────────────────┬───────────────────┐
│ SSID │ NetsTuts-Corp │ NetsTuts-Guest │
│ Layer 2 Security │ WPA2-PSK │ None (open) │
│ Layer 3 Security │ None │ Web Policy: Auth │
│ VLAN │ 10 │ 100 │
│ Client Subnet │ 10.0.0.0/24 │ 192.168.100.0/24 │
│ Internet Access │ Yes │ Yes (post-auth) │
│ Corporate LAN Access │ Yes │ No (denied) │
└──────────────────────┴───────────────────┴───────────────────┘
Guest Local Users (WLC):
Username: visitor1 Password: Guest@2024
Username: visitor2 Password: Guest@2024
3. Step 1 — Create Guest VLAN on the Distribution Switch
Before touching the WLC, create VLAN 100 on the distribution switch, add it to the trunk port connecting to the WLC, and configure a DHCP scope for guest clients. The SVI provides the default gateway:
NetsTuts_SW>en NetsTuts_SW#conf t ! ── Create guest VLAN ───────────────────────────────────── NetsTuts_SW(config)#vlan 100 NetsTuts_SW(config-vlan)#name GUEST-WLAN NetsTuts_SW(config-vlan)#exit ! ── Add VLAN 100 to the trunk toward the WLC ────────────── NetsTuts_SW(config)#interface GigabitEthernet0/1 NetsTuts_SW(config-if)#description Trunk to WLC NetsTuts_SW(config-if)#switchport mode trunk NetsTuts_SW(config-if)#switchport trunk allowed vlan add 100 NetsTuts_SW(config-if)#exit ! ── SVI — default gateway for guest clients ─────────────── NetsTuts_SW(config)#interface vlan 100 NetsTuts_SW(config-if)#description Guest WLAN Gateway NetsTuts_SW(config-if)#ip address 192.168.100.1 255.255.255.0 NetsTuts_SW(config-if)#no shutdown NetsTuts_SW(config-if)#exit ! ── DHCP scope for guest clients on VLAN 100 ────────────── NetsTuts_SW(config)#ip dhcp excluded-address 192.168.100.1 192.168.100.9 NetsTuts_SW(config)#ip dhcp pool GUEST-POOL NetsTuts_SW(dhcp-config)#network 192.168.100.0 255.255.255.0 NetsTuts_SW(dhcp-config)#default-router 192.168.100.1 NetsTuts_SW(dhcp-config)#dns-server 8.8.8.8 8.8.4.4 NetsTuts_SW(dhcp-config)#lease 0 4 NetsTuts_SW(dhcp-config)#exit NetsTuts_SW(config)#end NetsTuts_SW#wr
The DHCP lease is set to 4 hours (
lease 0 4) — appropriate
for a transient guest population to reclaim IPs promptly. DNS servers
point to public resolvers (8.8.8.8) rather than the internal DNS server,
preventing guests from resolving internal hostnames. For DHCP details, see
DHCP Server Configuration.
For trunk port configuration, see
Trunk Port Configuration and
VLAN Creation & Management.
4. Step 2 — Create the Guest Dynamic Interface on the WLC
On the WLC, a dynamic interface is the WLC's representation of a VLAN — it defines the VLAN tag, the WLC's own IP address on that VLAN, and the DHCP server to use for clients on that interface. Navigate to Controller → Interfaces → New:
WLC GUI — Controller → Interfaces → [New] ┌───────────────────────────────────────────────────────┐ │ Interface Name: guest-vlan100 │ │ VLAN Id: 100 │ └───────────────────────────────────────────────────────┘ [Apply] — then fill in interface details: ┌───────────────────────────────────────────────────────┐ │ IP Address: 192.168.100.2 │ │ Netmask: 255.255.255.0 │ │ Gateway: 192.168.100.1 ← Switch SVI │ │ VLAN Identifier: 100 │ │ Physical Port: (select WLC uplink port) │ │ Primary DHCP Server: 192.168.100.1 ← Switch SVI │ │ ACL: (leave blank for now) │ └───────────────────────────────────────────────────────┘ [Apply] → [Save Configuration]
The WLC's guest interface IP (192.168.100.2) and the switch SVI
(192.168.100.1) are in the same /24 subnet but are distinct addresses.
The switch SVI is the DHCP server and the default gateway that guest
clients will use. The WLC interface IP is used for CAPWAP
communication on that VLAN. Ensure the Physical Port field matches
the WLC uplink port connected to the distribution switch trunk.
For more on WLC interface setup, see
WLC Getting Started.
5. Step 3 — Configure the Pre-Authentication Redirect ACL
The redirect ACL defines what a guest client can do before authenticating. It must permit DNS (so clients can resolve hostnames) and permit HTTPS to the WLC's virtual IP (so the portal page loads). All other traffic is denied — and this is the key point: traffic that is denied by this ACL is what the WLC redirects to the captive portal, not what it silently drops. Navigate to Security → Access Control Lists → New:
WLC GUI — Security → Access Control Lists → New ┌───────────────────────────────────────────────────────┐ │ ACL Name: GUEST-REDIRECT-ACL │ │ ACL Type: IPv4 │ └───────────────────────────────────────────────────────┘ [Apply] — then add rules: Rule 1 — Permit DNS queries (client resolves hostnames) ┌───────────────────────────────────────────────────────┐ │ Sequence: 1 Action: Permit │ │ Protocol: UDP │ │ Source: Any │ │ Destination: Any Dst Port: 53 │ └───────────────────────────────────────────────────────┘ Rule 2 — Permit DNS replies (src port 53 returning) ┌───────────────────────────────────────────────────────┐ │ Sequence: 2 Action: Permit │ │ Protocol: UDP │ │ Source: Any Src Port: 53 │ │ Destination: Any │ └───────────────────────────────────────────────────────┘ Rule 3 — Permit HTTPS to WLC Virtual IP (portal page) ┌───────────────────────────────────────────────────────┐ │ Sequence: 3 Action: Permit │ │ Protocol: TCP │ │ Source: Any │ │ Destination: 1.1.1.1 / 255.255.255.255 Port: 8443 │ └───────────────────────────────────────────────────────┘ Rule 4 — Permit HTTP to WLC Virtual IP ┌───────────────────────────────────────────────────────┐ │ Sequence: 4 Action: Permit │ │ Protocol: TCP │ │ Source: Any │ │ Destination: 1.1.1.1 / 255.255.255.255 Port: 80 │ └───────────────────────────────────────────────────────┘ Rule 5 — Deny all other traffic (TRIGGERS the redirect) ┌───────────────────────────────────────────────────────┐ │ Sequence: 5 Action: Deny │ │ Protocol: Any │ │ Source: Any │ │ Destination: Any │ └───────────────────────────────────────────────────────┘ [Apply] → [Save Configuration]
The ACL logic here is the opposite of a typical
firewall deny. Traffic that is permitted (DNS, portal HTTPS)
passes through uninterrupted. Traffic that is denied (rule 5
— all other HTTP/HTTPS) is intercepted by the WLC WebAuth engine
and redirected to the captive portal URL. If rule 5 were set to
permit, HTTP traffic would pass freely and the portal would never
appear — guests would have full internet access without authenticating.
For ACL syntax and wildcard mask details, see
Named ACLs and
Wildcard Masks.
Virtual Interface IP: The WLC Virtual Interface
must be configured with a non-routable IP — conventionally
1.1.1.1. When a guest browser is redirected to
https://1.1.1.1:8443/login.html, the WLC intercepts
this request and serves the portal page. The virtual IP is never
actually routed across the network. Verify or set it at
Controller → Interfaces → Virtual.
6. Step 4 — Create the Guest WLAN (SSID)
Navigate to WLANs → Create New → Go. The WLAN ties together the guest interface, open Layer 2 security (no PSK), and the WebAuth Layer 3 policy:
WLC GUI — WLANs → Create New → [Go] ┌───────────────────────────────────────────────────────┐ │ Type: WLAN │ │ Profile Name: NetsTuts-Guest │ │ SSID: NetsTuts-Guest │ │ ID: 2 (ID 1 = corporate WLAN) │ └───────────────────────────────────────────────────────┘ [Apply] ── Tab: General ───────────────────────────────────────── ┌───────────────────────────────────────────────────────┐ │ Status: Enabled ✅ │ │ Interface/Group: guest-vlan100 │ │ Broadcast SSID: Enabled ✅ │ └───────────────────────────────────────────────────────┘ ── Tab: Security → Layer 2 ────────────────────────────── ┌───────────────────────────────────────────────────────┐ │ Layer 2 Security: None (open — no WPA key) │ │ MAC Filtering: Disabled │ └───────────────────────────────────────────────────────┘ ── Tab: Security → Layer 3 ────────────────────────────── ┌───────────────────────────────────────────────────────┐ │ Layer 3 Security: Web Policy ✅ │ │ Web Policy: ● Authentication │ │ ○ Passthrough │ │ ○ Conditional Web Redirect │ │ ○ Splash Page Web Redirect │ │ │ │ Preauthentication ACL: GUEST-REDIRECT-ACL ✅ │ └───────────────────────────────────────────────────────┘ ── Tab: Security → AAA Servers ────────────────────────── ┌───────────────────────────────────────────────────────┐ │ Authentication Server 1: None │ │ (None = use WLC local Net Users for internal WebAuth)│ │ (Select a RADIUS server here for RADIUS-backed auth) │ └───────────────────────────────────────────────────────┘ ── Tab: Advanced ───────────────────────────────────────── ┌───────────────────────────────────────────────────────┐ │ DHCP Addr. Assignment: Required ✅ │ │ Client Exclusion: Enabled ✅ (60 sec) │ │ Session Timeout: 1800 sec (30 min) │ └───────────────────────────────────────────────────────┘ [Apply] → [Save Configuration]
Web Policy: Authentication requires username and
password at the portal. Passthrough displays a
splash/terms page with a single Accept button and no credentials.
The Preauthentication ACL field is critical — it
links the redirect ACL from Step 3. Without it, no pre-auth filtering
occurs and the redirect will not work. Session Timeout (1800 sec = 30 min)
automatically de-authenticates idle guests, freeing IP leases and
enforcing re-authentication. For SSID and VLAN concepts, see
WLC SSID & VLAN Mapping.
For Wi-Fi security types including
WPA2 used on the corporate SSID, see the Wi-Fi Security overview.
7. Step 5 — Create Guest Local User Accounts
For internal WebAuth, the WLC validates credentials against its local user database. Navigate to Security → Local Net Users → New:
WLC GUI — Security → Local Net Users → [New] User 1: ┌───────────────────────────────────────────────────────┐ │ Username: visitor1 │ │ Password: Guest@2024 │ │ Confirm: Guest@2024 │ │ Guest User: ✅ Enabled │ │ Lifetime: 86400 seconds (24 hours — then expired)│ │ WLAN Id: 2 (NetsTuts-Guest only) │ │ Description: Daily guest pass │ └───────────────────────────────────────────────────────┘ [Apply] User 2: ┌───────────────────────────────────────────────────────┐ │ Username: visitor2 │ │ Password: Guest@2024 │ │ Guest User: ✅ Enabled │ │ Lifetime: 86400 seconds │ │ WLAN Id: 2 │ └───────────────────────────────────────────────────────┘ [Apply] → [Save Configuration]
Enabling Guest User marks these as time-limited
accounts — the WLC automatically expires them after the Lifetime
elapses. Scoping to WLAN Id: 2 prevents these
credentials from authenticating on any other WLAN. For production
deployments with many daily guests, use a RADIUS server such as
Cisco ISE with a Guest Portal for automated account creation,
sponsor-approval workflows, and automatic expiry at scale — local
accounts on the WLC do not scale beyond a handful of users.
See AAA RADIUS Configuration.
8. Step 6 — Customise the Internal WebAuth Login Page
The WLC's internal portal can be lightly branded with a logo, headline, and terms message. Navigate to Security → Web Auth → Web Login Page:
WLC GUI — Security → Web Auth → Web Login Page ┌───────────────────────────────────────────────────────┐ │ Web Authentication Type: Internal (Default) ✅ │ │ │ │ Cisco Logo: Hide ✅ (replace with custom logo) │ │ Custom Logo: Upload netstuts-logo.png │ │ │ │ Page Title: NetsTuts Guest Wi-Fi │ │ Message: Welcome. By logging in you agree │ │ to our acceptable use policy. │ │ │ │ Redirect URL after login: │ │ https://netstuts.com │ └───────────────────────────────────────────────────────┘ [Preview] — verify appearance in the preview pane [Apply] → [Save Configuration]
The Redirect URL after login sends the guest's browser
to a welcome page immediately after successful authentication —
confirming to the user that they are now online. If left blank, the
browser stays on the WLC portal page after login. For full HTML/CSS
branding and custom portal logic, an External WebAuth deployment
pointing to Cisco ISE or a dedicated web server is required.
9. Verification
Monitor → Clients — Guest Client State
WLC GUI — Monitor → Clients Before authentication (pre-auth): ┌────────────────────┬─────────────────┬────────────────┬────────────────┐ │ Client MAC │ IP Address │ WLAN │ Status │ ├────────────────────┼─────────────────┼────────────────┼────────────────┤ │ a4:c3:f0:11:22:33 │ 192.168.100.15 │ NetsTuts-Guest │ WebAuth Reqd │ └────────────────────┴─────────────────┴────────────────┴────────────────┘ After successful authentication (post-auth): ┌────────────────────┬─────────────────┬────────────────┬────────────────┐ │ Client MAC │ IP Address │ WLAN │ Status │ ├────────────────────┼─────────────────┼────────────────┼────────────────┤ │ a4:c3:f0:11:22:33 │ 192.168.100.15 │ NetsTuts-Guest │ Associated │ │ │ │ │ (RUN) │ └────────────────────┴─────────────────┴────────────────┴────────────────┘
WebAuth Reqd means the client has an IP address and
is associated with the SSID but has not completed portal authentication
— the redirect ACL is active. Associated (RUN) means
authentication succeeded and the client has full internet access.
Click the client MAC address for detailed information including
authentication method, signal strength, and policy applied.
WLC CLI — show client summary and show client detail
! ── Connect to WLC CLI via SSH ──────────────────────────── (Cisco Controller) >show client summary Number of Clients................................ 3 MAC Address AP Name Status WLAN Auth Protocol ------------------- --------------- -------------- ---- ---- -------- a4:c3:f0:11:22:33 NetsTuts-AP-01 Associated 2 Yes 802.11ac b8:27:eb:44:55:66 NetsTuts-AP-01 WebAuth Reqd 2 No 802.11n c0:ee:fb:77:88:99 NetsTuts-AP-02 Associated 1 Yes 802.11ac ! ── Detailed client info ────────────────────────────────── (Cisco Controller) >show client detail a4:c3:f0:11:22:33 Client MAC Address............................... a4:c3:f0:11:22:33 Client Username.................................. visitor1 AP Name.......................................... NetsTuts-AP-01 Client State..................................... Associated Wireless LAN Id.................................. 2 WLAN Profile Name................................ NetsTuts-Guest Interface........................................ guest-vlan100 VLAN............................................. 100 IP Address....................................... 192.168.100.15 Security Policy Completed........................ Yes Policy Type...................................... WebAuth Web Security Policy.............................. Passed Session Timeout.................................. 1800
show wlan summary and show acl detailed
(Cisco Controller) >show wlan summary WLAN ID Profile Name Status Interface ------- ----------------- ------- --------------- 1 NetsTuts-Corp Enabled management 2 NetsTuts-Guest Enabled guest-vlan100 (Cisco Controller) >show acl detailed GUEST-REDIRECT-ACL ACL Name: GUEST-REDIRECT-ACL Seq Action Protocol Src IP Src Port Dst IP Dst Port --- ------ -------- ------------- -------- -------------- -------- 1 Permit UDP(17) 0.0.0.0/0 Any 0.0.0.0/0 53 2 Permit UDP(17) 0.0.0.0/0 53 0.0.0.0/0 Any 3 Permit TCP(6) 0.0.0.0/0 Any 1.1.1.1/32 8443 4 Permit TCP(6) 0.0.0.0/0 Any 1.1.1.1/32 80 5 Deny Any 0.0.0.0/0 Any 0.0.0.0/0 Any
End-to-End WebAuth Validation Checklist
| Test | Expected Result | Confirms |
|---|---|---|
| Connect to NetsTuts-Guest SSID (no password) | Client associates and receives 192.168.100.x IP | Open SSID, guest VLAN interface, and DHCP scope all working |
| Open browser to a plain HTTP URL (e.g., http://neverssl.com) | Browser redirects to https://1.1.1.1:8443/login.html |
Redirect ACL and WebAuth engine intercepting HTTP traffic correctly |
| Enter credentials: visitor1 / Guest@2024 and submit | Browser redirects to https://netstuts.com — internet access granted | Local user authentication successful, post-auth policy applied |
| Ping 10.0.0.1 (corporate gateway) from guest client | Ping fails — no response | Guest VLAN isolation enforced at Layer 3 |
| Check WLC Monitor → Clients | Status changes from WebAuth Reqd to Associated (RUN) after login | WLC tracking client authentication state correctly |
| Wait 30 minutes (Session Timeout expiry) | Client is de-authenticated and must re-authenticate on next browser open | Session timeout and re-auth enforcement working |
Verification Command Summary
| Command / Location | What It Shows | Primary Use |
|---|---|---|
show client summary (WLC CLI) |
All associated clients — MAC, AP, status (Associated / WebAuth Reqd), WLAN ID, auth state | Quick overview of all connected clients and authentication status |
show client detail [MAC] (WLC CLI) |
Full client detail — IP, VLAN, policy type, auth method, WebAuth status, ACL applied, session timeout | Confirm a specific client's authentication state and applied policies |
show wlan summary (WLC CLI) |
All WLANs — ID, profile name, status, interface mapped | Confirm guest WLAN is enabled and mapped to the correct guest interface |
show acl detailed [name] (WLC CLI) |
Redirect ACL rules — sequence, action, protocol, source, destination, port | Verify redirect ACL rules are correctly defined and ordered |
| Monitor → Clients (WLC GUI) | Real-time client table with status, AP, WLAN, and IP | Visual confirmation of client state transitions during WebAuth testing |
| Monitor → Statistics → WLAN (WLC GUI) | Per-WLAN counters — associations, authentications, WebAuth success/failure counts | Operational monitoring — detect authentication failures and usage patterns |
10. Troubleshooting Guest WebAuth Issues
| Problem | Symptom | Cause | Fix |
|---|---|---|---|
| Browser never redirects to login page | Guest gets an IP address but opening a browser shows "connection timed out" — no portal appears | Layer 3 Web Policy not enabled on the WLAN, Preauthentication ACL field is empty, or the client is using an HTTPS-only URL where the browser's HSTS blocks the redirect before it can happen | Verify WLANs → [WLAN] → Security → Layer 3 has Web Policy enabled and GUEST-REDIRECT-ACL selected. Test with a plain HTTP URL — use http://neverssl.com which is designed for captive portal testing. Confirm the Virtual Interface is set at Controller → Interfaces → Virtual |
| Guest client does not receive a DHCP address | Client associates with the SSID but shows 169.254.x.x (APIPA) or no IP | VLAN 100 is not on the switch trunk to the WLC, DHCP scope is exhausted, or the Primary DHCP Server in the WLC guest interface points to the wrong IP | Check show interfaces trunk on the switch — confirm VLAN 100 is in the allowed list. Check show ip dhcp binding and show ip dhcp pool GUEST-POOL. Verify the Primary DHCP Server field in the WLC guest interface is 192.168.100.1. See DHCP Server Configuration |
| Login credentials rejected | Client reaches the portal but "Invalid username or password" appears after submitting | Local Net User account is expired, account is scoped to a different WLAN ID, or RADIUS is configured but unreachable causing the WLC to fall through to local users where the account does not exist | Check Security → Local Net Users — confirm account exists, Lifetime has not expired, and WLAN ID is 2. If using RADIUS, run ping [RADIUS-IP] from the WLC CLI to verify reachability, then check the RADIUS server auth log for a reject reason. See AAA RADIUS Configuration |
| Authenticated guests can access the corporate LAN | After successful login, a guest can ping or reach 10.0.0.x internal hosts | No Layer 3 ACL or firewall rule blocks traffic from VLAN 100 (192.168.100.0/24) to the corporate LAN (10.0.0.0/24) — VLAN separation at Layer 2 alone does not prevent routing between VLANs on a multilayer switch | Add an ACL or firewall rule on the Layer 3 boundary device: deny ip 192.168.100.0 0.0.0.255 10.0.0.0 0.0.0.255. See Applying ACLs and Firewall Concepts |
| Portal page shows SSL certificate warning | Browser displays "Your connection is not private" before showing the login page | The WLC uses a self-signed certificate for its internal HTTPS server — modern browsers flag self-signed certs from unknown CAs as untrusted | For labs: instruct users to click "Advanced" and proceed. For production: install a CA-signed certificate on the WLC at Security → Web Auth Certificate, or use External WebAuth with ISE which can present a properly signed certificate |
| Guest WLAN shows "Disabled" in WLC GUI | show wlan summary shows the guest WLAN status as Disabled |
WLAN Status checkbox was not enabled on the General tab, or the guest-vlan100 dynamic interface is not up because VLAN 100 is not on the trunk | Go to WLANs → [WLAN] → General and enable the Status checkbox. Verify the guest-vlan100 interface is up at Controller → Interfaces. Confirm at least one AP is associated under Wireless → Access Points. See WLC Getting Started |
Key Points & Exam Tips
- Guest WebAuth requires four components: a dedicated guest VLAN isolated from the corporate LAN, an open SSID mapped to that VLAN, a redirect ACL that permits DNS and portal HTTPS but denies everything else, and a Layer 3 Web Policy on the WLAN referencing the redirect ACL.
- The redirect ACL logic is inverted compared to a standard firewall ACL. Traffic that is denied by the ACL is what the WLC redirects to the captive portal. Traffic that is permitted (DNS, portal HTTPS) passes through without redirection. Permitting HTTP/HTTPS in the ACL would give guests full internet access without ever seeing the portal.
- The WLC Virtual Interface (conventionally 1.1.1.1) is the redirect target IP. It must be a non-routable address that no other network device owns — the WLC intercepts all requests to this IP internally and serves the login page. Set it at Controller → Interfaces → Virtual.
- Guest clients have two states: WebAuth Reqd (associated, DHCP address assigned, redirect ACL active, no internet) and Associated/RUN (authenticated, redirect ACL removed, internet permitted). These states are visible in Monitor → Clients and via
show client summary. - VLAN isolation must be enforced at Layer 3 — placing guests in VLAN 100 prevents Layer 2 communication with VLAN 10 but does not stop Layer 3 routing between the two. A firewall rule or ACL on the gateway must explicitly deny VLAN 100 from reaching the corporate subnet.
- Web Policy: Authentication requires username/password at the portal. Passthrough shows a splash page with a single Accept button and no credentials — the "coffee shop" model. Both use the same redirect ACL mechanism; only the portal page content and credential requirement differ.
- Local Net Users scoped to a specific WLAN ID and given a Lifetime expire automatically after the configured duration. For scale (100+ daily guests), use Cisco ISE with a Guest Portal for automated account management — local WLC users do not scale.
- Always test the captive portal with a plain HTTP URL such as http://neverssl.com — HTTPS URLs with HSTS headers may not redirect in modern browsers because the browser enforces HTTPS before the WLC can inject the redirect.
- On the exam: know the three WebAuth client states, the inverted deny-triggers-redirect logic of the redirect ACL, the role of the Virtual Interface, the difference between Authentication and Passthrough portal types, and how to read
show client summaryoutput.
Next Steps: For port-based authentication on wired
switches, see
802.1X Port-Based Authentication.
For RADIUS-backed credential validation behind the WebAuth portal, see
AAA RADIUS Configuration
and AAA TACACS+ Configuration.
For WLC management access hardening, see
Login Security &
Brute-Force Protection.
For understanding wireless frequencies and channel planning that
supports the guest SSID, see
Frequency & Channels.
For RF channel and power planning on the WLC, see
Wireless RF Channel
& Power Planning.
For FlexConnect branch deployments where the guest portal must work
without a live WLC connection, see
FlexConnect AP
Configuration.