search

berkus / tunnelblick

TunnelBlick configs for OpenVPN on OSX
code.google.com/p/tunnelblick
1 stars 1 forks source link

VPN reconnect every 5 seconds #113

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
3.0b16 works  fine.
3.0b18 reconnect every 5 seconds.
In log I see "event_wait : Interrupted system call (code=4)"

2009-09-28 08:55:20 event_wait : Interrupted system call (code=4)
2009-09-28 08:55:20 
/Applications/Tunnelblick.app/Contents/Resources/client.down.osx.sh tun0 1500 
1541 
10.28.45.126 10.28.45.125 init
2009-09-28 08:55:20  process restarting
2009-09-28 08:55:20 SUCCESS: hold release succeeded
2009-09-28 08:55:20  based on an official port number assignment by IANA. 
 OpenVPN 2.0-
beta16 and earlier used 5000 as the default port.
2009-09-28 08:55:20 NOTE: the current --script-security setting may allow this 
configuration 
to call user-defined scripts
2009-09-28 08:55:20 UDPv4 link local (bound): [undef]:1194
2009-09-28 08:55:20 UDPv4 link remote: ${VPN_HOST_IP}:1194
2009-09-28 08:55:21 [${VPN_HOST}] Peer Connection Initiated with 
${VPN_HOST_IP}:1194
2009-09-28 08:55:22 TUN/TAP device /dev/tun0 opened
2009-09-28 08:55:22 /sbin/ifconfig tun0 delete
2009-09-28 08:55:22 NOTE: Tried to delete pre-existing tun/tap instance -- No 
Problem if 
failure
2009-09-28 08:55:22 /sbin/ifconfig tun0 10.28.45.126 10.28.45.125 mtu 1500 
netmask 
255.255.255.255 up
2009-09-28 08:55:22 
/Applications/Tunnelblick.app/Contents/Resources/client.up.osx.sh tun0 
1500 1541 10.28.45.126 10.28.45.125 init
2009-09-28 08:55:22 Initialization Sequence Completed
2009-09-28 08:55:27 event_wait : Interrupted system call (code=4)
2009-09-28 08:55:27 
/Applications/Tunnelblick.app/Contents/Resources/client.down.osx.sh tun0 1500 
1541 
10.28.45.126 10.28.45.125 init
2009-09-28 08:55:27  process restarting
2009-09-28 08:55:27 SUCCESS: hold release succeeded
2009-09-28 08:55:27  based on an official port number assignment by IANA. 
 OpenVPN 2.0-
beta16 and earlier used 5000 as the default port.
2009-09-28 08:55:27 NOTE: the current --script-security setting may allow this 
configuration 
to call user-defined scripts
2009-09-28 08:55:27 UDPv4 link local (bound): [undef]:1194
2009-09-28 08:55:27 UDPv4 link remote: ${VPN_HOST_IP}:1194
2009-09-28 08:55:28 [${VPN_HOST}] Peer Connection Initiated with 
${VPN_HOST_IP}:1194
2009-09-28 08:55:29 TUN/TAP device /dev/tun0 opened
2009-09-28 08:55:29 /sbin/ifconfig tun0 delete
2009-09-28 08:55:29 NOTE: Tried to delete pre-existing tun/tap instance -- No 
Problem if 
failure
2009-09-28 08:55:29 /sbin/ifconfig tun0 10.28.45.126 10.28.45.125 mtu 1500 
netmask 
255.255.255.255 up
2009-09-28 08:55:29 
/Applications/Tunnelblick.app/Contents/Resources/client.up.osx.sh tun0 
1500 1541 10.28.45.126 10.28.45.125 init
2009-09-28 08:55:29 Initialization Sequence Completed

Original issue reported on code.google.com by bartosz....@gmail.com on 28 Sep 2009 at 10:12

GoogleCodeExporter commented 9 years ago 
I forgot:
MacOS X 10.6.1

