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. 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. I am confused as to how to seperate what with where given incoming WCCP traffic from the router. 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? 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. 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
