9.3 Enterprise Guest Networking, Web-Auth & Foreign/Anchor Mobility Tunnels

9.3 Enterprise Guest Networking, Web-Auth & Foreign/Anchor Mobility Tunnels

Core Blueprint Focus: Deploying secure, isolated guest wireless access while protecting internal campus enterprise resources is a pivotal component of Domain 5.0 (Client Connectivity Configuration). The Cisco Foreign-Anchor mobility architecture segregates untrusted guest traffic by tunneling client sessions from internal campus controllers directly to dedicated Anchor controllers residing in the perimeter Demilitarized Zone (DMZ). Mastering the migration from legacy AireOS EoIP (protocol 97) to Catalyst 9800 CAPWAP mobility (UDP ports 16666 and 16667), symmetric mobility tunneling mechanics, and Cisco ISE Central Web Authentication (CWA) redirect and Change of Authorization (CoA) workflows is essential for the WLCOR 350-101 exam.

---

1. Enterprise Guest Isolation Architecture & The DMZ

Enterprise organizations routinely provide wireless access to visiting contractors, clients, auditors, and vendors. However, guest devices are fundamentally untrusted: they are personally owned (BYOD), lack corporate endpoint management agents (MDM/EDR), may harbor malware or botnets, and are operated by unvetted users.

The Security Mandate for Guest Isolation

Security policy and applicable compliance controls commonly require guest access to be segmented from protected enterprise resources. The exact obligation depends on the organization, data, threat model, and applicable standard; PCI DSS, HIPAA, ISO 27001, and SOC 2 should not be summarized as one identical prescriptive guest-network mandate:

• No Local Corporate-VRF Exposure: Do not bridge or locally route guest client traffic into protected corporate VLANs or VRFs. In a Foreign/Anchor design, the encapsulated mobility tunnel still traverses the enterprise transport to reach the DMZ anchor.
• Containment of Broadcast and Malicious Probing: Isolating guest traffic prevents broadcast storms, ARP poisoning attacks, and unauthorized port scanning from reaching internal enterprise endpoints.

+-----------------------------------------------------------------------------------------+
|                        ENTERPRISE PERIMETER DMZ ARCHITECTURE                            |
|                                                                                         |
|  [ INTERNAL CAMPUS CORE ]               [ SCREENED PERIMETER DMZ ]          [ INTERNET ]|
|                                                                                         |
|  +--------------------+             +-----------------------------+                     |
|  | Internal Corporate |             |     PERIMETER DMZ ZONE      |                     |
|  |   Campus Network   |             |                             |                     |
|  |                    |             |  +-----------------------+  |                     |
|  |  +--------------+  |             |  | Catalyst 9800 Anchor  |  |    +--------------+ |
|  |  | Catalyst 9800|  |             |  | WLC (Terminates Guest |  |    | External     | |
|  |  | Foreign WLC  |  |             |  | Tunnels & Guest SVIs) |  |    | Perimeter FW | |
|  |  +-------+------+  |             |  +-----------+-----------+  |    +-------+------+ |
|  +----------|---------+             +--------------|--------------+            |        |
|             |                                      |                           |        |
|             | [Internal Firewall]                  | [Direct Internet Breakout]|        |
|             +======================================+===========================+        |
|                    Mobility Control (UDP 16666 - DTLS)                                  |
|                    Mobility Data    (UDP 16667 - CAPWAP)                                |
+-----------------------------------------------------------------------------------------+

The Screened Perimeter DMZ Architecture

To enforce total isolation, network architects deploy an Anchor Wireless LAN Controller inside a perimeter Demilitarized Zone (DMZ) positioned between an Internal Perimeter Firewall and an External Perimeter Firewall:

• Campus APs register exclusively to the internal Foreign WLC.
• When guests associate to the Guest SSID, their 802.11 frames are encapsulated by the Foreign WLC into a secure mobility tunnel and forwarded across the internal firewall to the DMZ Anchor WLC.
• The DMZ Anchor WLC terminates the mobility tunnel, bridges the guest traffic into an isolated DMZ VLAN, and routes packets directly through the external perimeter firewall to the Internet.
• Guest client payload remains encapsulated through the campus transport and exits at the anchor’s configured VLAN, avoiding local guest routes in protected corporate VRFs.

---

