Wireless Access

I have been asked to disable the ablity to use HTTP for the redirect captive portal page on our guest network. I have already unchecked the box where it won't send the HTTP page only sends HTTPS, but it still allows one to type in HTTP:// and get to a non secure captive portal page. I have tried to remove the HTTP ACL from the session GUEST - Login but It still is working. 

 

This is for the controller captive portal or Clearpass guest ?

Controller

Hi,

Can you please confirm if you have removed http from the captive portal ACL under the guest logon role.

Also I assume under aaa authentication --> layer 3 authentication you have already uncheck use http for authentication.

Thank You.

Yes to both after we did that I was able to paste in HTTP:// and get the captive portal to come up. I called in a support ticket they are suggesting we delete the ACL svc-http-proxy2 and 3 we are seeing hits on the ACL

 

guest-logon            captiveportal     user  any                  svc-http-proxy2   dst-nat   8088         0         455         10056  ipv4

guest-logon            captiveportal     user  any                  svc-http-proxy3   dst-nat   8088         0         2           10057  ipv4

 

Last time I called in they said to remove the HTTP ACL and it didn't work. I even tried putting a deny in there that didn't work either. 

If you go to Management -- Captive Portal, then click on View Captiveportal, does it show https in the browser address bar?

I get HTTPS://   but as I said before that works fine what can be done is the S can be removed and they are able to get to the same page using HTTP://

Check Clearpass Guest -> Configuration. Check the box for "Require https for guest access". If this is already checked then all acces with http to a guest portal will be redirected to https.

We aren't using clearpass just the controller we plan on going to clearpass but not until the end of the year.

Try this:

 

config t
firewall cp ipv4 deny 192.168.1.0 255.255.255.0 proto http

 We are assuming that your guests are coming from 192.168.1.0/24

 

And do this to reverse it:

 

config t
firewall cp
no ipv4 deny 192.168.1.0 255.255.255.0 proto 6 ports 80 80

 

WIll that block all HTTP traffic or just during the login phase? While logging in it is using Role Guest-logon but after one is authentiacted it is using guest role. 

That will block all http traffic to the controller, period.

We don't want to block all HTTP traffic only during the captive portal page when the user is using guest-logon

Why if the default action is to redirect to https anyways?

The problem is if you block all HTTP traffic while a guest is on the internet they can't go to webpages that are not HTTPS we only want the authentication process to use HTTPS.

Pages from a user to the internet are NOT destined to the controller.  It will only affect traffic TO the controller on port 80.

 

 

So this firewall block will not block HTTP traffic once someone has authenticated. 

 

config t
firewall cp ipv4 deny 192.168.1.0 255.255.255.0 proto http

 We are assuming that your guests are coming from 192.168.1.0/24

 

And do this to reverse it:

 

config t
firewall cp
no ipv4 deny 192.168.1.0 255.255.255.0 proto 6 ports 80 80

No.

Been ahwile i had not been able to test this unitl I setup a small 620 controller at my house beacuse didn't want to try this on our production controllers, but anyway it didn't work still I was able to authenticate with HTTP, but at the same time I had contact Aruba TAC they suggested I remove the HTTP firewall statements from the captive portal firewall session this works but has a catch.

 

When you go to the internet the first time you can't get the redirect page when going to a HTTP like www.google.com but if you go to https://www.google.com then you get the redirect page. That probably isn't going to work because also I noticed on my Ipad I'm not getting the apple redirect page at all now. I'm not sure this is ever going to work because if you block HTTP to the controller it will never know to send you the re-direct webpage. I have since spoken to our security department and outlided the risk here no one is really ever going to try and authenticate using a HTTP page when they are presented with a HTTPS page. Even if they were someone at that exact time would have to be capturing their unencrypted data and all just to get on the internet not real life situation. 

 

 

did the security guys accept that? i do agree with you btw.

I think so havne't heard back from them we are getting clearpass at the end of the year I think that should take care of the issue anyway. I think this could be fixed probably take a code fix to do it Aruba wanted me to get back to them on it I might do that.

Even if you uncheck HTTP in CP profile, users can still open HTTP page and get redirected to CP page. You should see difference in redirection URL:

 

HTTPS::

HTTPS://securelogin.arubanetworks.com/.....

 

HTTP::

HTTP://<controller-ip>.com/...

Yes what a user can do is simply change the HTTPS://  to HTTP:// and it works we have done a wire shark packet capture and see while we are authenticating it is sending it unencrypted. 

Why would a user do that, though?  What is the motivation?

 

The command I listed above will stop answers from port 80 to the controller, ONLY.

Somone could intercept the logon credentals if it is sent in plane text I think the security risk is very small but our IT security department wants it close. We are going to purchase clear pass by the end of the year so I'm trying to convence them to forget about this due to Clear pass should resolve the issue.