Beta VPN Director testing

[octopus]

Just loaded latest new alpha (4th) build. Seems working fine.
Only thing is as I mentioned before that my vpn-pool not working as the log says.
But it seems working anyway, giving new vpn-server after restart. (perhaps is it only a word check against ip nummer)
All used environment variables working fine, all passed.

Error: any valid prefix is expected rather than "pool-1.prd.se.sthlm.ovpn.com".
Error: any valid prefix is expected rather than "pool-2.prd.se.sthlm.ovpn.com".

Is something missing in between " " ??

Jun 24 18:38:21 rc_service: httpd 1261:notify_rc restart_vpnrouting0 <<==
Jun 24 18:38:21 custom_script: Running /jffs/scripts/service-event (args: restart vpnrouting0) <<==
Jun 24 18:38:21 (service-event): 24878 Script not defined for service-event: servicerestart-vpnrouting0 <<==
Jun 24 18:38:21 openvpn-routing: Routing Tun22-route from "10.8.40.3" to "" through ovpnc3
Jun 24 18:38:21 openvpn: Forcing 10.8.40.3 to use DNS server 46.227.67.134
Jun 24 18:38:21 openvpn-routing: Routing DummyIP from "172.16.32.8" to "" through ovpnc2
Jun 24 18:38:21 openvpn-routing: Routing LANtoVPN from "192.168.12.0/24" to "" through ovpnc1
Jun 24 18:38:21 openvpn: Forcing 192.168.12.0/24 to use DNS server 46.227.67.134

Server:
2021-06-24 18:23:12 158.xxx.xx.xxx:34071 [octopus-3] Peer Connection Initiated with [AF_INET]158.xxx.xx.xxx:34071 (via [AF_INET]158.xxx.xxx.45%eth0) <<==

Thank you @RMerlin

 

[Intrepid2007]

Today I tried to add a new rule 'Jumbo #1'...

The idea is that this rule re-routes traffic to this destination IP (a supermarket) from VPN client 4 to VPN client1.

In this example, my PC (with IP 192.168.4.10) is using VPN4. However, this website (www.jumbo.com) is blocking my VPN. So I thought I use use another interface (VPN1 instead of VPN4)...

After adding this rule, my PC with IP 192.168.4.10 cannot resolve names anymore.... When I change the interface to WAN, everything starts to work again.

P.S.: Yesterday I had problems after updating to this firmware and I posted a message about this (the message about Torguard).. Now I realize I had this rule already included... With the previous firmware version, this rule appeared to work just fine.

After having this problem, yesterday I removed all 'non-relevant' rules.. I only kept the rules that handle the routing per subnet.. After doing that, it started to work fine...

So this rule is what is causing problems now (the 'Jumbo' rule with interface OVPN1)

 

[Sonyrolfy]

DNS exclusive works very well for every client now. Even when throw the whole lan in in VPN,. eg 192.169.1.10/24. The other VPN client can be set to exclusive and the client will use the DNS from it. With this i can use different vpn countries. Works perfect.

The (bottleneck) with this setup you can only use exclusive. I wish i could use the router DNS eg DOT dns for a second vpn client setup. I know I already asked and Merlin gave his answer that 2 or more instances cant be used.

Maybe ?...just thinking .... Every vpn client can have extra setting when using Accept DNS Configuration: With DOT DNS or WAN ? so scripts can work, like Diversion /x3mRouting for a second or third, etc client so lookups still are encrypted. Again please bear with me the limited knowledge.

 

[RMerlin]

Only thing is as I mentioned before that my vpn-pool not working as the log says.

This has nothing to do with the firmware. That message doesn't even come from the firmware, it's from whichever third party script you are using. This will have to be addressed by the script's author, after my code has stabilized enough.

Is something missing in between " " ??

No, it just means "any" basically.

In this example, my PC (with IP 192.168.4.10) is using VPN4. However, this website (www.jumbo.com) is blocking my VPN. So I thought I use use another interface (VPN1 instead of VPN4)...

DNS exclusivity cannot work when you have those overlapping rules, especially when one has an explicit remote IP and the other doesn't. DNS resolution occurs before the destination IP is actually known, since the destination of the resolution process is the DNS server, not the final destination. So with that configuration, you end up trying to use VPN4 for DNS resolution, and then you try to use VPN1 for the actual connection, which I doubt is the intention.

 

[octopus]

This has nothing to do with the firmware. That message doesn't even come from the firmware, it's from whichever third party script you are using. This will have to be addressed by the script's author, after my code has stabilized enough.

ok I hear you, That comes from "openvpnclientx.postconf" script.

#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
sed -i "/remote pool-1.prd.se.sthlm.ovpn.com 1194/a remote pool-2.prd.se.sthlm.ovpn.com 1194" $CONFIG

No, it just means "any" basically.

Ok

 

[SomeWhereOverTheRainBow]

Just loaded latest new alpha (4th) build. Seems working fine.
Only thing is as I mentioned before that my vpn-pool not working as the log says.
But it seems working anyway, giving new vpn-server after restart. (perhaps is it only a word check against ip nummer)
All used environment variables working fine, all passed.


Is something missing in between " " ??

Server:
2021-06-24 18:23:12 158.xxx.xx.xxx:34071 [octopus-3] Peer Connection Initiated with [AF_INET]158.xxx.xx.xxx:34071 (via [AF_INET]158.xxx.xxx.45%eth0) <<==

Thank you @RMerlin

looks like your script may not be parsing the rules or routes properly. you may definitely be having some issues with your script.

 

[kernol]

Show me the system log generated while connecting.

I am using Scribe - so have sent you a PM of the openVPN log in PDF.

No traffic goes through the tunnel - and so an inactivity timeout kicks in and the tunnel is closed - however the VPN Director Tab and the VPN Client Tab of webui - claim the connection is still valid 0- even though shown as OFF - see screen grab ...

For what its worth - here is short extract of relevant lines from the System Log ...

Spoiler: System.log

Extract from System Messages:
Jun 25 05:53:59 RT-AX86U-D850 rc_service: httpds 1674:notify_rc restart_vpnrouting0
Jun 25 05:53:59 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart vpnrouting0)
Jun 25 05:53:59 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event-end (args: restart vpnrouting0)
Jun 25 05:55:00 RT-AX86U-D850 (gen_ytadblock.sh): 20733 Number of yt adblocked domains: 108
Jun 25 05:55:12 RT-AX86U-D850 rc_service: httpds 1674:notify_rc start_vpnrouting4
Jun 25 05:55:12 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: start vpnrouting4)
Jun 25 05:55:13 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event-end (args: start vpnrouting4)
Jun 25 05:56:00 RT-AX86U-D850 rc_service: httpds 1674:notify_rc start_vpnclient4
Jun 25 05:56:00 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: start vpnclient4)
Jun 25 05:56:00 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event-end (args: start vpnclient4)
Jun 25 05:56:09 RT-AX86U-D850 custom_script: Running openvpn-event
Jun 25 05:56:56 RT-AX86U-D850 rc_service: httpds 1674:notify_rc restart_vpnclient4
Jun 25 05:56:56 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event (args: restart vpnclient4)
Jun 25 05:56:56 RT-AX86U-D850 custom_script: Running openvpn-event
Jun 25 05:56:56 RT-AX86U-D850 custom_script: Running /jffs/scripts/service-event-end (args: restart vpnclient4)
Jun 25 05:57:05 RT-AX86U-D850 custom_script: Running openvpn-event
Jun 25 05:58:29 RT-AX86U-D850 custom_script: Running openvpn-event

No amount of clicking "Stop Client" on the VPN Director Page - or clicking "refresh" on the VPN Client page with the client showing Service State OFF - will change the displayed status as actually stopped. Clicking "Apply" makes no difference either.
DNS Leak test proves that the tunnel is NOT in fact up at this stage - but the only way to recover correct webui information is for me to re-activate the tunnel using VPN Director Policy Rule - and after connected - to them switch the Client OFF to get correct state displayed.

 

[kernol]

