{"slug":"access-azure-windows-vms-privately-using-tailscale","title":"Access Azure Windows VMs privately using Tailscale","tags":["tailscale","access-control","setup"],"agent_summary":"Last validated: Jan 5, 2026","trigger_phrases":[],"runnable":false,"markdown":"\r\n# Access Azure Windows VMs privately using Tailscale\r\n\r\nLast validated: Jan 5, 2026\r\n\r\nMicrosoft Azure is a cloud service provider offering Linux and Windows virtual machines, to which Tailscale can be used to provide secure connectivity. This topic covers Windows VMs running within Azure. For Linux VMs, refer to [Access Azure Linux VMs privately using Tailscale](https://tailscale.com/docs/install/cloud/azure/linux).\r\n\r\n## [Prerequisites](https://tailscale.com/docs/install/cloud/azure/windows\\#prerequisites)\r\n\r\nBefore you begin this guide, you'll need a Tailscale network set up and\r\nconfigured with at least one existing device. Read our [getting started guide](https://tailscale.com/docs/how-to/quickstart)\r\nif you need help with this.\r\n\r\n## [Step 1: Set up the Tailscale client for Windows VMs](https://tailscale.com/docs/install/cloud/azure/windows\\#step-1-set-up-the-tailscale-client-for-windows-vms)\r\n\r\nFirst, [create a Virtual Machine](https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.Compute%2FVirtualMachines)\r\nrunning Windows Datacenter Edition.\r\n\r\nIf at least one side of a tunnel has \"easy NAT,\" where Tailscale can determine the UDP port\r\nnumber on the far side of the NAT device, then it will make\r\n[direct connections to minimize latency.](https://tailscale.com/blog/how-tailscale-works)\r\nWe ensure that the Azure nodes can make direct connections by allowing UDP port 41641 to\r\ningress through the firewall.\r\n\r\nIn the Networking step while creating the VM choose Advanced for the NIC network security group,\r\nand create a network security policy to allow UDP port 41641 to ingress.\r\n\r\n![Network Security Group allow port 41641](https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fwindows-nsg.c0ce1417.jpg&w=3840&q=75)\r\n\r\nFor the initial setup it is helpful to also allow RDP and/or SSH. Once Tailscale is installed, public\r\naccess can be removed in favor of going through Tailscale.\r\n\r\nThen RDP to the system, and [download the latest Windows installer](https://tailscale.com/download/windows).\r\n\r\nIt is possible to log in using a browser as described in\r\n[install Tailscale on Windows](https://tailscale.com/docs/install/windows), as Windows\r\nDatacenter Edition does include a GUI and web browser.\r\n\r\nHowever this tends not to work as well\r\nfor a Cloud VM where one is likely not already logged in from the browser.\r\n\r\nAlternately, one can use a `cmd.exe` shell to run the Tailscale CLI command and [use an auth key](https://tailscale.com/docs/features/access-control/auth-keys):\r\n`tailscale up --accept-dns=false --auth-key=tskey-0123456789abcdef`\r\n\r\nFor Azure VMs it is generally best to let Azure handle the DNS configuration,\r\nnot have Tailscale override it, so we added `--accept-dns=false`.\r\n\r\n## [Step 2: Advertise routes from the VM](https://tailscale.com/docs/install/cloud/azure/windows\\#step-2-advertise-routes-from-the-vm)\r\n\r\nFor the benefit of the _other_ nodes in the tailnet we'll set up\r\n[split DNS](https://tailscale.com/docs/reference/dns-in-tailscale#tailscale-dns-settings) to allow\r\nuse of the same DNS names as are used inside of Azure. The\r\n[Azure DNS server address is 168.63.129.16](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances#azure-provided-name-resolution), which is an anycast address that will go\r\nto the nearest DNS server within Azure.\r\n\r\nWe'll use `cmd.exe` to have our VM advertise routes for both the subnet it sits on as well as the\r\nAzure DNS server. For example, if the subnet address range is 10.1.0.0/24, the command would be:\r\n\r\n```shell\r\ntailscale set --advertise-routes=10.1.0.0/24,168.63.129.16/32 --accept-dns=false\r\n```\r\n\r\n## [Step 3: Add Azure DNS for your tailnet](https://tailscale.com/docs/install/cloud/azure/windows\\#step-3-add-azure-dns-for-your-tailnet)\r\n\r\nIn the [DNS](https://login.tailscale.com/admin/dns) page of the admin console we add a nameserver\r\nrestricted to the `internal.cloudapp.net` domain, pointing to the Azure DNS server which we\r\nmade available through our VM.\r\n\r\n![Adding a Split DNS resolver for internal.cloudapp.net](https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fazure-add-DNS.35617d9c.jpg&w=3840&q=75)\r\n\r\nNow the same hostnames which work between nodes running within Azure will also be available\r\nto all nodes on our tailnet.\r\n\r\n## [Step 4: Remove public SSH access](https://tailscale.com/docs/install/cloud/azure/windows\\#step-4-remove-public-ssh-access)\r\n\r\nAs we can now SSH to the system over the private Tailscale network, there is no reason to leave\r\nthe SSH port open on a public IP address. In the Settings > Network tab select the ingress\r\nrule for \"SSH\" and delete it.\r\n\r\n![Disable public SSH port.](https://tailscale.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fazure-disable-ssh.a5877f02.jpg&w=3840&q=75)\r\n\r\n## [4via6 subnet routers](https://tailscale.com/docs/install/cloud/azure/windows\\#4via6-subnet-routers)\r\n\r\nIf your network has subnets with overlapping IPv4 addresses, you can use the [4via6 subnet routers](https://tailscale.com/docs/features/subnet-routers/4via6-subnets)\r\nfeature to ensure traffic from each node in your tailnet is routed to the correct device.\r\n\r\n![Project Logo](https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed)\r\n\r\nAsk AI\r\n\r\nreCAPTCHA\r\n\r\nRecaptcha requires verification.\r\n\r\nprotected by **reCAPTCHA**\r\n","html":"

Access Azure Windows VMs privately using Tailscale

\n

Last validated: Jan 5, 2026

\n

Microsoft Azure is a cloud service provider offering Linux and Windows virtual machines, to which Tailscale can be used to provide secure connectivity. This topic covers Windows VMs running within Azure. For Linux VMs, refer to Access Azure Linux VMs privately using Tailscale.

\n

Prerequisites

\n

Before you begin this guide, you'll need a Tailscale network set up and\r\nconfigured with at least one existing device. Read our getting started guide\r\nif you need help with this.

\n

Step 1: Set up the Tailscale client for Windows VMs

\n

First, create a Virtual Machine\r\nrunning Windows Datacenter Edition.

\n

If at least one side of a tunnel has \"easy NAT,\" where Tailscale can determine the UDP port\r\nnumber on the far side of the NAT device, then it will make\r\ndirect connections to minimize latency.\r\nWe ensure that the Azure nodes can make direct connections by allowing UDP port 41641 to\r\ningress through the firewall.

\n

In the Networking step while creating the VM choose Advanced for the NIC network security group,\r\nand create a network security policy to allow UDP port 41641 to ingress.

\n

\"Network

\n

For the initial setup it is helpful to also allow RDP and/or SSH. Once Tailscale is installed, public\r\naccess can be removed in favor of going through Tailscale.

\n

Then RDP to the system, and download the latest Windows installer.

\n

It is possible to log in using a browser as described in\r\ninstall Tailscale on Windows, as Windows\r\nDatacenter Edition does include a GUI and web browser.

\n

However this tends not to work as well\r\nfor a Cloud VM where one is likely not already logged in from the browser.

\n

Alternately, one can use a cmd.exe shell to run the Tailscale CLI command and use an auth key:\r\ntailscale up --accept-dns=false --auth-key=tskey-0123456789abcdef

\n

For Azure VMs it is generally best to let Azure handle the DNS configuration,\r\nnot have Tailscale override it, so we added --accept-dns=false.

\n

Step 2: Advertise routes from the VM

\n

For the benefit of the other nodes in the tailnet we'll set up\r\nsplit DNS to allow\r\nuse of the same DNS names as are used inside of Azure. The\r\nAzure DNS server address is 168.63.129.16, which is an anycast address that will go\r\nto the nearest DNS server within Azure.

\n

We'll use cmd.exe to have our VM advertise routes for both the subnet it sits on as well as the\r\nAzure DNS server. For example, if the subnet address range is 10.1.0.0/24, the command would be:

\n
tailscale set --advertise-routes=10.1.0.0/24,168.63.129.16/32 --accept-dns=false\n
\n

Step 3: Add Azure DNS for your tailnet

\n

In the DNS page of the admin console we add a nameserver\r\nrestricted to the internal.cloudapp.net domain, pointing to the Azure DNS server which we\r\nmade available through our VM.

\n

\"Adding

\n

Now the same hostnames which work between nodes running within Azure will also be available\r\nto all nodes on our tailnet.

\n

Step 4: Remove public SSH access

\n

As we can now SSH to the system over the private Tailscale network, there is no reason to leave\r\nthe SSH port open on a public IP address. In the Settings > Network tab select the ingress\r\nrule for \"SSH\" and delete it.

\n

\"Disable

\n

4via6 subnet routers

\n

If your network has subnets with overlapping IPv4 addresses, you can use the 4via6 subnet routers\r\nfeature to ensure traffic from each node in your tailnet is routed to the correct device.

\n

\"Project

\n

Ask AI

\n

reCAPTCHA

\n

Recaptcha requires verification.

\n

protected by reCAPTCHA

\n"}