ovpn config that worked on older mac (El Capitan, TB 3.7.0, UDP) fails on new mac (High Sierra, TB 3.7.6 TCP)

67 views
Skip to first unread message

srx...@gmail.com

unread,
Jun 15, 2018, 6:29:59 PM6/15/18
to tunnelblick-discuss
Reading on High Sierra issues, I have telnet, kex appears to load, no errors that I see. I'm told the ovpn file should work (am suspicious) on either mac but as it was at a lower level (ovpn 2.3.14) I'm trying openvpn 2.3.18 (openssl v1.0.2o) and the later 2.4 level on the new mac. Slightly different errors, but connection refused on both. The older mac is shutdown and TB is not active, but access attempts are from same subnet and destination connect are pingable (*.226.21.101-I've edited the domain below to take out the leading address) from both machines.
 
What I note is that on the new machine:
2018-06-15 14:31:53 Attempting to establish TCP connection with [AF_INET]*.226.21.101:11994 [nonblock]
followed by connection refused

The old machine has entries like this:
UDPv4 link local: [undef]
UDPv4 link remote: [AF_NET].....:443
and then connects

Looked for a TB setting that switches from TCP to UDP, but no luck. The openvpnstart args all look the same, but I don't get the down-root "Warning" on the old system.

Do not remember setting any routes on the old system to get this to work.

Would default to bothering the VPN source but not understanding why the new system wants to connect tcp and the old one appears to use udp..

Thx,
Steve


##########################################################
*Tunnelblick: OS X 10.13.4; Tunnelblick 3.7.6 (build 5060); prior version 3.7.5a (build 5011)
2018-06-15 14:31:52 *Tunnelblick: Attempting connection with steven2 using shadow copy; Set nameserver = 771; monitoring connection
2018-06-15 14:31:52 *Tunnelblick: openvpnstart start steven2.tblk 53335 771 0 1 0 1065264 -ptADGNWradsgnw 2.3.18-openssl-1.0.2o
2018-06-15 14:31:52 OpenVPN 2.3.18 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Jun  9 2018
2018-06-15 14:31:52 library versions: OpenSSL 1.0.2o  27 Mar 2018, LZO 2.10
2018-06-15 14:31:52 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:53335
2018-06-15 14:31:52 Need hold release from management interface, waiting...
2018-06-15 14:31:52 *Tunnelblick: openvpnstart starting OpenVPN
2018-06-15 14:31:53 *Tunnelblick: openvpnstart log:
     Warning: Tunnelblick is using 'openvpn-down-root.so', so the route-pre-down script will not be used. You can override this by providing a custom route-pre-down script (which may be a copy of Tunnelblick's standard route-pre-down script) in a Tunnelblick VPN Configuration. However, that script will not be executed as root unless the 'user' and 'group' options are removed from the OpenVPN configuration file. If the 'user' and 'group' options are removed, then you don't need to use a custom route-pre-down script.OpenVPN started successfully. Command used to start OpenVPN (one argument per displayed line):
    
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.18-openssl-1.0.2o/openvpn
          --daemon
          --log
          /Library/Application Support/Tunnelblick/Logs/-SUsers-Ssteve-SLibrary-SApplication Support-STunnelblick-SConfigurations-Ssteven2.tblk-SContents-SResources-Sconfig.ovpn.771_0_1_0_1065264.53335.openvpn.log
          --cd
          /Library/Application Support/Tunnelblick/Users/steve/steven2.tblk/Contents/Resources
          --setenv
          IV_GUI_VER
          "net.tunnelblick.tunnelblick 5060 3.7.6 (build 5060)"
          --verb
          3
          --config
          /Library/Application Support/Tunnelblick/Users/steve/steven2.tblk/Contents/Resources/config.ovpn
          --verb
          3
          --cd
          /Library/Application Support/Tunnelblick/Users/steve/steven2.tblk/Contents/Resources
          --management
          127.0.0.1
          53335
          /Library/Application Support/Tunnelblick/hkellogdmkdlmaffinpblmahjmebkcemgkjblcha.mip
          --management-query-passwords
          --management-hold
          --script-security
          2
          --up
          /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
          --plugin
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.18-openssl-1.0.2o/openvpn-down-root.so
          /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw

2018-06-15 14:31:53 *Tunnelblick: Established communication with OpenVPN
2018-06-15 14:31:53 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:53335
2018-06-15 14:31:53 MANAGEMENT: CMD 'pid'
2018-06-15 14:31:53 MANAGEMENT: CMD 'state on'
2018-06-15 14:31:53 MANAGEMENT: CMD 'state'
2018-06-15 14:31:53 MANAGEMENT: CMD 'bytecount 1'
2018-06-15 14:31:53 MANAGEMENT: CMD 'hold release'
2018-06-15 14:31:53 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2018-06-15 14:31:53 PLUGIN_INIT: POST /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.18-openssl-1.0.2o/openvpn-down-root.so '[/Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.18-openssl-1.0.2o/openvpn-down-root.so] [/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh] [-9] [-d] [-f] [-m] [-w] [-ptADGNWradsgnw]' intercepted=PLUGIN_UP|PLUGIN_DOWN
2018-06-15 14:31:53 Socket Buffers: R=[131072->131072] S=[131072->131072]
2018-06-15 14:31:53 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
2018-06-15 14:31:53 Attempting to establish TCP connection with [AF_INET]*.226.21.101:11994 [nonblock]
2018-06-15 14:31:53 MANAGEMENT: >STATE:1529098313,TCP_CONNECT,,,
2018-06-15 14:31:54 TCP: connect to [AF_INET]*.226.21.101:11994 failed, will try again in 5 seconds: Connection refused
2018-06-15 14:31:59 MANAGEMENT: >STATE:1529098319,TCP_CONNECT,,,
2018-06-15 14:32:00 TCP: connect to [AF_INET]*.226.21.101:11994 failed, will try again in 5 seconds: Connection refused
2018-06-15 14:32:05 MANAGEMENT: >STATE:1529098325,TCP_CONNECT,,,
2018-06-15 14:32:06 TCP: connect to [AF_INET]*.226.21.101:11994 failed, will try again in 5 seconds: Connection refused
2018-06-15 14:32:11 MANAGEMENT: >STATE:1529098331,TCP_CONNECT,,,
2018-06-15 14:32:12 TCP: connect to [AF_INET]*.226.21.101:11994 failed, will try again in 5 seconds: Connection refused
2018-06-15 14:32:14 *Tunnelblick: Disconnecting; VPN Details… window disconnect button pressed
2018-06-15 14:32:15 *Tunnelblick: No 'pre-disconnect.sh' script to execute
2018-06-15 14:32:15 *Tunnelblick: Disconnecting using 'kill'
2018-06-15 14:32:15 PLUGIN_CLOSE: /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.3.18-openssl-1.0.2o/openvpn-down-root.so
2018-06-15 14:32:15 SIGTERM[hard,init_instance] received, process exiting
2018-06-15 14:32:15 MANAGEMENT: >STATE:1529098335,EXITING,init_instance,,
2018-06-15 14:32:15 *Tunnelblick: No 'post-disconnect.sh' script to execute
2018-06-15 14:32:16 *Tunnelblick: Expected disconnection occurred.

Tunnelblick developer

unread,
Jun 15, 2018, 6:47:09 PM6/15/18
to tunnelblick-discuss
You are not using the same configuration file.

TCP vs. UDP is set in the configuration file -- it is not a Tunnelblick setting. A configuration file can have multiple connection sets (and thus could try both UDP and TCP), but yours doesn't seem to have them.

And I can't imagine that the version of OpenVPN (2.3.14 vs. 2.3.18) is a factor, either.

I think you just have the wrong configuration file.

You didn't post the diagnostic info obtained by following the instructions at Read Before You Post, so it's hard to say more. But even if you had, if you have the wrong configuration file it isn't surprising that it doesn't work.

srx...@gmail.com

unread,
Jun 15, 2018, 7:26:00 PM6/15/18
to tunnelblick-discuss
This is indeed the case. I had requested a new file and wrote it over the file I had on the desktop. Same name. Then ftp'd it over. Repeated that when it didn't work. But old mac was using an older copy located somewhere else. I ftp'd that over and now it works.

Did not know the file was ascii, should have looked at it. Not sure I should bring it up with the hoster, but it works.

Thx and have a good weekend.
Reply all
Reply to author
Forward
0 new messages