On Wed, 2 Mar 2011 14:29:01 -0800 (PST), mbruell wrote:
> Ubuntu server 10.04 with 2.6.37, 8 gb of ram, libcap2 2.20-1,
> iptables
> 1.4.10, squid 1.3.10. The machine is in the dmz, but will be proxying
> local
> traffic. We're trying to use wccp to tunnel traffic. According to
> diagnostic
> tests on our firewall, the tunnel is up and working.
>
> 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.
>
> However, we're having a few issues. The client can't browse.
>
> The following error crops up after about a minute of launching squid,
> and
> repeats every 10 sec:
> Unknown record type in WCCPv2 Packet (6)
>
> The results of: sudo iptables -t nat -L -v
>
> Chain PREROUTING (policy ACCEPT 16 packets, 2936 bytes)
> pkts bytes target prot opt in out source
> destination
> 0 0 REDIRECT tcp -- wccp0 any anywhere
> anywhere
> tcp redir ports 3129
This is NAT interception, not TPROXY interception.
The two are not compatible. NAT being obsoleted by TPROXY. Remove this
rule.
>
> The results of: sudo iptables -t mangle -L -v
>
> Chain PREROUTING (policy ACCEPT 435 packets, 160K bytes)
> pkts bytes target prot opt in out source
> destination
> 2664 202K DIVERT tcp -- any any anywhere
> anywhere
> socket
> 79 3792 TPROXY tcp -- any any anywhere
> anywhere
> tcp dpt:www TPROXY redirect 0.0.0.0:3129 mark 0x1/0x1
>
<snipped empty tables>
>
> Chain DIVERT (1 references)
> pkts bytes target prot opt in out source
> destination
> 2664 202K MARK all -- any any anywhere
> anywhere
> MARK set 0x1
> 2664 202K ACCEPT all -- any any anywhere
> anywhere
That looks okay.
Since you have a mixup with NAT/TPROXY earlier also check that your
http_port 3129 line only has the "tproxy" flag on it.
>
> 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)
>
> Does anyone have any ideas about where to go next?
>
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
Received on Wed Mar 02 2011 - 23:07:48 MST
This archive was generated by hypermail 2.2.0 : Thu Mar 03 2011 - 12:00:01 MST