BYOD, or Bring Your Own Device, is the method in which Mobile Devices are filtered and monitored through your network, and how we can achieve the best way to set up Sonar as a proxy on your network. There are a number of different ways that Sonar can be deployed as a Proxy, and this document will outline those particular ways in which you can set that up for your network.

The ways in which Sonar can be set up as a proxy include:

  1. Transparent HTTP Proxy
  2. A Manual Proxy
  3. Proxy PAC file
  4. Auto Proxy (WPAD)

A list of devices and their compatibility with the above proxy configurations  are listed below in the table:

PC (Windows)
Mac OS X
Transparent HTTP Proxy

Manual Proxy

Proxy PAC file setup

 (10.6 and above)
Auto Proxy (WPAD) - No script set - Full automatic detection.
(iOS 6.1 and above)

(10.7 and above)

The next few sections will explain how each individual proxy configuration works, and how to configure it on your network. Advantages and disadvantages will also be explained.



The first question you’re probably asking is: “What is a Transparent Proxy?”

Firstly, there are two ways in which Sonar can operate as a proxy. Transparent, and Non-Transparent.

  • Non Transparent proxies mean that the IP address of Sonar must be specified in the web browser’s proxy settings in order for devices to access the internet.
  • A Transparent works differently. Transparent proxies capture any HTTP request automatically and redirect it to Sonar’s proxy (on port 8080), which means there is no need for any web browser configurations. The user would not even be aware that their request is being redirected. By default, all HTTP traffic is routed through port 80. However, for Transparent Proxies, you will need to create a rule in Sonar to redirect all traffic from port 80 to Sonar’s proxy port of 8080.


Transparent proxies are great “backup” proxies. It is always good to have one set up just in case your WPAD or PAC file fails for whatever reason (i.e. the server it is hosted on isn’t working). A Transparent Proxy will always ensure that you have access to the internet at a proxy level, and all traffic through it is logged, tracked and monitored.



So far, a Transparent proxy sounds pretty good. However, while a Transparent Proxy can be very beneficial and easy to manage, there can also be some major disadvantages in using them as well, those of which are outlined below:


  • No proxy set-up in the browser required. A user can simply jump on to your network with any device and start browsing the internet.
  • All HTTP traffic is filtered and tracked.
  • Compatible with all devices.


  • Transparent Proxies are NOT compatible with HTTPS. Yes, this means any attempt to connect to a HTTPS website WILL NOT work. The reason for this is because the TCP stream requires SSL Encryption between the client and the server, and any interception of that traffic by Sonar will invalidate and break the communication. Any decryption of SSL is in a violation of the web standard, meaning Sonar does not support any SSL Decryption or Man-in-the-Middle attacks.



The process in setting up a Transparent Proxy is quite simply and pretty straight forward. The process consists of three main steps:

  1. Create an object rule to redirect 80/TCP traffic to Sonar’s local proxy on port 8080/TCP by default.
  2. Adding this rule to the SYSTEM group, or any other Group.
  3. Confirming that the Transparent proxy has been successfully set up.


Step 1 - Creating the Redirect Rule

Creating the redirect rule is a simple process, and this guide will walk you through step-by-step on how to create that rule.

  1. In the Sonar GUI, select Network → Objects → Rule Objects and click Add Rule. The Add Rule Object window will be displayed.
  2. Select the NAT rule type option.
  3. In the Rule Label field, enter a descriptive name for that rule, something like “Transparent Proxy”.
  4. Ensure that the Protocol field is TCP.
  5. From the Target field, ensure that DNAT is selected from the Drop-Down menu.
  6. Click the ellipsis button [...] next to the Target field. This will open the Maintain Target Window.
  7. Make sure that in the Available Choice field, “to-destination” is selected.
  8. In the Enter a Value field, enter Sonar’s IP address and its proxy port using the following syntax: <Sonar’s IP Address>:8080 and then click “Add” and “OK”.
  9. From the Match 1 drop down list ensure “Multiport” is selected.
  10. Click the ellipsis button [...] next to Match 1.
  11. Again, from the Available Choice field, make sure “dst-ports” is selected.
  12. Enter 80 in the Enter a Value field and then click “Add” and “OK”.
  13. Click “Apply” and close the Edit Rule Window. 


Step 2 - Adding the Rule to System Group

