Re: Squid + Tproxy + Bridge on Kernel 2.6.34 - Workaround

[Amos Jeffries <squid3@treenet.co.nz>]

On Tue, 15 Jun 2010 13:37:48 -0500, Luis Daniel Lucio Quiroz
<luis.daniel.lucio@gmail.com> wrote:
> Le mardi 25 mai 2010 23:21:39, senthilkumaar2021 a écrit :
>> Hi,
>> 
>> Squid + Tproxy + Bridge Setup on latest kernel - version 2.6.34
>> 
>> I had followed all the steps that had given in the
>> http://wiki.squid-cache.org/Features/Tproxy4
>> 
>> Kernel - 2.6.34
>> iptable - 1.4.8
>> ebtable - 2.0.9-1
>> 
>> But clients were unable to browse and no errors in cache.log. Error -
>> Network Unreachable. The error had returned by browser not squid proxy.
>> 
>> Workaround :-
>> 
>> After adding the following rules, clients are able to browse.
>> 
>> # ip rule add dev <device name> fwmark 1 lookup 100
>> 
>> example
>> 
>> # ip rule add dev eth0 fwmark 1 lookup 100
>> 
>> NOTE : Repeat the above for each interface except " lo "
>> 
>> Source -
>> https://lists.balabit.hu/pipermail/tproxy/2010-January/001212.html
>> 
>> Based on the above source this issue had identified on kernel version -
>> 2.6.32. But still not yet fixed.
>> 
>> I have CC ed this mail to netfilter mailing lists also.
>> 
>> Hope this helps
>> 
>> Thanks,
>> Senthil
> 
> I was about to  ask
> if this is fixed in 2.6.33+
> 
> or shall i stay in 2.6.31.x

From the Squid side;
 I have not seen any concrete evidence that this problem was anything more
than a configuration mixup.

This "fix" is to configure routing tables so that packets the bridge stack
sends to the routing stacks (ebtables ... -j DROP) actually get routed to
Squid. Our wiki demo uses 127.0.0.1 and the lo interface, it seems like the
reporter was using a global IP and only had to configure a global
interfaces' routing.

The other two older reporters have been suspiciously silent on the lists
since the same bridge/router interaction was mentioned.

Amos