Original comment by bartosz....@gmail.com on 28 Sep 2009 at 10:19

GoogleCodeExporter commented 9 years ago 
confirming the issue.

MacOS 10.6.1 with 64bit mode on.

Works fine with b16

Original comment by zbigniew...@gmail.com on 28 Sep 2009 at 8:58

GoogleCodeExporter commented 9 years ago 
I've got the same problem too.
MacOS 10.6.1

Worked in b16
Doesn't work in b18
I think my kernel's in 32bit mode since I haven't done anything special.  Want 
me to
give you a log dump, turn up the logging level, or give you a config dump?

Original comment by kc7...@gmail.com on 30 Sep 2009 at 6:21

GoogleCodeExporter commented 9 years ago 
I also had the same problem with b18 and MacOS 10.6.1.  Unlike the others here, 
I
still had the same problem after downgrading to b16.  However, b10 is working 
for me.

Original comment by emanuel....@gmail.com on 30 Sep 2009 at 6:42

GoogleCodeExporter commented 9 years ago 
A fix for this issue has been committed as r198. It updates three scripts that 
Tunnelblick uses for "Set 
nameserver". The three scripts are contained in the attached .zip file.

To use them, download the file and double-click on it. Drag the three files in 
the folder that is created to 
Tunnelblick.app/Contents/Resources, replacing three older files with the same 
names. You will probably need 
an administrator username/password to do this.

