TunnelBlick fails to reconnect. Get "Cannot resolve host address"

[PaulT]

Hi All,

[This is on a MacAir OSX10.10.3, TB 3.5.0 (build 4265)]

TB starts, connects, and then works well. Lots of traffic is going across the connection.

But after a while (under half an hour in the logs below) it disconnects and is unable to re-establish connection.

The logs show it connected at 7:08, then the connection dropped at 7:30. 

Before the failure - it was working fully.

2015-05-06 07:08:07 *Tunnelblick: This computer's apparent public IP address changed from XXX.XXX.XXX.XXX before connection to 46.246.42.195 after connection
2015-05-06 07:30:01 [fiekohphuphi.openvpn.ipredator.se] Inactivity timeout (--ping-restart), restarting
2015-05-06 07:30:01 SIGUSR1[soft,ping-restart] received, process restarting
2015-05-06 07:30:01 MANAGEMENT: >STATE:1430854201,RECONNECTING,ping-restart,,
2015-05-06 07:30:01 MANAGEMENT: CMD 'hold release'
2015-05-06 07:30:01 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2015-05-06 07:30:01 Socket Buffers: R=[196724->65536] S=[9216->65536]
2015-05-06 07:30:01 MANAGEMENT: >STATE:1430854201,RESOLVE,,,
2015-05-06 07:30:32 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known
2015-05-06 07:30:32 MANAGEMENT: >STATE:1430854232,RESOLVE,,,
2015-05-06 07:31:03 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known
2015-05-06 07:31:38 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known

The last line repeats for the next 30 minutes until I manually disconnect.

After that manual disconnect, I *can* ping pw.openvpn.ipredator.se with no problems.

I can also reconnect, and everything works fine again, for a while.

The drop at exactly 7:30 is pretty suspicious. I'm wondering if my ISP is trying to discourage the use of proxies by sending

or doing something.

The full log, down to and including the failure is below.

Any hints or advice would be gratefully accepted.

Paul.

*Tunnelblick: OS X 10.10.3; Tunnelblick 3.5.0 (build 4265); prior version 3.4.4 (build 4055.4236); Admin user
Configuration IPredator
"Sanitized" condensed configuration file for /Users/Paul/Library/Application Support/Tunnelblick/Configurations/IPredator.tblk:
client
dev tun0
proto udp
remote pw.openvpn.ipredator.se 1194
resolv-retry infinite
nobind
auth-user-pass
auth-retry nointeract
ca [inline]
tls-client
tls-auth [inline]
ns-cert-type server
keepalive 10 30
cipher AES-256-CBC
tls-cipher TLSv1:!ADH:!SSLv2:!NULL:!EXPORT:!DES:!LOW:!MEDIUM:@STRENGTH
persist-key
persist-tun
comp-lzo
tun-mtu 1500
mssfix
verb 3
<ca>
[Security-related line(s) omitted]
</ca>
<tls-auth>
[Security-related line(s) omitted]
</tls-auth>

===============================================================================
"Sanitized" full configuration file

client
dev tun0
proto udp
remote pw.openvpn.ipredator.se 1194
resolv-retry infinite
nobind
auth-user-pass
auth-retry nointeract
ca [inline]
tls-client
tls-auth [inline]
ns-cert-type server
keepalive 10 30
cipher AES-256-CBC
tls-cipher TLSv1:!ADH:!SSLv2:!NULL:!EXPORT:!DES:!LOW:!MEDIUM:@STRENGTH
persist-key
persist-tun
comp-lzo
tun-mtu 1500
mssfix
verb 3

<ca>
 [Security-related line(s) omitted]
</ca>

<tls-auth>
 [Security-related line(s) omitted]
</tls-auth>

================================================================================

There are no unusual files in IPredator.tblk

================================================================================

Configuration preferences:

-routeAllTrafficThroughVpn = 1
-keychainHasUsernameAndPassword = 1
-openvpnVersion = -
-notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0
-keepConnected = 1
-lastConnectionSucceeded = 1

================================================================================

Wildcard preferences:

-notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0

================================================================================

Program preferences:

placeIconInStandardPositionInStatusBar = 1
launchAtNextLogin = 1
notOKToCheckThatIPAddressDidNotChangeAfterConnection = 0
askedUserIfOKToCheckThatIPAddressDidNotChangeAfterConnection = 1
tunnelblickVersionHistory = (
    "3.5.0 (build 4265)",
    "3.4.4 (build 4055.4236)",
    "3.4.3 (build 4055.4198)",
    "3.4.2 (build 4055.4161)",
    "3.4.1 (build 4054)",
    "3.4.0 (build 4007)",
    "3.4beta36 (build 3945)",
    "3.4beta34 (build 3935)",
    "3.4beta32 (build 3904)",
    "3.4beta30 (build 3893)"
)
statusDisplayNumber = 0
lastLaunchTime = 452516708.845653
showConnectedDurations = 1
connectionWindowDisplayCriteria = showWhenConnecting
maxLogDisplaySize = 10485760
lastConnectedDisplayName = IPredator
keyboardShortcutIndex = 1
updateCheckAutomatically = 1
updateSendProfileInfo = 0
NSWindow Frame SettingsSheetWindow = 316 227 829 424 0 0 1440 877
NSWindow Frame ConnectingWindow = 525 518 389 187 0 0 1440 877
NSWindow Frame SUStatusFrame = 648 675 384 129 0 0 1680 1027
detailsWindowFrameVersion = 4265
detailsWindowFrame = {{262, 308}, {912, 467}}
detailsWindowLeftFrame = {{0, 0}, {163, 350}}
leftNavSelectedDisplayName = IPredator
haveDealtWithSparkle1dot5b6 = 1
haveDealtWithOldTunTapPreferences = 1
haveDealtWithOldLoginItem = 1
SUEnableAutomaticChecks = 1
SUFeedURL = https://www.tunnelblick.net/appcast-s.rss
SUScheduledCheckInterval = 86400
SUSendProfileInfo = 0
SULastCheckTime = 2015-05-05 19:27:19 +0000
SUHasLaunchedBefore = 1
WebKitDefaultFontSize = 11
WebKitStandardFont = .Helvetica Neue DeskInterface

================================================================================

Tunnelblick Log:


2015-05-06 07:07:42 *Tunnelblick: OS X 10.10.3; Tunnelblick 3.5.0 (build 4265); prior version 3.4.4 (build 4055.4236)
2015-05-06 07:07:43 *Tunnelblick: Attempting connection with IPredator using shadow copy; Set nameserver = 1; monitoring connection
2015-05-06 07:07:43 *Tunnelblick: openvpnstart start IPredator.tblk 1337 1 0 1 0 17200 -ptADGNWradsgnw 2.3.6
2015-05-06 07:07:44 *Tunnelblick: openvpnstart log:
     OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):
     
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.6/openvpn
          --daemon
          --log
          /Library/Application Support/Tunnelblick/Logs/-SUsers-SPaul-SLibrary-SApplication Support-STunnelblick-SConfigurations-SIPredator.tblk-SContents-SResources-Sconfig.ovpn.1_0_1_0_17200.1337.openvpn.log
          --cd
          /Library/Application Support/Tunnelblick/Users/Paul/IPredator.tblk/Contents/Resources
          --config
          /Library/Application Support/Tunnelblick/Users/Paul/IPredator.tblk/Contents/Resources/config.ovpn
          --cd
          /Library/Application Support/Tunnelblick/Users/Paul/IPredator.tblk/Contents/Resources
          --management
          127.0.0.1
          1337
          --management-query-passwords
          --management-hold
          --redirect-gateway
          def1
          --script-security
          2
          --up
          /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -d -f -m -w -ptADGNWradsgnw
          --down
          /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -d -f -m -w -ptADGNWradsgnw


