Captive portals suck.

We need them for any public access network, but with the widespread adoption of HTTPS, it is really difficult for users to find a hint as to where to go to get their access.

How captive portals work

In most real-world applications, the client station is placed in a network where all of the station's generated traffic is not allowed until authentication is performed.

The problem

Any scalable, well-engineered, easy-to-use guest platform needs some way of notifying the user as to why they're being blocked, and how to properly connect.

The most common approach taken by Aruba, Palo Alto, most firewall platforms will enforce a destination NAT policy on unauthenticated guest traffic, translating every possible destination address -> your client access gateway. This method still requires DNS be allowed through unless you implement a separate rule for DNS (and a corresponding no-NAT policy).

As a side-effect, this implementation will make it appear as if your client access gateway is impersonating every site a user visits - pretty much all client web browsers will abort any connections that appear insecure in this manner. The only workaround is for the client station to browse to an HTTP web site - like http://neverssl.com/. As a consolation, some network devices attempt to access a captive portal detection URL automatically, like Apple's http://captive.apple.com/hotspot-detect.html, but these implementations vary greatly based on the end device and are not always reliable.

Enter RFC 7710

This is not an uncommon issue, as most modern enterprises, conventions, events will all require heavy use of this particular network type. Due to the usability issues presented above, most conventions and other platforms will typically just provide you the WPA2-PSK and leave it as-is.

The IETF did not ignore the difficulties that most have had with guest usability at-scale, and have proposed an internet standard to notify client stations that a captive portal exists:

https://tools.ietf.org/html/rfc7710

In a nutshell, the IETF proposed that the network discovery protocols used by a client station when connecting to a new network would present the most efficient path for notification for this case, specifying options for DHCPv4, DHCPv6, and IPv6 Router Advertisements:

• DHCPv4 Option 160
• DHCPv6 Option 103
• RA Type 37

This completely eliminates the need for a MiTM if the client supports this RFC. It also lets you authenticate your client access gateway, which is vulnerable to spoofing otherwise:

In all of these cases, the implementation should be pretty simple - you just punch in the URI of your captive portal server, and you're done!