Web Authentication as a Fallback in 802.1X: Configuration and Use Cases

Web Authentication in the 802.1X Fallback Chain

The standard 802.1X fallback chain on a Cisco access port runs: 802.1X → MAB → Guest VLAN. When all three fail or are absent, the endpoint has no access. Web authentication inserts a fourth option between MAB and the Guest VLAN: endpoints that have no 802.1X supplicant and no MAB entry can still authenticate by opening a browser and submitting credentials through a captive portal.

This matters in several real-world scenarios:

Guest access in a conference center or lobby: Visitors arrive with personal laptops. They have no corporate 802.1X credentials and their MAC addresses are not in any ISE database. Web authentication allows them to self-register, accept an acceptable use policy, or use a sponsor-provided account — all without touching the endpoint's network configuration.

Contractor onboarding: A new contractor's laptop has not yet been provisioned with a corporate certificate or 802.1X supplicant configuration. Web authentication provides temporary access while provisioning occurs.

BYOD enrollment: An employee's personal device needs to be enrolled in the corporate MDM before receiving full 802.1X credentials. Web authentication is the access mechanism for the enrollment portal.

Legacy systems with no supplicant: A device that cannot run 802.1X (legacy industrial control hardware, embedded systems) and whose MAC address is not in the ISE database. Web authentication allows a human operator to authorize it through a browser on another device.

Two web authentication models are available on Cisco IOS XE:

• Local Web Authentication (LWA): The switch hosts the login page. Authentication is handled by the switch itself or forwarded to a RADIUS server.
• Central Web Authentication (CWA): ISE hosts the login page. The switch redirects HTTP/HTTPS traffic to ISE, and after authentication, ISE sends a CoA to the switch to change the port authorization.

CWA is the production-recommended model for ISE-integrated environments. LWA is simpler but lacks the policy richness and logging that ISE provides. This article covers both, with a focus on CWA.

Central Web Authentication (CWA) Architecture

The CWA flow involves more steps than standard 802.1X because the authentication does not happen at port connection time — it happens when the user opens a browser:

1. Endpoint connects to the switchport. 802.1X fails (no supplicant). MAB triggers.
2. Switch sends a RADIUS Access-Request to ISE using the endpoint's MAC address.
3. ISE does not recognize the MAC address (no endpoint entry). ISE returns an Access-Accept with a redirect URL and redirect ACL — placing the endpoint in a limited access state.
4. The switch places the port in a "redirect" authorization state — the endpoint gets an IP address from the pre-auth VLAN (typically the Guest VLAN 30 or a dedicated WebAuth VLAN), but all HTTP/HTTPS traffic is intercepted and redirected to the ISE portal URL.
5. The user opens a browser. The switch intercepts the HTTP request and redirects to the ISE Guest Portal.
6. The user enters credentials (or accepts AUP) on the ISE portal.
7. ISE authenticates the user against Active Directory, a local user database, or a sponsor-provisioned account.
8. ISE sends a CoA (Change of Authorization) Reauthenticate to the switch.
9. The switch triggers a new RADIUS authentication (MAB again, using the same MAC address).
10. This time, ISE recognizes the endpoint (it was registered during step 6) and returns the appropriate Access-Accept with VLAN and dACL attributes.
11. The switch applies the new authorization and the endpoint has the access defined by the ISE post-authentication policy.

This two-phase approach — MAB redirect, then MAB post-CWA — means CWA uses the MAB method as its transport. The switch never knows the user's credentials; ISE handles credential validation through the portal.

Switch Configuration for CWA

Global Configuration

aaa new-model

aaa authentication dot1x default group radius
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius

radius server ISE-Primary
 address ipv4 10.0.0.10 auth-port 1812 acct-port 1813
 key ISEsecret123

aaa server radius dynamic-author
 client 10.0.0.10 server-key ISEsecret123
 auth-type any

dot1x system-auth-control

ip device tracking

ip http server
ip http secure-server

The ip http server and ip http secure-server commands are required for the switch to intercept HTTP/HTTPS traffic and perform the redirect. These do NOT mean the switch's web management interface is open to endpoints — the redirect uses the HTTP intercept capability independent of management access. Restrict management access separately with appropriate ACLs on the management interface.

Redirect ACL

The redirect ACL defines which traffic the switch should redirect to the ISE portal and which traffic it should allow through before authentication (DNS, DHCP, ISE itself).

ip access-list extended ACL-WEBAUTH-REDIRECT
 10 deny  udp any any eq 53
 20 deny  udp any eq 67 any
 30 deny  udp any any eq 68
 40 deny  ip any host 10.0.0.10
 50 permit tcp any any eq 80
 60 permit tcp any any eq 443

