File: FAQ-17.html

package info (click to toggle)
squid 2.6.5-6etch5
links: PTS
area: main
in suites: etch
size: 12,540 kB
ctags: 13,801
sloc: ansic: 105,278; sh: 6,083; makefile: 1,297; perl: 1,245; awk: 40
file content (1401 lines) | stat: -rw-r--r-- 50,329 bytes
parent folder | download | duplicates (2)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.21">
 <TITLE>SQUID Frequently Asked Questions: Interception Caching/Proxying</TITLE>
 <LINK HREF="FAQ-18.html" REL=next>
 <LINK HREF="FAQ-16.html" REL=previous>
 <LINK HREF="FAQ.html#toc17" REL=contents>
</HEAD>
<BODY>
<A HREF="FAQ-18.html">Next</A>
<A HREF="FAQ-16.html">Previous</A>
<A HREF="FAQ.html#toc17">Contents</A>
<HR>
<H2><A NAME="trans-caching"></A> <A NAME="s17">17.</A> <A HREF="FAQ.html#toc17">Interception Caching/Proxying</A></H2>

<P><I>How can I make my users' browsers use my cache without configuring
the browsers for proxying?</I></P>
<P>First, it is <EM>critical</EM> to read the full comments in the squid.conf
file!  That is the only authoritative source for configuration
information.  However, the following instructions are correct as of
this writing (July 1999.)</P>

<P>Getting interception caching to work requires four distinct steps:
<OL>
<LI>
<B>Compile and run a version of Squid which accepts
connections for other addresses</B>.  For some operating systems,
you need to have configured and built a version of Squid which
can recognize the hijacked connections and discern the
destination addresses. For Linux this seems to work
automatically.  For *BSD-based systems, you probably have to
configure squid with the <EM>--enable-ipf-transparent</EM> option.
(Do a <EM>make clean</EM> if you previously configured without that
option, or the correct settings may not be present.)
</LI>
<LI>
<B>Configure Squid to accept and process the connections</B>.
You have to change the Squid configuration settings to
recognize the hijacked connections and discern the destination
addresses.  Here are the important settings in <EM>squid.conf</EM>:
<PRE>
http_port 8080
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy  on
httpd_accel_uses_host_header on
</PRE>

</LI>
<LI>
<B>Get your cache server to accept the packets</B>. You have to
configure your cache host to accept the redirected packets -
any IP address, on port 80 - and deliver them to your cache
application.  This is typically done with IP
filtering/forwarding features built into the kernel.
On linux they call this <EM>iptables</EM> (kernel 2.4.x),
<EM>ipchains</EM> (2.2.x) or <EM>ipfwadm</EM> (2.0.x).
On FreeBSD its called <EM>ipfw</EM>.  Other
BSD systems may use <EM>ip filter</EM> or <EM>ipnat</EM>.  On most
systems, it may require rebuilding the kernel or adding a new
loadable kernel module.
</LI>
<LI>
<B>Get the packets to your cache server</B>.  There are several
ways to do this.  First, if your proxy machine is already in
the path of the packets (i.e. it is routing between your proxy
users and the Internet) then you don't have to worry about this
step.  This would be true if you install Squid on a firewall
machine, or on a UNIX-based router.  If the cache is not in the
natural path of the connections, then you have to divert the
packets from the normal path to your cache host using a router
or switch. You may be able to do this with a Cisco router using
their "route maps" feature, depending on your IOS version. You
might also use a so-called layer-4 switch, such as the Alteon
ACE-director or the Foundry Networks ServerIron.  Finally, you
might be able to use a stand-alone router/load-balancer type
product, or routing capabilities of an access server.
</LI>
</OL>
</P>
<P><B>Notes</B>:
<UL>
<LI>The <EM>http_port 8080</EM> in this example assumes you will redirect
incoming port 80 packets to port 8080 on your cache machine.  If you
are running Squid on port 3128 (for example) you can leave it there via
<EM>http_port 3128</EM>, and redirect to that port via your IP filtering or
forwarding commands.
</LI>
<LI>In the <EM>httpd_accel_host</EM> option, <EM>virtual</EM> is the magic word!
</LI>
<LI>The <EM>httpd_accel_with_proxy on</EM> is required to enable interception
proxy mode; essentially in interception proxy mode Squid thinks it is acting
both as an accelerator (hence accepting packets for other IPs on port 80) and
a caching proxy (hence serving files out of cache.)
</LI>
<LI> You <B>must</B> use <EM>httpd_accel_uses_host_header on</EM> to get
the cache to work properly in interception mode.  This enables the cache
to index its stored objects under the true hostname, as is done in a
normal proxy, rather than under the IP address.  This is especially
important if you want to use a parent cache hierarchy, or to share
cache data between interception proxy users and non-interception proxy
users, which you can do with Squid in this configuration.
</LI>
</UL>
</P>

<H2><A NAME="ss17.1">17.1</A> <A HREF="FAQ.html#toc17.1">Interception caching for Solaris, SunOS, and BSD systems</A>
</H2>

<P>NOTE: You don't need to use IP Filter on FreeBSD.  Use the built-in <EM>ipfw</EM> feature
instead.  See the FreeBSD subsection below.</P>

<H3>Install IP Filter</H3>

<P>First, get and install the
<A HREF="http://coombs.anu.edu.au/ipfilter/">IP Filter package</A>.</P>

<H3>Configure ipnat</H3>

<P>Put these lines in <EM>/etc/ipnat.rules</EM>:
<PRE>
        # Redirect direct web traffic to local web server.
        rdr de0 1.2.3.4/32 port 80 -> 1.2.3.4 port 80 tcp

        # Redirect everything else to squid on port 8080
        rdr de0 0.0.0.0/0 port 80 -> 1.2.3.4 port 8080 tcp
</PRE>
</P>

<P>Modify your startup scripts to enable ipnat.  For example, on FreeBSD it
looks something like this:
<PRE>
        /sbin/modload /lkm/if_ipl.o
        /sbin/ipnat -f /etc/ipnat.rules
        chgrp nobody /dev/ipnat
        chmod 644 /dev/ipnat
</PRE>
</P>

<H3>Configure Squid</H3>

<H3>Squid-2</H3>

<P>Squid-2 (after version beta25) has IP filter support built in.
Simple enable it when you run <EM>configure</EM>:
<PRE>
        ./configure --enable-ipf-transparent
</PRE>

Add these lines to your <EM>squid.conf</EM> file:
<PRE>
        http_port 8080
        httpd_accel_host virtual
        httpd_accel_port 80
        httpd_accel_with_proxy on
        httpd_accel_uses_host_header on
</PRE>

Note, you don't have to use port 8080, but it must match whatever you
used in the <EM>/etc/ipnat.rules</EM> file.</P>
<H3>Squid-1.1</H3>

