Troubleshoot Central Web Authentication (CWA) with Wireless Lan Controller (WLC) 9800 and Identity Services Engine (ISE)

Introduction

This document describes how to troubleshoot Central Web Authentication (CWA) with WLC 9800 and ISE.

Background Info

There are so many personal devices currently that network administrators that look for securing Wireless access normally opt for Wireless networks that use CWA.
In this document, we focus on the flow chart of CWA, that helps in the troubleshooting of the common issues that affect us.
We look at the common gotchas of the process, how to collect logs related to CWA, how to analyze these logs, and how to collect an embedded packet capture on the WLC to confirm traffic flow.

CWA is the most common setup for companies that allow users to connect to the company network using their personal devices, also known as BYOD.
Any network administrator is interested in the gotchas and troubleshooting steps to perform to fix their problems prior to opening a TAC case.

Here is the CWA packet flow:

CWA Packet Flow

Detailed flow

First Association and RADIUS Authentication:

First Assocition and RADIUS Authentication

DHCP, DNS and Connectivity Check:

DHCP, DNS and Connectivity Check

The connectivity check is done using captive portal detection by the client device Operating System or browser.

There are device OS pre-programed to do HTTP GET towards specific domain

• • Apple = captive.apple.com
  • Android = connectivitycheck.gstatic.com
  • Windows = msftconnectest.com

And browsers also perform this check when opened:

• Chrome = clients3.google.com
• Firefox = detectportal.firefox.com

Traffic interception and redirection:

Traffic interception and redirection

Client login into ISE guest login portal:

Client login into ISE guest login portal

Client login and CoA:

Client login and CoA

Troubleshooting

Common Symptom: User not getting redirected to login page.

Let us start with the first part of the flow:

First Assocition and RADIUS Authentication

1 - Is the first RADIUS authentication successful?

Check mac filtering authentication result:

ISE Live logs showing mac filtering authentication result

Make sure advanced option for the authentication is set to “Continue” if user not found:

User not found advanced option

2 - WLC receives the Redirect URL and ACL?

Check ISE live logs and WLC client security information under Monitoring Verify that the ISE sends Redirect URL and ACL in the Access Accept and it is received by WLC and applied to the client in the client details:

Redirect ACL and URL

3 - Is the redirect ACL correct?

Check ACL name for any typo. Make sure it is exactly like it is sent by the ISE:

Redirect ACL verification

4 - Is the client moved to Web-Auth Pending?

Check client details for "Web Auth Pending" state. If its not in that state, then verify if AAA override and Radius NAC are enabled in policy profile:

Client details, aaa override and RADIUS NAC

Still not working? 

Let’s revisit the flow….

DHCP, DNS and Connectivity Check

5 - Does WLC allow DHCP and DNS traffic?

Verify redirect ACL contents in the WLC:

Redirect ACL contents in the WLC

The Redirect ACL defines which traffic is intercepted and redirected by the permit statement and which traffic is ignored from interception and redirection with a deny statement.

In this example, we allow DNS and traffic to/from ISE IP address to flow, and intercept any tcp traffic on port 80 (www).

6 - Does DHCP server receives DHCP Discover/Request? 

Check with EPC if DHCP exchange happens. EPC can be used with Inner Filters like DHCP protocol and/or Inner Filter MAC where we can use the client device mac address and we get in the EPC only DHCP packets sent by or sent to the client device mac address.

In this example, we can see the DHCP Discover packets sent as broadcast on VLAN 3:

WLC EPC to verify DHCP

Confirm the expected client VLAN in the policy profile:

VLAN in the policy profile

Verify WLC VLAN and switchport Trunk configuration and DHCP subnet:

VLAN, switchport and DHCP subnet

We can see that VLAN 3 exists in the WLC and it also has SVI for VLAN 3, however when we verify the DHCP server ip address, its on different subnet, therefore we need ip helper address on the SVI.

Best practices dictate that SVI for client subnets be configured in the wired infrastructure and avoid them at the WLC.

In any of the cases, the ip helper-address command needs to be added to the SVI regardless where it resides.

An alternative is to configure the DHCP server ip address at the Policy profile:

Ip helper-address at SVI or Policy Profile

You can then verify with EPC if DHCP exchange is now ok and if DHCP server offers DNS server IP(s):

DHCP Offer detail of DNS server ip

7 - Does automatic redirection happen?

Verify with WLC EPC if DNS server replies to queries:

DNS query and responses

• If the redirection is not automatic, open a browser and try a random IP address. For example 10.0.0.1.
• If redirection then works, it is possible that you have a DNS resolution problem.

