This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

New Policy Rules Not Working

Hello All,

 

I am new to this community - I have inherited a Sophos Virtual Web Appliance, set up in transparent mode for the network I now manage.

I have been taking time to reverse engineer the configurations, and have slowly been learning how my predecessor set up the infrastructure (little to no documentation)

In any case, they currently run RADIUS for authentication in Wifi and through the VWA. These policies work properly, and users are filtered correctly.

However, I need to deploy some mobile devices which do not play nice with RADIUS. I have created an SSID on the AP's, tied it to a VLAN, and set up routing for the VLAN.

I can access the internet, however the VWA is filtering the traffic for this VLAN with the Default policy, and not the new IP-Based policies I have created.

Essentially:

Under Group Policy -> Additional Policies.

--Mobile Devices 

---Manual Entries: 10.8.0.0/21 (IP range for the VLAN)

---Schedule: All the time

---Turn this policy on for machines connecting from anywhere

 

As well, in System -> Authentication -> Profiles

--Mobile Devices:

---Manual Entries: 10.8.0.0/21

---Authentication: Bypass Authentication (use IP-based policy rules)

 

And in Connection Profiles:

--Mobile Devices

--- Include only the selected IP's in this profile: 10.8.0.0/21

 

I have checked the other policies in place for servers, guest network, etc - it seems I have everything configured the same, but these policies for this VLAN do not work.

I have tested it by placing several devices on the VLAN, as well as using the Policy Test tool under Group Policy.


Can anyone perhaps provide some insight as to why this doesn't work?

 



This thread was automatically locked due to age.
Parents
  • 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

Reply
  • 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

Children
No Data