Release [Test] Asuswrt-Merlin 384.19 - OpenVPN test builds

[RMerlin]

Howdy folks,

UPDATE 30-July: ALpha 4 test builds. Replaced up/down event handlers, fixes surrounding DNS configuration when pushed by the server.

UPDATE 25-July:: Alpha 3 test builds. See this post for details: https://www.snbforums.com/threads/test-asuswrt-merlin-384-19-openvpn-test-builds.65323/post-605382

In the Test Builds folder on Onedrive I created a new folder named OpenVPN-test. This folder contains test builds that uses largely rewritten OpenVPN code, which will need to be tested in depth.

OpenVPN's implementation in Asuswrt-Merlin is a long story, but to make it short, the code I'm currently using was originally ported from Tomato with its original author's permission. That author retains licensing rights to that code (reusing that code is forbidden unless you obtain the author's permission, which I did obtain at the time).

Quite a few portions of the code are redundant, and almost everything is implemented in a fairly monolithic way, making it hard to maintain. I first started out by refactoring some of the code to make it more manageable, by moving portions into separate functions. One thing led to another, and I ended up rewriting a large portion of the OpenVPN implementation. There were a few goals behind this project:

• Continue the code cleanup I had been working on from time to time in the past
• Make the code more modular, moving redundant portions into separate functions
• Rewriting as much as possible so it could be placed under a GPL licence (or for portions I had already written, move them under a GPL licence)

Feature-wise, the implementation still has all the same features. The webui wasn't changed, only the backend code was reorganized. A few minor issues were tracked down along the way, some were fixed (like the reneg time that could be set to a larger vaue than supported by nvram storage). Others were added to my todo list.

One of the related enhancements I've made while working on this was to change the way OpenVPN instances are launched at boot time, which should help make it more reliable on certain scenarios (such as when you have a very fast NTP server, which could lead to OpenVPN instances starting twice at boot time).

With such a large code change, pretty much everything tied to OpenVPN will need to be retested, hence this test project. Please, try out these test builds. Try out various OpenVPN setups, both client and server. Report any issue encountered (particularly new ones). Please stick to only OpenVPN-related issues. This isn't about the 384.19 dev cycle as a whole, this is currently only focused on OpenVPN. The full beta cycle will happen later.

Test builds: https://www.asuswrt-merlin.net/test-builds

Thank you for your cooperation.

 

[RMerlin]

• Error message about "-1" being an invalid retry value: this is normal, -1 was incorrectly used for "infinite retry", while it should have been 0 instead. Just switch it to 0 when the error message pops up when editing an existing client.
• Garbled "Starting_OpenVPN_%s_%d...: client" log message at the start of an instance - fixed.
• Initializing a new server instance fails to properly store/use the new client keypair that was generated (these two are missing from ovpn_get_runtime_filename());

 

[RMerlin]

One change that could impact people who were interacting with the DNS and firewall setup scripts generated for OpenVPN: instead of locating these under /etc/openvpn/fw and /etc/openvpn/dns, they have now been moved within their respective /etc/openvpn/server1-2 and client1-5/ folder, alongside the rest of the instance's config files. This is in line with upstream, and also made more sense. Note that the updown-client.sh script was also updated to handle this change.

 

[Intrepid2007]

I just updated my RT-AX88U to this firmware version (I had alpha 1 installed on it, it runned 10 days without issues).

After rebooting the router, it went online (internet status: connected) and clients not using VPN were connected to the internet without issues.

However I had an issue with OpenVPN routing rules.
I use 3 OpenVPN clients and each one has a rule that routes traffic to that VPN client.

My routing rules look like this:

It appears that traffic to these VPN clients with rules was not working (blocked), no internet.
To fix this, I had to remove (<apply>) and then add the rules (<apply>) again for each VPN client.

Now VPN routing works fine.

 

[Toink]

Thank you @RMerlin for your hard work!
Dirty-flashed from the previous BETA Build 384.19_alpha1-g2546f95291. My OpenVPN settings are working so far, as expected. I did not experience @Intrepid2007's routing rules. Will try to observe more.

 

[AurelM]

I've updated my local RT-AC68U from 384.18_0 to 384.19_alpha2 (dirty update).
The OpenVPN server started without issues and clients could connect to it, an iPhone and a remote RT-AC66U B1 running 384.18_0, which I could access through the vpn connection.
Setting used:

Interface Type - TUN
Protocol - UDP
Server Port - 1194 (default)
Authorization Mode - TLS
Username/Password Authentication - No
TLS control channel security (tls-auth / tls-crypt) - Encrypt channel
HMAC Authentication - SHA1
Advertise DNS to clients - Yes
Cipher Negotiation - Disabled
Legacy/fallback cipher - AES-128-CBC
Compression - Disable
Log verbosity - 3 (default)
Manage Client-Specific Options - Yes
Allow Client <-> Client - Yes
Allow only specified clients - No

