Matt Schmitz/ November 12, 2019

Update 2020 / 05 / 19 – I’ve added a video above that walks through the steps detailed in this blog post.

If you’re using the ‘Basic’ Wireless setup, you may see an error when trying to apply the policy: “switch 1 dbm wireless Use of default ACL preauth v4 is not permitted”

If you come across this error, it’s a known bug (CSCvt18875) specific to only the ‘Basic’ setup wizard (which is what I used in this post below). If so, check out the video above which walks through the ‘Advanced’ setup and bypasses this error.

I’ve been spending a bit of time over the past few weeks building up a wireless lab. Trying to get a good understanding of how the new Catalyst 9800 wireless controller works, and how it differs from some of the previous iterations.

In order to play around with the new controller, I decided to try to build a new configuration that mimics my current home wireless. Today I am using Ubiquiti APs, which come with their own free controller software. Most of my current config is fairly straightforward – a few SSIDs, two APs, and a guest network with captive portal. One of my SSIDs is dedicated to any IoT devices and is more restrictive than the other networks. This network uses both a pre-shared key for authentication as well as MAC-based filtering.

In this post – we’ll walk through how to set up a new SSID with client MAC filtering.

Note: This was written using Catalyst 9800-CL version 16.12.1s. APs are configured in flexconnect with local authentication (no AAA, ISE, etc)

While this post is not focused on in-depth WLAN config, we will start by quickly setting up a new network.

Once you get logged into the controller – we’ll click on the Wireless Setup icon in the upper right-hand side. Then drop down to the Basic option:

This takes us through a pretty quick and easy wizard to set up our new location & wireless networks. At first, we will have no locations configured – so we will click Add:

We’ll start off building our location by giving it a name and description. These are used for some naming of policy objects within the WLC, so make sure to use a name that makes sense.

In my case, I’m also going with a flexconnect deployment – so we’ll select that option and also provide the AP native VLAN.

Next, we’ll click over to the Wireless Networks tab. This is where we will create our WLAN and apply the initial configuration. We don’t have any networks yet, so click Add

The two primary things we need to address are highlighted in red below. We need to create a WLAN and assign it to a VLAN. Let’s start with the WLAN by clicking Define new.

On the General tab, we’ll give this WLAN a profile name and a SSID.

Next, we’ll hop on over to the Security tab, and focus on the Layer 2 sub-tab. The first thing I want to point out – is that at this point, we will not be enabling the MAC Filtering checkbox. We’ll need some additional config first, then come back to this later.

Scroll down to the bottom of the window and there will be some settings for your authentication. By default, 802.1x will be enabled. This post won’t cover how to setup/configure that. Instead, we’ll be deselecting 802.1x and checking the box for PSK. Then a text field will appear for us to enter the Pre-Shared Key.

Once we click Apply to Device, we’ll finish up by assigning our VLAN or VLAN Group. In this case, I have already created a VLAN named IoT. If you haven’t created a VLAN yet, you can do so by going to Configuration > Layer 2 > VLAN. Then add a new VLAN under the VLAN tab.

Click Add, then we’ll be back to the wizard and see the new WLAN we just created.

In order to finish up with the wizard, we just need to assign our Access Points. Click on the AP Provisioning tab. If you have already configured APs to join to this controller, you will see them on the left side under Available APs. Check which ones to apply this WLAN to, then click the arrow to move them to APs on this location.

Click Apply, and that will finalize all of the configuration we just did – then drop us back to the Wireless Setup page.

Okay – Now that we have that completed, we can move onto creating our MAC filtering policies.

Back in the menu – Let’s go to Configuration > Security > AAA

In this section – we first need to create an Authorization policy. Select the AAA Method List tab, then Authorization, then Add to create the new policy.

In here we’ll specify a name, then select Type: network, and Group Type: local. Then go ahead and Apply to Device

Once we have that, let’s go over to the AAA Advanced tab, and click Add in the Attribute List Name section

Here we need to provide the SSID we want our MAC policy to apply to. Under Attribute Type, select SSID. Then under Attribute Value, select the target SSID that our policy will be tied to.

Don’t forget to click Save on the attribute before clicking Apply to Device!

Time to input our list of device MAC addresses! Drop into the Device Authentication section, and click Add – or upload a CSV file if you have one.

Input the device MAC Addrees and select the Attribute List Name that we configured just a minute ago. Then Apply to Device

After that – we should have our completed list of MAC addresses which will be permitted to join our wireless network. All we need to do is go back to our WLAN and enable MAC filtering.

Let’s go to Configuration > Tags & Profiles > WLANs

This should give us the list of any configured WLANS – including the one we created earlier. Go ahead and click on it to edit.

Next, we’ll jump straight to the Layer 2 section under the Security tab. Check the box for MAC Filtering and select the Authorization List we created from the drop down.

And we’re done! Clients that want to join our newly created SSID will need the pre-shared key we configured, but they will also need to be manually added to our MAC address filter as well. While this isn’t a perfect security measure since MAC addresses can be easily spoofed – it does add an extra layer of protection to keep unauthorized devices from inadvertently being able to join this specific WLAN.

In the event that a client is NOT on the authorized list, you may see the following logs in a client debug:

