Wireless Access

Hey,

 

We are using packetfence as an external captive portal.  We are doing MAC authentication and after that's all set we do a policy on the captive portal role the user has as follows: 

 

1 user <external CP IP> svc-https permit
2 user any svc-http dst-nat 8080
3 user any svc-https dst-nat 8081

 

HTTP works correctly.  Client gets on wireless.  Get's an IP.  Goes to a site like google.com and receives a 302 redirect form Aruba saying redirect to external CP and proceeds to packetfence. 

 

IF a user tries to go to an HTTPS site though, and types in https://google.com, the user first receives the default securelogin.arubanetworks.com certificate error saying it can't be validated, then I accept the warning and get to my external CP.  

 

Why is Aruba presentig a cert first and how do I get around this so users aren't seeing an aruba cert before getting to packetfence.

 

Hope all that makes sense - please let me know if I can provide any more info or if anyone has any ideas.... Working with Aruba support at the same time but not getting anywhere yet.

 

Thanks!

 

Of course, right after I post this I find a post that seems to be similar to my issue:

 

http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Redirect-to-Captive-Portal-using-HTTPS/m-p/252597/highlight/true#M55481

 

But what I'm confused by is why Aruba needs to present/ terminate the SSL session at all.  Client goes to https://google.com - Aruba should see the traffic and present the redirect dst-nat 8081 telling it to go to https://<my captive portal> and let my captive portal present a cert.  Which it does, BUT only after aruba presents a cert first.

 

 

it is because the very same 302 redirect that you saw in the http case now needs to be sent inside the https session that the client is establishing. To achieve what you're asking about, you would need to alter the ACL as follows

 

user any svc-https dst-nat 8081

 

to be

 

user any svc-https dst-nat 443 ip 1.2.3.4

 

where 1.2.3.4 is your desired destination. If you do this, you will lose all the extra info that goes on the cp redirect url, i.e.  ?cmd=login&mac=00:21:6b:0b:11:22&ip=172.16.90.252&essid=something&url=http%3A%2F%2Fsomewhere%2Edot%2Enet%2F

 

If missing this "window dressing" is ok for your needs, presuming you are going to handle the authentication and redirects etc, then there is nothing to stop you from bypassing the controller for the 302 redirect.

 

regards

-jeff

 

Understood - that makes sense.  We went the route of doing a dst-nat to the server.  But the problem we ran into is the cert error in all browsers warning that the browser expected "https://chase.com" or what not and received the packetfence cert... And on certain HTTPS sites that do HSTS like google or reddit the browser doesn't even let you proceed.  Are there any Aruba side work arounds for this or is that normal behavior?  I see based off the following post I understood that it is what it is and unless we serve packetfence on port 80 we will have this problem.

 

http://community.arubanetworks.com/t5/Wireless-Water-Cooler/How-are-you-all-dealing-with-HSTS/td-p/239328

 

Thanks!

there is no workaround. the user should go to an http site first and not HTTPS. unfortunately because you do not have the chase certificate the browser will not let you proceed, if you "faked" it and forced the redirect it could be considered a "man in the middle attack". that is why guest users should attempt HTTP sites first. no other way around this.

as CJoseph said in another thread somewhere on Airheads, its an industry problem

Thanks a bunch for the responses.  That's what I was afraid of.  I understand the reasoning behind it, but I know this will generate tickets from users trying to get to an https site like google.com  and not being let through.  Thanks again!