On Wednesday, 8 March 2023 18:30:55 GMT Dale wrote:

> It starts at about 13:54. It seems to try to reconnect but can't. I got this
> by using tail -n and then grep openvpn on the end.
> 
> 
> Mar  1 13:53:32 fireball openvpn[27908]:
> [us-hou-v029.prod.surfshark.com] Inactivity timeout (--ping-restart),
> restarting
> Mar  1 13:53:32 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 1500
> 1584 10.8.8.9 255.255.255.0 restart
> Mar  1 13:53:32 fireball openvpn[27908]: SIGUSR1[soft,ping-restart]
> received, process restarting
> Mar  1 13:53:32 fireball openvpn[27908]: Restart pause, 5 second(s)
> Mar  1 13:53:37 fireball openvpn[27908]: NOTE: the current
> --script-security setting may allow this configuration to call
> user-defined scripts
> Mar  1 13:53:37 fireball openvpn[27908]: Outgoing Control Channel
> Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
> Mar  1 13:53:37 fireball openvpn[27908]: Incoming Control Channel
> Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
> Mar  1 13:53:37 fireball openvpn[27908]: TCP/UDP: Preserving recently
> used remote address: [AF_INET]37.19.221.71:1194
> Mar  1 13:53:37 fireball openvpn[27908]: Socket Buffers:
> R=[212992->425984] S=[212992->425984]
> Mar  1 13:53:37 fireball openvpn[27908]: UDP link local: (not bound)
> Mar  1 13:53:37 fireball openvpn[27908]: UDP link remote:
> [AF_INET]37.19.221.71:1194
> Mar  1 13:54:37 fireball openvpn[27908]: TLS Error: TLS key negotiation
> failed to occur within 60 seconds (check your network connectivity)

Here's your problem ^^^

> Mar  1 13:54:37 fireball openvpn[27908]: TLS Error: TLS handshake failed

This is your error.


> Mar  1 13:54:37 fireball openvpn[27908]: /etc/openvpn/down.sh tun0 1500
> 1653 10.8.8.9 255.255.255.0 restart
> Mar  1 13:54:37 fireball openvpn[27908]: SIGUSR1[soft,tls-error]
> received, process restarting
> Mar  1 13:54:37 fireball openvpn[27908]: Restart pause, 5 second(s)
> Mar  1 13:54:42 fireball openvpn[27908]: NOTE: the current
> --script-security setting may allow this configuration to call
> user-defined scripts
> Mar  1 13:54:42 fireball openvpn[27908]: Outgoing Control Channel
> Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
> Mar  1 13:54:42 fireball openvpn[27908]: Incoming Control Channel
> Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
> Mar  1 13:54:42 fireball openvpn[27908]: TCP/UDP: Preserving recently
> used remote address: [AF_INET]107.179.20.179:1194
> Mar  1 13:54:42 fireball openvpn[27908]: Socket Buffers:
> R=[212992->425984] S=[212992->425984]
> Mar  1 13:54:42 fireball openvpn[27908]: UDP link local: (not bound)
> Mar  1 13:54:42 fireball openvpn[27908]: UDP link remote:
> [AF_INET]107.179.20.179:1194
> Mar  1 13:55:42 fireball openvpn[27908]: TLS Error: TLS key negotiation
> failed to occur within 60 seconds (check your network connectivity)
> Mar  1 13:55:42 fireball openvpn[27908]: TLS Error: TLS handshake failed

Have a look here for suggestions:

https://openvpn.net/faq/tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity/


> The weird thing, I can stop openvpn, then start it again just seconds later
> and it works fine for a good long while.

Right, the problem is with renegotiating a connection, after it times out and 
it fails to agree TLS keys.  I seem to recall a bug with this, but I think it 
would/should have been fixed by now.


> I got this config file from Surfshark.  I think it's public so I guess
> there's no harm posting as is. 
> 
> 
> client
> dev tun
> proto udp
> remote us-hou.prod.surfshark.com 1194
> resolv-retry infinite
> remote-random
> nobind
> tun-mtu 1500
> tun-mtu-extra 32
> mssfix 1450
> persist-key
> persist-tun
> ping 15
> ping-restart 0
> ping-timer-rem
> reneg-sec 0
> 
> remote-cert-tls server
> 
> auth-user-pass /etc/openvpn/login.conf
> mute-replay-warnings
> 
> #comp-lzo
> verb 3
> pull
> fast-io
> cipher AES-256-CBC
> 
> auth SHA512
> 
> 
> I don't see anything about DNS/nameserver/resolv.conf there but I may be
> missing it.  When I tried to add that detail, it refused to start at all
> and puked on my keyboard.  It was very unhappy with me telling it what DNS
> IP to use. That up script it runs is pretty complicated looking.  I'm kinda
> nervous about messing with it.

There is no DNS problem at all.  The problem is related to your client 
renegotiating keys to encrypt the tunnel with and failing to do so.  Have a 
look at the above URL and see if any of the solutions suggested there points 
you in the right direction.

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to