Re: [squid-users] yahoo mail problem with tproxy (squid 3.1.19, kernel 3.2.21)

On 7/21/2012 6:01 AM, Ming-Ching Tiew wrote:
>
>
> ----- Original Message -----
>> From: Eliezer Croitoru <eliezer_at_ngtech.co.il>
>>
>> so what you just need for ebtables is two rules:
>> all packets the are destined to the web om port 80.. route them into the machine... later will be intercepted by tproxy > so:
>> ebtables -t broute -A BROUTING -i eth0 -p ipv4 --ip-protocol tcp \ --ip-destination-port 80 -j redirect --redirect-target DROP
>
>> and every packet that comes from the internet from port 80 (web server) should be always get to the proxy as it's an > answer to squid request either tproxy or intercept.
>> the only difference with intercept mode is that:
>> the packet that comes back from the internet destination is the proxy and on any case the bridge will send it to the > proxy.
>
>> so to intercept web answers to the proxy you need the rules:
>> ebtables -t broute -A BROUTING -i eth1 -p ipv4 --ip-protocol tcp \
>> --ip-source-port 80 -j redirect --redirect-target DROP
>>
>> and that is it for the bridge.
>
> Your rules are essentially the same as mine and I don't see how it that different,
> maybe I am just missed the point.
>
>
> The reason you see many more rules than is needed because I want to make them
> the connection symmetric so that it does not matter which ethX is the upstream,
> and which is the down stream, ie whichever port you plug into it will still work.
>
> And I have specifically confirmed that the other two additional rules have no traffic.
>
they indeed are not suppose to fail your setup but it's not suppose to
be symmetric with tproxy.
the idea of the bridge is that you have clients side and external side
that you abuse both.

if you make it this way for a purpose it's another story.
i would say that the result can show some really nasty issue you are
having in the network level and ebtables+switch is the basic thing to check.
i will try to dump the tcp sessions on the interfaces using:
tcpdump -i any -X -s0 -n port 80 -w test.pcap

i will be happy to look into the packets to see if there is a clue in
them saying something about the "zero reply".

to make sure it's not squid issue try to install the rpm of squid 3.2
http://pkgs.org/fedora-16/fedora-i386/squid-3.2.0.12-1.fc16.i686.rpm.html

i have tested it on fedora 15-16 and still the same result that it works
both on 3.1.X and 3.2.X.

you can try to play with stp on\off on the bridge for case of packets
getting lost somewhere by STP filters.

Regards,
Eliezer

-- 
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il