<P>Patches for Squid-1.X are available from
<A HREF="http://www.fan.net.au/~q/squid/">Quinton Dolan's Squid page</A>.
Add these lines to <EM>squid.conf</EM>:
<PRE>
        http_port 8080
        httpd_accel virtual 80
        httpd_accel_with_proxy on
        httpd_accel_uses_host_header on
</PRE>
</P>

<P>Thanks to 
<A HREF="mailto:q@fan.net.au">Quinton Dolan</A>.</P>

<H2><A NAME="trans-linux-1"></A> <A NAME="ss17.2">17.2</A> <A HREF="FAQ.html#toc17.2">Interception caching with Linux 2.0 and ipfwadm</A>
</H2>

<P>by 
<A HREF="mailto:Rodney.van.den.Oever@tip.nl">Rodney van den Oever</A></P>

<P><B>Note:</B> Interception proxying does NOT work with Linux&nbsp;2.0.30!
Linux&nbsp;2.0.29 is known to work well.  If you're using a more recent
kernel, like 2.2.X, then you should probably use an ipchains configuration,
<A HREF="#trans-linux-2">as described below</A>.</P>

<P><B>Warning:</B> this technique has some shortcomings.
<OL>
<LI><B>This method only supports the HTTP protocol, not gopher or FTP</B></LI>
<LI>Since the browser wasn't set up to use a proxy server, it uses
the FTP protocol (with destination port 21) and not the required
HTTP protocol.  You can't setup a redirection-rule to the proxy
server since the browser is speaking the wrong protocol.  A similar
problem occurs with gopher.  Normally all proxy requests are
translated by the client into the HTTP protocol, but since the
client isn't aware of the redirection, this never happens.</LI>
</OL>
</P>

<P>If you can live with the side-effects, go ahead and compile your
kernel with firewalling and redirection support.  Here are the
important parameters from <EM>/usr/src/linux/.config</EM>:</P>
<P>
<PRE>
        #
        # Code maturity level options
        #
        CONFIG_EXPERIMENTAL=y
        #
        # Networking options
        #
        CONFIG_FIREWALL=y
        # CONFIG_NET_ALIAS is not set
        CONFIG_INET=y
        CONFIG_IP_FORWARD=y
        # CONFIG_IP_MULTICAST is not set
        CONFIG_IP_FIREWALL=y
        # CONFIG_IP_FIREWALL_VERBOSE is not set
        CONFIG_IP_MASQUERADE=y
        CONFIG_IP_TRANSPARENT_PROXY=y
        CONFIG_IP_ALWAYS_DEFRAG=y
        # CONFIG_IP_ACCT is not set
        CONFIG_IP_ROUTER=y
</PRE>
</P>

<P>You may also need to enable <B>IP Forwarding</B>.  One way to do it
is to add this line to your startup scripts:
<PRE>
        echo 1 > /proc/sys/net/ipv4/ip_forward
</PRE>
</P>

<P>Go to the
<A HREF="http://www.xos.nl/linux/ipfwadm/">Linux IP Firewall and Accounting</A> page,
obtain the source distribution to <EM>ipfwadm</EM> and install it.
Older versions of <EM>ipfwadm</EM> may not work.  You might need
at least version <B>2.3.0</B>.
You'll use <EM>ipfwadm</EM> to setup the redirection rules.  I
added this rule to the script that runs from <EM>/etc/rc.d/rc.inet1</EM>
(Slackware) which sets up the interfaces at boot-time. The redirection
should be done before any other Input-accept rule.  To really make
sure it worked I disabled the forwarding (masquerading) I normally
do.</P>
<P><EM>/etc/rc.d/rc.firewall</EM>:</P>
<P>
<PRE>
        #!/bin/sh
        # rc.firewall   Linux kernel firewalling rules
        FW=/sbin/ipfwadm

        # Flush rules, for testing purposes
        for i in I O F # A      # If we enabled accounting too
        do
                ${FW} -$i -f
        done

        # Default policies:
        ${FW} -I -p rej         # Incoming policy: reject (quick error)
        ${FW} -O -p acc         # Output policy: accept
        ${FW} -F -p den         # Forwarding policy: deny

        # Input Rules:

        # Loopback-interface (local access, eg, to local nameserver):
        ${FW} -I -a acc -S localhost/32 -D localhost/32

        # Local Ethernet-interface:

        # Redirect to Squid proxy server:
        ${FW} -I -a acc -P tcp -D default/0 80 -r 8080

        # Accept packets from local network:
        ${FW} -I -a acc -P all -S localnet/8 -D default/0 -W eth0

        # Only required for other types of traffic (FTP, Telnet):

        # Forward localnet with masquerading (udp and tcp, no icmp!):
        ${FW} -F -a m -P tcp -S localnet/8 -D default/0
        ${FW} -F -a m -P udp -S localnet/8 -D default/0
</PRE>
</P>

<P>Here all traffic from the local LAN with any destination gets redirected to
the local port 8080.  Rules can be viewed like this:
<PRE>
        IP firewall input rules, default policy: reject
        type  prot source               destination          ports
        acc   all  127.0.0.1            127.0.0.1            n/a
        acc/r tcp  10.0.0.0/8           0.0.0.0/0            * -> 80 => 8080
        acc   all  10.0.0.0/8           0.0.0.0/0            n/a
        acc   tcp  0.0.0.0/0            0.0.0.0/0            * -> *
</PRE>
</P>

<P>I did some testing on Windows 95 with both Microsoft Internet
Explorer 3.01 and Netscape Communicator pre-release and it worked
with both browsers with the proxy-settings disabled.</P>

<P>At one time <EM>squid</EM> seemed to get in a loop when I pointed the
browser to the local port 80.  But this could be avoided by adding a
reject rule for client to this address:
<PRE>
        ${FW} -I -a rej -P tcp -S localnet/8 -D hostname/32 80

        IP firewall input rules, default policy: reject
        type  prot source               destination          ports
        acc   all  127.0.0.1            127.0.0.1            n/a
        rej   tcp  10.0.0.0/8           10.0.0.1             * -> 80
        acc/r tcp  10.0.0.0/8           0.0.0.0/0            * -> 80 => 8080
        acc   all  10.0.0.0/8           0.0.0.0/0            n/a
        acc   tcp  0.0.0.0/0            0.0.0.0/0            * -> *
</PRE>
</P>

<P><EM>NOTE on resolving names</EM>:  Instead of just
passing the URLs to the proxy server, the browser itself has to
resolve the URLs.  Make sure the workstations are setup to query
a local nameserver, to minimize outgoing traffic.</P>
<P>If you're already running a nameserver at the firewall or proxy server
(which is a good idea anyway IMHO) let the workstations use this
nameserver.</P>

