Different vendors have widely different opinions on which method should be used to deploy web filters or SWGs (secure web gateways). Historically, vendors struggled to implement authentication in Transparent mode, and maybe they remember some awkward conversations with customers that chose the wrong method.
The tricky thing 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. You'd really need to talk 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 direction of a decent system integrator who knew what they were talking about.
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 vendor's product.
- Check carefully that authentication and SSL decryption are supported in Transparent mode.
- Whichever method you choose, prioritise making the web gateway highly available. Don't just buy a single appliance!
What's the difference between an Explicit web proxy and a Transparent web proxy?
With an Explicit proxy deployment, you explicitly tell the client computers which proxy server to use. In other words, 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, it's not. Bridges suck!
- You can use Active Directory Policy, PAC or WPAD script to make client deployment easier.
However, with a Transparent proxy deployment — you transparently route the client traffic via the proxy. In other words, you don't need to change the web browser client and configure a proxy server.
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 for 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 want to see the client's source IP address at the web filter (just as you would if you only had one web filter).
To do that via a load balancer you'd have to change the network layout (which can be a nightmare in a live environment), because you would either need:
- Layer 7 in a two arm TPROXY configuration.
- Or preferably, layer 4 in a two arm NAT configuration.
Network diagram: Layer 4 two arm NAT configuration for high-availability Explicit web filters:
Why is adding another subnet behind the load balancer a potential problem?
- Think about how the web filters handle authentication. Will it even work if they are on a subnet behind the load balancer?
- Think about how the web filters route to your clients' PCs. If you know they are in a specific subnet, could you add a static route?
- Think about how the web filters access the internet. You will need to configure the load balancer to masquerade traffic for them.
- Think about performance. Do you really want each web filter to have the load balancer as a default gateway?
It's not that these problems aren't easy to solve. With a bit of planning and a little downtime you can make the transition fairly easily. 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!
If your chosen vendor doesn't support it, ask us to have a chat with them. We'll point out how it could 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:
- Smoothwall
- CensorNet USS Gateway
- Bloxx
Full manual configuration support:
- Trend Micro
- Clearswift
- McAfee
- WebTitan
- NetSweeper
Requires console access to be requested from the vendor:
- Sophos
- Barracuda
No support:
- Forcepoint
- Symantec Bluecoat
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?
Niagra Networks do have a pretty cool solution to the bridge failure problem though which I've talked about recently.
Please let me know if you disagree, it's quick and easy to leave a comment.