What's new

OVPN connection loss after TLS re-key

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I was the other one along with @cowst who had the same issue.

First I cranked the logging up, almost to the max. Nothing in the logs to note. Just silence on server side.

I own two RT-N66Us. One is the 450 variant which I was using until today. I swapped it for the 900 variant and changed NordVPN servers as well. Same issue again.

I'll try the additional text in the config per the other posts and see if anything changes.
 
Oof. Unfortunately none of that has worked. @cowst, be glad to tag on to your NordVPN ticket. If you send me the ticket # I will reference it with NordVPN.
 
I did not see the issue in the last week since I re-enabled the vpn client (5 days ago), but it doesn't mean the issue is gone, and if it is, it means something changed on server side, because I am still on 374.43_2-26BAj9527 for a while.

About the ticket, twice I have been told the routing team was unavailable to chat, and I was invited to write them.
Hi,
I have an Asus router runnin the Merlin fork, and periodically (since going up to openvpn client 2.4?) loses connectivity silently and does not recover it.
This happens randomly (e.g., 3 days with no issues, then it happens 3 times in 2 days, and so on).
It normally happens during the hourly re-negotiation, and this is the log of the event (the first line seems not there when renegotiations are not causing the issue):
Jun 11 20:22:38 openvpn[694]: TLS: tls_process: killed expiring key
Jun 11 20:22:43 openvpn[694]: VERIFY OK: depth=1, C=PA, ST=PA, L=Panama, O=NordVPN, OU=NordVPN, CN=de92.nordvpn.com, name=NordVPN, emailAddress=cert@nordvpn.com
Jun 11 20:22:43 openvpn[694]: VERIFY KU OK
Jun 11 20:22:43 openvpn[694]: Validating certificate extended key usage
Jun 11 20:22:43 openvpn[694]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Jun 11 20:22:43 openvpn[694]: VERIFY EKU OK
Jun 11 20:22:43 openvpn[694]: VERIFY OK: depth=0, C=PA, ST=PA, L=Panama, O=NordVPN, OU=NordVPN, CN=de92.nordvpn.com, name=NordVPN, emailAddress=cert@nordvpn.com
Jun 11 20:22:45 openvpn[694]: Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Jun 11 20:22:45 openvpn[694]: Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Jun 11 20:22:45 openvpn[694]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

The FW developers (Merlin and John, from a fork of the fork) are trying to help for a while (I am not the only NordVPN customer affected), but so far they had no success. https://www.snbforums.com/threads/ovpn-connection-loss-after-tls-re-key.40066/

I tried different servers (I connect from Germany to german servers) and different accounts (I pay for 2).
Router model: Asus rt-n66u
Firmware version: merlin fork and John fork >= v24

Thank you for your letter.

We currently do not have any additional information regarding this issue, although our system administrators have told they're going to look into this as soon as possible.

Let us know if there's anything else we can assist you with.

Meh...
 
I did not see the issue in the last week since I re-enabled the vpn client (5 days ago), but it doesn't mean the issue is gone, and if it is, it means something changed on server side, because I am still on 374.43_2-26BAj9527 for a while.

About the ticket, twice I have been told the routing team was unavailable to chat, and I was invited to write them.




Meh...

What does your custom config look like?
 
I am on 68U, Merlin 380.67, NordVPN. Had similar issue consistently and based on the NordVPN support chat, I added the line "auth-retry nointeract" to the custom configuration.

Looking good so far.

Note: Make sure that you are not exceeding six concurrent connections to the VPN server.

Regards...
 
Hi Pete,

I too have been using this line in custom config to no avail. Only using 2 connections at most concurrently. I fear your problem may reappear unfortunately.

I am on 68U, Merlin 380.67, NordVPN. Had similar issue consistently and based on the NordVPN support chat, I added the line "auth-retry nointeract" to the custom configuration.

Looking good so far.

Note: Make sure that you are not exceeding six concurrent connections to the VPN server.

Regards...
 
Use the following configuration instead:

Code:
pull-filter ignore "auth-token"

That fixes it for PIA (I had nearly a whole week without any disconnection in my last test).
 
Wow, I gave up and installed openvpn in every device (no downtime detected this way for a couple of weeks already).
Perhaps I will give it a try again with this setting.
Thanks :)

Use the following configuration instead:

Code:
pull-filter ignore "auth-token"

That fixes it for PIA (I had nearly a whole week without any disconnection in my last test).
 
