Beta VPN Director testing

[RMerlin]

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.

It's possible that "Strict" also had a similar effect as "Exclusive" (as it was also a special case), causing the router's own resolv.conf to be empty.

I'm reorganizing that part of the code to ensure that the system resolv.conf will always contain proper values, so only dnsmasq's own servers will be skipped. I'm also tightening requirements for this to happen. The expected final result will be:

• If at least one client is running, and it has DNS mode set to Exclusive, and it's set in "Redirect All", then skip adding WAN DNS servers to dnsmasq
• Always have the router's own resolv.conf contain WAN nameservers, regardless of VPN

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

Either nobody used it recently, or they somehow had it set so it just worked without triggering the issues (for example if they only configured that one client, and kept the DNS mode to the default value). However now that it will more reliably truly redirect WAN traffic (or not redirect it if set to "No"), I believe it's worth the effort of fixing it.

Dnsmasq's configuration changed a lot over the years, and I suspect that gradually the OpenVPN DNS management started to develop issues of its own following these changes. This might have gotten worse when I redesigned a lot of the OpenVPN implementation during the last 384.xx releases, but it only got noticed just now as we've all been poking at OpenVPN's implementation during this test cycle.

 

[Howard_inGA]

All of these are normal and aren't problems. They come from the hardcoded settings not being in sync with what is being negotiated at connect time, which is what will ultimately be used.

I do all of my tests with NordVPN. You might want to erase your setting and update an up-to-date config file from them.

Thanks for that info! I'll reinstall Nord for the router. The PC and Android local Nord connections all are working 4.0, so it is a limited problem...

 

[RMerlin]

I have reworked the DNS handling, particularly related to Exclusive mode. DNS exclusive redirection priority order will now follow the OpenVPN client priority order.

Note that you can still create yourself a problem if you have two clients with overlapping rules, and only one of them is in Exclusive mode - the DNS exclusive rule will always be applied to the client regardless of which of the two instances "caught" it first. At that point, you seriously should consider rethinking your setup, as overlapping rules with two different types of VPN setups will always potentially cause problems. DNS handling is totally separate from routing, so they cannot be explicitly tied together. Only the rule processing order can be controlled.

 

[kernol]

I have reworked the DNS handling, particularly related to Exclusive mode. DNS exclusive redirection priority order will now follow the OpenVPN client priority order.

Note that you can still create yourself a problem if you have two clients with overlapping rules, and only one of them is in Exclusive mode - the DNS exclusive rule will always be applied to the client regardless of which of the two instances "caught" it first. At that point, you seriously should consider rethinking your setup, as overlapping rules with two different types of VPN setups will always potentially cause problems. DNS handling is totally separate from routing, so they cannot be explicitly tied together. Only the rule processing order can be controlled.

Sounds good - let us know when you have compiled beta4 and I will happily test .

 

[ugandy]

impact to x3mRouting?

 

[HappyJuicy]

I want to understand something.
This will fix this Issue?

Policy Rules not excluding a PC and YazFi network can't see local devices

Hi 1) I have set VPN client 1-4 the same way with different servers and added the kill switch to client 5 only. (See picture) This setup run flawlessly even when a server goes down, the next client take the relay BUT when I try to exclude a device from the chain, I go to client 1 and add it to...

www.snbforums.com

 

[kernol]

impact to x3mRouting?

Already asked and answered in prior post here - read to bottom of that post

 

[RMerlin]

Updated builds uploaded. DNS Exclusive mode was re-worked to improve its reliability. DNS rules will get refreshed whenever changes are made to VPN Director rules. Also fixes a number of random DNS-related issues that have been there for quite some time.

77d01758ed rc: add missing change missing in acb41da6c7ef0d21dc381fc6f9c4621998e8016c
185bee1449 Updated documentation
c7c5362b32 openvpn: Updated to 2.5.3
7d0bba90cd libovpn: only use first available DNS servers for Exclusive mode; tweaked logging
346f48a991 webui: properly handle switch state when starting OpenVPN client with missing username/password
e54949ff2d HND5.02p1: Add support for BCM50991
31a4d322d6 libovpn: clear custom settings in reset_ovpn_settings()
acb41da6c7 libovpn: rc: move openvpn-event script back to route-up and route-pre-down handlers instead of up and down handlers.
3a1e8bfb15 libovpn: ensure that DNS exclusive iptables rules are always in the correct order
11ee222581 rc: fix vpnrouting event missing ovpn client 5; reverse order so DNS exclusive rules will be in the correct order in iptables's PREROUTING table
583ce6ffb1 libovpn: rework DNS Exclusive mode interaction with dnsmasq
b6e6633744 webui_ update VPN Director page to use VPN Director instead of Policy Rule in its summary table
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

 

[HappyJuicy]

eric can you help me. Quebec power

 

[RMerlin]

eric can you help me. Quebec power

I don't know. Your setup is so complicated, I can't predict the actual behaviour there.

 

[Intrepid2007]

I just flashed the latest alpha firmware to my AX88U...

After that my router rebooted, I encountered DNS related issues on one of my VPN clients:

VPN1: WeVPN (exclusive DNS)
VPN2: -
VPN3: -
VPN4: Torguard NL (exclusive DNS) *
VPN5: Torguard US (exclusive DNS)

(*) The VPN4 client did not work properly, LAN clients using that VPN connection could not resolve names, no DNS server could be reached. Switching my VPN connections off/on somehow fixed this issue...

Another thing: In my setup, the VPN4 client does NOT receive DNS server(s) from the VPN server during setup. Therefore I added 'dhcp-option DNS 1.1.1.1' in the custom configuration field to get it to work. There are other ways but I prefer it doing like this...

But when I change the DNS server in the custom field (for example 8.8.8.8) and press [Apply], then that DNS server is not used. Instead the previous DNS server is still active..

Only after disabling and enabling the VPN client (using the on/off switch), the DNS server specified in the custom configuration field becomes active..

I tested this with www.dnsleaktest.com...

Nevertheless, now it works as great like it did with the previous firmware

 

[RMerlin]

The VPN4 client did not work properly, LAN clients using that VPN connection could not resolve names, no DNS server could be reached. Switching my VPN connections off/on somehow fixed this issue...

Are all of them set to automatically start at boot?

Can you post the following output while the problem is present?

iptables -t nat -L -vn

In my setup, the VPN4 client does NOT receive DNS server(s) from the VPN server during setup.

What is the system log content during connection of that client?

 

[Intrepid2007]

Are all of them set to automatically start at boot?

Yes, all clients are set to automatically start at boot

Can you post the following output while the problem is present?

iptables -t nat -L -vn

What is the system log content during connection of that client?

OpenVPN log:

Jun 23 22:25:33 ovpn-client4[5748]: OpenVPN 2.5.3 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jun 23 2021 Jun 23 22:25:33 ovpn-client4[5748]: library versions: OpenSSL 1.1.1k 25 Mar 2021, LZO 2.08 Jun 23 22:25:33 ovpn-client4[5749]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Jun 23 22:25:33 ovpn-client4[5749]: TCP/UDP: Preserving recently used remote address: [AF_INET]?.?.?.?:1194 Jun 23 22:25:33 ovpn-client4[5749]: Socket Buffers: R=[524288->524288] S=[524288->524288] Jun 23 22:25:33 ovpn-client4[5749]: UDP link local: (not bound) Jun 23 22:25:33 ovpn-client4[5749]: UDP link remote: [AF_INET]?.?.?.?:1194 Jun 23 22:25:33 ovpn-client4[5749]: TLS: Initial packet from [AF_INET]?.?.?.?:1194, sid=7ab58bff a1862fe5 Jun 23 22:25:33 ovpn-client4[5749]: VERIFY OK: depth=1, CN=TG-VPN-CA Jun 23 22:25:33 ovpn-client4[5749]: VERIFY KU OK Jun 23 22:25:33 ovpn-client4[5749]: Validating certificate extended key usage Jun 23 22:25:33 ovpn-client4[5749]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Jun 23 22:25:33 ovpn-client4[5749]: VERIFY EKU OK Jun 23 22:25:33 ovpn-client4[5749]: VERIFY OK: depth=0, CN=server Jun 23 22:25:33 ovpn-client4[5749]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1557', remote='link-mtu 1525' Jun 23 22:25:33 ovpn-client4[5749]: WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 0' Jun 23 22:25:33 ovpn-client4[5749]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256 Jun 23 22:25:33 ovpn-client4[5749]: [server] Peer Connection Initiated with [AF_INET]?.?.?.?:1194 Jun 23 22:25:34 ovpn-client4[5749]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1) Jun 23 22:25:34 ovpn-client4[5749]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.9.0.1,dhcp-option DNS 10.8.0.1,sndbuf 524288,rcvbuf 524288,route 10.25.0.1,topology net30,ping 5,ping-restart 30,compress,ifconfig 10.25.0.81 10.25.0.82,peer-id 0,cipher AES-256-GCM' Jun 23 22:25:34 ovpn-client4[5749]: OPTIONS IMPORT: timers and/or timeouts modified Jun 23 22:25:34 ovpn-client4[5749]: OPTIONS IMPORT: compression parms modified Jun 23 22:25:34 ovpn-client4[5749]: OPTIONS IMPORT: --sndbuf/--rcvbuf options modified Jun 23 22:25:34 ovpn-client4[5749]: Socket Buffers: R=[524288->1048576] S=[524288->1048576] Jun 23 22:25:34 ovpn-client4[5749]: OPTIONS IMPORT: --ifconfig/up options modified Jun 23 22:25:34 ovpn-client4[5749]: OPTIONS IMPORT: route options modified Jun 23 22:25:34 ovpn-client4[5749]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Jun 23 22:25:34 ovpn-client4[5749]: OPTIONS IMPORT: peer-id set Jun 23 22:25:34 ovpn-client4[5749]: OPTIONS IMPORT: adjusting link_mtu to 1624 Jun 23 22:25:34 ovpn-client4[5749]: OPTIONS IMPORT: data channel crypto options modified Jun 23 22:25:34 ovpn-client4[5749]: Data Channel: using negotiated cipher 'AES-256-GCM' Jun 23 22:25:34 ovpn-client4[5749]: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Jun 23 22:25:34 ovpn-client4[5749]: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key Jun 23 22:25:34 ovpn-client4[5749]: TUN/TAP device tun14 opened Jun 23 22:25:34 ovpn-client4[5749]: TUN/TAP TX queue length set to 1000 Jun 23 22:25:34 ovpn-client4[5749]: /usr/sbin/ip link set dev tun14 up mtu 1500 Jun 23 22:25:34 ovpn-client4[5749]: /usr/sbin/ip link set dev tun14 up Jun 23 22:25:34 ovpn-client4[5749]: /usr/sbin/ip addr add dev tun14 local 10.25.0.81 peer 10.25.0.82 Jun 23 22:25:34 ovpn-client4[5749]: ovpn-up 4 client tun14 1500 1552 10.25.0.81 10.25.0.82 init Jun 23 22:25:36 ovpn-client4[5749]: Initialization Sequence Completed

iptables -t nat -L -vn

xxxxx@RT-AX88U-B230:/tmp/home/root# iptables -t nat -L -vn Chain PREROUTING (policy ACCEPT 606 packets, 123K bytes) pkts bytes target prot opt in out source destination 0 0 DNSVPN1 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 164 11534 DNSVPN1 udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 DNSVPN4 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 102 7222 DNSVPN4 udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 0 0 DNSVPN5 tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 44 3129 DNSVPN5 udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 16 5701 GAME_VSERVER all -- * * 0.0.0.0/0 192.168.20.20 16 5701 VSERVER all -- * * 0.0.0.0/0 192.168.20.20 38 2664 DNSFILTER udp -- * * 192.168.0.0/21 0.0.0.0/0 udp dpt:53 0 0 DNSFILTER tcp -- * * 192.168.0.0/21 0.0.0.0/0 tcp dpt:53 12 912 REDIRECT udp -- br0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:123 redir ports 123 Chain INPUT (policy ACCEPT 154 packets, 21830 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 71 packets, 4665 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 67 packets, 4184 bytes) pkts bytes target prot opt in out source destination 161 19062 MASQUERADE all -- * tun14 0.0.0.0/0 0.0.0.0/0 129 7565 MASQUERADE all -- * tun15 0.0.0.0/0 0.0.0.0/0 197 13484 MASQUERADE all -- * tun11 0.0.0.0/0 0.0.0.0/0 297 23224 PUPNP all -- * eth0 0.0.0.0/0 0.0.0.0/0 37 6308 MASQUERADE all -- * eth0 !192.168.20.20 0.0.0.0/0 21 3127 MASQUERADE all -- * br0 192.168.0.0/21 192.168.0.0/21 Chain DNSFILTER (2 references) pkts bytes target prot opt in out source destination 38 2664 DNAT all -- * * 0.0.0.0/0 0.0.0.0/0 to:192.168.0.1 Chain DNSVPN1 (2 references) pkts bytes target prot opt in out source destination 95 6408 DNAT all -- * * 192.168.1.0/24 0.0.0.0/0 to:10.255.0.1 Chain DNSVPN4 (2 references) pkts bytes target prot opt in out source destination 59 4158 DNAT all -- * * 192.168.4.0/24 0.0.0.0/0 to:1.1.1.1 Chain DNSVPN5 (2 references) pkts bytes target prot opt in out source destination 44 3129 DNAT all -- * * 192.168.5.0/24 0.0.0.0/0 to:10.9.0.1 Chain GAME_VSERVER (1 references) pkts bytes target prot opt in out source destination Chain LOCALSRV (0 references) pkts bytes target prot opt in out source destination Chain PCREDIRECT (0 references) pkts bytes target prot opt in out source destination Chain PUPNP (1 references) pkts bytes target prot opt in out source destination Chain VSERVER (1 references) pkts bytes target prot opt in out source destination 16 5701 VUPNP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain VUPNP (1 references) pkts bytes target prot opt in out source destination intrepid@RT-AX88U-B230:/tmp/home/root# intrepid@RT-AX88U-B230:/tmp/home/root#

The strange thing is that I cannot reproduce none of these issues anymore.

