Hello,
I have a site to site VPN between SonicWall (local) and UDM Pro (remote).
I’m unable to join a remote computer to my local domain. Remote computer is pointing to the DC for DNS and it can ping across the tunnel. But when I try to join the domain, it cannot find the domain. When I do an nslookup and search for my domain, it doesn’t resolve to my domain controller. Has anyone else run into this issue before? What did you do to resolve it? Thank you in advance!
Do you have the right firewall rules on both firewalls to allow all the proper traffic?
I think so. I can ping across the tunnel to the domain controller. Just not able to resolve the names for some reason.
Ping might be allowed but if port 53 isn’t allowed DNS won’t work. These are all the ports your need to allow for a DC.
Thanks, I’ll try that.
I created a rule on the remote UDM under LAN Out to all all traffic to and from the IP of the domain controller. Still not resolving names.
Created allow ANY rule over VPN on the Sonicwall side.
Created allow ANY rule on LAN OUT to 10.0.0.4 on the UDM side.
Am able to ping 10.0.0.4.
Still not resolving names.
C:\Windows\System32>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : ALB-WS-06
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter Ethernet:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek PCIe GbE Family Controller
Physical Address. . . . . . . . . : 36-36-36-36-36-36
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.0.210(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Wednesday, March 20, 2024 7:55:45 PM
Lease Expires . . . . . . . . . . : Saturday, March 23, 2024 5:47:18 AM
Default Gateway . . . . . . . . . : 192.168.0.1
DHCP Server . . . . . . . . . . . : 192.168.0.1
DNS Servers . . . . . . . . . . . : 10.0.0.4
10.110.10.10
NetBIOS over Tcpip. . . . . . . . : Enabled
C:\Windows\System32>ping 10.0.0.4
Pinging 10.0.0.4 with 32 bytes of data:
Reply from 10.0.0.4: bytes=32 time=34ms TTL=127
Reply from 10.0.0.4: bytes=32 time=32ms TTL=127
Reply from 10.0.0.4: bytes=32 time=33ms TTL=127
Reply from 10.0.0.4: bytes=32 time=38ms TTL=127
Ping statistics for 10.0.0.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 32ms, Maximum = 38ms, Average = 34ms
C:\Windows\System32>nslookup 10.0.0.4
Server: UnKnown
Address: 10.0.0.4
*** UnKnown can’t find 10.0.0.4: Non-existent domain
C:\Windows\System32>nslookup theserver.titanic.local
Server: UnKnown
Address: 10.0.0.4
*** UnKnown can’t find theserver.titanic.local: Non-existent domain
C:\Windows\System32>tracert theserver.titanic.local
Unable to resolve target system name theserver.titanic.local.
C:\Windows\System32>
The next thing I would do is check traffic logs on the firewalls or setup wireshark to find out if DNS queries are making it to the DC.
This appears to be a DNS thing. Looks like you are trying to route a .local top-level domain across routers. That is problematic. From my experience your top level domain should always be “routeable”, so something like .com, .name, etc. Changing your toplevel domain should fix it.
The domain controller is the dns server that the remote computer is using. It should be able to resolve the domain name. If I run nslookup locally I get this:
PS C:\Users\user> nslookup titanic.local
Server: UnKnown
Address: 10.10.0.1
Name: titanic.local
Addresses: 10.0.0.4
10.110.10.10
Using .local is bad design in my opinion. Maybe not for super simple flat networks, but you’re beyond that. Sticking with it will cause problems.
Does this name resolve inside the 10.0.0.0/xx subnet?
Yes. I posted it the results above. Locally it resolves just fine. It’s not resolving over the vpn tunnel. Another thing I noticed is if I do a register dns on the remote computer it won’t register it in the dns. Maybe that’s a clue of something.
There is nothing fancy about any of this. If the remote computer can reach the domain controller and it’s using the domain controller as DNS it should be able to resolve names and join the domain. Wondering if this is a known issue with UDM.
I fixed it! Here’s what I did:
- In the UDM I added the domain controller to NTP option under DHCP.
- In the UDM under Networks DHCP I added our domain name.
One of these two things fixed the problem.
Thanks for your help.
Spoke too soon. It was working on Friday. Now it’s back to not resolving again. What is going on?
Looks like based on NS 10.10.0.1, the two DC’s for titanic.local are at 10.0.0.4 & 10.110.10.10. Up above you did a lookup for thesever.titanic.local. Is that your DC hostname? titanic.local should not be. Does NS 10.10.0.1 know about this? Does 10.110.10.10 resolve locally successfully?
Often times it’s too hard fixing dns issues without being elbows deep in it. These questions are just suggestions to point you in a testing direction.
Your setup isn’t fancy, but it isn’t stupid simple either.
Thanks for your help, Joe. I appreciate it.
You aren’t wrong about the routers not liking the .local domain. But it shouldn’t be an issue when routing between lans over ipsec tunnel. I’ve never had any problems doing this with any firewall. Not even Sonicwall, just the UDM.
I did find the problem. And it was related to the .local domain name, but maybe not in the way your thinking. I had to disable the content filter on the UDM because it is using the safebrowsing public dns content filter which can’t resolve the .local domain name. When I disable the content filter on the UDM everything routes and names resolve normally as it should.
Hopefully this info helps anyone else having this problem!
Thanks again for your help!