What's new

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

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

Status
Not open for further replies.
If you replace ovpn-up, then you become responsible for doing everything it was previously doing.


And also updating resolv.conf/dnsmasq's config:

Thanks for sending the links. You read my mind!

I just started exploring if I can also use the openvpn-event script to do my mods since the same parms are being passed. I currently use the "route-up" and "route-pre-down" scripts (e.g. vpnclient1-route-up. I just had time to bounce the vpnclient to see where in the process they are called. One thing I noticed is that the openvpn-event script used to report "-up" (e.g. vpnclient-up) and "-down" being passed in the process. My openvpn-event script would output to system log when these were passed but not script was found to run. But I don't see those two being passed any longer. Did anything change for script type?

#!/bin/sh
###########################################################################################################
# Script: openvpn-event
# VERSION=1.0.2
# Author: John9527, Martineau, Xentrk
# Last Updated Date: 27-June-2020
#
# Description:
# Original Script by John9527:
# https://www.snbforums.com/threads/f...lts-releases-v39e3.18914/page-238#post-294825
#
# Updated Script by John9527
# https://www.snbforums.com/threads/s...pn-port-5060-blocked.41585/page-2#post-352772
#
# Implemented additional patches suggested by Martineau
# https://www.snbforums.com/threads/s...pn-port-5060-blocked.41585/page-2#post-352834
# https://www.snbforums.com/threads/x...swrt-merlin-firmware.57793/page-7#post-520433
#
# Modified by Xentrk for x3mRouting project
############################################################################################################
# shellcheck disable=SC2154

PROJECT_REPO="/jffs/scripts/x3mRouting"
scr_name="$(basename "$0")[$$]"

#Determine Caller
case "$1" in
"tun11")
vpn_name="client1"
;;
"tun12")
vpn_name="client2"
;;
"tun13")
vpn_name="client3"
;;
"tun14")
vpn_name="client4"
;;
"tun15")
vpn_name="client5"
;;
"tun21")
vpn_name="server1"
;;
"tun22")
vpn_name="server2"
;;
*)
vpn_name=""
;;
esac

# Call appropriate script based on script_type
vpn_script_name="vpn$vpn_name-$script_type"
vpn_script_log="/tmp/vpn${vpn_name}_state"

# Check script state
vpn_script_state=$(cat $vpn_script_log 2>/dev/null)
if [ "$vpn_script_name" = "$vpn_script_state" ]; then
echo "VPN script $vpn_script_name already run" | logger -t "$scr_name"
exit 0
fi

# Execute and log script state
if [ -f "$PROJECT_REPO/$vpn_script_name" ]; then
echo "$vpn_script_name" >"$vpn_script_log"
logger -t "$scr_name" "Running $PROJECT_REPO/$vpn_script_name $*"
sh "$PROJECT_REPO/$vpn_script_name" "$*"
else
logger -t "$scr_name" "No scripts found to run for openvpn-event: $vpn_script_name"
echo "${vpn_script_name}-NOSCRIPT" >"$vpn_script_log" # (or nvram set vpn_script_state="${vpn_script_name}-NOSCRIPT"")
exit 0
fi

exit 0
 
Testing fresh Alpha 4
When setting DNS to exclusive ( no policy routing ) i will get 2 DNS servers on Ipleak. 1 VPNDNS and 1 DOTDNS.
When setting DNS to exclusive (with policy routing 192.168.1.0/24) i will get 1 DNS server. 1 DNS from CF not from my VPN DNS.
See logs: https://filebin.net/39ywqyky0w3a5kjh

Your VPN server pushes a private DNS IP, which means we don't know what's the PUBLIC resolver they use on their own end. Could very well be CF, could be multiple servers.

You also seem to be using DNS over TLS, which may override things there.

Code:
Jul 31 18:16:11 dnsmasq[5461]: using nameserver 127.0.1.1#53
 
Last edited:
I just started exploring if I can also use the openvpn-event script to do my mods since the same parms are being passed.

That would be another option, as openvpn-event will always be called on at the end.

One thing I noticed is that the openvpn-event script used to report "-up" (e.g. vpnclient-up) and "-down" being passed in the process. My openvpn-event script would output to system log when these were passed but not script was found to run. But I don't see those two being passed any longer. Did anything change for script type?

Nothing changed that I'm aware of. That script was called with the same argument received from the calling script (i.e. it was passed $* as argument). The syslog content might be different because the calling program/script was changed, but it shouldn't affect parameters.

I recommend relying on environment variables instead of the passed arguments, as this will be far more comprehensive.
 
Happy to confirm that alpha4 works fine for me.
 
31 00:24:37 ovpn-server1[5965]: event_wait : Interrupted system call (code=4)

This either indicate that starting failed (in which case I'll need to see the error messages before that), or that you actively turned it off (once again, previous events in the log would confirm whether a stop_vpnserver command was sent, or something else terminated it).

Set OpenVPN log verbosity to level 5, then post the log content including what's before that event.
 
Last edited:
Looks like Asus made some changes to the jffs partition size on the RT-AC86U with the last merged GPL, truncating it by 1 MB for use for crashlog storage. So if you had a nearly full partition, that would explain why its content might get partly lost after an upgrade.
 
Looks like Asus made some changes to the jffs partition size on the RT-AC86U with the last merged GPL, truncating it by 1 MB for use for crashlog storage. So if you had a nearly full partition, that would explain why its content might get partly lost after an upgrade.

It seems to me to mess with jffs partition regardless of whether full or not. In my case jffs has never been more than 15.47 / 47.00 MB on my RT-AC86U ... but bits get lost on upgrade all the same.
 
Your VPN server pushes a private DNS IP, which means we don't know what's the PUBLIC resolver they use on their own end. Could very well be CF, could be multiple servers.

You also seem to be using DNS over TLS, which may override things there.

Code:
Jul 31 18:16:11 dnsmasq[5461]: using nameserver 127.0.1.1#53
Thanks for the heads up. Even when i disable DOT on WAN ( to avoid CF) and set exclusive mode on the client page. The Policy RulesPolicy Rules (strict) with 192.168.1.0/24 will now push the ISP DNS. The only setting with the DNS from the VPN that works, is when i set Force Internet traffic through tunnel to YES.

Update: Got it working with a custom dns on DNS filter, but i dont think thats the way to go when exclusive is on ? But it helps for some clients who needs exclusive dns.
 
Last edited:
It seems to me to mess with jffs partition regardless of whether full or not. In my case jffs has never been more than 15.47 / 47.00 MB on my RT-AC86U ... but bits get lost on upgrade all the same.
Same with mine
 
Did a dirty update from 384.18 to 384.19_alpha4. Had to reset my openvpn server to default because of certificate issues. After reconfiguring the openvpn server again and updating the clients with the new configuration file, everything seems to work again. (RT-AC86U)
 
Last edited:
Not sure if I can bring this up here, but it seems like a legitimate concern that might be addressed with this Alpha, or see if anyone else has this issue that perhaps this OpenVPN rewrite helps resolve?

I've got 5 identical OpenVPN profiles configured to point to different servers around the country using ExpressVPN... I'm using Martineau's VPN_Failover.sh script to move from one to another when the connection drops.

I tend to have frequent intermittent issues with my ISP, so when my physical connection drops, the script will move from one VPN profile to the next until the internet comes back up and reconnects the VPN, as advertised.

Problem: So here's the issue... in certain cases, after the internet comes up, the VPN will reconnect, but for some reason, not successfully in some form or fashion. In these cases, none of my clients can browse the internet through the VPN. From all indications, the Merlin UI and VPN_Failover script don't see anything as being wrong. However, I can see that the TCP/UDP Read/Write bytes are extremely low and only trickling in... The TUN/TAP Read/Write bytes are higher, but also coming in at a very low rate. The fix: I have to manually stop and restart the VPN connection through the UI, and then it works as normal.

I just don't know enough to troubleshoot why this happens... it's almost like either DNS isn't working, or perhaps the gateway IP isn't being relayed to the clients when the connection comes back up... not sure. Anyways, if you've seen this, or think the Alpha may help address this reconnection stability issue, please let me know. Thanks in advance!
 
On the OpenVPN Server configuration page I still get this message after a while. Everything still works only unable to export configuration files until I reboot the router or just hit the apply button again.
1596300667243.png

It is the same issue as described in:
https://www.snbforums.com/threads/server-cert-doesnt-match-exported-ovpn-cert.61998/
 
On the OpenVPN Server configuration page I still get this message after a while. Everything still works only unable to export configuration files until I reboot the router or just hit the apply button again.
View attachment 25045
It is the same issue as described in:
https://www.snbforums.com/threads/server-cert-doesnt-match-exported-ovpn-cert.61998/

This has been an issue some individuals have experienced. Currently doesn't seem to be an issue with 384.19alpha V3 on my AC86.

When I was having the issue I just saved a copy of the the exported OVPN file on my computer and if the wheel was spinning and I needed a copy to send to a device I just sent it from my PC instead of trying to do it from the router. As you said even with the spinning wheel the server works fine.
 
It seems to me to mess with jffs partition regardless of whether full or not. In my case jffs has never been more than 15.47 / 47.00 MB on my RT-AC86U ... but bits get lost on upgrade all the same.

Could be due to wear leveling, files ending up written near the end of the partition, so they get lost in the resize. Just a poor technical decision on Asus's part.
 
The router model is RT-AC86U. Version is 384.19_alpha4-ge04cf51267. Some times I get the errors below when local devices still are connected but that will recover itself and I don't notice interuptions. Also I suspect it appears if devices switch from AP.

Code:
Aug  1 19:21:55 ovpn-server1[21368]: client/192.168.2.205:38370 TLS ERROR: received control packet with stale session-id=45527e7e d097caf8
Aug  1 19:21:56 ovpn-server1[21368]: client/192.168.2.205:38370 TLS ERROR: received control packet with stale session-id=45527e7e d097caf8
Aug  1 19:22:11 ovpn-server1[21368]: client/192.168.2.205:38370 TLS ERROR: received control packet with stale session-id=45527e7e d097caf8
Aug  1 19:22:12 ovpn-server1[21368]: client/192.168.2.205:38370 TLS ERROR: received control packet with stale session-id=45527e7e d097caf8
Aug  1 19:22:13 ovpn-server1[21368]: client/192.168.2.205:38370 TLS ERROR: received control packet with stale session-id=45527e7e d097caf8
Aug  1 19:22:17 ovpn-server1[21368]: client/192.168.2.205:38370 TLS ERROR: received control packet with stale session-id=45527e7e d097caf8
Aug  1 19:22:24 ovpn-server1[21368]: client/192.168.2.205:38370 TLS ERROR: received control packet with stale session-id=45527e7e d097caf8
Aug  1 19:22:40 ovpn-server1[21368]: client/192.168.2.205:38370 TLS ERROR: received control packet with stale session-id=45527e7e d097caf8
Aug  1 19:22:56 ovpn-server1[21368]: client/192.168.2.205:38370 TLS ERROR: received control packet with stale session-id=45527e7e d097caf8
Aug  1 19:23:10 ovpn-server1[21368]: client/192.168.2.205:38370 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Aug  1 19:23:10 ovpn-server1[21368]: client/192.168.2.205:38370 TLS Error: TLS handshake failed

Configuration:
1596305347450.png


1596305529534.png


Initilization log for the VPN server:

Code:
Aug  1 20:20:33 rc_service: httpds 6959:notify_rc restart_chpass;restart_vpnserver1
Aug  1 20:20:33 ovpn-server1[21368]: event_wait : Interrupted system call (code=4)
Aug  1 20:20:33 ovpn-server1[21368]: Closing TUN/TAP interface
Aug  1 20:20:33 ovpn-server1[21368]: /sbin/ifconfig tun21 0.0.0.0
Aug  1 20:20:33 lldpd[1398]: removal request for address of <REMOVED IP PART>.1%38, but no knowledge of it
Aug  1 20:20:33 ovpn-server1[21368]: ovpn-down 1 server tun21 1500 1621 <REMOVED IP PART>.1 255.255.255.0 init
Aug  1 20:20:33 ovpn-server1[21368]: PLUGIN_CLOSE: /usr/lib/openvpn-plugin-auth-pam.so
Aug  1 20:20:33 ovpn-server1[21368]: SIGTERM[hard,] received, process exiting
Aug  1 20:20:33 ovpn-server1[16308]: OpenVPN 2.4.9 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 30 2020
Aug  1 20:20:33 ovpn-server1[16308]: library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.08
Aug  1 20:20:33 ovpn-server1[16309]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Aug  1 20:20:33 ovpn-server1[16309]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug  1 20:20:33 ovpn-server1[16309]: PLUGIN_INIT: POST /usr/lib/openvpn-plugin-auth-pam.so '[/usr/lib/openvpn-plugin-auth-pam.so] [openvpn]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY
Aug  1 20:20:33 ovpn-server1[16309]: Diffie-Hellman initialized with 2048 bit key
Aug  1 20:20:33 ovpn-server1[16309]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Aug  1 20:20:33 ovpn-server1[16309]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug  1 20:20:33 ovpn-server1[16309]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Aug  1 20:20:33 ovpn-server1[16309]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Aug  1 20:20:33 ovpn-server1[16309]: TUN/TAP device tun21 opened
Aug  1 20:20:33 ovpn-server1[16309]: TUN/TAP TX queue length set to 1000
Aug  1 20:20:33 ovpn-server1[16309]: /sbin/ifconfig tun21 <REMOVED IP PART>.1 netmask 255.255.255.0 mtu 1500 broadcast <REMOVED IP PART>.255
Aug  1 20:20:33 lldpd[1398]: removal request for address of <REMOVED IP PART>.1%40, but no knowledge of it
Aug  1 20:20:33 lldpd[1398]: removal request for address of <REMOVED IP PART>.1%40, but no knowledge of it
Aug  1 20:20:33 ovpn-server1[16309]: ovpn-up 1 server tun21 1500 1621 <REMOVED IP PART>.1 255.255.255.0 init
Aug  1 20:20:33 ovpn-server1[16309]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Aug  1 20:20:33 ovpn-server1[16309]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Aug  1 20:20:33 ovpn-server1[16309]: UDPv4 link local (bound): [AF_INET][undef]:<REMOVED PORT>
Aug  1 20:20:33 ovpn-server1[16309]: UDPv4 link remote: [AF_UNSPEC]
Aug  1 20:20:33 ovpn-server1[16309]: MULTI: multi_init called, r=256 v=256
Aug  1 20:20:33 ovpn-server1[16309]: IFCONFIG POOL: base=<REMOVED IP PART>.2 size=252, ipv6=0
Aug  1 20:20:33 ovpn-server1[16309]: Initialization Sequence Completed
 
Last edited:
This has been an issue some individuals have experienced. Currently doesn't seem to be an issue with 384.19alpha V3 on my AC86.

When I was having the issue I just saved a copy of the the exported OVPN file on my computer and if the wheel was spinning and I needed a copy to send to a device I just sent it from my PC instead of trying to do it from the router. As you said even with the spinning wheel the server works fine.

I am doing the same. I'm only posting it because this thread is about rework in OpenVPN code. Not because things are not working in matter of connectivity.
 
The router model is RT-AC86U. Version is 384.19_alpha4-ge04cf51267. Some times I get the errors below when local devices still are connected but that will recover itself and I don't notice interuptions. Also I suspect it appears if devices switch from AP.

This is specific to OpenVPN and not the firmware itself. Something is preventing your TLS re-negotiation from occuring properly I suppose, or something like that. Try a Google search for that error message, I saw quite a few discussions about it. One person resolved it by switching from UDP to TCP, for instance.
 
Thanks, I thought the error wasn't related to the message in the GUI.
 
Thanks, I thought the error wasn't related to the message in the GUI.

Chances are the server gets stuck right in the middle of its restart/renegotiate phase, which is why it never reaches a fully "running" state, leaving you with that message.
 
Status
Not open for further replies.

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