Slate AX - Wireguard VPN tunnel DNS not working

[yurividal]

Hi. I have a VPN tunnel to my home server, which runs 2 DNS pi-hole servers.
I can’t get any of my SlateAX clients to use the DNS from the tunnel, even if i try to nslookup directly to the servers.

Here are some screenshots:

I can ping the server over the tunnel. But can’t nslookup directly to it. I’m trying to resolve a name that is configured in my DNS server to resolve to a local IP in the LAN.

The tunnel is properly configured to route any 10.10.10.0/24 addresses to my wireguard tun.My DNS settings are set to auto: (I tried override, allow custom, and even setting it to manual 10.10.10.53.


My wireguard conf is as follows:

[Interface]
Address = 10.8.0.4/24
PrivateKey = <redacted>
DNS = 10.10.10.53,10.10.10.54
MTU = 1420
[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = <redacted>:51820
PersistentKeepalive = 25
PublicKey = <redacted>
PresharedKey = <redacted>

What am i missing?

[yurividal]

[yurividal]

[yurividal]

[yurividal]

Just to be clear, normal DNS still works. I can browse the internet just fine. its just that resolving names form my pihole server doesn’t work

[bruce]

Hello,

First switch to Global mode, to reduce the variables, only use the ***LAN tunnel, and then test:

1. Is the DNS server 10.10.10.53 resolution normally if test in the server router LAN client?
2. Is the DNS server 10.10.10.53 resolution normally if test in the Slate AX SSH terminal?

[yurividal]

The problem seems to be on the policy based routing.

If i set my VPN to go "All Targets" to my wireguard, and disable the proton VPN, i can resolve the dns names. If I change it to "Specified Domain / IP List" and set it to 10.10.10.0/24 the name resolution doesn't work. Even though my DNS is set to 10.10.10.53 which is within that subnet range

[fwdlink]

I have a similar issue also Slate AX upgraded tonight to 4.8.2, in my case I’m seeing some of the resolves go to the VPN server endpoint by confirming on the endpoint. However what I do see is that the traffic is also no flowing for domain names through the tunnel, for example I want all co.uk domains to route to the server endpoint, this is not happening. The traffic is going out the Slate AX and can confirm this as I’m receiving content for the local geo, not the server geo. Normally in the logs of the Slate AX client I would see “route added” for the domains after the DNS lookup reply from the WG Server endpoint or even IP’s, to then enable the traffic to route through the tunnel. This is not happening with this update. I can reach the server endpoint and the lan ip’s in that network as the server allows it, however nothing else is routing down the tunnel using the specifiied domain/ip policy. And like the OP, not all is resolving to the WG Server DNS and like OP the routes are defined for this, and as stated some queries do go. Strange!

[bruce]

Hello,

Thank you for your feedback.

I tested it locally and indeed be reproduced.

My test topology:

VPN server, AX1800:

VPN client, MT3000:

• When tunnel policy To is All target, the DNS resolution from Pi-Hole works fine:
  
  
  
  
  

C:\Users\itwuh>nslookup www.qq.com
Server:  console.gl-inet.com
Address:  192.168.18.1

Non-authoritative answer:
Name:    ins-r23tsuuf.ias.tencent-cloud.net
Addresses:  121.14.77.221
          121.14.77.201
Aliases:  www.qq.com

C:\Users\itwuh>nslookup www.qq.com 192.168.6.118
Server:  UnKnown
Address:  192.168.6.118

Non-authoritative answer:
DNS request timed out.
    timeout was 2 seconds.
Name:    ins-r23tsuuf.ias.tencent-cloud.net
Addresses:  121.14.77.201
          121.14.77.221
Aliases:  www.qq.com

C:\Users\itwuh>nslookup www.qq.com 10.0.0.1
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  10.0.0.1

Non-authoritative answer:
DNS request timed out.
    timeout was 2 seconds.
Name:    ins-r23tsuuf.ias.tencent-cloud.net
Addresses:  121.14.77.221
          121.14.77.201
Aliases:  www.qq.com

• When tunnel policy To is 192.168.6.0/24 (VPN server router LAN subnet), the DNS resolution from Pi-Hole does not work:
  
  

C:\Users\itwuh>nslookup www.qq.com 192.168.6.118
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.6.118

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

C:\Users\itwuh>nslookup www.qq.com 10.0.0.1
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  10.0.0.1

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

# without specified DNS server, request server should be used the WAN.
C:\Users\itwuh>nslookup www.qq.com
Server:  console.gl-inet.com
Address:  192.168.18.1

Non-authoritative answer:
Name:    ins-r23tsuuf.ias.tencent-cloud.net
Addresses:  121.14.77.221
          121.14.77.201
Aliases:  www.qq.com

Whether To is All target or 192.168.6.0/24, PC ping [pihole LAN IP] is reachable:

C:\Users\itwuh>ping 192.168.6.118

Pinging 192.168.6.118 with 32 bytes of data:
Reply from 192.168.6.118: bytes=32 time=100ms TTL=62
Reply from 192.168.6.118: bytes=32 time=351ms TTL=62
Reply from 192.168.6.118: bytes=32 time=100ms TTL=62
Reply from 192.168.6.118: bytes=32 time=81ms TTL=62

Ping statistics for 192.168.6.118:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 81ms, Maximum = 351ms, Average = 158ms

I submitted the issue to R&D for analysis. It may be that the DNS shunt design is like this, or it may be that there is a problem with DNS in the VPN policy.
When we confirm later, will update here.

[bruce]

Hello,

Thank you for your feedback.

I tested it locally and indeed be reproduced.

My test topology:

VPN server, AX1800:

VPN client, MT3000:

• When tunnel policy To is All target, the DNS resolution from Pi-Hole works fine:
  
  
  
  
  

C:\Users\itwuh>nslookup www.qq.com
Server:  console.gl-inet.com
Address:  192.168.18.1

Non-authoritative answer:
Name:    ins-r23tsuuf.ias.tencent-cloud.net
Addresses:  121.14.77.221
          121.14.77.201
Aliases:  www.qq.com

C:\Users\itwuh>nslookup www.qq.com 192.168.6.118
Server:  UnKnown
Address:  192.168.6.118

Non-authoritative answer:
DNS request timed out.
    timeout was 2 seconds.
Name:    ins-r23tsuuf.ias.tencent-cloud.net
Addresses:  121.14.77.201
          121.14.77.221
Aliases:  www.qq.com

C:\Users\itwuh>nslookup www.qq.com 10.0.0.1
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  10.0.0.1

Non-authoritative answer:
DNS request timed out.
    timeout was 2 seconds.
Name:    ins-r23tsuuf.ias.tencent-cloud.net
Addresses:  121.14.77.221
          121.14.77.201
Aliases:  www.qq.com

• When tunnel policy To is 192.168.6.0/24 (VPN server router LAN subnet), the DNS resolution from Pi-Hole does not work:
  
  

C:\Users\itwuh>nslookup www.qq.com 192.168.6.118
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.6.118

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

C:\Users\itwuh>nslookup www.qq.com 10.0.0.1
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  10.0.0.1

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out

# without specified DNS server, request server should be used the WAN.
C:\Users\itwuh>nslookup www.qq.com
Server:  console.gl-inet.com
Address:  192.168.18.1

Non-authoritative answer:
Name:    ins-r23tsuuf.ias.tencent-cloud.net
Addresses:  121.14.77.221
          121.14.77.201
Aliases:  www.qq.com

Whether To is All target or 192.168.6.0/24, PC ping [pihole LAN IP] is reachable:

C:\Users\itwuh>ping 192.168.6.118

Pinging 192.168.6.118 with 32 bytes of data:
Reply from 192.168.6.118: bytes=32 time=100ms TTL=62
Reply from 192.168.6.118: bytes=32 time=351ms TTL=62
Reply from 192.168.6.118: bytes=32 time=100ms TTL=62
Reply from 192.168.6.118: bytes=32 time=81ms TTL=62

Ping statistics for 192.168.6.118:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 81ms, Maximum = 351ms, Average = 158ms

I submitted the issue to R&D for analysis. It may be that the DNS shunt design is like this, or it may be that there is a problem with DNS in the VPN policy.
When we confirm later, will update here.

Update:
We re-check the VPN rules again:
When tunnel policy To is 192.168.6.0/24 (VPN server router LAN subnet)

The meaning of this rule is that the domain/IP of the resource that needs to be accessed will only go to this VPN server/node, and DNS resolution does not belong to the "resource to be accessed".

Based on your description, I assume that you should want to access certain custom domain which goes to the subnet "10.10.10.0/24":

Please copy the custom domain list from the pihole and paste to the router VPN client tunnel rule "To", that make specific part go to the VPN tunnel.