(To get at Tunnelblick.app/Contents, right- or control-click on 
Tunnelblick.app, and click "Show Package 
Contents". The files go in the "Resources" folder inside of "Contents".)

Original comment by jkbull...@gmail.com on 1 Oct 2009 at 4:03

Attachments:

GoogleCodeExporter commented 9 years ago 
still have this problem MacOS 10.5.7 even i checkout source code and compiled.

Original comment by renxiaox...@gmail.com on 6 Oct 2009 at 8:18

GoogleCodeExporter commented 9 years ago 
It is likely something else if it is on 10.5 -- the fix was for 10.6. Do any 
older versions of Tunnelblick work?

Can you attach (in zipped form or some other compressed form) the contents of 
the file /tmp/Tunnelblick-
Leasewatch.log so we can take a look and determine why the script failed to do 
its job?

Thanks.

Original comment by jkbull...@gmail.com on 6 Oct 2009 at 3:12

GoogleCodeExporter commented 9 years ago 
Hi,

I got the same problem, the fix doesn't work ;(. Here the log file.

L.

Original comment by laurent....@gmail.com on 9 Oct 2009 at 8:33

Attachments:

GoogleCodeExporter commented 9 years ago 
renxiaoxian & laurant.seror -

Here are revised scripts to try. Please let us know if they fix the problem.

To use them, download the file and double-click on it. Drag the three files in 
the folder that is created to 
Tunnelblick.app/Contents/Resources, replacing three older files with the same 
names. You will probably need 
an administrator username/password to do this.

(To get at Tunnelblick.app/Contents, right- or control-click on 
Tunnelblick.app, and click "Show Package 
Contents". The files go in the "Resources" folder inside of "Contents".)

Thanks

Original comment by jkbull...@gmail.com on 9 Oct 2009 at 10:24

Attachments:

GoogleCodeExporter commented 9 years ago 
More informations about my MacBook :

Vue d’ensemble du logiciel système :

  Version du système : Mac OS X 10.6.1 (10B504)
  Version du noyau :    Darwin 10.0.0
  Volume de démarrage :    MacHD
  Mode de démarrage :  Normal
  Nom de l’ordinateur :   MacBook Pro de Laurent SEROR
  Nom de l’utilisateur :  Laurent SEROR (laurent)
  Mémoire virtuelle sécurisée :  activée
  Noyau et extensions 64 bits :    Non
  Temps depuis le démarrage :  2:22

I install the b10 version and it is working.
Regards,
L.

Original comment by laurent....@gmail.com on 9 Oct 2009 at 10:47

GoogleCodeExporter commented 9 years ago 
I have a similar issue, but connection keeps of for almost a minute, then it 
dies,
and it takes about another minute for tunnelblick to reopen the tunnel. I had 
the
connection dropping every 5 seconds problem but that went away after using the
revised scripts from comment 9.

here is a snippet from the log:

2009-10-09 16:16:07 /sbin/route add -net 192.168.0.0 172.16.42.5 255.255.255.0
2009-10-09 16:16:07 /sbin/route add -net 172.16.42.1 172.16.42.5 255.255.255.255
2009-10-09 16:16:07 Initialization Sequence Completed
2009-10-09 16:16:07 XXX.XXX.XXX.XXX
2009-10-09 16:18:02  restarting
2009-10-09 16:18:02 TCP/UDP: Closing socket
2009-10-09 16:18:02
/Applications/Tunnelblick.app/Contents/Resources/client.down.osx.sh tun0 1500 
1542
172.16.42.6 172.16.42.5 restart
2009-10-09 16:18:02  process restarting

at the time the connection dies approximately at 16:17:00 there are no entries 
on the
log.

I noticed the connection dieing after about a minute by pinging over the tunnel.
First 49 pings get replied, next to get thru is icmp_seq=111.

Tunnelblick version: 3.0b18
Mac OS X: 10.6.1

so far i've had this problem with every tunnelblick version i've tried.

pete

Original comment by petri.le...@gmail.com on 9 Oct 2009 at 1:32

GoogleCodeExporter commented 9 years ago 
http://jamit.de/2009/10/09/tunnelblick-fur-snow-leopard.html

This should fix the "Set Nameserver" problem. Definitely it fixed it in my 
case. (Snow Leopard with 64bit kernel).

Original comment by phil.bla...@googlemail.com on 9 Oct 2009 at 1:57

GoogleCodeExporter commented 9 years ago 
Anything for the poor 32 bits users ?

Original comment by laurent....@gmail.com on 9 Oct 2009 at 5:55

GoogleCodeExporter commented 9 years ago 
Tunnelblick 3.0b20 has been released and is available on the downloads page:
http://code.google.com/p/tunnelblick/downloads/list

Release Notes are available at:
http://code.google.com/p/tunnelblick/wiki/ReleaseNotes

It includes fixes for problems using "Set nameserver" on Snow Leopard that 
caused VPN reconnects.

Original comment by jkbull...@gmail.com on 9 Oct 2009 at 9:22

GoogleCodeExporter commented 9 years ago 
I can't find the file: /tmp/Tunnelblick-Leasewatch.log

Do I need to activate logging with some command?

I got two machines with OS X 10.5.8 and only _one_ have this reconnect issue 
with b18
(b16 do work fine).

Update:
This post has been in my browser for a couple of hours and now the b20 version 
is out
and installed on both my machines. The problematic machine now has the log file 
in:
/tmp/Tunnelblick-Leasewatch.log. And that log file pointed out that it was the 
WINS
configuration settings that was the culprit. Erased Net-BIOS name under network
preferences and there is now no more reconnects. :)

But still, one machine doesn't have the /tmp/Tunnelblick-Leasewatch.log file in 
it's
place... any thoughts?

Original comment by alexande...@gmail.com on 9 Oct 2009 at 10:20

GoogleCodeExporter commented 9 years ago 
As I understand it, the log is only created and written to if Tunnelblick's 
"leasewatch" script detects a change in 
the network configuration which requires a VPN connection restart.

Original comment by jkbull...@gmail.com on 10 Oct 2009 at 1:24

GoogleCodeExporter commented 9 years ago 
> I have a similar issue, but connection keeps of for almost a minute, then it 
dies,
and it takes about another minute for tunnelblick to reopen the tunnel.

I used to have that problem.  This fixed it (and might be overkill):
*Quit Tunnelblick
*Remove it from the Applications folder
*Restart the computer
*Install Tunnelblick 3.0b20

My config file doesn't include "script-security", "up", or "down".

Original comment by kc7...@gmail.com on 13 Oct 2009 at 12:55

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
My problem is similar. I stay connected mostly but about every minute it 
restarts/resets the connection. It 
only interrupts work for like 5 seconds, but it is annoying. Here is my 
"Details" output when it happends:
2009-10-27 20:33:48 *Tunnelblick: Tunnelblick 3 (3.0b20 build 1206); OpenVPN 2 
(2.1_rc19)
2009-10-27 20:34:32 event_wait : Interrupted system call (code=4)
2009-10-27 20:34:32 TCP/UDP: Closing socket
2009-10-27 20:34:32 
/Applications/Tunnelblick.app/Contents/Resources/client.down.osx.sh tun0 1500 
1542 10.x.x.x 10.x.x.x restart
2009-10-27 20:34:32  process restarting
2009-10-27 20:34:32 
2009-10-27 20:34:32 MANAGEMENT: CMD 'hold release'
2009-10-27 20:34:32 SUCCESS: hold release succeeded
2009-10-27 20:34:32 NOTE: the current --script-security setting may allow this 
configuration to call user-
defined scripts
2009-10-27 20:34:32 Re-using SSL/TLS context
2009-10-27 20:34:32 LZO compression initialized
2009-10-27 20:34:32 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 
EL:0 ]
2009-10-27 20:34:32 
2009-10-27 20:34:32 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 
EL:0 AF:3/1 ]
2009-10-27 20:34:32 tls-client'
2009-10-27 20:34:32 tls-server'
2009-10-27 20:34:32 Local Options hash (VER=V4): '41690919'
2009-10-27 20:34:32 Expected Remote Options hash (VER=V4): '530fdded'
2009-10-27 20:34:32 Socket Buffers: R=[42080->65536] S=[9216->65536]
2009-10-27 20:34:32 UDPv4 link local: [undef]
2009-10-27 20:34:32 UDPv4 link remote: 38.x.x.x:1194
2009-10-27 20:34:32 
2009-10-27 20:34:32 
2009-10-27 20:34:32  sid=02594753 41d9a94a
2009-10-27 20:34:32  <stuff I don't want to share>
2009-10-27 20:34:32 VERIFY OK: nsCertType=SERVER
2009-10-27 20:34:32  <stuff I don't want to share> 
2009-10-27 20:34:33 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 
bit key
2009-10-27 20:34:33 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for 
HMAC authentication
2009-10-27 20:34:33 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 
bit key
2009-10-27 20:34:33 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for 
HMAC authentication
2009-10-27 20:34:33  1024 bit RSA
2009-10-27 20:34:33 [OpenVPN_Server] Peer Connection Initiated with 
38.x.x.x:1194
2009-10-27 20:34:34 
2009-10-27 20:34:34 SENT CONTROL [OpenVPN_Server]: 'PUSH_REQUEST' (status=1)
2009-10-27 20:34:34 ifconfig 10.x.x.x 10.x.x.x'
2009-10-27 20:34:34 OPTIONS IMPORT: timers and/or timeouts modified
2009-10-27 20:34:34 OPTIONS IMPORT: --ifconfig/up options modified
2009-10-27 20:34:34 OPTIONS IMPORT: route options modified
2009-10-27 20:34:34 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options 
modified
2009-10-27 20:34:34 Preserving previous TUN/TAP instance: tun0
2009-10-27 20:34:34 
/Applications/Tunnelblick.app/Contents/Resources/client.up.osx.sh tun0 1500 
1542 
10.x.x.x 10.x.x.x restart
2009-10-27 20:34:34 Initialization Sequence Completed
2009-10-27 20:34:34 38.x.x.x

