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 standardise 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 login to the captive portal.

Fixes

Sometimes the login page for the Captive Portal never appears automatically, 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 would 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.

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)

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