> 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. > 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. > 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. <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. > > Thanks in advance for any help. I apologize if this discussion should be > on the squid-users list, I assumed this list was the place given it was > squid3HEAD. It's okay. Either way. 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? Amos > > Nick > > > -----Original Message----- > From: Amos Jeffries [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 24, 2008 12:05 AM > To: Ritter, Nicholas > Cc: [email protected] > Subject: RE: squid3HEAD/TPROXY: interception log entries > >> >> I should have added some specifics...here are the log items in >> cache.log: >> >> 2008/07/23 13:35:34| IPInterception.cc(171) NetfilterTransparent: NF >> getsockopt(IP_TRANSPARENT) failed: (92) Protocol not available >> 2008/07/23 13:36:37| IPInterception.cc(137) NetfilterInterception: NF >> getsockopt(SO_ORIGINAL_DST) failed: (11) Resource temporarily >> unavailable > > These can often be cleared up by correct use of 'intercept' and 'tproxy' > options in http_port. The old 'transparent' option is deprecated and > will to be backward-compatible, turn both on when often only one lookup > type is needed on that port. > >> >> ....and occasionally the client browser sees an error page from squid >> stating a connection to the server failed, and the system returns a >> "(99) Cannot assign requested address" > > This may be related to the above. If a tproxy receiving port is also > used for DNAT/REDIRECT reception the tproxy kernel sub-system may not > have records to correctly handle the apparent client address. > > The getsockopt() failures should not be a problem, just annoying. > The assign failure, may be a problem. Squid will use its normal outgoing > address I think in those cases. But I'm not certain on the network > routing behavior when transparent squid become visible. > > To solve both the the above. I recommend using seperate http_port's to > receive each type of traffic and setting specific 'intercept' or > 'tproxy' > options to match the expected traffic types. > > Amos > > > > >