2. Foreign / Anchor Mobility Architecture

Cisco inter-controller mobility divides responsibilities between two distinct architectural roles:

+-----------------------------------------------------------------------------------------+
|                         FOREIGN / ANCHOR ARCHITECTURAL ROLES                            |
|                                                                                         |
|  CAMPUS FOREIGN CONTROLLER (Internal WLC)   DMZ ANCHOR CONTROLLER (Perimeter WLC)       |
|  ----------------------------------------   -------------------------------------       |
|  - Terminates physical campus AP CAPWAP     - Resides in perimeter DMZ network          |
|    tunnels (UDP 5246 Control, 5247 Data)    - Does NOT terminate physical campus APs    |
|  - Advertises Guest SSID over the air       - Hosts Layer 3 Guest SVI & DHCP Relay/Pool |
|  - Manages 802.11 RF associations & RRM     - Terminates guest client mobility sessions |
|  - Maps Guest Policy Profile to an          - Acts as RADIUS client to Cisco ISE for    |
|    Export Anchor pointing to the DMZ WLC      Central Web Authentication (CWA) redirect |
|  - Forwards guest frames into mobility      - Breaks out guest data traffic directly    |
|    tunnel toward DMZ Anchor                   through DMZ firewall to the Internet      |
+-----------------------------------------------------------------------------------------+

Mobility Groups vs. Mobility Peers

• Mobility Group: A logical administrative collection of controllers sharing client roaming state, PMK security contexts, and controller redundancy. Controllers in the same mobility group share an identical, case-sensitive Mobility Group Name.
• Mobility Peers: Two controllers explicitly configured with each other's IP addresses and public cryptographic keys to establish control tunnels. Foreign and Anchor controllers can reside in the same mobility group or belong to different mobility groups linked as configured mobility peers.

Tag-Based Policy Profile Configuration

On the Cisco Catalyst 9800 Foreign WLC, the Guest WLAN is linked via tags to a Policy Profile configured with an Export Anchor:

• Under the Policy Profile Mobility configuration, the administrator adds the DMZ Anchor WLC's management IP as the primary mobility anchor.
• When a client associates to the Guest SSID on a campus AP, the Foreign WLC immediately triggers an inter-controller handshake, offloading client session ownership to the DMZ Anchor WLC.

---

3. Mobility Protocol Mechanics: Legacy EoIP vs. Modern CAPWAP Mobility

A critical evolution between legacy Cisco AireOS controllers and modern Cisco Catalyst 9800 (IOS-XE) controllers is the transport protocol used for inter-controller mobility tunnels.

+-----------------------------------------------------------------------------------------+
|                         MOBILITY PROTOCOL EVOLUTION MATRIX                              |
|                                                                                         |
|  PROTOCOL ATTRIBUTE       LEGACY AIREOS MOBILITY       CATALYST 9800 CAPWAP MOBILITY    |
|  ------------------       ----------------------       -----------------------------    |
|  Control Plane Transport  UDP Port 16666 (Cleartext    UDP Port 16666 (Mandatory        |
|                           or Optional DTLS)            DTLS Encrypted)                  |
|  Data Plane Transport     Ethernet-over-IP (EoIP)      CAPWAP Data (UDP Port 16667)     |
|                           IP Protocol 97               with Optional DTLS Encryption    |
|  Firewall Traversal       Difficult (Firewalls block   Firewall Friendly (Standard UDP  |
|                           raw IP protocol 97)          ports 16666 & 16667)             |
|  NAT Traversal            Unsupported / Breaks EoIP    Fully Supported via UDP          |
|  Symmetric Tunneling      Configurable (Asymmetric     Mandatory (Bidirectional         |
|                           was legacy default)          Symmetric Tunneling Enforced)    |
+-----------------------------------------------------------------------------------------+

Legacy AireOS EoIP (Protocol 97)

In legacy AireOS environments, mobility data was encapsulated using Ethernet-over-IP (EoIP), assigned IANA IP Protocol 97:

• EoIP wrapped the client Layer 2 Ethernet frame directly inside an outer IPv4 header without an intermediate Layer 4 UDP or TCP header.
• Firewall Operational Flaw: Enterprise firewalls separating the campus core from the DMZ strictly inspect Layer 4 TCP/UDP state. Firewalls frequently dropped raw IP protocol 97 packets unless explicitly permitted by custom protocol inspection rules. Furthermore, Network Address Translation (NAT) devices could not translate protocol 97, preventing controllers behind NAT boundaries from establishing mobility data tunnels.

