Skip to content

Instantly share code, notes, and snippets.

@tromlet
Created November 25, 2020 08:25
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tromlet/2c968654dbacd4e388d2ffe25e13acfd to your computer and use it in GitHub Desktop.
Save tromlet/2c968654dbacd4e388d2ffe25e13acfd to your computer and use it in GitHub Desktop.

So that was the dumbest thing. I have a love-hate relationship with OpenVPN. When it works, it works WELL. When it doesn't, it's usually because of some obscure incompatibility with network devices or a cryptographic oversight on my part, since I've been configuring it and setting it up for the better part of seven years. Anyways, that's just me bitching - I figured I'd put the relevant information here in case some other poor, lost soul has this issue.

I was getting the following error message on OpenVPN 2.4.9 on Windows x64 (Server 2019 Essentials):

Wed Nov 25 00:38:30 2020 us=37816 MULTI: multi_create_instance called
Wed Nov 25 00:38:30 2020 us=37816 192.168.1.23:51026 Re-using SSL/TLS context
Wed Nov 25 00:38:30 2020 us=37816 192.168.1.23:51026 Control Channel MTU parms [ L:1621 D:1184 EF:66 EB:0 ET:0 EL:3 ]
Wed Nov 25 00:38:30 2020 us=37816 192.168.1.23:51026 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Wed Nov 25 00:38:30 2020 us=37816 192.168.1.23:51026 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Wed Nov 25 00:38:30 2020 us=37816 192.168.1.23:51026 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1557,tun-mtu 1500,proto UDPv4,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Wed Nov 25 00:38:30 2020 us=37816 192.168.1.23:51026 TLS: Initial packet from [AF_INET]192.168.1.23:51026, sid=42c0280b aa21e6d9
Wed Nov 25 00:39:26 2020 us=698371 192.168.1.23:54693 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Nov 25 00:39:26 2020 us=698371 192.168.1.23:54693 TLS Error: TLS handshake failed
Wed Nov 25 00:39:26 2020 us=698371 192.168.1.23:54693 SIGUSR1[soft,tls-error] received, client-instance restarting

I fixed it by disabling NAT hardware acceleration in my router (an ASUS RT-AC68U), by performing the following:

  1. Left-click "LAN" in the side navigation menu.
  2. Left-click the "Switch Control" tab at the top.
  3. Left-click the drop-down menu labeled "NAT Acceleration" and select "Disable".
  4. Left-click "Apply".

Your router will take an unreasonably long amount of time to shut down, disable this feature, boot back up, and then be connected to by all of your wireless devices... but it'll work. I tested my configs with JUST this setting enabled and then disabled - configs on TWO computers did not work with it enabled, and DID work with it disabled. There may be more in play here, but after probably six hours of troubleshooting, I wanted this knowledge out there in the world. Save yourselves.

My router is an RT-AC68U, yours may differ in make/model and implementation of NAT acceleration, but this might help you nonetheless. I hope it does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment