Security

Hi All,

 

I'm trying to build a 7220 cluster with captive portal guest access (8.2.2.0). 

 

Running into a couple of weird issues which i thought i'd share in the hope others may have solved already. 

 

The controllers in L2 cluster with VRRP enabled. Guest network is deployed as L2 (separate upstream router) and management network unreachable from guest network (no route / firewalled).

 

Issue #1

 

ip cp-redirect IP has been configured for IP address assigned to interface in user VLAN on all controllers.  External captive portal solution uses "switchip" attribute in redirect URL to trigger the HTTP post back to controller for user login. This switchip is being sent as the VRRP interface address of the MD's in the cluster and not the ip cp-redirect address i'd expect to see. Result is clients attempt to post back to cluster VRRP (non reachable) and fail. 

 

Initial fix was to remove VRRP from cluster and this solved the issue of the switch ip. Not sure if this is correct - seems buggy. 

 

Issue # 2

External captive portal solution (purple) requires http only authentication as it posts back to IP address and not FQDN of controller. when user posts back to ip cp-redirect address the traffic get captured by the default captiveportal ACL in the pre-login role and is redirected back to login page causing a loop. 

 

Presumably if this was FQDN that matched controller cert (i.e. when using ClearPass) then "magic" routing would capture call to FQDN and redirect to controller bypassing cp-redirect rule and allowing POST for radius to take place. 

 

What i'm seeing is that i need ot push an ACL into the pre-auth role allowing HTTP access to the ip address specified for ip cp-redirect interface on each controller. this seems to work fine.  Not sure if this is correct or will break other things. 

 

 

Issue #3 - when user completes login, the logout popup window is displayed, regardless of the state of the logout popup window option in the captive portal authentication profile. 

 

Anybody else had this issue? is this a bug?

 

hoping i'm not the only one thinking these things aren't right. 

 

scott

 

 

 

Have you configured a trusted webserver certificate to your controllers for captive portal authentication?

 

Typically, I have avoided using switch-ip in hosted captive portal solutions, using instead the certificate cn name for the client post to ensure it reaches the correct controller. This should resolve both of your issues, although I'm not familiar enough with Purple to know whether they support that method rather than a specific IP. Other captive portal platforms that I've used will use the FQDN of the controller's certificate instead.

Hi Charlie,

 

Purple is very rigid in how it needs to be configured. We cannot define the URL for the authentication post as it only takes the switchip variable from the URL. Purple also requires HTTP authentication for this reason to prevent certificate errors so we don't have a certificate installed.

 

They have a reference configuratoin guide for 6.5 however nothing for 8.x. it seems things are a little different in 8.x and this may prevent proper integration between the two systems. 

If the switch-ip needs to equal the cp-redirect ip, then you may need to update the controller configuration so that it knows to use the public/guest IP instead of the current interface.

 

On the guest pre-auth role, you'll want to ensure that the controller is also allowed. Typically, https traffic to the switch-ip (netdestination mswitch) is allowed by default. Since your cp-redirect is not the same as the switch-ip, and traffic is specifically http and not https, you may need to statically allow that the same way you whitelisted traffic to the Purple portal.

Thanks Charlie,

 

As you suggested i did whitelist the cp-redirect IP and this got me past that issue. i think i've hit another bug now as the logout popup window keeps triggering for these users despite the config being disabled. 

 

Scott

---

@scottdoorey wrote:

Thanks Charlie,

 

As you suggested i did whitelist the cp-redirect IP and this got me past that issue. i think i've hit another bug now as the logout popup window keeps triggering for these users despite the config being disabled. 

 

Scott

---

What version of 8.2 are you running? I've not seen the logout popup come up in recent testing with 8.2.2.0 or 8.3.0.1. That's not to say it isn't a bug, hopefully it helps narrow the scope a little.

8.2.2.0

 

Scott

Was the configuration pushed from a mobility master, or are these standalone controllers? 

 