I'll update the remote RT-AC66U B1 to 384.19_alpha2 when it stops being used and report back then.
I've updated the remote router and vpn is still working as expected (dirty update over the vpn connection).

 

[no_name]

Upgraded RT-AC86U from 384.18_0 to 384.19_alpha2 and did a factory reset

VPN clients 1, 3 & 5 appear to be working fine and start after a reboot

I'm not sure is this is relevant or helpful, Unbound requests via VPN Client 1 tunnel is enabled and working as normal

 

[hifiwifi]

Working fine with PIA. Initially, the "Exclusive" DNS setting wasn't working, but changing to Relaxed and back to Exclusive fixed the leaks.

 

[TechTinkerer]

@Merlin Thanks for this have dirty flashed from 384.19_alpha1-g2ee0f0674 to your openvpn test 384.19_alpha2-gd6f340a2c will run it for a bit and report back if any weirdness

 

[visortgw]

Successfully updated various routers ((2) RT-AX88U, (2) RT-AC68U, and RT-AC86U) on local and distant networks. OpenVPN servers and clients on all are functioning as expected without issue. Thanks!

 

[maxbraketorque]

Is it possible to downgrade from these OVPN test builds to 384.18 without resetting the router?

 

[octopus]

Just updated to alpha2 and my 3-vpn clients working fine. All mine scripts around vpn working fine to.
Thank you RMerlin

EDIT: Only thing a value was -1 need to be 0. Then right dns working again.

Iustus updated ad alpha2 et III-finis opus vpn clients. Denique, ut omnia mea scripta circa vpn opus.
Tibi gratias ago RMerlin

 

[RMerlin]

Is it possible to downgrade from these OVPN test builds to 384.18 without resetting the router?

Depends on the router model. Best to make a backup of your settings first.

 

[RMerlin]

To the people who had issues going away after you remove/re-add a setting: this is more likely to be an issue occurring when the client is started at boot time, and just restarting the client resolved the issue. Can you check what`s in your system log during both OpenVPN starts, and see if there is anything different between the two instances?

 

[Torson]

Is it possible to downgrade from these OVPN test builds to 384.18 without resetting the router?

Updated to the newly posted 384.19 alpha2 on the RT-C86U - no Internet access. Also, amtm and Skynet would not start; just threw a syntax error. Downgraded back to 384.18 which seemed to work. However, I'm now unable to log back into the web UI or ssh in.
Well, time for a long postponed nuclear reset...

 

[QuikSilver]

Updated to the newly posted 384.19 alpha2 on the RT-C86U - no Internet access. Also, amtm and Skynet would not start; just threw a syntax error. Downgraded back to 384.18 which seemed to work. However, I'm now unable to log back into the web UI or ssh in.
Well, time for a long postponed nuclear reset...

If you had no internet then that may be why amtm and skynet would not start. I believe they wait for ntp to sync before starting. Would be curious to know why you didnt have internet after the upgrade though.

 

[Torson]

If you had no internet then that may be why amtm and skynet would not start. I believe they wait for ntp to sync before starting. Would be curious to know why you didnt have internet after the upgrade though.

I use Xentrk's Selective Routing; all devices go through OVPN Client 1 and the router through WAN. Also, I was able to access an OVPN server on a remote router through another OVPN Client on the AC86U to which most devices do not have access to. It now works as before on 384.18 but lost login access to it. No big deal, I expect that when trying alpha code.

 

[maxbraketorque]

Depends on the router model. Best to make a backup of your settings first.

RT-AC86U. I have time to try if I don't need to reset and apply all my settings if something goes wrong on the test build. I have two different VPN connections setup with custom certificates, and reapplying all that is more than I have time for right now.

 

[kernol]

RT-AC86U. I have time to try if I don't need to reset and apply all my settings if something goes wrong on the test build. I have two different VPN connections setup with custom certificates, and reapplying all that is more than I have time for right now.

My RT-AC86U along with add ons per my signature did not fare well with this Alpha - and yes ... I had to factory reset to revert to 384.18 ... but could restore settings and JFFS folder from 384.18 backup. OpenVPN seemed fine - but several other issues not open for comment in this thread were broken.

Best to await Beta unless you don't use similar add-ons to me [including Skynet which broke badly and could not be uninstalled or reinstalled - which is why I bailed and went back to 384.18].

 

[FTC]

Hi, I tried the alpha code this afternoon in my rt-ax88u. Basically my OpenVPN server started and allowed connection from my other devices that were not in the network, however it seemed like working very slowly.. . Now looking at the CPU usage I could also observe that around 30% of my CPU was being constantly pegged by the processes jffs2_gcd_mtd9 and nt_center (unrelated to vpn). I finally had to go back to 384.18 where all this problems do not exist.