Nord gave me many disconnects so I switched to PIA this past weekend. Ran a ping test (24 hr every 60 sec) on PIA and not a single disconnect and no error messages in the log file.

Here's my configuration:
TLS control channel security (tls-auth / tls-crypt) DISABLED
Auth digest SHA1
Poll Interval 0
Cipher Negotiation DISABLED
Legacy/fallback cipher AES-128-CBC
Compression LZ0 Adaptive
TLS Renegotiation Time 0
Connection Retry -1

Here's my custom config:
tls-client
remote-cert-tls server
disable-occ

Running Merlin 380.68. The connection is stable. My config is bits and pieces of what I found on the forum here. I don't know much about networking so let me know if I should change or add anything for security.
Thanks
 
if you have disabled the cypher detection etc haven't you turned off the security features of the vpn?

I want to find a better vpn myself since nordvpn seems to be playing games. constant disconnects defeats the role of vpn & opens up leaking your real contact info i want to be able to maintain a constant connection. is that dreaming? or is it achievable with a different provider? im using merlin 380.68 in process of upgrading so maybe that will help?
 
If I set Cipher Negotiation to "ENABLED" I get lots of errors in my log: openvpn[5394]: Authenticate/Decrypt packet error: cipher final failed
If I set it to "DISABLED" or "ENABLED WITH FALLBACK" I can connect fine. So I assume its using the fallback AES-128-CBC when disabled.

I agree the Nord disconnects are unacceptable. Hopefully they will fix this problem with an update to their server configuration or specify updated custom config options for routers with the Merlin firmware. I moved on to PIA.
 
Last edited:
My NordVPN connection seems to have stabilized since I made some changes. Yes, I run LZO compression (not adaptive). Cipher negotiation is disabled (just AES-256-CBC). I also added the following to the custom setup: explicit-exit-notify 3
I don't know what it does but I saw the line in NordVPN's .ovpn file.
 
Hi Pete,

I too have been using this line in custom config to no avail. Only using 2 connections at most concurrently. I fear your problem may reappear unfortunately.
You are correct.

So, I cancelled NordVPN account and switched to PIA. I see a stable connection during the last two days. Unlike NordVPN, PIA does not refresh the keys every hour.

Configured PIA on GL-MT300N-V2 and it rocks.
 
I'm hitting the wall on sustained connection issues in rt-AC 68U with nordvpn. What tweaks can i do to fix this problem? It is very frustrating almost rendering vpn not doable with them other than my ikev2 mobile link. It seems like they have everyone on a timer so connection breaks at a predetermined interval. That is not the type of coverage I agreed to sign on for.
 
I'm hitting the wall on sustained connection issues in rt-AC 68U with nordvpn. What tweaks can i do to fix this problem? It is very frustrating almost rendering vpn not doable with them other than my ikev2 mobile link. It seems like they have everyone on a timer so connection breaks at a predetermined interval. That is not the type of coverage I agreed to sign on for.

Try this:

Code:
pull-filter ignore "auth-token"

It fixes it for PIA. I suspect something's broken with OpenVPN 2.4'x auth token support.
 
Do you think other clients like openvpn for Android have some specific mechanism to recover immediately from this auth issue (since they also renegotiate every hour but I never noticed the connectivity loss i have on the router)?

Try this:

Code:
pull-filter ignore "auth-token"

It fixes it for PIA. I suspect something's broken with OpenVPN 2.4'x auth token support.
 
For those who are interested; they can fill their boots at:
<PIA website>/blog/2017/05/openvpn-2-4-evaluation-summary-report/
It's all above my head.
 
Do you think other clients like openvpn for Android have some specific mechanism to recover immediately from this auth issue (since they also renegotiate every hour but I never noticed the connectivity loss i have on the router)?

Most of these clients are still using OpenVPN 2.3, which might be why they aren't affected. Also, the issue doesn't always occur immediately, for me it might take 6-10 hours before the PIA connection would fail its re-auth. A typical mobile client rarely stays connected that long.
 
I understand about the 2.3 client.

In my case I have the satellite receiver behind router vpn, and it goes always down, within 1 to 5 days.

The openvpn for Android is on my fire tv stick, again always on, and I never found it down.

Most of these clients are still using OpenVPN 2.3, which might be why they aren't affected. Also, the issue doesn't always occur immediately, for me it might take 6-10 hours before the PIA connection would fail its re-auth. A typical mobile client rarely stays connected that long.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top