dump the packet at eth0 and eth1. When traffic comes into eth1 i called 'old packet', squid should forward the 'new' packet to eth0. Check 'the new' packet and 'old packet', look at source ip and destination ip. it should same source and destination ip. if this is correct, Check the reply packet from internet, Also check in cache.log, any error or not ? if you test, you should test from another computer that reside below the bridge. if doing wget, dont set the proxy in parameter, because you are using TPROXY. 2010/4/2 Kurt Sandstrom <sandmanaz@xxxxxxxxx>: > You are correct in that it's a routing issue... > > I have network -> eth1(no ip bridged)->eth0(no ip bridged)-> gateway(router) > the eth1 and eth0 interfaces have a br0 assigned. > > when I assign the bridge interface I use the following for routing: > > ifconfig br0 xxx.xxx.xxx.xxx netmask 255.255.0.0 up #routable IP > route add default gw xxx.xxx.xxx.xxx dev br0 #gateway > > Then I use: > > ebtables -t broute -A BROUTING -i eth1 -p ipv4 --ip-proto tcp > --ip-dport 80 -j redirect --redirect-target DROP > ebtables -t broute -A BROUTING -i eth0 -p ipv4 --ip-proto tcp > --ip-sport 80 -j redirect --redirect-target DROP > iptables -t mangle -N DIVERT > iptables -t mangle -A DIVERT -j MARK --set-mark 1 > iptables -t mangle -A DIVERT -j ACCEPT > iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT > iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY > --tproxy-mark 0x1/0x1 --on-port 3129 > cd /proc/sys/net/bridge/ > for i in * > do > echo 0 > $i > done > unset i > > and I think this is where the problem resides but may be wrong: > > ip rule add fwmark 1 lookup 100 > ip route add local 0.0.0.0/0 dev lo table 100 > > My iptables are being traversed and I can see the counters increasing > in the PREROUTING chain TPROXY target > > 2 things I may try this evening... grab tcp traffic from eth0 and br0 > to see if redirected port 3129 is being routed out of the system > instead of to the localhost. Then try (a shot in the dark) changing: > > ip route add local 0.0.0.0/0 dev lo table 100 to ip route add local > 0.0.0.0/0 dev br0 table 100 > > If you have any other ideas then please let me know... I know I'm > close and the help received here has really helped > > Kurt > > > > > > > > > > > > I did a couple tests on the system last night. If wget > 0.0.0.0:3129(tproxy port) then I see traffic in the squid access.log. > I recieve a gateway not found error > > 2010/4/2 johan firdianto <johanfirdi@xxxxxxxxx>: >> Have you setup ebtables to drop packet, >> ebtables -t broute -A BROUTING -i $CLIENT_IFACE -p ipv4 --ip-proto tcp >> --ip-dport 80 -j redirect --redirect-target DROP >> ebtables -t broute -A BROUTING -i $INET_IFACE -p ipv4 --ip-proto tcp >> --ip-sport 80 -j redirect --redirect-target DROP >> >> second hint, >> route all your network/netmask ip address to dev bridge, >> example: >> ip route add 192.168.100.0/24 dev br0 >> ip route add 10.0.0.0/8 dev br0 >> BUT, if you have router again below your bridge, you should define >> routing in your bridge. >> Because your box actually act as bridge and router. Act as router >> because you intercepted trafic to squid. So, when kernel will forward >> the traffic to network, they must know which interface to forward. >> >> >> >> 2010/4/2 Henrik Nordström <henrik@xxxxxxxxxxxxxxxxxxx>: >>> tor 2010-04-01 klockan 13:43 -0700 skrev Kurt Sandstrom: >>>> The bridging is working just not redirecting to the squid. I can see >>>> the counters increment for port 80 but nothing on the squid side. >>> >>> TPROXY has some quite peculiar requirements, and the combination with >>> bridgeing makes those even more complex. And is why I ask that you first >>> verify your TPROXY setup in routing mode before trying the same in >>> bridge mode. It's simply about isolating why things do not work for you >>> instead of trying to guess if it's the bridge-iptables integration, >>> ebtables, iptables TPROXY rules, routing, or whatever.. >>> >>> Regards >>> Henrik >>> >>> >> >
