Something very wrong - disconnecting and not reconnecting

[Christopher Laprise]

Hi again,

I thought I would give this list one more try:

The link to the remote server initially works but I keep getting
disconnected (usually at around 10 min.). The VPN says 'server timeout'
and just gives up. AFAIK the client is supposed to keep re-reconnecting
after getting disconnected. When I connect to the same server locally
using the private LAN address, I can physically interrupt the link and
the client will keep trying to reconnect seemingly forever... Yet
remotely it will NEVER attempt to reconnect.

These unannounced, unmitigated disconnections are a breach of security.

The client configs for local and remote are identical except for the
server address. I have not set any kind of timeout on the server end.

I also tried making a tblk package containing a 'reconnecting.sh' script
but it seems to be ignored.

Here is the TB log:

2011-04-17 01:34:11 *Tunnelblick: OS X 10.5.8; Tunnelblick 3.1.7 (build
2190.2413); OpenVPN 2.1.4
2011-04-17 01:34:26 *Tunnelblick: Attempting connection with
serverremote; Set nameserver = 3; monitoring connection
2011-04-17 01:34:26 *Tunnelblick:
/Applications/Tunnelblick.app/Contents/Resources/openvpnstart start
serverremote.tblk 1337 3 0 0 0 49
2011-04-17 01:34:26 *Tunnelblick: kextload:
/Applications/Tunnelblick.app/Contents/Resources/tun.kext loaded
successfully
2011-04-17 01:34:26 OpenVPN 2.1.4 i386-apple-darwin10.7.1 [SSL] [LZO2]
[PKCS11] built on Mar 1 2011
2011-04-17 01:34:26 WARNING: No server certificate verification method
has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2011-04-17 01:34:26 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2011-04-17 01:34:26 LZO compression initialized
2011-04-17 01:34:26 NOTE: UID/GID downgrade will be delayed because of
--client, --pull, or --up-delay
2011-04-17 01:34:26 UDPv4 link local: [undef]
2011-04-17 01:34:26 UDPv4 link remote: x.x.x.x:xxxx
2011-04-17 01:34:26 *Tunnelblick: openvpnstart:
/Applications/Tunnelblick.app/Contents/Resources/openvpn --cd
/Users/user/Library/Application
Support/Tunnelblick/Configurations/serverremote.tblk/Contents/Resources
--daemon --management 127.0.0.1 1337 --config
/Users/user/Library/Application
Support/Tunnelblick/Configurations/serverremote.tblk/Contents/Resources/config.ovpn
--log /Library/Application
Support/Tunnelblick/Logs/-SUsers-Suser-SLibrary-SApplication
Support-STunnelblick-SConfigurations-Sserverremote.tblk-SContents-SResources-Sconfig.ovpn.3_0_0_0_49.1337.openvpn.log
--management-query-passwords --management-hold --script-security 2 --up
/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m
-w -d --plugin
/Applications/Tunnelblick.app/Contents/Resources/openvpn-down-root.so
/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh
-m -w -d --up-restart
2011-04-17 01:34:27 [server] Peer Connection Initiated with x.x.x.x:xxxx
2011-04-17 01:34:29 TUN/TAP device /dev/tun0 opened
2011-04-17 01:34:29 /sbin/ifconfig tun0 delete
2011-04-17 01:34:29 NOTE: Tried to delete pre-existing tun/tap instance
-- No Problem if failure
2011-04-17 01:34:29 /sbin/ifconfig tun0 10.5.0.3 10.5.0.3 netmask
255.255.255.0 mtu 1500 up
add net 10.5.0.0: gateway 10.5.0.3
2011-04-17 01:34:30
/Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -m
-w -d tun0 1500 1558 10.5.0.3 255.255.255.0 init
route: writing to routing
socket: File exists
add net x.x.x.x: gateway
172.1.1.2: File exists
add net 0.0.0.0: gateway 10.5.0.1
add net 128.0.0.0: gateway 10.5.0.1
2011-04-17 01:34:30 GID set to nobody
2011-04-17 01:34:30 UID set to nobody
2011-04-17 01:34:30 Initialization Sequence Completed
2011-04-17 01:34:30 *Tunnelblick client.up.tunnelblick.sh: No network
configuration changes need to be made
2011-04-17 01:34:30 *Tunnelblick client.up.tunnelblick.sh: Will NOT
monitor for other network configuration changes
2011-04-17 01:34:30 *Tunnelblick: Flushed the DNS cache
2011-04-17 01:44:35 [server] Inactivity timeout (--ping-restart), restarting
2011-04-17 01:44:35 SIGUSR1[soft,ping-restart] received, process restarting
2011-04-17 01:44:35 WARNING: No server certificate verification method
has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2011-04-17 01:44:35 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2011-04-17 01:44:35 Re-using SSL/TLS context
2011-04-17 01:44:35 LZO compression initialized
2011-04-17 01:44:35 UDPv4 link local: [undef]
2011-04-17 01:44:35 UDPv4 link remote: x.x.x.x:xxxx
2011-04-17 01:44:36 [server] Peer Connection Initiated with x.x.x.x:xxxx
2011-04-17 01:44:38 Preserving previous TUN/TAP instance: tun0
2011-04-17 01:44:38 PLUGIN_CALL: plugin function PLUGIN_UP failed with
status 1:
/Applications/Tunnelblick.app/Contents/Resources/openvpn-down-root.so
2011-04-17 01:44:38 ERROR: up/down plugin call failed
2011-04-17 01:44:38 Exiting
route:
must be root to alter routing table
2011-04-17 01:44:38 ERROR: OS X route delete command failed: external
program exited with error status: 77
route: must be root to alter
routing table
2011-04-17 01:44:38 ERROR: OS X route delete command failed: external
program exited with error status: 77
route: must be root to alter
routing table
2011-04-17 01:44:38 ERROR: OS X route delete command failed: external
program exited with error status: 77
2011-04-17 01:44:38 *Tunnelblick: Flushed the DNS cache

