Ssh – Tunneling into vpn using squid and ssh-tunnel

squidsshtunnelingvpn

intro:

In order to access the administrative console of a certain datacenter I am supposed to use a VPN. However due to company network setup I cannot establish a vpn connection (I was told that they wont set up the required tunnel for me. At the same time I was allowed to find a bypass). To bypass it, I'm using google chrome browser with proxy set to localhost:9999. There's an ssh tunnel connecting localhost:9999 with a instance of squid on a dedicated server. Dedicated server has established VPN connection using vpnc.

When I test web browsing – I have no problem logging into gmail account through this proxy. So http and https is redirected correctly.

When I try to reach a https:///login.html , chrome tells me Error 7 (net::ERR_TIMED_OUT): The operation timed out

ifconfig tun0 (tun0 being the vpn connection)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.237.1  P-t-P:192.168.237.1  Mask:255.255.255.255

squid access.log excerpt:

1322248499.456  29972 94.23.35.103 TCP_MISS/000 0 CONNECT 172.30.3.93:443 - NONE/- -
1322248499.484  30000 94.23.35.103 TCP_MISS/000 0 CONNECT 172.30.3.93:443 - NONE/- -
1322248529.478  29905 94.23.35.103 TCP_MISS/000 0 CONNECT 172.30.3.93:443 - NONE/- -

ip r command

180.150.133.253 via 94.23.35.254 dev eth0  src 94.23.35.103 
192.168.237.0/24 dev tun0  scope link 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 
94.23.35.0/24 dev eth0  proto kernel  scope link  src 94.23.35.103 
172.30.0.0/22 dev tun0  scope link 
default via 94.23.35.254 dev eth0  metric 100

tcpdump -i tun0

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
20:39:41.146346 IP 192.168.237.1.33810 > 172.30.3.93.https: Flags [S], seq 2990531692, win 13720, options [mss 1372,sackOK,TS val 34961006 ecr 0,nop,wscale 7], length 0
20:39:41.206331 IP 192.168.237.1.50869 > 172.30.3.93.https: Flags [S], seq 1974326041, win 13720, options [mss 1372,sackOK,TS val 34961012 ecr 0,nop,wscale 7], length 0
20:39:41.370436 IP 172.30.3.93.https > 192.168.237.1.33810: Flags [S.], seq 953273047, ack 2990531693, win 5792, options [mss 1380,sackOK,TS val 4294958113 ecr 34961006,nop,wscale 2], length 0
20:39:41.370458 IP 192.168.237.1 > 172.30.3.93: ICMP 192.168.237.1 tcp port 33810 unreachable, length 68
20:39:41.427724 IP 172.30.3.93.https > 192.168.237.1.50869: Flags [S.], seq 3867774677, ack 1974326042, win 5792, options [mss 1380,sackOK,TS val 4294958118 ecr 34961012,nop,wscale 2], length 0
20:39:41.427743 IP 192.168.237.1 > 172.30.3.93: ICMP 192.168.237.1 tcp port 50869 unreachable, length 68
20:39:44.147985 IP 192.168.237.1.33810 > 172.30.3.93.https: Flags [S], seq 2990531692, win 13720, options [mss 1372,sackOK,TS val 34961307 ecr 0,nop,wscale 7], length 0
20:39:44.207981 IP 192.168.237.1.50869 > 172.30.3.93.https: Flags [S], seq 1974326041, win 13720, options [mss 1372,sackOK,TS val 34961313 ecr 0,nop,wscale 7], length 0
20:39:50.157964 IP 192.168.237.1.33810 > 172.30.3.93.https: Flags [S], seq 2990531692, win 13720, options [mss 1372,sackOK,TS val 34961908 ecr 0,nop,wscale 7], length 0
20:39:50.217978 IP 192.168.237.1.50869 > 172.30.3.93.https: Flags [S], seq 1974326041, win 13720, options [mss 1372,sackOK,TS val 34961914 ecr 0,nop,wscale 7], length 0
20:40:02.197916 IP 192.168.237.1.33810 > 172.30.3.93.https: Flags [S], seq 2990531692, win 13720, options [mss 1372,sackOK,TS val 34963112 ecr 0,nop,wscale 7], length 0
20:40:02.237994 IP 192.168.237.1.50869 > 172.30.3.93.https: Flags [S], seq 1974326041, win 13720, options [mss 1372,sackOK,TS val 34963116 ecr 0,nop,wscale 7], length 0
20:40:11.245849 IP 192.168.237.1.43253 > 172.30.3.93.https: Flags [S], seq 885758311, win 13720, options [mss 1372,sackOK,TS val 34964016 ecr 0,nop,wscale 7], length 0
20:40:11.467567 IP 172.30.3.93.https > 192.168.237.1.43253: Flags [S.], seq 1102840217, ack 885758312, win 5792, options [mss 1380,sackOK,TS val 4294961122 ecr 34964016,nop,wscale 2], length 0
20:40:11.467591 IP 192.168.237.1 > 172.30.3.93: ICMP 192.168.237.1 tcp port 43253 unreachable, length 68
20:40:14.247958 IP 192.168.237.1.43253 > 172.30.3.93.https: Flags [S], seq 885758311, win 13720, options [mss 1372,sackOK,TS val 34964317 ecr 0,nop,wscale 7], length 0

