Re: [squid-users] Squid - WCCP and ASA

Parvinder Bhasin wrote:
> Amos,
>
> Is there any compilation option that I am missing to make squid
> transparent??? maybe that's what's missing?. This is the 3.0 release.
>

I'm not sure if you are missing it or not. But every OS and firewall
combination needs the matching one of these to perform the right NAT
lookups:
   --enable-linux-netfilter
   --enable-ipf-transparent
   --enable-ipfw-transparent
   --enable-pf-transparent
   --enable-linux-tproxy (v2.2 only)

In 3.0 only one of those at a time will work.

Amos

> -Parvinder Bhasin
>
> On Jun 17, 2009, at 8:16 AM, Amos Jeffries wrote:
>
>> Parvinder Bhasin wrote:
>>> Amos,
>>> The tunnel is actually between the ASA and WCCP enabled squid.
>>
>> No tunnel is between ASA and the squid box Operating System.
>>
>> Squid itself has nothing to do with the tunnel. Squids only concern is
>> that the packets are arriving via some interception method. Thus the
>> src/dst IPs are a bit strange and it needs "transparent" or
>> "intercept" http_port option to handle.
>>
>>
>>> All the examples on squid-cache site as well as googling this issue
>>> points to creating a tunnel like this. Are you saying I don't need
>>> tunnel??? external ip???
>>
>> No you still need the tunnel. But I think assigning localhost-only
>> address to it may be a bad thing.
>>
>> The other tunnels I know about all need an IP the firewall device can
>> send to. Try without it to see if our packets start appearing.
>>
>>
>>> the squid box has an internal interface and is not connected to the
>>> internet directly.
>>
>> There are three categories of traffic interface:
>> WAN - Internet facing
>> LAN - local network facing
>> localhost - not even getting past the NIC onto the wire.
>>
>>> The squid box itself goes out the ASA and fetches the pages.
>>> Basically its NATed.
>>
>> Can you trace the packets as far as reaching Squid and starting their
>> way out again though?
>> If so the tunnels etc are fine. But the routing exemption to allow for
>> Squid box connections out through the router may be whacked.
>>
>> Amos
>>
>>> -Parvinder Bhasin
>>> On Jun 16, 2009, at 5:51 PM, Amos Jeffries wrote:
>>>> On Tue, 16 Jun 2009 16:49:56 -0700, Parvinder Bhasin
>>>> <parvinder.bhasin_at_gmail.com> wrote:
>>>>> I have setup of squid ..which was compiled with --enable-delay-pools
>>>>> option. Works really well but without WCCP.
>>>>> I enabled WCCP support in the squid config and also enabled wccp
>>>>> support on my ASA. Setup GRE tunnel etc.
>>>>> For my testing purpose I am only having ONE client IP go through
>>>>> WCCP. The problem is I am able to see that client on the GRE1
>>>>> interface (the requests) of the proxy server but that client is not
>>>>> getting anything back reply back. Do I need anything in iptables to
>>>>> allow etc??? do I need to compile with some transparent support?? if
>>>>> so which one would I use for ASA?
>>>>>
>>>>> Any help is highly appreciated.
>>>>>
>>>>>
>>>>> Here is part of my config:
>>>>>
>>>>> http_port 3128 transparent
>>>>>
>>>>> wccp2_router 192.168.100.250
>>>>> wccp_version 4
>>>>> wccp2_forwarding_method 1
>>>>> wccp2_return_method 1
>>>>> wccp2_service standard 0
>>>>>
>>>>> Additionally here is what I did to setup tunnel:
>>>>>
>>>>> modprobe ip_gre
>>>>> iptunnel add gre1 mode gre remote $ASA_IP local $LOCAL_IP dev eth0
>>>>> ifconfig gre1 inet 127.0.0.2 netmask 255.255.255.0 up
>>>>>
>>>>
>>>> IIRC localhost IDs 127.0.0.0/8 are hardware-limited to only be
>>>> usable for
>>>> traffic internal to the box.
>>>> If WCCP is going on a tunnel it will likely need an externally
>>>> visible IP
>>>> for the router to send to.
>>>>
>>>>> echo 1 > /proc/sys/net/ipv4/ip_forward
>>>>> echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
>>>>> echo 0 > /proc/sys/net/ipv4/conf/default/rp_filter
>>>>> echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
>>>>> echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
>>>>> echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter
>>>>> echo 0 > /proc/sys/net/ipv4/conf/gre1/rp_filter
>>>>>
>>>>> iptables -t nat -A PREROUTING -i gre1 -p tcp -m tcp --dport 80 -j
>>>>> REDIRECT --to-port
>>>>> 3128
>>>>>
>>>>> I do see the RX counter going up but not the TX on gre1:
>>>>>
>>>>> gre1 Link encap:UNSPEC HWaddr C0-A8-64-CF-B7-BF-C8-
>>>>> C2-00-00-00-00-00-00-00-00
>>>>> inet addr:127.0.0.2 P-t-P:127.0.0.2 Mask:255.255.255.0
>>>>> UP POINTOPOINT RUNNING NOARP MTU:1476 Metric:1
>>>>> RX packets:1559 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:83432 (81.4 KiB) TX bytes:0 (0.0 b)
>>>>>
>>>>> Here is tcpdump output:
>>>>>
>>>>> [root_at_squidnclamav etc]# tcpdump -i gre1 host 192.168.100.175 and port
>>>>> not ssh
>>>>> tcpdump: WARNING: arptype 778 not supported by libpcap - falling back
>>>>> to cooked socket
>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>>> decode
>>>>> listening on gre1, link-type LINUX_SLL (Linux cooked), capture size 96
>>>>> bytes
>>>>> 14:13:37.615862 IP 192.168.100.175.52257 > cf-in-f99.google.com.http:
>>>>> S 3689381709:3689381709(0) win 65535 <mss 1460,sackOK,eol>
>>>>> 14:13:45.524999 IP 192.168.100.175.52256 >
>>>>> bs2.ads.vip.sp1.yahoo.com.http: S 2516726129:2516726129(0) win 65535
>>>>> <mss 1460,sackOK,eol>
>>>>> 14:13:45.525001 IP 192.168.100.175.52255 >
>>>>> bs2.ads.vip.sp1.yahoo.com.http: S 878462413:878462413(0) win 65535
>>>>> <mss 1460,sackOK,eol>
>>>>> 14:13:45.525002 IP 192.168.100.175.52254 >
>>>>> bs2.ads.vip.sp1.yahoo.com.http: S 1528706489:1528706489(0) win 65535
>>>>> <mss 1460,sackOK,eol>
>>>>> 14:13:45.525003 IP 192.168.100.175.52253 >
>>>>> bs2.ads.vip.sp1.yahoo.com.http: S 1578413587:1578413587(0) win 65535
>>>>> <mss 1460,sackOK,eol>
>>>>> 14:13:47.427509 IP 192.168.100.175.52252 >
>>>>> mc2b.mail.vip.re1.yahoo.com.http: S 3796070861:3796070861(0) win 65535
>>>>> <mss 1460,sackOK,eol>
>>>>> 14:13:47.886251 IP 192.168.100.175.52259 >
>>>>> f1.www.vip.sp1.yahoo.com.http: S 1111547104:1111547104(0) win 65535
>>>>> <mss 1460,nop,wscale 3,nop,nop,timestamp 322113293 0,sackOK,eol>
>>>>> 14:13:48.127001 IP 192.168.100.175.52260 > hp-core.ebay.com.http: S
>>>>> 357937093:357937093(0) win 65535 <mss 1460,nop,wscale
>>>>> 3,nop,nop,timestamp 322113295 0,sackOK,eol>
>>>>> 14:13:48.829652 IP 192.168.100.175.52259 >
>>>>> f1.www.vip.sp1.yahoo.com.http: S 1111547104:1111547104(0) win 65535
>>>>> <mss 1460,nop,wscale 3,nop,nop,timestamp 322113302 0,sackOK,eol>
>>>>> 14:13:49.029600 IP 192.168.100.175.52260 > hp-core.ebay.com.http: S
>>>>> 357937093:357937093(0) win 65535 <mss 1460,nop,wscale
>>>>> 3,nop,nop,timestamp 322113304 0,sackOK,eol>
>>>>> 14:13:49.820922 IP 192.168.100.175.52259 >
>>>>> f1.www.vip.sp1.yahoo.com.http: S 1111547104:1111547104(0) win 65535
>>>>> <mss 1460,nop,wscale 3,nop,nop,timestamp 322113312 0,sackOK,eol>
>>>>> 14:13:50.030914 IP 192.168.100.175.52260 > hp-core.ebay.com.http: S
>>>>> 357937093:357937093(0) win 65535 <mss 1460,nop,wscale
>>>>> 3,nop,nop,timestamp 322113314 0,sackOK,eol>
>>
>>
>> --
>> Please be using
>> Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
>> Current Beta Squid 3.1.0.8
>

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
   Current Beta Squid 3.1.0.8