[squid-users] Re: transparent proxy on remote box issue

Amos Jeffries <squid3 <at> treenet.co.nz> writes:

>
> On 2/11/2013 9:17 p.m., WorkingMan wrote:
> >> One hint I had was that the traffic are not marked correctly.
> >>
> >> This line if added (I got it from somewhere online) will change the mac
> > address
> >> of
> >> the web site to be the one of SQUID:
> >>
> >> iptables -t mangle -A OUTPUT -o eth0 -p tcp --dport 80 -j MARK --set-
mark
> > 2
> >> With that rule:
> >> 06:13:38.327212 0a:a5:82:f8:2e:93 (VPN's mac)> 0a:3c:e1:08:45:b7
(SQUID's
> > mac),
> >> IPv4, length 74: 10.0.0.170.57525 > 157.166.248.10.80 (web site): tcp 0
> >>
> >> Without that rule:
> >> 06:01:59.823267 0a:a5:82:f8:2e:93 (VPN's mac) > 0a:ee:81:f6:13:ef
(SQUID's
> >> mac),
> >> IPv4, length 66: 10.0.0.170.43154 > 157.166.249.11.80 (web site): tcp 0
> >>
> > This diagram explains the flow of PRE/POSTROUTING/OUTPUT/FORWARD:
> > http://users.ecs.soton.ac.uk/ajf101/kptd.pdf
>
> It is very simplified, but yes.
>
> For a better view use this diagram as written by the netfilter xtables
> author:
> http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-
flow.svg
>
> > So OUTPUT rule makes a different because I am testing from a local
process
> > (ie: curl on VPN server).
>
> Sorry my fault here, I made a mistake in crafting the tests. You are
> right about OUTPUT being needed or _they_ fail. But that is only for the
> curl tests and traffic generated on the VPN server itself. You *also*
> need identical iptables rules in the mangle PREROUTING tables for the
> clients traffic we are intending to route.
>
> We are trying to use the MARK to influence the arrows leaving "routing
> decision" box on left and side of the diagram for client 10.100.0.0/16
> traffic and either the "routing decision" or the "reroute check" on the
> right hand side for curl tests.
>
> > I then tried from VPN client (inbound traffic) and POSTROUTING makes a
> > difference here (putting SQUID's mac). Here some notes:
> >
> > #marking inbound traffic:
> > iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 80 -j MARK --
set-
> > mark 2
> >
> > #marking outbound traffic (ie: locally generated traffic):
> > iptables -t mangle -A OUTPUT -o eth0 -p tcp --dport 80 -j MARK --set-
mark 2
> >
> > Anyhow that doesn't explain to me why market traffic is not going to
SQUID.
>
> Did you also have the special routing table created for the marked
packets?
>
> If you have that setup. You could try without the -i / -o parameters
> and see if the interface/outerface is correct.
>
> Amos
>
>

proxy.rules:

iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -t filter -F

sysctl -w net.ipv4.ip_forward=1

#can't add -d 10.100.0.0/16 because when I do it breaks http;
#only DNS requests are done; when removed http request can continue
#after DNS check
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

export WAN=eth0
export SQUID=10.0.0.117

iptables -t mangle -A PREROUTING -i $WAN -p tcp --dport 80 -j MARK --set-
mark 2
iptables -t mangle -A PREROUTING -m mark --mark 2 -j ACCEPT

iptables -t mangle -A OUTPUT -o eth0 -p tcp --dport 80 -j MARK --set-mark 2

#do the rt_tables change once
#echo 202 http >> /etc/iproute2/rt_tables

#remove old rules
ip rule del fwmark 2 table http
ip route del default via $SQUID dev eth0 table http

#add new rules
ip rule add fwmark 2 table http
ip route add default via $SQUID dev eth0 table http
ip route flush cache

iptables-save

BTW, from your hint I added -o $WAN to first POSTROUTING:
iptables -t mangle -A PREROUTING -o $WAN -i $WAN -p tcp --dport 80 -j MARK -
-set-mark 2

This had the consequence of undoing the mac address change. So I could
navigate the internet using VPN client but mac address of the web server is
not that of SQUID's mac (and still no traffic going to SQUID).

Did you say earlier that local process' traffic can't be routed using policy
routing? I was thinking VPN server will act as a router by creating virtual
IP (10.100.0.0/16, defined in ipsec.conf). So technically all traffic are
seeing as if coming out of VPN server's IP (is that considered local
traffic?). I know DNAT/SNAT can route the traffic except for its flaws.
TPROXY is also for local traffic only right? Would an additional hop to make
VPN uncapped traffic look like inbound traffic and apply policy based
routing work? I am running out of ideas now (openVPN creates a new interface
tun0 not sure if that has the same effect of an extra hop?).

Thanks,
Received on Sat Nov 02 2013 - 09:47:30 MDT