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

[L&LD]

Just a quick report.

I flashed a test RT-AC86U with this Alpha 2 firmware (was using 384.18_0) and lost not only the OpenVPN servers, but also the script support too (had to format the JFFS partition on next boot and then reboot 3 times afterward).

In addition to getting a 'read only' message when trying to start amtm and amtm would not start (of course).

Before I reformatted the JFFS partition, I disabled scripts, rebooted a few times, enabled scripts and rebooted a couple of more times. No joy.

After reformatting the JFFS partition, I could launch and select the color scheme for amtm, but all scripts were MIA.

I will have to return to this test location later next week. I didn't have time to do a full M&M Config (another customer had called in the meantime).

On a positive note, the network works great with 384.19 Alpha 2. Even with dirty upgrades for many months now testing new betas and alphas.

 

[brummygit]

It's on the settings page the first time you enable a new server instance.

Anyway, this issue seems to be more complex than that, there's some code missing to ensure it gets stored to jffs as well.

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.

 

[gerardr]

Performed a dirty upgrade from 384.19_alpha1 (installed via dirty upgrade from stock Asus 9354) on an RT-AX3000. I don't use VPN, so this is just an FYI that the RT-AX58U alpha2 firmware is basically working on it's cousin the RT-AX3000.

 

[L&LD]

Just an update to post #61 above.

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

Just a quick report. I flashed a test RT-AC86U with this Alpha 2 firmware (was using 384.18_0) and lost not only the OpenVPN servers, but also the script support too (had to format the JFFS partition on next boot and then reboot 3 times afterward). In addition to getting a 'read only' message...

www.snbforums.com

Surprisingly, the OpenVPN servers were still 'On' and (seemingly) in effect after flashing Alpha 2 on the RT-AC86U. Today, I tried connecting to that router but just getting TLS errors (BIO, object, handshake, etc.) and not being able to connect at all.

What made me think the OpenVPN servers were 'lost' in the previous post, was, they don't show in the VPN Status tab, but do when the VPN Server tab is selected.

I hope this additional information is useful for @RMerlin.

 

[RMerlin]

I am able to duplicate. Applying the DNS Filter bounces the firewall which is probably responsible for wiping out the Accept DNS Configuration = Exclusive DNS iptables rules. Just bouncing the VPN Client using the apply button reinstates them. Or, from command line: service restart_vpnclient1

Will show the DNSFilter Rules

iptables --line -t nat -nvL PREROUTING

DNS Exclusive Rules for VPN Client 1 (can be 1-5)

iptables --line -t nat -nvL DNSVPN1

For your use case, I recommend setting DNS Filter to Router. LAN clients routed to the VPN will use the DNS of the Express since you have the Accept DNS Configuration = Exclusive. WAN clients will use the DNS specified on the WAN page.

This is an old design limitation. DNS redirections are handled by OpenVPN whenever its interface goes up or down rather than by the firewall, so it currently has no way of knowing if there has been a firewall restart.

Actually shouldn't be so bad, since those rules are stored in a separate script, in parallel to the regular vpn firewall script.

 

[Protik]

@RMerlin, I am curious, I heard wireguard code is simpler and way smaller than OpenVPN. Then why choose to rewrite OpenVPN? Because you are familiar with the technology?

 

[NoobuserAdvanced]

This build run smooth 4-days now....Nice work Merlin!

 

[kernol]

Just an update to post #61 above.

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

Just a quick report. I flashed a test RT-AC86U with this Alpha 2 firmware (was using 384.18_0) and lost not only the OpenVPN servers, but also the script support too (had to format the JFFS partition on next boot and then reboot 3 times afterward). In addition to getting a 'read only' message...

www.snbforums.com

Surprisingly, the OpenVPN servers were still 'On' and (seemingly) in effect after flashing Alpha 2 on the RT-AC86U. Today, I tried connecting to that router but just getting TLS errors (BIO, object, handshake, etc.) and not being able to connect at all.

What made me think the OpenVPN servers were 'lost' in the previous post, was, they don't show in the VPN Status tab, but do when the VPN Server tab is selected.

I hope this additional information is useful for @RMerlin.

Thanks for providing further info for Merlin - saves me from having another attempt on my RT-AC86U this weekend ... after feeling a bit bad about bailing out of the Alpha2 after hitting all the script and amtm problems ... and not focusing on the OpenVPN side. I thought OpenVPN was fine because of the status in the webgui - glad you tested.

EDIT: Is Tim so chuffed with his avatar that he has found a way to replicate it into every quoted post in the forum @thiggins

 

[Xentrk]

This is an old design limitation. DNS redirections are handled by OpenVPN whenever its interface goes up or down rather than by the firewall, so it currently has no way of knowing if there has been a firewall restart.

