New Policy Rules Not Working

Hi Rhys,

Can you tell me if you have any clients in full webcontrol?  

and what happens when you go to sophostest.com and click on the adult test.. 

as a normal rule, you "can" set up authentication as described above.. but I really wouldn't recommend it for a couple of reasons.

#1 - generally you should try and avoid mixing public/un-authenticated wifi with your secure wifi

       the best thing to do here is to set up a second un-managed appliance and configure it for no-authentication and define a default policy with no https scanning

       then use another appliance or more than one appliance that is managed to filter tour secure wifi and wired lan traffic with all of your policy's and https scanning etc

this will avoid your pain with phones and such and allow you to properly inspect your secured traffic. you will not be able to enable https scanning with phones and such

and not having https scanning enabled will not allow the appliance to properly police policy and generate reports for encrypted traffic. 

#2 as for authentication, doesn't really matter what source does it.. the big thing to consider is that you do NOT want super long lease times on the IP's The problem here is that authentication requires 2 basic things.. and IP and a username.  The appliance supports both SSO and Captive portal. normally sso is re-authed every 4m59s .. however captive portal is only re-authed based on what you set as a time out in the portal configuration. 

so if you don't recycle ips very often, or have a long time set in the captive portal.. you may find users sharing ip's that are not expired and still valid from another user.    Its best to avoid this scenario..  option 1 helps a lot.

its also important to know that our licence included VM's  so if you need to set up another one to make your network work more efficiently, by all means contact your account manager and ask them for an activation code. 

personally I set it up like this:

10.10.1.0/24   wireless unsecure

172.16.100.0/24   wired lan

192.168.100.0/24  servers

172.24.100.0  branch office

1 appliance runs 10.10.1.0/24 and only has a default policy that applys to all guests by default.     (you could create a single elevated policy like log in guest password)

2 appliances managed by a management appliance, one at site A: 172.16.100.0/24 and one on site B 172.24.100.0/24    they are joined via a vpn and go into port 12 .. then switch rules basically has a rule that says anything on port 443/80 send to appliance .. with an omit to get out to the internet from the appliances ip. 

the 172 range is omitted from authentication and has its own policy that allows it to update and not really go anywhere else.   (as server tasks are underprivileged user they may not have a credential to authenticate on the network) 

some resources for you.

if you have endpoint clients see this kb: https://community.sophos.com/kb/en-us/122384 

deployment mode kb: https://community.sophos.com/kb/en-us/126692

authentication kb: https://community.sophos.com/kb/en-us/126599

also see the policy tester and make sure you test with the domain\user and the ip address .. this will tell you if the result is expected.. the other thing you can do is open a support case when you can live test and an engineer can assess your authentication by looking at the query type. 

cheers

I appreciate your response, but I think we may be on different pages a bit.

If the solution to this problem is to set up a second device, I suppose that can be done - however, there are already policies in place on this device which accomplish this task - these policies are the ones I based this configuration off of.

The policy I am trying to get working is not for public devices or use. It is for internal mobile devices, which still need to be subject to HTTPS scanning. These devices are owned by the entity I am supporting, and are tied to an MDM which installs the Root CA for Sophos.

I agree that your suggestion is a better way to accomplish my goal, however there is only so much network overhauling that can be accomplished at once. Unfortunately, I don't think the powers that be will allow for such an undertaking on short notice.

Lease times for this VLAN are roughly 12 hours, but again, the devices on this VLAN are used by authorized members of this entity.

Everything else is functioning normally, we use RADIUS and Active Directory for our authentication on Wifi for default VLAN and our Captive Portal and SSO works fine.

There is a set of policies defined for the Servers, which bypasses them from authentication by IP address. This is essentially all I am trying to accomplish with this 10.8.0.0 VLAN.

Hopefully that makes things a little more clear.

Thanks,
Rhys

Hi Rhys,

The biggest reasons for separating out the guest wifi are for security of traffic, https scanning and configuration of the captive portal.   

In your case pushing out the certs will get around https scanning, so that's good.  If security of traffic is not a big issue for you, then thats fine.. the portal configuration is definitely set to long.. 

what happens is every time a user authenticates with a credential it will cache it for 12 hrs.. ..  so if you get a in a situation where users authenticate all the time, your going to be recycling ips before the portal timer expires. 

so the first thing to do is lower the portal to 1 hr.. and see how that goes this will expire cached credentials faster.

unfortunately the next step would be to look directly at the credential store on the appliance.  To do this you will need to open a support case and enable access so the engineer can check the credential cash and see whats going on.

I suspect you will have multiple IP's in-use by multiple people at the same time. 

another thing you can do is run policy checks from the /config/group policy / policy tester

use the same site.. ie: www.theonion.com

under user name.. do the first test with DOMAIN\user and the second with an IP from the users hand held.. make sure the policy is the same..  (you may need to do a couple of samples)  but I suspect you will find cases were a different user is associated to an ip in your wifi network because the credential is still in use and has not expired. 

give that a shot and open a case.  if the tests come back as I suspect.. lower the portal time.  if your still sharing ips before they are recycled you cloud lower the lease on the hdcp server its self.. or at that point deploy a dedicated appliance that is not managed so it has its own credential store thats specifically for that wifi network.

Thank you for your response, but I have resolved this problem.

I do want to point out, that in my response and in my original post, I stated this is not a guest network.

In any case, I resolved this problem on my own. I understand your concerns and suggestions, but you misunderstand my issue as they are not applicable.

Thanks,

Rhys