topic Re: Issue with CoA? ISE 2.7/9800-80 in Wireless

Issue with CoA? ISE 2.7/9800-80

Erik Allen — Thu, 22 Jul 2021 22:21:04 GMT

Hello,

Recently we've been working on deploying new 9800-80's and currently have them set up in our test environment, they are running 17.3.3. We are presently using ISE 2.7.0.356 as well.

We've set up a CWA Guest Portal and our redirects are presently working. The user joins the Guest SSID we have created and are presented with the captive portal page. Upon pressing "accept" to gain wireless access, the client is properly moved to the run state and a successful log is placed in the ISE Live Logs saying all is well.

The problem, however, is that the client does not recognize that it has been moved into the run state and does not gain internet access unless the client disassociates from the SSID and re-associates. The client runs into no further issues upon re-association. We've tested this on multiple iPhones running iOS 14.7, a macbook air running OSX_Catalina and three motorola android devices. All exhibit the same issue.

Checking radioactive traces show the clients move through L2 and L3 auth as expected and move into the run state. The only errors generated pertain to 11w not being enabled as this is an open guest SSID.

Any thoughts on what to try would be appreciated.

Thanks.

Re: Issue with CoA? ISE 2.7/9800-80

Arshad Safrulla — Fri, 23 Jul 2021 00:14:25 GMT

Please make sure overrides and NAC state is enabled under policy profile, also check support for COA is enabled under the Radius servers.

Make sure if there is any firewalls UDP port 1700 is allowed as well. Also share the Web Auth redirect ACL, remember for the redirection ACL deny action is deny redirection (not deny traffic), and permit action as permit redirection.

Re: Issue with CoA? ISE 2.7/9800-80

Erik Allen — Fri, 23 Jul 2021 01:16:08 GMT

Hi Arshadsaf,

Here is what my policy tag looks like, all of those options are enabled

Additionally, we've checked our testing PA Firewall and can see that port 1700 is not being blocked. We see ISE successfully communicating over UDP port 1700. ISE also appears to be acknowledging that the WLC has replied.

Below is our generalized punt ACL for web auth redirection. We've tinkered with this a lot and admit that it's certainly very generalized and just enough to get the client to hit get the Hotspot Guest Portal (IP has been blurred.)

This ACL seems to "work" and users do get to the Hotspot Guest portal on all of the devices we've tested. They scroll down, press "accept" and get a confirmation screen that says, "You've connected to the network".

During this, I see the client move to the "RUN" state on the WLC and a successful authentication log is produced on ISE.

However, still, the client does not see that it has an internet connection. We do have a deny ACL that is on that policy tag to block internal applications from being accessed by the guest user, but even taking that ACL out of play, the client still doesn't see it as having internet until you manually disconnect from the SSID and rejoin.

Re: Issue with CoA? ISE 2.7/9800-80

Arshad Safrulla — Fri, 23 Jul 2021 02:32:02 GMT

Is the Guest SSID locally switched or centrally switched?

Also make sure to match the ACL name that was entered into ISE on the authorization results. You may find the below community post helpful as well.

https://community.cisco.com/t5/network-access-control/can-ise-send-a-coa-in-an-authorization-profile/td-p/3454366

Re: Issue with CoA? ISE 2.7/9800-80

Brian McPhillips — Fri, 23 Jul 2021 09:15:41 GMT

Hi,

I'm having a similiar Hotspot issue. Android/Apple get a redirect and accept but do not get the successful redirect page. A refresh or browsing to another page confirms internet access. Windows 10 devices do not redirect to the hotspot at all.

Android/Apple hit the initial redirect policy and then get the PermitAccess Policy, Windows 10 just permanently sit on the redirect policy on ISE

Pretty sure i have everything in place with the 9800 CWA guidelines. I have a TAC logged. I will update if i get a resolution.

9800-L 17.3.3

ISE 3.0 Patch 2

Re: Issue with CoA? ISE 2.7/9800-80

