Blog

Google Chrome, Web Auth, and 1.1.1.1

Posted on by Charles Bisel

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.

Identity PSK with Cisco Secure ACS

Posted on by Charles Bisel

Overview

One of the features introduced with AireOS 8.5 for the Cisco Wireless LAN Controller (WLC) is Identity PSK (IPSK).  IPSK allows each wireless client device to have its own, unique PSK, which increases the security of the network, as a compromised key cannot be used to connect another wireless client device to the network (providing that each device uses a unique PSK).

421461

Cisco provides an Identity PSK Feature Deployment Guide; however, this guide only covers the RADIUS configuration for the Cisco Identity Services Engine (ISE).  As discussed in the guide, other RADIUS servers are supported, including Cisco Secure ACS.

Configuration Steps in Cisco Secure ACS

Because some customers are still running Cisco Secure ACS, this guide focuses on the configuration of Cisco Secure ACS.  The version used in this example is 5.8.0.32.9.

Step 1  (Optional)

The first step is to create an Identity Group to group all of the IPSK devices.  This step is not necessary for enabling IPSK functionality, however it is recommended, as these groups can be used to create custom policies based upon the group membership of the device.

  1. Navigate to Users and Identity Stores > Identity Groups
  2. Click the Create button
  3. Enter a Name for the Identity Group
  4. (Optional) Enter a Description for the Identity Group
  5. Click the Select button and choose the Parent group
  6. Click the Submit button to create the Identity Group

2018_06_06_12_45_39_Cisco_Secure_ACS

Step 2

Next, enter the MAC addresses of the device that will be using an IPSK.

  1. Navigate to Users and Identity Stores > Internal Identity Stores > Hosts
  2. Click the Create button
  3. Enter the MAC Address using the format: AA-BB-CC-DD-EE-FF
  4. Leave the Status set to Enabled
  5. (Optional) Enter a Description of the device
  6. Select an Identity Group (such as one you created in the previous step), or leave this set to the default of All Groups
  7. Click the Submit button to create the Internal Host

2018_06_06_12_57_59_Cisco_Secure_ACS

Step 3

Next, create the Authorization Profile.  Every unique IPSK will need to have its own Authorization Profile.  So for example, if you have ten devices and you want them all to have their own, unique PSK, then you will need to create ten Authorization Profiles.  Alternatively, if you want all ten devices to share the same IPSK, then you would only need to create one Authorization Profile.

  1. Navigate to Policy Elements > Authorization and Permissions > Network Access > Authorization Profiles
  2. Click the Create button
  3. On the General tab, enter a Name and optional Description
  4. On the RADIUS Attributes tab, enter the following for the PSK Mode:
    1. Dictionary Type:  RADIUS-Cisco
    2. RADIUS Attribute:  cisco-av-pair
    3. Attribute Type:  String
    4. Attribute Value:  Static
    5. Value:  psk-mode=ascii
  5. Click the Add button to add this RADIUS attribute
  6. Staying on the RADIUS Attributes tab, enter the following to set the PSK:
    1. Dictionary Type:  RADIUS-Cisco
    2. RADIUS-Attribute:  cisco-av-pair
    3. Attribute Type:  String
    4. Attribute Value:  Static
    5. Value:  psk=yourpsk
  7. Click the Add button to add this RADIUS attribute
  8. Click the Submit button to create the Authorization Profile

Note:  The Authorization Profile created to provide an IPSK to the device can also be used to set the client device’s VLAN, ACL, QoS, and other values.  The steps to configure these options are outside the scope of this document.

2018_06_06_13_15_27_Cisco_Secure_ACS

Step 4

Next, create the Access Service for IPSK.

  1. Navigate to Access Policies > Access Services
  2. Click the Create button
  3. Enter a Name for the Access Service
  4. (Optional) Enter a Description for the Access Service
  5. Select the Based on Service Template radio button and click the Select button
    1. Select Network Access – MAC Authentication Bypass
    2. Click OK
  6. Click the Next button
  7. Ensure that the Process Host Lookup checkbox is checked (enabled)
  8. Click Finish to create the Access Service

Step 5

Next, modify the Access Service’s Authorization Policy to allow for compound conditions:

  1. Navigate to Access Policies > (Access Service Name) > Authorization
  2. Click the Customize button
  3. In the Available Conditions box, select Compound Condition and click the > (right arrow) button to move it to the Selected box.
  4. Click OK
  5. Click the Save Changes button to save the configuration.

2018-06-06 15_22_12-Mozilla Firefox

Step 6

Next, modify the Access Service’s Authorization Policy:

  1. Navigate to Access Policies > (Access Service Name) > Authorization
  2. Click the Create button
  3. In the Name field, enter a name for the rule.  I would recommend setting this to the host name of the device if using a unique PSK for each device.
  4. Leave the Status set to Enabled
  5. Check the Compound Condition box
  6. In the Dictionary drop-down box, select RADIUS-IETF
  7. In the Attribute field, click the Select button and select Calling-Station-ID
  8. In the Value box, enter the MAC Address of the client device.
  9. Click the Add button to add this condition.
  10. In the Authorization Profiles box, click the Select button and select the Authorization Profile that you configured back in Step 3.
  11. Click the OK button to create the Authorization Policy.
  12. Click the Save Changes button to save the policy.

2018_06_06_15_27_55_Cisco_Secure_ACS

Step 7

Next, create a rule that will use the Access Service that we have just created.

  1. Navigate to Access Policies > Access Services > Service Selection Rules
  2. Click the Create button.
  3. Enter a descriptive Name for the rule.
  4. Leave the Status set to Enabled.
  5. Check the Protocol box and select RADIUS
  6. Check the Compound Condition box.
  7. For the Dictionary drop-down box, select RADIUS-IETF
  8. For the Attribute field, click the Select button and choose Service-Type
  9. In the Value field, click the Select button and choose Call Check
  10. Click the Add button to add this condition.
  11. For the Results drop-down, select the Access Service created in Step 4.
  12. Click the OK button
  13. Click the Save Changes button to save the configuration.

2018_06_06_15_42_20_Cisco_Secure_ACS

Step 8

Finally, if you have other rules in ACS, you will likely need to move this rule up in the list.  Otherwise, the client device may match on another rule and fail to authenticate.

  1. Navigate to Access Policies > Access Services > Service Selection Rules
  2. Select the rule created in the prior step.
  3. Click the ^ (up arrow) to move the rule up in the list.  It should be a higher priority than RADIUS rules that use 802.1X authentication.
  4. Click the Save Changes button to save the configuration.

Conclusion

For additional information on the IPSK feature, including the steps to configure the Cisco Wireless LAN Controller (WLC), please consult the Identity PSK Feature Deployment Guide

If you are still running Cisco Secure ACS, I would highly recommend developing a strategy to migrate to the Cisco Identity Services Engine (ISE), as Cisco Secure ACS was announced End of Life (EoL) on 30 Nov 2016.  The last date for Software Maintenance (EoSWM) is set for 30 Aug 2018 and the software will no longer be supported (LDoS) after 31 Aug 2020.