I85PREP
⌘ K
ENWLSI 300-430 study materials
ENWLSI 300-430 study resources

Guest Anchor Design After a DMZ Firewall Tightening

ENWLSI 300-430 · Put your knowledge to work in context.

All case studies

Guest Anchor Design After a DMZ Firewall Tightening

Mercato Retail has 260 stores. Each store runs three Catalyst 9115 APs in FlexConnect local switching, joining a C9800-L in a regional data center. The guest WLAN is centrally switched and anchored to a C9800-L in a DMZ, where guests receive addresses from a /23 DMZ DHCP scope and authenticate on the anchor's built-in web portal. Since the security team tightened DMZ firewall policy, guests in about 40 stores associate successfully and receive an IP address, but the login page never renders: browsers time out, iPhone captive-portal detection reports no internet, and clients are deauthenticated after roughly 90 seconds. In the stores that still work, guest throughput is around 2 Mbps and the DMZ anchor shows sustained 60 percent CPU. There is one anchor per region with no redundancy, and the design standard requires guest traffic to exit through the DMZ for logging.

1. Guests get an IP address but never see the portal. Walk through the traffic path and identify, in order, what you would check to find where it breaks.

Read the worked answer

The path Client -> store AP (FlexConnect, local switching not used for guest) -> CAPWAP to the regional C9800-L (foreign) -> mobility tunnel to the DMZ anchor (control UDP 16667, data UDP 16666 or IP protocol 97 if EoIP is used) -> anchor guest VLAN -> DMZ switch -> firewall -> internet.

Why "gets an IP" narrows it DHCP succeeded, so the mobility control and data tunnels are almost certainly up and the anchor's guest VLAN and DHCP relay are working. The failure is in the portal/redirect path, not in mobility.

Check in this order

  1. Pre-auth ACL on the guest WLAN: it must permit DHCP, DNS to the client's resolvers, and HTTP/HTTPS to whatever the portal and OS captive-portal detection need. If DNS is blocked, the portal hostname never resolves.
  2. Captive-portal detection endpoints. iOS uses captive.apple.com, Android uses connectivitycheck.gstatic.com or clients3.google.com, Windows uses msftconnecttest.com. If the firewall now drops these, the OS never launches the mini-browser even though the WLC redirect works.
  3. The redirect itself. Web auth returns an HTTP 302 to the virtual interface (192.0.2.1 by default). That address must be reachable from the guest subnet, or the redirect has to point at a routable portal hostname. A firewall rule that blocks RFC 5737 space or the old virtual IP breaks the redirect while leaving DHCP intact.
  4. Session timeout and idle timeout on the WLAN: a 90 s deauthentication smells like a sleep/session timeout expiring while the client sits unauthenticated, not like a firewall reset.
  5. DNS from the guest VLAN through the firewall: resolve a public name from a test guest client.

Most likely single cause A tightened firewall rule set blocking the pre-auth destinations (detection endpoints and/or the portal), not a broken anchor.

2. The design standard requires DMZ egress and the business wants no guest outage if the DMZ anchor fails. What redundancy model would you implement, and what are its limits?

Read the worked answer

What to implement

  • On the guest WLAN, configure multiple anchors with priorities: primary anchor in region A, secondary anchor in region B, and optionally a tertiary. The foreign controller falls back when its highest-priority anchor is unreachable, and the fallback is per-WLAN.
  • Optionally place the anchors themselves in an HA SSO pair so an individual anchor chassis failure does not drop the tunnel.
  • Keep identical SSID, security policy, virtual interface behavior, and mobility group name on every anchor, and make sure the virtual interface IPs are unique per controller.
  • Open the firewall for mobility between the foreign controllers and every anchor: control UDP 16667 and data UDP 16666, or IP protocol 97 when the mobility tunnel is configured for EoIP.

Limits you must state to the business

  • Anchor fallback is not hitless. Clients on the failed anchor are dropped and must reassociate to the WLAN, get a new address from the other region's scope, and re-authenticate on the portal. Expect a visible outage measured in tens of seconds to minutes.
  • Anchor priority protects against an anchor or tunnel failure, not against the regional data center being unreachable from the store; if the foreign controller is unreachable, guest is down regardless of how many anchors exist.
  • Firewall state matters: if the DMZ firewall is stateful and asymmetric, a fallback anchor in another region may be reachable on control but not on data, producing exactly the "associates, no data" symptom you are trying to avoid. Test fallback, do not assume it.
  • Document that DHCP scope design must cover the sum of guests across the regions that can fail over to each anchor, or fallback will succeed and then fail on scope exhaustion.

3. Guest throughput is about 2 Mbps and the anchor is at 60 percent CPU. What is causing that, and what are the realistic architectural options given the DMZ logging requirement?

Read the worked answer

Why it is slow

  • Every guest frame is hairpinned: store AP to regional foreign controller over CAPWAP, then through the mobility data tunnel to the DMZ anchor, then back out through the DMZ firewall. Two tunnel encapsulations and a firewall inspection path per packet.
  • The anchor's data plane is sized for a modest centralized guest load; at 60 percent CPU with only a few hundred guests it is close to being the bottleneck, and its throughput ceiling may be far below the sum of store uplinks.
  • Centrally switched guest traffic also shares the store's CAPWAP path with corporate traffic, so a busy guest can degrade corporate WLAN performance.

Options, in order of preference

  1. Keep authentication and logging centralized but switch data locally: terminate guest on a per-store guest VLAN with FlexConnect local switching, break out to the internet through a store firewall, and ship the logging/accounting feeds to the same central collector. This satisfies the intent of the standard and removes the hairpin. Confirm with security that "DMZ egress" means "inspected egress", not literally "one DMZ in one region".
  2. Keep anchoring but distribute it: an anchor per region sized for the regional guest peak, with multiple anchors per WLAN and per-store anchor priority. Throughput improves per region but the hairpin remains.
  3. If neither is possible, cap guest bandwidth per client and per WLAN so the anchor degrades gracefully instead of saturating, and monitor the anchor CPU as a capacity alarm.

Do not simply raise the per-client rate limit; the constraint is the anchor data path, not policy.