Bonjour Printing, Guest Portal, and Dynamic PSK in a Library
A university library has three SSIDs: LIBRARY-STAFF (WPA2-Enterprise, VLAN 10), LIBRARY-STUDENT (WPA2-PSK, VLAN 20), and LIBRARY-GUEST (captive portal, VLAN 30). The site has 60 APs and about 1,200 daily clients. Staff use AirPrint printers on VLAN 10; students must discover and print to two public printers that also sit on VLAN 10. mDNS is not crossing VLANs. Guest clients get a DHCP address but the portal page times out; the portal is hosted externally and the guest VLAN has no internet access until authorization. Conference rooms use dynamic PSK with self-registration; Windows 10 clients fail while iOS clients succeed. The network team wants to keep guest isolation and refuses to flatten the VLANs.
1. How would you make the public printers discoverable from VLAN 20 without allowing all inter-VLAN traffic?
Read the worked answer
The requirement is service discovery, not general routing. Enable the Bonjour/mDNS gateway on the student WLAN and include VLAN 10 and VLAN 20 as members, but scope the services to the print services the printers actually advertise, such as _ipp._tcp and _ipps._tcp, rather than reflecting all mDNS. Then use a WxLAN policy that permits mDNS from VLAN 20 to VLAN 10 while continuing to block other inter-VLAN traffic, which preserves isolation. Verify that the printers really advertise mDNS and that multicast is not being dropped on the wired VLAN; the gateway can only reflect advertisements it can see. Test service discovery from a student client and from the staff VLAN. Flattening the VLANs would solve discovery but violate the stated isolation requirement, so it should not be the fallback.
2. Why does the guest portal time out even though clients receive a DHCP address, and what would you check?
Read the worked answer
Receiving DHCP only shows that the client reached the local DHCP service. Before authorization, the guest VLAN is intentionally restricted, so the client must still be allowed to reach the external portal and to resolve its name. Check the pre-authorization walled garden: the portal hostname and any required authentication or content domains, plus DNS and HTTPS, must be reachable from VLAN 30 before login. If the portal is external, confirm that the firewall permits those destinations and that DNS is not being redirected incorrectly. Also confirm that the client is actually redirected to the portal and that captive-portal detection is not failing silently. Test from a guest client with a manual DNS lookup and a direct HTTPS request to the portal. A walled garden that omits the portal's own dependencies produces exactly this symptom: an address, no page, and no obvious DHCP error.
3. What would explain Windows 10 failing dynamic PSK while iOS succeeds, and how would you isolate it?
Read the worked answer
First determine whether Windows fails at association, at the 4-way handshake, or at the self-registration portal. If association fails, the Windows profile may be stale, pinned to an old security type, or trying WPA3 transition when the SSID is WPA2-PSK. If the 4-way handshake fails, the PSK delivered by the dynamic PSK portal is not being accepted, which can be a mistyped or incorrectly copied key, a profile saved from an earlier key, or a portal flow that never completed. Use the client timeline in Mist to distinguish these stages rather than guessing. Test one Windows device with a manually entered DPSK after removing the saved profile, then test the portal flow on the same device. If iOS always succeeds and Windows always fails at the same stage, focus on the Windows profile and portal completion; if failures follow specific users, focus on DPSK issuance.