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

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
Received on Sat Nov 02 2013 - 08:13:44 MDT