Tunnelblick does not send any packets, other clients work ok

j.f...@gmail.com

unread,

Sep 6, 2017, 10:11:46 AM9/6/17

to tunnelblick-discuss

I have a strange problem with Tunnelblick 3.7.3beta02 (build 4861) on macOS 10.12.6. (I have tried the stable Tunnelblick before, the result is the same.)

The server is turris openwrt, I have no problems connecting there from Linux (NetworkManager) and iPad (OpenVPN Connect).

Tunnelblick connects fine, but I think there is a problem with route. No packet get through the VPN. It is not DNS problem, I'm trying ping 8.8.8.8 (google) or ping 10.111.111.1 (vpn server on the same subnet) or traceroute. The problem is there if I use push redirect-gateway def1 or using the Tunnelblick option "Route all ipv4 traffic..."

Not sure what the problem might be. Tried almost all settings. What to try or what information is needed? Here is the log:

*Tunnelblick: OS X 10.12.6; Tunnelblick 3.7.3beta02 (build 4861); prior version 3.7.2 (build 4850)

2017-09-06 14:38:18 *Tunnelblick: Attempting connection with turris_u_babicky; Set nameserver = 769; not monitoring connection

2017-09-06 14:38:18 *Tunnelblick: openvpnstart start turris_u_babicky.tblk 1337 769 0 3 1 83760 -ptADGNWradsgnw 2.5_git_974513e-libressl-2.5.5

2017-09-06 14:38:19 *Tunnelblick: openvpnstart log:

OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):

/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.5_git_974513e-libressl-2.5.5/openvpn

--daemon

--log

/Library/Application Support/Tunnelblick/Logs/-SLibrary-SApplication Support-STunnelblick-SShared-Sturris_u_babicky.tblk-SContents-SResources-Sconfig.ovpn.769_0_3_1_83760.1337.openvpn.log

--cd

/Library/Application Support/Tunnelblick/Shared/turris_u_babicky.tblk/Contents/Resources

--setenv

IV_GUI_VER

"net.tunnelblick.tunnelblick 4861 3.7.3beta02 (build 4861)"

--verb

3

--config

/Library/Application Support/Tunnelblick/Shared/turris_u_babicky.tblk/Contents/Resources/config.ovpn

--verb

3

--cd

/Library/Application Support/Tunnelblick/Shared/turris_u_babicky.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 -o -r -w -ptADGNWradsgnw

--down

/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -d -f -o -r -w -ptADGNWradsgnw

2017-09-06 14:38:18 OpenVPN 2.5_git_974513e x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Aug 20 2017

2017-09-06 14:38:18 library versions: LibreSSL 2.5.5, LZO 2.10

2017-09-06 14:38:18 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337

2017-09-06 14:38:18 Need hold release from management interface, waiting...

2017-09-06 14:38:18 *Tunnelblick: openvpnstart starting OpenVPN

2017-09-06 14:38:19 *Tunnelblick: Established communication with OpenVPN

2017-09-06 14:38:19 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337

2017-09-06 14:38:19 MANAGEMENT: CMD 'pid'

2017-09-06 14:38:19 MANAGEMENT: CMD 'state on'

2017-09-06 14:38:19 MANAGEMENT: CMD 'state'

2017-09-06 14:38:19 MANAGEMENT: CMD 'bytecount 1'

2017-09-06 14:38:19 MANAGEMENT: CMD 'hold release'

2017-09-06 14:38:19 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2017-09-06 14:38:19 MANAGEMENT: >STATE:1504701499,RESOLVE,,,,,,

2017-09-06 14:38:19 TCP/UDP: Preserving recently used remote address: [AF_INET]X.X.X.X:1194

2017-09-06 14:38:19 Socket Buffers: R=[196724->196724] S=[9216->9216]

2017-09-06 14:38:19 UDP link local: (not bound)

2017-09-06 14:38:19 UDP link remote: [AF_INET]X.X.X.X:1194

2017-09-06 14:38:19 MANAGEMENT: >STATE:1504701499,WAIT,,,,,,

2017-09-06 14:38:19 MANAGEMENT: >STATE:1504701499,AUTH,,,,,,

2017-09-06 14:38:19 TLS: Initial packet from [AF_INET]X.X.X.X:1194, sid=473a8e4a ef2d6887

2017-09-06 14:38:19 VERIFY OK: depth=1, CN=openvpn

