Tunnelblick reconnects every minute?

[Erich Weiler]

Hi Y'all,

I've got this odd problem I'm trying to sort out. I used to have
tunnelblick 3.1.2 on OS 10.4, worked great. I then migrated to 10.6,
and now I'm seeing this odd problem where the connection establishes
OK, then I lose connectivity, then I see tunnelblick reconnect. The
connection restores for about one minute, then goes dead again, then
tunnelblick reconnects again. Ad nauseum. Here's the config:

client
dev tun
proto udp
cipher AES-256-CBC
remote 11.22.33.44 4444
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca /Users/bob/XYZ-CA.crt
cert /Users/bob/bob.crt
key /Users/bob/bob.key
tls-auth /Users/bob/static.key 1
comp-lzo
verb 3
mute 20
auth-user-pass
tls-remote fw.my.com

And what happens in the log repeatedly (notice at 2011-01-11 21:33:09
it restarts, that happens every minute or two):

2011-01-11 21:31:24 [fw.my.com] Inactivity timeout (--ping-restart),
restarting
2011-01-11 21:31:24 TCP/UDP: Closing socket
2011-01-11 21:31:24 /Applications/Tunnelblick.app/Contents/Resources/
client.down.tunnelblick.sh -m -w -d tun0 1500 1558 172.30.0.30
172.30.0.29 restart
2011-01-11 21:31:24 *Tunnelblick client.down.tunnelblick.sh: Cancelled
monitoring of system configuration changes
2011-01-11 21:31:25 SIGUSR1[soft,ping-restart] received, process
restarting
2011-01-11 21:31:25 MANAGEMENT: >STATE:1294810285,RECONNECTING,ping-
restart,,
2011-01-11 21:31:25 MANAGEMENT: CMD 'hold release'
2011-01-11 21:31:25 WARNING: Make sure you understand the semantics of
--tls-remote before using it (see the man page).
2011-01-11 21:31:25 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2011-01-11 21:31:25 Re-using SSL/TLS context
2011-01-11 21:31:25 LZO compression initialized
2011-01-11 21:31:25 Control Channel MTU parms [ L:1558 D:166 EF:66 EB:
0 ET:0 EL:0 ]
2011-01-11 21:31:25 Socket Buffers: R=[42080->65536] S=[9216->65536]
2011-01-11 21:31:25 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:
135 ET:0 EL:0 AF:3/1 ]
2011-01-11 21:31:25 Local Options hash (VER=V4): '9e7066d2'
2011-01-11 21:31:25 Expected Remote Options hash (VER=V4): '162b04de'
2011-01-11 21:31:25 UDPv4 link local: [undef]
2011-01-11 21:31:25 UDPv4 link remote: 11.22.33.44:4444
2011-01-11 21:31:25 MANAGEMENT: >STATE:1294810285,WAIT,,,
2011-01-11 21:31:25 MANAGEMENT: >STATE:1294810285,AUTH,,,
2011-01-11 21:31:25 TLS: Initial packet from 11.22.33.44:4444,
sid=63e0aae3 31822368
2011-01-11 21:31:25 WARNING: this configuration may cache passwords in
memory -- use the auth-nocache option to prevent this
2011-01-11 21:31:25 VERIFY OK: depth=1, /C=US/ST=California/L=SomeTown/
O=MyGroup/emailAddress=sup...@my.com/CN=XYZ-CA
2011-01-11 21:31:25 VERIFY X509NAME OK: /C=US/ST=California/O=MyGroup/
CN=fw.my.com
2011-01-11 21:31:25 VERIFY OK: depth=0, /C=US/ST=California/O=MyGroup/
CN=fw.my.com
2011-01-11 21:31:25 Data Channel Encrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
2011-01-11 21:31:25 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-01-11 21:31:25 Data Channel Decrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
2011-01-11 21:31:25 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-01-11 21:31:25 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-
AES256-SHA, 1024 bit RSA
2011-01-11 21:31:25 [fw.my.com] Peer Connection Initiated with
11.22.33.44:4444
2011-01-11 21:31:25 *Tunnelblick client.down.tunnelblick.sh: Restored
the DNS and WINS configurations
2011-01-11 21:31:26 MANAGEMENT: >STATE:1294810286,GET_CONFIG,,,
2011-01-11 21:31:27 SENT CONTROL [fw.my.com]:
'PUSH_REQUEST' (status=1)
2011-01-11 21:31:27 PUSH: Received control message: 'PUSH_REPLY,route
172.16.0.0 255.255.0.0,dhcp-option DOMAIN kilokluster.ucsc.edu,dhcp-
option DNS 128.114.48.44,redirect-gateway def1,route
172.30.0.1,topology net30,ping 10,ping-restart 60,ifconfig 172.30.0.30
172.30.0.29'
2011-01-11 21:31:27 OPTIONS IMPORT: timers and/or timeouts modified
2011-01-11 21:31:27 OPTIONS IMPORT: --ifconfig/up options modified
2011-01-11 21:31:27 OPTIONS IMPORT: route options modified
2011-01-11 21:31:27 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2011-01-11 21:31:27 Preserving previous TUN/TAP instance: tun0
2011-01-11 21:31:27 /Applications/Tunnelblick.app/Contents/Resources/
client.up.tunnelblick.sh -m -w -d tun0 1500 1558 172.30.0.30
172.30.0.29 restart
No such key
2011-01-11 21:31:27 Initialization Sequence Completed
2011-01-11 21:31:27 MANAGEMENT: >STATE:1294810287,CONNECTED,SUCCESS,
172.30.0.30,11.22.33.44
2011-01-11 21:31:27 *Tunnelblick client.up.tunnelblick.sh: Up to two
'No such key' warnings are normal and may be ignored
2011-01-11 21:31:27 *Tunnelblick client.up.tunnelblick.sh: Saved the
DNS and WINS configurations for later use
2011-01-11 21:31:27 *Tunnelblick client.up.tunnelblick.sh: Set up to
monitor system configuration with leasewatch
2011-01-11 21:31:27 *Tunnelblick: Flushed the DNS cache
2011-01-11 21:31:32 *Tunnelblick leasewatch: A system configuration
change was ignored because it was not relevant
2011-01-11 21:33:09 [fw.my.com] Inactivity timeout (--ping-restart),
restarting
2011-01-11 21:33:09 TCP/UDP: Closing socket
2011-01-11 21:33:09 /Applications/Tunnelblick.app/Contents/Resources/
client.down.tunnelblick.sh -m -w -d tun0 1500 1558 172.30.0.30
172.30.0.29 restart
2011-01-11 21:33:09 SIGUSR1[soft,ping-restart] received, process
restarting
2011-01-11 21:33:09 MANAGEMENT: >STATE:1294810389,RECONNECTING,ping-
restart,,
2011-01-11 21:33:09 MANAGEMENT: CMD 'hold release'
2011-01-11 21:33:09 WARNING: Make sure you understand the semantics of
--tls-remote before using it (see the man page).
2011-01-11 21:33:09 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2011-01-11 21:33:09 Re-using SSL/TLS context
2011-01-11 21:33:09 LZO compression initialized
2011-01-11 21:33:09 Control Channel MTU parms [ L:1558 D:166 EF:66 EB:
0 ET:0 EL:0 ]
2011-01-11 21:33:09 Socket Buffers: R=[42080->65536] S=[9216->65536]
2011-01-11 21:33:09 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:
135 ET:0 EL:0 AF:3/1 ]
2011-01-11 21:33:09 Local Options hash (VER=V4): '9e7066d2'
2011-01-11 21:33:09 Expected Remote Options hash (VER=V4): '162b04de'
2011-01-11 21:33:09 UDPv4 link local: [undef]
2011-01-11 21:33:09 UDPv4 link remote: 11.22.33.44:4444
2011-01-11 21:33:09 MANAGEMENT: >STATE:1294810389,WAIT,,,
2011-01-11 21:33:09 MANAGEMENT: >STATE:1294810389,AUTH,,,
2011-01-11 21:33:09 TLS: Initial packet from 11.22.33.44:4444,
sid=dc3ff38e 07fb3f11
2011-01-11 21:33:09 WARNING: this configuration may cache passwords in
memory -- use the auth-nocache option to prevent this
2011-01-11 21:33:09 VERIFY OK: depth=1, /C=US/ST=California/L=SomeTown/
O=MyGroup/emailAddress=sup...@my.com/CN=XYZ-CA
2011-01-11 21:33:09 VERIFY X509NAME OK: /C=US/ST=California/O=MyGroup/
CN=fw.my.com
2011-01-11 21:33:09 VERIFY OK: depth=0, /C=US/ST=California/O=MyGroup/
CN=fw.my.com
2011-01-11 21:33:09 Data Channel Encrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
2011-01-11 21:33:09 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-01-11 21:33:09 Data Channel Decrypt: Cipher 'AES-256-CBC'
initialized with 256 bit key
2011-01-11 21:33:09 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2011-01-11 21:33:09 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-
AES256-SHA, 1024 bit RSA
2011-01-11 21:33:09 [fw.my.com] Peer Connection Initiated with
11.22.33.44:4444
2011-01-11 21:33:09 *Tunnelblick client.down.tunnelblick.sh: Cancelled
monitoring of system configuration changes
2011-01-11 21:33:09 *Tunnelblick client.down.tunnelblick.sh: Restored
the DNS and WINS configurations
2011-01-11 21:33:10 MANAGEMENT: >STATE:1294810390,GET_CONFIG,,,
2011-01-11 21:33:11 SENT CONTROL [fw.my.com]:
'PUSH_REQUEST' (status=1)
2011-01-11 21:33:11 PUSH: Received control message: 'PUSH_REPLY,route
172.16.0.0 255.255.0.0,dhcp-option DOMAIN kilokluster.ucsc.edu,dhcp-
option DNS 128.114.48.44,redirect-gateway def1,route
172.30.0.1,topology net30,ping 10,ping-restart 60,ifconfig 172.30.0.30
172.30.0.29'
2011-01-11 21:33:11 OPTIONS IMPORT: timers and/or timeouts modified
2011-01-11 21:33:11 OPTIONS IMPORT: --ifconfig/up options modified
2011-01-11 21:33:11 OPTIONS IMPORT: route options modified
2011-01-11 21:33:11 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2011-01-11 21:33:11 Preserving previous TUN/TAP instance: tun0
2011-01-11 21:33:11 /Applications/Tunnelblick.app/Contents/Resources/
client.up.tunnelblick.sh -m -w -d tun0 1500 1558 172.30.0.30
172.30.0.29 restart
No such key
2011-01-11 21:33:11 Initialization Sequence Completed
2011-01-11 21:33:11 MANAGEMENT: >STATE:1294810391,CONNECTED,SUCCESS,
172.30.0.30,11.22.33.44
2011-01-11 21:33:11 *Tunnelblick client.up.tunnelblick.sh: Up to two
'No such key' warnings are normal and may be ignored
2011-01-11 21:33:11 *Tunnelblick client.up.tunnelblick.sh: Saved the
DNS and WINS configurations for later use
2011-01-11 21:33:11 *Tunnelblick client.up.tunnelblick.sh: Set up to
monitor system configuration with leasewatch
2011-01-11 21:33:11 *Tunnelblick: Flushed the DNS cache
2011-01-11 21:33:16 *Tunnelblick leasewatch: A system configuration
change was ignored because it was not relevant

