[squid-users] Central Proxy using WCCP to multiple sites in our network with ASA box.

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 18/10/2014 8:47 a.m., Luderitz Bob wrote:
> I have one central Proxy Server running Squid 3.1.10 under CentOS
> 6.3 running locally here and also for our 2 remote sites for all
> http traffic.
> 
> We are using Cisco's WCCP and between the remote sites and the
> Squid is a ASA box.
> 
> where the Proxy is running Site A and one of the remote Site B. 
> From either of the remote sites, when I try to access a printer or
> other web enabled device thru a browser that is not defined in
> squid.conf, I get access denied. This is strange to me as this
> request should be considered part of the internal network. When I
> put statements in squid.conf for this print, I then get connection
> timed out.


What do you mean by "defined in squid.conf"? What statements?

and, what does your squid.conf contain already?

> 
> From the Squid server, I cannot ping this remote printer due to the
> static route has 0.0.0.0 as its gateway address.
> 

That should not affect ping/ICMP.


> See the below config for one of the remote sites:
> 
> In /etc/rc.local file:
> 
> iptunnel add tun-cc mode gre remote 192.168.253.16 local
> 10.80.166.227 dev eth0 ip link set dev tun-cc up ip route add
> 10.80.202.0/23 dev tun-cc metric 101
> 

Remote 192.168.253.16 ??
That might be the problem. How does 192.168.* traffic get routed over
the Internet to remote endpoint?


> In squid.conf, this network should be considered internal: acl
> nga_net src 10.80.0.0/16    # Internal network (I have tried
> splitting out the ACL statements but same result)
> 
> http_access allow nga_net
> 
> If I look at the static routes on the server (netstat -rn or route
> -v) Destination     Gateway         Genmask         Flags   MSS
> Window  irtt Iface 1.2.3.0         0.0.0.0         255.255.255.0
> U         0 0          0 gre0 10.80.166.0     0.0.0.0
> 255.255.255.0   U         0 0          0 eth0 10.80.202.0
> 0.0.0.0         255.255.254.0   U         0 0          0 tun-cc
> (remote site) 0.0.0.0         10.80.166.254   0.0.0.0         UG
> 0 0          0 eth0
> 
> As you can see, the gateway for this remote site is the Internet
> (0.0.0.0)

No. That is link-local "gateway". As in: this machine thinks it is has
a direct cable/wireless connection to all machines in that netblock -
maybe a un-managed switch or hub on between but nothing more. Thus no
gateway router is needed to contact them.

The way to things on Internet is unknown and complex, thus a gateway
(10.80.166.254) is needed to manage routing those packets around.

Looks correct to me like that routing table is correct, even if you
are misunderstanding it.


NP: the tun-cc should be wrapping the packets in a tunnel wrapper IP
that can traverse the network/Internet between this machine and the
other end of the tunnel. Just as if the tunnel were a single "wire".


> and thinking it should be 10.80.166.254. When I try to change the
> gateway for this static route, I get message - RTNETLINK answers:
> File exists If I remove the static route, I cannot get to any
> internal or Internet site from a remote site workstation.
> 
> Due to the ASA in the traffic path of the remote sites, there is a
> gre tunnel setup for outbound traffic from the Squid server,
> without the tunnel the packet would be dropped by the ASA box.
> 
> I know the best practices is to have a proxy server at each remote
> location, but this solution does work for most requests. Has anyone
> else run into this and found a solution, thanks....
> 


This is what I think is happening:

 * "normal" traffic from Squid is destined to Internet servers, thus
has Squid 10.* src-IP and some global dst-IP. These go out via eth0 to
the ASA and get routed (and NAT?) applied normally.

 * the internal traffic to remove POP (including ping?) attempts to go
out the tunnel, and gets wrapped as src-IP 10.80.166.227 with dst-IP
192.168.253.16. Then sent out eth0 to the ASA.
   - something blocks/drops those packets ?

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUQbVWAAoJELJo5wb/XPRjP40H/jeBJpG/7ku5+YZVWk1UTEYO
tcd1UWwws5bEHqTP6HbFWloks/utXOXEnQmd+CuUanrXooI5ykpXQy8oBo4sJzY+
DZqlNltryiywf+0SYD8i1OfutxSeDIjn2NpiBGO6HppFaZhuoKeiP2MLqhR/wxee
GXxteK9kuRDOIcufvY+pIx3HZwXQOAykCATM65AxprgzebwKfYNqxRIzfCUUL0ti
pIFeNLDdzcCJieys4KCVvf1VUvpErSE/Eh52Wvwuv2w4zRzQhMrQ1ejC1Qlz3GjH
wqnuww1qXTUWCtCSGs8oeCpP3PPYX4IkE3FWuPSEaPmWhQ/Q02tQP8bd1t7wQ6Y=
=+3m1
-----END PGP SIGNATURE-----