DNS Proxy over Site-to-Site VPN
We have a remote site (TZ300) setup via an IKEv2 Site-to-Site VPN tunnel to a hub location (NSa2600). Lets say the TZ300 is 10.0.2.1 and is the gateway for the LAN network 10.0.2.0/24. The TZ300 is set to be a DNS proxy and all computers at the remote site are set with 10.0.2.1 as their DNS server. The TZ300 is then setup under the DNS settings to have the DNS IP be our DNS server (Win2016, lets say that is 10.0.1.2, the NSa2600 network is 10.0.1.0/24) at our hub location.
When a computer at the remote site (lets say 10.0.2.2) attempts a DNS query against the TZ300 (10.0.2.1), doing a Packet Monitor Capture on port 53, I can see that the remote computer does send the DNS query to the TZ300 and it has a status of "Received". But it appears the TZ300 is never forwarding the query on to the DNS server (10.0.1.2). The computer then eventually just times out on the DNS request since it never receives a reply from the TZ300.
That being said, I do see DNS traffic traversing just fine from the TZ300 itself to the DNS server for other needs (such as, several sonicwall.com DNS reqeusts which I assume are some services running on TZ300...such as Gateway Anti-Virus, etc.) These requests are being sent from the TZ300 to the DNS server, and receiving a reply without any problems. It just appears to be that the TZ300 is not recognizing what to do with the DNS proxy requests when the DNS server is on the other side of the VPN connection.
That being said, If I setup the DNS proxy to use a "public" DNS (Such as 188.8.131.52), then it immediately works without any issue and the remote computer receives a DNS response immediately.
What am I doing wrong?
UPDATE: in doing some more testing. I decided to do a "Monitor All" on the capture to see what is happening. I found out what the issue is.
It appears that the TZ300 is trying to send the traffic as the WAN IP address out the WAN interface, instead of trying to send it through the VPN tunnel.
It appears the TZ300 is translating the DNS query request into being from (as an example WAN IP) 184.108.40.206 to 10.0.1.2. So then I assume the TZ300 is giving up because IP address 10.0.1.2 does not exist in the WAN.
Do I need to setup some kind of Routing in order to pass the traffic through the VPN? I have never had to setup routing for a VPN before.
The only reason that the SonicWall might be trying to send the traffic on WAN and not through the VPN is when a SA is not formed between the source and destination address. Please check if the source IP from which the traffic is coming to the TZ 300 and the DNS server itself are both part of the networks that you have included in the VPN configuration.
Under the active tunnels section on VPN page you should see the networks for which the SA is built. Also, kindly take a look at the NAT policy table and make sure no incorrect NATs are in place.
Technical Support Advisor, Premier Services
that's an interessting question, which IP (Interface) is used for the forwarded DNS queries. In IPv4 Split DNS you can specifiy a local interface for that, but not for the general DNS proxy.
Do you really need to forward ALL DNS requests to your 10.0.1.2 W2K16 server or just for your internal Domain? That's usually a common scenario for me, just use the IPv4 Split DNS (Manage -> Network -> DNS) for this, forwarding only *.company.local to 10.0.1.2 with local interface X0 and you should be good to go. All remaining DNS requestes are forwarded to your usualy external DNS servers.
Maybe that's a way to resolve this situation?
Just one question, why do you need to use DNS proxy at all at the remote site?
you can just point your DHCP server on the 10.0.2.0/24 network to use the DNS server IP 10.0.1.2 address and this will know to go across the VPN anyway?
Ok, to answer some of your questions:
IP Address Source: Yes the subnet of the source is included in the VPN configuration on both sides. The remote computers CAN communicate with the DNS server directly via the VPN tunnel. Only the DNS Proxy is not routing through the VPN.
NAT: yes I checked the NAT and don't see anything wrong there. I even tried to add a specific NAT to explicitly re-categorize traffic from the "X1 Management IP" into the "X0 Management IP" for any traffic heading specifically to the server's IP address (10.0.1.2). And that still didn't work. DNS query would still come from the X1 Management IP address.
Split DNS: I guess I could try doing split, but I just thought it would be much easier to setup and manage without the split DNS.
Do I need to forward all DNS: yes. Our DNS has some "custom external" forwards setup for if people try to access some of our cloud services to redirect them to internal sources directly. As opposed to if they are attempting to access the same service from outside the network which then points to the WAN source. But yes MOST of the traffic for this would just be "*.company.local" queries.
Do I need DNS Proxy: No I don't "Need" it. But I would prefer it for many reasons, all stemming from caching of the DNS entries. Caching would allow: less VPN traffic usage thus less bandwidth usage on the ISP of each location...even if it is barely anything in the grand scheme of things, any little bit helps. Also if we have to reboot our DNS server people won't lose their internet completely. Also Windows being a Microsoft product it sucks...and if we setup a backup DNS on the remote computers (such as a public DNS provider) then when we reboot the DNS server all the computers will revert to the public DNS provider...but will NEVER do any checks to revert back once the DNS server is up and running, will only do so after a reboot of the computer. As such, I wanted to set the SonicWALL as the DNS, because it will periodically check for the DNS server to be back online and will automatically revert back to it once it is live again.
depending on the amount of "custom external" zones I would make a judgement call. If it's not that many then Split DNS is the way to go, IMHO. Don't but the burden of all DNS traffic to your VPN, it'll be probably much snappier for the endusers connecting to some resolvers on the internet (Google, ISP, ...).
I usually rely on this deployment when having one or two handful splitted domains, but whenever possible I deploy external resolvers like powerdns-recursor or at least dnsdist, which gives me extreme flexibility. Having externals resolvers defined on the endpoints is IMHO a no no as well.
And yes, MS DNS sucks for ages and always holds some surprises.