When it comes to web filters or SWGs (secure web gateways), different vendors have widely different opinions on which method should be used to deploy them. Historically, vendors struggled to implement authentication in transparent mode, and maybe they remember some awkward conversations with customers that chose the wrong method.
The sad fact is that even technical architects at the same vendor can have a different opinion. So, how are you supposed to choose?
You could ask your reseller?
We asked 6 different resellers of 3 different SWGs the question:
"What equipment and deployment method would you recommend to deploy SWG X for 1000, 5000 or 10000 users on one site?"
The answers were shocking:
- Firstly, all of the resellers recommended only one hardware web filter - no high availability!
- Secondly, half of them didn't have a clue how to deploy it
- Two of them suggested explicit mode (but didn't know why)
- One suggested inline (but didn't even know what transparent meant).
OK, So I'm being a bit harsh here, a reseller is mainly interested in the software licence side of the sale and you would want to be talking to a decent technical architect or consultant for this kind of advice.
Hopefully if you went direct to the vendor they would point you in the right direction of a decent system integrator who knew what they were talking about.
So my first recommendations when it comes to choosing between Transparent & Explicit deployments are:
- Talk directly to the Vendor or a system integrator who is very experienced with your chosen vendors product.
- Check carefully that authentication and SSL decryption are supported in transparent mode.
- But which ever method you choose - please, please make it a highly-available i.e. Don't just buy one!
So what exactly is the difference between an Explicit web proxy & a Transparent web proxy?
With an explicit deployment, you explicitly tell the client computers which proxy server to use.
i.e. you change the web browser client and configure a proxy server.
Explicit High-Availability Web Filter Proxy - Network Diagram
- The clients are configured to talk directly to the web filter cluster
- Although this diagram looks a bit like a bridge - Its not Bridges suck!
- You can use Active Directory Policy, PAC or WPAD script to make client deployment easier
Transparent High-Availability Web Filter Proxy - Network Diagram
- PBR (Policy Based Routing) is used to send all web traffic to the web filter cluster
- You could also use WCCP, or configure the cluster as a default gateway - But please don't!
- Clients don't need re-configuring, multi-platform support including internet devices like printers is simple
- Web filters can see all source and destination information transparently
- Authentication can be slightly trickier
- SSL Decryption still needs client certificates
Hang on a minute! I've read those two descriptions twice - aren't both methods almost identical?
Pretty much, yes.. BUT:
We have skipped past a MAJOR PROBLEM with load balancing web filters in explicit mode.
Ideally in explicit mode you would wish to be able to see the clients source IP address at the web filter (just like you would if you only had one web filter).
In order to do that via a load balancer you would have to change the network layout (which can be a nightmare in a live environment), because you would either need:
Network diagram: Layer 4 two arm NAT configuration for a high-availability explicit web filters:
Why is adding another subnet behind the load balancer a potential problem?
- Have a think about how the web filters handle authentication...
- Will it even work if they are on a subnet behind the load balancer?
- Have a think about how the web filters route to your clients PCs...If you know they are in a specific subnet then you could add a static route?
- Have a think about how the web filters access the Internet? You will need to configure the load balancer to masquerade traffic for them...
- Have a think about performance...Do you really want each web filter having the load balancer as a default gateway?
Now these problems are easy to solve, with a bit of planning you can make the transition fairly easily with a little bit of down time...But I can't help thinking...surely we could design a better solution?
Wouldn't it be nice if you could have an explicit mode web filter cluster with the load balancer in a simple non-disruptive one-arm mode?
Well, it just so happens that as long as your chosen vendor supports a simple one line firewall change, then you can have your cake and eat it too.
It's called Layer 4 Direct Routing, Direct Server Return, or N-Path depending on which load balancer you are using.
Direct Routing is always the best solution for clustering web filters:
It's vendor neutral, it's transparent, it's awesome, and we have been banging on about it for 15 years!
And if your chosen vendor doesn't support it - then maybe ask them to have a chat with us, about how it can make life easier for them, and more importantly - you?
Last minute suggestion:You can implement both explicit and transparent at the same time, which can give you even more flexibility.
Web Filter Vendors who Support Direct Routing:
Full web interface support:
Full manual configuration support:
- Trend Micro - Load Balancing - Authentication - Deployment
- Clearswift - Load Balancing - Deployment & Authentication
- McAfee - Load Balancing - Deployment & Authentication
Requires console access to be requested from the vendor:
- Sophos - Load Balancing - Deployment - Authentication
- Barracuda - Load Balancing - Deployment - Authentication
Did anyone notice that I have not mentioned bridge mode?
A lot of vendors seem to like bridge mode - they say just put one big web filter between your firewall and the network, nice and easy!
But I can't help thinking what do you do when your bridge fails? Do you really want to bypass the web filter?
I just don't see how you can guarantee high-availability when you are using a bridge?
Please let me know if you disagree, it's quick and easy to leave a comment.