Catalyst 9800 CAPWAP Mobility (UDP 16666 & 16667)

Cisco Catalyst 9800 IOS-XE controllers replaced EoIP with standardized, firewall-friendly CAPWAP-based mobility tunneling:

1. Mobility Control Tunnel (UDP Port 16666):
   • Carries mobility handshakes, client anchor negotiation, roaming context transfers, and ping keepalives.
   • Cryptographic Requirement: Mandatorily secured using Datagram Transport Layer Security (DTLS). The control tunnel authenticates peers using pre-shared keys (hash keys) or PKI X.509 certificates.
2. Mobility Data Tunnel (UDP Port 16667):
   • Encapsulates client data frames inside standard UDP datagrams using CAPWAP data headers.
   • Standard UDP transport traverses intermediate enterprise firewalls and NAT gateways seamlessly.
   • Data DTLS Encryption: Can optionally be enabled in software/hardware to encrypt guest data payloads traversing internal campus switches.

Symmetric vs. Asymmetric Mobility Tunneling

• Asymmetric Mobility Tunneling (Deprecated): Under asymmetric tunneling, outbound client packets traveled from Foreign WLC -> Anchor WLC -> Internet. However, return packets arriving at the DMZ gateway were routed directly back to the Foreign WLC across internal Layer 3 links, bypassing the Anchor WLC. Because outbound and inbound paths traversed different firewall interfaces, stateful firewalls dropped return packets due to missing TCP SYN/ACK state, and Unicast Reverse Path Forwarding (uRPF) flagged the packets as spoofed. Asymmetric mobility is unsupported on Catalyst 9800.
• Symmetric Mobility Tunneling (Mandatory): Enforced natively on the Catalyst 9800. Both egress and ingress client traffic traverse the identical bidirectional CAPWAP data tunnel (UDP 16667) between the Foreign and Anchor WLCs. The Anchor WLC serves as the sole Layer 3 default gateway, preserving stateful firewall integrity.

---

4. End-to-End Guest Onboarding Lifecycle with Cisco ISE Central Web Authentication (CWA)

Enterprise guest deployments rarely use pre-shared keys; instead, they implement Central Web Authentication (CWA) orchestrated by Cisco Identity Services Engine (ISE). CWA provides captive portal workflows, self-service guest registration, SMS credential delivery, sponsored approvals, and acceptable use policy (AUP) enforcement.

+-----------------------------------------------------------------------------------------+
|                            END-TO-END ISE CWA PACKET FLOW                               |
|                                                                                         |
|  [Guest Client]     [Campus AP]      [Foreign WLC]      [Anchor WLC]       [Cisco ISE]  |
|        |                 |                 |                  |                 |       |
|        |-- 1. 802.11 Assoc --------------> |                  |                 |       |
|        |                 |                 |-- 2. Anchor Init (UDP 16666)-----> |       |
|        |                 |                 |<-- 2. Anchor ACK ----------------- |       |
|        |-- 3. DHCP Discover (UDP 67) ----> |-- 3. CAPWAP Data (UDP 16667)-----> |       |
|        |<-- 3. DHCP Offer (172.20.100.55)- |<-- (From DMZ DHCP Server)--------- |       |
|        |                 |                 |                  |-- 4. RADIUS MAB ------->|
|        |                 |                 |                  |<-- 4. Access-Accept ----||
|        |                 |                 |                  |    (Redirect ACL + URL) |
|        |-- 5. HTTP GET (neverssl.com) ---> |-- (Tunneled) --> |                         |
|        |<-- 5. HTTP 302 Redirect (ISE Portal URL) ----------- |                         |
|        |                                                      |                         |
|        |== 6. HTTPS (Port 8443) Direct to ISE Portal ==================================>|
|        |   (Guest Enters Credentials / Accepts AUP Terms on Cisco ISE Portal)           |
|        |                                                      |                         |
|        |                 |                 |                  |<-- 7. RADIUS CoA -------|
|        |                 |                 |                  |    (RFC 5176 / UDP 1700)|
|        |                 |                 |                  |-- 7. CoA-ACK ---------->|
|        |                 |                 |                  |                         |
|        |                 |                 |                  | (Removes Redirect ACL;  |
|        |                 |                 |                  |  Applies Permit ACL)    |
|        |-- 8. Unrestricted Outbound Web Traffic (Direct Internet Breakout via DMZ FW) ->|
+-----------------------------------------------------------------------------------------+

