Recently I had to implement Central Web Authentication (CWA) on a network that uses the Cisco Embedded Wireless Controller (EWC) on Catalyst 9100 APs. Configuration is not that hard, but there is some misleading information in the documentation. Although this blog post is about EWC, it is nearly the same for the “bigger” 9800 WLC where the WLAN uses FlexConnect local switching. And yes, I know that no one really likes Captive portals. But that is a different story. 🙂
Components used in this Example:
- Cisco Catalyst 9120 with EWC, version 17.3.4
- Cisco ISE 2.7 as the RADIUS-server
The CWA Process with FlexConnect
- The client connects to an AP. We use local switching, but central Authentication here.
- The WLAN is configured for MAC filtering, a RADIUS Access-Request with the Clients MAC address is sent to the RADIUS-Server.
- The RADIUS server is not aware of this MAC address and sends an Access-Accept with the first Authorisation. This includes the redirect-URL and the redirect-ACL. Both are forwarded to the AP as the FlexConnect-AP will handle the redirection.
- The client does an HTTP request. It has to be HTTP as HTTPS redirection will always give certificate-warnings. This can be a little bit tricky nowadays as many browsers default to HTTPS. If the build-in captive-portal detection of the OS does not work, the user can point the browser to a site like neverssl.com which only uses HTTP and no HTTPS.
- The AP intercepts the HTTP-request based on the redirect-ACL and redirects the client to the redirect-URL.
- The client opens a new connection to the server which implements the Central Web Authentication. In my use case it is hosted on the ISE.
- The client interacts with the captive portal. In this example it will be a simple HotSpot-page with an AUP, but it could also ask for credentials or implement a self-registration.
- When the client went through all necessary steps of CWA, the RADIUS-server sends a CoA to the EWC/WLC with the request to reauthenticate.
- The EWC sends another Access-Request, similar to what was done in step (2).
- This time the RADIUS-server is aware of the MAC-address and sends back an Access-Accept which can include authorisation like an ACL, but no redirect-ACL and no redirect-URL. This information is again forwarded to the FlexConnect-AP
- The client can now connect to the internet or wherever our authorisation allows the client to go to.
Here I will only show the config that is relevant for CWA.
This is the config of my Hotspot-WLAN under Configuration -> Tags & Profiles -> WLAN:
MAC filtering is enabled, I have a “default” Authorisation-List of type “network” that points to the ISE. Layer 2 Security Mode could also be Open if wanted.
The Authentication-List “default” is of type “dot1x” and also points to my ISE.
This is the config of my Policy-Profile “GUESTS” under Configuration -> Tags & Profiles -> Policy
The GUEST-WLAN is statically bound to VLAN 1161, for my environment, the VLAN will not be changed later based on the Authorisation.
Under Advanced -> AAA Policy we need to enable, “Allow AAA Override”, “NAC State” and define the “NAC Type” as “RADIUS”. The Accounting-List of type “identity” again points to my ISE.
This is not CWA-specific, the WLAN Profile and Policy Profile are added to the Policy-Tag (Configuration -> Tags & Profiles -> Tags -> Policy) which gets assigned to the APs.
On step (3) of the Workflow, the RADIUS-server sends the name of the redirect-ACL. This ACL of type “IPv4 extended” is not downloaded from the RADIUS-server, it has to be configured on the EWC (Configuration -> Security -> ACL) and assigned to the APs:
The 9800/EWC is based on IOS-XE, the logic of the redirect-ACL is that “deny” does not redirect and “permit” will redirect. In my example I configured:
- no redirection for icmp
- no redirection for traffic going to the ISE (10.255.192.141) on the portal-port (8445)
- redirection for tcp/80 (HTTP)
With FlexConnect APs, the APs need to be aware of all used VLANs and ACLs. We assign these in the Flex-Profile Configuration -> Tags & Profiles -> Flex. The Flex-Profile is later added to the Site-Tag that is assigned to the AP.
Under “VLAN” all VLANs that are used on this AP are configured. I have one for the Guests, and two for Users.
“Policy ACL” lists all ACLs the AP needs. ACL_GUEST will later be assigned from the RADIUS-server and controls on the AP which traffic is allowed. ACL_WEBAUTH_REDIRECT is the previously configured redirect-ACL. As this ACL is used for CWA-redirection it needs the option “Central Web Auth”.
The ISE config
We need two rules in the Authorisation Policy:
I also match on the SSID-names and not only on the Endpoint Identity Group or MAB; this is a LAB-setup that includes additional config for different SSIDs with different functionality.
Guest-Hotspot is used in step (3) of the workflow and references the Authorisation Profile WLAN-Hotspot with the following attributes:
Guest-Access is used in step (10) of the workflow and references the Authorisation Profile Guest-Access with the following attributes:
Testing the setup
When connecting to the SSID, the ISE applies the first authorisation:
The EWC sees the client and uses the received Authorisation:
Next, the client is redirected to the ISE portal.
After accepting the AUP, the Server issues a CoA and sends the next Authorisation:
EWC switches to Run-State and applies the new authorisation:
Problems, Pitfalls, things to mention
The redirection-ACL (1):
This is the redirection ACL on the EWC:
ewc#sh ip access-lists
Extended IP access list ACL_WEBAUTH_REDIRECT
1 deny icmp any any echo
11 deny tcp any host 10.255.192.141 eq 8445
12 deny tcp host 10.255.192.141 eq 8445 any
30 permit tcp any any eq www
This is the redirection ACL on the AP:
ap1-c9120#sh ip access-lists
Extended IP access list ACL_WEBAUTH_REDIRECT
1 permit icmp any any
2 permit tcp any range 0 65535 10.255.192.141 0.0.0.0 eq 8445
3 permit tcp 10.255.192.141 0.0.0.0 eq 8445 any range 0 65535
4 deny tcp any range 0 65535 any eq 80
As already mentioned, “permit/deny” on the EWC uses the IOS-logic. But the AP operates in a legacy way and needs deny and permit reversed. The option “Central Web Auth” in the Flex-Profile takes care of this.
The redirection-ACL (2):
Many examples for redirection ACLs include explicit statements for DNS and some also for DHCP. In my tests this was not needed.
Other examples state that the ACL only needs to include the direction from the client to the network and that the reverse gets automatically added when the ACL is used in the Flex-Profile. This did not work for me and I needed to add lines for both directions (11 and 12 in the EWC ACL).
Downloadable ACLs (DACLs)
This is from the EWC config guide:
Punt/Redirect/Downloadable Access Control List (DACL): For the downloadable ACL (dACL), all the full ACEs and the dacl name are configured only on the Cisco ISE. The Cisco ISE sends the dacl name to the device in its ACCESS-Accept attribute, which takes the dacl name and sends the dACL name back to the Cisco ISE for the ACEs, using the ACCESS-request attribute.
I got a little enthusiastic as DACLs were not supported previously in FlexConnect. I tried a lot but came to the conclusion that this is a documentation-bug, where large parts from the documentation was just copied from the IOS-XE config guide.
HTTP/HTTPS Access Configuration
This was driving me crazy and I wasted hours of time troubleshooting. In my first tests the redirection didn’t want to kick in although the ACL and the URL got applied. Then I remembered that I disabled HTTP Access when I initially configured the controller. It needs to be enabled for redirection to work which is the same as with Catalyst switches.
On Catalyst switches, the attack-surface is typically reduced by disabling the session modules:
ip http active-session-modules none
The EWC-GUI doesn’t have any option for this. On the CLI these commands are available, but when trying to disable the HTTP modules, I always lost connection to the GUI. This needs some more research.
In the above configuration I use default AAA-lists to ease the configuration. This also works with named Authentication-, Authorisation- and Accounting-Lists.
As always with EWC/9800 WLC, when anything doesn’t work, the Radioactive Trace is of great help. Sadly, the EWC doesn’t have an embedded Packet-Capture. On the CLI, the commands are available, but it fails with a message that it will only work on the legacy APs (which are not supported with EWC):
ewc(config)#wireless profile ap packet-capture CAP
ewc(config)#ap profile default-ap-profile
This feature is supported only on AP803, AP170x, AP270x, AP370x, AP157x, IW3700 APs and not supported on other APs