Hi
The tproxy setup in bridge mode worked well as per in wiki squid till
the kernel version 2.6.30.xx
When we tested tproxy in bridge mode for kernels greater than
2.6.33.xx(2.6.34 also).
The tproxy was not working.when the following workaround was used the
tproxy was working fine.
# 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 "
and also
echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/br0/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
echo 1 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 1 > /proc/sys/net/ipv4/conf/eth0/send_redirects
We suspect the problem was not in squid and it is related to net filter.
Regards
senthil
Amos Jeffries wrote:
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
