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,
