Hey there,
I marked this as Windows as I primarily have Windows clients, but this would be more general networking. We utilize Tailscale for remote worker scenarios back to an Active Directory network. Those remote worker machines are joined to AD for group policy and software deployment purposes. We have Split DNS set up for the AD domain pointed to our Windows Domain Controllers which also function as DNS servers with a subnet router for our internal services subnet. From the client’s perspective, it works so flawlessly that we replaced our previous VPN solution in less than a month after initial trial.
Where we’re running in to an issue is that the remote clients are reporting to our AD DNS servers their local IP address on their physical NIC rather than the Tailscale IP address. This means that calling back to those clients isn’t as easy as the local domain (even if it’s a device with Tailscale on it) doesn’t know how to get to that local 192.xx subnet. Any suggestions on how to force the clients to report their TS addresses so that TS-joined devices like our software management machine running PDQ can reach out to them?
So this isn’t exactly a direct answer to your question, but we’ve solved a similar problem differently…
Since MagicDNS will handle keeping track of the TS IP addresses and assigning it an A record (something like your_machine dot your_tailnet dot beta dot tailscale dot net), we created a subdomain under our primary domain (ts dot domain dot com) which just uses CNAME records to point to the MagicDNS name.
So for example, let’s say my machine is named “kevin”, it’s on my tailnet named “kevins_tailnet”, and has the IP address 100.100.100.254. MagicDNS will create an A record which is resolvable only on the kevins_tailnet Tailscale tailnet so if I am connected to my tailnet I can do: dig Kevin dot kevins_tailnet dot beta dot tailscale dot net and I will get back 100.100.100.254.
Now let’s say I have a real domain, “kevin.com” from which I have delegated a subdomain, “ts” to give me “ts dot Kevin dot com”. I then create a CNAME record in that subdomain pointing to Kevin dot kevins_tailnet dot beta dot tailscale dot net, so when you query kevin.ts.kevin.com it will tell the resolver to check there for it. If you are on the TS network it will resolve to 100.100.100.254, and if you are not it will return NXDOMAIN. (Note: because there are no NS records for your Tailnet’s MagicDNS subdomain, tools like dig, host, nslookup, etc. won’t try to follow the CNAME and give you the eventual A record, but if you run something like ping the resolution will work all the way through and connectivity will happen. This also works for host based SNI, virtual hosts on web servers, hostname based routing on load balancers, etc.).
You will need to have some kind of tooling (or have someone manually) creating the CNAME records in your AD DNS, but we’ve found it to be a much cleaner and more maintainable solution than trying to manage A records ourselves (especially since MagicDNS already does this for you!).
Hopefully that helps!
EDIT: I had to write out “dot” instead of putting “.” because the forum only allows two “links” per post and it was interpreting the example DNS names as links. Doh!
1 Like
I think that’s a workable workaround at this point for me. It’s certainly better than paying the additional cost for Intune I think. Thanks for the help!
You are very welcome! It works well for us so I hope it does the same for you!