The 7-Step Packet-Level Workflow

1. Association & Mobility Anchor Session Establishment:
   • The guest client associates to an open or Opportunistic Wireless Encryption (OWE) SSID broadcast by the campus AP.
   • The Foreign WLC inspects its Policy Profile, detects the Export Anchor configuration, and transmits a mobility control message (Anchor_Request) over UDP port 16666 to the DMZ Anchor WLC.
   • The DMZ Anchor WLC acknowledges the session, allocates an anchor client block, and establishes the UDP 16667 data tunnel.
2. DMZ IP Address Allocation via DHCP:
   • The client broadcasts a DHCP Discover.
   • The campus AP encapsulates the frame inside CAPWAP data (UDP 5247) to the Foreign WLC, which encapsulates it inside the mobility data tunnel (UDP 16667) to the Anchor WLC.
   • The Anchor WLC bridges the packet into the DMZ Guest VLAN (e.g., VLAN 500, 172.20.100.0/24).
   • A DMZ DHCP server assigns an IP address (172.20.100.55), subnet mask, DNS servers (8.8.8.8), and default gateway (pointing to the DMZ firewall or Anchor WLC SVI).
3. Initial RADIUS Authentication & Pre-Auth Redirection:
   • The Anchor WLC acts as the Network Access Server (NAS) and initiates a MAC Authentication Bypass (MAB) RADIUS Access-Request to Cisco ISE on UDP port 1812.
   • Cisco ISE identifies that the MAC address is unauthenticated and evaluates its Guest Authorization Policy.
   • ISE returns a RADIUS Access-Accept containing two Cisco Vendor-Specific Attributes (AV-pairs):
     • cisco-av-pair = url-redirect-acl=GUEST_REDIRECT_ACL
     • cisco-av-pair = url-redirect=https://ise01.corp.local:8443/portal/gateway?sessionId=0a0a0a0a...&action=cwa
   • The Anchor WLC places the client into the WEBAUTH_PENDING state and binds the redirect ACL and URL to the client's session.
4. Redirect ACL Mechanics on the Catalyst 9800:
   • CRITICAL EXAM CONCEPT: On Cisco Catalyst 9800 WLCs, redirect ACLs operate on inverted interception logic:
     • A permit rule EXEMPTS traffic from redirection (traffic passes normally without interception).
     • A deny rule (or implicit unpermitted traffic) TRIGGERS the HTTP interception engine, redirecting the browser session to the ISE portal URL.
   • The redirect ACL must permit DNS, DHCP, and traffic destined to the Cisco ISE server:

     ip access-list extended GUEST_REDIRECT_ACL
      permit udp any any eq domain
      permit udp any any eq bootps
      permit udp any any eq bootpc
      permit tcp any host 10.200.10.50 eq 8443
      deny tcp any any eq www
      deny tcp any any eq 443
     