Erik Allen — Sat, 24 Jul 2021 14:55:50 GMT

The guest SSID is centrally switched. I have that option toggled in the policy as well.

The ACL names match directly (no extra spaces either) and still, no dice.

Also, we are using the same VLAN before and after CoA. There isn’t a separate guest VLAN. The client stays on our specified VLAN as well.

Re: Issue with CoA? ISE 2.7/9800-80

Erik Allen — Sat, 24 Jul 2021 14:59:46 GMT

Hopefully they find a solution that works! We’re still scratching our heads over this. You described perfectly what is occurring as well. If the user clicks, “continue without internet access” and tries to navigate to a page, the client is suddenly aware that it has internet.

I will say, however, that our Windows 10 clients move to the proper policy and do not get stuck on the redirect.

Re: Issue with CoA? ISE 2.7/9800-80

Arshad Safrulla — Sat, 24 Jul 2021 19:27:07 GMT

I just confirmed on a 9800-80 where CWA is being used. I can see the Client is getting provided Internet access without any hassles as soon as Captive portal requirements are completed. The only changes I see my ACL is more 5 lines instead of 3.

ip access-list extended WEB-AUTH-REDIRECT
deny ip any host X.X.X.X
deny ip host X.X.X.X any
deny udp any any eq domain
deny udp any eq domain any
permit ip any any

If this doesn't work open a case with TAC. As a matter of fact due to some bugs there were issues on 16.X.X codes where COA was not working, but I have multiple Cat WLC's doing CWA in 17.3.X codes or higher without any issues. PCAP's are the best way troubleshoot Radius related issues always, you can also do a radio active trace and upload it to https://cway.cisco.com/wireless-debug-analyzer to get to know whats happening

Re: Issue with CoA? ISE 2.7/9800-80

Erik Allen — Sun, 25 Jul 2021 01:14:53 GMT

I will try your ACL when I return to the office on Monday. Will update this post then.

I’ll also try the radioactive trace on the client. Didn’t know about the utility you provided.

Re: Issue with CoA? ISE 2.7/9800-80

Brian McPhillips — Wed, 28 Jul 2021 15:12:22 GMT

A colleague has informed me that patch 3 is released. There seems to be two potential issues I am hitting. Getting some weird cert errors as well even though i have a publically signed cert.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvu84184

In my portal i have a redirect url after successful authentication. That would match this issue below.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvv52637

I have upgraded so will wait for some users to test.

Re: Issue with CoA? ISE 2.7/9800-80

Erik Allen — Wed, 28 Jul 2021 23:09:52 GMT

I'll be patching my ISE install tonight. Didn't even think about outstanding patches.

Will update hopefully tomorrow if this resolves my issue.

Re: Issue with CoA? ISE 2.7/9800-80

Erik Allen — Wed, 04 Aug 2021 20:25:52 GMT

Unfortunately, even after patching ISE - the issue still persists.

At this point, we're out of ideas and will be looping TAC into this.

Thanks for the suggestions everyone.

Re: Issue with CoA? ISE 2.7/9800-80

Grendizer — Thu, 05 Aug 2021 04:59:53 GMT

If you have “no ip http server” in your config then you need to put it back by using “ip http server” or you can do the below if you have 17.3 and after:

parameter-map type webauth global

webauth-http-enable

the above is required if you have any Web Auth type: CWA, LWA, External LWA

All details in the 17.3 config guide here:

https://www.cisco.com/c/en/us/td/docs/wireless/controller/9800/17-3/config-guide/b_wl_17_3_cg/m_vewlc_sec_webauth_cg.html#d209960e4494a1635

Re: Issue with CoA? ISE 2.7/9800-80

Brian McPhillips — Thu, 05 Aug 2021 14:35:10 GMT

Hi Grendizer,

I can confirm that is working now as you have stated, my config is below:

parameter-map type webauth global
webauth-http-enable
parameter-map type webauth Captive-Bypass-Portal !!this seems to be enabled anyway, not sure if its impacting

