@danb - Based on your configuration, only LAN to LAN internal traffic is being passed over the VPN tunnels. Are you wanting to filter HTTP requests coming over the VPN tunnel even if they are destined for the Main Site's LAN? Or is the Websense filter just for web traffic destined for the internet?
One thing you could try is changing the direction the webfilter is applied to your WAN interface. Currently, the filter is applied to eth 0/2 at the main site as the following: ip urlfilter Web_Http_Filter out I'm not sure traffic coming over the VPN is being caught by the filter with it applied in this direction.
You may want to try changing this to state: ip urlfilter Web_Http_Filter in .
Please do not hesitate to let us know if you have any further questions or issues.
Thank you for your response. To clarify, each site has their own internet connection and a default route out to the internet. The VPN tunnels are for privately addressed site to site traffic so I assumed that since the router needs to send the Websense filter request to 10.43.0.24 at the main site it would handle this request (and response) over the VPN tunnel. When approved it would allow the traffic out the local interface. Am I misunderstanding how the Websense works?
We don't want to bottleneck the main site with routing all internet traffic for all the remote site as well as its own users. So the idea here was to funnel just the Websense requests to the main site and allow the traffic to leave and come back in the local public interface.
How can this be accomplished?
If you have Websence setup inline (which it sounds like you do) then all web traffic will have to go over the VPN and through the protector for it to get filtered.
danb - I think what unified mentioned may be correct if it was a hardware solution. However, I don't believe in this case the Websense filter has to be "inline" of the web traffic, but I could be wrong.
I do think the reason the Websense requests are not making it over the VPN tunnel is because the request is being sourced from the WAN interface of the remote router (Eth 0/2). Because of this, the traffic does not match the VPN selectors and therefore is not encrypted. Unfortunately, there is no way for us to specify to the router which source interface to use when sending the request to the Websense server. However, we could try adding an entry to the VPN selectors at the main and remote site that matches the websense request.
The remote site would need the following VPN selectors added (in bold):
ip access-list extended VPN-10-vpn-selectors1
permit ip 10.10.10.0 0.0.0.255 10.43.0.0 0.0.0.255
permit ip 10.10.10.0 0.0.0.255 10.143.0.0 0.0.0.255
permit tcp host 173.x.x.133 host 10.43.0.24 eq 15868
permit tcp host 173.x.x.133 eq 15871 host 10.43.0.24
The main site would need the following VPN selectors added for the return traffic:
ip access-list extended VPN-10-vpn-selectors
permit ip 10.43.0.0 0.0.0.255 10.10.10.0 0.0.0.255
permit ip 10.143.0.0 0.0.0.255 10.10.10.0 0.0.0.255
permit tcp host 10.43.0.24 host 173.x.x.133 eq 15871
permit tcp host 10.43.0.24 eq 15868 host 173.x.x.133
I referenced TCP ports 15868 and 15871 because I believe these are the default ports used by Websense to send web filter requests and block pages. You should be able to run a packet capture on the websense server to verify which ports are being used and to modify the VPN selectors I listed above accordingly.
Please do not hesitate to let us know if you have any further questions.
This is from the Websense deployment guide:
To ensure effective filtering, Websense software must be installed so that:
- Filtering Service can receive HTTP requests from an integrated firewall, proxy
server, or caching application, or Network Agent.
In a multi-segmented network, Filtering Service must be installed in a location
where it can both receive and manage Internet requests from the integration
product and communicate with Network Agent.
- Network Agent:
- Must be deployed where it can see all internal Internet traffic for the machines
that it is assigned to monitor.
- Can be installed on a dedicated machine to increase overall throughput.
- Must have bidirectional visibility into Internet traffic to filter non-HTTP
requests (such as instant messaging, chat, streaming media, and other Internet
applications and protocols).
- Multiple instances of Network Agent may be required in larger or distributed
networks. Each Network Agent monitors a specific IP address range or
Using multiple Network Agents ensures that all network traffic is monitored,
and prevents server overload. The required number of Network Agents
depends on network size and Internet request volume.
Unified, This seems to validate the point that we don't need to have an "inline" filter.
Noor, I will give the additional selection criteria a try. I think that may be the issue.
I spoke to the Websense "Expert" here and he said you should check with Websense in terms of licensing.
He believes the Websense license requires you to have an Agent at each physical location.
unified, Thank you, that may be the final answer but the first step is that the remote Adtran doesn't see the server.
noor, I tried the additional VPN selectors and it doesn't look like it worked. I have not been able to get a packet capture to see what communication/ports look like but will attempt to troubleshoot this further soon.
If you install a Network Agent at each location the Network Agent will need to contact the main site and not the web traffic.