Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
Check firewall rules (iptables -L -vn) — the ICMP port unreachable packets seen in your tcpdump might be generated by a REJECT in an iptables rule. –  Sergey Vlasov Nov 25 '11 at 20:09

1 Answer 1

up vote 0 down vote accepted
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.

share|improve this answer
    
Hello, and thanks for hints - the restrictive firewall was the problem. I had to add: {{ iptables -A INPUT -j ACCEPT -s VPN_GW_IP -p esp iptables -A INPUT -j ACCEPT -s VPN_GW_IP -p udp -m multiport --sport isakmp,10000 iptables -A INPUT -j ACCEPT -i tun0 iptables -A OUTPUT -j ACCEPT -d VPN_GW_IP -p esp iptables -A OUTPUT -j ACCEPT -d VPN_GW_IP -p udp -m multiport --dport isakmp,10000 iptables -A OUTPUT -j ACCEPT -o tun0 }} into the firewall script, where VPN_GW_IP is the vpn endpoint ip given to me –  strzelecki.maciek Nov 28 '11 at 9:34
    
@user102150, thanks for posting the solution. Can you please edit your comment with proper formatting? Because it is hardly readable. –  Sachin Divekar Nov 28 '11 at 10:48
    
im really sorry but im failing at using the code block, somehow it doesnt want to work for me. AS for reading the mess - every line starts with a word "iptables", its easy to copy and manualy parse it with new lines –  strzelecki.maciek Nov 28 '11 at 14:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.