Couldn't get an IP address and HTTPS redirection to ISE portal doesn't work.

[damode]

Two main issues I am facing as part of ISE guest access POC lab.

1. On any device on first attempt connections works smooth. However, if I disconnect and reconnect the SSID, its repeatedly giving "Couldn't get an IP address" or "No internet connection" on connecting to SSID.
2. On Windows workstation, on connecting SSID, it opens the re-direct page, upon clicking the "connect" link on the page, it opens another link repeatedly.
3. On Apple, accessing HTTP website is redirecting to ISE guest portal. However, accessing HTTPS url doesn't redirect to the portal.

Can someone please advise ?

Thanks.

[Arne Bier]

1. Sounds like you're using the ISE Remember-Me feature which stores the Endpoint Identity (MAC address) of clients that have logged into the portal. When the user returns (whose MAC address is still in the Endpoint Identity Group), you should return a different authorization Profile. This will contain a different ACL (Generally: allow DNS, allow DHCP, block RFC1918, allow any) - if you pass the incorrect Authorization Profile to the WLC and it doesn't enable the correct ACL, then you have no access.
2. Check that the WLC is enabled, and able to receive CoA (RFC3576) - and that the CoA return traffic gets back to the ISE PSN. This catches a lot of folks out. There should be no difference between an Apple/Android and a Windows device in this respect. Once the CoA has been sent to the WLC, the client is disconnected from the WiFI and then has to re-associate. This causes a new MAB event. Depending on whether you are using GuestFlow mode or Remember-Me, you then return an Authorization Profile to the WLC to allow DNS, DHCP, Block RFC1918 and Allow Any - if the ACLs are not working, then the WLC will intercept ALL traffic and cause a redirection to ISE. If you are stuck in a redirection loop, then check the status of the client on the WLC. It probably says "Auth=No" - this means that the CoA didn't succeed.
3. https redirection has to be specifically enabled on the WLC (I keep assuming here that you are using a Cisco AireOS controller). This is a CPU intensive task. All OS captive portal detection mechanisms "test connectivity" using http and not https. Why do you need https URL redirection?

[damode]

Hi Arne, thanks for your reply.

1. I am not using Remember-Me feature.

2. Once the CoA has been sent to the WLC, the client is disconnected from the WiFI and then has to re-associate.

   This is the behaviour, I am not seeing. Even when the client is disconnected, it still shows in session in ISE.

As stated in my post, when I reconnect the client, it shows 0.0.0.0 IP on the clients page on WLC under Monitor. What I have noticed is, when I "remove" the client from the active clients page on WLC, the client then immediately reconnects without any issues. Which seems related to the CoA issue you have indicated.

I have also checked the ACL you mentioned is indeed being used to pass on WLC. Please see the attached pics. All the steps I have followed are from Cisco's ISE training which has this particular use case.

1. With respect to HTTPS redirection, if Cisco recommends to disable captive portal bypass on WLC and HTTPS redirection is disabled, then on Apple devices, when SSID is connected and guest goes to any HTTPS link, he doesnt get redirected to guest portal for authentication. Hence, I had enabled HTTPS redirection. However, what would be your recommendation in this case to fix the redirection issue for HTTPS links if it is disabled ?

[Arne Bier]

Sure - regarding the https redirection and Apple devices, this is an issue. I have to admit that I don't disable the CNA bypass feature unless I have to (e.g. for BYOD using dual-SSID). I like my users to select the SSID and then have their OS pop up a browser or a CNA (Apple) to allow them to login. The problem is the CNA ... it's not a browser and it causes us all hassles.

I would check the following

1) Is your WLC always sending the initial MAB request to the same PSN that is referenced in the URL redirect? Since you have 2 PSN's, I assume that you have a Policy Set that redirect to the correct PSN node in either case (by checking the ISE Hostname in the Authorization Rule).

If this is working well, then run some tcpdumps on that PSN to see whether the ISE node is sending a CoA Disconnect to the WLC when the user logs in.

At the same time, run a WLC debug (debug client <mac>) and check the logs to see whether WLC is receiving the CoA. If not then you have an issue. Of course, if it is, then you should see the CoA ACK come back to ISE.

[damode]

So after a lot of troubleshooting with TAC, eventually the fix turned out to be a simple AP reload.

However, this time even though after reconnecting, the device immediately connects to the guest network (which wasn't the case before), there is still a certain delay in getting internet access. This is only on iPad. On Android device, its working fine.