On Tue, 15 Jun 2010 13:37:48 -0500, Luis Daniel Lucio Quiroz <luis.daniel.lucio@xxxxxxxxx> 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
