Issues connecting. Tunnelblick believes that the host is down

[Daniel Ivarsson]

Hi

I've got a weird problem. I try to connect to my OpenVPN server
(version 2.1.0) but Tunnelblick says that the host is down.
If I try to connect from Linux or Windows clients using the same
configuration file, they connect fine. I can also connect to other
services running on the machine from the Internet.

This is the server.conf file:
===================
mode server
tls-server
port-share localhost 4433
dev tap
up "/etc/openvpn/up.sh br0"
down "/etc/openvpn/down.sh br0"
ca ca.crt
dh dh1024.pem
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.0.1.1"
push "route 0.0.0.0 0.0.0.0"
client-to-client
keepalive 10 120
comp-lzo
max-clients 10
user nobody
group nogroup
persist-tun
status openvpn-status.log
===================

client.ovpn:
===================
client
dev tap
remote a_very_hidden_hostname.gotdns.org 443
resolv-retry infinite
nobind
persist-tun
ca ca.crt
cert daniel.crt
key daniel.key
tls-auth ta.key 1
comp-lzo
===================

This is the log file when trying to connect to this server:
===================
2011-01-13 19:39:32 *Tunnelblick: OS X 10.6.6; Tunnelblick 3.1.2
(build 2190.2258); OpenVPN 2.1.4
2011-01-13 19:39:35 *Tunnelblick: Attempting connection with Server;
Set nameserver = 1; not monitoring connection
2011-01-13 19:39:35 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpnstart start Server.tblk 1337 1 0 0 1 50
2011-01-13 19:39:35 OpenVPN 2.1.4 i386-apple-darwin10.5.0 [SSL] [LZO2]
[PKCS11] built on Dec 9 2010
2011-01-13 19:39:35 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2011-01-13 19:39:35 Need hold release from management interface,
waiting...
2011-01-13 19:39:35 MANAGEMENT: Client connected from 127.0.0.1:1337
2011-01-13 19:39:35 MANAGEMENT: CMD 'pid'
2011-01-13 19:39:35 MANAGEMENT: CMD 'state on'
2011-01-13 19:39:35 MANAGEMENT: CMD 'state'
2011-01-13 19:39:35 MANAGEMENT: CMD 'hold release'
2011-01-13 19:39:35 WARNING: No server certificate verification method
has been enabled. See http://openvpn.net/howto.html#mitm for more
info.
2011-01-13 19:39:35 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2011-01-13 19:39:35 Control Channel Authentication: using 'ta.key' as
a OpenVPN static key file
2011-01-13 19:39:35 Outgoing Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2011-01-13 19:39:35 Incoming Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2011-01-13 19:39:35 LZO compression initialized
2011-01-13 19:39:35 Control Channel MTU parms [ L:1576 D:168 EF:68 EB:
0 ET:0 EL:0 ]
2011-01-13 19:39:35 Socket Buffers: R=[262140->65536] S=[131070-
>65536]
2011-01-13 19:39:35 MANAGEMENT: >STATE:1294943975,RESOLVE,,,
2011-01-13 19:39:35 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:
135 ET:32 EL:0 AF:3/1 ]
2011-01-13 19:39:35 Local Options hash (VER=V4): 'e39a3273'
2011-01-13 19:39:35 Expected Remote Options hash (VER=V4): '3c14feac'
2011-01-13 19:39:35 Attempting to establish TCP connection with
111.112.113.114:443 [nonblock]
2011-01-13 19:39:35 MANAGEMENT: >STATE:1294943975,TCP_CONNECT,,,
2011-01-13 19:39:35 TCP: connect to 111.112.113.114:443 failed, will
try again in 5 seconds: Host is down
2011-01-13 19:39:35 *Tunnelblick: openvpnstart: /Applications/
Tunnelblick.app/Contents/Resources/openvpn --cd /Users/daniel/Library/
Application Support/Tunnelblick/Configurations/Server.tblk/Contents/
Resources --daemon --management 127.0.0.1 1337 --config /Users/daniel/
Library/Application Support/Tunnelblick/Configurations/Server.tblk/
Contents/Resources/config.ovpn --log /tmp/tunnelblick/logs/-SUsers-
Sdaniel-SLibrary-SApplication Support-STunnelblick-SConfigurations-
SServer.tblk-SContents-SResources-Sconfig.ovpn.
1_0_0_1_50.1337.openvpn.log --management-query-passwords --management-
hold --script-security 2 --up /Applications/Tunnelblick.app/Contents/
Resources/client.up.tunnelblick.sh -w -d -a --down /Applications/
Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -w -d -a
--up-restart
2011-01-13 19:39:40 MANAGEMENT: >STATE:1294943980,RESOLVE,,,
2011-01-13 19:39:40 MANAGEMENT: >STATE:1294943980,TCP_CONNECT,,,
2011-01-13 19:39:40 TCP: connect to 111.112.113.114:443 failed, will
try again in 5 seconds: Host is down
2011-01-13 19:39:42 SIGTERM[hard,init_instance] received, process
exiting
2011-01-13 19:39:42 MANAGEMENT: >STATE:
1294943982,EXITING,init_instance,,
2011-01-13 19:39:44 *Tunnelblick: Flushed the DNS cache
===================

I can't see why Tunnelblick fails to connect when other clients
succeeds. Maybe someone here has some ideas about what's wrong?

Thanks in advance.
/Daniel

[jkbull...gmail.com]

You are connecting using "Server.tblk". Is that what you want? Does that contain "client.ovpn" -- or does it contain "server.conf"?

Assuming it contains "client.ovpn", I'm puzzled by the fact that your config files don't contain any "proto" options, so the default should be UDP[1],yet the log shows:

2011-01-13 19:39:35 Attempting to establish TCP connection with 111.112.113.114:443 [nonblock] 

so it might be worth putting "proto udp" into your client config and trying that. (Maybe try "proto tcp", too, for completeness!)

[1] From the OpenVPN man page at http://openvpn.net/index.php/open-source/documentation/manuals/69-openvpn-21.html:

--proto p

Use protocol p for communicating with remote host. p can be udp, tcp-client, or tcp-server.

The default protocol is udp when --proto is not specified.

For UDP operation, --proto udp should be specified on both peers.

For TCP operation, one peer must use --proto tcp-server and the other must use --proto tcp-client. A peer started with tcp-server will wait indefinitely for an incoming connection. A peer started with tcp-client will attempt to connect, and if that fails, will sleep for 5 seconds (adjustable via the --connect-retry option) and try again infinite or up to N retries (adjustable via the --connect-retry-max option). Both TCP client and server will simulate a SIGUSR1 restart signal if either side resets the connection.

OpenVPN is designed to operate optimally over UDP, but TCP capability is provided for situations where UDP cannot be used. In comparison with UDP, TCP will usually be somewhat less efficient and less robust when used over unreliable or congested networks.

This article outlines some of problems with tunneling IP over TCP:

http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

There are certain cases, however, where using TCP may be advantageous from a security and robustness perspective, such as tunneling non-IP or application-level UDP protocols, or tunneling protocols which don't possess a built-in reliability layer.