Captive portal

Captive portals are used as a way to verify users or accept terms before gaining network access on a (public) WiFi network.

Updated over a week ago

When you connect to a (public) WiFi network, you may need to login or accept terms on a captive portal page. These networks redirect you to their captive portal using DNS.

Captive portals may not work when you use DNS Guard. They won't allow captive portals by default because there is a potential security risk: DNS rebinding (changing the DNS response to redirect traffic). By default, DNS Guard will detect captive portals within 10 minutes after starting or connecting to a new network. We've limited this to 10 minutes to prevent you from DNS rebinding attacks after the initial connection.

It's possible to always support captive portals in the DNS Guard client. Edit the dnsguard.yaml file located in C:\Program Files\dnsguard on Windows systems. Change detect_captive_portals from false to true and restart the device or DNS Guard client.

If you're installing using command line parameters (when you're deploying via MDM for example), you can add the following parameter: DETECT_CAPTIVE_PORTALS="1"

When detect_captive_portals is enabled, DNS Guard will fallback to mDNS, or DNS received via DHCP to process its queries when the DNS Guard server is not available. Captive portals will block all traffic except to itself, therefore DNS Guard will fallback to local DNS. Note: it may occur queries will be resolved slower and PTR records/Reverse DNS may not get resolved in some situations.

Did this answer your question?