Actually shouldn't be so bad, since those rules are stored in a separate script, in parallel to the regular vpn firewall script.

I have a similar problem in x3mRouting for IPSET lists routed through the modified OpenVPN Client Screen. PREROUTING rules for IPSET lists get wiped after a firewall-start. I just added functionality to the 384.19 test branch to bounce all active VPN clients after a firewall-start to reinstate the rules for both IPSET lists and DNS.

Another idea I came up with is the code below. It checks if the dns.sh file exists, if it does, it runs the script to implement the DNS rules after a firewall-start.

/jffs/scripts/firewall-start

#!/bin/sh
for VPN_CLIENT in 1 2 3 4 5; do
  [ -s "/tmp/etc/openvpn/client${VPN_CLIENT}/dns.sh" ] && sh "/tmp/etc/openvpn/client${VPN_CLIENT}/dns.sh"
done

 

[Delusion]

Just a quick report.

I flashed a test RT-AC86U with this Alpha 2 firmware (was using 384.18_0) and lost not only the OpenVPN servers, but also the script support too (had to format the JFFS partition on next boot and then reboot 3 times afterward).

In addition to getting a 'read only' message when trying to start amtm and amtm would not start (of course).

Before I reformatted the JFFS partition, I disabled scripts, rebooted a few times, enabled scripts and rebooted a couple of more times. No joy.

After reformatting the JFFS partition, I could launch and select the color scheme for amtm, but all scripts were MIA.

I will have to return to this test location later next week. I didn't have time to do a full M&M Config (another customer had called in the meantime).

On a positive note, the network works great with 384.19 Alpha 2. Even with dirty upgrades for many months now testing new betas and alphas.

I compiled yesterday the build (mainline) with new commits which include Second stage of OpenVPN rewrites and this Happened to me too but reformatting the JFFS partition didn't help , on tools page I saw that JFFS partition was unmounted, I had to do hard reset and now it works fine/=

OpenVPN client works very well. The only issue I see with self compiled build is that every reboot to the router, I have to export certificate I generated for accessing webui via HTTPS and install the certificate again as if a new certificate is being generated every reboot.

 

[Blacklistedcard]

@RMerlin, I am curious, I heard wireguard code is simpler and way smaller than OpenVPN. Then why choose to rewrite OpenVPN? Because you are familiar with the technology?

The Linux kernel on the routers is too old for wireguard.

 

[Blacklistedcard]

I compiled yesterday the build (mainline) with new commits which include Second stage of OpenVPN rewrites and this Happened to me too but reformatting the JFFS partition didn't help , on tools page I saw that JFFS partition was unmounted, I had to do hard reset and now it works fine/=

OpenVPN client works very well. The only issue I see with self compiled build is that every reboot to the router, I have to export certificate I generated for accessing webui via HTTPS and install the certificate again as if a new certificate is being generated every reboot.

I was able to reformat my JFFS partition on my AC86u. It worked and amtm installed everything in about 10 minutes.

 

[Butterfly Bones]

The Linux kernel on the routers is too old for wireguard.

For most ASUS routers, yes. Not true for AC86U and AX88U
https://www.snbforums.com/threads/experimental-wireguard-for-rt-ac86u-ax88u.46164/

 

[tarzan2000]

Server 1 (Local+External Network)
- TCP
- TUN
- TLS\Encrypt Ch\SHA512\AES-256-CGM\LZO\Advertize DNS\
- No static Key, firmware cert and key's 2048 bits

Server 2 (Local Network)
- TCP
- TUN
- TLS\Encrypt Ch\SHA512\AES-256-CGM\LZO\
- No static Key, firmware cert and key's 2048 bits

No scripts
Everything is working as before, great.
AC86U

Spoiler: log

