Roaming Client and Captive Portal

Overview

In most use cases and circumstances, no action should be required when connecting to Captive Portals with the Roaming Client installed.

There has been an attempt to standardize captive portals in this RFC: RFC8908. 

But there are some captive portals out there that do not behave the same as the above 'standard'. Each of these has something in common, and that is the hijacking of DNS queries for any domain, and it returns an IP address for a server that listens on port 80. 

Before passing through the captive portal form, all internet access is usually completely blocked. Some iterations block specific protocols (HTTP, HTTPS, or DNS), and some block any communication except for DNS to the DHCP server and HTTP to the captive portal form. 

However, if any issues are experienced when connecting via a Captive Portal, please follow the instructions below. 

Explanation

When encountering a Captive Portal, the Roaming Client will default to open to allow access to login via the Captive Portal. This includes both airline and hotel Wi-FI. 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.

Fixes

Sometimes the login page for the Captive Portal never appears automatically, and this can potentially be fixed by reopening a browser window and browsing to any domain, for example (https://www.dnsfilter.com/). This can, at times, kick the Captive Portal login window into play. 

If there are issues connecting to the network, adding the domain suffix to the Local Domains list on the dashboard will resolve this issue. 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.

For reference, below, we have comprised a 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 still a work in progress. If there is a want to bulk add multiple domains to multiple organizations, please reach out to support, and they can assist with this.

Captive Portal List:

Airlines & Transportation

• unitedwifi.com(United Airlines)
• gogoinflight.com(Multiple Airlines including Delta, Alaska, Virgin America *excluding ViaSat flights, American)
• southwestwifi.com(Southwest Airlines)
• flyfi.com(JetBlue Airlines)
• amtrakconnect.com(Amtrak)
• via.boingohotspot.net(Multiple Airlines)
• login.yyc.com(Calgary Airport)
• connect.airfrance.com(Air France)
• guestwifi.united.com(United Airlines)
• login.attwifi.com(Denver Airport)
• aainflight.com(American Airlines)

Hotels

• marriott.com(Marriott Hotels)
• hotelwifi.com
• registerforhsia.com
• danmagi.com
• redwoodsystemsgroup.com
• cloud5.com(Marriott Hotels)
• globalsuite.net(Hyatt hotels)
• bap.aws.opennetworkexchange.net(Hyatt & others)
• splash.skyadmin.io(Montage hotel)
• secure.guestinternet.com(Hilton hotels)
• snap.selectnetworx.com(Hilton Dana Point hotel)

Misc.

• wifi.connected.xfinity.com (Used for Comcast Xfinity hotspots)

If we are missing any Wi-Fi captive portal domains, let us know by sending us an email to support@dnsfilter.com and reference this article.