Search squid archive

Squid transparent proxy + VPN problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I can't decide if this is a squid problem or an iptables problem, so I'm
asking here in case someone can point me in the right direction.

-----------------------------
Software/Environment details:
-----------------------------

jekyl:/home/david# uname -a
Linux jekyl 2.4.27-2-686 #1 Wed Aug 17 10:34:09 UTC 2005 i686 GNU/Linux

jekyl:/home/david# iptables --version
iptables v1.2.11

jekyl:/home/david# squid -v
Squid Cache: Version 2.5.STABLE9
configure options:  --prefix=/usr --exec_prefix=/usr --bindir=/usr/sbin --sbindir=/usr/sbin --libexecdir=/usr/lib/squid --sysconfdir=/etc/squid --localstatedir=/var/spool/squid --datadir=/usr/share/squid --enable-async-io --with-pthreads --enable-storeio=ufs,aufs,diskd,null --enable-linux-netfilter --enable-arp-acl --enable-removal-policies=lru,heap --enable-snmp --enable-delay-pools --enable-htcp --enable-poll --enable-cache-digests --enable-underscores --enable-referer-log --enable-useragent-log --enable-auth=basic,digest,ntlm --enable-carp --with-large-files i386-debian-linux

jekyl:/home/david# cat /etc/debian_version
3.1

--------------------------
Issue/action Description
--------------------------

I am attempting to do transparent HTTP proxying with squid. This works
fine for traffic flowing in over individual interfaces, but not for
traffic arriving over a VPN (the proxy server is also a VPN gateway).

Tracking packets using logging rules, it seems that the packets are
getting redirected, and even accepted, but are not arriving in userland,
or squid is dropping the requests. I can see no indication in the squid
logs that it is recieving the requests - no corresponding entries in
access.log or cache.log. The proxy can be accessed directly in all
cases, but not transparently via the VPN.

In squid.conf i've got:  

debug_options ALL,1 33,2

Transparent proxying works flawlessly for network traffic that comes in
over individual interfaces (eth0, mcnulty_ppp - a wanrouter interface).
These networks are connected like so:

192.168.20/24 --- [router] ------------- [main router/proxy] ------- {internet}

I am having problems with networks connected via IPSec VPN. I am using
native 2.6 ipsec, so there are no interfaces associated with individual
VPN connections as when using KLIPS (the openswan IPSec implementation).
They are connected in the following fashion:

192.168.30/24 --- [router] ======Full tunnel (0.0.0.0/0 is forwarded to main router)========= [main router/proxy] ------- {internet}

In the sense of network topology and functionality, these two
configurations are identical, as I see it. For all other purposes
besides that of transparent proxying of HTTP requests, both
configurations work flawlessly.

In my iptables set up, I've set the default policy to DROP for the
INPUT, OUTPUT, and FORWARD chains. This means that packets must be
explicitly accepted. The last rule in each chain is a LOG rule so that I
see packets that get dropped in the logs.

For the working networks, I've got these iptables rules:

nat:
-A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128

filter:
-A INPUT -d 192.168.10.1 -i eth0 -p tcp -m tcp --dport 3128 -j ACCEPT

Note: in testing the VPN iptables rules, I am restricting their effect
to one host on the remote network, so as to avoid breaking everyone's
internet connection, hence the extra --source switch.

For the VPN networks, I've got these rules in the nat table:

-A PREROUTING -i eth1 -p tcp -m tcp --source 192.168.30.5 --dport 80 -j LOG --log-prefix "matched redirect "
-A PREROUTING -i eth1 -p tcp -m tcp --source 192.168.30.5 --dport 80 -j REDIRECT --to-ports 3128

and these in the filter table:

-A INPUT -s 192.168.30.5 -i eth1 -j LOG --log-prefix "redirected to input "
-A INPUT -s 192.168.30.5 -d 192.168.2.2 -i eth1 -p tcp -m tcp --dport 3128 -j ACCEPT
-A INPUT -s 192.168.30.5 -d 192.168.2.2 -i eth1 -p tcp -m tcp --dport 3128 -j LOG --log-prefix "but not accepted for input "

I know that packets are matching the nat rules because the LOG rule
shows up in the logs, and redirected packets are getting logged by my
first filter LOG rule.

I know that packets are getting accepted on the interface because ACCEPT
is a terminating target, and the following LOG rule is not getting
logged. If I remove the ACCEPT rule, the following LOG rule is
evaluated.

Grasping at straws here, but I removed all entries
from /etc/hosts.{allow,deny} in case these contained entries that would
be preventing squid from accepting connections from certain IPs, and
restarted squid.

This doesn't really make any sense, as connections should (I think) be
refused rather than just dropped or ignored if it was a tcpwrappers
thing. Anyway, I tried, and it made no difference.


-davidc

--
Who is General failure and why is he reading my disk?

[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux