Beta VPN Director testing

[AntonK]

This has to be a joke. Garbage in garbage out.

?

 

[skeal]

DFTT

 

[Nick_J]

Hi Merlin as you've mentioned in http://www.snbforums.com/threads/vp...r-client-versus-centralized.72907/post-694570

Are we still on that schedule ?

Thank you.

 

[RMerlin]

Hi Merlin as you've mentioned in http://www.snbforums.com/threads/vp...r-client-versus-centralized.72907/post-694570

Are we still on that schedule ?

Thank you.

Yes. This current thread is the thread I was referring to in that post.

 

[RMerlin]

What I remeber is this variable don't get set:
UDP link remote: [AF_INET]217.64.148.60:1194

AF_INET is not a variable, it's just the protocol type used internally.

I just created an openvpn-event script that dumped the env vars to a file, and it was working fine for me, the OpenVPN env vars were defined.

The problem is most likely with your script itself.

 

[octopus]

AF_INET is not a variable, it's just the protocol type used internally.

I just created an openvpn-event script that dumped the env vars to a file, and it was working fine for me, the OpenVPN env vars were defined.

The problem is most likely with your script itself.

Yes, I have tested and I get variables and openvpn-event get triggered but that not calling my script.
I have them under /jffs/script/myscript.sh I don't know why at the moment.

 

[RMerlin]

Yes, I have tested and I get variables and openvpn-event get triggered but that not calling my script.
I have them under /jffs/script/myscript.sh I don't know why at the moment.

This looks more like an issue in how you have your scripts setup than an issue with VPN Director. How do you have your scripts configured? What do your scripts contain? We'll need more info about your specific setup.

 

[netware5]

A (maybe) stupid question: VPN Director has a business only with OpenVPN client, isn't it? Or also messes with OpenVPN Server?

 

[RMerlin]

A (maybe) stupid question: VPN Director has a business only with OpenVPN client, isn't it? Or also messes with OpenVPN Server?

Only OpenVPN clients.

 

[RMerlin]

I uploaded refreshed builds, main change is that exclusive DNS configurations are now applied at the same time as routing rules, so no need to restart the VPN clients.

d516f7b904 webui: renamed "Policy Rules" for "VPN Director" on OpenVPN client dropdown; updated help popup
0a55e79998 libovpn: handle DNS exclusive iptable rules separately, and refresh them on vpnrouting events

 

[octopus]

This looks more like an issue in how you have your scripts setup than an issue with VPN Director. How do you have your scripts configured? What do your scripts contain? We'll need more info about your specific setup.

Thanks.
That is really strange, I publish my openvpn-event script maybe someone have any hint. I don't see it at the moment.

#!/bin/sh

/usr/bin/logger -st "Started openvpn-event script "$@""
/usr/bin/logger -st "environment" "${script_type}" "${common_name}" "${trusted_ip}" "${trusted_port}"


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 "/jffs/scripts/$vpn_script_name" ]]; then
echo " Script executing.. for VPN event: "$vpn_script_name | logger -t $scr_name
echo "$vpn_script_name" > $vpn_script_log
logger -t "$scr_name" "Running $vpn_script_name $*"
/bin/sh /jffs/scripts/$vpn_script_name $* # I don't use this, but I have them in /jffs/scripts


/bin/sh /jffs/scripts/vpnc.sh & # This trigger my script and use environment variables from clients.

else

logger -t "$scr_name" "No scripts found to run for openvpn-event: $vpn_script_name"
echo " Script not defined for VPN event: "$vpn_script_name | logger -t $scr_name
echo "${vpn_script_name}-NOSCRIPT" > $vpn_script_log

exit 0
fi

exit 0

seems openvpn-event is working and the error is in my script, but I can't find why.

/jffs/scripts/vpnc.sh: line 139: syntax error: unexpected "("

