Getting back to the DNS leaks …
I decided to take a closer look @ NordVPN, esp. their instructions, and the results I got when following them, to the letter.
Oddly, NordVPN recommends you configure the WAN w/ their DNS servers (103.86.96.100 and 103.86.99.100). That suggests to me that perhaps their servers are NOT pushing these to the OpenVPN client. OTOH, they do advise you specify Strict for "Accept DNS Configuration". So something seems odd there.
I assigned their DNS servers on the WAN as instructed, which shows up in /tmp/etc/resolv.conf as expected.
Code:
admin@lab-merlin1:/tmp/home/root# cat /tmp/etc/resolv.conf
nameserver 103.86.96.100
nameserver 103.86.99.100
DNSMasq then copies that file to its own servers file, /tmp/resolv.dnsmasq.
Code:
admin@lab-merlin1:/tmp/home/root# cat /tmp/resolv.dnsmasq
server=103.86.96.100
server=103.86.99.100
So far, all as expected.
I then configured the OpenVPN client w/ one of their .ovpn files, set the OpenVPN client to Strict, and connected. Note, I'm using the VPN Director and the following rule.
Code:
192.168.1.0/24 <blank> OVPN3
The syslog clearly shows their server pushing the same DNS servers.
Code:
Jan 25 12:26:55 ovpn-client3[11001]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 103.86.96.100,dhcp-option DNS 103.86.99.100,sndbuf 524288,rcvbuf 524288,explicit-exit-notify,comp-lzo no,route-gateway 10.8.1.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.8.1.4 255.255.255.0,peer-id 2,cipher AES-256-GCM'
Because Strict was specified, their DNS servers will be prepended to those already in /tmp/resolv.dnsmasq. But since they are the same DNS servers, they just end up as duplicates.
Code:
admin@lab-merlin1:/tmp/home/root# cat /tmp/resolv.dnsmasq
server=103.86.96.100
server=103.86.99.100
server=103.86.96.100
server=103.86.99.100
So now I dump both the main and OpenVPN client's routing table (ovpnc3).
Code:
admin@lab-merlin1:/tmp/home/root# ip route
103.86.96.100 via 192.168.63.1 dev eth0 metric 1
103.86.99.100 via 192.168.63.1 dev eth0 metric 1
192.168.63.1 dev eth0 proto kernel scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.8.1.0/24 dev tun13 proto kernel scope link src 10.8.1.4
192.168.63.0/24 dev eth0 proto kernel scope link src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev eth0 metric 1
127.0.0.0/8 dev lo scope link
default via 192.168.63.1 dev eth0
admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc3
103.86.96.100 via 192.168.63.1 dev eth0 metric 1
103.86.99.100 via 192.168.63.1 dev eth0 metric 1
193.160.245.211 via 192.168.63.1 dev eth0
192.168.63.1 dev eth0 proto kernel scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.8.1.0/24 dev tun13 proto kernel scope link src 10.8.1.4
192.168.63.0/24 dev eth0 proto kernel scope link src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev eth0 metric 1
127.0.0.0/8 dev lo scope link
default via 10.8.1.1 dev tun13
Notice something very interesting here. Starting w/ 386.4, ASUS is now binding the WAN DNS servers to the WAN! When the OpenVPN client then gets connected, those static routes are copied down to the OpenVPN client's routing table (ovpnc3). Because static routes always take precedence over the default gateway, any device bound to that VPN (LAN client or even the router) will access those DNS servers over the WAN, NOT the VPN! A traceroute to either of those DNS servers from a LAN client will prove it.
Even if you attempt to force those DNS servers over the VPN w/ routing policy (i.e., as destination/remote IPs), it won't work, since the OpenVPN client's routing table contains the same static routes that point to the WAN.
Even if you don't use routing policy, but "Yes (all)", the NordVPN DNS servers are bound to the WAN like glue.
For my money, that's a DNS leak. The fact you're still using the VPN provider's DNS server(s) is NOT sufficient. They should be routed over the VPN to prevent DNS eavesdropping and hijacking. That's why most OpenVPN providers push DNS servers within the same *private* IP space as the tunnel (e.g., 10.8.0.0/24). Once you start using public IPs, you create these types of problems. Of course, it's exacerbated by the fact the DNS servers are now bound to the WAN.
Also, I believe I know why NordVPN has you configure their DNS servers on the WAN. As I've reported in other threads, the Strict option is NOT working as intended. Instead of prepending the VPN provider's DNS servers to the WAN's DNS servers in /tmp/resolv.dnsmasq, it's appending them. And since the whole purpose of using Strict is to have DNSMasq access the servers in that file, in order, it effectively means the WAN's DNS servers still get priority! But since they shoved their own DNS servers into the WAN anyway, the net effect is that theirs get used, even if the OpenVPN client isn't running.
As I say time and again, managing DNS on the router is very difficult. There are way too many "chefs in the DNS kitchen", each of whom are capable of spoiling the DNS soup. I'm convinced many users have DNS leaks and don't even know it. I just knew this latest change by ASUS to bind the WAN's DNS servers to the WAN was going to be trouble.