2015-05-06 07:07:43 OpenVPN 2.3.6 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Apr  3 2015
2015-05-06 07:07:43 library versions: OpenSSL 1.0.1m 19 Mar 2015, LZO 2.08
2015-05-06 07:07:43 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337
2015-05-06 07:07:43 Need hold release from management interface, waiting...
2015-05-06 07:07:43 *Tunnelblick: openvpnstart starting OpenVPN
2015-05-06 07:07:44 *Tunnelblick: Established communication with OpenVPN
2015-05-06 07:07:44 *Tunnelblick: Obtained VPN username and password from the Keychain
2015-05-06 07:07:44 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337
2015-05-06 07:07:44 MANAGEMENT: CMD 'pid'
2015-05-06 07:07:44 MANAGEMENT: CMD 'state on'
2015-05-06 07:07:44 MANAGEMENT: CMD 'state'
2015-05-06 07:07:44 MANAGEMENT: CMD 'bytecount 1'
2015-05-06 07:07:44 MANAGEMENT: CMD 'hold release'
2015-05-06 07:07:44 MANAGEMENT: CMD 'username "Auth" "the_gander"'
2015-05-06 07:07:44 MANAGEMENT: CMD 'password [...]'
2015-05-06 07:07:44 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2015-05-06 07:07:44 No valid translation found for TLS cipher 'TLSv1'
2015-05-06 07:07:44 No valid translation found for TLS cipher '!ADH'
2015-05-06 07:07:44 No valid translation found for TLS cipher '!SSLv2'
2015-05-06 07:07:44 No valid translation found for TLS cipher '!NULL'
2015-05-06 07:07:44 No valid translation found for TLS cipher '!EXPORT'
2015-05-06 07:07:44 No valid translation found for TLS cipher '!DES'
2015-05-06 07:07:44 No valid translation found for TLS cipher '!LOW'
2015-05-06 07:07:44 No valid translation found for TLS cipher '!MEDIUM'
2015-05-06 07:07:44 No valid translation found for TLS cipher '@STRENGTH'
2015-05-06 07:07:44 Control Channel Authentication: tls-auth using INLINE static key file
2015-05-06 07:07:44 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2015-05-06 07:07:44 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2015-05-06 07:07:44 Socket Buffers: R=[196724->65536] S=[9216->65536]
2015-05-06 07:07:44 MANAGEMENT: >STATE:1430852864,RESOLVE,,,
2015-05-06 07:07:45 UDPv4 link local: [undef]
2015-05-06 07:07:45 UDPv4 link remote: [AF_INET]46.246.42.130:1194
2015-05-06 07:07:45 MANAGEMENT: >STATE:1430852865,WAIT,,,
2015-05-06 07:07:45 MANAGEMENT: >STATE:1430852865,AUTH,,,
2015-05-06 07:07:45 TLS: Initial packet from [AF_INET]46.246.42.130:1194, sid=695b938c caf98fb1
2015-05-06 07:07:45 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2015-05-06 07:07:48 VERIFY OK: depth=1, C=SE, ST=Bryggland, L=Oeldal, O=Royal Swedish Beer Squadron, OU=Internetz, CN=Royal Swedish Beer Squadron A, emailAddress=hostmaster@ipredator.se
2015-05-06 07:07:48 VERIFY OK: nsCertType=SERVER
2015-05-06 07:07:48 VERIFY OK: depth=0, C=SE, ST=Bryggland, L=Oeldal, O=Royal Swedish Beer Squadron, CN=fiekohphuphi.openvpn.ipredator.se, emailAddress=hostmaster@ipredator.se
2015-05-06 07:07:49 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2015-05-06 07:07:49 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2015-05-06 07:07:49 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2015-05-06 07:07:49 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2015-05-06 07:07:49 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 3559 bit RSA
2015-05-06 07:07:49 [fiekohphuphi.openvpn.ipredator.se] Peer Connection Initiated with [AF_INET]46.246.42.130:1194
2015-05-06 07:07:51 MANAGEMENT: >STATE:1430852871,GET_CONFIG,,,
2015-05-06 07:07:52 SENT CONTROL [fiekohphuphi.openvpn.ipredator.se]: 'PUSH_REQUEST' (status=1)
2015-05-06 07:07:52 PUSH: Received control message: 'PUSH_REPLY,route 46.246.42.130 255.255.255.255 net_gateway,route-gateway 46.246.42.1,redirect-gateway def1,topology subnet,dhcp-option DOMAIN ipredator.se,dhcp-option DNS 46.246.46.46,dhcp-option DNS 194.132.32.23,ip-win32 dynamic,ping 10,ping-restart 60,explicit-exit-notify 3,ifconfig 46.246.42.195 255.255.255.0'
2015-05-06 07:07:52 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:8: ip-win32 (2.3.6)
2015-05-06 07:07:52 OPTIONS IMPORT: timers and/or timeouts modified
2015-05-06 07:07:52 OPTIONS IMPORT: explicit notify parm(s) modified
2015-05-06 07:07:52 OPTIONS IMPORT: --ifconfig/up options modified
2015-05-06 07:07:52 OPTIONS IMPORT: route options modified
2015-05-06 07:07:52 OPTIONS IMPORT: route-related options modified
2015-05-06 07:07:52 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2015-05-06 07:07:52 WARNING: potential conflict between --remote address [46.246.42.130] and --ifconfig address pair [46.246.42.195, 255.255.255.0] -- this is a warning only that is triggered when local/remote addresses exist within the same /24 subnet as --ifconfig endpoints. (silence this warning with --ifconfig-nowarn)
2015-05-06 07:07:52 Opening utun (connect(AF_SYS_CONTROL)): Resource busy
2015-05-06 07:07:52 Opening utun (connect(AF_SYS_CONTROL)): Resource busy
2015-05-06 07:07:52 Opened utun device utun2
2015-05-06 07:07:52 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
2015-05-06 07:07:52 MANAGEMENT: >STATE:1430852872,ASSIGN_IP,,46.246.42.195,
2015-05-06 07:07:52 /sbin/ifconfig utun2 delete
                                        ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2015-05-06 07:07:52 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2015-05-06 07:07:52 /sbin/ifconfig utun2 46.246.42.195 46.246.42.195 netmask 255.255.255.0 mtu 1500 up