Starting_OpenVPN_%s_%d...: server
ovpn-server1[189]: OpenVPN 2.4.9 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on 21 2020
ovpn-server1[189]: library versions: OpenSSL 1.1.1g 21 Apr 2020, LZO 2.08
ovpn-server1[1880]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
ovpn-server1[1880]: PLUGIN_INIT: POST /usr/lib/openvpn-plugin-auth-pam.so '[/usr/lib/openvpn-plugin-auth-pam.so] [openvpn]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY
ovpn-server1[1880]: Diffie-Hellman initialized with 2048 bit key
ovpn-server1[1880]: Outgoing Control Channel Encryption: Cipher 'AES--CTR' initialized with bit key
ovpn-server1[1880]: Outgoing Control Channel Encryption: Using bit message hash 'SHA' for HMAC authentication
ovpn-server1[1880]: Incoming Control Channel Encryption: Cipher 'AES--CTR' initialized with bit key
ovpn-server1[1880]: Incoming Control Channel Encryption: Using bit message hash 'SHA' for HMAC authentication
ovpn-server1[1880]: TUN/TAP device tun21 opened
ovpn-server1[1880]: TUN/TAP TX queue length set to 1000
ovpn-server1[1880]: /sbin/ifconfig tun21 10.8.0.1 netmask 5.5.5.0 mtu 1500 broadcast 10.8.0.5
lldpd[1355]: removal request for address of 10.8.0.1%23, but no knowledge of it
lldpd[1355]: removal request for address of 10.8.0.1%23, but no knowledge of it
ovpn-server1[1880]: updown.sh tun21 1500 124 10.8.0.1 5.5.5.0 init
ovpn-server1[1880]: Could not determine IPv4/IPv protocol. Using AF_INET
ovpn-server1[1880]: Socket Buffers: R=[8380->8380] S=[1384->1384]
ovpn-server1[1880]: Listening for incoming TCP connection on [AF_INET][undef]:43443
ovpn-server1[1880]: TCPv4_SERVER link local (bound): [AF_INET][undef]:43443
ovpn-server1[1880]: TCPv4_SERVER link remote: [AF_UNSPEC]
ovpn-server1[1880]: MULTI: multi_init called, r= v=
ovpn-server1[1880]: IFCONFIG POOL: base=10.8.0.2 size=2, ipv=0
ovpn-server1[1880]: MULTI: TCP INIT maxclients=1024 maxevents=1028
ovpn-server1[1880]: Initialization Sequence Completed
openvpn: OpenVPN server 1 launch completed.
openvpn: Setting up OpenVPN server 2...
Starting_OpenVPN_%s_%d...: server
ovpn-server2[1943]: OpenVPN 2.4.9 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on 21 2020
ovpn-server2[1943]: library versions: OpenSSL 1.1.1g 21 Apr 2020, LZO 2.08
ovpn-server2[194]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
ovpn-server2[194]: PLUGIN_INIT: POST /usr/lib/openvpn-plugin-auth-pam.so '[/usr/lib/openvpn-plugin-auth-pam.so] [openvpn]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY
ovpn-server2[194]: Diffie-Hellman initialized with 2048 bit key
ovpn-server2[194]: Outgoing Control Channel Encryption: Cipher 'AES--CTR' initialized with bit key
ovpn-server2[194]: Outgoing Control Channel Encryption: Using bit message hash 'SHA' for HMAC authentication
ovpn-server2[194]: Incoming Control Channel Encryption: Cipher 'AES--CTR' initialized with bit key
ovpn-server2[194]: Incoming Control Channel Encryption: Using bit message hash 'SHA' for HMAC authentication
ovpn-server2[194]: TUN/TAP device tun22 opened
ovpn-server2[194]: TUN/TAP TX queue length set to 1000
ovpn-server2[194]: /sbin/ifconfig tun22 10.1.0.1 netmask 5.5.5.0 mtu 1500 broadcast 10.1.0.5
lldpd[1355]: removal request for address of 10.1.0.1%24, but no knowledge of it
lldpd[1355]: removal request for address of 10.1.0.1%24, but no knowledge of it
ovpn-server2[194]: updown.sh tun22 1500 124 10.1.0.1 5.5.5.0 init
ovpn-server2[194]: Could not determine IPv4/IPv protocol. Using AF_INET
ovpn-server2[194]: Socket Buffers: R=[8380->8380] S=[1384->1384]
ovpn-server2[194]: Listening for incoming TCP connection on [AF_INET][undef]:43444
ovpn-server2[194]: TCPv4_SERVER link local (bound): [AF_INET][undef]:43444
ovpn-server2[194]: TCPv4_SERVER link remote: [AF_UNSPEC]
ovpn-server2[194]: MULTI: multi_init called, r= v=
ovpn-server2[194]: IFCONFIG POOL: base=10.1.0.2 size=2, ipv=0
ovpn-server2[194]: MULTI: TCP INIT maxclients=1024 maxevents=1028
ovpn-server2[194]: Initialization Sequence Completed
openvpn: OpenVPN server 2 launch completed.
ovpn-server1[1880]: TCP connection established with [AF_INET]xx.xx.xx.xx:392
ovpn-server1[1880]: xx.xx.xx.xx:392 TLS: Initial packet from [AF_INET]xx.xx.xx.xx:392, sid=aab5d5d 38513b09
ovpn-server1[1880]: xx.xx.xx.xx:392 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=ASUS, CN=RT-AC8U, emailAddress=me@myhost.mydomain
ovpn-server1[1880]: xx.xx.xx.xx:392 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=ASUS, CN=client, emailAddress=me@myhost.mydomain
ovpn-server1[1880]: xx.xx.xx.xx:392 peer info: IV_VER=3.git:released:3e5f9a:Release
ovpn-server1[1880]: xx.xx.xx.xx:392 peer info: IV_PLAT=android
ovpn-server1[1880]: xx.xx.xx.xx:392 peer info: IV_NCP=2
ovpn-server1[1880]: xx.xx.xx.xx:392 peer info: IV_TCPNL=1
ovpn-server1[1880]: xx.xx.xx.xx:392 peer info: IV_PROTO=2
ovpn-server1[1880]: xx.xx.xx.xx:392 peer info: IV_LZO_STUB=1
ovpn-server1[1880]: xx.xx.xx.xx:392 peer info: IV_COMP_STUB=1
ovpn-server1[1880]: xx.xx.xx.xx:392 peer info: IV_COMP_STUBv2=1
ovpn-server1[1880]: xx.xx.xx.xx:392 peer info: IV_GUI_VER=net.openvpn.connect.android_3.2.2-502
ovpn-server1[1880]: xx.xx.xx.xx:392 peer info: IV_SSO=openurl
ovpn-server1[1880]: xx.xx.xx.xx:392 PLUGIN_CALL: POST /usr/lib/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
ovpn-server1[1880]: xx.xx.xx.xx:392 TLS: Username/Password authentication succeeded for username 'test23'
ovpn-server1[1880]: xx.xx.xx.xx:392 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES__GCM_SHA384, 2048 bit RSA
ovpn-server1[1880]: xx.xx.xx.xx:392 [client] Peer Connection Initiated with [AF_INET]xx.xx.xx.xx:392
ovpn-server1[1880]: client/xx.xx.xx.xx:392 MULTI_sva: pool returned IPv4=10.8.0.2, IPv=(Not enabled)
ovpn-server1[1880]: client/xx.xx.xx.xx:392 MULTI: Learn: 10.8.0.2 -> client/xx.xx.xx.xx:392
ovpn-server1[1880]: client/xx.xx.xx.xx:392 MULTI: primary virtual IP for client/xx.xx.xx.xx:392: 10.8.0.2
ovpn-server1[1880]: client/xx.xx.xx.xx:392 PUSH: Received control message: 'PUSH_REQUEST'
ovpn-server1[1880]: client/xx.xx.xx.xx:392 SENT CONTROL [client]: 'PUSH_REPLY,route 10..0.0 5.5.5.0 vpn_gateway 500,dhcp-option DOMAIN MyHome,dhcp-option DNS 10..0.1,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 15,ping-restart 0,ifconfig 10.8.0.2 5.5.5.0,peer-id 0,cipher AES--GCM' (status=1)
ovpn-server1[1880]: client/xx.xx.xx.xx:392 Data Channel: using negotiated cipher 'AES--GCM'
ovpn-server1[1880]: client/xx.xx.xx.xx:392 Outgoing Data Channel: Cipher 'AES--GCM' initialized with bit key
ovpn-server1[1880]: client/xx.xx.xx.xx:392 Incoming Data Channel: Cipher 'AES--GCM' initialized with bit key
ovpn-server1[1880]: client/xx.xx.xx.xx:392 Connection reset, restarting [-1]
ovpn-server1[1880]: client/xx.xx.xx.xx:392 SIGUSR1[soft,connection-reset] received, client-instance restarting
ovpn-server2[194]: TCP connection established with [AF_INET]xx.xx.xx.xx:4013

 

[RMerlin]

@RMerlin, I am curious, I heard wireguard code is simpler and way smaller than OpenVPN. Then why choose to rewrite OpenVPN? Because you are familiar with the technology?

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.

 

[Sonyrolfy]

Cant be be sure if this is known, but when a vpn client is set to exclusive and enabling SSH to make some changes. The DNS from the clients flips to (In my case DOT servers) Checked with Ipleak.

No scripts

 

[RMerlin]

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.

 

[RMerlin]

Cant be be sure if this is known, but when a vpn client is set to exclusive and enabling SSH to make some changes. The DNS from the clients flips to (In my case DOT servers) Checked with Ipleak.

View attachment 24897No scripts

Exclusive mode was being broken whenever you did anything causing a firewall restart. This is an old issue that existed since day one, fixed in alpha 3.

 

[Sonyrolfy]

Exclusive mode was being broken whenever you did anything causing a firewall restart. This is an old issue that existed since day one, fixed in alpha 3.

Ah oke Thanks, Alpha 3, my bad I will download this one right away

 

[Sonyrolfy]

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.