<P>Additional notes from
<A HREF="mailto:RichardA@noho.co.uk">Richard Ayres</A></P>
<P>
<BLOCKQUOTE>
<P>I'm using such a setup. The only issues so far have been that:</P>
<P>
<OL>
<LI>It's fairly useless to use my service providers parent caches
(cache-?.www.demon.net) because by proxying squid only sees IP addresses,
not host names and demon aren't generally asked for IP addresses by other
users;
</LI>
<LI>Linux kernel 2.0.30 is a no-no as interception proxying is broken (I use
2.0.29);
</LI>
<LI>Client browsers must do host name lookups themselves, as they don't know
they're using a proxy;
</LI>
<LI>The Microsoft Network won't authorize its users through a proxy, so I
have to specifically *not* redirect those packets (my company is a MSN
content provider).</LI>
</OL>
</P>
<P>Aside from this, I get a 30-40% hit rate on a 50MB cache for 30-40 users and
am quite pleased with the results.</P>
</BLOCKQUOTE>
</P>

<P>See also 
<A HREF="http://www.ibiblio.org/pub/Linux/docs/HOWTO/mini/other-formats/html_single/TransparentProxy.html">Daniel Kiracofe's page</A>.</P>

<H2><A NAME="trans-linux-2"></A> <A NAME="ss17.3">17.3</A> <A HREF="FAQ.html#toc17.3">Interception caching with Linux 2.2 and ipchains</A>
</H2>

<P>by 
<A HREF="mailto:Support@dnet.co.uk">Martin Lyons</A></P>
<P>You need to configure your kernel for ipchains.
Configuring Linux kernels is beyond the scope of 
this FAQ.  One way to do it is:
<PRE>
        # cd /usr/src/linux
        # make menuconfig
</PRE>
</P>
<P>The following shows important kernel features to include:
<PRE>
        [*] Network firewalls
        [ ] Socket Filtering
        [*] Unix domain sockets
        [*] TCP/IP networking
        [ ] IP: multicasting
        [ ] IP: advanced router
        [ ] IP: kernel level autoconfiguration
        [*] IP: firewalling
        [ ] IP: firewall packet netlink device
        [*] IP: always defragment (required for masquerading)
        [*] IP: transparent proxy support
</PRE>
</P>
<P>You must include the <EM>IP: always defragment</EM>, otherwise it prevents
you from using the REDIRECT chain.</P>

<P>You can use this script as a template for your own <EM>rc.firewall</EM>
to configure ipchains:
<PRE>
        #!/bin/sh
        # rc.firewall   Linux kernel firewalling rules
        # Leon Brooks (leon at brooks dot fdns dot net)
        FW=/sbin/ipchains
        ADD="$FW -A"

        # Flush rules, for testing purposes
        for i in I O F # A      # If we enabled accounting too
        do
                ${FW} -F $i
        done

        # Default policies:
        ${FW} -P input REJECT   # Incoming policy: reject (quick error)
        ${FW} -P output ACCEPT  # Output policy: accept
        ${FW} -P forward DENY   # Forwarding policy: deny

        # Input Rules:

        # Loopback-interface (local access, eg, to local nameserver):
        ${ADD} input -j ACCEPT -s localhost/32 -d localhost/32

        # Local Ethernet-interface:

        # Redirect to Squid proxy server:
        ${ADD} input -p tcp -d 0/0 80 -j REDIRECT 8080

        # Accept packets from local network:
        ${ADD} input -j ACCEPT -s localnet/8 -d 0/0 -i eth0

        # Only required for other types of traffic (FTP, Telnet):

        # Forward localnet with masquerading (udp and tcp, no icmp!):
        ${ADD} forward -j MASQ -p tcp -s localnet/8 -d 0/0
        ${ADD} forward -j MASQ -P udp -s localnet/8 -d 0/0
</PRE>
</P>

<P>Also, 
<A HREF="mailto:andrew@careless.net">Andrew Shipton</A>
notes that with 2.0.x kernels you don't need to enable packet forwarding,
but with the 2.1.x and 2.2.x kernels using ipchains you do.  Packet
forwarding is enabled with the following command:
<PRE>
        echo 1 > /proc/sys/net/ipv4/ip_forward
</PRE>
</P>

<H2><A NAME="trans-linux-3"></A> <A NAME="ss17.4">17.4</A> <A HREF="FAQ.html#toc17.4">Interception caching with Linux 2.4 and netfilter</A>
</H2>

<P>NOTE: this information comes from Daniel Kiracofe's
<A HREF="http://en.tldp.org/HOWTO/mini/TransparentProxy.html">Transparent Proxy with Squid mini-HOWTO</A>.</P>
<P>To support netfilter transparent interception on Linux 2.4 Squid
must be compiled with the --enable-linux-netfilter option.</P>
<P>To enable netwfilter support you may need to build a new kernel.
Be sure to enable all of these options:
<UL>
<LI>Networking support </LI>
<LI>Sysctl support </LI>
<LI>Network packet filtering </LI>
<LI>TCP/IP networking </LI>
<LI>Connection tracking (Under ``IP: Netfilter Configuration'' in menuconfig) </LI>
<LI>IP tables support </LI>
<LI>Full NAT </LI>
<LI>REDIRECT target support </LI>
<LI>/proc filesystem support </LI>
</UL>
</P>
<P>You must say NO to ``Fast switching'' </P>
<P>After building the kernel, install it and reboot.</P>
<P>You may need to enable packet forwarding (e.g. in your startup scripts):
<PRE>
echo 1 > /proc/sys/net/ipv4/ip_forward
</PRE>
</P>
<P>Use the <EM>iptables</EM> command to make your kernel intercept HTTP connections
and send them to Squid:
<PRE>
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128 
</PRE>
</P>


<H2><A NAME="ss17.5">17.5</A> <A HREF="FAQ.html#toc17.5">Interception caching with Cisco routers</A>
</H2>

<P>by 
<A HREF="mailto:John.Saunders@scitec.com.au">John Saunders</A></P>

<P>This works with at least IOS 11.1 and later I guess. Possibly earlier,
as I'm no CISCO expert I can't say for sure. If your router is doing
anything more complicated that shuffling packets between an ethernet
interface and either a serial port or BRI port, then you should work
through if this will work for you.</P>

<P>First define a route map with a name of proxy-redirect (name doesn't
matter) and specify the next hop to be the machine Squid runs on.
<PRE>
        !
        route-map proxy-redirect permit 10
         match ip address 110
         set ip next-hop 203.24.133.2
        !
</PRE>

Define an access list to trap HTTP requests. The second line allows
the Squid host direct access so an routing loop is not formed.
By carefully writing your access list as show below, common
cases are found quickly and this can greatly reduce the load on your
router's processor.
<PRE>
        !
        access-list 110 deny   tcp any any neq www
        access-list 110 deny   tcp host 203.24.133.2 any
        access-list 110 permit tcp any any
        !
