On Tue, 15 Jun 2010 13:37:48 -0500, Luis Daniel Lucio Quiroz
<luis.daniel.lucio_at_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
Received on Wed Jun 16 2010 - 03:45:51 MDT
This archive was generated by hypermail 2.2.0 : Wed Jun 16 2010 - 12:00:03 MDT