On 2/11/2013 7:24 p.m., WorkingMan wrote:
There is a very specific order of packet flow required to get these
things working. And an equally specific order of configuration and
testing needed to ensure that it is all working.
I have taken the liberty of re-arranging the details you posted to
follow the order of configuration necessary to show working testing at
every step.
IFF (and only if) you have advanced networking skills can you do these
stages out of order.
Start reading the below text and comments *in-order* and ensure each
machine is showing the expected behaviour before moving on to the next one.
If any one of these stages fails to show the expected behaviour please
stop and ask for more help before continuing or experimenting further
(Im not perfect, but lets not have to re-do/undo anything complex if I
make a mistake writing this up in advane of the test results).
]
It's very simple I want this flow to happen.
client (10.100.0.0/16) <-port 500/4500-> VPN server (10.0.0.170)
VPN server (10.0.0.170) <- port 80-> SQUID (10.0.0.117) <--> Default
Gateway
(10.0.0.1)
VPN server (10.0.0.170) <- ! port 80-> Default Gateway (10.0.0.1)
So the Squid machine is the only one supposed to have direct contact to
Internet for this traffic. We start there, ensuring that it works
properly before setting up anything to depend on it.
** ensure the 10.0.0.1 has NAT setup to convert any 10.0.0.0/24 or
10.100.0.0/16 to public IP as is the duty of a gateway.
** ensure that 10.0.0.170 and 10.0.0.117 *both* have default gateway of
10.0.0.1
TEST ...... at this point you should:
1) be able to make any communication directly from 10.0.0.117 to any
public Internet machine.
2) be able to make any communication directly from 10.0.0.170 to any
public Internet machine.
3) tcpdump on 10.0.0.117 does NOT show any traffic from 10.0.0.170
during test (2)
VPN Server - > Web Site (SQUID's mac),
** ensure the 10.0.0.117 machine has these configured:
(/etc/sysctl.conf)
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0
net.ipv4.ip_forward=1
** also configure the policy based routing to ensure packets leaving
10.0.0.170 destintion port 80 are routed to 10.0.0.117.
TEST ...... at this point by generating test traffic from 10.0.0.170 you
should see in tcpdump:
1) port-80 packets 10.0.0.170 being delivered to the 10.0.0.117 machine
(visible in 10.0.0.170 tcdumps)
2) port-80 packets arriving into the 10.0.0.117 machine (visible on
10.0.0.117 tcpdumps)
3) other traffic working fine, if you want to check that it is NOT
visible on the 10.0.0.117 machine you can also do that.
IMPORTANT: if any one of the tests above fails to have the expected
result we will need to dig deeper into what is going on there between them.
VPN Client -> VPN Server
** on the client 10.100.0.0/16 configure the default gateway to be
10.0.0.170 (or whatever the client-end of the VPN is set to).
** ensure that the routing done by 10.0.0.170 and 10.0.0.117 is able to
route 10.100.0.0/16 traffic.
NOTICE how there is no mention of NAT between 10.100.0.0/16 and
10.0.0.0/24. All the routing table entries for 10.0.0.0/24 machines need
to be able to handle packets with IP addresses in 10.100.0.0/16
NOTE: things will get quite complicated if you want other WAN
connections from the client device. Leave that complication out of the
system for now.
TEST ... at this point what you should see when generating traffic from
the client machine 10.100.0.0/16:
1) all client packets being delivered to 10.0.0.170 (visible on the
client machine)
2) all client packets are visible arriving on the 10.0.0.170 (visible on
10.0.0.170).
3) client port-80 packets being delivered to 10.0.0.117 (visible on
10.0.0.170).
4) from client viewpoint everything should be working fine.
IF and only if the above tests are all passed sucesfully are you ready
to start the Squid and interception parts of the configuration. They
take place on the Squid box and consists only of the LinuxDnat /
LinuxRedirect configuration examples in the Squid wiki.
Can you just tell me what I need to do to make this work? It seems we
are back to square one. It would go faster if you tell me everything in one
reply
instead of feeding each other with bits of information then
change direction with each new information that comes along.
We have indeed gone down several different network topology
configurations and ended back at step 1.
It would have helped if we had started with the intended network diagram
below.
It's very simple I want this flow to happen.
client (10.100.0.0/16) <-port 500/4500-> VPN server (10.0.0.170)
VPN server (10.0.0.170) <- port 80-> SQUID (10.0.0.117) <--> Default
Gateway
(10.0.0.1)
VPN server (10.0.0.170) <- ! port 80-> Default Gateway (10.0.0.1)
I am not sure if http response goes directly to original client or goes
back from the route where it came from so It could be incorrectly drawn
above.
It SHOULD be going back via the Squid box. The above is good.
Amos
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
