Re: WCCP / no return traffic on gre interface

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: WCCP / no return traffic on gre interface

Nick Ellson

Hi Henrik,

I caught this thread as I was fighting the same issue, and this dialogue got me
much farther. But not quite there so i have a question if you do not mind.

I have a Cisco 1841 doing wccpv2 with an ACL that, for now, trap only my wifi
laptops web traffic on the DSL egress BVI1 interface. Squid is a Gentoo Linux
box on a 10.0.0.20/24 address, off FastEtherenet0/0.1. My Wifi Station is
10.0.2.10/24 off FastEtherenet0/0.5.

Squid listening on port 3128 transparent, iptables REDIRECT from 80 to 3128.
wccp0 gre tunnel is up and shows traffic recieved from the router.

Squid works great as I have firefox manually using 10.0.0.20 port 80 as a
proxy, so my iptables redirect is doing it's job, and Squid is happy as a
proxy.

When I run IE7 on the same laptop with no proxy, I see my router catch it, and
send ther request to my proxy. The eth0/wccp0 port has it come in (tshark -i
wccp0 shows the web request, tshark -i eth0 -R ip proto gre shows the gre
traffic of the same)

But Squid in debug mode shows no hit to the proxy server process.

I suspect that the WCCPv2 is working, but the traffic is not making it to Squid
from the end of the GRE tunnel.

Debug from router:

WCCP-PKT:S00: Received valid Here_I_Am packet from 10.0.0.20 w/rcv_id 00000B48
WCCP-PKT:S00: Sending I_See_You packet to 10.0.0.20 w/ rcv_id 00000B49
WCCP-PKT:S00: Received valid Here_I_Am packet from 10.0.0.20 w/rcv_id 00000B49
WCCP-PKT:S00: Sending I_See_You packet to 10.0.0.20 w/ rcv_id 00000B4A

Debug ip packet (permit gre any any)

IP:  s=222.222.222.222 (FastEthernet0/0.5), d=10.0.0.20 (FastEthernet0/0.1),
IP:  g=10.0.0.20, len 80, forward, proto=47
IP:  s=222.222.222.222 (FastEthernet0/0.5), d=10.0.0.20 (FastEthernet0/0.1),
IP:  g=10.0.0.20, len 80, forward, proto=47

My router has a loopback of 222.222.222.222 so I would know it easily in tunnel
config. The real outside IP it was using was 209.162.205.230 on BVI1 and that
is where the "ip wccp web-cache redirect out" command lives.

A sniff on my proxy server, as I have IE7 do a google search:

goonie ~ # tshark -R gre
Capturing on eth0
   8.212647 mater.nickellson.com -> po-in-f147.google.com TCP 2087 > http [SYN]
Seq=0 Len=0 MSS=1260 WS=0
  11.218921 mater.nickellson.com -> po-in-f147.google.com TCP 2087 > http [SYN]
Seq=0 Len=0 MSS=1260 WS=0
  17.255232 mater.nickellson.com -> po-in-f147.google.com TCP 2087 > http [SYN]
Seq=0 Len=0 MSS=1260 WS=0

This is how I am surmizing WCCPv2 is OK, as I get the GRE redirect.

Squid cache.log under debug:

2007/05/19 15:31:37| wccp2HereIam: sending to service id 0
2007/05/19 15:31:37| Sending HereIam packet size 144
2007/05/19 15:31:37| Incoming WCCPv2 I_SEE_YOU length 132.
2007/05/19 15:31:37| Complete packet received
2007/05/19 15:31:37| Incoming WCCP2_I_SEE_YOU Received ID old=3039 new=3040.
2007/05/19 15:31:37| Cleaning out cache list
2007/05/19 15:31:37| checking cache list: (1400000a:1400000a)
2007/05/19 15:31:37| Change not detected (5 = 5)

I think I have followed the bunny trail pretty far here and I wold love some
advice on how to debug this further. How can I see between the redirect packet
landing on eth0 from the wccp0 tunnel to why iptables never gets it to squid?

iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
ACCEPT     0    --  anywhere             10.0.2.0/24
REDIRECT   tcp  --  anywhere             anywhere            tcp dpt:http redir
ports 3128
ACCEPT     0    --  anywhere             10.0.0.0/24
REDIRECT   tcp  --  anywhere             anywhere            tcp dpt:http redir
ports 3128

ip addr show wccp0
4: wccp0@eth0: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue
      link/gre 10.0.0.20 peer 222.222.222.222
      inet 10.0.0.20/32 scope global wccp0

Nick



