[tproxy] Squid with tproxy extra brief FAQ - take 2

Eduardo Schoedler eschoedler at viavale.com.br
Mon Mar 3 23:15:00 CET 2008

Just one thing I've forgot...
Why can't I download from inside my linux/tproxy/squid box ?

 # wget http://gentoo.osuosl.org/snapshots/portage-20080229.tar.bz2
--19:59:40--  http://gentoo.osuosl.org/snapshots/portage-20080229.tar.bz2
           => `portage-20080229.tar.bz2'
Resolving gentoo.osuosl.org...
Connecting to gentoo.osuosl.org||:80... failed: Connection
timed out.

--19:59:43--  http://gentoo.osuosl.org/snapshots/portage-20080229.tar.bz2
  (try: 2) => `portage-20080229.tar.bz2'
Connecting to gentoo.osuosl.org||:80...

Here's my ebtables rules:

Bridge chain: BROUTING, entries: 2, policy: ACCEPT
-p IPv4 -i eth1 --ip-proto tcp --ip-dport 80 -j redirect  --redirect-target
-p IPv4 -i eth0 --ip-proto tcp --ip-sport 80 -j redirect  --redirect-target

... and here my iptables rules:

target     prot opt source               destination
TPROXY     tcp  --  anywhere             anywhere            tcp dpt:http
TPROXY redirect

Any idea?

Thanks in advance.

Best Regards,

Eduardo Schoedler.

From: "Eduardo Schoedler" <eschoedler at viavale.com.br>
Subject: Re: [tproxy] Squid with tproxy extra brief  FAQ - take 2

Hey people!!! Good news!!!
It worked !!! \o/

I've installed the new patch tproxy-4.0.4-2.6.22 in kernel-2.6.22-r10 and
My problem was exactly the patch for squid-2.6.STABLE16.

So, how I sad, I've done it by hand, using the patch from
I've generated a patch file, so if everyone want's it, just contact me.

Thanks for all !!!
Sorry my bad english... =)

Best Regards,

Eduardo Schoedler.

From: nantenaina Tianarivo
Subject: Re: [tproxy] Squid with tproxy extra brief FAQ - take 2

I had this problem also when I patched my squid package. I didn't find any
link where you can get this patch as. For me, I have done manually all
changes described in this patch and it worked.

On jeu, 2008-02-28 at 08:58 -0300, Eduardo Schoedler wrote:
Hello nantenaina Tianarivo !!!

Thanks for the link.
But, I'm having some troubles to apply it, as you can see below.

In your link is another link, to get the the patch as an attachment.
I've tried it (without the html tags, of course), and did'nt work.

