What's new

Beta VPN Director testing

  • 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.
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.
 
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...
 
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.
 
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 :).
 
impact to x3mRouting?
 
Last edited:
I want to understand something.
This will fix this Issue?
 
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.

Code:
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
 
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
 
Last edited:
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?

Code:
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?
 
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?

Code:
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).
 
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.
 
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.
 
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 :D.
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)".
 
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.
 
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.
 
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.
 
Status
Not open for further replies.

Similar threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top