On 2/11/2013 9:46 p.m., WorkingMan wrote:
I have confidence that we can get to the bottom of this with this level
of
details.
I am currently stuck at this step:
VPN Server - > Web Site (SQUID's mac)
This was also where I was stuck before. At this point I am simply
issuing a
curl
www.cnn.com from VPN server (VPN client/SQUID not involved)
If I follow: http://www.tldp.org/HOWTO/TransparentProxy-6.html
What happens is that it says use DNAT/SNAT + policy routing and that in
the end
didn't do any policy routing since MAC address to the web site didn't
point to
SQUID's mac address.
Okay please drop that how-to. It is for a completely different network
topology than your diagram showed.
If I follow http://wiki.squid-
cache.org/ConfigExamples/Intercept/IptablesPolicyRoute.
Mac address of web site is SQUID's mac address but somewhere I get
packet loss
because it just keeps retransmitting the same http request. I had to add
one
extra
rule to arrive to this behavior (see below).
There are several use-case configurations in that page.
You need the one under "When Squid is in a DMZ between the router and
Internet".
There is no traffic going to SQUID other than ARP (for getting mac
address).
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
OUTPUT ??? none of the routing tutorials you have been looking at
mention doing anything in OUTPUT.
*PREROUTING* table (as in the "before routing" table of rules) is the
one you should be altering on the VPN server.
- Reset the VPN server config from these changes,
- go back to
http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute.
- follow the section "When Squid is in a DMZ between the router and
Internet"
- follow the section "Routing Setup"
- then re-run the 4 tests I outlined for this stage of configuration.
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
Easily explained. MARK are not set on the packet, they are flags in the
kernel metadata about a connection.
I'm doubt if they show up in a tcpdump, but they definitely will not
leave the machine they are used on.
On SQUID I followed this: http://wiki.squid-
cache.org/ConfigExamples/Intercept/LinuxRedirect
There is no traffic going to SQUID according to tshark (unless there is
just
not
showing up) so we can ignore this for now.
Rewind. That is steaming on way ahead of where things are broken.
Amos
I followed DMZ + policy routing and it still same result (tested with VPN
client).
*mangle
:PREROUTING ACCEPT [383:47877]
:INPUT ACCEPT [311:32547]
:FORWARD ACCEPT [149:20258]
:OUTPUT ACCEPT [302:67329]
:POSTROUTING ACCEPT [451:87587]
[77:4928] -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j MARK --set-xmark
0x2/0xffffffff
[77:4928] -A PREROUTING -m mark --mark 0x2 -j ACCEPT
COMMIT
# Completed on Sat Nov 2 08:30:56 2013
# Generated by iptables-save v1.4.18 on Sat Nov 2 08:30:56 2013
*nat
:PREROUTING ACCEPT [13:864]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [5:354]
:POSTROUTING ACCEPT [0:0]
[18:1218] -A POSTROUTING -o eth0 -j MASQUERADE
Source-NATing the outbound traffic.
I take it this is intended to happen on the traffic back to the client
network?
If so, try adding the parameter: -d 10.100.0.0/16 so only that
client reply traffic is NAT'ed.
COMMIT
# Completed on Sat Nov 2 08:30:56 2013
# Generated by iptables-save v1.4.18 on Sat Nov 2 08:30:56 2013
*filter
:INPUT ACCEPT [311:32547]
:FORWARD ACCEPT [149:20258]
:OUTPUT ACCEPT [313:68601]
COMMIT
ip route list table http
default via 10.0.0.117 dev eth0
ip rule show
0: from all lookup local
219: from all fwmark 0x2 lookup http
220: from all lookup 220
32766: from all lookup main
32767: from all lookup default
ip route
default via 10.0.0.1 dev eth0
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.170
Can you make this work on your end?
My wireless POP have a wifi link where yours has a VPN link. But
otherwise the same as what you seem to be trying to setup.
There is a subtle difference in your 10.0.0.0/24 being in a cloud
though. Mine are physical Ethernet between CPE.
Amos
