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 permit2 user any svc-http dst-nat 80803 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.
Of course, right after I post this I find a post that seems to be similar to my issue:
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
user any svc-https dst-nat 443 ip 188.8.131.52
where 184.108.40.206 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.
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.
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!
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.