This is the Tunnelblick-Leasewatch.log when it happens:
Tue Oct 27 20:34:32 MDT 2009: DNS configuration has changed:
--- BEGIN "GOOD" DNS CFG ---
<dictionary> {
  ServerAddresses : <array> {
    0 : 192.x.x.x <my work network>
    1 : 192.x.x.x
  }
  DomainName : openvpn
  SearchDomains : <array> {
    0 : openvpn
  }
}
---- END "GOOD" DNS CFG ----
--- BEGIN CURRENT DNS CFG ---
<dictionary> {
  ServerAddresses : <array> {
    0 : 10.x.x.x <my internal home network>
  }
  DomainName : comcast.net
}
---- END CURRENT DNS CFG ----
Tue Oct 27 20:34:32 MDT 2009: WINS configuration has changed:
--- BEGIN "GOOD" WINS CFG ---
<dictionary> {
  Workgroup : <array> {
    0 : No
    1 : such
    2 : key
  }
  WINSAddresses : <array> {
    0 : 192.x.x.x <work network again>
  }
}
---- END "GOOD" WINS CFG ----
--- BEGIN CURRENT WINS CFG ---
  No such key
---- END CURRENT WINS CFG ----
Tue Oct 27 20:34:32 MDT 2009: Sending USR1 to OpenVPN PID 80667

