In this post, I am going to configure my wireless controller to use ISE for AAA, set up my SSIDs, and configure other basic settings. I'm going to start from the initial installation of the Virtual Wireless Controller and go through those steps. After I have that completed, I will set up all the initial configurations you will need in order to have the Wireless Controller use ISE.
For this lab, I imported the vWLC into my ESXi environment. Before starting the virtual machine, I configured the NICs as trunk ports. This is optional but if you want ISE and the WLC to dynamically change VLANs based on a user getting authorized, it would need to be trunked back to the rest of the network so the WLC has access to those VLANs. After configuring the network adapters, start the VM.
Consoling into the VM, you should be able to start the setup script for your Wireless Controller.
This is the setup script that I configured:
Would you like to terminate autoinstall? - yes
System Name: vWLC
Administrative User Name: admin
Administrative Password: networknode
Service IP Address Configuration: static
Service Interface IP address: 1.1.1.1
Service Interface Netmask: 255.255.255.252
Management Interface IP Address: 10.1.100.41
Management Interface Netmask: 255.255.255.0
Management Interface Default Router: 10.1.100.1
Management Interface VLAN Identifier: 100
Management Interface Port Number: 1
Management Interface DHCP Service IP Address: 10.1.100.1
Virtual Gateway IP Address: 2.2.2.2
Mobility/RF Group Name: MobilityGroup
Network Name (SSID): SecurityLabCorp
Configure DHCP Bridging Mode: Yes
Allow Static IP Addresses: Yes
Configure a RADIUS Server: No
Country Code: US
Enable 802.11b: Yes
Enable 802.11a: Yes
Enable 802.11g: Yes
Enable Auto-RF: Yes
Configure NTP Server: Yes
NTP Server IP address: 24.56.178.140
Polling Interval: 3600
Configure IPv6? No
Save Configuration? Yes
After the Wireless Controller has finished installing, navigate to the Wireless Controller GUI through the browser at https://management-ip-address/ and login with the credentials you created in the previous step. Click on the Advanced link to navigate to the advanced settings
If you are using an evaluation version of the wireless controller or you need to add your licenses, navigate to Management>Software Activation>Licenses and under Adder Licenses, add 5 licenses and click Set Count. Accept the EULA that pops up:
If your AP does not associate with your wireless controller, check the following:
- That the AP is getting an IP address
- That you have licenses on the wireless controller
- Console into the AP and login with the default credentials of Cisco/Cisco. Enter EXEC mode and issue the following commands:
clear capwap private-config
clear lwapp private-config
reload - If the above does not work, check the wireless controller logs by navigating to Management>Logs>Messages Logs in the WLC GUI to see if you can determine if the wireless controller is seeing the AP trying to associate with it.
- Look at the console output of the AP and see if there are any messages or warnings that indicate what the problem is.
- If that does not work, check the version number of firmware of the AP. Some older APs have expired certificates or require a complete wipe and restore
After the AP has associated itself to the wireless controller, navigate to Wireless>Access Points and click on the AP:
If the AP has been previously joined to another wireless controller and still has leftover settings, I would recommend performing a hardware reset of the AP on this menu. If everything appears to be fine, choose FlexConnect from the AP Mode drop-down in this menu and click Save.
If you don't change the AP Mode to FlexConnect, you might have issues with trying to broadcast SSIDs so that's important to change.
I usually like to enable Fast SSID Change as well. When this is enabled, the controller allows clients to move between SSIDs quicker. The way it does so is that when a client sends a new association for a different SSID, the client entry in the controller table is cleared before the client is added to the new SSID. To enable this setting, navigate to Controller>General and make sure that the Fast SSID Change is enabled.
It's recommended to disable DHCP Proxy on your wireless controller so you can have DHCP in bridging mode and have all the DHCP packets from the wireless clients forwarded to ISE. You can do this on a per-interface basis or globally on the wireless controller. In my lab, I am going to disable it globally by navigating to Controller>Advanced>DHCP and unchecking the box next to Enable DHCP Proxy. Click Save.
ISE will use SNMP to query the wireless controller for certain attributes to help identify and profile the endpoints that connect to the network. In order to enable this, we will need to configure SNMP communities on the WLC. Navigate to Management>SNMP>General and ensure that SNMP v2 is enabled:
After that, I will navigate to Management>SNMP>Communities and delete the two default community strings. After clicking New to create a new community string, I use the SNMP community string I configured in ISE (networknode) and I configure the IP address with the address of my ISE server. I also make sure that the status of this community is Enabled:
Next, I navigate to Management>SNMP>Trap Recievers and click New again. I use networknode as my commumity name, put the IP address of my ISE node in and make sure that the status is set to Enable before I apply my changes:
Now that I've set up SNMP, I'm going to configure ISE as my RADIUS server on the wireless controller. Navigate to Security>RADIUS>Authentication. On this page, we'll make sure that Auth Called Station ID Type is set to AP MAC Address:SSID in the drop-down. Click New.
On this New RADIUS Authentication Server page, I ensure that the following is configured:
- New RADIUS server is the IP address of my ISE server
- I am using the shared secret that I previously configured in ISE for this NAD (networknode).
- I'm ensuring that Enable is selected in the drop-down for RFC 3576 - This is the RFC for Dynamic Authorization Extensions
- The port number for is 1812
- Server Status is Enabled
- The Management box is unchecked
After completing the Authentication configuration, navigate to Security>RADIUS>Accounting. On this page, ensure that the Auth Called Station ID Type is AP MAC Address: SSID from the drop-down. Click New.
On the New RADIUS Accounting Servers page, I'm going to configure ISE as my RADIUS server with the following settings:
- IP address of ISE
- Shared secret that I previously configured in ISE for this NAD
- Server Status is Enabled
- The port number is 1813
- Network User is checked
Now that I've configured the RADIUS AAA servers on the wireless controller, I'm going to configure my interfaces. Navigate to Controller>Interfaces and click New to adda new interface. In this scenario, the VLAN is going to be my User VLAN (VLAN 50).
After clicking Apply, I will find myself in the Edit Interfaces page. On this page, I can specify the port number on the wireless controller for this interface ("1"), configure the interface IP address, subnet mask and default gateway. I can also specify a DHCP server as well as enabling or disabling DHCP Proxy Mode. The default should be "Global" but if you are in a production environment and don't want to globally disable it like I did, I would recommend just changing it on the interface itself that you're going to use for the ISE SSIDs:
Not pictured here but in my lab, I created another interface for the Guest VLAN (VLAN 70). After I finished configuring it, I wanted to make sure all my interfaces were in an interface group so I navigated to Controller>Interface Groups and clicked New. I made sure to add all my interfaces to this new interface group:
In the current and previous versions of code, wireless controllers have never supported dACLs. Because of that, we still need to define ACLs on our wireless controller. ISE can still use these ACLs as long as we call it out by name in the Authorization Profiles that we create in ISE. I'll go over this in more detail in my next blog post but it's something to be aware of.
I'm going to navigate to Security>Access Control Lists>Access Control Lists and click New. These are the ACLs I'm going to start with and I'll try to explain the logic in each.
Note: The WLC's perspective of Inbound/Outbound is nonintuitive. It's from the perspective of the WLC facing towards the wireless client, NOT from the perspective of the client. So inbound direction means a packet coming from your endpoint to your wireless client and outbound means a packet coming from the WLC to the client.
Before we dig into the ACLs, here's a quick reminder of my IP scheme in my lab:
- 3650 Switch – 10.1.100.1
- FlowCollector – 10.1.100.8
- Stealthwatch Management Console – 10.1.100.9
- Firepower Management Console – 10.1.100.10
- Nexus 1000v – 10.1.100.11
- Prime Infrastructure – 10.1.100.13
- Web Security Appliance – 10.1.100.16
- ISE – 10.1.100.21
- Active Directory/DNS/DHCP - 10.1.100.40
- Wireless Controller – 10.1.100.41
This is the ACL that will be used for my WebAuth redirects in the future.
Here's the breakdown of the rules:
1 - Allows the endpoint to get an IP address
2 - Allows the endpoint to use DNS which will be necessary to communicate with ISE
3 - Allows the endpoint to communicate with ISE
4 - Allows outbound traffic from my server subnet to the client. This could be DNS and DHCP relies or anything coming from ISE. You can lock this down more if you'd like but in my next ACE, I lock down any other traffic leaving the endpoint.
5 - Everything else is denied
This is the ACL I will use for corporate computers that a user is not logged into. Typically, you don't want your corporate PCs to have no access at all to the network if no one is logged into them since you would still want them to receive group policy updates, patches, etc and prevent "chicken before the egg" scenarios with new users trying to authenticate to the network.
Here's a breakdown of the rules:
1- Allows the endpoint to get an IP address
2- Allows the endpoint to use DNS
3- Allows the endpoint to communicate with ISE
4- Allows the endpoint to receive traffic from my server subnet
5 - Everything else is denied
This rule is a lot like my ISE-Only rule but in a production environment, you might be specifying specific AD and WSUS servers instead of the blanket ACEs I used for a lab. You also might specify specific ports (i.e. "389"). My lab is a lot simplier so I just re-used rules from my previous ACL but a production environment will likely look different and for the purposes of organizing my rules, I wanted a separate ACL for this purpose.
This is going to be my ACL for employees. I denied them for certain devices just to show that ISE was providing differentiated access based on the user's role.
Here's a breakdown of the rules:
1 - Allows an endpoint to get an IP address
2 - Allows an endpoint to use DNS
3 - Allows an endpoint to communicate with ISE
4 - Allows an endpoint to communicate with my AD server
5 - Allows an endpoint to receive traffic from my server subnet
6 - Denies my employee endpoint from talking to my ESXi host because I've determined that my regular employees shouldn't log into ESXi
7 - Denies my employee from sending traffic to the rest of my server subnet since there is no reason they should be trying to communicate with the rest of the servers on that subnet.
8 - Permits everything else
This is my ACL for guest on the network.
Here's a breakdown of the rules:
1 - Allows an endpoint to get an IP address
2 - Allows an endpoint to use my DNS server
3 - Allows an endpoint to communicate with my ISE server - This could be locked down further to ports 8443. 8449, etc but this is a lab so I'm not going to worry as much about it.
4 - This permits traffic back from any 10.0.0.0/8 subnet to this endpoint.
5 - This permits this endpoint to communicate with my AD server - You can lock this down if you want but if you want to force updates or posturing for even your clients, I typically use my AD server in the environment to push them down. In a production network, you would NOT be doing this and it's safe to remove this rule in your own lab.
6- Denies the endpoint from reaching any of my internal subnets - You could further add more ACEs that include other RFC 1918 addresses but I'm only using the 10.0.0.0/8 space so there was no need for my lab
7 - Permits everything else so the Guest has internet access
This one is pretty self-explanatory. I'm going to let my domain admins have access to everything. In production, you would probably want to lock this down. Typically, it's best practice to give your domain admins an account for every day use (non-Domain Admin user) and an account that's part of the Domain Admins group which they can use for specific purposes. If you're in an environment like this, you might want to create the above rule permitting access to all internal resources but blocking access to external ones like the internet
Now that we've finished creating our ACLs, I'm going to move onto creating my SSIDs. Navigate to WLANs and you can click on the WLAN name you created during setup of the wireless controller or click New to create a new one. Either way, you will be in the Edit page for this SSID.
I like to make sure the SSID is enabled and for the interface, I put this SSID in the interface group that I just created:
Next, I'll move to Security>AAA Servers on this Edit page. Make sure the Authentication and Accounting Servers are enabled and choose your ISE server from the drop-down for both. If you have multiple ISE PSNs configured, you would add them here as well:
On the Edit page, navigate to the Advanced tab. This is typically what I change on this page:
- Check the box next to Allow AAA Override
- Check the DHCP Addr Assignment box
- Change the NAC State to Radius NAC in the drop-down
- Uncheck the box next to Flexconnect Local Switching - This is only for my lab environment. Production *will* be different.
- Under Radius client profiling, check the boxes for both HTTP and DHCP profiling
Click Apply when done.
Next, I am going to add Guest and Hotspot SSIDs. From the WLANs page, click New and create the following:
I'm going to change the interface group again to the group I previously created as well as enabling the SSID:
The big key difference on this SSID is that on Security>Layer 2, I'm going to change the following:
- Set Layer 2 Security to None in the drop-down
- Check the box next to MAC Filtering
- Check the box next to Fast Transition
- Uncheck the box for Over the DS
On the Security>AAA Servers tab, I'm going to add my ISE servers just like I did in the previous SSID:
On the Advanced tab, the configuration is exactly the same as the previous SSID:
For the Hotspot SSID, the configuration is exactly the same as the Guest SSID. The only difference will be the name so if you would like to configure that SSID, so you would repeat the last steps.
The last thing we will need to do on this WLC to set it up is configure Web-Auth Captive-Bypass. The reason this is important is because certain devices (i.e. Apple iOS devices) have a mechanism for which they can determine that a device is connected to the internet, based on an HTTP WISPr request made to a designated URL. This mechanism is used for the device to automatically open a web browser when a direct connection to the internet is not available and enables the user to provide his/her credentials to access the internet. This HTTP request triggers the web authentication interception in the controller as any other page requests are performed by a wireless client and this leases to a regular web authentication request. Problem is that if the web authentication is being used with any of the controller splash page features (i.e URL provided by a configured RADIUS server - or ISE in our case), the splash page may never be displayed because the WISPr requests are made at very short intervals and as soon as one of these queries is able to reach the designated server, any web redirection or splash page display process that is performed in the background is aborted and the device processes the page request which results in breaking the splash page functionality.
To avoid issues, it's best practice to configure the controller to bypass the WISPr detection process so the web authentication interception is only done when a user requests a web page leading to a splash page load in user context. To do this, login to the CLI of the wireless controller. Enter the following command:
config network web-auth captive-bypass enable
Back on your WLC GUI, click on the Save Configuration link on the top of the screen. This will save your configuration so it will be intact on the next reboot. Then navigate to Commands>Reboot and choose Reboot.