2019/10/25 22:26:12.327 {wncd_x_R0-0}{1}: [client-orch-sm] [22573]: (note): MAC: aaaa.aaaa.aaaa  Association received. BSSID aaaa.aaaa.b34d, old BSSID 0000.0000.0000, WLAN SuperSecret, Slot 1 AP aaaa.aaaa.b340, AP_3802-1F01
2019/10/25 22:26:12.327 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_INIT -> S_CO_ASSOCIATING
2019/10/25 22:26:12.328 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_ASSOCIATING -> S_CO_MACAUTH_IN_PROGRESS
2019/10/25 22:26:12.328 {wncd_x_R0-0}{1}: [client-auth] [22573]: (note): MAC: aaaa.aaaa.aaaa  MAB Authentication initiated. Policy VLAN 0, AAA override = 0, NAC = 0
2019/10/25 22:26:12.329 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [22573]: (note): Authentication Success. Resolved Policy bitmap:11 for client aaaa.aaaa.aaaa 
2019/10/25 22:26:12.329 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [22573]: (ERR): SANET_AUTHC_FAILURE - AAA Server Down username ac37434a673a, audit session id 000000000000006B3E9D2A55, 
2019/10/25 22:26:12.331 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_MACAUTH_IN_PROGRESS -> S_CO_ASSOCIATING
2019/10/25 22:26:12.331 {wncd_x_R0-0}{1}: [dot11] [22573]: (ERR): MAC: aaaa.aaaa.aaaa  Failed to assoc failure tr state entry. Incorrect validation status value :1
2019/10/25 22:26:12.331 {wncd_x_R0-0}{1}: [dot11] [22573]: (ERR): MAC: aaaa.aaaa.aaaa  Dot11 update co assoc fail. Sent assoc failure to CO. delete reason: 9, CO_CLIENT_DELETE_REASON_MAB_FAILED
2019/10/25 22:26:12.331 {wncd_x_R0-0}{1}: [client-orch-sm] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client delete initiated. Reason: CO_CLIENT_DELETE_REASON_MAB_FAILED, fsm-state transition

On the opposite side, when a client is successfully able to pass MAC authentication – the logs will show the following:

2019/10/25 21:25:53.148 {wncd_x_R0-0}{1}: [client-auth] [22573]: (note): MAC: aaaa.aaaa.aaaa  MAB Authentication initiated. Policy VLAN 0, AAA override = 0, NAC = 0
2019/10/25 21:25:53.150 {wncd_x_R0-0}{1}: [ewlc-infra-evq] [22573]: (note): Authentication Success. Resolved Policy bitmap:11 for client aaaa.aaaa.aaaa 
2019/10/25 21:25:53.151 {wncd_x_R0-0}{1}: [client-auth] [22573]: (note): MAC: aaaa.aaaa.aaaa  MAB Authentication success.
2019/10/25 21:25:53.151 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_MACAUTH_IN_PROGRESS -> S_CO_ASSOCIATING

2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-orch-sm] [22573]: (debug): MAC: aaaa.aaaa.aaaa  Received Dot11 association request. Processing started,SSID: SuperSecret2, Policy profile: Home_WLANID_3, AP Name: AP_3802-3F01, Ap Mac Address: aaaa.aaaa.c9a0 BSSID MAC aaaa.aaaa.b34d wlan ID: 3RSSI: 0, SNR: 32
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_L2_AUTH_IN_PROGRESS -> S_CO_L2_AUTH_IN_PROGRESS
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [dot11] [22573]: (info): MAC: aaaa.aaaa.aaaa  DOT11 state transition: S_DOT11_ASSOCIATED -> S_DOT11_MAB_PENDING
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_L2_AUTH_IN_PROGRESS -> S_CO_MACAUTH_IN_PROGRESS
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-auth] [22573]: (info): MAC: aaaa.aaaa.aaaa  Client auth-interface state transition: S_AUTHIF_ADD_MOBILE_ACK_WAIT_KM -> S_AUTHIF_MAB_AUTH_DONE
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-orch-sm] [22573]: (debug): MAC: aaaa.aaaa.aaaa  Processing MAB authentication result status: 0, CO_AUTH_STATUS_SUCCESS
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [client-orch-state] [22573]: (note): MAC: aaaa.aaaa.aaaa  Client state transition: S_CO_MACAUTH_IN_PROGRESS -> S_CO_ASSOCIATING
2019/10/25 21:30:08.626 {wncd_x_R0-0}{1}: [dot11] [22573]: (debug): MAC: aaaa.aaaa.aaaa  dot11 send association response. Sending association response with resp_status_code: 0 
2019/10/25 21:30:08.627 {wncd_x_R0-0}{1}: [dot11] [22573]: (info): MAC: aaaa.aaaa.aaaa  dot11 send association response. Sending assoc response of length: 137 with resp_status_code: 0, DOT11_STATUS: DOT11_STATUS_SUCCESS
2019/10/25 21:30:08.627 {wncd_x_R0-0}{1}: [dot11] [22573]: (note): MAC: aaaa.aaaa.aaaa  Association success. AID 1, Roaming = True, WGB = False, 11r = False, 11w = False
2019/10/25 21:30:08.627 {wncd_x_R0-0}{1}: [dot11] [22573]: (info): MAC: aaaa.aaaa.aaaa  DOT11 state transition: S_DOT11_MAB_PENDING -> S_DOT11_ASSOCIATED

About Matt Schmitz

CCIE #63461. Herding packets since 2007. Perpetually trying to automate myself out of a job. I believe that all problems can be solved by implementing more IPv6. Disclaimer: All opinions posted here are my own, and do not represent any vendor or current/former employer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.