Re: [squid-users] transparent tproxy: routing issue or my own problem ?
From: Ming-Ching Tiew [EMAIL PROTECTED] I am using squid in a Linux box setting up as a bridge, and have set up ebtables and iptables following the documentation available on the Net :- ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6 \ --ip-destination-port 80 -j redirect --redirect-target ACCEPT iptables -t tproxy -A PREROUTING -i br0 -p tcp --dport 80 \ -j TPROXY --on-port 80 On a brief glance it seems it's working properly but upon detail investigation, there are some issues. I am looking for something more transparent. Any insight is much appreciated. I think I fixed the issue by changing the ebtables rule to :- ebtables -t broute -A BROUTING --logical-in br0 -p IPv4 --ip-protocol 6 \ --ip-destination-port 80 -j redirect --redirect-target DROP Note that subtle changes. With that I don't need to add routes and other shits. I would appreciate feedback from others to see if this is a better rule than the original one. Regards.
Re: [squid-users] transparent tproxy: routing issue or my own problem ?
fre 2007-07-06 klockan 09:41 +0800 skrev Ming-Ching Tiew: However, if there is a subnet B, which is connected to subnet A, via a router R, then all the machines inside subnet B will have problem getting the http reply packets but http request packets have no problem going out. Do your proxy have a return path route for subnet B? Then I added a route inside the Bridge/Squid S for the subnet B via router R, then the web request/reply problem is solved. Ah, you didn't.. You need routing for all sessions you intercept, or the proxy server won't know where to return traffic.. It seems then to me that the http reply ( source port 80 ) has also be directed ***INTO*** the Bridge/Squid S. Why is that so ? Why didn't the Bridge/Squid forward the reply packet to the other side of the interface ? I'd say that your ebtables rules is perhaps a bit too broad.. a packet matched by the ebtables redirect rule will be diverted from the bridge into the TCP/IP stack to be routed, NAT:ed etc.. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] transparent tproxy: routing issue or my own problem ?
I think I fixed the issue by changing the ebtables rule to :- ebtables -t broute -A BROUTING --logical-in br0 -p IPv4 --ip-protocol 6 \ --ip-destination-port 80 -j redirect --redirect-target DROP Note that subtle changes. With that I don't need to add routes and other shits. I would appreciate feedback from others to see if this is a better rule than the original one. Sorry false alarm. The new rule bypasses all traffic from squid, that's why it is working. Back to square ones. Need to work harder on it. :-(
Re: [squid-users] transparent tproxy: routing issue or my own problem ?
fre 2007-07-06 klockan 11:07 +0800 skrev Ming-Ching Tiew: I think I fixed the issue by changing the ebtables rule to :- ebtables -t broute -A BROUTING --logical-in br0 -p IPv4 --ip-protocol 6 \ --ip-destination-port 80 -j redirect --redirect-target DROP Should be ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6 \ -i eth0 --ip-source your.lan.network/mask \ --ip-destination-port 80 -j redirect --redirect-target ACCEPT with eth0 being the interface connected to your LAN, and your.lan.network/mask the IP network used on your LAN. Do NOT redirects networks for which you do not have routing configured, doing so will not work. If you are to use TPROXY then I'd recommend using the bridge-netfilter integration instead of ebtables. This because TPROXY needs to intercept the return traffic as well, not just lan-internet traffic. It's possible to add ebtables rules for this by doing rules inverse to the above. ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6 \ --ip-destination your.lan.network/mask \ --ip-source-port 80 -j redirect --redirect-target ACCEPT Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