</PRE>

Apply the route map to the ethernet interface.
<PRE>
        !
        interface Ethernet0
         ip policy route-map proxy-redirect
        !
</PRE>
</P>

<H3>possible bugs</H3>

<P>
<A HREF="mailto:morgan@curtin.net">Bruce Morgan</A> notes that
there is a Cisco bug relating to interception proxying using IP
policy route maps, that causes NFS and other applications to break.
Apparently there are two bug reports raised in Cisco, but they are
not available for public dissemination.</P>

<P>The problem occurs with o/s packets with more than 1472 data bytes.  If you try
to ping a host with more than 1472 data bytes across a Cisco interface with the
access-lists and ip policy route map, the icmp request will fail.  The
packet will be fragmented, and the first fragment is checked against the
access-list and rejected - it goes the "normal path" as it is an icmp
packet - however when the second fragment is checked against the
access-list it is accepted (it isn't regarded as an icmp packet), and
goes to the action determined by the policy route map!</P>

<P>
<A HREF="mailto:John.Saunders@scitec.com.au">John</A> notes that you
may be able to get around this bug by carefully writing your access lists.
If the last/default rule is to permit then this bug
would be a problem, but if the last/default rule was to deny then
it won't be a problem.  I guess fragments, other than the first,
don't have the information available to properly policy route them.
Normally TCP packets should not be fragmented, at least my network
runs an MTU of 1500 everywhere to avoid fragmentation.  So this would
affect UDP and ICMP traffic only.</P>

<P>Basically, you will have to pick between living with the bug or better
performance.  This set has better performance, but suffers from the
bug:
<PRE>
        access-list 110 deny   tcp any any neq www
        access-list 110 deny   tcp host 10.1.2.3 any
        access-list 110 permit tcp any any
</PRE>

Conversely, this set has worse performance, but works for all protocols:
<PRE>
        access-list 110 deny   tcp host 10.1.2.3 any
        access-list 110 permit tcp any any eq www
        access-list 110 deny   tcp any any
</PRE>
</P>

<H2><A NAME="ss17.6">17.6</A> <A HREF="FAQ.html#toc17.6">Interception caching with LINUX 2.0.29 and CISCO IOS 11.1</A>
</H2>

<P>Just for kicks, here's an email message posted to squid-users
on how to make interception proxying work with a Cisco router
and Squid running on Linux.</P>

<P>by 
<A HREF="mailto:signal@shreve.net">Brian Feeny</A></P>

<P>Here is how I have Interception proxying working for me, in an environment
where my router is a Cisco 2501 running IOS 11.1, and Squid machine is
running Linux 2.0.33.</P>

<P>Many thanks to the following individuals and the squid-users list for
helping me get redirection and interception proxying working on my
Cisco/Linux box.</P>
<P>
<UL>
<LI>Lincoln Dale</LI>
<LI>Riccardo Vratogna</LI>
<LI>Mark White</LI>
<LI>Henrik Nordstrom</LI>
</UL>
</P>

<P>First, here is what I added to my Cisco, which is running IOS 11.1.  In
IOS 11.1 the route-map command is "process switched" as opposed to the
faster "fast-switched" route-map which is found in IOS 11.2 and later.
You may wish to be running IOS 11.2.  I am running 11.1, and have had no
problems with my current load of about 150 simultaneous connections to
squid.:
<PRE>
        !
        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
</PRE>
</P>

<P>So basically from above you can see I added the "route-map" declaration,
and an access-list, and then turned the route-map on under int e0 "ip
policy route-map proxy-redir"</P>

<P>ok, so the Cisco is taken care of at this point.  The host above:
208.206.76.44, is the ip number of my squid host.</P>

<P>My squid box runs Linux, so I had to do the following on it:</P>

<P>my kernel (2.0.33) config looks like this:
<PRE>
        #
        # Networking options
        #
        CONFIG_FIREWALL=y
        # CONFIG_NET_ALIAS is not set
        CONFIG_INET=y
        CONFIG_IP_FORWARD=y
        CONFIG_IP_MULTICAST=y
        CONFIG_SYN_COOKIES=y
        # CONFIG_RST_COOKIES is not set
        CONFIG_IP_FIREWALL=y
        # CONFIG_IP_FIREWALL_VERBOSE is not set
        CONFIG_IP_MASQUERADE=y
        # CONFIG_IP_MASQUERADE_IPAUTOFW is not set
        CONFIG_IP_MASQUERADE_ICMP=y
        CONFIG_IP_TRANSPARENT_PROXY=y
        CONFIG_IP_ALWAYS_DEFRAG=y
        # CONFIG_IP_ACCT is not set
        CONFIG_IP_ROUTER=y
</PRE>
</P>

<P>You will need Firewalling and Transparent Proxy turned on at a minimum.</P>

<P>Then some ipfwadm stuff:
<PRE>
        # Accept all on loopback
        ipfwadm -I -a accept -W lo
        # Accept my own IP, to prevent loops (repeat for each interface/alias)
        ipfwadm -I -a accept -P tcp -D 208.206.76.44 80
        # Send all traffic destined to port 80 to Squid on port 3128
        ipfwadm -I -a accept -P tcp -D 0/0 80 -r 3128
</PRE>
</P>
<P>it accepts packets on port 80 (redirected from the Cisco), and redirects
them to 3128 which is the port my squid process is sitting on.  I put all
this in /etc/rc.d/rc.local</P>

<P>I am using
<A HREF="/Versions/1.1/1.1.20/">v1.1.20 of Squid</A> with
<A HREF="http://devel.squid-cache.org/hno/patches/squid-1.1.20.host_and_virtual.patch">Henrik's patch</A>
installed.  You will want to install this patch if using a setup similar
to mine.</P>

<H2><A NAME="trans-freebsd"></A> <A NAME="ss17.7">17.7</A> <A HREF="FAQ.html#toc17.7">Interception caching with FreeBSD</A>
</H2>

<P>by Duane Wessels</P>
<P>I set out yesterday to make interception caching work with Squid and
FreeBSD.  It was, uh, fun.</P>
<P>It was relatively easy to configure a cisco to divert port 80
packets to my FreeBSD box.  Configuration goes something like this:
<PRE>
access-list 110 deny   tcp host 10.0.3.22 any eq www
access-list 110 permit tcp any any eq www
route-map proxy-redirect permit 10
 match ip address 110
 set ip next-hop 10.0.3.22
int eth2/0
 ip policy route-map proxy-redirect
</PRE>

Here, 10.0.3.22 is the IP address of the FreeBSD cache machine.</P>

<P>Once I have packets going to the FreeBSD box, I need to get the
kernel to deliver them to Squid.
I started on FreeBSD-2.2.7, and then downloaded
<A HREF="ftp://coombs.anu.edu.au/pub/net/ip-filter/">IPFilter</A>.  This was a dead end for me.  The IPFilter distribution
includes patches to the FreeBSD kernel sources, but many of these had
conflicts.  Then I noticed that the IPFilter page says
``It comes as a part of [FreeBSD-2.2 and later].''  Fair enough.  Unfortunately,
you can't hijack connections with the FreeBSD-2.2.X IPFIREWALL code (<EM>ipfw</EM>), and
you can't (or at least I couldn't) do it with <EM>natd</EM> either.</P>

