Browse All Articles
> Using Policy Based Routing (PBR) with SonicWALL firewall and Websense Gateway.
To setup a SonicWALL for policy based routing to be used with the Websense Content Gateway there are several steps that need to be completed. Below is a rough guide for accomplishing this. One thing of note is this guide is intended to assist in the setup but is not supported by Websense or its employees. It is encouraged to contact the vendor should you run into any issues in the setup on non-Websense products. This guide was written using the latest firmware to date for 5th Gen SonicWALL firewalls v188.8.131.52-36o.
1) To get started you need to create and address object for your network ranges. We are going to use ranges since you need to exclude Websense components from the redirection to the proxy. On the SonicWALL interface navigate to Network > Address Objects. Scroll to the “Address Objects” section and click on add. Create one for each range of your network making sure you leave out your Websense Components. In this below example
2) Next we need to group the address objects we created together for later use. Scroll back to the top of the Address Objects Menu and under “Address Groups” choose Add. Name the group anything you want, for this guide we will use WS Redirect, and select all of the address objects you created earlier and move them to the right.
3) With the redirection group setup we need to create another “Address Object” for the proxy address. This is the address we will send traffic too. This is either the eth0 address of your software based Websense Content Gateway or the P1 interface of your Websense Appliance. For this example our Gateway Address is 192.168.1.250
4) With the address groups configured now we setup the policy based route. For this navigate to Network > Routing. Under “Route Policies” choose add to create a new route. For the data follow the information below:
• Source: The group we created before, in this case WS Redirect.
• Destination: Any (This is because we do not know the destination of the websites so it can be any address).
• Service: HTTP (can be FTP or HTTPS as well).
• Gateway: The address object with the Websense Proxy address (in the example we called it Websense Proxy IP).
• Interface: This is the interface the Websense Proxy resides. Our LAN is on X0 in this example.
• Metric: This is the number of hops to the Gateway; in our case it was 1 hop away.
• Comment: Any description you want to give this route.
All other options can remain their defaults. Click OK and ensure the route was added to the table.
5) This guide was for HTTP, if you want to route HTTPS and FTP to the proxy as well you need to follow step #4 again and change the service to the desired one for each. With the route in place if you run a packet capture you should see the traffic being redirected or “Forwarded “ to the Websense Proxy address. Below you can see an excerpt of a packet capture using the policy-based route. The client in this test was 192.168.1.140 and the proxy MAC address ends with 6a:30. In the capture you will see line #7 shows a packet ingress from 192.168.1.140 then packet # 9 the same packet is “Forwarded” out of the same interface with the IP of the internet site but sent to the Proxy’s Layer 2 address ending in 6a:30. This confirms that the policy-based route is working successfully. This was confirmed as well with a capture on the proxy (not included in this guide)
This Article uses WebSense only as an example – the procedure described is appliable for all kind of web proxy redirection. WebSense provides more than just that, e.g. classification of traffic for risk evaluation; using WebSense just as proxy service might not reveal the full scope of available features.