--
Nick Ellson
Dad
CCDA, CCNP, CCSP, CCAI,
MCSE 2000, Security+, Network+
Network Hobbyist, VFR Private Pilot.

Reply | Threaded
Open this post in threaded view
|

Re: WCCP / no return traffic on gre interface

Nicolás Ruiz-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nick Ellson wrote:

> I think I have followed the bunny trail pretty far here and I wold love
> some advice on how to debug this further. How can I see between the
> redirect packet landing on eth0 from the wccp0 tunnel to why iptables
> never gets it to squid?
>
> iptables -t nat -L
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     0    --  anywhere             10.0.2.0/24
> REDIRECT   tcp  --  anywhere             anywhere            tcp
> dpt:http redir ports 3128
> ACCEPT     0    --  anywhere             10.0.0.0/24
> REDIRECT   tcp  --  anywhere             anywhere            tcp
> dpt:http redir ports 3128

I think the PREROUTING destination is not 10.0.2.0/24 or 10.0.0.0/24.
PREROUTING would see the decapsulated packet, so it would see the real
destination.

My iptables are

iptables -A PREROUTING -i wccp1 -p tcp -m tcp --dport 80 -j REDIRECT \
  --to-ports 3128
iptables -A PREROUTING -i wccp1 -p tcp -m tcp --dport 8000 -j REDIRECT \
  --to-ports 3128
iptables -A PREROUTING -i wccp1 -p tcp -m tcp --dport 8080 -j REDIRECT \
  --to-ports 3128


>
> ip addr show wccp0
> 4: wccp0@eth0: <POINTOPOINT,NOARP,UP,10000> mtu 1476 qdisc noqueue
>      link/gre 10.0.0.20 peer 222.222.222.222
>      inet 10.0.0.20/32 scope global wccp0
>
> Nick
>
>
>

- --
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
- --
Juan Nicolás Ruiz    | Corporación Parque Tecnológico de Mérida
                     | Centro de Cálculo Cientifico ULA
[hidden email]       | Avenida 4, Edif. Gral Masini, Ofic. B-32
+58-(0)274-252-4192  | Mérida - Edo. Mérida. Venezuela
PGP Key fingerprint = CDA7 9892 50F7 22F8 E379  08DA 9A3B 194B D641 C6FF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFGT6dhmjsZS9ZBxv8RAtQUAJdMrKVyw1rUozLJqlO5lMGoRPrrAJ9CXcYL
5HbNeNAxzk7pqXVgOmrpUA==
=1ox6
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: WCCP / no return traffic on gre interface

Nick Ellson
Hi Nicolas,

I was using this WIKI to configure, and thought the same thing you did..
would not my destination be anything BUT my local net? Then at the end of
this WIKI there is a guy that has my type of set-up.

"Interception Caching with Linux 2.6.18, ip_gre, Squid-2.6 and cisco IOS
12.4(6)T2 by ReubenFarrelly"

http://wiki.squid-cache.org/SquidFaq/InterceptionProxy

So I tried the ! <my net> approach, though i noticed he used DNAT.. Not=20
sure why.  Anyway, I get hits, but still nothing into Squid.

iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 2968 packets, 969K bytes)
   pkts bytes target     prot opt in     out     source               destination
     64  3328 DNAT       tcp  --  wccp0  any     10.0.0.0/16         !10.0.0.0/16         tcp dpt:http to:10.0.0.20:3128

The counter only climbs when I try to surf from IE7. So it's getting hit.

I want to try yours now and see what happens.

iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 5763 packets, 1846K bytes)
  pkts bytes target     prot opt in     out     source               destination
    12   624 REDIRECT   tcp  --  wccp0  any     anywhere             anywhere            tcp dpt:http redir ports 3128


Hrmmmm, got hits, but same result.. the browser justs sits there. No logs
in Squid.




Nick

--
Nick Ellson
Dad
CCDA, CCNP, CCSP, CCAI,
MCSE 2000, Security+, Network+
Network Hobbyist, VFR Private Pilot.


Reply | Threaded
Open this post in threaded view
|

Re: WCCP / no return traffic on gre interface

Adrian Chadd
On Sat, May 19, 2007, Nick Ellson wrote:
> Hi Nicolas,
>
> I was using this WIKI to configure, and thought the same thing you did..
> would not my destination be anything BUT my local net? Then at the end of
> this WIKI there is a guy that has my type of set-up.
>
> "Interception Caching with Linux 2.6.18, ip_gre, Squid-2.6 and cisco IOS
> 12.4(6)T2 by ReubenFarrelly"

