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

Eliezer Croitoru <eliezer <at> ngtech.co.il> writes:

>
> Hey,
>
> On 10/31/2013 09:58 AM, WorkingMan wrote:
> > iptables -t nat -A POSTROUTING -j MASQUERADE
>
> try to flush all the iptables rules by:
> iptables -t nat -F
> iptables -t filter -F
> iptables -t mangle -F
>
> then add the next:
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> sysctl -w net.ipv4.ip_forward=1
>
> The above rules should make the client able to do any network thing he
> needs to if the vpn client and server are configured to route all the
> traffic to the VPN server.
> then use tcpdump:
> tcpdump -i eth0 -nn port 80
>
> to see what traffic is being sent from the server to the web.
>
> then and only after these tests are made (note that the -F might need
> the POSTROUTING or any other name of a table after it) you can minimize
> the cause of the problem to the VPN level or to the iptables or any
> other level.
>
> can you by any chance run a "ifconfig -a" command and share the output?
>
> Eliezer
>
>

Do I need to do anything on client side? I am using OS's built-in VPN client
and browser.

VPN server:

eth0 Link encap:Ethernet HWaddr 0a:a5:82:f8:2e:93
          inet addr:10.0.0.170 Bcast:10.0.0.255 Mask:255.255.255.0
          inet6 addr: fe80::8a5:82ff:fef8:2e93/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:14748 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5123 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:15268379 (15.2 MB) TX bytes:917810 (917.8 KB)

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:65536 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

#this interface has no consequence since it's working with or without it

eth1 Link encap:Ethernet HWaddr 0a:af:5f:23:3d:31
          inet addr:10.0.0.11 Bcast:10.0.0.255 Mask:255.255.255.0
          inet6 addr: fe80::8af:5fff:fe23:3d31/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:2197 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2326 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:435969 (435.9 KB) TX bytes:458603 (458.6 KB)

SQUID server:

eth0 Link encap:Ethernet HWaddr 0a:3c:e1:08:45:b7
          inet addr:10.0.0.117 Bcast:10.0.0.255 Mask:255.255.255.0
          inet6 addr: fe80::83c:e1ff:fe08:45b7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:105968 errors:0 dropped:0 overruns:0 frame:0
          TX packets:58748 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:101288758 (101.2 MB) TX bytes:17275538 (17.2 MB)

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:65536 Metric:1
          RX packets:175 errors:0 dropped:0 overruns:0 frame:0
          TX packets:175 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:82568 (82.5 KB) TX bytes:82568 (82.5 KB)

I am suspecting something is going on but I am just not seen it in the logs.
tshark is not catching anything either by host <IP> or port 3130 on either
VPN/SQUID. Does the TPROXY way work for SQUID on a remote server because I
was going to try that next?

ping, dns lookup all seems normal except for port 80 (all apps not using
port 80 works). with clean.rules set using your suggested rules I see this
(client can browse but doesn't look like it went to SQUID server at all)

Src: 10.100.0.1 (10.100.0.1, VPN client), Dst: 176.32.98.168 (amazon)
Src: 10.0.0.170 (10.0.0.170, VPN), Dst: 176.32.98.168 (176.32.98.168)
Src: 176.32.98.168 (176.32.98.168), Dst: 10.0.0.170 (10.0.0.170)

Let's just say things look normal.

With proxy.rules (policy based routing), I see alot of TCP retransmission
from VPN client/server to the web server.

10.0.0.170 -> 157.166.248.10 TCP 78 60440 > http [SYN] Seq=0 Win=65535 Len=0
MSS=1240 WS=16 TSval=230783310 TSecr=0 SACK_PERM=1
10.0.0.170 -> 157.166.248.11 TCP 78 [TCP Retransmission] 60437 > http [SYN]
Seq=0 Win=65535 Len=0 MSS=1240 WS=16 TSval=230783793 TSecr=0 SACK_PERM=1
 10.100.0.1 -> 157.166.249.10 TCP 78 [TCP Retransmission] 60438 > http [SYN]
Seq=0 Win=65535 Len=0 MSS=1240 WS=16 TSval=230783995 TSecr=0 SACK_PERM=1

it does this until it gives up. I hope that rings a bell. I could be
debugging this wrong and not seen the obvious. There is no trace on SQUID
server or its log so I assume traffic didn't made it over. On VPN server
when I do a query to a web site it works which is weird because I thought it
should also get routed since all tcp on eth0 ared marked (also no log in
access.log on squid side so it's not routed).
 
Thanks,
Received on Thu Oct 31 2013 - 18:02:30 MDT