Web Proxy / Filter Deployment Guide
Web Proxy / Filter Deployment Guide
Deployment Guide
1
Table of Contents
2
About this Guide
This guide is intended to provide details on using loadbalancer.org appliances with Web Proxies / Filters. For
an introduction to setting up the appliance as well as more detailed technical information, please refer to our
quick-start guide and full administration manual available at:
http://loadbalancer.org/pdf/quickstartguideLBVM.pdf
http://loadbalancer.org/pdffiles/loadbalanceradministration.pdf
• URL Filtering
• Content Caching
• User Authentication
• High Availability
Layer 4
3
Network Address Translation (NAT Mode)
This modes requires the implementation of a two-arm infrastructure with an internal and external subnet to
carry out the translation (the same way a firewall works). The real servers (i.e. the web proxies) must have
their default gateway configured to point at the load balancer. It offers fairly high performance and like DR
mode is transparent by default.
Layer 7
Persistence
Persistence may or may not be required and depends on the specific web proxy being used.
Source IP Address
Source IP persistence is the standard method and is appropriate for most requirements. When set, clients
connecting from the same source IP address within the persistence timeout period (the default is 5 mins) will
always be sent to the same web proxy.
Destination Hash
Another option is to change the load balancing algorithm (i.e. the “scheduler”) to destination hash (DH). This
causes the load balancer to select the proxy based on a hash of the destination IP address. This causes
session requests to be directed at the same server based solely on the destination IP address of a packet
which therefore makes client connections persistent for a particular Internet host.
Since this setting is a scheduler, the way connections are load balanced will also change. However it should
still provide a well balanced distribution of client sessions between web proxy servers.
4
Web Proxy Deployment Modes
There are two implementation methods that are typically used – proxy mode & transparent (routed) proxy
mode.
Proxy Mode
This mode requires a web proxy address to be defined in users browsers. This allows specific traffic
(typically HTTP & HTTPS) to be handled by the proxy on behalf of the client PC.
In transparent mode, web proxies are unable to filter HTTPS traffic. This is because SSL cannot be
proxied transparently. SSL authenticates both sides of the connection and if a proxy is in the middle,
then both sides try to authenticate to the proxy which is incorrect and therefore the connection fails. NTLM
authentication also fails for similar reasons. For HTTPS & NTLM, either the proxy server must be explicitly
configured or traffic should pass directly from the client to the server.
5
Loadbalancer.org Web User Interface
Username: loadbalancer
Password: loadbalancer
Once you have entered the logon credentials the Loadbalancer.org Web User Interface will be displayed.
6
Setting Up Proxy Mode
Deployment Architecture
Client
PC
Client Default
Firewall Internet
PC Gateway
Load balancer 1
Load balancer 2
Web Proxy 1
Web Proxy 2
Notes
• Browser settings on client PC's must be changed to point at the Virtual Service (VIP) on the load
balancer
• The Web Proxies must be configured to accept traffic for the VIP
• Typically, two loadbalancer.org appliances are deployed for resilience – this is our recommended
configuration
7
Web Proxy Appliance Configuration
i.e. Redirect any incoming packets destined for the VIP to the local address
Many vendors such as Bloxx, Clearswift and Smoothwall have options in their Web Interface that
allow this to be easily configured, so command line entries are not required. Please consult your
specific vendor or loadbalancer.org for more information.
8
Load Balancer Configuration
• Set the Scheduler setting according to your needs (recommended: 'wlc' – weighted least connection)
9
Client Configuration
Client browser settings must be set so that browsers connect via the VIP. This is typically achieved using AD
group policy.
10
Setting Up Transparent Proxy Mode
Deployment Architecture
Client
PC
Load balancer 1
Load balancer 2
Web Proxy 1
Web Proxy 2
Notes
• Rules must be added to the router / default gateway so that http traffic is sent to the load balancer /
web proxise listening port
• The Web Proxies must be configured to accept traffic for the VIP
• Typically, two loadbalancer.org appliances are deployed for resilience – this is our recommended
configuration
11
Web Proxy Appliance Configuration
12
Load Balancer Configuration
• Set the Scheduler setting according to your needs (recommended: 'wlc' – weighted least connection)
13
Configure the load balancer to accept all http & https traffic on ports 80 & 443
To do this, add the following rules under Maintenance > Firewall Script
Now modify the VIP settings to relate to the particular Firewall Mark used (in this case '1')
i.e. change:
to:
14
Router / Default Gateway Configuration
Depending on your network configurtation, rules must be added to the router or default gateway so that all
http traffic is sent to the VIP on the load balancer. The load balancer then load balances this traffic between
the web proxy servers.
CLIENT="192.168.2.0/24"
FWMARK="10"
TABLE="10"
PROXY="192.168.2.204"
iptables -t mangle -A PREROUTING -s $CLIENT -p tcp -m tcp --dport 80 -j MARK --set-mark $FWMARK
ip route flush table $TABLE
ip route add default via $PROXY dev eth3 table $TABLE
ip rule add fwmark $FWMARK table $TABLE
ip route flush cache
ip route show table $TABLE
route add default gw 192.168.2.1
This example uses policy routing via firewall marks. This works by first selecting and marking the packets we
want to be sent to the proxy, i.e .all packets on port 80. Then, when the kernel goes to make a routing
decision, the marked packets aren't routed using the normal routing table, intstead via table 10 in this case.
Table 10 has only one entry: route packets to the web proxy.
Client Configuration
No changes are required to the client for transparent mode and no proxy settings should be be defined. As
long as the default gateway is set correctly, or a suitable static route is configured and rules have been setup
on the gateway, this should be all that's needed.
Testing
To verify that the traffic is passing through the load balancer correctly the following reporting options can be
used:
Several reporting and dashboard options are also available on the web proxies, for this please refer to your
specific vendors documentation.
15
Conclusion
Loadbalancer.org appliances provide a very cost effective solution for highly available load balanced Web
Proxy/Filter environments.
16