Re: Cisco redirection working

Graham Somers wrote:
>
> Hi
>
> If you could take the time to give a short rundown on your steps to
> getting your Cisco redirection working I, and I'm sure others, would
> appreciate it. I have been following the topic but seem to have left
> out something vital.

Ok, here is how I would go about to make transparent proxying:

1. Configure the Squid process as a accelerator and proxy. Transparent
proxying is the same as acceleration of all internet hosts.
2. Get the HOST to transparently accept ANY port 80 traffic and send
them to the Squid process. This is how a transparent proxy differs from
a plain httpd accelerator.
3. Set up the routing to pass port 80 traffic throught the proxy host.

---- Details on step 1, configure squid 1.1.X ----
In squid.conf you write
  httpd_accel virtual 80
  httpd_accel_with_proxy on
  httpd_accel_uses_host_header on

And patch src/icp.c function parseHttpRequest so that the acceleration
part looks like
        /* prepend the accel prefix */
        if (opt_accel_uses_host && ...
            ...
        } else if (vhost_mode) {
            ...
        }
instead of the other way around.
A patch that does this is available from
http://hem.passagen.se/hno/squid/squid-1.1.20.host_and_virtual.patch
(cd to main directory, and patch -p1 <patchfile")

This patch is needed to accelerate both Host: based virtual servers, and
simple clients not sending Host: headers. Without the patch one of them
corrupts the cache or fails (which one depends on what you write in
squid.conf, and the most likely bet is that virtual servers get
corrupted).

---- Details on step 1, configure squid 1.2 ----
In squid.conf you write
  httpd_accel_host virtual
  httpd_accel_with_proxy on
  httpd_accel_uses_host_header on

no patching required.

---- Details on step 2, accepting port 80 traffic -----
The HOST needs to transparently accept port 80 traffic from the clients,
and hand it off to the Squid process. This needs some modifications to
the TCP/IP processing on the host, and can't be done from inside Squid.

On Linux this modifications is done with the ipfwadm -r option (requires
IP Firewalling to be compiled in the kernel).
  # First some safe-guard rules to prevent looping
  ipfwadm -I -a accept -W lo
  ipfwadm -I -a accept -S thishost
  ipfwadm -I -a accept -D thishost
  # Then the magic rule that forwards traffic to the Squid process
  ipfwadm -I -a accept [-S clientnet/mask] -D 0/0 80 -r 3128

On some other OS:es you can use ipfilter to do a similar thing, but I
have no experience of it (I am sure others have).

The easies way to test if you have done everyting correcly so far is to
have a station in the same network as the Squid host, and set the
routing on that station to use the Squid host instead of your normal
router. Then "telnet 1.2.3.4 80" and type HELLO<enter>, and you should
see a error message from squid. Then telnet "proxy-host 80", and check
that you get connection refused (or connected to the local HTTP server
if any).

---- Details on step 3, routing ----

This can be done in two ways, either set up a route-map on the router,
or use the proxy-host as a router. Most people prefer to have the router
remap port 80 traffic to a separate proxy machine, as the proxy machine
has a higher failure ratio then a typical router...

A Cisco config resently shown in squid-users ("Graham Somers"
<gsomers@icon.co.zw>):
  !
  interface Ethernet0
  description To Office Ethernet
  ip address 208.206.76.1 255.255.255.0
  no ip directed-broadcast
  no ip mroute-cache
  ip policy route-map proxy-redir
  !
  access-list 110 deny tcp host 208.206.76.44 any eq www
  access-list 110 permit tcp any any eq www
  route-map proxy-redir permit 10
  match ip address 110
  set ip next-hop 208.206.76.44

There are however a few gotchas when doing transparent proxying. The
most prominent one is that the MTU of the interface talking to the
clients needs to be set to the lowest MTU possible in the patch between
the Squid host and the clients (including their dialup connection). I
have seen on this list that someone did solve this with a patched
ipfilter(?) and a route-map to redirect ICMP to the Squid host. In most
situations this is no problem as most links have MTU 1500, but some
likes to use smaller MTUs to support mixed traffic on slow links. A easy
path around the problem is to tell those few that use a smaller MTU to
fill in their proxy settings in the browser.

---
Henrik Nordstr�m
Sparetime Squid Hacker