On the md or standalone controller, what's the output from "show aaa authentication captive-portal"? I suspect there is more than one portal profile, so in addition to the profile list (for the number of references for each profile), what is the profile detail "show aaa authentication captive-port <profile-name>"?

Mobility Master

(md1) *#show aaa authentication captive-portal Captive Portal Authentication Profile List ------------------------------------------ Name References Profile Status ---- ---------- -------------- @XXX-guest-logon_cppm_sg 1 ClearPassGuest 1 default 1 Total:3 (md1) *#show aaa authentication captive-portal @XXX-guest-logon_c ppm_sg Captive Portal Authentication Profile "XXX-guest-logon_cppm_sg" ------------------------------------------------------------------------------- Parameter Value --------- ----- Default Role guest Default Guest Role guest Server Group XXX Redirect Pause 1 sec User Login Enabled Guest Login Disabled Logout popup window Disabled Use HTTP for authentication Disabled Logon wait minimum wait 5 sec Logon wait maximum wait 10 sec logon wait CPU utilization threshold 60 % Max Authentication failures 0 Show FQDN Disabled Authentication Protocol PAP Login page https://region3.purpleportal. net/access/?acmac=XXXXXXXXXXXXXX Welcome page https://region3.purpleportal. net/access/?res=success?acmac=XXXXXXXXXXXXXX Show Welcome Page No Add switch IP address in the redirection URL Enabled Adding user vlan in redirection URL Disabled Add a controller interface in the redirection URL N/A Allow only one active user session Disabled White List walledgarden Black List N/A Show the acceptable use policy page Disabled User idle timeout N/A Redirect URL https://XXXXXXXXXXXXXX Bypass Apple Captive Network Assistant Disabled URL Hash Key N/A

we're definitely using the right profile. the second one was created for another use case. 

---

@scottdoorey wrote:

we're definitely using the right profile. the second one was created for another use case. 

---

That was my thinking, but it sounds like the reference count for ClearPass lines up with your expected use count.

 

Do you have a mac or other device that you can grab a wireshark capture to see where the logout window is being triggered from?

I am having very similar issues with an 8.3.0.5 deployment. All configs pushed from the mobility master.

 

A few differences, everyone once and a while login is successful. When it is successful the logout window appears, even though it is unchecked.

 

Also, I have include switch IP in the URL. I imagine that it should show up as plain text in the URL as the rest of the information does, but it is not present.

 

Any Ideas?

unfortunately i was never able to get to the bottom of my issue as it was a temporary setup for a conference and i had to rip it out at the end. 

I'm getting similar behavior with purple captive portal in our controller.

 

It seems that the post generated from purple is using our controller management IP and not our "guest vlan" ip.

 

If I change the vlan for the guests to the management vlan everything works just fine.

 

I'm talking to Purple's support right now to resolve this, I'll post the news as soon as I get them so whoever reaching this issue could resolve it. 

Simple , Inside your HTML code , Just Edit the post itself and add the needed ip of the controller inside your guest vlan ( l3 address ) it will do a magic :)

Hey kdisc98, thank you for the reply.

Unfortunately this is a "purple" 3rd party captive portal, I can't change the the HTML code to include our IP on the POST.

 

 

You might be looking for the "ip cp-redirect-address" command

https://community.arubanetworks.com/t5/Command-of-the-Day/COTD-ip-cp-redirect-address/td-p/236

Thank you cjoseph,

Just tried that, but I'm still getting redirected to the management IP. I'm almost sure that It is Purples captive portal that is redirecting me whit the POST to that IP.

 

I'm going to submit a case with purple to resolve this and post any further updates here.

 

Thanks

I would install wireshark on a Windows laptop so that you can capture exactly what is happening on the laptop when submit is being pressed.

When I was troubleshooting this a few months ago I found that purple had a hardcoded configuration for the post back UrL which couldnt be modified.