Effects of using https authentication on normal https traffic
-
Is there a negative effect on normal https traffic as a result of using https for the captive portal authentication?
We are using CP https auth/Cisco ACS/Windows AD to authenticate our users who are participating in our BYOD program as well as contractors, consultant, vendors, etc. After a person authenticates, all http traffic works great, https traffic that is generated by iOS apps over https does not, in most cases does not work.
-
I'm not quite sure I understand the problem…
There are several scenarios where using https auth may lead to problems at the initial step of authentication by the CP, due to OCSP issues (note: depending on your CA cert and your clients' browser). However, after inital CP auth the client's IP is added to a passthrough ipfw table and no further filtering is done.
-
We are having problems with https traffic, on both iOS devices and Droids, not sure about Windows at the moment. A user is redirected to the CP page and logs in successfully, after that they can hit any site on http but when they try to go to a https site it fails. We installed our wildcard cert but I am not sure that it is working with the intermediates. I don't even see state rules for 443 based on the individuals ip addressed reported in CP status but I do see them in the ipfw tables. I also see ip addresses for some that are not authenticated, even if I clear the state table they show back up.
We also have this setup in a lab with just Windows OS's and self signed certs on the pfsense box and everything is working correctly.
Can you provide a few links to the OCSP issue and I will see if it looks related to what we are experiencing?
Thanks
-
That sounds vaguely familiar, but if I remember right it was a client-side issue that went like so:
For example if you go to https://www.examplebank.com and ended up on the portal, you could go to any HTTPS site except for https://www.examplebank.com due to the way it cached that initial connect.
Not sure if anything can be done on the portal end of things for that.
-
Doing some more testing this morning after changing the cert to a self signed in production.
Just a note, this is not a typical out of the box setup, the pfsense session is running in a vm within our vsphere 4 environment. The LAN interface sits on one of our DC subnets while the WAN interface sits in one of our DMZ's. All CP clients are Cisco WAPS connected and all are policy based routed to the LAN interface in the DC. Firewall rules on the LAN interface is basically set to 10.0.0.0/8 allowed to all destinations. PF firewall optimizations are set to aggressive and hard timeout is set to 720 mins on the CP.
This morning I logged in with my ipad, authenticated with our guest account and was able to hit several http sites and https sites, no problem, at that time there were 2 CP sessions authenticated. Now we have 10 authenticated and I just had some test and http traffic is working fine but https traffic has decided to stop.
When I look at the state tables, I have a bunch of established sessions when I filter for 443, whats weird is that I have a lot of states for client ips that are not even authenticated to the portal. New clients that are authenticated get almost an immediate Syn_sent:closed and can not get to https sites.
-
At this point I am looking for ideas of things to check. There may not be a lot of people out there running in this type of configuration but I was hoping that someone has a similar setup, ran into some of the same issues, and could provide some feedback.
All the Best,
Mac -
Using HTTPS on captive portal has no relation at all to anything after they're logged into captive portal. Captive portal is 100% out of the picture after users are authenticated.
If you have a restrictive firewall ruleset on that interface, it could be permitting HTTP but blocking HTTPS.
-
The ruleset on the LAN side is not restrictive on the PFSense box.
However, it is restrictive on the acls for the network infrastructure. But even then, we use it mostly to filter traffic destined for our private subnets, only setting rules for resources that have been fronted with Netscalers or we feel are secure. I have had our network engineer remove his acl's in the past and it had no effect.
I am going to try setting up a test vm on the same DC subnet with the PF box as its default gateway and do some more testing, also going to do a capture on the pfsense box now that https is not working again.
Thanks
-
Just a reminder, inbound states are not indicative of traffic but the presence of outbound traffic. It wasn't until I started pulling captures that I started seeing the lack of return traffic. We have put bypasses in our Websense system for the WAN ip of pfSense and amazingly it started working.
Thanks to those that replied. I am looking forward to the next version of the pfsense definitive guide. I hope that it reaches into the technical depths a little more than the first one.
Best Regards,
Mac
