bengalih
Senior Member
I had this issue which appears to have ben discussed at least once here:
www.snbforums.com
However that was from a while ago and no definitive troubleshooting/root cause was listed.
I have some more specific information and I believe this is a a big enough problem it should have some more visibility for a possible fix, and at the very least to inform people who might come looking for the same issue.
I'm not sure if this is something that @RMerlin can fix, or if it is baked into the Asus code and therefore we are stuck with it.
At the very least I hope this helps others who are experiencing this strange issue, and if lucky we can find a fix (or at least someone with the knowledge can state how widespread and/or if it has indeed been fixed).
I want to preface that I am on a RT-AC68U with 386.3_2, which I realize is about 3 years old. The reason I have not upgraded is that last I checked (about a year ago) there were some problems with NVRAM space issues with the newer firmware which seemed like they were going to cause issues for me (large custom_clientlist). I don't know if any of these issues are fixed, I will have to research that to see if I can upgrade and if these OpenVPN issues are resolved. However, I have looked at the changelog and do not see anything which would indicate that these OpenVPN issues are fixed, and not much in the forums at all acknowledging the issue.
Issue:
As was mentioned in the linked thread above, the issue exhibits itself upon adding new users to the OpenVPN server. I have tested with only 2 users (not including the built-in account, which is apparently never affected). In short, what happens is that if you add a second user at a future time (most likely anytime after the router has been rebooted at least once) the password of the first user gets corrupted. If you then remove and readd the first user (as this is the only way to change/reset password), the second user would then get affected. The only solution is to add both users at once. I suspect this issue would occur on subsequent users, although I'm unsure if it would corrupt all users passwords or just some.
Some technical information and testing:
I won't claim to be definitive on this, but from my investigation it appears that the usernames and passwords for the OpenVPN server are saved in NVRAM.
Specifically in the vpn_serverx_clientlist variable.
In the below example, I show a user exists called jsmith exists with a password "ThisIsMyPassword".
Now you will note that the password is unencrypted. It appears to remain this way initially, I believe until a reboot happens (whether this is a full reboot or a reboot just of the VPN services, I have not yet tested).
After a reboot however, the entry will look like this:
XxYyZz12345 is just my shorthand of the encrypted password. At this point, everything is fine with the VPN and will remain so indefinitely. I had been running mine for years with this configuration and only a single user (in addition to the built-in admin account).
If however you decide to add a second user. Let's say we want to add jdoe with password "Password123", this is what it will look like:
The above makes sense based on what we have seen so far. The jsmith password is unchanged (and encrypted), but the new jdoe password has not yet been encrypted. We would expect/hope that after a reboot both would be properly encrypted, but this is only half true. The VPN will continue to work properly with both user account until a reboot occurs. At that time, the jsmith account will cease to function, and looking at the variable we can see why:
"XxYyZz456" represents the proper encrypted form of jdoe's password. However "AFBgMc173" represents that the encrypted password of jsmith has been garbled and no longer represents the unencrypted "ThisIsMyPassword". Therefore, the jsmith user will now no longer be able to login.
You can solve this by deleting and re-adding jsmith with the proper credentials, which will then display the following:
And everything will continue to work until the next reboot:
Here we can see that jdoe's encrypted password has been corrupted to "XAPyZq596", and that user will no longer be able to login.
This cycle will continue with only one solution: Delete both users and add them back at the same time.
This is obviously a major problem for this function if you have several users. Even if you could add all known users at once, if one user forgets their password, the only way to reset it is to add and delete the user which will affect at least one other user and then it is a chain effect from there. All users would need to be removed and re-added. Add to that the fact it is impossible to determine the unencrypted passwords of the current users, all users will have to have their passwords reset.
Again, I don't know what other models and firmware versions this affects, but as it is likely not tied to the model, and I can't find anything in the changelog about remedies to it, I expect it affects many devices out there and simply not many people are using multiple users on their VPN. Those that are however will be strongly affected.
NOTE:
One other side piece of technical information. As OpenVPN is authenticated via the underlying PAM subsystem, therefore the user accounts and passwords appear to also exist in the /etc/password and /etc/shadow files. These files are generated each time at boot. I can only assume that the data inside NVRAM (specifically vpn_serverx_clientlist) is used to create the data values in these files.
Even when the passwords in NVRAM match, the values in /etc/shadow may be different each time. This is due to the way the salts are used in the hash.
OpenVPN Usernames and Passwords not working
I am currently running Asuswrt-Merlin 386.2_6 on two Asus routers (RT-AC68U and RT-AC86U). Since a few software releases back, I have found that usernames and passwords are not working with OpenVPN (I use certificates PLUS usernames/passwords -- not usernames and passwords only). OpenVPN...
www.snbforums.com
However that was from a while ago and no definitive troubleshooting/root cause was listed.
I have some more specific information and I believe this is a a big enough problem it should have some more visibility for a possible fix, and at the very least to inform people who might come looking for the same issue.
I'm not sure if this is something that @RMerlin can fix, or if it is baked into the Asus code and therefore we are stuck with it.
At the very least I hope this helps others who are experiencing this strange issue, and if lucky we can find a fix (or at least someone with the knowledge can state how widespread and/or if it has indeed been fixed).
I want to preface that I am on a RT-AC68U with 386.3_2, which I realize is about 3 years old. The reason I have not upgraded is that last I checked (about a year ago) there were some problems with NVRAM space issues with the newer firmware which seemed like they were going to cause issues for me (large custom_clientlist). I don't know if any of these issues are fixed, I will have to research that to see if I can upgrade and if these OpenVPN issues are resolved. However, I have looked at the changelog and do not see anything which would indicate that these OpenVPN issues are fixed, and not much in the forums at all acknowledging the issue.
Issue:
As was mentioned in the linked thread above, the issue exhibits itself upon adding new users to the OpenVPN server. I have tested with only 2 users (not including the built-in account, which is apparently never affected). In short, what happens is that if you add a second user at a future time (most likely anytime after the router has been rebooted at least once) the password of the first user gets corrupted. If you then remove and readd the first user (as this is the only way to change/reset password), the second user would then get affected. The only solution is to add both users at once. I suspect this issue would occur on subsequent users, although I'm unsure if it would corrupt all users passwords or just some.
Some technical information and testing:
I won't claim to be definitive on this, but from my investigation it appears that the usernames and passwords for the OpenVPN server are saved in NVRAM.
Specifically in the vpn_serverx_clientlist variable.
In the below example, I show a user exists called jsmith exists with a password "ThisIsMyPassword".
Code:
myadmin@router-asus:/tmp/home/root# nvram show | grep vpn_serverx_clientl
vpn_serverx_clientlist=<jsmith>ThisIsMyPasswordAfter a reboot however, the entry will look like this:
Code:
myadmin@router-asus:/tmp/home/root# nvram show | grep vpn_serverx_clientl
vpn_serverx_clientlist=<jsmith>AaBbCc123If however you decide to add a second user. Let's say we want to add jdoe with password "Password123", this is what it will look like:
Code:
myadmin@router-asus:/tmp/home/root# nvram show | grep vpn_serverx_clientl
vpn_serverx_clientlist=<jsmith>AaBbCc123<jdoe>Password123
Code:
myadmin@router-asus:/tmp/home/root# nvram show | grep vpn_serverx_clientl
vpn_serverx_clientlist=<jsmith>AFBgMc173<jdoe>XxYyZz456You can solve this by deleting and re-adding jsmith with the proper credentials, which will then display the following:
Code:
myadmin@router-asus:/tmp/home/root# nvram show | grep vpn_serverx_clientl
vpn_serverx_clientlist=<jdoe>XxYyZz456<jsmith>ThisIsMyPassword
Code:
myadmin@router-asus:/tmp/home/root# nvram show | grep vpn_serverx_clientl
vpn_serverx_clientlist=<jdoe>XAPyZq596<jsmith>AaBbCc123This cycle will continue with only one solution: Delete both users and add them back at the same time.
This is obviously a major problem for this function if you have several users. Even if you could add all known users at once, if one user forgets their password, the only way to reset it is to add and delete the user which will affect at least one other user and then it is a chain effect from there. All users would need to be removed and re-added. Add to that the fact it is impossible to determine the unencrypted passwords of the current users, all users will have to have their passwords reset.
Again, I don't know what other models and firmware versions this affects, but as it is likely not tied to the model, and I can't find anything in the changelog about remedies to it, I expect it affects many devices out there and simply not many people are using multiple users on their VPN. Those that are however will be strongly affected.
NOTE:
One other side piece of technical information. As OpenVPN is authenticated via the underlying PAM subsystem, therefore the user accounts and passwords appear to also exist in the /etc/password and /etc/shadow files. These files are generated each time at boot. I can only assume that the data inside NVRAM (specifically vpn_serverx_clientlist) is used to create the data values in these files.
Even when the passwords in NVRAM match, the values in /etc/shadow may be different each time. This is due to the way the salts are used in the hash.