2017-09-06 14:38:19 VERIFY KU OK

2017-09-06 14:38:19 Validating certificate extended key usage

2017-09-06 14:38:19 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication

2017-09-06 14:38:19 VERIFY EKU OK

2017-09-06 14:38:19 VERIFY OK: depth=0, CN=turris

2017-09-06 14:38:19 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA

2017-09-06 14:38:19 [turris] Peer Connection Initiated with [AF_INET]X.X.X.X:1194

2017-09-06 14:38:20 MANAGEMENT: >STATE:1504701500,GET_CONFIG,,,,,,

2017-09-06 14:38:20 SENT CONTROL [turris]: 'PUSH_REQUEST' (status=1)

2017-09-06 14:38:20 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.111.111.1,topology net30,ping 60,ping-restart 720,ifconfig 10.111.111.6 10.111.111.5,peer-id 2,cipher AES-256-GCM'

2017-09-06 14:38:20 OPTIONS IMPORT: timers and/or timeouts modified

2017-09-06 14:38:20 OPTIONS IMPORT: --ifconfig/up options modified

2017-09-06 14:38:20 OPTIONS IMPORT: route options modified

2017-09-06 14:38:20 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

2017-09-06 14:38:20 OPTIONS IMPORT: peer-id set

2017-09-06 14:38:20 OPTIONS IMPORT: adjusting link_mtu to 1624

2017-09-06 14:38:20 OPTIONS IMPORT: data channel crypto options modified

2017-09-06 14:38:20 Data Channel: using negotiated cipher 'AES-256-GCM'

2017-09-06 14:38:20 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

2017-09-06 14:38:20 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key

2017-09-06 14:38:20 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)

2017-09-06 14:38:20 Opened utun device utun1

2017-09-06 14:38:20 do_ifconfig, tt->did_ifconfig_ipv6_setup=0

2017-09-06 14:38:20 MANAGEMENT: >STATE:1504701500,ASSIGN_IP,,10.111.111.6,,,,

2017-09-06 14:38:20 /sbin/ifconfig utun1 delete

ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

2017-09-06 14:38:20 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure

2017-09-06 14:38:20 /sbin/ifconfig utun1 10.111.111.6 10.111.111.5 mtu 1500 netmask 255.255.255.255 up

2017-09-06 14:38:20 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -d -f -o -r -w -ptADGNWradsgnw utun1 1500 1552 10.111.111.6 10.111.111.5 init

**********************************************

Start of output from client.up.tunnelblick.sh

Retrieved from OpenVPN: name server(s) [ 208.67.222.222 208.67.220.220 8.8.8.8 8.8.4.4 ], search domain(s) [ ] and SMB server(s) [ ] and using default domain name [ openvpn ]

Not aggregating ServerAddresses because running on OS X 10.6 or higher

Setting search domains to 'openvpn' because running under OS X 10.6 or higher and the search domains were not set manually (or are allowed to be changed) 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 '213.46.228.196 62.179.104.196' to '208.67.222.222 208.67.220.220 8.8.8.8 8.8.4.4'

Changed DNS SearchDomains setting from '' to 'openvpn'

Changed DNS DomainName setting from 'arnhem.chello.nl' to 'openvpn'

Did not change SMB NetBIOSName setting of ''

Did not change SMB Workgroup setting of ''

Did not change SMB WINSAddresses setting of ''

DNS servers '208.67.222.222 208.67.220.220 8.8.8.8 8.8.4.4' will be used for DNS queries when the VPN is active

The DNS servers include only free public DNS servers known to Tunnelblick.

Flushed the DNS cache via dscacheutil

/usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil

Notified mDNSResponder that the DNS cache was flushed

End of output from client.up.tunnelblick.sh

**********************************************

2017-09-06 14:38:24 *Tunnelblick: No 'connected.sh' script to execute

2017-09-06 14:38:24 *Tunnelblick: Could not determine this computer's apparent public IP address before the connection was completed

2017-09-06 14:38:24 /sbin/route add -net X.X.X.X 192.168.1.1 255.255.255.255

add net X.X.X.X: gateway 192.168.1.1

2017-09-06 14:38:24 /sbin/route add -net 0.0.0.0 10.111.111.5 128.0.0.0

add net 0.0.0.0: gateway 10.111.111.5

2017-09-06 14:38:24 /sbin/route add -net 128.0.0.0 10.111.111.5 128.0.0.0

add net 128.0.0.0: gateway 10.111.111.5

2017-09-06 14:38:24 MANAGEMENT: >STATE:1504701504,ADD_ROUTES,,,,,,

2017-09-06 14:38:24 /sbin/route add -net 10.111.111.1 10.111.111.5 255.255.255.255

add net 10.111.111.1: gateway 10.111.111.5

2017-09-06 14:38:24 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this

2017-09-06 14:38:24 Initialization Sequence Completed

2017-09-06 14:38:24 MANAGEMENT: >STATE:1504701504,CONNECTED,SUCCESS,10.111.111.6,X.X.X.X,1194,,

2017-09-06 14:39:50 *Tunnelblick: Disconnecting; 'Disconnect' (toggle) menu command invoked

2017-09-06 14:39:50 *Tunnelblick: No 'pre-disconnect.sh' script to execute

2017-09-06 14:39:50 *Tunnelblick: Disconnecting using 'kill'

2017-09-06 14:39:50 event_wait : Interrupted system call (code=4)

2017-09-06 14:39:50 /sbin/route delete -net 10.111.111.1 10.111.111.5 255.255.255.255

delete net 10.111.111.1: gateway 10.111.111.5

2017-09-06 14:39:50 /sbin/route delete -net X.X.X.X 192.168.1.1 255.255.255.255

delete net X.X.X.X: gateway 192.168.1.1

2017-09-06 14:39:50 /sbin/route delete -net 0.0.0.0 10.111.111.5 128.0.0.0

delete net 0.0.0.0: gateway 10.111.111.5

2017-09-06 14:39:50 /sbin/route delete -net 128.0.0.0 10.111.111.5 128.0.0.0

delete net 128.0.0.0: gateway 10.111.111.5

2017-09-06 14:39:50 Closing TUN/TAP interface

2017-09-06 14:39:50 /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -d -f -o -r -w -ptADGNWradsgnw utun1 1500 1552 10.111.111.6 10.111.111.5 init

**********************************************

Start of output from client.down.tunnelblick.sh

Restored the DNS and SMB configurations

Flushed the DNS cache via dscacheutil

/usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil

Notified mDNSResponder that the DNS cache was flushed

Resetting primary interface 'en0' via networksetup -setairportpower en0 off/on...

End of output from client.down.tunnelblick.sh

**********************************************

2017-09-06 14:39:54 SIGTERM[hard,] received, process exiting

2017-09-06 14:39:54 MANAGEMENT: >STATE:1504701594,EXITING,SIGTERM,,,,,

2017-09-06 14:39:54 *Tunnelblick: No 'post-disconnect.sh' script to execute

2017-09-06 14:39:54 *Tunnelblick: Expected disconnection occurred.

Tunnelblick developer

unread,

Sep 6, 2017, 5:01:44 PM9/6/17

to tunnelblick-discuss

These

2017-09-06 14:38:20 Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
2017-09-06 14:38:20 Opened utun device utun1

and this

2017-09-06 14:38:24 *Tunnelblick: Could not determine this computer's apparent public IP address before the connection was completed

indicate problems before Tunnelblick tried to connect.

I suggest you restart your computer and try again. If that doesn't help, please follow the instructions at Read Before You Post to get the info needed to diagnose problems and then post that info.

j.f...@gmail.com

unread,

Sep 7, 2017, 5:03:22 AM9/7/17

to tunnelblick-discuss

After restart unfortunately nothing changes.

I don't understand the problem opening utun, is it utun0? It exists before running Tunnelblick, I guess it is related to "Back to My Mac" iCloud feature. Although that feature is currently switched off. When I switch it on, I have mysteriously utun0 and utun1 as well.

If I have just unun0, Tunnelblick complains once "Resource busy" and creates utun1. When I have utun0 and utun1 (Back to My Mac on), Tunnelblick complains twice "Resouce busy" and creates utun2.

I already checked everything in "Read Before you Post", but still no data flows through the utun1 or utun2. I guess it is a routing problem?

The pre-existing utun0 and utun1 are present only in ipv6 part of the routing table. The ipv4 routing table (netstat -nr) with Tunellblick connected starts with:

0/1 10.111.111.5 UGSc 4 0 utun2

Shouldn't the destination be "default" as on my Linux instead of "0/1"?

Reply all

Reply to author

Forward