2015-05-06 07:07:52 /sbin/route add -net 46.246.42.0 46.246.42.195 255.255.255.0
                                        add net 46.246.42.0: gateway 46.246.42.195
2015-05-06 07:07:52 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -d -f -m -w -ptADGNWradsgnw utun2 1500 1558 46.246.42.195 255.255.255.0 init
                                        **********************************************
                                        Start of output from client.up.tunnelblick.sh
                                        Retrieved from OpenVPN: name server(s) [ 46.246.46.46 194.132.32.23 ], domain name [ ipredator.se ], search domain(s) [  ], and SMB server(s) [  ]
                                        Not aggregating ServerAddresses because running on OS X 10.6 or higher
                                        Setting search domains to 'ipredator.se' because running under OS X 10.6 or higher and the search domains were not set manually and 'Prepend domain name to search domains' was not selected
                                        Saved the DNS and SMB configurations so they can be restored
                                        Changed DNS ServerAddresses setting from '192.168.1.1' to '46.246.46.46 194.132.32.23'
                                        Changed DNS SearchDomains setting from '' to 'ipredator.se'
                                        Changed DNS DomainName setting from '' to 'ipredator.se'
                                        Did not change SMB NetBIOSName setting of ''
                                        Did not change SMB Workgroup setting of ''
                                        Did not change SMB WINSAddresses setting of ''
                                        DNS servers '46.246.46.46 194.132.32.23' will be used for DNS queries when the VPN is active
                                        The DNS servers do not include any free public DNS servers known to Tunnelblick. This may cause DNS queries to fail or be intercepted or falsified even if they are directed through the VPN. Specify only known public DNS servers or DNS servers located on the VPN network to avoid such problems.
                                        Flushed the DNS cache via dscacheutil
                                        Flushed the DNS cache via discoveryutil udnsflushcaches
                                        Flushed the DNS cache via discoveryutil mdnsflushcache
                                        No matching processes were found
                                        mDNSResponder not running. Not notifying it that the DNS cache was flushed
                                        Setting up to monitor system configuration with process-network-changes
                                        End of output from client.up.tunnelblick.sh
                                        **********************************************
2015-05-06 07:07:56 /sbin/route add -net 46.246.42.130 192.168.1.1 255.255.255.255
2015-05-06 07:07:56 *Tunnelblick: No 'connected.sh' script to execute
                                        add net 46.246.42.130: gateway 192.168.1.1
2015-05-06 07:07:56 /sbin/route add -net 0.0.0.0 46.246.42.1 128.0.0.0
                                        add net 0.0.0.0: gateway 46.246.42.1
2015-05-06 07:07:56 /sbin/route add -net 128.0.0.0 46.246.42.1 128.0.0.0
                                        add net 128.0.0.0: gateway 46.246.42.1
2015-05-06 07:07:56 MANAGEMENT: >STATE:1430852876,ADD_ROUTES,,,
2015-05-06 07:07:56 /sbin/route add -net 46.246.42.130 192.168.1.1 255.255.255.255
                                        route: writing to routing socket: File exists
                                        add net 46.246.42.130: gateway 192.168.1.1: File exists
2015-05-06 07:07:56 Initialization Sequence Completed
2015-05-06 07:07:56 MANAGEMENT: >STATE:1430852876,CONNECTED,SUCCESS,46.246.42.195,46.246.42.130
2015-05-06 07:08:00 *Tunnelblick process-network-changes: A system configuration change was ignored
2015-05-06 07:08:07 *Tunnelblick: This computer's apparent public IP address changed from XXX.XXX.XXX.XXX before connection to 46.246.42.195 after connection
2015-05-06 07:30:01 [fiekohphuphi.openvpn.ipredator.se] Inactivity timeout (--ping-restart), restarting
2015-05-06 07:30:01 SIGUSR1[soft,ping-restart] received, process restarting
2015-05-06 07:30:01 MANAGEMENT: >STATE:1430854201,RECONNECTING,ping-restart,,
2015-05-06 07:30:01 MANAGEMENT: CMD 'hold release'
2015-05-06 07:30:01 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2015-05-06 07:30:01 Socket Buffers: R=[196724->65536] S=[9216->65536]
2015-05-06 07:30:01 MANAGEMENT: >STATE:1430854201,RESOLVE,,,
2015-05-06 07:30:32 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known
2015-05-06 07:30:32 MANAGEMENT: >STATE:1430854232,RESOLVE,,,
2015-05-06 07:31:03 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known
2015-05-06 07:31:38 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known
2015-05-06 07:32:14 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known

2015-05-06 07:32:50 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known

2015-05-06 07:33:26 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known

2015-05-06 07:34:01 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known

2015-05-06 07:34:37 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known

2015-05-06 07:35:13 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known

2015-05-06 07:35:49 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known

2015-05-06 07:36:24 RESOLVE: Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known

[jkbull...gmail.com]

There are several things going on here:

(1) There are some OpenVPN options in your configuration file that are not being processed properly; note the following error messages:

2015-05-06 07:07:44 No valid translation found for TLS cipher 'TLSv1'

2015-05-06 07:07:44 No valid translation found for TLS cipher '!ADH'

2015-05-06 07:07:44 No valid translation found for TLS cipher '!SSLv2'

2015-05-06 07:07:44 No valid translation found for TLS cipher '!NULL'

2015-05-06 07:07:44 No valid translation found for TLS cipher '!EXPORT'

2015-05-06 07:07:44 No valid translation found for TLS cipher '!DES'

2015-05-06 07:07:44 No valid translation found for TLS cipher '!LOW'

2015-05-06 07:07:44 No valid translation found for TLS cipher '!MEDIUM'

2015-05-06 07:07:44 No valid translation found for TLS cipher '@STRENGTH'

and:

2015-05-06 07:07:52 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:8: ip-win32 (2.3.6)

(ip-win32 is a "Windows only" OpenVPN option. It shouldn't be in a configuration file for a Mac.)

and:

2015-05-06 07:07:52 WARNING: potential conflict between --remote address [46.246.42.130] and --ifconfig address pair [46.246.42.195, 255.255.255.0] -- this is a warning only that is triggered when local/remote addresses exist within the same /24 subnet as --ifconfig endpoints. (silence this warning with --ifconfig-nowarn)

(This is an odd one and looks like another misconfiguration.)

For all of those, you should contact iPredator.

(2) Why did it lose the connection at exactly 7:30?

I suspect that was just some network issue (perhaps a scheduled restart of something between your computer and the VPN server).

(3) Why couldn't it recover from the connection loss?

This is complicated. This OpenVPN configuration and server are set up so that DNS queries go through the VPN. When there is a loss of connection, OpenVPN does a "soft restart". That means that it doesn't do a full restore of the network setup and then start over, but instead just tries to reconnect to the server again. But since it doesn't restore the original network settings, DNS queries are still going to the VPN nameserver. Unfortunately, that server is not available because you are not connected to the VPN at that point. So all DNS queries fail, including the query to get the IP address of the VPN server so OpenVPN can reconnect. The only way around this problem that I know of is to add an additional DNS server entry for a public DNS server such as Google DNS or OpenDNS. I don't know if it would work for you to add it to your client configuration; that's something that you should talk to iPredator about, too.

On Tuesday, May 5, 2015 at 6:42:51 PM UTC-4, PaulT wrote:

Hi All,

[This is on a MacAir OSX10.10.3, TB 3.5.0 (build 4265)]

TB starts, connects, and then works well. Lots of traffic is going across the connection.

But after a while (under half an hour in the logs below) it disconnects and is unable to re-establish connection.

The logs show it connected at 7:08, then the connection dropped at 7:30. 

Before the failure - it was working fully.

<snip>

 

[PaulT]

First... Thanks for the speedy response and advice.

I've been in contact with iPredator support and pointed them at your response.

They have suggested:

a) updating the config file for issue (1) - the invalid options. I haven't done that for a while, and apparently its been addressed.