# cat squid-tproxy.patch | patch -p1
patching file src/comm.c
patch: **** malformed patch at line 7: {

Any ideas?


Best Regards,

Eduardo Schoedler.

From: nantenaina Tianarivo
Subject: Re: [tproxy] Squid with tproxy extra brief FAQ - take 2

I have tried the patch for IP_freebind proposed here
https://lists.balabit.hu/pipermail/tproxy/2007-December/000638.html and my
squid could work with the tproxy4.
Before that it loaded the tproxy2 when compiled with --enable-linux-tproxy

I hope it can help you.
On mer, 2008-02-27 at 14:33 -0300, Eduardo Schoedler wrote:
Thanks for the FAQ.

I'm using the (B) Version Tproxy 4.0.x.
However, I haven't found the patch for squid in the site

I'm using SQUID-2.6.17 with "--enable-linux-tproxy".
But this compile options activates suppor for tproxy2 instead tproxy4.0.x,
right ?
How can I found the patch ?

Thanks in advance!

Best Regads,

Eduardo Schoedler.

From: "Ming-Ching Tiew" <mingching.tiew at redtone.com>
Subject: [tproxy] Squid with tproxy extra brief  FAQ - take 2

1. There are at least 3 different versions of tproxy kernel patches.

    Each tproxy kernel patch is quite strongly tied to a kernel version,

   (A) Version Tproxy2
   For kernel 2.6.18
   URL: http://www.balabit.hu/downloads/files/tproxy/obsolete/

   (B) Version Tproxy 4.0.x
    For kernel 2.6.22
    URL: http://www.balabit.hu/downloads/files/tproxy/

   (C) Version Tproxy-4.1.0
    For kernel 2.6.25
    URL: The "official website" is for kernel <=2.6.24

     but the actual version of tproxy 4.1 for 2.6.25 is here:

    The kernel patch might work with nearby kernel versions, for example,
    tproxy2 might work with kernel 2.6.19; however it will not work
    will kernel 2.6.22 ( unless you port it ).

2. Do not confuse tproxy kernel patch mentioned above with
    squid user-space patches.

    So far the Squid ( 3.0 and 2.6 ) is only supporting on tproxy2 - the
    userspace code is integrated.

    If you managed to compile Squid without changing the source,
    perhaps with only minor changes in header files, meaning you are
    likely either did not successfully link in tproxy support or at best it
    is using tproxy2, and it will not work with tproxy-4.0.x and
    tproxy-4.1.0 kernel counterpart.

    However, if you patch the squid source, you should be able
    to get squid to work with tproxy-4.0.x and tproxy-4.1.0.

    You can look through the archive of this maillist to look at how
    to port squid versions to support tproxy-4.0.x and tproxy-4.1.0.
    Most of the patches floating around are not fully satisfactory,
    but it could work, at least; but perhaps it will require you to have
    some programming knowledge.

    Here maybe a good start :-

3. All the tproxy kernel patches are not compatible with one another.
    Each requires it's own way of setup and usage. So before doing
    anything, check if you have gotten the correct info/tproxy

    These are some of the info :-

     (A) Version Tproxy2
     The Squid documentation recommends this :-

           ebtables -t broute -A BROUTING -p ipv4 --ip-protocol tcp \
                 --ip-destination-port 80 -j redirect --redirect-target

      This rule will "broute" bridge traffic from br0 to netfilter.

      The iptables rule will bring http traffic into local process  :-

             iptables -t tproxy -A PREROUTING -i br0 -p tcp --dport 80 \
              -j TPROXY --on-port 3128

      To get SNAT working for tproxy2, there is a need for double NAT,
       and here was the discussion and patch :-


      (B) Version tproxy-4.0.x
      Requires additional patches for SNAT and FWMARK.
      Some hurdles with bridge.

      Bridge problem is to do with packets must be marked PACKET_HOST when
      heading for br0 as discussed in this tproxy maillist. There have been
      people saying they will post the patch for it  but yet to date, there
is none.

     This problem can be worked around by brouting the traffic into
     the real devices instead of br0 :-

      ebtables -t broute -A BROUTING -i $INSIDE_DEV -p ipv4 \
              --ip-protocol tcp --ip-destination-port 80 \
               -j redirect --redirect-target DROP
      ebtables -t broute -A BROUTING -i $OUTSIDE_DEV -p ipv4 \
        --ip-protocol tcp --ip-source-port 80 \
         -j redirect --redirect-target DROP

      Please note for real interfaces, it's  redirect-target DROP and
      not redirect-target ACCEPT, while doing it on br0, it's
      redirect-target ACCEPT !

      Remember to adjust your iptables rule accordingly since now
      packets entering and leaving real  interfaces instead of br0.

      Example :-

       iptables -t tproxy -A PREROUTING -i $INSIDE_DEV \
             -p tcp --dport 80 -j TPROXY --on-port 3128

      For tproxy-4.0.3 remember to apply the additional kernel patches
      mentioned in this maillist or else the kernel will panic accessing
      null pointer.

      (C) Version tproxy-4.1.0
      The ebtables/bridge notes above is equally applicable. However
      the iptables rules are totally different.

      Something like this will be required :-

           iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \
                  --tproxy-mark 0x1/0x1 -on-port 3128
            iptables -t mangle -N DIVERT
            iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
            iptables -t mangle -A DIVERT -j MARK --set-mark 1
            iptables -t mangle -A DIVERT -j ACCEPT

            ip rule add fwmark 1 lookup 100
            ip route add local dev lo table 100

More information about the tproxy mailing list