Scheduled maintenance on Saturday, August 8th from 7am to 10am (UTC). Licensing registrations and key activations will be unavailable during this period. More info here.
The Sophos Web Appliance (SWA) has no ability to direct or redirect traffic, it is simply a web proxy. The deployment mode dictates how the SWA will receive proxy traffic from the workstations.
There are 4 basic deployment modes, each has pros and cons. Deployment modes are:
This document will elaborate on each mode and provide additional information that should help you get the most out of your SWA.
The following sections are covered:
Applies to the following Sophos products and versions Sophos Web Appliance
Regardless of the deployment mode the SWA will always accept connections on port 8080.
There are 3 basic ways to configure explicit mode:
Using the virtual IP (VIP) on the Sophos Management Appliance is a simple option to load balance connections across managed devices. This configuration is only available on the Sophos Management Appliance under: Configuration / Network / Load balancing.
Enable and specify an unused real IP address, then use this address instead of the SWA IP address. All traffic sent to the VIP will in-turn be balanced by the specified SWAs in the pool.
The .pac files are script files that allow advanced proxy configuration:
Here are some reference links that will help you host and create your own .pac files:
NOTE: .wpad/.pac file is not something that can be supported as every company has their own infrastructure, however here are links to samples and everything you need to create a configuration script
Transparent redirection will physically route traffic from one network to another. WCCP offers load balancing and this deployment mode will allow you to create specific rules about what traffic is directed to the appliance.
In short create rules to intercept port 80/443 traffic from network X and send it to appliance in network Y.
NOTE: Ensure you exclude the SWA to ensure that it can make web requests out.
NOTE: The SWA is designed to work on Cisco devices, other devices that offer WCCP redirection should work but are not supported.
SPECIAL NOTE: When using WCCP with a router that supports the fast timers feature (Cisco firmware from later than 2012 or WCCP v2 rev1), you must disable the fast timers feature. To disable this on a Cisco router, use the command no ip wccp variable-timers.
A common misconception is that the appliance interferes or has any say when it comes to WCCP. The appliance is a secondary to the ASA with 1 exception (in advanced source hashing configurations)
The general premise is that you would create a WCCP pool on your Adaptive Security Appliance (ASA). This pool will include service groups or protocols. A normal single SWA setup should include the following protocols:
Using service group 0 and 70 on a single SWA will redirect all HTTPS and HTTP traffic to the SWA. In the WCCP configuration on the SWA ensure to select accept HTTPS redirects.
Any time there is more than one appliance in a WCCP redirection pool you should enable source hashing and deploy the WCCP pool with the appropriate protocols. (To enable source hashing you will need to enable remote assistance and open a support ticket)
The source hashing is a method that is used by ASA to determine the load balancing based on the source of the request. If you had 100 users the ASA would balance based off the 100 users. When not using source hashing the ASA will do destination hashing, meaning it will balance base off the sites users go to. If everyone goes to google then everyone would go through one appliance.
In this case you will use Service group 70 as above, but you will use service group 90 instead of Web cache/service 0.
Destination Hashing: (default)
The destination hashing means that the ASA will direct the workstation request to whatever appliance handled the last request for that site. IE: ALL requests for google, go to appliance #13
Source Hashing: (Advanced)
This method should be used anytime you are directing traffic to more than one device.
Source hashing bases each request on the source of the IP of the workstation. IP's are divided into buckets each bucket is spread across the total IP range which is in turn distributed across the appliances. Note: a detailed explanation is NOT KB friendly.
In short: source hashing will ensure that user requests stay on the same appliance and allows the ASA to properly distribute traffic evenly across all of the appliances in the pool. This will eliminate authentication issues and increase performance globally.
Additional information : Cisco Deployment Guide
Bridge mode allows you to place the SWA just before your gateway to the internet (usually between a switch and the forward facing firewall). Bridged SWAs transparently inspect web traffic at layer 2 and ignore all other traffic.
The bridge card in the SWA will fail to open (if it fails your internet will not go down)
The common mistake with bridged SWAs is you run the risk of bridging across your forward facing firewall, thus causing the SWA to become an open proxy. Ensure you take caution when deploying in bridge mode.
FWC is a special deployment and must be configured correctly to work. There are some limitations and special considerations.
Considerations when putting clients into full web control:
When using a web SWA / management SWA the workstation clients will register with the SWA and upload logs to it.
Clients in full web control will communicate with the SEC console to download policy. Every request made by the workstation is in turn check against that policy. If the request is failed, it is flagged with an endpoint flag. If the SWA observes the tag it is assumed that all policy is done and allows the request without scanning.
Full web control does not offer the same level of policy enforcement as a web SWA. The client has no ability to see inside encrypted content nor can it apply complex policy like application control to the workstation. It is designed to provide a basic Yes/No policy based on a root domain or basic category.
Additional article for troubleshooting full web control
Terminal Server: Ensure your TS is set up to use virtual IP per client. Otherwise authentication will fail, as every request will look like its coming from the same IP address. Refer to Configure Remote Desktop IP Virtualization
Citrix: Ensure you have the following local site list entries and set them to trusted. Replace the example name with your FQDN. (NOTE: Port is required as the SWA only understand port 80 and 443, unless otherwise defined in the local site list.)
If you've spotted an error or would like to provide feedback on this article, please use the section below to rate and comment on the article. This is invaluable to us to ensure that we continually strive to give our customers the best information possible.
Every comment submitted here is read (by a human) but we do not reply to specific technical questions. For technical support post a question to the community. Or click here for new feature/product improvements. Alternatively for paid/licensed products open a support ticket.