Tunnelblick Drops connection?
Silm
I am running OS X 10.6.2 and Tunnelblick 3.0.
For months, Tunnelblick has worked fine. Recently, however, I am
having problems with dropped connections.
Specifically. When I connect to the VPN (over a wireless connection),
the connection works fine for a minute or two and then drops.
Moreover, my (wireless) Internet connection no longer works, even
though it shows as connected (and with very strong signal).
The moment I disconnect Tunnelblick the wireless connection springs
back into life and I can browse quite happily.
There seems to be some kind of conflict going on. Anyone seen similar?
Thanks,
Steve.
jkbull...gmail.com
show up on the OpenVPN Log in the Details.. window? How about the
console log?
When you say "The moment I disconnect Tunnelblick the wireless
connection springs back", do you mean when you disconnect the VPN or
when you quit Tunnelblick?
If by "dropped connections" you mean that there is no response (you
can't surf the web) but it returns when you disconnect from the VPN,
that sounds like a problem with the VPN server (i.e., the computer at
the other end of the tunnel).
To eliminate one other possibility, you might try downgrading
Tunnelblick to the version you were using successfully (Tunnelblick
3.0 was only released last week, so you haven't been using it for
months). Get old versions of Tunnelblick by going to the downloads
page. In the drop-down box next to "Search", select "Deprecated
downloads", then click the "Search" button. If you know when you first
downloaded Tunnelblick, that will tell you which version you
downloaded originally (and which worked for you).
Please let us know what happens.
bhyland
although I have never used an older client.
I know it cannot be a problem with the vpn server or the local network
quality as both are shared by many other clients running a wide
variety of different environments without issues.
I've not seen anything particularly interesting in the log (up to
verbosity 8).
If you can make any suggestions to help diagnose what's going with
this version I'd be happy to try them.
regards
Ben
jkbull...gmail.com
original post, I don't know what "similar symptoms" means : )
To help find out what is going on, please post the entire OpenVPN Log
of a session (verbosity 3 should provide enough detail without being
too long). X-out anything sensitive.
If you can indicate at what point the problems appear to occur, and
what the problems are, that will help, too.
bhyland
What seems to be happening is that I lose connectivity to the vpn and
because I am relying on vpn dns for all resolution it looks like I
lose connectivity to the internet also. However I can still ping
internet servers by ip so it I think it is a vpn issue only. After
some time (tens of seconds to a minute or two), the vpn and/or
Tunnelblick recovers, so it looks like I was mistaken in thinking this
a bug. Iit is not the case that restarting Tunnelblick is a required
workaround (although this is quicker than waiting).
I'm still not sure why the vpn appears to drop out in the first place
though.
Here is a complete log anyway; as you can see nothing much happens
after initialisation.
Thanks for your time.
Ben
2010-03-12 11:23:45 *Tunnelblick: OS X 10.6.2; Tunnelblick 3.0 (build
1437); OpenVPN 2.1.1
2010-03-12 11:23:52 *Tunnelblick: Attempting connection with
ovpn.conf; Set nameserver = 1; not monitoring connection
2010-03-12 11:23:52 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpnstart start ovpn.conf 1337 1 0 0 1
2010-03-12 11:23:53 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpn --management-query-passwords --cd /Users/
Ben/Library/Application Support/Tunnelblick/Configurations --daemon --
management-hold --management 127.0.0.1 1337 --config /Users/Ben/
Library/Application Support/Tunnelblick/Configurations/ovpn.conf --
script-security 2 --up "/Applications/Tunnelblick.app/Contents/
Resources/client.nomonitor.up.osx.sh" --down "/Applications/
Tunnelblick.app/Contents/Resources/client.nomonitor.down.osx.sh" --up-
restart
2010-03-12 11:23:53 SUCCESS: pid=15152
2010-03-12 11:23:53 SUCCESS: real-time state notification set to ON
2010-03-12 11:23:53 SUCCESS: real-time log notification set to ON
2010-03-12 11:23:52 OpenVPN 2.1.1 i386-apple-darwin10.2.0 [SSL] [LZO2]
[PKCS11] built on Feb 24 2010
2010-03-12 11:23:52 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2010-03-12 11:23:52 waiting...
2010-03-12 11:23:53 MANAGEMENT: Client connected from 127.0.0.1:1337
2010-03-12 11:23:53 MANAGEMENT: CMD 'pid'
2010-03-12 11:23:53 MANAGEMENT: CMD 'state on'
2010-03-12 11:23:53 MANAGEMENT: CMD 'log on all'
2010-03-12 11:23:53 END
2010-03-12 11:23:53 MANAGEMENT: CMD 'hold release'
2010-03-12 11:23:53 SUCCESS: hold release succeeded
2010-03-12 11:23:53 MANAGEMENT: CMD 'username "Auth" "xxxx"'
2010-03-12 11:23:53 but not yet verified
2010-03-12 11:23:53 MANAGEMENT: CMD 'password [...]'
2010-03-12 11:23:53 but not yet verified
2010-03-12 11:23:53 WARNING: No server certificate verification method
has been enabled. See http://openvpn.net/howto.html#mitm for more
info.
2010-03-12 11:23:53 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2010-03-12 11:23:53 Control Channel Authentication: using '/Users/Ben/
Library/Application Support/Tunnelblick/Configurations/key.key' as a
OpenVPN static key file
2010-03-12 11:23:53 Outgoing Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2010-03-12 11:23:53 Incoming Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2010-03-12 11:23:53 LZO compression initialized
2010-03-12 11:23:53 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:
0 ET:0 EL:0 ]
2010-03-12 11:23:53
2010-03-12 11:23:53 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:
135 ET:32 EL:0 AF:3/1 ]
2010-03-12 11:23:53 Local Options hash (VER=V4): '13a273ba'
2010-03-12 11:23:53 Expected Remote Options hash (VER=V4): '360696c5'
2010-03-12 11:23:53 Socket Buffers: R=[42080->65536] S=[9216->65536]
2010-03-12 11:23:53 UDPv4 link local: [undef]
2010-03-12 11:23:53 UDPv4 link remote: XXXX:XX
2010-03-12 11:23:53
2010-03-12 11:23:53
2010-03-12 11:23:53 sid=664ca77e 93c5da70
2010-03-12 11:23:53 WARNING: this configuration may cache passwords in
memory -- use the auth-nocache option to prevent this
2010-03-12 11:23:53 /C=XX/ST=XXXX/L=XXXX/O=XXXX/CN=XXXX_CA/
emailAddress=XXXX
2010-03-12 11:23:53 /C=XX/ST=XXXX/L=XXXX/O=XXXX/CN=server/
emailAddress=XXXX
2010-03-12 11:23:53 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2010-03-12 11:23:53 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2010-03-12 11:23:53 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2010-03-12 11:23:53 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2010-03-12 11:23:53 1024 bit RSA
2010-03-12 11:23:53 [server] Peer Connection Initiated with XXXX:XX
2010-03-12 11:23:54
2010-03-12 11:23:55 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2010-03-12 11:23:55 ifconfig XXXX 255.255.255.0'
2010-03-12 11:23:55 OPTIONS IMPORT: --ifconfig/up options modified
2010-03-12 11:23:55 OPTIONS IMPORT: route options modified
2010-03-12 11:23:55 OPTIONS IMPORT: route-related options modified
2010-03-12 11:23:55 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2010-03-12 11:23:55 ROUTE default_gateway=172.20.1.254
2010-03-12 11:23:55 TUN/TAP device /dev/tap0 opened
2010-03-12 11:23:55
2010-03-12 11:23:55 /sbin/ifconfig tap0 delete
2010-03-12 11:23:55 NOTE: Tried to delete pre-existing tun/tap
instance -- No Problem if failure
2010-03-12 11:23:55 /sbin/ifconfig tap0 XXXX netmask 255.255.255.0 mtu
1500 up
2010-03-12 11:23:55 /Applications/Tunnelblick.app/Contents/Resources/
client.nomonitor.up.osx.sh tap0 1500 1574 XXXX 255.255.255.0 init
2010-03-12 11:23:55
2010-03-12 11:23:55 /sbin/route add -net XXXX XXXX 255.255.0.0
2010-03-12 11:23:55 /sbin/route add -net XXXX XXXX 255.255.255.0
2010-03-12 11:23:55 Initialization Sequence Completed
2010-03-12 11:23:55 XXXX
2010-03-12 11:25:07 Replay-window backtrack occurred [2]
jkbull...gmail.com
IP. Can you ping servers in the local network at the far end of the
VPN? Maybe you're losing DNS, but not connectivity in general.
Try connecting with "Monitor connection" checked. It will put entries
into the log when a network interface change occurs. (And it will
force a restart, but we don't care about that, we just want to see if
there are network interface changes.) The post the part of the log
after "Initialization Sequence Completed ".
Also, you might try Tunnelblick version 3.0b10, available at
http://tunnelblick.googlecode.com/files/Tunnelblick_3.0b10.dmg
Just drag the Tunnelblick.app icon in the disk image to your Desktop
or some other convenient place and run it from there; you don't have
to replace the newer version that is (I assume) installed in /
Applications.
Also, some tap connections are problematic; can you try tun?
> has been enabled. Seehttp://openvpn.net/howto.html#mitmfor more
bhyland
I can't run with 'monitor connection' checked as something in the
local net here triggers a restart every few seconds - this situation
is mentioned but not explained in the Tunnelblick docs.
I don't think I can use tun because of the firewall rules we have set.
I still think my issue is probably not related to Tunnelblick after
all, although many thanks for following this up.
My current thought is that the local dhcp lease is very short and is
blatting my resolv.conf every so often when it renews.
I'm going to manually set this and prevent changes and see whether it
improves matters.
I don't think this will fix everything since if this were the only
issue I would expect still to be able to ping servers at the far end
of the vpn by ip address.
thanks and regards
Ben
> ...
>
> read more »
jkbull...gmail.com
repeated restarts (just kill it after a cycle or two), but I want to
see the messages that describe _why_ it restarted -- they may be a
clue as to what is going on.
> ...
>
> read more »
lumin...@gmail.com
tried with monitor connection turned on.
It no longer restarts the vpn every few seconds.
However, the latest blip lasted about 5 mins and there was nothing
whatsoever printed in the log for the entire duration.
Sorry :(
> --
> 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
occurred while running with "Monitor connection" checked. That's
interesting. You should keep "Monitor connection" checked, just to be
sure, while you try other things.
And I assume that before the blip and after the blip resolves itself
you _can_ ping servers at the far end of the vpn (not just Internet
servers).
If so, I can't think of anything else to try. As I said before, tap
connections can be problematic. I've never been able to track down the
problem because I don't have access to a tap server.
By the way, on OS X, resolv.conf is really just a read-only copy of
part of the "system configuration". man scutil for more details. (This
is different from Unix.)
If/When you do resolve the problem, please post here about it, you
might help someone else.
On Mar 12, 9:35 am, luminoc...@gmail.com wrote:
> Something local has changed (or I changed something) since I last
> tried with monitor connection turned on.
> It no longer restarts the vpn every few seconds.
> However, the latest blip lasted about 5 mins and there was nothing
> whatsoever printed in the log for the entire duration.
> Sorry :(
>
> ...
>
> read more »
jkbull...gmail.com
Tunnelbick version 3.0b10 (link in my earlier post in this
discussion).
Viscosity, which is not free but it is inexpensive and I think there
is a free trial period.
If either one solves the problem, please post to let us know.
> ...
>
> read more »
lumin...@gmail.com
Thanks for the suggestions.
I'll check back later to let you know what happens.
Neal Tyrone
Tried Viscosity and I have the exact same problem. I'd like to point
out that the VPN server is confirmed working by other users. Here's
the log on mine:
2010-03-13 08:17:08 *Tunnelblick: OS X 10.5.8; Tunnelblick 3.0 (build
1437); OpenVPN 2.1.1
2010-03-13 08:17:19 *Tunnelblick: Attempting connection with
client.conf; Set nameserver = 1; monitoring connection
2010-03-13 08:17:19 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpnstart start client.conf 1337 1 0 0 0
2010-03-13 08:17:19 *Tunnelblick: /Applications/Tunnelblick.app/
Contents/Resources/openvpn --management-query-passwords --cd /Users/
USER/Library/Application Support/Tunnelblick/Configurations --daemon --
management-hold --management 127.0.0.1 1337 --config /Users/USER/
Library/Application Support/Tunnelblick/Configurations/client.conf --
script-security 2 --up "/Applications/Tunnelblick.app/Contents/
Resources/client.up.osx.sh" --down "/Applications/Tunnelblick.app/
Contents/Resources/client.down.osx.sh" --up-restart
2010-03-13 08:17:19 SUCCESS: pid=41236
2010-03-13 08:17:19 SUCCESS: real-time state notification set to ON
2010-03-13 08:17:19 SUCCESS: real-time log notification set to ON
2010-03-13 08:17:19 OpenVPN 2.1.1 i386-apple-darwin10.2.0 [SSL] [LZO2]
[PKCS11] built on Feb 24 2010
2010-03-13 08:17:19 MANAGEMENT: TCP Socket listening on 127.0.0.1:1337
2010-03-13 08:17:19 waiting...
2010-03-13 08:17:19 MANAGEMENT: Client connected from 127.0.0.1:1337
2010-03-13 08:17:19 MANAGEMENT: CMD 'pid'
2010-03-13 08:17:19 MANAGEMENT: CMD 'state on'
2010-03-13 08:17:19 MANAGEMENT: CMD 'log on all'
2010-03-13 08:17:19 END
2010-03-13 08:17:19 MANAGEMENT: CMD 'hold release'
2010-03-13 08:17:19 SUCCESS: hold release succeeded
2010-03-13 08:17:19 NOTE: the current --script-security setting may
allow this configuration to call user-defined scripts
2010-03-13 08:17:19 WARNING: file 'keys/X.key' is group or others
accessible
2010-03-13 08:17:19 WARNING: file 'keys/XX.key' is group or others
accessible
2010-03-13 08:17:19 Control Channel Authentication: using 'keys/
XX.key' as a OpenVPN static key file
2010-03-13 08:17:19 Outgoing Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2010-03-13 08:17:19 Incoming Control Channel Authentication: Using 160
bit message hash 'SHA1' for HMAC authentication
2010-03-13 08:17:19 LZO compression initialized
2010-03-13 08:17:19 Control Channel MTU parms [ L:1542 D:166 EF:66 EB:
0 ET:0 EL:0 ]
2010-03-13 08:17:19
2010-03-13 08:17:19 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:
135 ET:0 EL:0 AF:3/1 ]
2010-03-13 08:17:19 Local Options hash (VER=V4): '504e774e'
2010-03-13 08:17:19 Expected Remote Options hash (VER=V4): '14168603'
2010-03-13 08:17:20 Socket Buffers: R=[42080->65536] S=[9216->65536]
2010-03-13 08:17:20 UDPv4 link local: [undef]
2010-03-13 08:17:20 UDPv4 link remote: X.X.X.X:XXXX
2010-03-13 08:17:20
2010-03-13 08:17:25
2010-03-13 08:17:25 sid=faf2f4e8 dd97157f
2010-03-13 08:17:30 /C=XX/ST=XXX/L=XXXX/O=XXXXX/CN=XXXXX_CA/
emailAddress=XXXXXX
2010-03-13 08:17:30 VERIFY OK: nsCertType=SERVER
2010-03-13 08:17:30 /C=XX/ST=XXX/L=XXXX/O=XXXXX/CN=SERVER/
emailAddress=XXXXXX
2010-03-13 08:17:38 Data Channel Encrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2010-03-13 08:17:38 Data Channel Encrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2010-03-13 08:17:38 Data Channel Decrypt: Cipher 'BF-CBC' initialized
with 128 bit key
2010-03-13 08:17:38 Data Channel Decrypt: Using 160 bit message hash
'SHA1' for HMAC authentication
2010-03-13 08:17:38 2048 bit RSA
2010-03-13 08:17:38 [SERVER] Peer Connection Initiated with
X.X.X.X:XXXX
2010-03-13 08:17:40
2010-03-13 08:17:41 SENT CONTROL [SERVER]: 'PUSH_REQUEST' (status=1)
2010-03-13 08:17:41 ifconfig X.X.X.X X.X.X.X'
2010-03-13 08:17:41 OPTIONS IMPORT: timers and/or timeouts modified
2010-03-13 08:17:41 OPTIONS IMPORT: --ifconfig/up options modified
2010-03-13 08:17:41 OPTIONS IMPORT: route options modified
2010-03-13 08:17:41 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option
options modified
2010-03-13 08:17:41 ROUTE default_gateway=192.168.1.1
2010-03-13 08:17:41 TUN/TAP device /dev/tun0 opened
2010-03-13 08:17:41
2010-03-13 08:17:41 /sbin/ifconfig tun0 delete
2010-03-13 08:17:41 NOTE: Tried to delete pre-existing tun/tap
instance -- No Problem if failure
2010-03-13 08:17:41 /sbin/ifconfig tun0 X.X.X.X X.X.X.X mtu 1500
netmask 255.255.255.255 up
2010-03-13 08:17:41 /Applications/Tunnelblick.app/Contents/Resources/
client.up.osx.sh tun0 1500 1542 X.X.X.X X.X.X.X init
2010-03-13 08:17:41 /sbin/route add -net X.X.X.X 192.168.1.1
255.255.255.255
2010-03-13 08:17:41 /sbin/route add -net 0.0.0.0 X.X.X.X 128.0.0.0
2010-03-13 08:17:41 /sbin/route add -net 128.0.0.0 X.X.X.X 128.0.0.0
2010-03-13 08:17:41
2010-03-13 08:17:41 /sbin/route add -net X.X.X.X X.X.X.X
255.255.255.255
2010-03-13 08:17:41 Initialization Sequence Completed
2010-03-13 08:17:41 X.X.X.X
Thanks lots for the help.
> ...
>
> read more »
jkbull...gmail.com
A critical issue is whether it is able to resolve names (like
google.com) into IP addresses (like 1.2.3.4). That's done by Domain
Name Servers (DNS).
If you can "ping" addresses at the other end of the VPN using their IP
address then you have a DNS problem, and the connection itself is OK.
When connected, use Network Utility.app (it's in /Applications/
Utilities). Click the "Ping" tab, and enter 208.67.217.231 as the
network address to ping, then click the "Ping" button.
If that works, replace 208.67.217.231 with www.google.com as the
network address and click "Ping" button again.
Let us know what happens.
> ...
>
> read more »
zphelj
regularly. After some basic troubleshooting and retesting on my home
network here is what I believe is happening in my case. Note: I can
ping addresses, it's DNS resolution that is broken.
1) Macbook connects to WiFi network and pulls IP, gateway, DNS
settings.
2) I launch Tunnelblick and establish a link to my OpenVPN server
(hosted on a linode). That changes routes and updates DNS (using DHCP
option to direct DNS to my OpenVPN server connection for the best
compatibility)
3) All is well for a few minutes until half the DHCP lease time
expires (short lease times at T-Mobile hotspost's apparently)
4) Macbook renews the lease, as it should, however the the DNS servers
are replaced with T-Mobiles
5) All subsequent DNS requests go to an IP address that will no longer
respond to requests. This is likely because T-Mobile's servers won't
accept requests from outside the network.
I am using dhcp-option DNS xxx.xxx.xxx.xxx to point to my linode
servers in my configurate. That works initially but once step 4
(lease renew occurs) it's being overridden.
I first noticed this about 4 months ago when I started using
Tunnelblick. I also tried Viscosity at that time and it did not have
this problem so I'm fairly certain this is manageable in some sane way
in the client. Monitor connection was not stable at the time though
I've not tried it recently.
*Tunnelblick: OS X 10.6.2; Tunnelblick 3.0 (build 1437); OpenVPN 2.1.1
Jason Fehrs
champ.
Sent from my iPhone, please excuse any typos.
bhyland
My network admins had set up both static and dynamic ip allocations on
the vpn. I only just started working from a different location and
mine was the computer which first overlapped ips with someone else.
The intermittent connectivity problem was caused because whichever of
us connected to the vpn most recently would kick the other one off.
Nothing to do with Tunnelblick; I appreciate the time spent to help me
out.
For the record I tried both the b10 version and Viscosity before
figuring this out and neither of them provided any extra help in
diagnosis.
One other point to note for anyone else struggling with diagnosis of
this sort of thing, (yes, captain obvious...) - it's a good idea to
flush your dns cache whenever you try something new, to make sure your
ping checks are telling you the truth.
cheers and good luck
On Mar 12, 3:09 pm, luminoc...@gmail.com wrote:
> Sorry if I wasn't clear; your assumptions are correct.
> Thanks for the suggestions.
> I'll check back later to let you know what happens.
>
> ...
>
> read more »
Silm
original post. My excuses are few - save that managed to solve the
problem (and so the urgency of replying went away).
In the end it was almost embarrassingly simple, and tunnelblick is
blame-free. I, less so.
In short - I had only recently begun to use a Mac laptop at Home,
using tunnelblick to connect to the VPN. I had though, for over a
year, been using my iMac to connect to the same VPN.
(you can see where this is going...)
The iMac was configured (apparently) to _auto-re-connect_ in the event
of a dropped connection. Thus, my Mac laptop was able to connect
briefly to the VPN up until the iMac choose to re-connect, at which
point there was a conflict and my laptop connection no longer worked.
I can't explain why this conflict caused my general (laptop) Internet
connection to drop (until I disabled Tunnelblick on the laptop). But,
I can confirm that shutting down Tunnelblick on my iMac resolved the
problem.
Thanks, and apologies again. Hopefully somebody else will read this
and recognize the same symptoms.
Steve.