5. Web Traffic Interception & Portal Submission:
   • The user opens a browser and navigates to an HTTP website (e.g., http://neverssl.com).
   • The packet hits the deny tcp any any eq www rule in the redirect ACL.
   • The Anchor WLC intercepts the TCP port 80 SYN/GET request, terminates the TCP session locally, and returns an HTTP 302 Redirect response containing the ISE portal URL with the client's MAC address and unique audit session ID embedded in the query string.
   • The client's browser connects to Cisco ISE over HTTPS on port 8443 (https://ise01.corp.local:8443/...).
   • The guest registers, enters sponsor credentials, or clicks "Accept" on the Acceptable Use Policy (AUP). If posture assessment is enabled, the Cisco Secure Client (AnyConnect) Temporal Agent evaluates host compliance.
6. RADIUS Change of Authorization (CoA):
   • Once authentication succeeds on the ISE portal, Cisco ISE initiates a RADIUS Change of Authorization (CoA) request conforming to RFC 5176.
   • ISE transmits a CoA-Reauth or Disconnect-Request packet to the Anchor WLC on UDP destination port 1700 (or port 3799).
   • The Anchor WLC acknowledges the CoA with a CoA-ACK on UDP 1700.
7. Post-Auth State & Unrestricted Internet Access:
   • Upon receiving the CoA, the Anchor WLC clears the WEBAUTH_PENDING flag, detaches the GUEST_REDIRECT_ACL, and applies the post-authentication authorization profile (e.g., attaching a GUEST_PERMIT_ACL or assigning an unrestricted VLAN).
   • The client transitions into the operational RUN state.
   • All subsequent client web requests route directly through the DMZ firewall to the Internet without redirection.

---

5. Catalyst 9800 CLI Configuration & Operational Verification

Deploying and troubleshooting mobility tunnels requires configuring mobility peers, verifying tunnel encryption, and inspecting client mobility states via the Cisco IOS-XE CLI.

Step-by-Step Configuration on Catalyst 9800 Foreign WLC

! Configure the Mobility Group and Peer on the Foreign WLC (Campus Core)
C9800-Foreign(config)# wireless mobility group name CAMPUS-MOBILITY
C9800-Foreign(config)# wireless mobility mac-address 00a3.d144.1101
C9800-Foreign(config)# wireless mobility peer ip 192.168.100.10
C9800-Foreign(config-mobility-peer)# group DMZ-MOBILITY
C9800-Foreign(config-mobility-peer)# data-encrypt
C9800-Foreign(config-mobility-peer)# exit

! Configure the Guest Policy Profile with Export Anchor
C9800-Foreign(config)# wireless profile policy GUEST_POLICY_PROFILE
C9800-Foreign(config-wireless-policy)# no shutdown
C9800-Foreign(config-wireless-policy)# mobility anchor 192.168.100.10 priority 1
C9800-Foreign(config-wireless-policy)# exit

Step-by-Step Configuration on Catalyst 9800 Anchor WLC

! Configure the Mobility Group and Peer on the Anchor WLC (DMZ)
C9800-Anchor(config)# wireless mobility group name DMZ-MOBILITY
C9800-Anchor(config)# wireless mobility mac-address 00a3.d188.9902
C9800-Anchor(config)# wireless mobility peer ip 10.10.10.10
C9800-Anchor(config-mobility-peer)# group CAMPUS-MOBILITY
C9800-Anchor(config-mobility-peer)# data-encrypt
C9800-Anchor(config-mobility-peer)# exit

! Configure the Guest Policy Profile acting as Anchor
C9800-Anchor(config)# wireless profile policy GUEST_POLICY_PROFILE
C9800-Anchor(config-wireless-policy)# no shutdown
C9800-Anchor(config-wireless-policy)# vlan GUEST_VLAN_500
C9800-Anchor(config-wireless-policy)# mobility anchor
C9800-Anchor(config-wireless-policy)# exit

Operational Verification Commands

Engineers verify mobility tunnel health and client state using the following diagnostic commands:

! 1. Verify Mobility Tunnel Operational Status (Control UDP 16666 & Data UDP 16667):
C9800-Foreign# show wireless mobility summary

Mobility Peer List:
IP Address      Group Name       Control State   Data State   Data Path DTLS
----------------------------------------------------------------------------
192.168.100.10  DMZ-MOBILITY     Up              Up           Enabled

! 2. Verify Foreign/Anchor Client Association Detail on the Anchor WLC:
C9800-Anchor# show wireless client mac-address a483.e722.9104 detail

Client MAC Address : a483.e722.9104
Client IPv4 Address : 172.20.100.55
Client State : UP (RUN)
WLAN ID : 2
WLAN Profile Name : Guest-WLAN
Wireless Policy Profile : GUEST_POLICY_PROFILE
Mobility Role : Export Anchor
Mobility Foreign IP : 10.10.10.10
Redirect ACL : None (Cleared post-CoA)
Policy Type : WPA2
Authentication Method : Central Web Authentication

! 3. Inspect Client State on the Foreign WLC:
C9800-Foreign# show wireless client mac-address a483.e722.9104 detail

Client MAC Address : a483.e722.9104
Mobility Role : Export Foreign
Mobility Anchor IP : 192.168.100.10
AP Name : AP-Floor2-North
Radio Slot ID : 1 (5 GHz)