What's new

ASUS RT AC68U OpenVPN client broken?

  • 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!

hp-snb

Occasional Visitor
Did anyone manage to get the OpenVPN client of an ASUS RT AC68U working with PIA under stock firmware branches 382 and/or 384?

My reason for asking……

I have got an RT AC68U (H/W version E1) which has been running a PIA VPN client under stock firmware 380.7378 for many months without problems, it is just rocksolid.
Prior to the 7378 build there were older ones which also worked fine.

When I flash firmware from the 382 or 384 branch I can not get a connection with PIA although I use the same credentials and the same (most recent) PIA .ovpn configuration files that work fine under the 380 branch firmware.

After flashing new firmware I routinely give the router a factory reset followed by a power off/on cycle to make sure settings are wiped and I have a clean out-of-the box condition.

The log file always show the same error, like this (which was created under the 382 branch BTW):
Code:
Nov 23 10:21:05 vpnclient5[1064]: OpenVPN 2.3.2 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [eurephia] [MH] [IPv6] built on Nov  2 2017
Nov 23 10:21:05 vpnclient5[1065]: UDPv4 link local: [undef]
Nov 23 10:21:05 vpnclient5[1065]: UDPv4 link remote: [AF_INET]46.166.186.225:1198
Nov 23 10:21:05 vpnclient5[1065]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Nov 23 10:21:06 vpnclient5[1065]: [acede04be2333ca8ff1493afdb53a60d] Peer Connection Initiated with [AF_INET]46.166.186.225:1198
Nov 23 10:21:08 vpnclient5[1065]: AUTH: Received control message: AUTH_FAILED
Nov 23 10:21:08 vpnclient5[1065]: SIGTERM[soft,auth-failure] received, process exiting

I have contacted our local ASUS representative who escalated this issue to Taiwan.
The result was that they could not replicate this.

I also contacted PIA, who were very helpful but could not solve this issue.

So, if someone has got a working PIA OpenVPN client with stock firmware branch 382 or 384: please share what you did to get this going!

Thanks!
 
Last edited:
AUTH_FAILED usually means a problem with the username/password provided. Make sure you do configure both of these properly on your router.
 
Thank you @RMerlin for your reply!

I recognize your concern about credentials having to be entered correctly.

Knowing myself, being a retired old fart who is an senior typo-expert, I use a KeePass password manager to hold all my credentials. I use that manager to enter my PIA credentials in the router too. The same point-and-clicks I used for the 382 and 384 branches worked fine in the 380 branch, so I am pretty sure I entered them correctly. When I noticed the authorization error I even swapped the username- and password entries deliberately to check if that would work. No joy though.....

Having said that I will try the latest build of the 384 branch tonight, when I have access to the router.
If creating the PIA OpenVPN client results in an authorization error again I will enter the full credentials manually to test if that makes any difference.
I will keep you posted.
 
Well, I finally found the cause for the authentication failure.

It was definitely not a typo, the credentials I entered in the router matched the credentials stored at PIA for 100%.

However, it appears that the OpenVPN client password length is limited to 16 characters in branch 384 (and most likely in branch 382 too as I had the same error there).
My PIA password had 20 characters, causing no problem at all in branch 380.
Apparently something changed in this area in newer branches.....

Thank you again @RMerlin for your answer which pushed me to rethink and re-assess this from the bottom up!
 
Apparently something changed in this area in newer branches.....

Starting with 382, Asus is now enforcing content length in nvram as a security measure against buffer overrun attacks. Unfortunately, it's not always visible when a variable is getting rejected due to its length.
 
Thank you for your clarification, highly appreciated!
The router is running OK now, VPN tunnel up and running, everything seems well.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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