Google Chrome, Web Auth, and 1.1.1.1

Overview

Much has been written over the past couple of years about changing the virtual IP address on the WLC from 1.1.1.1 to an RFC 5737 address, such as 192.0.2.1.  This recently became more important as the 1.1.1.1 address now resolves to a public website.

With the recent update of Google Chrome (v. 67), it has become an absolute necessity to discontinue the use of 1.1.1.1.

The Problem

Starting with v. 67, Google Chrome will only attempt to connect to the 1.1.1.1 IP address via HTTPS.  A packet capture shows the SYN being sent to 1.1.1.1:443.  If you have HTTPS disabled on the WLC for web-auth, the web-auth portal will fail to load and the user will receive either an ERR_CONNECTION_REFUSED or ERR_CONNECTION_TIMED_OUT message, as a SYN+ACK will not be sent in return from the WLC.

Disabling HTTPS on the WLC for guest web-auth is perfectly valid if your portal is a simple ‘Click Accept’ page and is not passing any credentials that should be encrypted.  This avoids the need for you to purchase certificates from a public CA.

The Solution

The recommended approach is to change the virtual IP address to an RFC 5737 address.  When the redirect occurs, Google Chrome v. 67 will connect on port 80 instead of forcing a connection on port 443, as it does when 1.1.1.1 is used.

Cisco’s documentation recommends the 192.0.2.1 address, and I would advise that you stick with that as well.  The reason being is that just as the 1.1.1.1 address became well-known as the defacto standard for the virtual IP (also due to Cisco’s documentation), the 192.0.2.1 address will end up being the new defacto standard.  Standardizing on this address makes it easier for other engineers that look at your config, as a different RFC 5737 address may cause some initial confusion.

Make sure to change the virtual IP address on all of the controllers in the same mobility group.  Additionally, the same virtual IP address should be used on all of the controllers in the mobility group, otherwise inter-controller mobility will fail.

The other option is to enable HTTPS for guest web-auth; however, you will now have to contend with a certificate warning if you have not installed a certificate from a public CA.  Also, your virtual IP will still be set to a public IP, which could cause additional problems in the future, so I would strongly recommend taking the first approach and change that IP.

Google Chrome v. 68

As if this wasn’t enough to contend with, the next version of Google Chrome (v. 68), which is due to release in July, will display a ‘Not Secure’ warning message whenever the user visits a site that does not use HTTPS.

So if you have disabled HTTPS on your guest web-auth WLAN to avoid confusing the user with a certificate warning, you will now likely cause them to question your guest portal when they see a ‘Not Secure’ message displayed in the browser.

Because of this, I would recommend that you begin to develop a strategy to obtain certificates from a public CA for your WLCs.  After these certificates have been installed, you can then enable HTTPS without any warnings.

Because guest users will not have certificates from your internal CA installed on their machine, you will have to purchase the certificates from a public CA, as most devices have these root CA certificates pre-installed.  Some options include Entrust, Go Daddy, and Thawte.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s