My machine is Macbook A1181 model, black, Core Duo, 2GB RAM, Mac OS 10.5.8, 
Tunnelblick 3.0b20, newly 
installed.

Thanks,
Jake

Original comment by jake...@gmail.com on 28 Oct 2009 at 2:42

GoogleCodeExporter commented 9 years ago 
same problem here. 

  Model Name:   MacBook Air
  Model Identifier: MacBookAir2,1
  Processor Name:   Intel Core 2 Duo
  Processor Speed:  1.6 GHz
  System Version:   Mac OS X 10.5.8 (9L30)

Sequence: 

2009-10-28 10:49:19  restarting
2009-10-28 10:49:19 TCP/UDP: Closing socket
2009-10-28 10:49:19 /sbin/route delete -net 172.16.2.1 172.16.2.5 
255.255.255.255
2009-10-28 10:49:19 /sbin/route delete -net 172.16.1.0 172.16.2.5 255.255.255.0
2009-10-28 10:49:19 Closing TUN/TAP interface
2009-10-28 10:49:19 
/Applications/Utilities/Tunnelblick.app/Contents/Resources/client.down.osx.sh 
tun0 
1400 1441 172.16.2.6 172.16.2.5 init
2009-10-28 10:49:19 script failed: external program exited with error status: 1

Original comment by fedel...@gmail.com on 28 Oct 2009 at 12:50

GoogleCodeExporter commented 9 years ago 
jake.cf and fedelang:

Are you using DHCP or manual network settings? If not pure DHCP, please read 
"THE "SET NAMESERVER" 
CHECKBOX AND DNS & WINS SETTINGS" in the Using Tunnelblick Wiki at 
http://code.google.com/p/tunnelblick/w/list

Original comment by jkbull...@gmail.com on 28 Oct 2009 at 12:57

GoogleCodeExporter commented 9 years ago 
I assume this is the section you meant in the Using Tunnelblick guide. This is 
what I am doing:
If you are using DHCP, wish to use DNS and WINS servers at the far end of the 
tunnel when connected, and the 
VPN server you are connecting to "pushes" DNS and WINS settings to your client, 
put a check in the "Set 
nameserver" checkbox. (This is the situation for most users.)

I am strictly using DHCP, in fact I created a new setting in Network just to be 
sure. I am using wireless. I can 
send screen captures of my settings if you would like.
My openvpn server has these set in the conf file:
push "dhcp-option DNS 192.x.x.x"
push "dhcp-option WINS 192.x.x.x"
Which tells me it is pushing DNS and WINS.
I have the checkbox selected for Set nameserver.
Just to be thorough here is my client conf:
client
dev tun
proto udp
remote <hostname of vpn> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
ca <my ca>
cert <my cert>
key <my key>
comp-lzo
verb 4
mute 20
dhcp-option DNS 192.x.x.x
#dhcp-option DOMAIN <our domain inside the network>
I still have the problem.