Any idea what could be happening? It seemed to work fine before on
10.4, are there any known issues with 10.6? BTW - I have "Monitor
Connection" checked. If I uncheck it, my connection goes dead, and
stays dead, no reconnect attempts are made by tunnelblick....

[Jonathan K. Bullard]

I think this is a firewall problem of some sort. Pings don't seem to be getting through.

The problem is indicated here:

2011-01-11 21:33:09 SIGUSR1[soft,ping-restart] received, process restarting

This says that the connection is being restarted because of a "ping-restart".

"Ping-restart" is being pushed by the server:

2011-01-11 21:31:27 SENT CONTROL [fw.my.com]: 'PUSH_REQUEST' (status=1)

2011-01-11 21:31:27 PUSH: Received control message: 'PUSH_REPLY,route172.16.0.0 255.255.0.0,dhcp-option DOMAIN kilokluster.ucsc.edu,dhcp-option DNS 128.114.48.44,redirect-gateway def1,route 172.30.0.1,topology net30,ping 10,ping-restart 60,ifconfig 172.30.0.30 172.30.0.29'

The "ping 10,ping-restart" causes a ping (from the client to the server, I think) every ten seconds, and tells the client to restart the connection if it hasn't received a reply to the ping within 60 seconds. It looks like that's what is happening.