no ip http server
ip http authentication local
ip http secure-server

Re: Issue with CoA? ISE 2.7/9800-80

Erik Allen — Thu, 05 Aug 2021 16:10:03 GMT

Hi Grendizer,

I had ran into this previously, but had already made these changes as well. The captive portal is working as expected. My failure occurs here:

While the page shows "Connection Successful" users have to hit "Cancel" and then "Use without internet".

Immediately upon doing this, the client recognizes that it does have wireless connectivity and they can browse the internet as expected. This holds true for my Macbook as well as my android devices. Users never see that "done" button appear as we would expect. If they don't hit cancel, but toggle their wifi off and then on, the connection works as expected.

We're utilizing one VLAN for our guest network and not attempting to apply a new VLAN after authentication. As far as I am aware, this shouldn't be causing any issues with authentication and the client recognizing it has network.

Before the user hits "cancel" and "Use without internet" the WLC shows them in the "RUN" state and our ISE installation generates a successful Live Log.

Additionally, I've ran my configuration through the Wireless Config Analyzer Express (to see if there was anything obviously wrong) and got no results from that.

Any thoughts or guidance is greatly appreciated.

Re: Issue with CoA? ISE 2.7/9800-80

Grendizer — Fri, 06 Aug 2021 19:49:49 GMT

Hi Erik,

1) What is the WLC code: is it 17.3.3 (just for confirmation)?

2) What are the AP models?

3) What is the AP mode? Local or Flex? If the AP mode is Flex, does the problem happen with local mode APs too?

4) Is this Foreign/Anchor scenario?

5) Is the DHCP external or local, meaning the 9800 is acting as the DHCP or you have external DHCP server?

6) If you have external DHCP server, where did you configure the ip helper address, from the 9800 or from the connected Switch?

7) Is the clients VLAN configured on the WLC has a Layer 3 interface or just Layer 2 (I saw many problems with Layer 3 interfaces for client’s subnet and the best practices is to go with Layer 2 interface for all clients unless we need to implement mDNS or DHCP relay or Internal DHCP Server) Best Practices Doc is here: https://www.cisco.com/c/en/us/products/collateral/wireless/catalyst-9800-series-wireless-controllers/guide-c07-743627.html

(((DHCP bridging is the recommended mode)))

I’m not TAC but I really suspect a DHCP problem here (not from your DHCP server, instead handling the DHCP packets from/to AP-WLC-switch)

If you want to go further to troubleshoot this without TAC, then collect RA trace “radioactive” as explained here https://www.cisco.com/c/en/us/support/docs/wireless/catalyst-9800-series-wireless-controllers/213949-wireless-debugging-and-log-collection-on.html#anc13 then verify if you’re seeing the below messages:

Failed to get ewlc dot11 packet handler. Dot11 action processing error. Dropping request

Skipping DHCP TLVs for further processing. DHCP based classification isn't enabled

If that’s the case, then you will see just

DHCP_DISCOVER

DHCP_OFFER

Without DHCP_REQUEST

Then the client sends another discover because didn’t get an offer. This will validate that you have problem with DHCP handling.

Oh, I forgot to mention that I did test CWA with ISE 3.0 Patch 2 and Patch 3 and it’s working fine for me with iOS 14.7.1

Re: Issue with CoA? ISE 2.7/9800-80

Erik Allen — Sat, 07 Aug 2021 17:49:07 GMT

Hi Grendizer,

1. Version is 17.3.3

2. We were initially using an AIR-AP3802i-B-K9, but switched to using AIR-AP2802i-B-K9. I've also tried a 3702, problem persists across models.

3. AP's are in Local Mode, we don't utilize flex.

4. This is not a Foreign/Anchor scenario.

5. We are utilizing our external DHCP server on site.

6. We configured IP helper addresses on each of our Layer 2 VLANS. Additionally, our connected switches do have an ip helper address configured. These IP's match.

