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.
The 3rd option of using the x3mRouting script and specifying the interfaces is still compatible with Alpha 4 It is option 1 - LAN Routing and option 2- modified OpenVPN Screen that won't work with Alpha 4 at the moment due to integration with updown-client.sh..
@Xentrk Any special recommendations from gng from RMerlin Alpha2 and using your current script only using option 3? Everything is working as expected at this time. But I would like to try alpha 4 for the DoT update.
 
Done restoring manually jffs and all good.

Something weird happens when going to this alphas.
Yes, jffs got corrupted on my AC86U on alpha 3 too. I reformatted it 3 times (aka rebooted the router with that option selected - leaving some 10-15 minutes in-between.) Then manually copied it all back in and it seems stable for the last few days.

As for the alphas 3&4 (after the jffs episode) the following OVPN related continue to work well (as in the previous stable F/W) with script driven selective routing (from @Xentrk )
- 3 vpn clients to a vpn provider
-1 vpn client to a remote AX56U (on Asus F/W)
- 1 vpn server (1024 + default settings exported in a previous F/W iteration)
All scripts (diversion, unbound, selective routing, cake-qos, scribe) running well.
 
@Xentrk Any special recommendations from gng from RMerlin Alpha2 and using your current script only using option 3? Everything is working as expected at this time. But I would like to try alpha 4 for the DoT update.
You can use Alpha 4 test build with the 384.19 Test build of x3mRouting if using option 3. Option 3 just uses the x3mRouting.sh and openvpn-event scripts which are unaffected by this update. This is where you specify the source and destination interface e.g. x3mRouting 1 0 NETFLIX asnum=AS2906. Using the modified Screen and LAN routing options won't work with Alpha 4 at this time though until I make the required changes.
 
Last edited:
<snip>

If you were previously overwriting updown-client.sh, this will no longer work. Please use a postconf script to modify the client.ovpn config file instead. Locate lines that start with "up " and "down " (with the trailing space), and replace the line with "up your-own-handler.sh" and "down your-own-handler.sh". route-up used by vpnrouting.sh is not changed, at least for the time being. I haven't decided to rewrite that script just yet, so there's a good chance it will remain there for the near future.

I am writing a proof of concept to understand the integration with new handler. It appears that I can't install a full path for my handler file. As a result, I have to perform a copy of the file to the /etc/openvpn/client1/ directory location on the last line:

openvpnclient1.postconf
Code:
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
pc_replace "up 'ovpn-up 1 client'" "up 38419test.sh" $CONFIG
cp /jffs/scripts/38419test.sh /etc/openvpn/client1/38419test.sh

38419test.sh
Code:
#!/bin/sh
logger -st "($(basename "$0"))" "$$ 01 TEST MSG"

The above message gets logged which indicates it ran. In the system log, I can see 38419test.sh being called with the usual vpn client parms. But the dns.sh script for the exclusive rules does not get created. It appears that an exit occurs after the 38419test.sh script is run. The RPDB rules get created okay though.

System Log snip
Code:
<snip>Jul 31 09:56:39 ovpn-client1[2558]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jul 31 09:56:39 ovpn-client1[2558]: TUN/TAP device tun11 opened
Jul 31 09:56:39 ovpn-client1[2558]: TUN/TAP TX queue length set to 1000
Jul 31 09:56:39 ovpn-client1[2558]: /sbin/ifconfig tun11 10.24.0.38 pointopoint 10.24.0.37 mtu 1500
Jul 31 09:56:39 ovpn-client1[2558]: 38419test.sh tun11 1500 1584 10.24.0.38 10.24.0.37 init
Jul 31 09:56:39 (38419test.sh): 2818 01 TEST MSG
Jul 31 09:56:41 openvpn-routing: Configuring policy rules for client 1
Jul 31 09:56:42 custom_script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1584 10.24.0.38 10.24.0.37)
Jul 31 09:56:42 openvpn-event[3041]: Running /jffs/scripts/x3mRouting/vpnclient1-route-up tun11 1500 1584 10.24.0.38 10.24.0.37
Jul 31 09:56:42 ovpn-client1[2558]: Initialization Sequence Completed
 
I am writing a proof of concept to understand the integration with new handler. It appears that I can't install a full path for my handler file. As a result, I have to perform a copy of the file to the /etc/openvpn/client1/ directory location on the last line:

Odd, examples on the OpenVPN man page shows full paths for Windows. Make sure you enclose the handler in single quotes.