and i can ping the machine ok.

PING 172.30.3.93 (172.30.3.93) 56(84) bytes of data.
64 bytes from 172.30.3.93: icmp_req=1 ttl=64 time=221 ms
64 bytes from 172.30.3.93: icmp_req=2 ttl=64 time=222 ms
64 bytes from 172.30.3.93: icmp_req=3 ttl=64 time=221 ms
64 bytes from 172.30.3.93: icmp_req=4 ttl=64 time=226 ms
64 bytes from 172.30.3.93: icmp_req=5 ttl=64 time=221 ms
64 bytes from 172.30.3.93: icmp_req=6 ttl=64 time=221 ms
^C
--- 172.30.3.93 ping statistics ---
7 packets transmitted, 6 received, 14% packet loss, time 6001ms
rtt min/avg/max/mdev = 221.068/222.406/226.608/1.991 ms

Can anyone give me hints as to:
-What's the obvious error here (I hope there is one ;))?
-What logs to look on to debug the matter?

Best Answer

20:40:11.245849 IP 192.168.237.1.43253 > 172.30.3.93.https: Flags [S], seq 885758311, win 13720, options [mss 1372,sackOK,TS val 34964016 ecr 0,nop,wscale 7], length 0
20:40:11.467567 IP 172.30.3.93.https > 192.168.237.1.43253: Flags [S.], seq 1102840217, ack 885758312, win 5792, options [mss 1380,sackOK,TS val 4294961122 ecr 34964016,nop,wscale 2], length 0
20:40:11.467591 IP 192.168.237.1 > 172.30.3.93: ICMP 192.168.237.1 tcp port 43253 unreachable, length 68

First line says that your machine sent SYN flag i.e. [S] to initiate handshake with the server(segment sequence number 885758311).

Second line says that server has acknowledged with Flag [S.] to your machine's SYN request(ack 885758312 i.e 885758311+1).

I am not sure about the third line but I think it says that destination host(your machine) is informing sending host(remote machine) that the requested port i.e. 43253 is not reachable. So there must be something in your firewall that is rejecting this connection. Check the firewall rules.

Related Solutions

Split Tunnel VPN using incorrect Tunnel

This will definitely be dependent on the VPN client you use.

At our site we use 2003 server with RRAS for VPN connections and I had similar issues that I resolved by making a custom VPN "connectoid" using the microsoft CMAK (connection manager administration kit)

I used this guide while creating the client http://www.isaserver.org/tutorials/work-around-VPN-clients-split-DNS.html It helped me to get clients to connect, use DNS servers at the office for name resolution but also allows all internet destined traffic to use the local gateway properly.

Your issues, if they are like mine, have to do with 2 things.

VPN connections are low on the bind order for DNS in windows by default. This means that it will favor your local LAN DNS servers over your VPN connections servers unless you tell windows to favor your VPN connection over the others.
Dns resolution isn't working properly because no DNS suffix is specified for the VPN connection. Even if you are looking at the right DNS servers, if no search suffix is configured for that link the machine will fail to convert the name "server" to "server.domain.com" when performing a lookup. unless you reference everything using fqdn, which I have never seen in practice, this could be a show-stopper as well.

Hopefully the guide for the 2003 CMAK kit and this information will help you to get the nortel client working in your environment.

HOWEVER, another option for these networks is to use a gateway that can do IPsec with your main site so that users aren't required to connect using individual VPN connections while they are at any of your sites. PFsense is a great BSD based firewall/router distro that has done an amazing job for me in the past. I've used PFsense in production to pipe 150+ users over an IPsec connection with a cisco device on the other end and it didn't even bat an eye.

Get back with more information if you think I have mis-understood your issue!

Linux – SSH remote access vpn tunnel

Under Centos the answer appears to be as follows:

on bar (the restricted machine) run the following command:

ssh -N -R 1234:localhost:22 foo.theinternet.com

then on foo (the open machine) run:

ssh -p 1234 localhost

I suspect there are refinements to be made to this, but hopefully it will be enough to get any googlers started.

Thanks to pkaeding for putting me on the right track.

Best Answer

Related Solutions

Split Tunnel VPN using incorrect Tunnel

Linux – SSH remote access vpn tunnel

Related Topic