Original comment by jake...@gmail.com on 28 Oct 2009 at 1:53

GoogleCodeExporter commented 9 years ago 
jake.cf - It looks like your DHCP is being renewed, apparently repeatedly. Why?

You might also look at sbolay's last comment on the last page of the discussion 
thread at
http://groups.google.com/group/tunnelblick-
discuss/browse_thread/thread/f164544d49fbd50f/239ebebc06a06079

It contains a work-around for his problem, which may help you.

Original comment by jkbull...@gmail.com on 30 Oct 2009 at 4:22

GoogleCodeExporter commented 9 years ago 
Hello,

I'm having the exact same issue, with two different configuration files, on Mas 
OS X
10.6.2, with Tunnelblick versions b22 as well as latest from SVN.

The client uses DHCP and no search domains like in sbolay's case mentionned in 
the
previous post.

I joined more information attached to this post (console output, config file and
leasewatch log). Tell me if you need anything else to troubleshoot that.

Thanks

Original comment by xrogerma...@gmail.com on 23 Nov 2009 at 4:20

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks for the info; I think it is all we need.

If you can try the latest source (which is what I gather you mean by "as well 
as latest from SVN"), try it with "Set 
nameserver" checked, and the new "Monitor configuration" checkbox NOT checked.

Original comment by jkbull...@gmail.com on 23 Nov 2009 at 5:25

GoogleCodeExporter commented 9 years ago 
Just did the test you suggested with today's source (I didn't have the checkbox
before because I actually checked out the sources last week or so); it fixed the
problem. So I guess something touches my configuration files after the 
connection...
But it's fine now, I don't need live change detection anyway.

Thanks !

Original comment by xrogerma...@gmail.com on 24 Nov 2009 at 1:25

GoogleCodeExporter commented 9 years ago 
The checkbox does not seem to work when in Deploy mode. But maybe it's still a 
work
in progress ?

Original comment by xrogerma...@gmail.com on 24 Nov 2009 at 6:14

GoogleCodeExporter commented 9 years ago 
Thanks, you found a bug. I just committed a fix for it as r289.

(The bug was that, if using Deploy, the "Monitor connection" checkbox was 
always considered checked.)

It all _should_ work.

Original comment by jkbull...@gmail.com on 24 Nov 2009 at 10:34

GoogleCodeExporter commented 9 years ago 
Nice, seems it all works fine now !
Cheers

Original comment by xrogerma...@gmail.com on 25 Nov 2009 at 1:20

GoogleCodeExporter commented 9 years ago 
I still have the same problem (every 3-4 seconds).
mac os x 10.6.2

Original comment by bogdan...@gmail.com on 27 Mar 2010 at 7:36

GoogleCodeExporter commented 9 years ago 
bogdansmc - Does it happen when "Monitor connections" is NOT checked?

Either way, please post the OpenVPN Log output showing a couple of restart 
cycles. Be sure to X out any 
sensitive info.

(To get the OpenVPN Log output, click on the Tunnelblick icon, then on 
"Details...". Select the tab for the 
configuration and copy/paste from the log window.)

Thanks.

Original comment by jkbull...@gmail.com on 27 Mar 2010 at 7:46

GoogleCodeExporter commented 9 years ago 
sorry, everything is working.
My configuration failed because of windows parallels tried to connect at the 
same time. I turned off windows and 
now mac connection works file.

Original comment by bogdan...@gmail.com on 27 Mar 2010 at 8:03

GoogleCodeExporter commented 9 years ago 
Marked as "Fixed" -- unchecking "Monitor connection" solves this problem.

Original comment by jkbull...@gmail.com on 2 Sep 2010 at 1:07