As of OpenVPN 2.3 it is now a strict requirement to have full path to the script interpreter when running non-executables files. This is not needed for executable files, such as .exe, .com, .bat or .cmd files. For example, if you have a Visual Basic script, you must use this syntax now:


--up 'C:\\Windows\\System32\\wscript.exe C:\\Program\ Files\\OpenVPN\\config\\my-up-script.vbs'

Note that it's possible that the handler needs a valid return value.
 
Odd, examples on the OpenVPN man page shows full paths for Windows. Make sure you enclose the handler in single quotes.

Note that it's possible that the handler needs a valid return value.
I tried that earlier as well. Following is the up directive with the single quotes

config.ovpnc
Code:
daemon ovpn-client1
client
dev tun11
txqueuelen 1000
proto udp
remote xx.xx.xx.xx 995
connect-retry-max 15
nobind
persist-key
persist-tun
ncp-ciphers AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
cipher AES-256-CBC
auth SHA1
route-noexec
ca ca.crt
auth-user-pass auth
up '/jffs/scripts/38419test.sh'
down 'ovpn-down 1 client'
script-security 2
route-delay 2
route-up vpnrouting.sh
route-pre-down vpnrouting.sh
verb 3
status-version 2
status status 5

# Custom Configuration
remote-cert-tls server
setenv CLIENT_CERT 0
resolv-retry infinite
tun-mtu-extra 32
fast-io

System Log Msgs
Code:
Jul 31 10:26:40 ovpn-client1[8565]: /sbin/ifconfig tun11 10.24.0.34 pointopoint 10.24.0.33 mtu 1500
Jul 31 10:26:40 ovpn-client1[8565]: /jffs/scripts/38419test.sh tun11 1500 1584 10.24.0.34 10.24.0.33 init
Jul 31 10:26:40 ovpn-client1[8565]: WARNING: Failed running command (--up/--down): could not execute external program
Jul 31 10:26:40 ovpn-client1[8565]: Exiting due to fatal error

I also tried adding "return $@" at the end of the script and get the warning msg about the up/down command.
 
You can use Alpha 4 test build with the 384.19 Test build of x3mRouting if using option 3. Option 3 just uses the x3mRouting.sh and openvpn-event scripts which are unaffected by this update. This is where you specify the source and destination interface e.g. x3mRouting 1 0 NETFLIX asnum=AS2906. Using the modified Screen and LAN routing options won't work with Alpha 4 at this time though until I make the required changes.
So there's no need to use your special alpha repo if we only use option 3?
 
I tried that earlier as well. Following is the up directive with the single quotes

config.ovpnc
Code:
daemon ovpn-client1
client
dev tun11
txqueuelen 1000
proto udp
remote xx.xx.xx.xx 995
connect-retry-max 15
nobind
persist-key
persist-tun
ncp-ciphers AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
cipher AES-256-CBC
auth SHA1
route-noexec
ca ca.crt
auth-user-pass auth
up '/jffs/scripts/38419test.sh'
down 'ovpn-down 1 client'
script-security 2
route-delay 2
route-up vpnrouting.sh
route-pre-down vpnrouting.sh
verb 3
status-version 2
status status 5

# Custom Configuration
remote-cert-tls server
setenv CLIENT_CERT 0
resolv-retry infinite
tun-mtu-extra 32
fast-io

System Log Msgs
Code:
Jul 31 10:26:40 ovpn-client1[8565]: /sbin/ifconfig tun11 10.24.0.34 pointopoint 10.24.0.33 mtu 1500
Jul 31 10:26:40 ovpn-client1[8565]: /jffs/scripts/38419test.sh tun11 1500 1584 10.24.0.34 10.24.0.33 init
Jul 31 10:26:40 ovpn-client1[8565]: WARNING: Failed running command (--up/--down): could not execute external program
Jul 31 10:26:40 ovpn-client1[8565]: Exiting due to fatal error

I also tried adding "return $@" at the end of the script and get the warning msg about the up/down command.
Try to remove "route-noexec" and test again.
 
Something odd is happening with my VPN server (after install alpha 4)
On status page, it shows as disconnected and on VPN server page it shows as connected. However it is disconnected.
It disconnects by itself and I don't know why.

The only log I find related to this is that:

Code:
31 00:24:37 ovpn-server1[5965]: event_wait : Interrupted system call (code=4)
Jul 31 00:24:38 ovpn-server1[5965]: Closing TUN/TAP interface
Jul 31 00:24:38 ovpn-server1[5965]: /sbin/ifconfig tun21 0.0.0.0
Jul 31 00:24:38 lldpd[1608]: removal request for address of 10.8.0.1%25, but no knowledge of it
Jul 31 00:24:38 ovpn-server1[5965]: ovpn-down 1 server tun21 1500 1621 10.8.0.1 255.255.255.0 init
Jul 31 00:24:38 openvpn-event[13831]: No scripts found to run for openvpn-event: vpnserver1-down
Jul 31 00:24:38 custom_script: Running openvpn-event
Jul 31 00:24:38 ovpn-server1[5965]: PLUGIN_CLOSE: /usr/lib/openvpn-plugin-auth-pam.so
Jul 31 00:24:38 ovpn-server1[5965]: SIGTERM[hard,] received, process exiting

At midnight I was sleeping so I haven't done anything, it disconnected by itself

Then, after manually turn it on, I can't connect to server anymore, I have to export the ovpn file again
 

Attachments

  • Screenshot_20200731-091546765.png
    Screenshot_20200731-091546765.png
    77.5 KB · Views: 152
RT-AC86U on 384.19_Alpha4 after dirty upgrade form 384.18 running "purrfectly" :).
OpenVPN Server1 - TUN / UDP / TLS ... 100's and no certificate issues;
OpenVPN Client1 and Client2 - TUN / UDP ... DNS - strict ... NAT tunnel-Yes ... Inbound firewall-Block also 100's no cert issues.
All VPN's fully functional as before.

Also all scripts per signature working properly - just needed to force update uiScribe {System Log webui page would not display} and re-install FlexQos {clearly some JFFS stuff lost in the firmware upgrade - no idea why ... definitely not short of JFFS space - but easy to fix ... either reinstall or restore backup of JFFS}.

EDIT: - up for 12 hours without issues ....
 
Try to remove "route-noexec" and test again.
I got further along doing that. I didn't get the route add msgs before. But the DNS rules for Accept DNS Configuration = Exclusive and the dns.sh script doesn't get created.

Code:
Jul 31 16:12:42 ovpn-client1[8496]: 38419test.sh tun11 1500 1584 10.24.0.30 10.24.0.29 init
Jul 31 16:12:42 (38419test.sh): 8545 01 TEST MSG
Jul 31 16:12:44 ovpn-client1[8496]: /sbin/route add -net x.x.x.x.x netmask 255.255.255.255 gw x.x.x.x
Jul 31 16:12:44 ovpn-client1[8496]: /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.24.0.29
Jul 31 16:12:44 ovpn-client1[8496]: /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.24.0.29
Jul 31 16:12:44 ovpn-client1[8496]: /sbin/route add -net 10.24.0.1 netmask 255.255.255.255 gw 10.24.0.29
Jul 31 16:12:44 openvpn-routing: Configuring policy rules for client 1
Jul 31 16:12:44 custom_script: Running /jffs/scripts/openvpn-event (args: tun11 1500 1584 10.24.0.30 10.24.0.29)
Jul 31 16:12:44 openvpn-event[8715]: Running /jffs/scripts/x3mRouting/vpnclient1-route-up tun11 1500 1584 10.24.0.30 10.24.0.29
Jul 31 16:12:45 ovpn-client1[8496]: Initialization Sequence Completed
 
I think you have to ask @RMerlin to help with dns.sh script been created/executed. ;)
 
Last edited:
AC86U on alpha 4 rebooted itself - very low (if any) user initiated activity. No background downloads. The message log is attached. The scripts did not show errors before reboot.
https://filebin.net/mncbucdw7bmuk11u
 
Last edited:
I tried that earlier as well. Following is the up directive with the single quotes

Make sure the script is executable. You could also try specifying the interpretor.

Code:
up '/bin/sh /jffs/scripts/38419test.sh'
 
I got further along doing that. I didn't get the route add msgs before. But the DNS rules for Accept DNS Configuration = Exclusive and the dns.sh script doesn't get created.

If you replace ovpn-up, then you become responsible for doing everything it was previously doing.


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

 
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
 
Hi,

Tried it last night and S2S VPN between two other devices on one VPNserver no issue, VPNserver 2 no issue. Rolled back to previous, and had to the restore as previously suggested! I have a fairly tight customized setup and had no issue.

Only thing I did was set the client side to retry indefinitely in case something went wrong prior.
 
Make sure the script is executable. You could also try specifying the interpretor.

Code:
up '/bin/sh /jffs/scripts/38419test.sh'
That worked!
 
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