Failed to send you the log by PM - but managed to break NordVPN as well by choosing : -
Accept DNS Configuration = "Exclusive" and
Redirect Internet Traffic = "Yes (all)
with no Policy Rules.

Got a local ip address but a Public of Unknown.
Once again an inactivity timeout closed the tunnel - but in this case it closed properly.

Then, without doing anything other than once again enable that VPN client - it works ??? and remains connected.
Trouble is though - it is still using my unbound as DNS - and not using Nord's DNS ??? - Even though client is set to Exclusive.

NB - when testing I have no other VPN clients enabled and all policy rules Disabled.

EDIT: Even when I go back to Accept DNS = Disabled - DNS leak reports the Public ip issued by NordVPN to my tunnel as the DNS address [which means my unbound is the DNS]. Strange because before it would report my ISP supplied public ip address as my DNS ??

Anyway - this VPN stuff is well beyond my pay grade - so best I shuffle back to 386.2_6 and cut more teeth on x3mRouting which seems to me to be a very comprehensive VPN routing option with a bunch of boiler plate examples to play with .

 

[octopus]

looks like your script may not be parsing the rules or routes properly. you may definitely be having some issues with your script.

Thanks
But there is no script, that comes from my openvpnclient1.postconf (call it script...!!!???). That is how my vpn-provider config theirs server pool which contain 28 VPN-servers.

 

[SomeWhereOverTheRainBow]

Thanks
But there is no script, that comes from my openvpnclient1.postconf (call it script...!!!???). That is how my vpn-provider config theirs server pool which contain 28 VPN-servers.

Sounds like the .postconf has some parsing issues.

 

[kernol]

Having reverted to 386.2_6 - it's clear to me that certain bugs have lurked for some time in this section of the Asus firmware.
Here's a quick summary of my findings: -

