I’m trying to understand how Tailscale will interact with my Microsoft Active Directory Domain.
I think I need to setup a subnet router. Once I do that, all the devices on my traditional network will be able to connect to all the devices on my Tailscale network. If I’m thinking about this correctly, DHCP won’t be a factor in this because all the Tailscale devices already have an IP and so they wouldn’t request one from the DHCP server.
DNS is the part I can’t seem to get my head around. Should I enable MagicDNS in this situation? It seems to me that Active Directory really wants to manage its own DNS. How would Active Directory and MagicDNS interact?
Outcome: I have a remote site with no connectivity to my main site that uses Active Directory. At this remote site, I want to join 3 Windows servers to the domain at the main site. How can Tailscale help me?
So I’ve gone down the path of installing a subnet router at both locations. It appears that I need to enable the site-to-site connection as described here: Site-to-site networking · Tailscale
However, this guide only references Linux. Is it possible to use with Windows?
Subnet routers can be on windows, but site-site seems to only work on Linux.
From what you’ve said, I would think having the subnet router at the main site and installing Tailscale directly on the windows servers at the remote site to connect to the main site directly would do what you want.
Ideally, you’d want Tailscale installed directly on all the servers eventually, but start with the subnet and remote servers and see how it goes
So I have the subnet router at the main site and I did a test with a server at the remote site. The remote server had the Tailscale client installed.
In the network connections properties of the Tailscale interface I changed the DNS to point to the AD servers. I was able to ping the IP and do nslookup to the main site. I still couldn’t ping by DNS name. Anyway, it did let me joint the domain, but there were other issues. It wouldn’t let me login with a domain account, presumably because Tailscale wasn’t fully enabled at the login screen. It also caused issues with DNS for other services running on that server. I’ve since restored that server back since it was a production server.
DNS messes up a lot, and windows doesn’t really help itself here - I’d suggest leave the tailscale interface alone and start with the DNS settings on the Tailscale control panel. If necessary add manual hostnames to the hosts file to start with while you get the system as a whole working and then move to getting the DNS right more generally once everything else is satisfactory.
At the login screen, tailscale won’t be connected unless you have selected ‘Run unattended’ in Tailscale client.
For a more manual approach, log in as the local user that runs tailscale, then switch user and log in again - as long as the tailscale user is logged in, the domain would be available system-wide. I use this short term for remote setup of new domain accounts on laptops without having to enable unattended mode.
As a note, I just joined a Surface to our domain over Tailscale. Beside the standard SplitDNS settings in tailscale’s admin console and a subnet router that included our Domain I didn’t do anything special.
I am using magicDNS and it’s a bit of a PITA if you have machines both on the LAN subnet, and advertised as tailscale nodes.
You need to make sure your subnet is at least a /23 for a /24 subnet otherwise your route tables will by default send traffic over tailscale even when connected over 100gbe or even co-located on the same VM host with “infinite” bandwidth. We discovered some of our machines were routing through our Subnet Router even though they were LAN peers on the same switch.
Clients seem to very randomly decide whether to use Ts.net vs Corp.com DNS. This is especially annoying with the new system32\drivers\etc\hosts conf which does make DNS instant, but also circumvents magicDNS entirely.
There are some ?new? features though in tailscaleD though like the “use Tailscale DNS” and “use Tailscale subnets”.
Overall, our experience of installing tailscale on servers and trying to use tailscale as it’s “intended” with ACLs and MagicDNS and not just using it as a SSO Wireguard client with traditional splitDNS and subnet routing has been mostly terrible.
DNS has been very unpredictable. Routing has been unpredictable. Windows Servers are just a total mess on authentication/updates/reboots. Client experience has been bad where sometimes they try to connect to Tailscale IP (but tailscale daemon isn’t running because of an automatic update\reboot but Tailscale not coming back up). Also, manually configuring ports isn’t straightforward on Windows at all, so you need to use random ports. And once you have random ports, you need to firewall punch using Nat-PMP which is a whole rash of security implications but the only way to make it work.
I love the dream of Tailscale everywhere, but the reality is still very messy with multiple clients on the same LAN.
Tailscale still needs to straighten out all of the LAN quirks.
Tailscale still needs to improve magicDNS intelligence.
Tailscale needs something like a Derp but without the https overhead. Something in-between a Subnet Router and a Derp server that is easy to firewall manage and regulate. Something Tailscale ACL aware even. To offer facilitate direct connections without exposing UPnP\Nat-PMP vulnerabilities to the whole network.
I’m not dissimilar to Gavin, MagicDNS didn’t really work for us, but adding Tailscale entries to the windows DNS was a no-go as well due to the equipment that doesn’t use it. In the end, I built a pair of DNS servers to do exactly what we want, but there’s still issues with DNS that I blame on Windows - it will use both the local network DNS and TS DNS servers in tandem so often switches address half way through a session, particularly notcable in the browser.
That said Active Directory itself is now working quite happily over the top of TS. We obviously still have the internal network ranges, but almost no user machines are on it direclty any more - even in the office we just give a generic internet service and let TS handle the connection to our internal systems.
We are small enough that I can give dedicated IPv4 NAT addresses for certain key TS systems though and manage it manually - if we got much bigger that would be a problem and we’d hit the same issue of random ports or NAT-PMP.
IPv6 helps a lot here as well - it tends to work a lot easier (for those who have it) since everything is globally routable there, if you allow it.
We never see TS not coming up after a reboot, or have any problems on windows servers - I can just run the update from an admin RDP session and it comes back up quickly and reliably. On user machines there’s more update issues if done while the user is logged in, but we just set it to run on reboot and it works for 80-90% of machines.
Hi @Spidge. Thanks for this explanation. Can you clarify what mean by “I built a pair of DNS servers to do exactly what we want”?
The only DNS I’m familiar with controlling is the Windows Active Directory DNS. Is that what you mean? If you have any other suggestions, I’m all ears. In my case, I just need a single remote print server to connect back to the domain. Client devices don’t need to be on the domain.
If you just want a remote print server to connect back to the domain, I wouldn’t be bothering with all the messing about I’ve done. Install Tailscale and get it working either by subnet routing to the domain, magicDNS if you can, or editing the hosts list.
For windows servers, best to set it as unattended unless you want to log it in every time it reboots.