<P>FreeBSD-3.0 has much better support for connection hijacking, so I suggest
you start with that.  You need to build a kernel with the following options:
<PRE>
        options         IPFIREWALL
        options         IPFIREWALL_FORWARD
</PRE>
</P>

<P>Next, its time to configure the IP firewall rules with <EM>ipfw</EM>.
By default, there are no "allow" rules and all packets are denied.
I added these commands to <EM>/etc/rc.local</EM>
just to be able to use the machine on my network:
<PRE>
        ipfw add 60000 allow all from any to any
</PRE>

But we're still not hijacking connections.  To accomplish that,
add these rules:
<PRE>
        ipfw add 49  allow tcp from 10.0.3.22 to any
        ipfw add 50  fwd 127.0.0.1 tcp from any to any 80
</PRE>

The second line (rule 50) is the one which hijacks the connection.
The first line makes sure we never hit rule 50 for traffic originated
by the local machine.  This prevents forwarding loops.</P>

<P>Note that I am not changing the port number here.  That is,
port 80 packets are simply diverted to Squid on port 80.
My Squid configuration is:
<PRE>
        http_port 80
        httpd_accel_host virtual
        httpd_accel_port 80
        httpd_accel_with_proxy on
        httpd_accel_uses_host_header on
</PRE>
</P>

<P>If you don't want Squid to listen on port 80 (because that
requires root privileges) then you can use another port.
In that case your ipfw redirect rule looks like:
<PRE>
        ipfw add 50 fwd 127.0.0.1,3128 tcp from any to any 80
</PRE>

and the <EM>squid.conf</EM> lines are:
<PRE>
        http_port 3128
        httpd_accel_host virtual
        httpd_accel_port 80
        httpd_accel_with_proxy on
        httpd_accel_uses_host_header on
</PRE>
</P>

<H2><A NAME="ss17.8">17.8</A> <A HREF="FAQ.html#toc17.8">Interception caching with ACC Tigris digital access server</A>
</H2>

<P>by 
<A HREF="mailto:John.Saunders@scitec.com.au">John Saunders</A></P>
<P>This is to do with configuring interception proxy
for an ACC Tigris digital access server (like a CISCO 5200/5300
or an Ascend MAX 4000). I've found that doing this in the NAS
reduces traffic on the LAN and reduces processing load on the
CISCO. The Tigris has ample CPU for filtering.</P>

<P>Step 1 is to create filters that allow local traffic to pass.
Add as many as needed for all of your address ranges.
<PRE>
        ADD PROFILE IP FILTER ENTRY local1 INPUT  10.0.3.0 255.255.255.0 0.0.0.0 0.0.0.0 NORMAL
        ADD PROFILE IP FILTER ENTRY local2 INPUT  10.0.4.0 255.255.255.0 0.0.0.0 0.0.0.0 NORMAL
</PRE>
</P>

<P>Step 2 is to create a filter to trap port 80 traffic.
<PRE>
        ADD PROFILE IP FILTER ENTRY http INPUT  0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 = 0x6 D= 80 NORMAL
</PRE>
</P>

<P>Step 3 is to set the "APPLICATION_ID" on port 80 traffic to 80.
This causes all packets matching this filter to have ID 80
instead of the default ID of 0.
<PRE>
        SET PROFILE IP FILTER APPLICATION_ID http 80
</PRE>
</P>

<P>Step 4 is to create a special route that is used for
packets with "APPLICATION_ID" set to 80. The routing
engine uses the ID to select which routes to use.
<PRE>
        ADD IP ROUTE ENTRY 0.0.0.0 0.0.0.0 PROXY-IP 1
        SET IP ROUTE APPLICATION_ID 0.0.0.0 0.0.0.0 PROXY-IP 80
</PRE>
</P>

<P>Step 5 is to bind everything to a filter ID called transproxy.
List all local filters first and the http one last.
<PRE>
        ADD PROFILE ENTRY transproxy local1 local2 http
</PRE>
</P>

<P>With this in place use your RADIUS server to send back the
``Framed-Filter-Id = transproxy'' key/value pair to the NAS.</P>

<P>You can check if the filter is being assigned to logins with
the following command:
<PRE>
        display profile port table
</PRE>
</P>

<H2><A NAME="ss17.9">17.9</A> <A HREF="FAQ.html#toc17.9">Interception caching with Foundry L4 switches</A>
</H2>

<P>by 
<A HREF="mailto:signal at shreve dot net">Brian Feeny</A>.</P>
<P>First, configure Squid for interception caching as detailed
at the 
<A HREF="#trans-caching">beginning of this section</A>.</P>
<P>Next, configure
the Foundry layer 4 switch to 
redirect traffic to your Squid box or boxes.  By default,
the Foundry
redirects to port 80 of your squid box.  This can
be changed to a different port if needed, but won't be covered
here.  </P>

<P>In addition, the switch does a "health check" of the port to make 
sure your squid is answering.  If you squid does not answer, the
switch defaults to sending traffic directly thru instead of 
redirecting it.  When the Squid comes back up, it begins
redirecting once again.</P>

<P>This example assumes you have two squid caches:
<PRE>
squid1.foo.com  192.168.1.10
squid2.foo.com  192.168.1.11
</PRE>
</P>

<P>We will assume you have various workstations, customers, etc, plugged
into the switch for which you want them to be intercepted and sent to Squid.
The squid caches themselves should be plugged into the switch as well.
Only the interface that the router is connected to is important.  Where you
put the squid caches or other connections does not matter.</P>

<P>This example assumes your router is plugged into interface <B>17</B>
of the switch.  If not, adjust the following commands accordingly.</P>
<P>
<OL>
<LI>Enter configuration mode:
<PRE>
telnet@ServerIron#conf t
</PRE>

</LI>
<LI>Configure each squid on the Foundry:
<PRE>
telnet@ServerIron(config)# server cache-name squid1 192.168.1.10
telnet@ServerIron(config)# server cache-name squid2 192.168.1.11
</PRE>

</LI>
<LI>Add the squids to a cache-group:
<PRE>
telnet@ServerIron(config)#server cache-group 1
telnet@ServerIron(config-tc-1)#cache-name squid1
telnet@ServerIron(config-tc-1)#cache-name squid2
</PRE>

