Airespace Wireless Controller Configuration for ISE

Navigate to Security>RADIUS>Authentication.

I’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:

• The new RADIUS server is the IP address of my ISE server
• I am using the shared secret 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 will configure my interfaces.

Navigate to Controller>Interfaces and click New to add a new interface.

In this scenario, the VLAN is going to be my User VLAN (VLAN 50).

After clicking Apply, I will find myself on 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 and enable or disabling DHCP Proxy Mode. The default should be “Global” but if you are in a production environment and don’t want to disable it like I did globally, 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 configuring it, I wanted to ensure 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 if we call them out by name in the Authorization Profiles we create in ISE.

I will navigate to Security>Access Control Lists>Access Control Lists and click New. These are the ACLs I will 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 standpoint of the WLC facing the wireless client, NOT from the perspective of the client. So, inbound direction means a packet from your endpoint to your wireless client, and outbound means a packet from the WLC to the client.

Before we dig into the ACLs, here is the IP scheme 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 on 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, and I’m 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.