Still not working? 

Let’s revisit the flow…

Traffic interception and redirection

8 - Browser does not show login page?

Verify if client sends the TCP SYN to port 80 and WLC intercepts it:

TCP retransmissions to port 80

Here we can see that the client sends TCP SYN packets to port 80 but does not get any reply and does TCP retransmissions.

Ensure you have the command ip http server in the global configuration or webauth-http-enable in the parameter-map global:

http interception commands

After the command, WLC intercepts the TCP and Spoofs the destination ip address to reply to client and redirect.

TCP interception by WLC

Still not working? 

There is more in the flow…

Client login into ISE guest login portal

9 - Can client resolve ISE hostname?

Verify if redirect URL uses IP or hostname and if client resolves ISE hostname:

ISE Hostname resolution

A common issue is seen when the redirect URL contains the ISE hostname, however the client device is unable to resolve that hostname to the ISE IP address. If hostname is used, assure that is resolvable via DNS.

10 - Login page still does not load?

Verify with WLC EPC and ISE TCPdump if client traffic reaches ISE PSN. Configure and initiate the captures on WLC and ISE:

WLC EPC and ISE TCPDump

After issue reproduction, collect captures and correlate traffic. Here we can see ISE hostname resolved and then communication between client and ISE on port 8443:

WLC and ISE traffic

11 - Why do we get security violation due to certificate?

If you use self signed certificate on ISE, then its expected that the client throws security warning when it attempts to present the ISE portal login page. 

On the WLC EPC or ISE TCPdump we can verify if ISE certificate is trusted.

In this example we can see connection close from Client with Alert (Level: Fatal, Description: certificate Unknown) which means the ISE certificate is not known (Trusted):

ISE untrusted certificate

If we check on client side, we see these examples output:

Client device that does not trust ISE certificate

Finally, redirection is working!! But login fails…

One last time checking the flow…

Client login and CoA

12 - Guest login fails?

Check ISE logs for failed authentication. Make sure credentials are correct.

Guest authentication fails due to wrong credentials

13 - Login succeeds but not moving to RUN?

Check ISE logs for authentication details and result:

Redirection loop

In this example w can see the client getting again the authorization profile that contains the Redirect URL and Redirect ACL. This results in a redirection loop.

Check Policy set. Rule checking Guest_Flow must be before the Redirection:

Guest_Flow rule

14 - COA Failing?

With EPC and ISE TCPDump we can verify CoA traffic. Verify if CoA port (1700) open between WLC and ISE. Make sure shared secret matches.

CoA traffic

Note: On version 17.4.X and later, ensure to also configure the CoA server key when you configure the RADIUS server. Use the same key as the shared secret (they are the same by default on ISE). The purpose is to optionally configure a different key for CoA than the shared secret if that is what your RADIUS server configured. In Cisco IOS® XE 17.3, the web UI simply used the same shared secret as CoA key.

As from version 17.6.1, RADIUS (including CoA) is supported through this port. If you want to use the Service Port for RADIUS then you need this configuration:

aaa server radius dynamic-author 
 client 10.48.39.28 vrf Mgmt-intf server-key cisco123

interface GigabitEthernet0
vrf forwarding Mgmt-intf
 ip address x.x.x.x x.x.x.x

!if using aaa group server:
aaa group server radius group-name
 server name nicoISE
ip vrf forwarding Mgmt-intf
ip radius source-interface GigabitEthernet0

Conclusion

This is the resumed CWA checklist:

• Make sure client sits on correct VLAN and gets IP address and DNS.
  • Get client details at WLC and run packet captures to see DHCP exchange. 
• Verify that client can resolve hostnames via DNS.
  • Ping hostname from cmd.
• WLC must be listening on port 80
  • Verify global command ip http server or global parameter map command webauth-http-enable.
• To get rid of certificate warning, install trusted certificate on ISE.
  • No need to install trusted certificate on WLC in CWA.
• Authentication Policy at ISE Advanced option “Continue” If user not found
  • To allow sponsored Guest users to connect and get URL Redirect and ACL.

And the main tools used in the troubleshoot:

• WLC EPC
  • Inner filters: DHCP protocol, mac address.
• WLC Monitor
  • Check client security details.
• WLC RA tracing
  • Debugs with detailed info at WLC side.
• ISE Live Logs
  • Authentication details.
• ISE TCPDump
  • Collect packet captures at ISE PSN interface.

References

Configure Central Web Authentication (CWA) on Catalyst 9800 WLC and ISE