</LI>
<LI>Create a policy for caching http on a local port
<PRE>
telnet@ServerIron(config)# ip policy 1 cache tcp http local
</PRE>

</LI>
<LI>Enable that policy on the port connected to your router
<PRE>
telnet@ServerIron(config)#int e 17
telnet@ServerIron(config-if-17)# ip-policy 1 
</PRE>

</LI>
</OL>
</P>

<P>Since all outbound traffic to the Internet goes out interface
<B>17</B> (the router), and interface <B>17</B> has the caching policy applied to
it, HTTP traffic is going to be intercepted and redirected to the 
caches you have configured.</P>

<P>The default port to redirect to can be changed.  The load balancing
algorithm used can be changed (Least Used, Round Robin, etc).  Ports
can be exempted from caching if needed.  Access Lists can be applied
so that only certain source IP Addresses are redirected, etc.  This
information was left out of this document since this was just a quick
howto that would apply for most people, not meant to be a comprehensive
manual of how to configure a Foundry switch.  I can however revise this
with any information necessary if people feel it should be included.</P>

<H2><A NAME="ss17.10">17.10</A> <A HREF="FAQ.html#toc17.10">Interception caching with Cabletron/Entrasys products</A>
</H2>

<P>By Dave Wintrip, dave at purevanity dot net, June 3, 2004.</P>
<P>I have verified this configuration as working on a Cabletron
SmartSwitchRouter 2000, and it should work on any layer-4 aware
Cabletron or Entrasys product.</P>
<P>You must first configure Squid to enable interception caching,
outlined earlier.</P>
<P>Next, make sure that you have connectivity from the layer-4 device
to your squid box, and that squid is correctly configured to intercept
port 80 requests thrown it's way.</P>
<P>I generally create two sets of redirect ACLs, one for cache, and
one for bypassing the cache. This method of interception is very
similar to Cisco's route-map.</P>
<P>Log into the device, and enter enable mode, as well as configure
mode.
<PRE>
        ssr> en
        Password:

        ssr# conf
        ssr(conf)#
</PRE>
</P>
<P>I generally create two sets of redirect ACLs, one for specifying
who to cache, and one for destination addresses that need to bypass
the cache. This method of interception is very similar to Cisco's
route-map in this way. The ACL cache-skip is a list of destination
addresses that we do not want to transparently redirect to squid.
<PRE>
        ssr(conf)# acl cache-skip permit tcp any 192.168.1.100/255.255.255.255 any http
</PRE>
</P>
<P>The ACL cache-allow is a list of source addresses that will be
redirected to Squid.
<PRE>
        ssr(conf)# acl cache-allow permit tcp 10.0.22.0/255.255.255.0 any any http
</PRE>
</P>
<P>Save your new ACLs to the running configuration.
<PRE>
        ssr(conf)# save a
</PRE>
</P>
<P>Next, we need to create the ip-policies that will work to perform
the redirection. Please note that 10.0.23.2 is my Squid server, and
that 10.0.24.1 is my standard default next hop. By pushing the
cache-skip ACL to the default gateway, the web request is sent out
as if the squid box was not present. This could just as easily be
done using the squid configuration, but I would rather Squid not
touch the data if it has no reason to.
<PRE>
        ssr(conf)# ip-policy cache-allow permit acl cache-allow next-hop-list 10.0.23.2 action policy-only
        ssr(conf)# ip-policy cache-skip permit acl cache-skip next-hop-list 10.0.24.1 action policy-only
</PRE>
</P>
<P>Apply these new policies into the active configuration.
<PRE>
        ssr(conf)# save a
</PRE>
</P>
<P>We now need to apply the ip-policies to interfaces we want to cache
requests from. Assuming that localnet-gw is the interface name to
the network we want to cache requests from, we first apply the
cache-skip ACL to intercept requests on our do-not-cache list, and
forward them out the default gateway. We then apply the cache-allow
ACL to the same interface to redirect all other requests to the
cache server.
<PRE>
        ssr(conf)# ip-policy cache-skip apply interface localnet-gw
        ssr(conf)# ip-policy cache-allow apply interface localnet-gw
</PRE>
</P>
<P>We now need to apply, and permanently save our changes. Nothing we
have done before this point would effect anything without adding
the ip-policy applications into the active configuration, so lets
try it.
<PRE>
        ssr(conf)# save a
        ssr(conf)# save s
</PRE>
</P>
<P>Provided your Squid box is correct configured, you should now be
able to surf, and be transparently cached if you are using the
localnet-gw address as your gateway.</P>
<P>Some Cabletron/Entrasys products include another method of applying
a web cache, but details on configuring that is not covered in this
document, however is it fairly straight forward.</P>
<P>Also note, that if your Squid box is plugged directly into a port
on your layer-4 switch, and that port is part of its own VLAN, and
its own subnet, if that port were to change states to down, or the
address becomes uncontactable, then the switch will automatically
bypass the ip-policies and forward your web request though the
normal means. This is handy, might I add.</P>

<H2><A NAME="ss17.11">17.11</A> <A HREF="FAQ.html#toc17.11">The cache is trying to connect to itself...</A>
</H2>

<P>by 
<A HREF="mailto:hno@squid-cache.org">Henrik Nordstrom</A></P>
<P>I think almost everyone who have tried to build a interception proxy
setup have been bitten by this one.</P>