I'm not sure if the ping is sent from the server to the client, but I think that's how it works -- do you have "Block all incoming connections" checked (in System Preferences | Security | Firewall | Advanced)? Maybe that is causing it. You might try (as an experiment) to uncheck it and see if the problem goes away. Then I think you can add Tunnelblick to the list of programs that can accept incoming connections (although that isn't usually necessary, maybe because most people don't have "ping-restart"?) but I am not absolutely sure that will work. It might be worth a try, though.

--
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.

[Erich Weiler]

Man, I just don't know what's up here. I checked the firewall on my
laptop - disabled. I tried downgrading to the last beta of
tunnelblick, no go. The only things that have changed between this
working and not working was:

1: I upgraded from 10.4 to 10.6
2: I moved to a new MacBook Pro (using the migration assistant, all
apps were copied over)

Something changed here.... Others are using tunnelblick OK without
this problem. Other OpenVPN clients (like from linux) have no
problems. OpenVPN server (pfSense project) has been remained the same
throughout. :(

[jkbull...gmail.com]

Hmmm. So you switched to a different computer and a different operating system. Should have worked but...

This seems to be a network/OpenVPN problem, not a Tunnelblick (GUI) problem, but if you want to completely uninstall Tunnelblick and then reinstall it, maybe that would help.

Make a backup first, in case there are problems, then do the following:

1. Make sure none of your configurations are set to automatically launch "when computer starts".

2. Backup:

Copy the following to the Desktop (or somewhere else convenient) in case you need them later:

/Library/Application Support/Tunnelblick (folder)

/Users/__your-username__/Library/Application Support/Tunnelblick/Configurations (folder)

/Users/__your-username__/Library/Preferences/com.openvpn.tunnelblick.plist (file)

3. Uninstall:

Drag the following to the Trash, then empty the Trash

/Applications/Tunnelblick.app

/Library/Application Support/Tunnelblick (folder)

/Users/__your-username__/Library/Application Support/Tunnelblick/Configurations (folder)

/Users/__your-username__/Library/Preferences/com.openvpn.tunnelblick.plist (file)

4. Download the latest version of Tunnelblick, double-click the .dmg file, then double-click the Tunnelblick icon in the new window that appears. You'll be guided through the process of adding your configuration files (and key and certificate files), which you can get from the backup copy you made in step 2. above.

You may have to change the options shown on the Details… page, such as "Set nameserver" and "Monitor connection". 

If this doesn't help, you may have to delete and reestablish your network interfaces or something, but I don't know enough about that to help.

[Erich Weiler]

Thanks-

I tried uninstalling per your directions and re-installing, no love.
I also brought in another laptop (MacBook, OS 10.4) and installed
tunnelblick 3.1.2 on it and I'm experiencing the same problem. So,
it's not the laptop itself or the OS version. Yet, other out there
connect to this same VPN server with tunnelblick 3.1.2 as well with no
problems, the connection is stable.

I ruled out my wireless router by connecting directly to the DSL
modem, same thing happens there, so that rules out a problem with the
wireless router.

It is interesting to note that when I connect, the connection is live
for almost exactly 60 seconds, then the connection drops. 60 seconds
after that, tunnleblick notices the connection has dropped and
restarts, after which I have 60 seconds of 'live' uptime before the
connection drops again, and the cycle continues. So, I don't think it
is tunnelblick's fault exactly, because my connection drops long
before tunnelblick notices and restarts it. But it is VERY odd that
my connection is live for exactly 60 seconds before dropping. At the
moment the connection goes dead, nothing is logged in the tunnelblick
logs, so tunnelblick definitely doesn't notice it. If my DSL
connection was flaky I could believe there would be problems since I'm
using UDP to the OpenVPN server, but I don't think that's it, since I
see the connection drop after 60 seconds exactly, it is the same every
time.

I guess I need to try this at some other location, like a neighbor's
house that uses a different ISP or something. I called my ISP (a
local mom-and-pop ISP) and they had no idea what I was talking about
(not surprising). But the precise regularity at which the connection
drops (60 seconds exactly) makes me think there is some problem with
the router at the ISP. I don't know yet for sure.

All I know is that it was working a week ago and now it's not. I feel
like I'm searching for a needle in a haystack. ;)

[jkbull...gmail.com]

The regularity comes because the config file tells OpenVPN to disconnect if it goes 60 seconds without a ping from the server. It looks like the pings aren't getting through.

Can you try a computer (laptop, preferably!) that works from somewhere else, and see if it works at your home? Or, as you say, try one of the non-working pair somewhere where other computers can stay connected?

The only other thing I can think of is to try putting "ping-restart 0" in your client config. That should turn it off completely.

[Erich Weiler]

Heads up, I found the answer to my problem... I had my office desktop
connected to the VPN for the past week. When I tried to connect from
home from my laptop, my laptop at home and my dekstop at work were
competing for the same OpenVPN session and they were kicking each
other off every minute, then reconnecting. I confirmed this was the
problem after I disconnected from the VPN at work, then tunnelblick
became stable again. Tricky little problem! But at least I'll know
how to recognize it in the future.

Thanks again for your help!

[Goldstein]

Hi there,

I had same issue. I tried to change all parameters in Tunnelblick and Pfsense firewall but no success.

Finally, reading this post I decided to reboot Pfsense and problem was solved.

Maybe one session got stuck on the server.

Thanks!!

p.s. Mac OS Mojave 10.14.6 and Tunnelblick 3.8.1