Amos Jeffries-2 wrote:
>
> On Wed, 2 Mar 2011 14:29:01 -0800 (PST), mbruell wrote:
>
>> Firewall policy grabs traffic from the client based on IP address,
>> and
>> forces it to our proxy through the wccp tunnel.
>
> "based on IP address" is very bad. Working TPROXY traffic coming out of
> squid will have the client IP address.
>
> Manipulation of the traffic MUST use measures other than IP to
> filter/route the traffic if both streams are possibly handled. The
> easiest ways are to use interface name or machine MAC/EUI address on the
> firewall and router. Packet MARKs, TOS or VPN marks are also available,
> but more complex to handle.
>
>
Okay - though I thought our wccp tunnel was taking care of that. The
firewall rule that grabs the machine's IP traffic only does so on the
interface facing the client. Once it's been grabbed, it's getting sent down
the gre tunnel.
> The following error crops up after about a minute of launching squid,
> and
> repeats every 10 sec:
> Unknown record type in WCCPv2 Packet (6)
Is this error meaningful?
Amos Jeffries-2 wrote:
>
>
> This is NAT interception, not TPROXY interception.
>
> The two are not compatible. NAT being obsoleted by TPROXY. Remove this
> rule.
>
>
Okay - I removed the rule, but there are still some other issues (it's still
not working).
So are the ip rules in mangle table all that is needed here?
Amos Jeffries-2 wrote:
>
> Since you have a mixup with NAT/TPROXY earlier also check that your
> http_port 3129 line only has the "tproxy" flag on it.
>
Double checked this - it was not misconfigured.
Should we be seeing traffic on the lo interface when it's all working
correctly? The packet count on lo is very low, and doesn't change when
trying to proxy the traffic.
Also - it looks like the tunnel is sending the traffic to the computer
running squid (wccp rx = 3.7 KB, but tx = o), but it's not getting anything
back from it to send to the client.
> Results of ifconfig show:
>
> eth0 Link encap:Ethernet HWaddr x
> inet addr:208.x.x.x Bcast:208.x.x.x Mask:255.255.255.224
> inet6 addr: x Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:3417 errors:0 dropped:0 overruns:0 frame:0
> TX packets:2613 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:431614 (431.6 KB) TX bytes:699823 (699.8 KB)
> Interrupt:18 Memory:d8020000-d8040000
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:1 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:88 (88.0 B) TX bytes:88 (88.0 B)
>
> wccp0 Link encap:UNSPEC HWaddr
> D0-48-47-70-30-30-30-30-00-00-00-00-00-00-00-00
> inet addr:208.x.x.x P-t-P:208x.x.x Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1
> RX packets:79 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:3792 (3.7 KB) TX bytes:0 (0.0 B)
>
Amos Jeffries-2 wrote:
>
> Its a game of "find the packets" now. Spec out the full path of where
> you think the packets should be going (in both directions) and
> spot-check whether or not they are there. The squid logs will show
> whether they are arriving on squids port. tcpdump and iptables logging
> can view other spots.
>
> Amos
>
Okay - thanks very much for your help!
-- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Client-timing-out-when-using-squid-as-tproxy-tp3243429p3333616.html Sent from the Squid - Users mailing list archive at Nabble.com.Received on Thu Mar 03 2011 - 15:59:00 MST
This archive was generated by hypermail 2.2.0 : Thu Mar 03 2011 - 12:00:02 MST