One destination VPN policy rule and strict DNS behavior

[Genadio]

Hello,

my situation:
on one device, I need to use VPN only for one single destination. To do this, I configured the VPN client in the router's interface and specified only one rule in the policy rules - so that the VPN would be used on the specified device only when connecting to this single destination.
But then it is not clear to me which DNS server will be used. If I'll set all traffic go through VPN, then it is clear that the device will use the VPN's DNS for everything.
But what if I have only one rule for using VPN for one destination? Will the VPN's DNS be used for this destination and the DNS specified in the WAN settings for everything else?

I apologize if the question is stupid. I did not find an answer to this and I am not good at networking things to check myself.

 

[eibgrad]

Be forewarned, DNS is very tricky when it comes to the router. No one can be 100% sure where your DNS is actually being accessed by merely knowing the configuration. You have to examine what the traffic is actually doing to verify what's happening.

By default, *all* LAN clients are bound to the router's local DNS proxy (DNSMasq) for the purposes of DNS. Therefore, how DNS is accessed wrt public DNS servers is dependent on how DNSMasq itself is configured. And by default, it's configured to use the ISP's DNS servers.

In theory (and I say that for a reason, which I'll get to in a moment), when you specify Strict for "Accept DNS Configuration", it causes the router to reconfigure the local DNS proxy (DNSMasq) to include the VPN's DNS servers w/ those of the ISP, and gives the VPN's DNS server priority (thanks to the strict-order directive). So all the LAN clients will now be redirected to the VPN for DNS, just so long as the VPN provider's DNS server remains up and running (if it fails, it falls back to the ISP's DNS servers).

But that doesn't tell the whole story. This *assumes* the VPN server actually pushes its own DNS server to the client. Thankfully most do, but NOT all. And if they don't, then DNSMasq remains effectively unchanged, and you're still using the ISP's DNS servers!

But let's assume the VPN does push its own DNS server. What if it pushes a *public* IP for DNS (e.g., 8.8.8.8)? I've seen it happen (esp. budget providers who don't want to manage their own DNS). And since the router itself is removed from the VPN whenever you're using routing policy, DNSMasq in this case will use the WAN to route all those DNS requests to 8.8.8.8!

I've even seen misconfigurations by the VPN provider. One of my own (KeepSolid) pushes a DNS server which is *outside* the scope of the IP tunnel! The provider configures the tunnel using a net30 topology, which means it's basically PTP (point to point).

admin@lab-merlin1:/tmp/home/root# ifconfig tun11
tun11     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.200.0.62  P-t-P:10.200.0.61  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:36 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3634 (3.5 KiB)  TX bytes:0 (0.0 B)

But notice the DNS server they push (10.200.0.1) is NOT within that same scope.

Jan  8 20:06:26 ovpn-client1[728]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.200.0.1,rcvbuf 262144,sndbuf 262144,comp-lzo no,ping 5,ping-exit 30,route 10.200.0.1,topology net30,ifconfig 10.200.0.62 10.200.0.61,peer-id 14,cipher AES-256-GCM'

The only way this works is if you are NOT using routing policy, since then *everything* is routed over the VPN by default anyway, including the router and DNSMasq. But once you enable routing policy, that *private* IP for the DNS server will be accessed over the WAN, which will obviously fail. And the router will once again fall back to the ISP's DNS servers.

Now granted, these situations are the exception. And the VPN provider above is just being a knucklehead. But things like this do occur. And it's why I say that you can never be 100% sure where your DNS is headed just by knowing/stating your configuration. There are certain things you can only know once the VPN is connected. And which require YOU to examine the results.

To make matters worse, I was just playing around w/ the new 386.4 firmware, and AFAICT, the use of Strict for "Accept DNS Configuration" is NOT working. When I examine the nameservers file (/tmp/resolv.dnsmasq) after the VPN is connected, it's putting the VPN's DNS server at the *bottom* of the file, after the ISP's DNS servers (I've overridden those w/ Cloudflare servers).

admin@lab-merlin1:/tmp/home/root# cat /tmp/resolv.dnsmasq
server=1.1.1.1
server=1.0.0.1
server=10.200.0.1

And when using the strict-order directive w/ DNSMasq, it will access them in the order specified in that file. Hence, the ISP's DNS servers are still being accessed. I've confirmed this by dumping connection tracking to see where the public DNS requests from DNSMasq are being routed, which is definitely over the WAN. If I manually move the 10.200.0.1 server to the top of the file and force DNSMasq to reread it (w/ SIGHUP), it now accesses the 10.200.0.1 server first (but still fails since it's routed over the WAN).

So either I'm missing something, or this appears to be a bug (I don't recall if things worked correctly/differently w/ 386.3_2).

Like I said, DNS is very tricky.

 

[Genadio]

Be forewarned, DNS is very tricky when it comes to the router. No one can be 100% sure where your DNS is actually being accessed by merely knowing the configuration. You have to examine what the traffic is actually doing to verify what's happening.

By default, *all* LAN clients are bound to the router's local DNS proxy (DNSMasq) for the purposes of DNS. Therefore, how DNS is accessed wrt public DNS servers is dependent on how DNSMasq itself is configured. And by default, it's configured to use the ISP's DNS servers.

In theory (and I say that for a reason, which I'll get to in a moment), when you specify Strict for "Accept DNS Configuration", it causes the router to reconfigure the local DNS proxy (DNSMasq) to include the VPN's DNS servers w/ those of the ISP, and gives the VPN's DNS server priority (thanks to the strict-order directive). So all the LAN clients will now be redirected to the VPN for DNS, just so long as the VPN provider's DNS server remains up and running (if it fails, it falls back to the ISP's DNS servers).

But that doesn't tell the whole story. This *assumes* the VPN server actually pushes its own DNS server to the client. Thankfully most do, but NOT all. And if they don't, then DNSMasq remains effectively unchanged, and you're still using the ISP's DNS servers!

But let's assume the VPN does push its own DNS server. What if it pushes a *public* IP for DNS (e.g., 8.8.8.8)? I've seen it happen (esp. budget providers who don't want to manage their own DNS). And since the router itself is removed from the VPN whenever you're using routing policy, DNSMasq in this case will use the WAN to route all those DNS requests to 8.8.8.8!

I've even seen misconfigurations by the VPN provider. One of my own (KeepSolid) pushes a DNS server which is *outside* the scope of the IP tunnel! The provider configures the tunnel using a net30 topology, which means it's basically PTP (point to point).

admin@lab-merlin1:/tmp/home/root# ifconfig tun11
tun11     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:10.200.0.62  P-t-P:10.200.0.61  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:36 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3634 (3.5 KiB)  TX bytes:0 (0.0 B)

But notice the DNS server they push (10.200.0.1) is NOT within that same scope.

Jan  8 20:06:26 ovpn-client1[728]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.200.0.1,rcvbuf 262144,sndbuf 262144,comp-lzo no,ping 5,ping-exit 30,route 10.200.0.1,topology net30,ifconfig 10.200.0.62 10.200.0.61,peer-id 14,cipher AES-256-GCM'

The only way this works is if you are NOT using routing policy, since then *everything* is routed over the VPN by default anyway, including the router and DNSMasq. But once you enable routing policy, that *private* IP for the DNS server will be accessed over the WAN, which will obviously fail. And the router will once again fall back to the ISP's DNS servers.

Now granted, these situations are the exception. And the VPN provider above is just being a knucklehead. But things like this do occur. And it's why I say that you can never be 100% sure where your DNS is headed just by knowing/stating your configuration. There are certain things you can only know once the VPN is connected. And which require YOU to examine the results.

To make matters worse, I was just playing around w/ the new 386.4 firmware, and AFAICT, the use of Strict for "Accept DNS Configuration" is NOT working. When I examine the nameservers file (/tmp/resolv.dnsmasq) after the VPN is connected, it's putting the VPN's DNS server at the *bottom* of the file, after the ISP's DNS servers (I've overridden those w/ Cloudflare servers).

admin@lab-merlin1:/tmp/home/root# cat /tmp/resolv.dnsmasq
server=1.1.1.1
server=1.0.0.1
server=10.200.0.1

And when using the strict-order directive w/ DNSMasq, it will access them in the order specified in that file. Hence, the ISP's DNS servers are still being accessed. I've confirmed this by dumping connection tracking to see where the public DNS requests from DNSMasq are being routed, which is definitely over the WAN. If I manually move the 10.200.0.1 server to the top of the file and force DNSMasq to reread it (w/ SIGHUP), it now accesses the 10.200.0.1 server first (but still fails since it's routed over the WAN).

So either I'm missing something, or this appears to be a bug (I don't recall if things worked correctly/differently w/ 386.3_2).

Like I said, DNS is very tricky.

Thanks for your reply, I tried to see for myself what happens with the DNS using DNS leak tests.

My config: WAN DNS is quad9 (9.9.9.9), Accept DNS Configuration - strict, Redirect Internet traffic through tunnel - policy rules.

Results:
1) No rules for my PC - in the DNS leak test I see only quad9's DNS servers.
2) All PC's trafic through VPN (rule for the PC with empty destination) - I see only VPN's DNS servers in the test.
3) Use VPN on the PC only for one destination (rule for the PC with one specific destination) - I see quad9 DNS servers. I suppose that even when connecting to the specified destination, the quad9's DNS instead of VPN's DNS will be used.

But probably this is not a problem, since still my activity on this destination will be hidden from the ISP and also the ISP will not know that I'am visiting this destination, since my router does not use the ISP's DNS at all.

 

[eibgrad]

I should preface by saying, I don't trust online leak testing tools. As I said, you're always accessing public DNS servers via a local proxy (DNSMasq), and therefore I don't see how a remote service can reliably detect how a given client is using DNS. I assume it involves some javascript "trickery", and it would be nice to know what that is for any given service. Whenever I use them, I never seem to get the correct results.

Realize too that when *I* speak of a DNS leak, I'm NOT just referring to the use of the ISP's DNS servers, but any other DNS servers I may have chosen to use instead (e.g., 9.9.9.9) but are still routed over the WAN, where the ISP can eavesdrop, or worse, hijack my preferred DNS back to their own DNS.

In the case of result #3, that would concern me. As I said, given the use of Strict for "Accept DNS Configuration", all your clients, whether bound to the WAN or VPN, *should* be using the DNS pushed by your VPN provider. All I can assume is you are experiencing the same bug I am, and that means Quad9 is being used and routed over the WAN. But if you're satisfied w/ that situation, then you might as well change Strict to Disabled, since you are effectively NOT using the DNS provided by your VPN provider anyway.

 

[eibgrad]

P.S. You might want to create a policy rule to bind 9.9.9.9 (as a destination) to the VPN. At least then, when the VPN is active, it will be routed over the VPN.

 

[Genadio]

P.S. You might want to create a policy rule to bind 9.9.9.9 (as a destination) to the VPN. At least then, when the VPN is active, it will be routed over the VPN.

Thanks a lot.

I set "Accept DNS Configuration" to Disabled.

But about the policy rule with the 9.9.9.9 destination:

In my configuration the router manages the DNS for all clients. (9.9.9.9 set in WAN settings and DNS in LAN is empty).
If I will add a policy rule for my PC with 9.9.9.9 as a destination to the VPN. Will then DNS requests from my PC be routed over the VPN?
I mean, I don't need a policy rule with my router address in the "Local IP" column for it, correct?

 

[eibgrad]

Thanks a lot.

I set "Accept DNS Configuration" to Disabled.

But about the policy rule with the 9.9.9.9 destination:

In my configuration the router manages the DNS for all clients. (9.9.9.9 set in WAN settings and DNS in LAN is empty).
If I will add a policy rule for my PC with 9.9.9.9 as a destination to the VPN. Then DNS requests from my PC will be routed over the VPN?
I mean, I don't need a policy rule with my router address in the "Local IP" column for it, correct?

Depends on what you want. If you *only* want that local IP to use 9.9.9.9 over the VPN, then include it in the rule. If you do NOT include it, then *all* clients, regardless whether they are bound to the WAN or VPN, will have their DNS routed over the VPN.