7. The client VLANs are configured as a layer 2 interface only. The configuration of one of them looks like such:

interface Vlan1101

description DC WiFi Guest1

ip address 10.18.0.11 255.255.248.0

ip helper-address 172.21.64.101

8. Radioactive Trace is attached, and I unfortunately do not see those statements in there. I ran this through the debug analyzer and don't see anything that sticks out, but will admit that this is a little over my head.

Thoughts?

Re: Issue with CoA? ISE 2.7/9800-80

Erik Allen — Sat, 07 Aug 2021 00:14:00 GMT

Ok! Try two (didn't sanitize my debug enough, I've double checked and removed every identifying element in the debug)

1. WLC Code is 17.3.3, and we're using ISE 2.7 on Patch 4.

2. We've tried various AP models: a 3802i, 2802i, 3702i, and a 2702i. The issue persists on all of these models.

3. AP mode is Local, as we do not utilize flex.

4. This is not a Foreign/Anchor scenario. The controller is acting alone.

5. DHCP server is external. The 9800 is not acting as our DHCP server.

6. The IP helper address is configured per interface on the 9800. I also have the ip helper address on our downstream switches to aid wired clients, etc.

7. The client vlans are purely layer 2 interfaces. We wanted to avoid the layer 3 interfaces due to reported issues. Our DHCP mode is in bridging mode.

It looks like DHCP is working as expected. However, I'm not too well versed in deciphering the log and the parser seems to suggest that things look ok? Not quite sure.

Lastly, I've ran a debug and radioactive trace. I've attached it after sanitizing any identifying information from it. (all information from the trace is sanitized. I've removed IP addresses/mac addresses/etc and substituted them with their corresponding purpose, I.E "[Wireless Controller] and [Client Mac]" etc.)

Re: Issue with CoA? ISE 2.7/9800-80

Grendizer — Sat, 07 Aug 2021 05:52:05 GMT

OK, two things need to be checked:
After the client accept the AUP page/portal, ISE is sending back to the WLC two things to apply them to the client session (yes, you will see successful log from ISE and the WLC moved the client to run state with below):

1. ACL: DENY_GUEST_INTERNAL
2. security-group-tag=0006
ISE shouldn't send group tag in this case
For the ACL, best practice is to not use ACL to control guest traffic, instead use Anchor deployment in the DMZ or VRFs design so you can isolate the guest traffic from corp traffic. In this case it might causing the problem somehow, you can start removing the security tag first from ISE config then if that doesn't fix the problem then try to remove the ACL too from ISE reply and make it simple "Permit Access" as in below screenshot.
I'm positive one of the above is causing the issue you have.

[cid:image001.jpg@01D78B1D.3D3E8960]

From the RA trace:
2021/08/06 15:23:46.036756 {wncd_x_R0-0}{1}: [radius] [24995]: (info): RADIUS: Cisco AVpair [1] 32 "cts:security-group-tag=0006-00"
.
.
2021/08/06 15:23:46.036773 {wncd_x_R0-0}{1}: [radius] [24995]: (info): RADIUS: Airespace-ACL-Name [6] 21 "DENY_GUEST_INTERNAL"
.
.
2021/08/06 15:23:46.040199 {wncd_x_R0-0}{1}: [aaa-attr-inf] [24995]: (info): [ Applied attribute : security-group-tag 0 "0006-00" ]
.
.
2021/08/06 15:23:46.040201 {wncd_x_R0-0}{1}: [aaa-attr-inf] [24995]: (info): [ Applied attribute : bsn-acl-name 0 "DENY_GUEST_INTERNAL" ]

Re: Issue with CoA? ISE 2.7/9800-80

Erik Allen — Mon, 09 Aug 2021 13:28:53 GMT

Good morning Grendizer,

First, thank you for your continued help. I really appreciate you taking the time to help me try and solve this issue.

Secondly, it was the ACL. We're going to look into the best practices for deploying the VRF's design, but as soon as I removed the ACL... it worked.

Thank you!