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

[NoobuserAdvanced]

Thanks! Merlin

 

[RMerlin]

Something is off. I cant enable the client, must provide username and password. Authorization Mode is TLS and Username/Password Authentication is set to no.

What does the system log says?

 

[octopus]

Installed Alpha3 and seems to work, can't get any DNS answer from ipleak.net but I think there is problem on their site. work with dnsleaktest.com

 

[Sonyrolfy]

What does the system log says?

Its a popup on the top op the client page at the moment i want to enable the vpn client (switch to on green) its says pls use username and password. AIRVPN doenst use the username or password. Did several reboots, cleaned browser. etc.

 

[Sonyrolfy]

Installed Alpha3 and seems to work, can't get any DNS answer from ipleak.net but I think there is problem on their site. work with dnsleaktest.com

At the moment i do see this problem with ipleak as well.

 

[octopus]

See if I can explain this,

When eg client1 Connected (Local: 10.128.0.100) goes down usually client1 get a new ip from VPN-isp but it's not update public ip display. gettunnelip.sh not been executed.

Is it possible to do something about that, or can I do it with some own code?

@RMerlin

 

[L&LD]

Updated both the RT-AX88U and the RT-AX58U in my signature to Alpha 3 after (almost) 5 days of uptime on Alpha 2 without issues.

The OpenVPN Servers are both working fully as is amtm and all the scripts I'm running too. This contrasts with a sole case of an RT-AC86U (reported above) that lost both amtm, USB swap file, and OpenVPN Server support when flashed to Alpha 2.

 

[jsbeddow]

Updated both the RT-AX88U and the RT-AX58U in my signature to Alpha 3 after (almost) 5 days of uptime on Alpha 2 without issues.

The OpenVPN Servers are both working fully as is amtm and all the scripts I'm running too. This contrasts with a sole case of an RT-AC86U (reported above) that lost both amtm, USB swap file, and OpenVPN Server support when flashed to Alpha 2.

Nice data point, but I am still leery to jump to this build (with my 86U) directly from 384.18 final: has anyone tried this sucessfully? That is, without having to do a full reset and rebuild from scratch (scripts and jffs included)?

 

[RMerlin]

Its a popup View attachment 24902on the top op the client page at the moment i want to enable the vpn client (switch to on green) its says pls use username and password. AIRVPN doenst use the username or password. Did several reboots, cleaned browser. etc.

Gotcha. The new empty username/password field check doesn't properly check first if password authentication itself is enabled.

 

[Xentrk]

Fresh test builds were uploaded a few minutes ago. These contain a second wave of code rewrite, which completes the replacement of the old code, and also contains a few bug fixes (both old and new bugs).

I haven`t kept a detailed list of changes, but in summary:

• Renamed libvpn to libovpn (since it's no longer just an open source replacement for Asus' own libvpn)
• Moved what was left of the rc/openvpn.c code into libovpn. rc/openvpn.c now only contains my code (one remaining Asus-written function was moved to rc/ovpn.c, which is their code)
• rc/openvpn.c still contains my code for stopping/starting, as I can't use any OpenSSL code in libovpn due to technical reasons (AMNG using two separate versions of OpenSSL)
• Improved error report in case of client failure. Webui will now properly report a config error for instance, rather than being stuck on "connecting", or reporting a key/cert error (when it really was a config error)
• Firewall restarts will now reapply both Exclusive DNS rules as well as Traditional QoS firewall fix
• Removed a lot of the unnecessary debug logging code (most of it was only useful to developers rather than end-user), and streamlined regular logging, saving a good bit of code size
• Tweaks to the updown-client.sh script

I am currently considering also rewriting the updown-client.sh event script, to make it C code like Asus' own implementation. I'm undecided yet as it currently works fairly well.

Please retest everything once again around OpenVPN, both client and server.

So far so good on the client side. I also updated the x3mRouting-384.19 test branch updown-client.sh to incorporate the updates. If you decide to rewrite updown-client.sh to make it C code, is there a way I could implement a custom version for x3mRouting that will take precendence over the firmware version? Right now, I use the mount command to implement the updown-client.sh script.

  mount -o bind /jffs/addons/x3mRouting/updown-client.sh /usr/sbin/updown-client.sh

Thank you.

 

[RMerlin]

So far so good on the client side. I also updated the x3mRouting-384.19 test branch updown-client.sh to incorporate the updates. If you decide to rewrite updown-client.sh to make it C code, is there a way I could implement a custom version for x3mRouting that will take precendence over the firmware version? Right now, I use the mount command to implement the updown-client.sh script.

If I rewrite it in C, the config will still use up/down event handlers, it's just that instead of using "up updown-client.sh", it would be something like "up ovpn-up 1". Not sure however if binding mounts work on top of symlinks (as ovpn-up would be a symlink to rc).

Worst case scenario, a postconf should allow you to replace the up/down config directives to point at you instead.

 

[RMerlin]

Its a popup View attachment 24902on the top op the client page at the moment i want to enable the vpn client (switch to on green) its says pls use username and password. AIRVPN doenst use the username or password. Did several reboots, cleaned browser. etc.

For now, just temporarily enable user/pass auth, enter bogus content into both username and password, then re-disable user/pass auth.

 

[Sonyrolfy]

For now, just temporarily enable user/pass auth, enter bogus content into both username and password, then re-disable user/pass auth.

Oke will do,. Never thought that will do the trick. I've to make a clean install first now.

 

[Sonyrolfy]

Nice data point, but I am still leery to jump to this build (with my 86U) directly from 384.18 final: has anyone tried this sucessfully? That is, without having to do a full reset and rebuild from scratch (scripts and jffs included)?

Its not a big of a effort for me to reset and install the new Alpha because of the (critical) vpn i want to use. most of the time i will write over it.

 

[Sonyrolfy]

For now, just temporarily enable user/pass auth, enter bogus content into both username and password, then re-disable user/pass auth.

Yes that did the trick Username: Thank you Pass: Merlin And NO leaks!

 

[TechTinkerer]

@RMerlin
on Rules for routing client traffic through the tunnel in VPN, Destination IP entries are shown as invisible on alpha 3
Thanks

 

[octopus]

@RMerlin
on Rules for routing client traffic through the tunnel in VPN, Destination IP entries are shown as invisible on alpha 3
Thanks

Pls read change log.

 

[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).

I've updated both routers to 384.19_alpha3 and the vpn between them works as intended (dirty update for both of them).

Thank you @RMerlin .

 

[gfondeur]

Because regardless of Wireguard, the reasons behind the OpenVPN rewrite (like the legal status of the existing code) still remained. And dropping OpenVPN is way out of question. OpenVPN runs on virtually anything, and is highly flexible. Not the case for Wireguard.

Wireguard is nowhere a replacement for OpenVPN, it`s just an alternative.

Rewriting existing code is far less work than writing everything from scratch for a brand new technology.

Nevermind, I found your answer to my question on another post

 

[brummygit]

Thanks, I would have said I selected 2048 in that screen but can't find a way back to the same screen again. I'll wait for it to be fixed then, thanks again for your hard work.

I still have the same issue with Alpha3 but assume it's because it has not yet been fixed.