Just to make sure I understood:
How many boxes do you have?
what is VPN and what is SQUID?
You do understand that there is no way to run TPROXY on amaozn safely??
So leave TPROXY out of sight for now.
If you have two machines it's another story.
if you do have one machine then what is the:
"ip route"
"iptables-save"
and
"ip addr"
output for this machine?
Eliezer
On 10/31/2013 10:52 PM, WorkingMan wrote:
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,
Update. Found this, https://forums.gentoo.org/viewtopic-t-932554-start-
0.html, that helped me look at the mac address of the src/dst.
With proxy.rules now with above info I see mac address of the web site is
the mac address of SQUID server. Again I only see one direction traffic
going to the web site. At least we know it's doing something that looks
correct.
With clean.rules, web site's mac address is the gateway/DNS (in my case is
the same mac). I see bidirectional traffic between web site and VPN server.
On SQUID server I have applied 4 rules from this SQUID guide:
http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect
There is no traffic to SQUID using tshark. Nothing in SQUID logs or syslog.
Nothing in VPN's syslog.
Thanks,
