Visitors in the hospital lobby can associate to the guest Wi-Fi SSID and their devices show they received a valid IP address, but the captive portal page never appears in their browser no matter what website they try to load. What is the most likely cause?

A valid IP address confirms DHCP, basic Layer 2 association, and Layer 3 addressing on the guest VLAN are all working correctly, which rules out channel overlap (that would show up as poor signal or failed association, not a fully connected client) and DHCP lease timing (irrelevant once an address has already been successfully issued) as the cause. Captive portals typically work by intercepting a client's first unencrypted DNS or HTTP request and redirecting it to the portal's login page; if the DNS redirection isn't functioning correctly — whether due to a misconfigured redirect rule, a walled-garden exception list that's blocking the portal's own domain, or a client using a DNS-over-HTTPS setting that bypasses the network's DNS entirely — the browser's request simply fails or times out instead of being redirected, and the portal never renders. A wrong native VLAN on a trunk would generally produce a more fundamental connectivity break (wrong subnet or complete failure to communicate) rather than this specific pattern of full IP connectivity paired with a missing redirect. The operational check is to have an affected client attempt to resolve a domain name and observe whether the response comes back as expected for a redirect, and to review the captive portal's configuration for its walled-garden and redirect rules. A caveat is that increasingly, mobile browsers and OS-level DNS-over-HTTPS settings can defeat traditional portal redirection entirely, which is worth ruling out on the affected device specifically.