I have just checked and there should not have been any security updates that should have affected OpenVPN, so it's very strange that it just stopped working!

Are all clients having the same experience (assuming there is more than one)? Have there been any recent client-side software updates? I wonder if there have been any Windows updates that may have affected this?

I also notice in the log "WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.". TBH I highly doubt that is the cause (it's a deprecation warning, not an error). But perhaps it's worth a try? Another user also noted that on the tracker and has also kindly provided a patch. Perhaps it's worth apply the suggested tweak and regenerating a new .opvn profile? I can't guarantee anything but possibly worth a shot...

Otherwise, TBH I'm not at all sure...

FWIW I've just had a quick glance through the bugs against OpenVPN on the Debian Bug Tracker (aka BTS). Unfortunately none of them jump out to me as being in any way related to your experience. Although it is possible that I'm missing something.

However, I did notice what appears to be a bug that may be related?! (For some reason it's not against the OpenVPN package, so doesn't show up via the BTS link above). It looks like a new package (version 2.4.0-6+deb9u3) should be available soon. At the time of writing, the latest (Debian 9/Stretch) package available is still 2.4.0-6+deb9u2 (one update version behind the new one noted above i.e. deb9u2 vs deb9u3).

It still doesn't completely match with your issue from my reading, but perhaps...?! It may also be worth investigating OpenSSL updates. Hopefully that package will be available soon. It's probably worth noting, that you'll need to manually update to it via apt:

apt update
apt install openvpn

If that says something along the lines of "OpenVPN is already at the latest version", then there isn't a new package (yet). Although it may also be worth double checking which version you have installed. You can do that like this:

apt policy openvpn

Actually, one other thing I just noticed is that OpenSSL has very recently had a security update (the notification I have is actually dated 9 hours after your post - hence why I didn't notice it before). But perhaps that is the real culprit of your issues? I note from your log that it appears your client is using OpenSSL 1.1.0h, where TurnKey was using 1.1.0f(-3+deb9u2), but has now updated to 1.1.0j(-1~deb9u1). Perhaps that version difference is upsetting things?

Sorry about all this stabbing in the dark, but I'd be really interested to hear how you're going with it and if any of this helps.

Have you tried creating a new profile and testing with that? I just launched a new TurnKey OpenVPN instance from the Hub (installed all security updates - with no other changes) and created a profile (i.e. .opvn file). I then imported that profile to my desktop and it "just works" (see below)?!

As I'm using Debian on my desktop, to check that it isn't just working Debian Debian (the basis of TurnKey) I also tried it on my (Android) phone. Using the same .opvn profile with the latest version of the OpenVPN Connect app it also works fine?! Unfortunately, I don't have a Windows machine handy so can't test that, but otherwise, it all appears to be working as intended here?!

The only other thing that I am thinking, is perhaps you aren't getting DNS for some reason? (Actually re-reading this thread - that comment doesn't make sense... sorry about that)

FWIW:

On the TurnKey OpenVPN instance (in US West 1 - California):

root@openvpn ~# curl icanhazip.com
52.53.228.144

On my Desktop (in Australia):

user@ninjux ~$ sudo openvpn --config turnkey/v15.0/opvn-test/tester.ovpn 
Fri Dec  7 07:21:02 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Fri Dec  7 07:21:02 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Fri Dec  7 07:21:02 2018 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Dec  7 07:21:02 2018 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Dec  7 07:21:02 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]52.53.228.144:1194
Fri Dec  7 07:21:02 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Fri Dec  7 07:21:02 2018 UDP link local: (not bound)
Fri Dec  7 07:21:02 2018 UDP link remote: [AF_INET]52.53.228.144:1194
Fri Dec  7 07:21:02 2018 TLS: Initial packet from [AF_INET]52.53.228.144:1194, sid=b5034aff 0149cbf8
Fri Dec  7 07:21:03 2018 VERIFY OK: depth=1, C=US, ST=CA, L=San Francisco, O=TurnKey Linux, OU=OpenVPN, CN=server, name=openvpn, emailAddress=jeremy@turnkeylinux.org
Fri Dec  7 07:21:03 2018 VERIFY OK: nsCertType=SERVER
Fri Dec  7 07:21:03 2018 VERIFY OK: depth=0, C=US, ST=CA, L=San Francisco, O=TurnKey Linux, OU=OpenVPN, CN=server, name=openvpn, emailAddress=jeremy@turnkeylinux.org
Fri Dec  7 07:21:03 2018 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Fri Dec  7 07:21:03 2018 [server] Peer Connection Initiated with [AF_INET]52.53.228.144:1194
Fri Dec  7 07:21:04 2018 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Fri Dec  7 07:21:04 2018 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,route 10.25.34.1,topology net30,ping 10,ping-restart 120,ifconfig 10.25.34.6 10.25.34.5,peer-id 0,cipher AES-256-GCM'
Fri Dec  7 07:21:04 2018 OPTIONS IMPORT: timers and/or timeouts modified
Fri Dec  7 07:21:04 2018 OPTIONS IMPORT: --ifconfig/up options modified
Fri Dec  7 07:21:04 2018 OPTIONS IMPORT: route options modified
Fri Dec  7 07:21:04 2018 OPTIONS IMPORT: peer-id set
Fri Dec  7 07:21:04 2018 OPTIONS IMPORT: adjusting link_mtu to 1625
Fri Dec  7 07:21:04 2018 OPTIONS IMPORT: data channel crypto options modified
Fri Dec  7 07:21:04 2018 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Dec  7 07:21:04 2018 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Fri Dec  7 07:21:04 2018 ROUTE_GATEWAY 192.168.1.254/255.255.255.0 IFACE=wlp3s0 HWADDR=84:3a:4b:d2:a0:20
Fri Dec  7 07:21:04 2018 TUN/TAP device tun0 opened
Fri Dec  7 07:21:04 2018 TUN/TAP TX queue length set to 100
Fri Dec  7 07:21:04 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Fri Dec  7 07:21:04 2018 /sbin/ip link set dev tun0 up mtu 1500
Fri Dec  7 07:21:04 2018 /sbin/ip addr add dev tun0 local 10.25.34.6 peer 10.25.34.5
Fri Dec  7 07:21:04 2018 /sbin/ip route add 52.53.228.144/32 via 192.168.1.254
Fri Dec  7 07:21:04 2018 /sbin/ip route add 0.0.0.0/1 via 10.25.34.5
Fri Dec  7 07:21:04 2018 /sbin/ip route add 128.0.0.0/1 via 10.25.34.5
Fri Dec  7 07:21:04 2018 /sbin/ip route add 10.25.34.1/32 via 10.25.34.5
Fri Dec  7 07:21:04 2018 Initialization Sequence Completed

Then in another terminal again on my desktop (Note I'm in Australia and geoiplookup MY_PUBLIC_IP reports as such prior to using the VPN):

user@ninjux ~$ curl icanhazip.com
52.53.228.144
user@ninjux ~$ geoiplookup 52.53.228.144
GeoIP Country Edition: US, United States
user@ninjux ~$ ip route
0.0.0.0/1 via 10.25.34.5 dev tun0 
default via 192.168.1.254 dev wlp3s0 proto static metric 600 
10.25.34.1 via 10.25.34.5 dev tun0 
10.25.34.5 dev tun0 proto kernel scope link src 10.25.34.6 
52.53.228.144 via 192.168.1.254 dev wlp3s0 
128.0.0.0/1 via 10.25.34.5 dev tun0 
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.89 metric 600 
user@ninjux ~$ curl -Is https://www.turnkeylinux.org -L | grep HTTP/
HTTP/2 200 

As the above suggests, web browsing etc works fine.

I wonder if this is related to another user's experience of the the default CRL expiring? It appears that the default CRL expiry is 30 days. As noted in the bug that I opened, 30 days is probably too short, so we should increase that...