When I apply an altered custom configuration (other DNS), this becomes active now (which is good)...

According to the logs, Torguard DOES send DNS servers but these servers don't work... This appear to be a Torguard specific thing because the Windows/Android app behave the same... On these apps you have to specify an alternative DNS server as well. I have had contact with their support and they told me that this is normal. I have to say that this is a dedicated IP (not a shared VPN IP).

 

[RMerlin]

According to the logs, Torguard DOES send DNS servers but these servers don't work... This appear to be a Torguard specific thing because the Windows/Android app behave the same...

I see that they push private DNS from a different subnet than the actual tunnel, which means your router (and your client devices) have no way of knowing what route to use to reach these, and therefore would typically send that to the default gateway. Torguard probably assume that everyone will always have their default gateway set to point at them whenever they use their service, which is not the case when you use policy routing or when you run multiple tunnels at the same time. Ideally, you'd need routes added for 10.9..0.0/24 and 10.8.0.0/24 going through the tunnel, and you also need to ensure that none of your other clients use the same subnet. Since 10.8.0.0 is commonly used by OpenVPN, you have a high chance of having routing conflicts if you run any other VPN at the same time as Torguard.

One option, once you are sure that none of your other VPN use the same subnets, is to create a Director rule that has these two DNS as the remote IP, and the VPN instance.

Another alternative is to set DNS mode to "disabled", and provide your own DNS servers for these tunnels, and not use these two private DNS at all.

 

[AckSync]

Since 10.8.0.0 is commonly used by OpenVPN, you have a high chance of having routing conflicts if you run any other VPN at the same time as Torguard.

ToGuard uses 10.8.x.x subnet (DNS 10.9.0.1) for OpenVPN config of TCP-443. To prevent subnet conflict when running another Torguard OpenVPN instance on the router, use other configuration different from the previous instance, for instance TCP-80 config that uses subnet of 10.21.x.x (DNS 10.9.0.1).

Torguard OpenVPN Specs:
TCP-443 : subnet 10.8.x.x
UDP-443: subnet 10.9.x.x
TCP-80: subnet 10.21.x.x
UDP-80: subnet 10.22.xx
- they all push DNS 10.9.0.1

The complete subset and cryptography details for various OpenVPN configurations are in "OpenVPN Specifications" under "Info" dropdown in the client area of Torguard.

 

[kernol]

I have reworked the DNS handling, particularly related to Exclusive mode. DNS exclusive redirection priority order will now follow the OpenVPN client priority order.

Note that you can still create yourself a problem if you have two clients with overlapping rules, and only one of them is in Exclusive mode - the DNS exclusive rule will always be applied to the client regardless of which of the two instances "caught" it first. At that point, you seriously should consider rethinking your setup, as overlapping rules with two different types of VPN setups will always potentially cause problems. DNS handling is totally separate from routing, so they cannot be explicitly tied together. Only the rule processing order can be controlled.

WELL DONE - All sorted as far as I can tell [including set Redirect to "Yes (All)"] - but here's the thing ... NordVPN works a treat in every respect ... but

VPNUnlimited fails with the Redirect set to "Yes (All)". Two distinctions from NordVPN - VPNUnlimited does not provide a public ip address in the settings but rather a hostname and does not require Username/Password Authentication [uses a certificate instead]. It does not matter what DNS setting is used - from Disabled through to Exclusive - tunnel fails to obtain Public ip address. It only works with VPN Director Policy set.

No worries - you have another NordVPN convert - have signed up and paid .
Just one more thing though [even applies to NordVPN] - Asus implementation of Guest WiFi 1 which now does cut across AiMesh Nodes ... does not get an internet connection via the tunnel if you attempt to redirect either with policy or with "Yes (All)".

 

[thebatfink]

The only way to add destinations will be individual ip or cidr, ipsets will never be a thing here?

 

[RMerlin]

The only way to add destinations will be individual ip or cidr, ipsets will never be a thing here?

That's correct. Routing tables work only with IP addresses, ipset is a higher level layer.

 

[RMerlin]

VPNUnlimited fails with the Redirect set to "Yes (All)". Two distinctions from NordVPN - VPNUnlimited does not provide a public ip address in the settings but rather a hostname and does not require Username/Password Authentication [uses a certificate instead]. It does not matter what DNS setting is used - from Disabled through to Exclusive - tunnel fails to obtain Public ip address. It only works with VPN Director Policy set.

Show me the system log generated while connecting.

 

[thebatfink]

That's correct. Routing tables work only with IP addresses, ipset is a higher level layer.

Hmm OK thanks. Hopefully he can make xm3routing work together with this then, imagine it will get messy. Being able to bypass the vpn for those geo lock services but sending everything else to vpn is a great little tool and I think it already handles this priority / rule based routing as well. I guess hes achieving it in some other method to yours.