NORDVPN - DNS Leak Test Results - firmware 386.2_6: [Only one VPN Client in operation at OPVN5]
Accept DNS = Disabled / Force Internet = Policy rules / result ... Public ip = my VPNtunnel ip / DNS = my ISP supplied ip [i.e. my unbound]; [CORRECT]
Accept DNS = Exclusive / Force Internet = Policy Rules / result ... Public ip = my VPNtunnel ip / DNS = my VPNtunnel ip [i.e. still my unbound; [WRONG! s/be VPN provider's DNS].

Accept DNS = Disabled / Force Internet = Yes / result ... Public ip = my VPNtunnel ip / DNS = my VPNtunnel ip [i.e. my unbound]; [WRONG! - s/be my ISP supplied ip]
Accept DNS = Exclusive / Force Internet = Yes / result ... Public ip = my VPNtunnel ip / DNS = my VPNtunnel ip [i.e. my unbound]; [WRONG! s/be VPN provider's DNS].

I can see the VPN Director project will probably absorb a good deal more of your time than you had anticipated. .
No small wonder @Xentrk [with the help of several "Parts of the Furniture"] had to develop so many work-a-rounds in his x3mRouting offering.

Report

 

[Jack Yaz]

Having reverted to 386.2_6 - it's clear to me that certain bugs have lurked for some time in this section of the Asus firmware.
Here's a quick summary of my findings: -

NORDVPN - DNS Leak Test Results - firmware 386.2_6: [Only one VPN Client in operation at OPVN5]
Accept DNS = Disabled / Force Internet = Policy rules / result ... Public ip = my VPNtunnel ip / DNS = my ISP supplied ip [i.e. my unbound]; [CORRECT]
Accept DNS = Exclusive / Force Internet = Policy Rules / result ... Public ip = my VPNtunnel ip / DNS = my VPNtunnel ip [i.e. still my unbound; [WRONG! s/be VPN provider's DNS].

Accept DNS = Disabled / Force Internet = Yes / result ... Public ip = my VPNtunnel ip / DNS = my VPNtunnel ip [i.e. my unbound]; [WRONG! - s/be my ISP supplied ip]
Accept DNS = Exclusive / Force Internet = Yes / result ... Public ip = my VPNtunnel ip / DNS = my VPNtunnel ip [i.e. my unbound]; [WRONG! s/be VPN provider's DNS].

I can see the VPN Director project will probably absorb a good deal more of your time than you had anticipated. .
No small wonder @Xentrk [with the help of several "Parts of the Furniture"] had to develop so many work-a-rounds in his x3mRouting offering.
Report

Since unbound is an addon, I'd suggest it's unreasonable for the firmware to be expected to cater for addon setup. Tests should be completed using core firmware features imo

 

[kernol]

Since unbound is an addon, I'd suggest it's unreasonable for the firmware to be expected to cater for addon setup. Tests should be completed using core firmware features imo

Thanks Jack - appreciate your comment - but you have not followed the discourse between myself and Merlin. The issue is not with unbound - but rather with DNS redirection within the options provided by the firmware. Merlin mentions that the routers resolve.cfg file was being wiped under certain combinations which left it unable to resolve DNS lookups - he is on it no doubt and I was simply giving feedback on my experiences under the PRIOR firmware ... which fits with his earlier comment that the bugs have been there for some time - particularly on the "Yes (all)" redirect option.

EDIT: - For your peace of mind _ I replicated exactly the same responses using Quad9 as my DNS with unbound removed.

 

[RMerlin]

but rather with DNS redirection within the options provided by the firmware. Merlin mentions that the routers resolve.cfg file was being wiped under certain combinations which left it unable to resolve DNS lookups - he is on it no doubt

That specific bug was already fixed over a week ago.

If you are switching back and forth between versions, make sure you flash the latest test build and not a previous one. Sort them by date in the Onedrive folder, and look at the hash tag to differentiate them (the -g... string in the filename, it will also show in the version strong on the webui).

 

[RMerlin]

ok I hear you, That comes from "openvpnclientx.postconf" script.

No, it must come from somewhere else, because that script only does a sed command (BTW, why not just add the second remote in the Custom field instead?). You must be running another script that contains that particular error message.

 

[RMerlin]

but managed to break NordVPN as well by choosing : -
Accept DNS Configuration = "Exclusive" and
Redirect Internet Traffic = "Yes (all)
with no Policy Rules.

Got a local ip address but a Public of Unknown.

Can't reproduce, works for me here with NordVPN.

 

[RMerlin]

Guest Network 1 clients couldn't use the VPN because the new Guest Network implementation Asus added with 386.xx didn't allow these to access any VPN interfaces in the firewall. Fixed now, the firewall will explicitly allow traffic between br2 and tun+.

 

[octopus]

No, it must come from somewhere else, because that script only does a sed command (BTW, why not just add the second remote in the Custom field instead?). You must be running another script that contains that particular error message.

Hmm, I get it not comes from openvpn implantation but it must comes from somewhere.
I have pokeked around and found this in "utils.c" maybe you can have a look at it.

https://github.com/RMerl/asuswrt-merlin.ng/search?q=Error:+any+valid+prefix+is+expected+rather+than

 

[kernol]

That specific bug was already fixed over a week ago.

If you are switching back and forth between versions, make sure you flash the latest test build and not a previous one. Sort them by date in the Onedrive folder, and look at the hash tag to differentiate them (the -g... string in the filename, it will also show in the version strong on the webui).

Thanks Eric
My post to which Jack reacted was simply to confirm that the bug was indeed evident in 386.2_6 firmware.
You probably knew that - I was just confirming it and Jack latched onto "unbound" which was not the issue.

All good - I have gone back to 386.2_6 for now and am cutting my teeth on x3mRouting {ThumbsUp}.

 

[RMerlin]

Hmm, I get it not comes from openvpn implantation but it must comes from somewhere.
I have pokeked around and found this in "utils.c" maybe you can have a look at it.

https://github.com/RMerl/asuswrt-merlin.ng/search?q=Error:+any+valid+prefix+is+expected+rather+than

That would be from iproute2.

Try setting verbosity of the OpenVPN client to 6 instead of the default 3, connect your client, and post the system log result. It will show most of the iproute calls as they are done, which might help tracking down which specific command is sent just before the error.