Line-by-line:

• Lines 10-30: Deny (exclude from redirect) DNS and DHCP traffic. These must pass through without redirection so the endpoint can get an IP address and resolve hostnames.
• Line 40: Deny (exclude from redirect) traffic destined for ISE (10.0.0.10). The browser must reach ISE directly for the portal to load — if ISE-destined traffic is redirected back to ISE, you get a redirect loop.
• Lines 50-60: Permit (redirect) HTTP and HTTPS traffic. These are the triggers for the redirect. When the endpoint's browser sends an HTTP GET or HTTPS request to any destination, the switch intercepts it and redirects to the ISE portal.

The redirect ACL uses permit entries to indicate traffic that should be redirected, and deny entries to indicate traffic that should pass through normally. This is the opposite of the standard ACL logic, which causes significant confusion. In standard ACLs, permit = allow. In a redirect ACL on a CWA-configured port, permit = redirect to portal. Deny = do not redirect (allow to flow normally).

Apply the redirect ACL to the interface:

interface GigabitEthernet1/0/1
 description WebAuth Guest Port
 switchport mode access
 switchport access vlan 30
 authentication host-mode multi-auth
 authentication order dot1x mab
 authentication priority dot1x mab
 authentication port-control auto
 authentication event no-response action authorize vlan 30
 dot1x pae authenticator
 dot1x timeout tx-period 10
 dot1x max-reauth-req 2
 mab
 ip access-group ACL-DEFAULT in
 spanning-tree portfast

Note: the redirect ACL itself is not applied directly on the interface with ip access-group. It is pushed to the switch by ISE as a Cisco AVPair in the RADIUS Access-Accept at the MAB redirect phase. The interface has a default ACL (ACL-DEFAULT) that permits only DHCP and DNS before any authentication. Once ISE returns the redirect authorization, the switch applies the redirect ACL from the RADIUS attributes.

ISE Configuration for CWA

Step 1: Create the Guest Portal

Navigate to Work Centers > Guest Access > Portals & Components > Guest Portals.

Click Create. Select Sponsored Guest Portal or Self-Registered Guest Portal based on your requirements.

For a self-registered guest portal (visitors register their own accounts):

• Portal Name: Guest-Self-Registration
• Language: English
• Self Registration Fields: First Name, Last Name, Email Address
• AUP: Enabled (require acceptance)
• Post-Registration: Email credentials to guest

For a sponsored portal (a corporate employee sponsors guest access):

• Portal Name: Guest-Sponsored
• Sponsor Authentication: Active Directory (sponsors authenticate with corporate credentials)
• Guest Account Duration: 8 hours (business day)

Note the portal URL that ISE generates — it looks like https://10.0.0.10:8443/portal/PortalSetup.action?portal=<portal-id>. You will use this in the authorization profile.

Step 2: Create the CWA Authorization Profile (Redirect Phase)

Navigate to Policy > Policy Elements > Results > Authorization > Authorization Profiles.

Name: CWA-Redirect-Profile

• Access Type: ACCESS_ACCEPT
• Common Tasks:
  • Web Redirection: Centralized Web Auth
  • Redirect: [select the Guest-Self-Registration portal created above]
  • Redirect ACL: ACL-WEBAUTH-REDIRECT (must match the ACL name on the switch exactly — case-sensitive)
  • VLAN: 30 (Guest VLAN — provides limited pre-auth network access for portal loading)

This profile is returned by ISE during the initial MAB authentication. It puts the endpoint in VLAN 30 with HTTP/HTTPS traffic redirected to the guest portal. ISE automatically adds the following RADIUS attributes to this profile:

Cisco:cisco-av-pair = url-redirect=https://10.0.0.10:8443/portal/PortalSetup.action?portal=<id>
Cisco:cisco-av-pair = url-redirect-acl=ACL-WEBAUTH-REDIRECT

Step 3: Create the Post-CWA Authorization Profile

After the user authenticates on the portal, ISE triggers a CoA reauthentication. The second MAB request gets a different authorization profile — one that provides actual access.

Name: Guest-Internet-Access-Profile

• Access Type: ACCESS_ACCEPT
• Common Tasks:
  • VLAN: 30
  • Downloadable ACL: Guest-Internet-Only (defined in Article 16)

This profile has no redirect — the endpoint now has the access defined by the Guest-Internet-Only dACL.

Step 4: Configure Authorization Policy Rules

Navigate to Policy > Policy Sets > [your policy set] > Authorization Policy.

The rules must distinguish between the initial MAB request (redirect phase) and the post-CWA MAB request (access phase). ISE uses the endpoint's registration status to differentiate:

Rule 3 matches MAB sessions where the endpoint's MAC address is now associated with a registered guest account in ISE (after portal authentication). Rule 4 is the catch-all for unrecognized MAB sessions — sends them through the portal.

For ISE to associate a MAC address with a guest account after portal authentication, the Guest Portal must have MAC Address Registration or Self-Registration configured to create an endpoint entry linked to the guest account. This is the default behavior for ISE Self-Registered Guest portals.

Step 5: Configure CoA in ISE

For the CoA to reach the switch after portal authentication, ISE must know the switch is a valid CoA target. This is already configured if you created the Network Device entry for the Catalyst 9300 in Administration > Network Resources > Network Devices. Confirm the CoA port is enabled:

In the Network Device entry for SW1-C9300:

• RADIUS CoA: Enabled
• CoA Port: 1700 (default)

The switch must accept CoA from ISE on port 1700. Verify the aaa server radius dynamic-author block has ISE's IP (10.0.0.10) configured as a client.

Local Web Authentication (LWA) — When to Use It

Local WebAuth uses the switch's built-in HTTP server to host a login page and forwards credentials to RADIUS. It is simpler to configure than CWA but has significant limitations:

• No ISE guest portal customization (logo, AUP, self-registration)
• Credentials are processed on the switch, not ISE
• No CoA — authentication happens at connect time only
• Limited logging and audit trail compared to ISE Live Logs

LWA is appropriate for small branch office deployments where ISE is not deployed, or for environments using a simple RADIUS server for guest authentication without the ISE policy engine.

LWA Configuration (for reference)

ip admission name WEBAUTH proxy http

ip access-list extended ACL-PREAUTH
 10 permit udp any any eq 67
 20 permit udp any any eq 68
 30 permit udp any any eq 53
 40 deny   ip any any

interface GigabitEthernet1/0/2
 description LWA Guest Port
 switchport mode access
 switchport access vlan 30
 ip access-group ACL-PREAUTH in
 ip admission WEBAUTH
 authentication port-control auto
 authentication order mab
 mab
 spanning-tree portfast

LWA on IOS XE 17.9.x requires the ip admission feature. The switch presents a login form when users browse to any HTTP URL. Credentials entered are forwarded to the RADIUS server configured under aaa authentication login for WebAuth authentication.

In most enterprise deployments with ISE, use CWA. LWA is documented here for completeness and for edge cases where CWA infrastructure is unavailable.

Verifying CWA Operation

Before Portal Authentication (Redirect Phase)

SW1# show authentication sessions interface GigabitEthernet1/0/1 detail

            Interface:  GigabitEthernet1/0/1
          MAC Address:  3c22.fb01.aabb
         IPv6 Address:  Unknown
         IPv4 Address:  10.0.30.102
           User-Name:  3c-22-FB-01-AA-BB
              Status:  Authorized
              Domain:  DATA
      Oper host mode:  multi-auth
    Oper control dir:  both
     Session timeout:  N/A
  Common Session ID:  0A00630A0000001A
    Acct Session ID:  0x0000001A
             Handle:  0x1C000010
     Current Policy:  POLICY_Gi1/0/1

Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)

Server Policies:
            URL Redirect ACL: ACL-WEBAUTH-REDIRECT
            URL Redirect: https://10.0.0.10:8443/portal/PortalSetup.action?portal=abc123
            Vlan Group:  Vlan: 30

Method status list:
       Method           State
       mab              Authc Success

Key lines to note:

• URL Redirect ACL: ACL-WEBAUTH-REDIRECT — the redirect ACL name pushed by ISE
• URL Redirect: https://10.0.0.10:8443/... — the ISE portal URL
• Vlan Group: Vlan: 30 — the endpoint is in the pre-auth Guest VLAN
• Status: Authorized — the MAB authentication succeeded (ISE returned Access-Accept with redirect attributes); the endpoint has limited connectivity, not full denial

After Portal Authentication (Post-CoA)

SW1# show authentication sessions interface GigabitEthernet1/0/1 detail

            Interface:  GigabitEthernet1/0/1
          MAC Address:  3c22.fb01.aabb
         IPv6 Address:  Unknown
         IPv4 Address:  10.0.30.102
           User-Name:  guest@example.com
              Status:  Authorized
              Domain:  DATA
      Oper host mode:  multi-auth
    Oper control dir:  both
     Session timeout:  28800s (server), Remaining: 28611s
  Common Session ID:  0A00630A0000001B
    Acct Session ID:  0x0000001B
             Handle:  0x1C000011
     Current Policy:  POLICY_Gi1/0/1

