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