In this example, we will be creating the Transparent Proxy policy in the System Group. This means ALL internal users without proxy settings set will be forced through the Transparent Proxy. But you can create this rule JUST for specific groups as well.

  1. In the Sonar GUI, select Groups → System → Rules → NAT and click Add. This will bring up a Window to create a new rule.  
  2. In the Sources section, click the + button to add the Network Object representing your internal LAN network. You can also choose a Range of IPs within your LAN network, or even an individual host IP.
  3. In the Destinations section, click + to add the Network Object representing Sonar’s internal Ethernet Interface to which TCP traffic will be redirected. Typically this is Sonar’s eth1 interface. If there is more than one network in your environment, for example, separate networks for Admin and Curriculum, you will need to select four network objects representing the Public IP address ranges instead (See below for more detail).  
  4. Right click the destination object (if eth1) and select negate. This is to prevent any authentication loops. By negating this object, you are essentially saying any port 80 traffic that is headed anywhere BUT Sonar must be redirected to port 8080.
  5. In the Rules section, click the + button to add the Transparent Proxy rule you created in Step 1.
  6. Click Apply and Close.


Step 3 - Checking the Transparent Proxy

To confirm that a Transparent Proxy has been successfully set up, check that users can access the internet without any browser settings configured in the proxy. If they can, Transparent Proxy has successfully been configured.



In addition to Transparent proxies, a Manual Proxy is another way that proxies can be deployed to users in your network. What is a manual proxy?

A Manual Proxy is simply a proxy that requires you to manually input the configuration settings of the proxy in your web browser.



Manual proxies are generally only good for testing purposes, when you have one or two computers that you need to get out on the internet with. It’s generally easier to input the proxy settings in the browser than having to go through the process of setting up a Transparent proxy, or configuring a WPAD or Proxy Pac for only a couple of machines.



Like Transparent Proxies, Manual Proxies also contain various advantages and disadvantages, however, you might find that Manual Proxies have more cons than pros and are generally not recommended to be used under a large network environment:


  • Easy to set up by simply inputting the proxy settings into one’s browser.
  • Good for testing different proxies.


  • No automated process with the proxy settings. Every user has to manually insert proxy details into their browser if they want to get out to the internet (unless you have Group Policy in place).
  • Exceptions for proxies also have to be entered in manually, and are generally not in an easy-to-find place in the browser.
  • Not great for users who are technologically challenged.



Open up Internet Explorer and navigate to the Browser's configuration or options. It should be a label called “Internet Options”. A window should appear.  

  1. Navigate to the tab Connections, then LAN Settings.
  2. Check the checkbox Use a proxy server for your LAN (these settings will not apply to dial up or your VPN connections).
  3. In the Address field, type in Sonar’s IP or hostname.
  4. In the Port field, type in 8080.
  5. Make sure Bypass proxy for local addresses is ticked as well.
  6. Exceptions can be found or entered by clicking the Advanced button.



Now that we’ve covered how Transparent proxies work with Sonar, it’s time to move on to Proxy Pac files. Like with Transparent proxies, the question to ask is “What is a Proxy Pac file?”.

A Proxy Pac file is just that, a simple file named proxy.pac and hosted on a web server somewhere on your network where it is easily accessible for users via a URL. Typically, a proxy pac file will look something like this:

function FindProxyForURL(url, host) {
       // Dont request proxy when accessing localhost.
       if (isInNet(host, "", ""))
               return "DIRECT";
       // Local URLs from the domains below don't need a proxy:
       if (shExpMatch(host, "*"))
               return "DIRECT";
       // All other requests go through port 8080 of
       // should that fail to respond, go directly to the WWW:
       return "PROXY; DIRECT";

This is where you perform all your proxy configurations about what you want to go through the proxy, and what you want to go direct.



Proxy Pac files should be standard. It is the best proxy format that works with Sonar on the right level. Instead of manually specifying a proxy IP or Host in every machine, you can simply point them towards a URL which hosts the proxy pac file, and all the configurations and exceptions can be done from the one file.



Proxy Pac files are highly recommended in terms of being one of the easiest ways to manage a proxy for your network. However, like Transparent Proxies, they come with positives and some negatives.


  • Easy to create, easy to manage. All configurations are done in one single file.
  • All HTTP and HTTPS traffic are filtered.
  • Unlike Transparent Proxies, HTTPS traffic works with a Proxy Pac file.
  • Works well with iOS devices such as iPhones and iPads.


  • Browsers still need to know where to look for a proxy pac file, which means, you would have to point your browser settings to the URL where your proxy pac file is hosted.



The process in setting up a Proxy Pac file is quite simple and easy to understand. As mentioned earlier, all configurations are done in a single file. If you are on Sonar 3.5, handling the pac file is even easier. If you navigate to System → System Files and from the drop-down menu, select Proxy Auto Configuration then click “Load”. This will bring up the default Proxy Pac file in Sonar 3.5. Here, you can edit and change the proxy pac file on Sonar.

Editing the Proxy Pac File

The configuration and layout of the pac file may seem confusing to begin with, but pac files are really easy to understand! The only configuration you’re going to be doing is when you want to send a domain direct instead of through the proxy.

// Local URLs from the domains below don't need a proxy:
       if (shExpMatch(host, "*"))
               return "DIRECT";

This section here is the part you edit if you want to send things direct through the proxy. What the line is saying is essentially “if the URL requested matches ‘*’, send it directly instead of through the proxy”. Then, the URL they’re attempted to go to will be controlled at a firewall level rather than at a proxy filtering level. If you send things direct through the proxy pac file, you will have to allow a firewall rule out for that domain/host IP in order for users to access it. If you need to add more than one domain, you can simply another domain into that line, separated by a comma. For example:

// Local URLs from the domains below don't need a proxy:
       if (shExpMatch(host, "*, *, *"))
               return "DIRECT";

You’ll then see the following line after:

return "PROXY; DIRECT";

This line here states in laymen’s terms “Anything else NOT specified in the above code, send it through” Which, of course, is Sonar’s Proxy on port 8080.  

Step 1 - Pointing your Browser to the PAC file

Once all configurations have been done in the PAC file, you are ready to point your browser to the proxy pac file in the browser settings.

  1. Open up the settings in whichever browser you’re using (Chrome, IE, Firefox, etc)
  2. Under the proxy settings, set it to “Automatic Proxy Configuration URL”. This will open up a field for you to enter a URL.
  3. Under this field, specify the URL where your proxy pac is hosted, for example:
  4. Test that the internet works by attempting to browse.

If you have Group Policy set up on your network, you can simply push out the browser settings to all the computers on your Domain, that way, you don’t have to manually set the URL for each computer.



If you’re currently running Sonar 3.2, there is no auto proxy configuration file in Sonar’s System Files, that’s a new feature in 3.5. With Sonar 3.2, the proxy pac must be hosted on a web server.


  1. A compatible web server
  2. A locally accessed DNS server

Step 1 - Hosting the PAC file on your Web Server

To host the pac file on your web server, you should only need to place the file in the root directory of the server. That way, when you attempt to access it, the URL should match something like “”. Or, if your server does not have a host name, it would be something like “”.

Step 2 - Creating a DNS hostname for the PAC file

To make things more user-friendly and easier to understand for your less-than technical users, you can create a hostname for your Proxy Pac file and inform users of this URL that they can then input into their mobile devices in order to access the internet.

  1. Create a CNAME or DNAME entry for the webserver, and enter in a meaningful hostname, something like, or

Step 3 - Pointing your Browser to the PAC file

Once all configurations have been done in the PAC file, you are ready to point your browser to the proxy pac file in the browser settings. Refer to Step 1 on the previous page to find out how to set your browser to point to your Proxy Pac file.



Now that we’ve discussed both Transparent Proxies and Proxy Pac files, let’s move on to WPAD. What is WPAD? 

WPAD stands for Web Proxy Auto-Discovery Protocol. Basically, a WPAD file is simply a Proxy Pac file, just renamed to wpad.dat. Everything about it is the same as a pac file, the only difference is that browser do not have to point to the pac file in order for the proxy to be used. WPAD is a technology which aids a web browser in automatically detecting the location of a PAC file using DNS or DHCP. A browser that supports both DHCP and DNS will first attempt to locate the WPAD file using DHCP, and should DHCP fail, it will fall back to DNS. If neither exist, the browser will fail.



The better question is, why not? WPAD is most likely the best way to push out a proxy to users, especially if you have a lot of mobile devices. With WPAD and the right configurations, the browser will need no proxy settings set and will auto-detect WPAD to deploy a proxy to all users.



Like with Proxy Pac and Transparent proxies, WPAD have its own pros and cons when deciding what proxy to use in your network.


  • Easy to manage, easy to configure.
  • HTTP and HTTPS traffic is logged and tracked.
  • Great for mobile devices such as iPads and smart phones.
  • Requires no browser configuration.


  • There aren’t many cons when it comes to WPAD. The only disadvantage could be that it may be hard to understand and set up for those that aren’t so technical.



As mentioned earlier, a WPAD file is identical to a proxy pac file. It is just called wpad.dat instead of proxy.pac. All forms of configuration are essentially the same as well. Please refer to “Editing the Proxy Pac File” on page 6 for instructions on how to configure the file.

Configuring the Web Server

Unlike Proxy Pac, WPAD needs a bit more configuration to set up in order to get things working the way they should. Depending on your Web Server, there are different ways that you will have to configure the server:

IIS Web Server (Windows)

  1. Login to the server through Terminal Services or Remote Desktop Connection.
  2. Click Start, select Programs, and then click Administrative Tools.
    1. For IIS 5.0: Open Internet Services Manager.
    2. For IIS 6.0: Open Internet Information Services.
  3. In the left column you will see the Server Name.
    1. In IIS 5.0: expand the Server Name to find the domain name.
    2. In IIS 6.0: expand the Server Name and then Web Sites to find the domain name.
  4. Right-click on the domain name and select Properties.
  5. On the HTTP Headers tab click MIME Types.
  6. Click New.
  7. Enter the below information:
  8. Extension: .dat
  9. MIME Type: application/x-ns-proxy-autoconfig
  10. Click OK. 

Other Linux-based Servers (Apache)

  1. Create .htaccess file.
  2. Add the below line into the file: AddType application/x-ns-proxy-autoconfig .dat
  3. Upload the file to the same location as the wpad.dat file.

Configuring the DNS Server

The DNS server needs to be configured to server (A) record for the host wpad. So that when browsers auto-lookup for the hostname wpad, they will be directed to where it is hosted on the Web Server.  

Removing WPAD from the DNS Block List

The DNS Server role in Windows Server 2008 introduces a global query block list to reduce vulnerability associated with DNS Dynamic Update Protocol.

If you want to use WPAD with DNS, please note the following:

  • If WPAD entries are configured in DNS before the DNS server is upgraded in Windows Server 2008, no action is required.
  • If you configure or remove WPAD after you deploy the DNS server role on a server running Windows Server 2008, you must update the block list on all DNS servers that host the zones affected by the change. The affected zones are those where you registered the WPAD servers. 

Updating the Block List

Use the dnscmd command prompt/line tool to manage the global query block list. Open Command Prompt, and then do the following:

  1. To check whether or not the global query block is enabled, type the following:

dnscmd /info /enableglobalqueryblocklist

  1. To display the host names in the current block list, type the following:

dnscmd /info /globalqueryblocklist 

  1. To disable the block list and ensure that the DNS server does not ignore queries for names in the block list, type the following:

dnscmd /config /enableglobalqueryblocklist 0

  1. To enable the block list and ensure that the DNS Server service ignores queries for names in the block list, type the following:

dnscmd /config /enableglobalqueryblocklist 1

  1. To remove all names from the block list, type the following:

dnscmd /config /globalqueryblocklist

  1. To replace the current block list with a list of the names that you specify, type the following:

 dnscmd /config /globalqueryblocklist name [name]…

For more information, you can refer to this link:

Adding a DNS Alias for WPAD in Windows 2008 Server

As well as removing the DNS entry from the block list in Windows 2008 Server, you will also have to configure an Alias for the WPAD entry:

  1. Click Start, point to All Programs, point to Administrative Tools, and then click DNS.
  2. In the console tree, right-click the forward lookup zone for your domain, and click New Alias (CNAME).
  3. In Alias name, type WPAD.
  4. In Fully Qualified Name for the Target Host, type the FQDN of the WPAD server (e.g. intranet.myschool.local).

For more information, you can refer to the following link: 



Now that we’ve configured and set up WPAD to work within your network, it’s time to test if it works.

  1. In your browser settings, make sure “Auto-Detect Proxy Settings” is enabled, and close the settings.
  2. Attempt to browse. If all is working well, the browser should do an auto-lookup for the hostname “wpad”, and grab the wpad file from the web server you’re hosting it on. There may be a delay in retrieving the web page due to the browser searching for the wpad file.

You can also make sure that wpad is being hosted properly by doing an nslookup for wpad in command prompt on Windows. If the result returns the IP of the server it’s hosted on, wpad should be working successfully.



Now that we’ve covered three different ways of deploying a proxy in your network, this should hopefully assist you in determining the best solution for you in how you should roll out Sonar as a proxy, and the best way in which this can work for you.

If you have any questions, queries or require any additional help, you can contact Blue Reef Support for more information.

To sum up what we’ve discussed:

Transparent Proxies:

  1. Great back-up proxies, for when your standard proxy becomes unavailable for whatever reason.
  2. Doesn’t require any proxy settings to be set or configured.
  3. Easily set up in Sonar.
  4. Essentially it is an “invisible proxy”. The only downside is that it does not work with HTTPS.

Proxy PAC files:

  1. An easy-to-manage proxy file that you can configure for all users in one single file.
  2. Works with both HTTP and HTTPS, and everything is logged and tracked with Sonar.
  3. Works well with iOS devices such as iPads and iPhones.
  4. The only disadvantage is users have to place in the URL in order to point the browser to the proxy, which needs to be hosted on a web server.


  1. More commonly the best solution to implement. The only disadvantage is that it may be difficult to set up for those not-so-technical.
  2. Requires no browser configuration, as browsers auto-lookup for wpad.
  3. Identical to a Proxy Pac file, just renamed, so it’s as easy to configure and edit as a Proxy Pac file.
  4. Works with both HTTP and HTTPS, and is compatible with iOS devices 6.1 and higher.