+ basename /jffs/scripts/openvpn-event
+ scr_name=openvpn-event[25040]
+ vpn_name=client3
+ vpn_script_name=vpnclient3-route-up
+ vpn_script_log=/tmp/vpnclient3_state
+ cat /tmp/vpnclient3_state
+ vpn_script_state=vpnclient3-up
+ [ vpnclient3-route-up = vpnclient3-up ]
+ [ -f /jffs/scripts/vpnclient3-route-up ]
+ logger -t openvpn-event[25040]
+ echo Script executing.. for VPN event: vpnclient3-route-up
+ echo vpnclient3-route-up
+ logger -t openvpn-event[25040] Running vpnclient3-route-up tun13 1500 1538 10.129.3.251
+ /bin/sh /jffs/scripts/vpnclient3-route-up tun13 1500 1538 10.129.3.251
+ exit 0

Do you have any suggestion?
@Martineau
Thanks !

 

[AveAdvenae]

Build RT-AC86U_386.3_alpha2-gd516f7b904

Looking good now, although I still can't get my head around some of the rule logic.

If I add

The Manchester device will be routed through OVPN5.

However, if I add

Then both Manchester and Huawei will be routed through OVPN1.

 

[Intrepid2007]

I just updated my AX88U to the latest firmware version and it looks great (and an improvement)! It appears that in my use-case no functionality was lost. Until now no issues seen with this firmware version.

The routing rules look more intuitive and it's more understandable, great work !
And split-tunneling is easier and more flexible to configure, everything is visible on 1 page..

OpenVPN works great as it is, but would it not be fantastic if in the feature Asus decides to implement Wireguard client support as well...

Mixing OpenVPN and Wireguard clients in Merlin firmware would be fantastic but I am not sure if that is ever going to happen.

 

[Sonyrolfy]

The way i test it with trough the whole lan in vpn startting with 5 because of the prio's, with some exceptions of devices needed to go trough another vpn lest say 3. It is possible but: The order in when i activate vpn 3 as last, the this will set the rules for 3. DNS exclusive. This will overrule the first one eg 192.168.1.0/24 having both on exclusive dns, all working fine. I didnt check when re-keying is performed. This could be a problem? Besides hitting the apply buttons on vpn 3 after apllaying 5 first, the director sould take care of it but troughs back DNS from 5 to vpn 3. With my limited knowledge i think this is not how it was supposed to work according to Merlin or the vpn clients are struggling with who comes first and set the rule?

 

[RMerlin]

The Manchester device will be routed through OVPN5.

Either you have the wrong IP, or you haven't set both clients to Policy Rules. Check the rule list at the kernel level:

ip rule show

Rules get applied in the order they are shown. It's impossible for an OVPN5 rule to be run before an OVPN1 rule because the prio is derived directly from the client unit number (10010 + (200 * unit)). So if it doesn't work, either the rule is not there, or your IP is incorrect.

With my limited knowledge i think this is not how it was supposed to work according to Merlin or the vpn clients are struggling with who comes first and set the rule?

