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

From: WorkingMan <signup_mail2002_at_yahoo.com>
Date: Sat, 2 Nov 2013 06:24:18 +0000 (UTC)

> 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.

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 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

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

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.

Thanks,
Received on Sat Nov 02 2013 - 06:24:46 MDT

This archive was generated by hypermail 2.2.0 : Sat Nov 02 2013 - 12:00:05 MDT