RE: [squid-users] WCCP, Squid, and that darn PIX

It looks to me as if the anti-spoofing features of the PIX are dropping the
session as a spoofed attack. You probably just need to turn off the
anti-spoofing stuff on the firewall (or on the interface or for that
specific source, depending on how granular the PIX will allow you to be).
This is due to the fact that you are running in transparent mode and the
cache is forwarding the HTTP response as though the web server (ie
www.nasa.gov) is sending the traffic directly to the client..
"Cisco says that error comes up when a session starts on one interface, but
continues on another." Which is what is happening when the web server at
NASA or wherever sends the return traffic through the outside interface to
the "client" IP but of course the traffic is actually returned to the Squid
server and then the Squid server forwards it back to the firewall's dmz
interface (on it's way back to the client) and the firewall sees the same
incoming traffic (at least according to it's session DB) coming in a
different interface and assumes it is spoofing. If Cisco can't tell you how
to disable this feature, just put Squid in front of the firewall (or on the
inside interface, assuming your clients are there, then the fw would never
see the squid to client return traffic which should solve the issue... :)

Hope this helps..

Thanks,

--Tim

===============================================
Timothy M. Wolfe CCSE/NSA/CCNA
Sr. Security Engineer tim@ignw.com
InfoGroup Northwest 541.485.0957 x108
===============================================
 

-----Original Message-----
From: Joe Mailander [mailto:jmailand@lane.k12.or.us]
Sent: Wednesday, June 13, 2001 7:58 AM
To: squid-users@squid-cache.org
Subject: [squid-users] WCCP, Squid, and that darn PIX

I've got WCCP v. 1 working between my Cisco router (12.1(6)) and squid (2.4
stable 1 on freebsd 4.3 with the GRE patch applied.), works fine when
there's no firewall in the picture (squid, squidguard all do what they're
supposed to do, the mechanics of the process seem to be OK). Squid runs
along, everything is great.

Now, I'd like to put the squid box behind my PIX firewall. The squid box
doesn't have any parent/child etc. relationships with other caches, I'm
using it just for some squidguard filtering.

When I put squid behind the pix, the router sees the squid box and lets me
know it has a cache. So far so good. Fire up a web client on the inside
interface of my pix (the LAN in our building), go to page, hangs.

Looking at the PIX syslog entries I see:

   Jun 12 14:32:28 <dmz> Jun 12 2001 14:33:36: %PIX-1-106022: Deny tcp
connection spoof from <web_to> to <client_from> on interface dmz

where:
<dmz> - ip address on pix DMZ interface
<web_to> - ip address site we're going to (nasa.gov or whatever)
<client_from> - ip addr. of client

Cisco says that error comes up when a session starts on one interface, but
continues on another. So, for laughs I put the client machine off a spare
ethernet on the router running WCCP (no pix between client and router, but
pix remains between router and squid). No error as above, but the whole
process doesn't work; no items start appearing in the squid store.log, and
again the client hangs and eventually times out.

While testing, I opened any IP and any ICMP from the router to the squid
box, and anything originating on the DMZ should go out.

I did some tcpdumps looking at the GRE packets:

1) when squid and firewall on same segment (works):

16:40:14.365663 [router ip] > [squid ip]: gre-proto-0x883E (gre encap)
                          4500 0040 0024 0000 fe2f 3b56 a329 fac5
                          a329 3ffc 0000 883e 4500 0028 b300 4000
                          8006 58f2 a329 3bfe 9f79 703c 041c 0050
                          0009 bf61 cb42 cef3 5004 0000 62f6 0000
16:40:14.365786 [router ip] > [squid ip]: gre-proto-0x883E (gre encap)
                          4500 0040 0025 0000 fe2f 3b55 a329 fac5
                          a329 3ffc 0000 883e 4500 0028 b400 4000
                          8006 57f2 a329 3bfe 9f79 703c 041d 0050
                          0009 bf64 cb42 cef3 5004 0000 62f2 0000
etc.

2) squid inside firewall (doesn't work):

16:56:41.987373 [router-ip] > [squid-ip]: gre-proto-0x883E (gre encap)
                          4500 0048 0000 0000 fe2f 3d08 a329 fac5
                          a329 3e66 0000 883e 4500 0030 2085 4000
                          fe06 6d0f a329 3c54 9f79 703c c000 0050
                          7246 91fc 0000 0000 7002 8000 52a9 0000
                          0204 0564 0101 0101
16:56:42.661343 [router-ip] > [squid-ip]: gre-proto-0x883E (gre encap)
                          4500 0059 0001 0000 fe2f 3cf6 a329 fac5
                          a329 3e66 0000 883e 4500 0041 2086 4000
                          fe06 6cfd a329 3c54 9f79 703c c000 0050
                          7246 91fd 0000 0000 5004 0000 cd89 0000
                          7463 705f 636c 6f73 652c 2064 7572 696e
                          6720

I don't see any GRE fragmented packet errors in either case.

If anyone's had any success using WCCP across a pix to squid, I'd like to
hear what worked for you. Or, if it's just a bad idea to put squid behind
a firewall, I should probably know that too.

Thanks! I found lots of great setup info on this list when getting Squid
and WCCP set up initially, you people rock.

- Joe Mailander
Received on Thu Jun 14 2001 - 11:08:41 MDT