Routing and DNS are two totally separate things. Routing will always obey the order I established in my previous posts. However DNS is handled separately (it's done at the firewall level rather than the routing level), and at this time I'm unable to give them any predictable priority, short of erasing and re-configuring the firewall on every rule changes, which would be very disruptive to the whole network. I haven't found any solution to this problem yet.

 

[kernol]

Following my earlier posts - I reverted to 386.2_6 with factory reset before restoring JFFS and Settings from 386.2_6 backups made before applying first 386.3 "Beta".

Tried NordVPN Client settings in that firmware and also could not get it to work with simple "Yes" to Redirect through tunnel.
It would only work if I selected "Policy Rules" and created an appropriate rule to redirect - in this case 192.168.50.0/24 to tunnel.

Applied latest 386.3 beta [version 3] and confirm all translated across to VPN Director perfectly - and works fine as long as Policy Rules selected. Once again - if I change to the "new" "Yes (all)" redirect option - it still does not work [partial connect since it gets new Local ip address - but claims Public: Unknown] and no internet connectivity through the tunnel.

 

[RMerlin]

if I change to the "new" "Yes (all)" redirect option - it still does not work [partial connect since it gets new Local ip address - but claims Public: Unknown

Thanks, I can reproduce the issue with my own setup I'll have to investigate. The odd thing is if I run a traceroute from the router itself, then it does properly go through the tunnel

 

[kernol]

Thanks, I can reproduce the issue with my own setup I'll have to investigate. The odd thing is if I run a traceroute from the router itself, then it does properly go through the tunnel

Must be something which crept in with 386 code ... I can clearly remember using Redirect = "Yes" in 384 code for a simple "protect all via VPN" trial period.

Sadly throughput on all the VPN's I have tested here down South mess badly with speeds and buffer-bloat so are largely unusable. NordVPN is marginally better than VPNUnlimited for use as a local VPN - but VPNUnlimited is way better for UK BBC.

One question - Will your new VPN Director remain compatible with x3mRouting from @Xentrk ?? Routing by intended internet destination rather than by selected local client ip is a mighty appealing feature of his offering [which as a non-coder I have yet to Master but have every intention of doing so] .

 

[RMerlin]

Must be something which crept in with 386 code ... I can clearly remember using Redirect = "Yes" in 384 code for a simple "protect all via VPN" trial period.

Unless there are two different separate issues here, I see one issue that's related to DNS handling whenever you have at least one client with DNS set to "Exclusive" mode, causing any other clients with redirection set to "Yes" to end up not having any DNS To use. That will require a major redesign of the DNS handling, I suspect that some of the very old legacy DNS handling is not compatible with the slightly newer exclusive mode that was added latter on. And since probably nobody ever used redirection set to "Yes", this old bug went unnoticed until now.

Try setting up all of your VPN clients so none of them have their DNS set to "Exclusive" mode while you have one set to "Redirect: Yes". See if Internet traffic starts working once again. At the very least it should fix the router's inability to determine the public IP, as the issue is that ministun is unable to resolve the IP address of any STUN server to retrieve that IP.

Sadly throughput on all the VPN's I have tested here down South mess badly with speeds

Seems fine here, I just got 220 Mbps through a US-based NordVPN server - that was most likely capped by my router's CPU rather than the server itself.

nd buffer-bloat so are largely unusable.

Don't expect bufferbloat tests to give any reliable results here. VPN add encapsulation and encryption, so they aren't great for that. UDP should do quite better than TCP in this particular scenario (I've heard some reports from colleagues how VoIP requires OpenVPN to run in UDP mode to be usable through a tunnel).

Will your new VPN Director remain compatible with x3mRouting from @Xentrk

I have no idea how his script works, so I cannot answer that. But VPN Director (and the previous Policy Routing) both allow to route traffic per destination, not just per source. The Remote IP field is right there on the VPN Director UI.

 

[kernol]

MANY thanks for your comprehensive response - unexpected but fully appreciated .

None of my VPN Client settings have ever used "Exclusive" for DNS setting.
I use "Strict" on the limited by ip address clients which I wish to tunnel through to UK and "Relaxed" with a catch-all for the rest to Local VPN.

With those DNS settings [NB I am using Unbound as my router's configured DNS - may give you a clue?] - the DNS leak test on all VPN's show VPN's Public IP as site to be tested - and then confirm my router's Public IP for the DNS record with no leaks.

However - changing to VPN Client DNS setting to "Disabled" / "Relaxed" / "Strict" or even "Exclusive" when used with Redirect "Yes (All)" still partially fails [gets correct VPN provider issued local ip but fails to get VPN providers Public IP - "Unknown"]!

What is weird is that on the affected local client [partial tunnel] - NSLookup and Tracert still work fine and use Unbound DNS - so DNS itself is not broken - it is just the partial tunnel that can't see it?

Simple solution ... if nobody uses Redirect = "(Yes All)" anymore - just dump it as an option .