Try http://wiki.squid-cache.org/ConfigExamples/

Also, make sure you've got ip forwarding turned on, and rp filtering turned
off.





Adrian

Reply | Threaded
Open this post in threaded view
|

Re: WCCP / no return traffic on gre interface

Nick Ellson

Hi Adrian,

From the section I quoted in the WIKI I did this:

  echo "0" > /proc/sys/net/ipv4/conf/default/accept_source_route
  echo "0" > /proc/sys/net/ipv4/conf/default/rp_filter
  echo "1" > /proc/sys/net/ipv4/ip_forward

I'll look at some of the other configs, but would you think having the
counters increment on the IPTABLES rules would mean that they are being
utilized and would be handled by Squid?

Nick



--
Nick Ellson
Dad
CCDA, CCNP, CCSP, CCAI,
MCSE 2000, Security+, Network+
Network Hobbyist, VFR Private Pilot.


Reply | Threaded
Open this post in threaded view
|

Re: WCCP / no return traffic on gre interface

Nick Ellson
In reply to this post by Adrian Chadd

Adrian and All,

I had been doing a lot of rebooting this morning just doing other work and
I got tierd of manualy loading my ip_gre, ip_tables  modules, so I built
them into the kernel this time. Now WCCPv2 works.

Wow.. That I did not expect.  Now i stuffed all this in the kernel.

----------------- From the WIKI ---------------
If you are running a custom built kernel (rather than one supplied by your
Linux distribution), you need to build in support for at least these
options:

     * Networking support
     * Sysctl support
     * Network packet filtering
     * TCP/IP networking
     * Connection tracking (Under "IP: Netfilter Configuration" in
menuconfig)
     * IP tables support
     * Full NAT
     * REDIRECT target support
------------------------------------------------

And as it works, I will leave it alone.

Now I need to research why SquidGuard's redirect URL is sent but the
browser does not display anything but set the title bar to the title of
the page I send it to. (The URL is on another internal server, 10.0.0.20)
Could this be a problem related to the one I just faced?

Nick


--
Nick Ellson
Dad
CCDA, CCNP, CCSP, CCAI,
MCSE 2000, Security+, Network+
Network Hobbyist, VFR Private Pilot.


Reply | Threaded
Open this post in threaded view
|

Re: WCCP / no return traffic on gre interface

Henrik Nordström
In reply to this post by Nick Ellson
lör 2007-05-19 klockan 15:39 -0700 skrev Nick Ellson:

> Squid listening on port 3128 transparent, iptables REDIRECT from 80 to 3128.
> wccp0 gre tunnel is up and shows traffic recieved from the router.

Have you disabled rp_filter on the gre tunnel?

Regards
Henrik

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WCCP / no return traffic on gre interface

Henrik Nordström
In reply to this post by Adrian Chadd
sön 2007-05-20 klockan 11:30 +0800 skrev Adrian Chadd:

> Try http://wiki.squid-cache.org/ConfigExamples/
>
> Also, make sure you've got ip forwarding turned on, and rp filtering turned
> off.

note: ip forwarding isn't actually needed, but might be useful if you
want to have iptables rules for bypassing the proxy..

Regards
Henrik

signature.asc (316 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: WCCP / no return traffic on gre interface

Adrian Chadd
On Mon, May 21, 2007, Henrik Nordstrom wrote:
> s??n 2007-05-20 klockan 11:30 +0800 skrev Adrian Chadd:
>
> > Try http://wiki.squid-cache.org/ConfigExamples/
> >
> > Also, make sure you've got ip forwarding turned on, and rp filtering turned
> > off.
>
> note: ip forwarding isn't actually needed, but might be useful if you
> want to have iptables rules for bypassing the proxy..

really? I could've sworn it didn't work without it. I know it doesn't work
under FreeBSD.



Adrian

Reply | Threaded
Open this post in threaded view
|

Re: WCCP / no return traffic on gre interface

Henrik Nordström
tis 2007-05-22 klockan 08:25 +0800 skrev Adrian Chadd:
> > note: ip forwarding isn't actually needed, but might be useful if you
> > want to have iptables rules for bypassing the proxy..
>
> really? I could've sworn it didn't work without it. I know it doesn't work
> under FreeBSD.

Yes. really. In Linux you only need to enable ip forwarding if you
really want to forward packets as a router, not to only intercept them
and deliver locally. This due to iptables/netfilter NAT executing pretty
much outside the TCP/IP stack, and as result the Linux TCP/IP stack only
sees packets with the hosts own IP as destination.

Regards
Henrik

signature.asc (316 bytes) Download Attachment