Local Policies:
        Service Template: DEFAULT_LINKSEC_POLICY_SHOULD_SECURE (priority 150)

Server Policies:
            Vlan Group:  Vlan: 30
                  ACS ACL: xGENIEx0a00630a0000001b-1-xGENIEx

Method status list:
       Method           State
       mab              Authc Success

After CoA reauthentication:

• The redirect URL and redirect ACL are gone — no more redirection
• User-Name has changed from the MAC address format to the guest's email address — ISE linked the MAC to the guest account
• A dACL (ACS ACL) is now applied — the endpoint has the Guest-Internet-Only policy
• Session timeout of 28800 seconds (8 hours) is set — matching the guest account duration

Troubleshooting

Symptom: Endpoint is in VLAN 30 but browser redirect is not happening — endpoint can browse normally without portal authentication

Cause: The redirect ACL on the switch is not matching the ISE-pushed ACL name, or the redirect ACL permit entries are not matching the browser's HTTP traffic.

Fix: Verify the URL redirect ACL name in show authentication sessions detail matches the ACL name configured on the switch:

SW1# show ip access-lists ACL-WEBAUTH-REDIRECT

If the ACL does not exist, create it as described in the configuration section. The name must be an exact case-sensitive match to what ISE sends in the url-redirect-acl AVPair. Also confirm ip http server and ip http secure-server are enabled — without these, the switch cannot intercept HTTP/HTTPS traffic for redirection.

Symptom: Portal loads correctly, user submits credentials, but ISE shows no CoA being sent and the switch remains in redirect state

Cause 1: ISE cannot send CoA to the switch because the switch IP is not in the aaa server radius dynamic-author client list.

Fix: On the switch, verify:

SW1# show aaa server radius dynamic-author

Dynamic author clients:
  Client: 10.0.0.10, Server key: configured

If the client entry is missing, add it:

aaa server radius dynamic-author
 client 10.0.0.10 server-key ISEsecret123

Cause 2: A firewall between ISE and the switch is blocking CoA UDP packets on port 1700.

Fix: Verify CoA reachability. From ISE, navigate to Operations > Troubleshoot > Diagnostic Tools > General Tools > CoA Test. Enter the switch IP (10.0.99.1) and test. If the test fails, check for firewall rules between 10.0.0.10 and 10.0.99.1 on UDP port 1700.

Symptom: Guest portal page shows "Certificate Error" or "Connection Not Trusted" in the browser

Cause: The ISE portal HTTPS certificate is self-signed or issued by an internal CA not trusted by the guest device's browser. Guest devices (personal laptops, phones) typically do not have the internal CA in their trust store.

Fix: ISE 3.2 supports publicly trusted certificates on the Guest Portal HTTPS listener. Navigate to Administration > System > Certificates > System Certificates. Install a publicly trusted certificate (e.g., from DigiCert, Let's Encrypt, or your public CA) and assign it to the Portal role. Guests' devices trust public CAs by default, eliminating the certificate error.

Alternatively, configure the redirect URL to use HTTP (port 8080) for the initial redirect if your security policy permits it — guests will see a non-secure portal warning but won't get a hard certificate error blocking access. This is not recommended for production but may be acceptable in low-security environments.

Symptom: CWA works for the first guest but subsequent guests on the same port go straight to internet access without portal authentication

Cause: The first guest's MAC address is still in the ISE endpoint database as a registered guest. When the second guest uses a different device, the new MAC gets redirected correctly. But if they reuse a device that was previously registered (or if endpoint registration is not session-bound), ISE may match the pre-existing endpoint record and skip the redirect.

Fix: Configure ISE Guest Portal to use Purge Guest Accounts after account expiration. Navigate to Work Centers > Guest Access > Settings > Guest Account Purge Policy. Set the purge schedule to remove expired guest accounts and their associated endpoint registrations. This ensures each new guest session requires fresh portal authentication.

Also, verify the authorization rule order. Rule 3 (Guest-Registered) must only match when the endpoint is associated with an ACTIVE guest account. Use the condition GuestUser:Status EQUALS ACTIVE to prevent expired guest account registrations from bypassing the portal.

What's Next

Article 19 — Change of Authorization (CoA) in 802.1X: How It Works and How to Configure It: CoA is the mechanism that makes CWA work — and it is also essential for posture-based access, dynamic policy changes, and session termination. Article 19 covers the full CoA architecture, IOS XE and ISE configuration, the different CoA types (reauthenticate, disconnect, port-bounce), and how to troubleshoot CoA failures.