Mist AP Onboarding Through an Explicit Proxy and TLS Inspection
A retail chain is deploying 32 new stores, each with 14 Mist AP45 access points and one EX switch. Corporate policy permits outbound traffic only through an explicit proxy; the firewall allows TCP 443 to a small allowlist but blocks UDP 123 and direct DNS from store VLANs. At 11 stores, APs obtain DHCP addresses but remain disconnected in Mist and store Wi-Fi is down. At the other 21 stores, APs connect but raise intermittent AP offline alerts every 6-10 hours. Each store has a /24 management VLAN with 200 addresses, a /24 guest VLAN, and a /24 POS VLAN. The proxy requires authentication for some destinations, and TLS inspection is enabled on the firewall. A junior engineer proposes static IPs and a local NTP server on the switch. The rollout deadline is 10 days.
1. Why can APs get DHCP addresses yet remain disconnected, and what should be verified first?
Read the worked answer
DHCP only proves that the AP reached a local DHCP server; it does not prove cloud reachability. A Mist AP also needs working DNS, accurate time, and outbound TCP 443 to the Mist cloud, and in this environment it must traverse an authenticated explicit proxy that is also doing TLS inspection. Static IPs and a local NTP server do not fix proxy authentication, an incomplete allowlist, or a certificate that the AP does not trust because the firewall is intercepting TLS. Verify first from the management VLAN: DNS resolution, proxy reachability and authentication for the AP, and firewall/proxy logs for blocked or inspected sessions to the Mist endpoints. Confirm the AP has a valid clock. If the AP cannot reach the cloud at all, proxy settings may need to be supplied through the bootstrap method the AP supports, or the store must be given a direct 443 exception for Mist traffic.
2. How should the 32 stores be configured so that VLAN differences do not create 32 unique WLAN designs?
Read the worked answer
Use organization-level WLAN templates and site variables rather than building each store manually. Define the SSIDs, security, and VLAN variables once, then map per-site variables to the local management, guest and POS VLAN IDs. Put stores of the same format into site groups so templates and RF settings apply consistently, and reserve per-site overrides for genuine exceptions such as a different POS VLAN or a special AP model. Use an RF template for channel width, power and band settings so all stores inherit the same baseline. This prevents configuration drift and makes a later change, such as disabling legacy rates, a template edit rather than 32 separate edits. Document which variables are mandatory so a missing value fails deployment visibly instead of silently assigning the wrong VLAN.
3. What would you investigate for the intermittent AP offline alerts at the 21 working stores?
Read the worked answer
Treat the alerts as a reachability problem until proven otherwise, not as 21 independent hardware failures. Use Marvis Actions and AP event history to see whether the APs lose cloud connectivity, reboot, or are reported offline by the cloud while still serving clients. Correlate the 6-10 hour pattern with proxy session timeouts, authentication revalidation, DHCP lease renewal, ISP flaps, and NTP or certificate issues that could break TLS after a period of time. Check whether the same AP models and firmware are affected and whether the alerts cluster by store, uplink switch, or proxy. If the AP keeps serving clients during the alert, the local data path is probably fine and the management path is suspect. Collect AP uptime and last reboot reason before replacing hardware, and fix the proxy or time source if that is the common factor.