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

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
Received on Sat Nov 02 2013 - 09:12:41 MDT