b) adding some explicit dhcp settings to the config file for issue (3). The config file is stored in ~/Library/Application Support/Tunnelblick.

I've added the following:

dhcp-option DNS 194.132.32.32
dhcp-option DNS 46.246.46.246
dhcp-option DNS 46.246.46.46
dhcp-option DNS 194.132.32.23
dhcp-option DNS 8.8.8.8
dhcp-option DNS 8.8.4.4

According to iPredator's website, that includes two public resolvers and

two DNS servers that are available when connected, 

and I've also added a couple of public DNS servers from 

TunnelBlick's list.

Hopefully, one of these will work when TB is disconnected.

Cheers.

Paul

[jkbull...gmail.com]

The best way to edit a configuration is to select it in Tunnelblick's "VPN Details…" window, then click the little "gear" icon at the bottom of the list of configurations and select "Edit OpenVPN Configuration File…". That will open the file in TextEdit for you.

If that command is not available and Tunnelblick shows "Examine OpenVPN Configuration File…" instead, make the configuration "private" before editing it, edit it, then change it back to a "shared" configuration.

If it is a "Deployed" version of Tunnelblick, you will not be able to convert it to "private"; you should talk to whoever gave you the "Deployed" version before modifying the file.

[PaulT]

Thanks. Per your comment, I used the "Edit OpenVPN Configuration File..." option,

and added the DNS servers. Here is the section of the VPN config file:

client
dev tun0
proto udp
remote pw.openvpn.ipredator.se 1194
resolv-retry

infinite
nobind


dhcp-option DNS 194.132.32.32

dhcp-option DNS 46.246.46.246
dhcp-option DNS 46.246.46.46
dhcp-option DNS 194.132.32.23
dhcp-option DNS 8.8.8.8
dhcp-option DNS 8.8.4.4

auth-user-pass

auth-retry nointeract


ca [inline]
...

The error still occurs. The connection drops after some period of time (15-30 minutes), and the log shows the same error as before:

Cannot resolve host address: pw.openvpn.ipredator.se: nodename nor servname provided, or not known

I'll do some more experimenting... perhaps just with the google DNS servers.

But it seems that when the connection drops, OpenVPN is not able to send any DNS queries out.

Cheers.

Paul.

[jkbull...gmail.com]

Without the diagnostic info with "Set nameserver" selected, I can't tell in what order the DNS servers will be queried, but OS X waits for a DNS server to time out (30 seconds, I think) before trying the next one on the list (Windows queries all servers simultaneously). So if you have four servers before the 8.8.8.8, it will take a long time for the four timeouts to occur. And that's assuming that OpenVPN has restored the routing so you can get to 8.8.4.4, which also isn't clear to me without the diagnostic info.

One nitpick: The problem isn't "when Tunnelblick is disconnected"; it is when OpenVPN is trying to do a "restart" of the connection. 

I am considering adding an option that would solve this problem even if the OpenVPN configurations are problematic (as the iPredator ones seem to be). It would do a full Tunnelblick disconnect/connect cycle instead of letting OpenVPN do a restart. But I don't know if I'll do it or when. And it assumes that if you disconnect you are able to reconnect (some configurations don't allow you to do that because they don't restore the routing properly).

[jkbull...gmail.com]

After thinking about what is happening, you might be able to fix it by removing the "persist-tun" line from the OpenVPN configuration file.

[srg.ga...@gmail.com]

Same problem here. Another workaround would be adding "persist-remote-ip". Not our case cause we use dns as part of failover mechanism.

I think tunnelblick should react on SIGUSR1 signal, cause it's normal for openvpn to generate that signal sometimes.

четверг, 7 мая 2015 г., 18:21:01 UTC+3 пользователь jkbull...gmail.com написал:

[jkbull...gmail.com]

Tunnelblick can't react to the SIGUSR1 signal, because the signal is directed to the OpenVPN process, which runs as root. Tunnelblick, running as the user, cannot intercept or monitor that signal.

Tunnelblick can, through the management interface to OpenVPN, send a SIGUSR1 to the OpenVPN process, but it does not have any way of receiving a SIGUSR1 that is sent to an OpenVPN process, or that is generated internally by an OpenVPN process. 

