What's the best way to filter web content for a remote office, without deploying another ProxySG appliance or software client?


Article ID: 167374


Updated On:


ProxySG Software - SGOS


This setup will allow for web content filtering to be preformed by the home office ProxySG via VPN/secure tunnel, while the actual content will be requested and delivered by the internet connection that is local to the remote office.  This will reduce the traffic sent and received over the VPN/secure tunnel, while still having some control of the web content that users can access.

1. Enable the DNS Access layer by launching the VPM--going to Policy--Add DNS Access Layer
2. Set your destination as Category and select the groups you wish to deny.
3. Set the Action as Reflect IP--Proxy IP and enter the IP address of your ProxySG.
4. On the Web Access layer ensure you have the same content filtering category rules applied so that they match the DNS access layer rules.

What this will do is check every DNS query. If it matches a denied category the proxy will report the IP address of the ProxySG which will deny access.  If the site is allowed, it will perform a proper DNS query and report back the correct IP address of the server thus allowing the content to load via the internet connection local to the remote office.

The above configuration is only valid when you have a select number of users located at these remote offices, if you have a significant number of users it is recommended that you consider placing a ProxySG local to the remote office, or use the Blue Coat Unified Client (Windows 7/8) or the Blue Coat Proxy Client (Windows XP).  Using the proxySG as a primary DNS server for all users could result in performance issues on the appliance and is not recommended.

The ideal environment for this type of configuration would be a remote office that is connected to a branch office through a VPN tunnel with split-tunneling enabled.  All internal requests (including the DNS query) would be made over the VPN tunnel while any external requests would be delivered via the local internet connection. This provides the additional benefit that web browsing does use up additional bandwidth through the the VPN tunnel or secure connection,  Some additional things to take note of when implementing this are:

When using the above configuration please take the following into consideration:

1. If the VPN tunnel or secure connection between the main branch and remote site goes down, users will be unable to access any web sites.  As this is the case it is important that you make the ProxySG IP address the primary DNS server and an external DNS server as the secondary or backup.
2. When configuring the Categories it is important that the list on the Web Access layer matches that of the DNS access layer or you will run into the following:
     a. If the rule is only configured on the Web Access layer it will not be triggered, the DNS query has no knowledge of the Deny action so the site will be accessible.
     b. If the rule is only configured on the DNS Access layer it will be triggered but not enforced.  While the DNS query will redirect the request to the ProxySG, the web layer is allowing the connection.  The site will be then delivered via the ProxySG back to the client over the VPN tunnel or secure connection.