[jkbull...gmail.com]

There is more than one problem here.

First, the "reconnecting.sh" script is only available in Tunnelblick 3.2beta02 and later, so it was never triggered (assuming you were still using Tunnelblick 3.1.7).

Second, "Monitor connection" only works with "Set nameserver", not with "Set nameserver (3.0b10)" or "Set nameserver (alternate 1)". If this isn't in the documentation, I apologize (and I'll put it in). The program should also warn you about this situation (and I gather it doesn't, so I'll look at that, too).

Third, my understanding is that if you are using "user nobody" and "group nobody", OpenVPN will not be able to reconnect all by itself. That's what you see in the log -- the up plugin fails because it "must be root to alter routing table".

Fourth, why is it losing the connection after ten minutes in the first place? If there isn't any such timeout in the OpenVPN setup, then perhaps a router between Tunnelblick and the OpenVPN server is losing the connection. I'm a bit fuzzy on this, but I think it can involve a stateful packet inspector in the router not updating its tables when there isn't traffic. Maybe you need to add the --ping option to the client configuration to keep traffic flowing so the router(s) update their stateful packet inspection info. Such a router problem may be the reason why you see different behavior when you are connected locally.

When you are connected locally and physically disrupt the link, does it successfully reconnect if you restore the link?

Some things to try:

1. Use "Set nameserver" instead of "Set nameserver (alternate 1)".
2. Add a "ping 30" option to the client configuration.
3. Remove "user nobody" and "group nobody" and remove the Tunnelblick preference involved (see https://groups.google.com/d/msg/tunnelblick-discuss/rOpsNIoyOmY/OwQYsP4FDMEJ).

[Christopher Laprise]

Thanks JK...

I see that disabling 'nobody' on the client and deleting that TB pref
allow reconnection to take place. (I'm not local now so can't test again
to see if could reconnect fully.)

Not specifying options to produce pings was an omission on my part
(stateful routers, yes). Adding them does seem to make the connection
last much longer (haven't seen it drop with the couple tests I made).
However, I need to address the overall issue of not reconnecting and/or
letting traffic escape when something does terminate a VPN connection,
so I may try the TB beta unless you can suggest an alternative.