-----Original Message----- From: Amos Jeffries [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2008 9:43 PM To: Ritter, Nicholas Cc: Amos Jeffries; squid-dev@squid-cache.org Subject: RE: squid3HEAD/TPROXY: interception log entries
> Amos- > > Thanks for your reply. > > Ok...I think I am understanding what you are saying. Now translating > that to the situation at hand, I am not sure which route to take. I > switched my setting for http_port to: > > http_port 3128 tproxy intercept disable-pmtu-discovery=always > > Which I understand doesn't address the issue you commented below about > seperating intercept and tproxy traffic. If I take out the intercept, > I get an error on the client. >What error on the client? That sounds like a bug. tproxy option AKAIK should be independent. Maybe that is a bug >that need fixing. The error the client gets is: Connection to <server name Failed. The system returned: (99) Cannot assign requested address. It is recreateable with this one part of the specific app, it something related to server-side redirection. Doing a reload on the broswer makes the error go away. > I can't take tproxy out because that is what is being redirected via > iptables rules and provides the client IP preservation to the remote > site. >>Agreed. My belief is that all you should need is the 'tproxy' option. If thats failing, we need to find out why >>and fix it. Yup...I take take intercept keyword out and it doesn't work correctly. > I am confused as to how to seperate > what with where given incoming WCCP traffic from the router. >>I'll have to learn a little more about WCCP before I can answer that. I know the router redirects the traffic to the squid box on the GRE tunnel, then either a problem with my iptables rules or something else hits a snag of some kind. the tproxy rule is in the prerouting chain, so it gets the HTTP redirected traffic before it hits the GRE tunnel...if I understand things correctly. But I notice that the whole setup will not work correctly if the GRE tunnel is not there. The other odd thing is that the whole setup works regardless of if I allow incoming WCCP packets on 2048 or not, which I thought was a violation of the WCCP spec, or maybe just would prevent extra WCCP features from working. <snippet from followup> > Ooops...I should have added the wccp2_server_info setting from > squid.conf: > > wccp2_service_info 80 protocol=tcp flags=src_ip_hash priority=240 > ports=80 wccp2_service_info 90 protocol=tcp > flags=dst_ip_hash,ports_source priority=240 ports=80 </snippet> > > On the router I have wccp redirection rules as note on the squid wiki > (note: the squid box is 10.48.33.2, clients are 10.48.1.0/24): > > ip wccp 80 redirect-list 121 > ip wccp 90 redirect-list 121 > > interface FastEthernet0/1.1 > encapsulation dot1Q 1 native > ip address 10.48.1.1 255.255.255.0 > ip helper-address 10.2.5.101 > ip wccp 80 redirect in > ip wccp 90 redirect out > ! > interface FastEthernet0/1.33 > encapsulation dot1Q 33 > ip address 10.48.33.1 255.255.255.0 > ip wccp redirect exclude in > > > On the squid box I have TProxy and GRE related rules: > > TPROXY rules: > -A PREROUTING -p tcp -m socket -j DIVERT -A PREROUTING -p tcp -m tcp > --dport 80 -j TPROXY --on-port 3128 --on-ip 0.0.0.0 --tproxy-mark > 0x1/0x1 -A DIVERT -j MARK --set-mark 0x1 -A DIVERT -j ACCEPT > > GRE and WCCP rules: > -A INPUT -i gre0 -j ACCEPT > -A INPUT -i gre0 -j ACCEPT > -A INPUT -p gre -j ACCEPT > -A INPUT -i eth0 -p gre -j ACCEPT > -A FORWARD -j LocalFW > -A LocalFW -i lo -j ACCEPT > -A LocalFW -s 10.48.33.1/32 -p udp -m udp --dport 2048 -j ACCEPT > > Given what you are saying, am I to assuming correctly that my iptables > rules would need to be adjusted? I understand in principle that I > would need to create a redirection rule to squid on one port with > TPROXY, and another redirection/NAT/DNAT rule to a squid port with > intercept. Is this correct? >>Only if you wanted to use both. The one TPROXY rule(s) as you have should be enough. I think I must need both because leaving out the intercept keyword causes breakage, and this is what WCCP is for. >>What pops into my head here, without knowing the error your clients show is a feeling that some bit of the >>overall flow is playing nasty. >>Can you explain what the full traffic flow behavior is vs what should be? I agree, I will do a write up of the application and send it off on Monday. I have to deal with a power problem in a data center now and in to the weekend. Nick