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:
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
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.
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:
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:
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:
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:
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:
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
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.
TEST WHAT YOU LEARNED
In a Cisco WLC WebAuth deployment, what is the purpose of the Virtual Interface IP address (e.g., 1.1.1.1), and why must it be a non-routable address?
Correct answer is B. The WLC Virtual Interface serves one purpose: it is the IP the WLC redirects guest browsers to when their HTTP traffic is intercepted by the WebAuth engine. When a guest opens http://example.com, the WLC sends an HTTP 302 to https://1.1.1.1:8443/login.html. The WLC itself intercepts this request — it knows 1.1.1.1 is its own virtual IP — and serves the login page. The packet never actually leaves the WLC toward 1.1.1.1. If 1.1.1.1 were a real routable address on the network, routers might forward the redirected request to that real device instead of the WLC, breaking the portal. The Virtual Interface IP (configured at Controller → Interfaces → Virtual) must be something that does not exist anywhere else in the network.
A guest client connects to NetsTuts-Guest, gets an IP address (192.168.100.15), but opening a browser shows "Connection timed out" — no portal appears. What is the most likely cause?
Correct answer is D. The client already has an IP (192.168.100.15), which rules out VLAN/DHCP problems (option A). The symptom — timeout instead of redirect — means the WLC is not intercepting the HTTP request and redirecting it. Two things must both be configured: (1) Layer 3 Web Policy must be enabled (the checkbox on Security → Layer 3 tab), and (2) the Preauthentication ACL must reference GUEST-REDIRECT-ACL. Without the Web Policy enabled, there is no WebAuth interception regardless of the ACL. Without the ACL, there is no redirect trigger. RADIUS is not needed for internal WebAuth with local users (option B). Session timeout only applies to authenticated clients, not pre-auth clients (option C). Always test with a plain HTTP URL — HTTPS URLs with HSTS may not redirect in modern browsers.
Why does the preauthentication redirect ACL use "Deny" in rule 5 for all traffic, when a deny in a standard ACL means "block"?
Correct answer is A. This is the most counterintuitive aspect of WLC WebAuth redirect ACLs. The WLC WebAuth engine specifically watches for traffic that is denied by the preauthentication ACL. When it sees a denied HTTP or HTTPS packet, it intercepts it and sends the client an HTTP 302 redirect to the portal URL — rather than dropping the packet silently. Traffic that is permitted passes through the WLC normally with no interception. DNS is permitted so clients can resolve hostnames; portal HTTPS (to the virtual IP) is permitted so the login page loads after the redirect. If you set rule 5 to Permit instead of Deny, HTTP/HTTPS traffic would flow freely through the WLC — the guest would have full internet access without ever seeing the portal. This inverted logic is specific to WLC redirect ACLs and does not apply to interface ACLs on routers or switches.
After a guest successfully logs in through the WebAuth portal, the client can browse the internet but can also ping 10.0.0.5 on the corporate LAN. What is the misconfiguration?
Correct answer is C. VLAN separation at Layer 2 ensures guest and corporate traffic do not share a broadcast domain. However, if a Layer 3 device (multilayer switch or router/firewall) has SVIs or interfaces in both VLAN 100 (192.168.100.1) and VLAN 10 (10.0.0.1) with routes to both, it will happily route traffic between them unless explicitly told not to. A guest client sends traffic to its gateway (192.168.100.1), which routes it into VLAN 10 toward 10.0.0.5. The fix is a deny ACL entry or firewall policy on the Layer 3 boundary: deny IP 192.168.100.0/24 to 10.0.0.0/24. The redirect ACL is a pre-authentication mechanism only — it has no role in post-auth traffic isolation. The problem existed before and after WebAuth; it is purely a routing/firewall configuration gap.
A guest's browser shows a certificate error before the captive portal login page appears. What causes this and what is the correct long-term fix for a production deployment?
Correct answer is D. The WLC generates its own self-signed TLS certificate for the internal HTTPS portal server. This certificate is not signed by any Certificate Authority in browsers' built-in trust stores (like DigiCert, Let's Encrypt, or a corporate CA). When the browser connects to https://1.1.1.1:8443, it checks the certificate, finds it untrusted, and displays a security warning. In a lab this is fine — users click Advanced and proceed. In a production guest network, the warning looks alarming and many users will refuse to continue, especially on corporate-managed devices with strict browser policies. The production fix is to upload a CA-signed certificate to the WLC. For a fully branded and trusted portal, External WebAuth with Cisco ISE gives you proper certificate management, full HTML/CSS customisation, and advanced guest management workflows in a single platform.
What is the functional difference between Web Policy "Authentication" and "Passthrough" on the Cisco WLC guest WLAN?
Correct answer is B. The portal type controls what happens when the guest arrives at the captive portal page — not how the redirect works. With Authentication, the portal presents a username/password form. The WLC (or RADIUS server) validates the credentials, and only matching accounts gain access. With Passthrough, the portal shows customisable text (a terms-of-use statement, organisation branding) and a single button. Clicking the button is sufficient — no identity verification occurs. Both types use the same redirect ACL mechanism; the difference is purely in what the portal requires from the user. Passthrough gives you MAC address logging (you can see who connected and when) without the friction of credential management. Authentication gives you stronger accountability — you know exactly who (visitor1, visitor2) was online and when. Neither type involves 802.1X EAP, which is a completely separate authentication framework for wired and wireless port security.
Which two ACL entries are non-negotiable in the preauthentication redirect ACL for WebAuth to function correctly end-to-end?
Correct answer is C. These two permits make the redirect mechanism work end-to-end. DNS permit: when the guest types any URL (http://example.com), the browser first performs a DNS lookup for example.com. Without the DNS permit, this lookup is denied — the browser gets a DNS resolution failure and never sends the HTTP GET that the WLC needs to intercept. No HTTP request = no redirect = portal never appears. HTTPS permit to Virtual IP port 8443: the WLC redirects the guest browser to https://1.1.1.1:8443/login.html. If the redirect ACL also denies HTTPS to 1.1.1.1, the browser sends the request but the ACL blocks it before it reaches the WLC's portal server — the portal page never loads. Both entries are essential. ARP and DHCP (option D) operate below the IP ACL level — WLC ACLs do not filter Layer 2 ARP frames, and DHCP typically completes before WebAuth is evaluated.
The organisation has 150–200 guest visitors per day and the administrator has been manually creating WLC Local Net Users for each. What is the scalability problem and the recommended solution?
Correct answer is A. WLC Local Net Users are designed for small-scale or lab deployments — a few accounts for a small office. At 150–200 guests per day, an administrator would need to create accounts daily, distribute credentials individually (email, printed card, front-desk staff), and manage expiry and cleanup — this is not sustainable. Cisco ISE solves this with a purpose-built Guest Lifecycle Management module: guests can self-register via a web portal (optionally requiring sponsor approval before getting credentials), sponsors can create time-limited credentials via the ISE Sponsor Portal without needing WLC access, accounts expire automatically, and usage is logged for compliance. The WLC WebAuth configuration is identical — only the AAA server in the WLAN Security → AAA Servers tab changes from local to the ISE RADIUS server IP. See AAA RADIUS Configuration.
show client summary on the WLC CLI shows a guest client with status WebAuth Reqd even after the user claims to have submitted the login form correctly. What should be checked first?
Correct answer is D. The status WebAuth Reqd persists until the WLC receives a successful authentication — it does not advance to Associated/RUN until credentials are validated and accepted. If the user submits the form and the password is wrong, the account is expired (Lifetime elapsed), the account is scoped to a different WLAN ID, or a RADIUS server rejects the credentials, the WLC redisplays the login form with an error and the client status remains WebAuth Reqd. The systematic check is: (1) Find the exact username in Security → Local Net Users — does it exist? Has the Lifetime expired? (2) Verify the WLAN ID on the account matches WLAN 2. (3) If using RADIUS, run
ping [RADIUS-IP] from the WLC CLI to confirm reachability, then check the RADIUS server's authentication log for the specific reason code (wrong password, account not found, authorisation policy mismatch).A new branch needs a guest WLAN where visitors accept a terms-of-use page with a single button click — no username or password required — and are given internet access immediately. Which WLC settings achieve this?
Correct answer is C. The scenario describes a classic click-through captive portal — no credentials, just terms acceptance. This is exactly what the WLC's Passthrough Web Policy provides. Layer 2 Security must be None (open SSID) so visitors can associate without knowing a WPA passphrase — a PSK would require distributing the key, which undermines the open guest model. Layer 3 Web Policy set to Passthrough presents a customisable splash page with an Accept button. Clicking Accept is the only requirement. No AAA server is needed. The preauthentication redirect ACL is still required to trigger the browser redirect to the splash page. Option D is incorrect — Web Policy Authentication always requires valid credentials. There is no automatic fallback to click-through mode when no AAA server is configured; in that state, authentication simply always fails and no guests get access.
Related Topics & Step-by-Step Tutorials
Related concepts and next steps:
- Wi-Fi Security – WPA2, WPA3 & EAP — Wi-Fi security — guest isolation best practices
- VLANs – Concepts & Overview — VLANs — guest VLAN isolation
- Firewalls – Concepts, Types, and Best Practices — firewall — guest network Internet access control
- Configuring a Wireless LAN Controller (WLC) — Gettin…
- Creating SSIDs and Mapping to VLANs on a Cisco WLC
- Private VLANs (PVLAN)