OpenVPN (Tunnelblick) Suddenly Dropping Constantly

[Atrophius]

I've been using Tunnelblick on my Mac for OpenVPN for about a year
now. All of a sudden, this morning, it decided that it was going to
take a nasty turn for the worse with no explanation. Here are the
symptoms I'm seeing:

* I can connect to the VPN fine, initially.
* After about 2 - 5 minutes of no interruption, the connection
suddenly dies.
* I can still see the VPN route using netstat -rn, and Tunnelblick
believes it's still connected.
* No VPN traffic can go through and I can't even ping the VPN gateway.
* Eventually, Tunnelblick will catch on that the connection has died
(usually about 5 - 10 minutes later) and shoot itself to restart and
then the cycle starts over again.

I've tried everything I can think of to figure this one out. I've
completely flushed my system by rebooting and removing Tunnelblick and
all traces of OpenVPN from my system and re-installing from scratch.
No dice, same problem.

I'm at my wits end, because I desperately need to get this fixed as
the VPN is required for me to be able to do my job. Any ideas you have
would be greatly appreciated.

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To post to this group, send email to tunnelbli...@googlegroups.com.
To unsubscribe from this group, send email to tunnelblick-dis...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en.

[jkbull...gmail.com]

When you say "the connection suddenly dies", is there anything unusual
in the Tunnelblick Details... window or the Console log?

If you post the configuration file, and the complete log from the
Tunnelblick Details... window (X out any confidential IP addresses),
it may help.

[Atrophius]

Nothing unusual that I see. Tunnelblick doesn't appear to notice
there's a problem for a long time and then it just restarts suddenly 5
- 10 minutes later and is all good again for the next 2 minutes.

I'm using 3.0b10, by the way. The latest version had problems for me,
so I stuck with what worked (until now). Here's the details for one
connection up until it dies and restarts. It dies like 2 minutes after
it successfully connected and the details don't show anything else
until it restarts a couple more minutes afterward.

Tue 05/04/10 10:35 AM: OpenVPN 2.1_rc15 i386-apple-darwin9.5.0 [SSL]
[LZO2] built on Nov 19 2008
Tue 05/04/10 10:35 AM: MANAGEMENT: TCP Socket listening on
127.0.0.1:1337
Tue 05/04/10 10:35 AM: waiting...
Tue 05/04/10 10:35 AM: MANAGEMENT: Client connected from
127.0.0.1:1337
Wed 12/31/69 07:00 PM: END
Wed 12/31/69 07:00 PM: SUCCESS: hold release succeeded
Tue 05/04/10 10:35 AM: NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
Wed 12/31/69 07:00 PM: but not yet verified
Tue 05/04/10 10:35 AM: WARNING: this configuration may cache passwords
in memory -- use the auth-nocache option to prevent this
Tue 05/04/10 10:35 AM: WARNING: file 'jprivett-desktop.key' is group
or others accessible
Tue 05/04/10 10:35 AM: Control Channel MTU parms [ L:1589 D:138 EF:38
EB:0 ET:0 EL:0 ]
Tue 05/04/10 10:35 AM: Data Channel MTU parms [ L:1589 D:1450 EF:57 EB:
4 ET:32 EL:0 ]
Tue 05/04/10 10:35 AM: Local Options hash (VER=V4): '7778e742'
Tue 05/04/10 10:35 AM: Expected Remote Options hash (VER=V4):
'3c42a582'
Tue 05/04/10 10:35 AM: or --up-delay
Tue 05/04/10 10:35 AM: Socket Buffers: R=[42080->65536] S=[9216-
>65536]
Tue 05/04/10 10:35 AM: UDPv4 link local: [undef]
Tue 05/04/10 10:35 AM: UDPv4 link remote: 69.16.130.6:1194
Tue 05/04/10 10:35 AM:
Tue 05/04/10 10:35 AM:
Tue 05/04/10 10:35 AM: sid=0666815c 2f59cc96
Tue 05/04/10 10:35 AM: /C=US/ST=AZ/L=Phoenix/
O=xxxxxxxxx_Support_OpenVPN/CN=xxxxxxxxx_Support_OpenVPN_CA/
emailAddress=xxxxxxxxx
Tue 05/04/10 10:35 AM: VERIFY OK: nsCertType=SERVER
Tue 05/04/10 10:35 AM: /C=US/ST=AZ/L=Phoenix/
O=xxxxxxxxx_Support_OpenVPN/CN=support/emailAddress=xxxxxxxxx
Tue 05/04/10 10:35 AM: Data Channel Encrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
Tue 05/04/10 10:35 AM: Data Channel Encrypt: Using 160 bit message
hash 'SHA1' for HMAC authentication
Tue 05/04/10 10:35 AM: Data Channel Decrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
Tue 05/04/10 10:35 AM: Data Channel Decrypt: Using 160 bit message
hash 'SHA1' for HMAC authentication
Tue 05/04/10 10:35 AM: 2048 bit RSA
Tue 05/04/10 10:35 AM: [support] Peer Connection Initiated with
xxxxxxxxx:1194
Tue 05/04/10 10:35 AM:
Tue 05/04/10 10:35 AM: SENT CONTROL [support]:
'PUSH_REQUEST' (status=1)
Tue 05/04/10 10:35 AM: ifconfig xxxxxxxxx 255.255.255.192'
Tue 05/04/10 10:35 AM: OPTIONS IMPORT: --ifconfig/up options modified
Tue 05/04/10 10:35 AM: OPTIONS IMPORT: route options modified
Tue 05/04/10 10:35 AM: OPTIONS IMPORT: route-related options modified
Tue 05/04/10 10:35 AM: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
Tue 05/04/10 10:35 AM: ROUTE default_gateway=192.168.10.1
Tue 05/04/10 10:35 AM: TUN/TAP device /dev/tap1 opened
Tue 05/04/10 10:35 AM:
Tue 05/04/10 10:35 AM: /sbin/ifconfig tap1 delete
Tue 05/04/10 10:35 AM: NOTE: Tried to delete pre-existing tun/tap
instance -- No Problem if failure
Tue 05/04/10 10:35 AM: /sbin/ifconfig tap1 xxxxxxxxx netmask
255.255.255.192 mtu 1500 up
Tue 05/04/10 10:35 AM:
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.192.0
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.240.0
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.0.0
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.0.0
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.255.0
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.255.0
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.255.255
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.224.0
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.255.0
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.255.0
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.224.0
Tue 05/04/10 10:35 AM: /sbin/route add -net xxxxxxxxx xxxxxxxxx
255.255.255.255
Tue 05/04/10 10:35 AM: GID set to nobody
Tue 05/04/10 10:35 AM: UID set to nobody
Tue 05/04/10 10:35 AM: Initialization Sequence Completed
Tue 05/04/10 10:35 AM: xxxxxxxxx
Tue 05/04/10 10:39 AM: restarting
Tue 05/04/10 10:39 AM: TCP/UDP: Closing socket
Tue 05/04/10 10:39 AM: process restarting
Tue 05/04/10 10:39 AM:
Wed 12/31/69 07:00 PM: SUCCESS: hold release succeeded
Tue 05/04/10 10:39 AM: NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
Tue 05/04/10 10:39 AM: Re-using SSL/TLS context

I did find this in the system.log, through. May or may not be useful:

May 4 10:35:04 Argontia openvpn[809]: MANAGEMENT: >STATE:
1272983704,CONNECTED,SUCCESS,xxxxxxxxxxx,xxxxxxxxxx
May 4 10:39:03 Argontia openvpn[809]: [support] Inactivity timeout (--
ping-restart), restarting
May 4 10:39:03 Argontia openvpn[809]: TCP/UDP: Closing socket
May 4 10:39:03 Argontia openvpn[809]: SIGUSR1[soft,ping-restart]
received, process restarting
May 4 10:39:03 Argontia openvpn[809]: MANAGEMENT: >STATE:
1272983943,RECONNECTING,ping-restart,,

And here's my config file:

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
dev tap1
;dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one. On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.

# Are we connecting to a TCP or
# UDP server? Use the same setting as
# on the server.
;proto tcp
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
#
# Use this entry for public IP pool
remote xxxxxxxxxx 1194
# Use this entry for nat'd private IP pool (remember to change proto
to tcp)
;remote xxxxxxxxxx443

# Choose a random host from the remote
# list for load-balancing. Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here. See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets. Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description. It's best to use
# a separate .crt/.key file pair
# for each client. A single ca
# file can be used for all clients.
ca ca.crt
cert jprivett-desktop.crt
key jprivett-desktop.key

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server". This is an
# important precaution to protect against
# a potential attack discussed here:
# http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server". The build-key-server
# script in the easy-rsa folder will do this.
ns-cert-type server

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
cipher AES-256-CBC

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
;comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20


Thanks for your help.

[jkbull...gmail.com]

If I understand the situation, you were actively using the VPN after
it connected:

Tue 05/04/10 10:35 AM: Initialization Sequence Completed
Tue 05/04/10 10:35 AM: xxxxxxxxx

for a couple of minutes, then the connection "went dead" for a couple
of minutes, then OpenVPN noticed the "inactivity" and restarted the
connection:

May 4 10:39:03 Argontia openvpn[809]: [support] Inactivity
timeout (--ping-restart), restarting

So we understand why it is restarting. So the question is, why is the
connection "going dead".

But before that, is it really dead, or is there a DNS problem? Try
(during the time it appears to be "dead") going to "http://
66.249.81.104", which is a www.google.com address. If that works, it
is a DNS problem. If not, then the connection probably is "dead".

[Atrophius]

Well, the VPN is configured to only have connections to IPs within our
subnets get routed across it, so pinging the Google IP wouldn't help.
But, it doesn't appear to be a DNS problem because when it happens I
can't even ping the VPN's gateway IP address.

On May 4, 11:49 am, "jkbull...gmail.com" <jkbull...@gmail.com> wrote:
> If I understand the situation, you were actively using the VPN after
> it connected:
>
>      Tue 05/04/10 10:35 AM: Initialization Sequence Completed
>      Tue 05/04/10 10:35 AM: xxxxxxxxx
>
> for a couple of minutes, then the connection "went dead" for a couple
> of minutes, then OpenVPN noticed the "inactivity" and restarted the
> connection:
>
>      May  4 10:39:03 Argontia openvpn[809]: [support] Inactivity
> timeout (--ping-restart), restarting
>
> So we understand why it is restarting. So the question is, why is the
> connection "going dead".
>
> But before that, is it really dead, or is there a DNS problem? Try
> (during the time it appears to be "dead") going to "http://

> 66.249.81.104", which is awww.google.comaddress. If that works, it

[jkbull...gmail.com]

Yes, but try Google anyway, via name and IP address, from a browser.
Maybe DNS is getting routed to the VPN, too. Anyway, it will verify
that the routing is working properly and that the problem is in the
VPN, and not your Mac generally.

Is DHCP renewing on a very short schedule? (Like every two minutes?)

There's not much more I can think of -- it is a problem between
OpenVPN on your computer and the OpenVPN server. And all the routers,
etc. between them.

BTW, the "user nobody" and "group nobody" options in your
configuration file will not work with down scripts (including the one
used by Tunnelblick's "Set nameserver" checkbox is checked) unless set
up properly. See the last comment in the discussion at
http://groups.google.com/group/tunnelblick-discuss/browse_thread/thread/21f3c92e08f16485

[Atrophius]

Arrrrgghhh. I just realized that my machine at home is still
connecting to the VPN and is auto-reconnecting every time it gets
kicked off. I have two separate VPN keys for the two machines and
apparently this machine somehow got the wrong key on it.

I put the right key on it and voila. No more problems.

Sorry for the noise.

On May 4, 1:09 pm, "jkbull...gmail.com" <jkbull...@gmail.com> wrote:
> Yes, but try Google anyway, via name and IP address, from a browser.
> Maybe DNS is getting routed to the VPN, too. Anyway, it will verify
> that the routing is working properly and that the problem is in the
> VPN, and not your Mac generally.
>
> Is DHCP renewing on a very short schedule? (Like every two minutes?)
>
> There's not much more I can think of -- it is a problem between
> OpenVPN on your computer and the OpenVPN server. And all the routers,
> etc. between them.
>
> BTW, the "user nobody" and "group nobody" options in your
> configuration file will not work with down scripts (including the one
> used by Tunnelblick's "Set nameserver" checkbox is checked) unless set

> up properly. See the last comment in the discussion athttp://groups.google.com/group/tunnelblick-discuss/browse_thread/thre...

[Ron Cemer]

Tunnelblick team, there needs to be a clear, concise fix for this issue.  Tunnelblick itself is useless if it can't stay connected to a VPN server when literally EVERY OTHER OpenVPN client can.  Fix it, post the fix, and let's be done with this once and for all.  After switching from Linux to MacOS, I am one of many users who are plagued by this issue.  Let's take it more seriously, or if we can't, then let's go ahead and admit defeat, and shut down Tunnelblick as a project, as it is only polluting the Google search results when someone searches for an OpenVPN client for MacOS.

[Tunnelblick developer]

I'm afraid there's no "this issue" to fix. Lots of different problems can cause "Suddenly dropping constantly", which is the problem that Atrophius was having. It turns out he was using the same security key to connect to his VPN from two different computers, and the VPN was set up to not allow that. He could have either modified the setup to allow that (it's an OpenVPN option), or he could use the correct (different) key on each computer. He did the latter. Problem solved.

If you have the same problem (multiple computers using the same security key), try a similar solution.

If you have a different problem, please start a new conversation and post the diagnostic info obtained by following the instructions at Read Before You Post (https://tunnelblick.net/cBeforeYouPost.html).