Security

Hi everyone.  I recently upgraded my lab (just my lab, thank god) guest controllers from 5.0.4.4 to 6.1.3.1 and now users don't get redirected to the controller internal captive portals.  All the browsers on the clients I try all (except for IE, which just shows a blank page) report a redirect problem.  Chrome says there's a redirect loop, Firefox says the page isn't redirecting properly, and Android reports too many redirects.

 

Downgrading back to 5.04.4 resolves the issue.

 

I do have a TAC case open and over an hour of troubleshooting hasn't helped.  Anyone else seen anything like this?

I did see this myself once. To fix it, I did an intermediate upgrade to 6.0.1.something (can't remember exactly which), then on to 6.1.3.1. The release notes don't say this is required, but some debugging I did when it was broken seemed to indicate the controller wasn't looking for the files in the flash properly (looking in wrong paths). After I did the two step upgrade it was fine. As it's only a lab, maybe try it?

---

@mike.j.gallagher wrote:

Hi everyone.  I recently upgraded my lab (just my lab, thank god) guest controllers from 5.0.4.4 to 6.1.3.1 and now users don't get redirected to the controller internal captive portals.  All the browsers on the clients I try all (except for IE, which just shows a blank page) report a redirect problem.  Chrome says there's a redirect loop, Firefox says the page isn't redirecting properly, and Android reports too many redirects.

 

Downgrading back to 5.04.4 resolves the issue.

 

I do have a TAC case open and over an hour of troubleshooting hasn't helped.  Anyone else seen anything like this?

---

Have heard a couple unreproducible cases about this.  Installing wireshark on the client and doing a packet capture is a good way to possibly get to the bottom of this.  Does the ip cp-redirect remain unchanged?

 

I think I might still have a controller somewhere still in the broken state (as well as the fixed one). From what I recall, the redirect on the client constantly loops to the original client page. The controller debugs show the redirect generated internally pointing at "null" locations (i.e. nothing in the path). Something like that.

@Colin - I do have Wireshark on the client and what it shows is the client trying to access google.com then the reply back, which is shown as the IP address of google but I'm certain it's the controller, is an HTTP 302, Moved Temporarily.  Then the controller initiates a normal FIN sequence with the client and the connection is closed.  Then that entire cycle repeats four or five times and the client gives up.

 

Yes, the ip cp-redirect stays the same throughout software upgrades/downgrades.

 

@Racking - I'll start looking at controller debugs as well.  I'm going to try your two-step upgrade path as well to see what happens when I do that.

 

Thanks guys!

 

 

Mike,

 

Can you please provide the ticket #?

Ticket #1293081.

 

I've run through a lot on my own because TAC has been no help whatsoever.  They're just fixated on my config, which I told them I've been using just fine for four years now.  They won't do any debugging.

 

Last Friday, I blew away both guest controllers completely (wr erase all) and started out with 5.0.4.5, licensed the controllers and did a flash restore.  That was a nightmare.  Restoring flash doesn't give you your exact configuration back, it appends custom session ACL and role entries onto the default entries and really makes a mess of things.  I got the config back to where it was orginally, but the CP wasn't functioning.  No redirect loop, but not functioning.  I figured the flash restore wasn't a good idea at this point.

 

I decided to start from scratch again.  This time after licensing the controllers, I just went ahead and copied and pasted my config in, making sure I pulled all the default stuff out of the default policies and roles that I use.  It finally started working properly again on 5.0.4.5 and upgraded to 6.0.2.1 and everything worked.  However, as soon as I upgrade to 6.1.3.1, all browsers report some kind of redirect loop.  I'm going to try 6.1.2.8, but I don't think that's going to make a difference.

I assume that you are using the captive portal page uploaded on the controller and not the external captive portal. Correct?

 

Just checked the packet-captures uploaded on the ticket notes. It looks that the location in the redirection URL (HTTP 302) is not correct.

 

In non working scenario:

  Location: http://utk.edu/\r

 

In my setup, for working scenario, the redirect locartion is:

  Location: https://securelogin.arubanetworks.com/cgi-bin/login?    cmd=login&mac=00:1c:26:89:af:78&ip=10.0.32.22&essid=PCC_Student&url=http%3A%2F%2Fpac%2Ezscaler%2Enet%2Fpcci%2Eedu%2Fproxy%2Epac\r

 

Can you please take client side packet-capture for working and non-working scenario to compare the difference? 

 

I will go through the config to understand the setup. As of now, I understasnd that you are using L2 GRE tunnel to redirect the guest traffic to the central guest controller and trying to show the captive-portal from there.

Hi Alap - Yes, I am using L2 GRE tunnels from my local controllers to redirect traffic up to central guest controllers.  I'll go ahead and get fresh sniffer traces for working and non-working scenerios and post them to the case.

 

Thanks for the reply!

Hi Alap - I went ahead and uploaded two fresh sniffer traces to the case.  One from AOS 6.0.2.1 that shows a correct redirect and one from 6.1.3.1 that shows the incorrect redirect.  What you saw in my original sniffer trace looks to be the problem.  AOS 6.1.3.1 (and 6.1.2.8) puts the original URL requested in the HTTP 302 temporarily moved redirect, which causes a loop.

Hi Mike,

 

Thanks for the captures. As we observed, the redirection location is incorrect after the upgrade. TAC is trying to reproduce the issue in the lab setup. 

Stay tune...

 

-Alap

Mike,

 

Just for the upadate, TAC is able to reproduce the same issue in the LAB setup using your configuration. We will work with develpers to find out the root cause. Meanwhile, we are also checking if there is any work-around. 

One of the escalation engineer will reach out to you and update you regarding the same and answer any questions you may have. 

 

I will update this thread once we find out the root cause or work-around.

 

Thanks,

Alap

To close the loop on this, in 6.1 you must add the following to your controller configuration for proper redirection:

 

(config) #aaa authentication wired
(Wired Authentication Profile) #profile default

 

I have the same problem and added

(config) #aaa authentication wired
(Wired Authentication Profile) #profile default

but the problem still exists.

Is there any update?

Please open a support case.  You could have a different problem.

 

I am also experiencing this issue with our captive portal setup using v. 6.1.1.0 and integrated with clearpass guest self registration. My experience has been the captive portal is displayed correctly (hosted on clearpass server) for a period of time, but eventually the redirects start to happen (IE just times out, other browsers show "too many redirect" messages). This is also user specific, so a brand new user can authenticate just fine, but someone who has been using the guest network all day will most likely see this mid afternoon when trying to reconnect.

 

There doesn't seem to be any errors on the clearpass but the error on the controller that I see right around the time this happens is

 

error 522043: Configured Session limit reached for client IP=[my IP address].

 

Not sure if this is something being sent from clearpass to the controller or if it a configuration present in the controller itself that is causing this error. More over I don;t know what the session limit is even set to, where to find it, etc. The recomended action in the syslog reference guide is to turn the client off until sessions have been cleared but would be nice to resolve a different way.

 

I confirmed the wired AAA profile is set to default as suggested in a previous post. I also have a case open with TAC, #1314697. The tech's have pcaps and controller logs.

 

Has anyone had the same experience with the same logs in the controller and the too many redirects/timeout? Any progress on this issue from the other guys that posted originally?

 

-GR

GR,

 

The error message which you mentioned, points that some users are generating too many sessions and reaching the session limit. By default the # of session limit per user is 65K, but u can reconfigure it under user-role to lower it down. Ususally in Captive Portal auth, people lower down that number, so that one user do not fill up controller's session table. This can happen due to virus on the user maching or some kind of DOS attack. 

 

Thank you for opening TAC ticket. Live debugging will help to troubleshoot the issue quickly.

 

Ah I found it. I had followed the best practice guide and reduced it down to 128 sessions. Maybe the number should only be reduced for unauthenticated guests and leave the authenticated guest user as the default 65k value? It seems as though 128 sessions per user fills up rather quickly. When it happens again, I need to load the session table to see what exatly is taking up the bulk of them, maybe I can limit it some other way.

 

Thank you for the input.

 

-GR

I have the exact same problem with version 6.1.2.3.

I have a case open: Case # 1315382

I'm having after sn upgrade to 6.2.1.4 the same problem right now, please anyone coild post the solution to the incorrect redirection??

i think the reason will have changed from person to person. can you start a new thread, explain which version you came from, provide your config, use a tool like http watch or inspect element in chrome to check how the redirection loops goes?

I have found that cp-redirect-address is pointing to my controller loopback address, if I change this address to whichever other with the command ip cp-redirect-address (even other not in our domain) then captive portal works fine.

 

I also have tested that controller ip address be allowed for any service in captive portal default role (preauthentication role) and in postauthentication role, but with no success, I don't reach the reason for this behaviour....

 

I'm going to check with other controller in version 5.0.4.12 if cp-redirect-address also was pointing to loopback address,  but some explanation will be welcome...