• No end user configuration is required (via wpad.dat or Group Policy etc);
• If something breaks, it’s extremely simple to remove;
• Most people wouldn’t even know it was in place;

There are some downsides to this approach however:

• HTTPS traffic cannot be silently routed through the proxy server;
• NTLM authentication cannot be used

The best place to start is by setting up a Linux server. This can be physical or virtual, running whichever distribution you prefer (I’d go with Ubuntu, but the choice is yours). If linux isn’t your bag, the following Ubuntu install documentation will help.

This guide will use the following example configuration information:

Install and configure Squid

Once your Linux system is up and running, you’ll want to install the latest (stable) version of Squid. If you went with Ubuntu this couldn’t be easier:

# aptitude install squid3

We can accept a very basic configuration. The only change you need to make is to set the default squid port to be “transparent”. Change the following in /etc/squid3/squid.conf

http_port 3128 transparent

Configure iptables on the proxy server

We also need to configure the Linux kernel firewall (iptables) to forward any traffic routed to it on port 80 to the port used by our proxy server. This can be done as follows:

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

Save our current iptables configuration using the iptables-save command:

# iptables-save > /etc/iptables.rules

We now need load the configuration whenever the network interface comes up, edit /etc/network/interfaces adding the following line to the relevant interface.

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.168.253
netmask 255.255.255.0
gateway 192.168.168.254
pre-up iptables-restore < /etc/iptables.rules

Finally, we’re onto the firewall configuration. This is going to vary depending on your device (Cisco PIX, Juniper Netscreen etc). My familiarity is with the ScreenOS product line so that’s what I’ll cover here.

Policy based routing (PBR) allows us to setup some pre-defined rules which determine how traffic is routed. In our scenario we want to route any outbound traffic from our corporate LAN destined for port 80 via a server on our network (or in a DMZ). The below instructions are for Juniper Netscreen firewalls running ScreenOS.

Policy Based Routing (PBR) requires ScreenOS 5.4 or later

Extended ACLs

An extended ACL is the criteria for matching certain traffic; each ACL can contain multiple matching rules. You may wish to match all traffic on port 80 destined for a few subnets, in which case you’d create an Extended ACL with multiple entries.

Create an ACL matching traffic from the corporate network for outbound HTTP traffic:

set access-list extended 10 src-ip 192.168.168.0/24 dst-port 80-80 protocol tcp entry 10

We also need to create an ACL so that our proxy server trafffic doesn’t get routed back to itself:

set access-list extended 20 src-ip 192.168.168.253/32 dst-port 80-80 protocol tcp entry 20

Match Groups

A match groups is a collection of one or more Extended ACL‘s, with a human-readable name. Create a match group named “Proxy” with an ID of 10 containing our extended ACL.

set match-group name Proxy
set match-group Proxy ext-acl 10 match-entry 10

We need to create another match group so that we can exclude systems from being routed through the proxy

set match-group name DirectHTTP
set match-group DirectHTTP ext-acl 20 match-entry 20

Action Groups

A group of one or more actions to perform, when multiple actions are available the first action is used. Create an action group which routes traffic to the proxy server on our internal network.

set action-group name Proxy
set action-group Proxy next-interface ethernet0/0 next-hop 192.168.168.253 action-entry 10

We now need to create another action group that routes traffic as it would do normally:

set action-group name DirectHTTP
set action-group DirectHTTP next-interface ethernet0/2 action-entry 10

Policy

A policy combines what we’ve created so far. When no policy is matched the normal routing tables are used. Create a new policy named “Proxy” with two entries. The first ensures that non-proxy traffic gets routed normally, the second routes traffic through the proxy.

set pbr policy name Proxy
set pbr policy Proxy match-group DirectHTTP action-group DirectHTTP 10
set pbr policy Proxy match-group Proxy action-group Proxy 20
exit

Policy Binding

The final step is to apply (or, ‘Bind’) the policy so that it takes effect. We have a few choices as to where we can bind the policy:

• A virtual router
• A zone
• An interface

We can apply multiple bindings, in which case the most specific binding takes effect. In our configuration we’ll bind the policy we’ve created to traffic passing out of our “Trust” interface:

set interface ethernet0/0 pbr Proxy

And there you have it, your outbound HTTP traffic is now being silently routed through a proxy server.

@echo off
REM ================================================================
REM CONFIGURATION INFO
REM ================================================================
set USERNAME=backupAccount
set PASSWORD=superSecretPassword
set CFGFILE=BackupList.txt
set DESTDIR=C:\Backups\

REM ================================================================
REM STOP CHANGING HERE OR YOU'LL BREAK SOMETHING
REM ================================================================
SET TIMESTAMP=%date:~-4,4%.%date:~-7,2%.%date:~-10,2%
for /F "tokens=1,2 delims=," %%A in (%CFGFILE%) do (
	IF NOT EXIST "%DESTDIR%%TIMESTAMP%" mkdir "%DESTDIR%%TIMESTAMP%"
	pscp -q -scp -pw %PASSWORD% %USERNAME%@%%B:ns_sys_config "%DESTDIR%%TIMESTAMP%\%%A.cfg"
)

The above will read the details of the firewalls from a CSV file (BackupList.txt) in hostname,ip address format. PSCP is then used to SCP the configuration from the firewall to the location specified in DESTDIR.

You’ll need to make sure SSH + SCP is enabled on your firewalls and that pscp is in the same directory as the script. You can find the latest version of Putty and PSCP here.

PPTP Forwarding

Firstly, I was having problems even forwarding the PPTP traffic. I’d initially setup a VIP on the external interface forwarding a custom PPTP service :

IP (47) src port: 2048-2048, dst port: 2048-2048
TCP src port: 0-65535, dst port: 1723-1723

I’d then setup a Policy to allow the relevant traffic through. Alas, no such luck. Ditching the VIP and having a fixed IP for VPN traffic seemed to work. To put it simply, use MIP rather than VIP.

Routing PPTP traffic for site to site links

The second problem was a little weird. At the moment we use MS-RAS for site to site links, I’d created a route on the Netscreen which was working, but connections would drop after a very short period of time (say 20 seconds). The routing was as follows (outbound shown in green, reutn shown in red).

Thankfully the solution wasn’t too messy. Since the Netscreen was missing the return traffic it was dropping the connections. The solution is to log into the Netscreen via telnet and issue the following command:

unset flow tcp-syn-check

As if by magic, everything now works.