N10-009 Question 170
Single answerGuest networks: Captive portalsA hotel deploys a guest Wi-Fi SSID that uses a captive portal to require users to accept terms of service before browsing. Guests report that after connecting to the SSID, some websites load but the login page does not automatically appear on many phones and tablets. The network administrator wants the captive portal to display reliably without manually telling guests to open a browser and type a website. Which configuration change is the BEST way to improve the captive portal experience?
- A
Allow unauthenticated DNS and HTTP/HTTPS redirection only to the captive portal detection and login resources until the user completes portal authentication
- B
Disable DHCP on the guest VLAN so devices are forced to reconnect and retry the captive portal process
- C
Broadcast the SSID as hidden so client devices perform a fresh association before opening the portal
- D
Replace the captive portal with WPA3-Personal so the terms of service page appears after the four-way handshake
Show answer and explanation
Correct answer: A
Explanation
The best answer is to permit the pre-authentication services and redirection behavior that captive portals require. In real guest network deployments, devices must usually be able to complete DHCP, perform DNS lookups, and reach or be redirected from operating-system connectivity-check destinations so the captive portal assistant opens automatically. If these services are blocked or misconfigured, users may have partial connectivity symptoms or may need to manually browse to trigger the portal. This aligns with common guest Wi-Fi design best practices used by wireless vendors and network administrators: permit only the minimal unauthenticated traffic required for onboarding, then enforce broader access only after portal acceptance. Options involving hidden SSIDs, disabling DHCP, or substituting WPA3-Personal reflect common misconceptions because they do not address the actual portal detection and redirection process.
- A. Correct.
Correct. Captive portals work most reliably when pre-authentication access permits the limited traffic needed for clients to obtain network settings and detect a captive portal, typically including DHCP and DNS, while redirecting web requests to the portal. Many modern operating systems use connectivity-check URLs and captive portal detection mechanisms; if those checks cannot reach the expected resources or be redirected properly, the portal may not pop up automatically. Allowing the required pre-authentication traffic and redirect behavior is a common best practice for guest networks.
- B. Incorrect.
Incorrect. Disabling DHCP would prevent guests from obtaining IP addressing information automatically, which would make captive portal access worse, not better. Captive portal workflows depend on clients first receiving valid network configuration such as an IP address, default gateway, and DNS servers.
- C. Incorrect.
Incorrect. Hiding the SSID does not improve captive portal detection or redirection. A hidden SSID can actually reduce usability and create additional connection issues for guests. SSID visibility is unrelated to whether the operating system can complete its connectivity check and launch the captive portal mini-browser.
- D. Incorrect.
Incorrect. WPA3-Personal provides wireless encryption and authentication using a shared passphrase, but it does not present a terms-of-service page after association. Captive portals and WPA-personal authentication serve different purposes. Replacing the portal with WPA3-Personal would remove the guest acceptance workflow rather than improve it.