Guests continually being redirected to "Connection Successful" portal page

[dmills488]

We just recently upgraded ISE from 2.1 to 2.3 After this upgrade we began experiencing issues with Guest endpoints.

Our policy states that if a user's LastAUPAcceptanceHours is less than 24 hours they can continue on.

If LastAUPAcceptanceHours is 24 hours or greater they should be redirected to the hotspot portal page and accept the AUP (which should reset the AUP timer). Once they hit accept they receive a connection successful page and a CoA is sent to ISE and then the WLC.

The problem occurs for users with LastAUPAcceptanceHours greater than 24 hours. They receive a redirect but instead of going to the AUP page they are sent straight to the "Connection Successful" and then send out a CoA. This disconnects them and when they reconnect they are sent straight to the "Connection Successful" page. This continues on indefinitely because the endpoint never hits "Accept" and resets the AUP timer.

Has anyone seen this before or know what the problem may be? Cisco tac case has been opened.

[paul · Accepted solution]

I know this won't answer your exact question but a different way to handle this is use the built in device registration in the guest process and the purge policies in ISE.  I usually setup a custom whitelist for my portal use cases.  So in your case a endpoint identity group called "Hotspot_Guest_Devices" could be setup. 

Then a purge policy can be setup around that to purge that list every night (elapsed days less than 9999).  I know that is not your exactly 24 hours thing, but it is very predictable.  The purge policy runs at 3:00 a.m. by default so you know the users won't have to see the portal again until the purge runs at 3:00 a.m.

Then set the Hotspot portal to use that identity group for registration and then your policy set is straight forward:

If in Hotspot_Guest_Devices whitelist grant Internet access else redirect to Hotspot portal.

[dmills488]

That was actually the workaround I was planning on using. The 9999 days, is that referenced somewhere? I was thinking I'd have to set it to elapsed days less than 1 then purge every endpoint once to reset the timers.

[paul]

The elapsed days less than 9999 is a trick I use to guarantee the list gets purged every night. The problem with using elapsed days less than 1 is if for some reason the MAC address was already in the system for longer than a day (probably not realistic) it wouldn’t get purged. The less than 9999 guarantees everything in the list will get purged. Pick any high number you want.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[hslai]

It should also work with the elapsed days greater than 0.

It appears that the non-hotspot portals have more AUP options (see attached screenshot) compared to the hotspot ones.

[paul]

The problem with elapsed days greater than 0 is you get inconsistent identity group removal times depending on when the MAC address was learned.

For example, if your purge time is at 3:00 a.m. and the MAC address gets learned at 3:01 a.m. you will get 47 hours and 59 minutes of access before your MAC address is purged. If your MAC address gets learned at 2:59 a.m. you will get 24 hours and 1 minute of access before your MAC address is purged. That is why I stopped using that in my rules and went to elapsed days less than 9999. Then the message to everyone is the same. The list gets dumped at 3:00 a.m. every night.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[hslai]

I do not see why greater than 0 would not give the same as less than 9999. Perhaps, you are thinking about the default "greater than 1 day(s)".

[paul]

Greater than 0=

Purge day 1 3:00 a.m

Endpoint learned 3:01 am

Purge day 2 3:00 am

3:01 am day to endpoint goes to 1 day

3:00 am day 3 endpoint purged

Time in group 47 hours 59 min

It all varies on when MAC is learned and give through portal. You could get purged day 1 through 3.

My way you always get purged day 1.

Sent from my iPhone

[Jason Kunst]

Why not less than 1 or equal to 0?

[paul]

That works but if for some reason the MAC address was already in the system it would never get purged. Say it was in the system for 1 day already when you put in purge rules. It wouldn't get purged. Less than 9999 guaranteed the list is aways dumped because no way a new endpoint in system longer than that.

You could use any impossible condition. Elapsed days not equal 56789.

Sent from my iPhone

[hslai]

OK. I see it now. Somehow, fractional part of the days are not considered, such that 0.1 day is considered as EqualsTo 0, but not GreaterThan 0.

We have the following enhancements since ISE 1.3:

CSCuv31918 Need capability to purge all endpoints in an EP group

CSCuv31921 Endpoint purge rules to Allow multiple rules with Same ID groups

CSCuv06727 ISE - Unable to create purge rules with compound condition using "OR".

[vmiraboronat]

Hello,

I'm facing a similar issue to this one, but instead of being redirected continuously to the 'Connection Successful', the guest only is being redirected once and then the access is granted. I mean, we don't have a loop, it is just that the user doesn't get the AUP page.

I'm also using a hotspot to give internet access and using the LastAUPAcceptanceHours on the authorization policy. The issue also happens when users that have been on the system for more than 24 hours (or the hours set here)

Initially I was also going via the option of adding all endpoints to a group and purge them during the night, but this environment is global meaning that we use two Cisco ISEs for guest access all over the world. So purging the enpoints at 3:00 a.m. in Europe affects directly to the guests in San Francisco, as the scheduler uses the primary PAN timezone (which is in UTC).

Any ideas so that the guest gets the AUP page instead of the 'Connection successful' one?

By the way, using version 2.4 patch 5.

Regards.

[hslai]

That sounds like CSCvg74394 but that bug resolved before ISE 2.4 FCS.

Thus, I would suggest you to open a TAC case to debug further.

[vmiraboronat · Accepted solution]

Hello and thanks for your quick answer. After all it seemed that I had one Authorization rule missing. I need three of the, one for "bypassing" the portal if the AUP has been accepted on the past 24 hours, another one to force the AUP acceptance if it has been more than 24 hours but the MAC is still on the system (this is the one missing) and a third one for the 1st login (the standard Wireless_MAB).

After adding the rule missing and doing some tests lowering the time to 1 hour, it seems it's working as expected.

Thanks again!

Víctor.

[branin-lippincott]

I apologize for necroing the thread, but this is the only place I've been able to find that has the issue I'm running into.

Victor: Can you please describe the rule that was missing in a bit more detail? (I know it's been 5 years.  Sorry!)  We are running into the same issue where everything works great the first time, but after 1 hour (which is the timer that we have set and want people to have to "re-accept" the AUP), they just get a "connection successful" page from the AUP portal and don't have to re-accept the AUP (and they also don't have Internet access, since their LastAUPAcceptance is more than 1 hour ago).

Thanks!

Branin