The problem the original poster had is that OpenVPN was configured incorrectly by his VPN service provider.

If, as is usually the case and is the case here, the client OpenVPN configuration in combination with OpenVPN options "pushed" by the OpenVPN server to the client cause DNS settings to be changed when the VPN becomes connected, then the configuration should insure that the original DNS settings are restored when the VPN is disconnected or that DNS is not used until the VPN is reconnected. Including the "persist-tun" option in the configuration inhibits the restore of DNS settings, so it may not be possible to do a DNS lookup on the hostname of the OpenVPN server while attempting to reconnect as a result of a SIGUSR1. If the configuration does not also include "persist-remote-ip", the DNS lookup of the OpenVPN server during the reconnection attempt may fail.

Bottom line: if you use "persist-tun", you probably need to also use "persist-remote-ip". That may not be necessary if the OpenVPN server hostname can still be resolved during a reconnect; it depends on exactly what is being changed about DNS and the particular DNS servers involved. 

[Sergey Gavrilov]

Jon, thank you for complete answer. Maybe to catch SIGUSR1 signal not such a good idea, as I thought at first, but anyway I don't agree that this is a misconfiguation issue.

It's Tunnelblick who recieves that pushed DNS options and changes DNS settings on client, why and how OpenVPN should ensure that original settings are restored?

--

Best regards,
Sergey Gavrilov

[jkbull...gmail.com]

Tunnelblick doesn't receive the pushed DNS options, OpenVPN does. OpenVPN then passes them on to an "up" script if one exists. Tunnelblick includes several such "up" scripts that are useful in different situations. (The "Set DNS/WINS" setting determines which script (if any) will be used by OpenVPN.) A corresponding "down" script usually restores the DNS settings, and again, it is OpenVPN that calls the "down" script, not Tunnelblick.

How does OpenVPN know whether it is necessary to call the "down" script to restore the DNS settings when doing a restart? By looking at the options in the configuration. If the "persist-tun" option is there, the VPN designer – the person who created the OpenVPN configuration – is telling OpenVPN not to restore the DNS settings while doing a restart of the VPN.

It was the VPN designer that made the decision to include "persist-tun". And it was the wrong decision for this VPN. That's why I say it is a configuration error.

Why can't OpenVPN or Tunnelblick decide whether or not to restore the DNS settings when restarting the connection? Because neither program knows enough. In some situations the DNS settings must be restored, in other situations they do not need to be restored. For example, it is probably not necessary if "persist-remote-ip" is also used, but there are some situations where having "persist-remote-ip" will not work (where the remote IP address is dynamic, for example). It is also not necessary to restore the DNS settings if the VPN DNS server responds to queries even when no VPN connection is active. That sort of knowledge is not known by OpenVPN or Tunnelblick. It is known only by the VPN designer. So only the VPN designer can decide what OpenVPN options will correctly deal with the situation and specify them.

On Thursday, May 7, 2015 at 3:24:07 PM UTC-4, Sergey Gavrilov wrote:

Jon, thank you for complete answer. Maybe to catch SIGUSR1 signal not such a good idea, as I thought at first, but anyway I don't agree that this is a misconfiguation issue.

It's Tunnelblick who recieves that pushed DNS options and changes DNS settings on client, why and how OpenVPN should ensure that original settings are restored?

[Sergey Gavrilov]

Ok, now I got it. Sorry for making you copy OpenVPN man page here, my fault.

I checked how OpenVPN GUI for Windows deals with this situation - it preserves old DNS while connecting for the first time and uses that old DNS while reconnecting if pushed DNS is failed. Maybe it would be better alternative to pushing public DNS or down script. What do you think? How can I get this behavior with Tunnelblick?

[jkbull...gmail.com]

@Sergey: I am happy to explain – explaining it to you helped me clarify it in my own mind!

And thank you for the information about how OpenVPN GUI for Windows does things. I will look into that if/when I have the time. More details or pointers into the source code would be helpful.

On Friday, May 8, 2015 at 3:47:50 AM UTC-4, Sergey Gavrilov wrote:

Ok, now I got it. Sorry for making you copy OpenVPN man page here, my fault.

I checked how OpenVPN GUI for Windows deals with this situation - it preserves old DNS while connecting for the first time and uses that old DNS while reconnecting if pushed DNS is failed. Maybe it would be better alternative to pushing public DNS or down script. What do you think? How can I get this behavior with Tunnelblick?