N10-009 Question 171
Single answerGuest networks: Captive portalsA hotel provides a guest Wi-Fi SSID that uses a captive portal to display the acceptable use policy and collect a room number before allowing internet access. Guests report that after connecting to the SSID, some devices do not automatically show the portal page. If users manually browse to a public website over HTTPS, the page often fails to load and the captive portal still does not appear. The wireless network, DHCP scope, and internet connectivity are all functioning. Which action is the BEST way to improve captive portal reliability for these guests?
- A
Configure the guest network to redirect all DNS queries to the captive portal until authentication is completed
- B
Implement a walled garden and ensure unauthenticated clients can reach the portal detection URLs and the portal page over HTTP/HTTPS as required
- C
Disable WPA2 on the guest SSID so devices will be more likely to detect the captive portal automatically
- D
Replace the captive portal with MAC address filtering so guest devices can be identified before internet access is granted
Show answer and explanation
Correct answer: B
Explanation
Captive portals work best when they account for how current operating systems detect restricted internet access. Many devices do not simply open a browser and get redirected anymore; instead, they perform connectivity checks against known URLs. If those checks are blocked incorrectly, or if only HTTPS redirection is attempted, the portal may not appear because HTTPS interception cannot be performed cleanly without certificate errors. A best-practice approach is to use a walled garden (sometimes called a pre-auth ACL) that permits access to the captive portal infrastructure and the OS connectivity-check resources needed to trigger captive portal detection, while still blocking general internet access until the user authenticates or accepts terms. This aligns with common vendor guidance for enterprise wireless platforms and with practical deployment patterns used in hospitality and public guest networks.
- A. Incorrect.
This is not the best answer. Redirecting all DNS queries is a common captive portal technique, but by itself it does not reliably solve modern device behavior. Many operating systems use specific connectivity-check URLs and expect access to those destinations in order to trigger the captive portal assistant. Simply forcing DNS responses to the portal can also cause certificate warnings or failed application behavior when users try to reach HTTPS sites before authentication.
- B. Correct.
This is correct. A walled garden allows limited pre-authentication access to the captive portal itself and, where needed, to the operating system's internet connectivity check endpoints. Modern captive portal deployments commonly permit access to those detection services and to the portal resources so devices can identify that sign-in is required and launch the portal assistant. This improves user experience without granting full internet access before acceptance or login.
- C. Incorrect.
This is incorrect. Captive portal detection is not dependent on disabling WPA2. Guest SSIDs can still use open access with a portal or use protected onboarding methods depending on business requirements, but removing encryption is not the mechanism that fixes portal detection issues. In fact, reducing wireless security can expose guest traffic unnecessarily and does not address HTTPS interception or OS detection behavior.
- D. Incorrect.
This is incorrect. MAC address filtering is not a practical replacement for a guest captive portal in this scenario. It does not present acceptable use terms, does not scale well for hotels with transient users, and is weak as an identification or security mechanism because MAC addresses can be spoofed. It also does nothing to resolve the issue of devices not launching the captive portal automatically.