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,
