In this article
Use this article to understand how the DNSFilter Roaming Client works with captive portals, including troubleshooting suggestions for when the captive portal does not populate or connect to the Wi-Fi network.
A captive portal is a webpage that the user of a public network is required to view and interact with before they can access the network. Think airport, hotel, or coffee shop Wi-Fi login pages terms of agreements.
In most circumstances, no action is required when connecting to captive portals with the Roaming Client installed. The Roaming Client will default to open a login window without issue.
There has been an attempt to standardize captive portals in RFC8908.
In some situations, usually where DNS is permitted through the hotel or airline network, the Roaming Client may not default to open and, in turn, cause issues either browsing to the necessary captive portal login page or connecting to the Wi-Fi network behind it.
The Roaming Client may interfere with the captive portal by redirecting DNS away from the network-provided DHCP server, therefore avoiding HTTP redirection to the login form.
This could lead to the internet being blocked while not being able to log in to the captive portal.
Captive Portal login page doesn't appear automatically
Sometimes the login page for the captive portal doesn't appears automatically.
Try these troubleshooting steps to resolve the issue. Any of these methods can prompt the captive portal login window to open:
- Reopen a browser window and browse to any domain (e.g. https://www.dnsfilter.com/)
- Turn off and on the device's Wi-Fi
- Re-establish the network connection
- Remove/forget the network
- Turn off and on the device's Wi-Fi
- Re-add the network
- Restart the device
As of v1.8.2 the macOS Roaming Client has improved this compatibility. We recommend updating to the latest agent version for continued improvements to the captive portal experience.
If a login window does not automatically open, click the DNSFilter status menu icon and select Access Captive Network. This forces the login open in a browser window.
Add domain suffix to Local Domains
If there are issues connecting to the network, adding the domain suffix to the Local Domains list on the DNSFilter dashboard will resolve this issue.
Remember to also add IPs for local resolvers that are not public DNS servers (like Google's 8.8.8.8). Add IPs for the DNS server provided by DHCP.
If you add known airline or hotel portals to your Local Domains list before the user travels in advance, this will prevent this issue from arising.
Captive Portal List
We comprised this list of domains used for hotels or airline Wi-Fi which can be added to your Local Domains. This may not be a complete list, as this is a work-in-progress.
Airlines & Transportation
Air France | connect.airfrance.com |
Alaska Airlines | alaskawifi.com |
American Airlines | aainflight.com |
Amtrak | amtrakconnect.com |
Calgary Airport |
login.yyc.com |
Delta Airlines |
deltawifi.com |
Denver Airport |
login.attwifi.com |
JetBlue Airlines |
flyfi.com |
Multiple Airlines | gogoinflight.com |
via.boingohotspot.net |
|
Southwest Airlines | southwestwifi.com |
United Airlines | guestwifi.united.com |
wifi.united.com | |
unitedwifi.com |
Hotels
Hilton Hotels | secure.guestinternet.com |
Hilton Dana Point Hotel | snap.selectnetworx.com |
Hyatt Hotels | globalsuite.net |
bap.aws.opennetworkexchange.net | |
Marriott Hotels | marriott.com |
cloud5.com | |
Montage Hotels |
splash.skyadmin.io |
Multiple Hotels |
hotelwifi.com |
registerforhsia.com |
|
danmagi.com |
|
redwoodsystemsgroup.com |
Miscellaneous
Comcast Xfinity Hotspots | xfinity.com/wifi |
Apple devices |
captive.apple.com |
Comments
9 comments
Please add the captive portal for Delta, DeltaWiFi.com, to this list.
Source: https://www.delta.com/us/en/onboard/inflight-entertainment/onboard-wifi (Step 3)
Thanks for the suggestion, Brian Zick —added to the list!
Thank you!
Please add captive.apple.com for Apple devices.
Thanks for the suggestion, Amanda Hunt —added to the list!
How about removing the hyperlink from the local domains so we don't accidentally click through while trying to copy.
Great suggestion, Karik Hill ! Thanks for helping make our documentation better 💖
Thank you for this list!
We have a client end-user who is traveling and discovered they can't connect to the Hilton URL “secure.guestinternet.com”. Will adding the URL to the Allow List of their assigned filter policy function the same way as adding it to the Local Domains? And will they need to connect to a different internet to pull down the new setting changes before it will start working?
Hi Kyle Murphy thanks for reaching out!
Adding "secure.guestinternet.com" to the Allow List is not the same as adding it to Local Domains. The Allow List lets DNS traffic to that domain through DNSFilter, but Local Domains ensures DNS queries for that domain are handled by the local network’s DNS (often needed for captive portals like Hilton’s).
We recommend following this article's suggestions in order. Start by having the user:
If none of these local steps work, add "secure.guestinternet.com" as a Local Domain in the DNSFilter dashboard. This allows the device to bypass DNSFilter to reach the captive portal login properly.
If the user is already unable to connect, they may need to join another network temporarily to sync the updated Local Domains setting with their Roaming Client. After syncing, they can reconnect to the Hilton Wi-Fi.
Let us know if the issue persists and we can look into some different troubleshooting steps!
Please sign in to leave a comment.