<P>Measures you can take:
<UL>
<LI>Deny Squid from fetching objects from itself (using ACL lists).</LI>
<LI>Apply a small patch that prevents Squid from looping infinitely
(available from 
<A HREF="http://devel.squid-cache.org/hno/">Henrik's Squid Patches</A>)</LI>
<LI>Don't run Squid on port 80, and redirect port 80 not destined for
the local machine to Squid (redirection == ipfilter/ipfw/ipfadm). This
avoids the most common loops.</LI>
<LI>If you are using ipfilter then you should also use transproxyd in
front of Squid. Squid does not yet know how to interface to ipfilter
(patches are welcome: squid-bugs@squid-cache.org).</LI>
</UL>
</P>

<H2><A NAME="ss17.12">17.12</A> <A HREF="FAQ.html#toc17.12">``Connection reset by peer'' and Cisco policy routing</A>
</H2>

<P>
<A HREF="mailto:fygrave at tigerteam dot net">Fyodor</A>
has tracked down the cause of unusual ``connection reset by peer'' messages
when using Cisco policy routing to hijack HTTP requests.</P>
<P>When the network link between router and the cache goes down for just a
moment, the packets that are supposed to be redirected are instead sent
out the default route.  If this happens, a TCP ACK from the client host
may be sent to the origin server, instead of being diverted to the
cache.  The origin server, upon receiving an unexpected ACK packet,
sends a TCP RESET back to the client, which aborts the client's request.</P>
<P>To work around this problem, you can install a static route to the
<EM>null0</EM> interface for the cache address with a higher metric (lower
precedence), such as 250.  Then, when the link goes down, packets from the client
just get dropped instead of sent out the default route.  For example, if
1.2.3.4 is the IP address of your Squid cache, you may add:
<PRE>
        ip route 1.2.3.4 255.255.255.255 Null0 250
</PRE>

This appears to cause the correct behaviour.</P>


<H2><A NAME="ss17.13">17.13</A> <A HREF="FAQ.html#toc17.13">WCCP - Web Cache Coordination Protocol</A>
</H2>

<P>Contributors: 
<A HREF="mailto:glenn@ircache.net">Glenn Chisholm</A>, 
<A HREF="mailto:ltd@cisco.com">Lincoln Dale</A> and 
<A HREF="mailto:reuben-squid@reub.net">Reuben Farrelly</A>.</P>

<H3>Does Squid support WCCP?</H3>

<P>CISCO's Web Cache Coordination Protocol V1.0 is supported in squid
2.3 and later. support WCCP V2.0.  Now that WCCP V2 is an open protocol,
Squid may be able to support it in the future.</P>

<H3>Configuring your Router</H3>

<P>There are two different methods of configuring WCCP on CISCO routers.
The first method is for routers that only support V1.0 of the
protocol. The second is for routers that support both.</P>

<H3>IOS Version 11.x</H3>

<P>It is possible that later versions of IOS 11.x will support V2.0 of the
protocol. If that is the case follow the 12.x instructions. Several
people have reported that the squid implimentation of WCCP does not
work with their 11.x routers. If you experience this please mail the
debug output from your router to <EM>squid-bugs</EM>.</P>
<P>
<PRE>
        conf t

        wccp enable
        !
        interface [Interface carrying Outgoing Traffic]x/x
        !
        ip wccp web-cache redirect
        !
        CTRL Z
        write mem
</PRE>
</P>

<H3>IOS Version 12.x</H3>

<P>Some of the early versions of 12.x do not have the 'ip wccp version'
command. You will need to upgrade your IOS version to use V1.0.</P>

<P>You will need to be running at least IOS Software Release <EM>12.0(5)T</EM>
if you're running the 12.0 T-train.  IOS Software Releases <EM>12.0(3)T</EM>
and <EM>12.0(4)T</EM> do not have WCCPv1, but  <EM>12.0(5)T</EM> does.</P>

<P>
<PRE>
        conf t

        ip wccp version 1
        ip wccp web-cache redirect-list 150
        !
        interface [Interface carrying Outgoing/Incoming Traffic]x/x
        ip wccp web-cache redirect out|in
        !
        CTRL Z
        write mem
</PRE>
</P>

<P>Replace 150 with an access list number (either standard or extended) 
which lists IP addresses which you do not wish to be transparently 
redirected to your cache.  Otherwise simply user the word 'redirect'
on it's own to redirect traffic from all sources to all destinations.</P>

<H3>IOS 12.x problems</H3>

<P>Some people report problems with WCCP and IOS 12.x.  They see
truncated or fragmented GRE packets arriving at the cache.  Apparently
it works if you disable Cisco Express Forwarding for the interface:
<PRE>
conf t
ip cef          # some systems may already have 'ip cef global'
int Ethernet 0/0      (or int FastEthernet 0/0 or other internal interface)
no ip route-cache cef
CTRL Z
</PRE>
</P>
<P>This may well be fixed in later releases of IOS.</P>

<H3><A NAME="wccp-on-freebsd"></A> Configuring FreeBSD</H3>

<P>FreeBSD first needs to be configured to receive and strip the GRE 
encapsulation from the packets from the router. To do this you will
need to patch and recompile your kernel.  The steps depend
on your kernel version.</P>

<H3>FreeBSD-3.x</H3>

<P>
<OL>
<LI>Apply the
<A HREF="../../WCCP-support/FreeBSD-3.x/gre.patch">patch for FreeBSD-3.x kernels</A>:
<PRE>
# cd /usr/src
# patch -s &lt; /tmp/gre.patch
</PRE>
</LI>
<LI>Download
<A HREF="../../WCCP-support/FreeBSD-3.x/gre.c">gre.c for FreeBSD-3.x</A>.
Save this file as <EM>/usr/src/sys/netinet/gre.c</EM>.</LI>
<LI>Add "options GRE" to your kernel config file and rebuild
your kernel. Note, the <EM>opt_gre.h</EM> file is
created when you run <EM>config</EM>.
Once your kernel is installed you will need to
<A HREF="#trans-freebsd">configure FreeBSD for interception proxying</A>.</LI>
</OL>
</P>


<H3>FreeBSD-4.0 through 4.7</H3>

<P>The procedure is nearly identical to the above for 3.x, but the
source files are a little different.</P>
<P>
<OL>
<LI>Apply the most appropriate patch file from the list of
<A HREF="../../WCCP-support/FreeBSD-4.x">patches for 4.x kernels</A>.</LI>
<LI>Download
<A HREF="../../WCCP-support/FreeBSD-3.x/gre.c">gre.c for FreeBSD-3.x</A>.
Save this file as <EM>/usr/src/sys/netinet/gre.c</EM>.</LI>
<LI>Add "options GRE" to your kernel config file and rebuild
your kernel. Note, the <EM>opt_gre.h</EM> file is
created when you run <EM>config</EM>.
Once your kernel is installed you will need to
<A HREF="#trans-freebsd">configure FreeBSD for interception proxying</A>.</LI>
</OL>
</P>

<H3>FreeBSD-4.8 and later</H3>

<P>The operating system now comes standard with some GRE support.  You need
to make a kernel with the GRE code enabled:
<PRE>
pseudo-device   gre
</PRE>
</P>
<P>And then configure the tunnel so that the router's GRE packets are
accepted:
<PRE>
# ifconfig gre0 create
# ifconfig gre0 $squid_ip $router_ip netmask 255.255.255.255 up
# ifconfig gre0 tunnel $squid_ip $router_ip
# route delete $router_ip
</PRE>
</P>
<P>Alternatively, you can try it like this:
<PRE>
ifconfig gre0 create
ifconfig gre0 $squid_ip 10.20.30.40 netmask 255.255.255.255 link1 tunnel $squid_ip $router_ip up
</PRE>
</P>
<P>Since the WCCP/GRE tunnel is one-way, Squid never sends any packets to 10.20.30.40 and that
particular address doesn't matter.</P>


<H3>Configuring Linux 2.2</H3>

<P>Al Blake has written a 
<A HREF="http://www.spc.int/it/TechHead/Wccp-squid.html">Cookbook for setting up transparent WCCP using Squid on RedHat Linux and a cisco access server</A>.</P>

<P>There are currently two methods for supporting WCCP with Linux 2.2.
A specific purpose module. Or the standard Linux GRE tunneling
driver. People have reported difficulty with the standard GRE
tunneling driver, however it does allow GRE functionality other
than WCCP. You should choose the method that suits your enviroment.</P>

<H3>Standard Linux GRE Tunnel</H3>

<P>Linux 2.2 kernels already support GRE, as long as the GRE module is
compiled into the kernel. However, WCCP uses a slightly non-standard
GRE encapsualtion format and Linux versions earlier than 2.6.9 may need
to be patched to support WCCP.</P>

<P>Ensure that the GRE code is either built as static or as a module by chosing
the appropriate option in your kernel config. Then rebuild your kernel.
If it is a module you will need to:
<PRE>
        modprobe ip_gre
</PRE>
</P>
<P>The next step is to tell Linux to establish an IP tunnel between the router and
your host.  Daniele Orlandi  reports
that you have to give the gre1 interface an address, but any old
address seems to work.
<PRE>
        iptunnel add gre1 mode gre remote &lt;Router-IP&gt; local &lt;Host-IP&gt; dev &lt;interface&gt;
        ifconfig gre1 127.0.0.2 up
</PRE>

&lt;Router-IP&gt; is the IP address of your router that is intercepting the 
HTTP packets.  &lt;Host-IP&gt; is the IP address of your cache, and
&lt;interface&gt; is the network interface that receives those packets (probably eth0).</P>

<P>Note that WCCP is incompatible with the rp_filter function in Linux and
you must disable this if enabled (default off). If enabled any packets
redirected by WCCP and intercepted by Netfilter/iptables will be silendly
discarded by the TCP/IP stack due to their "unexpected" origin from the gre
interface.</P>

<H3>Joe Cooper's Patch</H3>

<P>Joe Cooper has a patch for Linux 2.2.18 kernel on his 
<A HREF="http://www.swelltech.com/pengies/joe/patches/">Squid page</A>.</P>

<H3>WCCP Specific Module</H3>

<P>This module is not part of the standard Linux distributon. It needs
to be compiled as a module and loaded on your system to function.
Do not attempt to build this in as a static part of your kernel.</P>

<P>Download the 
<A HREF="../../WCCP-support/Linux/">Linux WCCP module</A>
and compile it as you would any Linux network module.</P>

<P>Copy the module to <EM>/lib/modules/kernel-version/ipv4/ip_wccp.o</EM>. Edit
<EM>/lib/modules/kernel-version/modules.dep</EM> and add:</P>
<P>
<PRE>
        /lib/modules/kernel-version/ipv4/ip_wccp.o:
</PRE>
</P>
<P>or run
<PRE>
        depmod -a
</PRE>
</P>

<P>Finally you will need to load the module:</P>
<P>
<PRE>
        modprobe ip_wccp
</PRE>
</P>

<H3>Common Steps</H3>

<P>The machine should now be striping the GRE encapsulation from any packets
recieved and requeuing them. The system will also need to be configured
for interception proxying, either with 
<A HREF="#trans-linux-1">ipfwadm</A> 
or with 
<A HREF="#trans-linux-2">ipchains</A>.</P>

<H3>Configuring Others</H3>

<P>If you have managed to configuring your operating system to support WCCP
with Squid
please contact us with the details so we may share them with others.</P>

<H2><A NAME="ss17.14">17.14</A> <A HREF="FAQ.html#toc17.14">Can someone tell me what version of cisco IOS WCCP is added in?</A>
</H2>

<P>IOS releases:
<UL>
<LI>11.1(19?)CA/CC or later</LI>
<LI>11.2(14)P or later</LI>
<LI>12.0(anything) or later</LI>
</UL>
</P>

<H2><A NAME="ss17.15">17.15</A> <A HREF="FAQ.html#toc17.15">What about WCCPv2?</A>
</H2>

<P>Cisco has published WCCPv2 as an 
<A HREF="http://www.web-cache.com/Writings/Internet-Drafts/draft-wilson-wrec-wccp-v2-00.txt">Internet Draft</A> (expired Jan 2001).  
There is a ongoing project at the 
<A HREF="http://devel.squid-cache.org/">Squid development projects</A>
website aiming to add support for WCCPv2 and at the time of writing this
patch provides at least the same functionality as WCCPv1.</P>

<H2><A NAME="ss17.16">17.16</A> <A HREF="FAQ.html#toc17.16">Can I use <EM>proxy_auth</EM> with interception?</A>
</H2>

<P>No, you cannot.  With interception proxying, the client thinks
it is talking to an origin server and would never send the
<EM>Proxy-authorization</EM> request header.</P>

<H2><A NAME="ss17.17">17.17</A> <A HREF="FAQ.html#toc17.17">Interception on Linux with Squid and the Browser on the same box</A>
</H2>

<P>by Joshua N Pritikin
<PRE>
#!/bin/sh

iptables -t nat -F  # clear table

# normal transparent proxy
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j REDIRECT --to-port 8080

# handle connections on the same box (192.168.0.2 is a loopback instance)
gid=`id -g proxy`
iptables -t nat -A OUTPUT -p tcp --dport 80 -m owner --gid-owner $gid -j ACCEPT
iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 192.168.0.2:8080
</PRE>
</P>

<H2><A NAME="ss17.18">17.18</A> <A HREF="FAQ.html#toc17.18">Interception caching with an Alcatel OmnySwitch 7700</A>
</H2>

<P>by Pedro A M Vazquez</P>
<P>On the switch define a network group to be intercepted:
<PRE>
 policy network group MyGroup 10.1.1.0 mask 255.255.255.0
</PRE>
</P>
<P>Define the tcp services to be intercepted:
<PRE>
 policy service web80 destination tcp port 80 
 policy service web8080 destination tcp port 8080
</PRE>
</P>
<P>Define a group of services  using the services above:
<PRE>
 policy service group WebPorts web80 web8080
</PRE>
</P>
<P>And use these to create an intercept condition:
<PRE>
 policy condition WebFlow source network group MyGroup service group WebPorts
</PRE>
</P>
<P>Now, define an action to redirect the traffic to the host running squid:
<PRE>
 policy action Redir alternate gateway ip 10.1.2.3 
</PRE>
</P>
<P>Finally, create a rule using this condition and the corresponding action: 
<PRE>
 policy rule Intercept  condition WebFlow action Redir
</PRE>
</P>
<P>Apply the rules to the QoS system to make them effective
<PRE>
 qos apply
</PRE>
</P>
<P>Don't forget that you still need to configure Squid and Squid's
operating system to handle the intercepted connections.  See above
for Squid and OS-specific details.</P>


<HR>
<A HREF="FAQ-18.html">Next</A>
<A HREF="FAQ-16.html">Previous</A>
<A HREF="FAQ.html#toc17">Contents</A>
</BODY>
</HTML>