# Tailscale > **Source:** --- # Getting Started with Tailscale **Source:** https://tailscale.com/kb/1016/start-using --- Install Tailscale on macOSThe current version of the Tailscale client requires macOS 12.0 (Monterey) or later. Download and install the Tailscale client using one of the following options: Standalone variant from Tailscale's package server (recommended). Mac App Store variant. The Tailscale client is free to download, but downloading any app from the Mac App Store may require an Apple ID with a valid credit card attached. Our open source variant from our GitHub repository. Follow the Tailscale onboarding flow, which will guide you to install the Tailscale VPN configuration. Sign up with your SSO identity provider. For more information about the different variant options, refer to Three ways to run Tailscale on macOS. MDM deployments You can use configuration profiles and user defaults to personalize your setup of Tailscale for macOS programmatically. This can help you deploy Tailscale using solutions like MDM. Troubleshooting For common macOS issues and suggestions to help resolve them, refer to the Troubleshooting guide. --- # Tailscale Quickstart Guide **Source:** https://tailscale.com/kb/1017/install --- ## Setting Up Your Tailnet ### Create a Tailnet 1. Visit tailscale.com and select **Get Started**, or download the client and sign up via login.tailscale.com 2. Authenticate using a supported SSO identity provider 3. Choose between **Business use** or **Personal use** 4. Install the client on your first device using your credentials 5. Add a second device by selecting its OS and sharing the installation link 6. Access the admin console to manage your network **Plan Details:** Custom domain signups qualify for a 14-day Enterprise trial. Public email addresses like @gmail.com enroll in the free Personal plan, which includes three users and most Enterprise features. ### Device Management Devices receive automatically generated names based on their OS hostname. You can rename them through the **Machines** page for better organization. MagicDNS is enabled by default, allowing you to "communicate with devices across your tailnet easier" using device names instead of IP addresses. ### Adding Users **Team members** with matching custom domain emails can log in automatically. **External users** receive email invites or shareable links, then authenticate via SSO providers. ## Advanced Features - **Exit Nodes:** Route traffic through designated tailnet devices for privacy - **Subnet Routers:** Access devices without Tailscale clients installed (like printers) - **Access Control:** Define custom permissions using ACLs and grants - **Monitoring:** Track network traffic, client activity, and SSH sessions ## Use Case Examples - Developers can deploy Kubernetes/Docker, use Tailscale Serve/Funnel, and share prototypes - IT admins can manage SSH, integrate cloud platforms, and automate via API - Personal users can stream media, implement ad blocking, and play Minecraft privately ## Support Resources Visit tailscale.com/contact/support for troubleshooting guides, production best practices, security hardening, and firewall integration assistance. --- # Installation on Windows **Source:** https://tailscale.com/kb/1018/install-windows --- Docs›How-to Guides›Manage Access›Manage access control›Manage ACLsManage permissions using ACLsTailscale now secures access to resources using grants, a next-generation access control policy syntax. Grants provide all original ACL functionality plus additional capabilities.ACLs will continue to work indefinitely; Tailscale will not remove support for this first-generation syntax from the product. However, Tailscale recommends migrating to grants and using grants for all new tailnet policy file configurations because ACLs will not receive any new features. ACLs are available on all plans, but certain functionality might be restricted on some plans. Tailscale's access control methodology follows the least privilege and zero trust principles. There are two ways to define access controls for your tailnet: access control lists (ACLs) and grants. Both methods follow a deny-by-default principle and are defined in the tailnet policy file using a declarative huJSON syntax. ACLs represent the traditional network layer approach to managing access within your tailnet, where you define a set of devices or users who can access ports on other devices. Each ACL you create must define a source and a destination. They let you precisely define access controls for users and devices on your Tailscale network (known as a tailnet). { "acls": [ { "action": "accept", "src": [ ], // These sources (devices or users) "dst": [ : ], // can access these destination devices on their defined ports } ] } You can use the visual policy editor to manage your tailnet policy file. Refer to the visual editor reference for guidance on using the visual editor. When you first create your tailnet, the default tailnet policy file enables communication between all devices within the tailnet. You can modify your policy file (including editing ACLs) to fit your needs. ACLs are deny-by-default, directional, locally enforced, and don't affect local network traffic. Deny-by-default. Using a default deny policy prevents communication between devices without explicit access to each other. However, in the absence of an acls section in the tailnet policy file, Tailscale applies the default allow all policy. Directional. Allowing a source to connect to a destination doesn't mean the destination can connect to the source (unless a policy explicitly enables it). Locally enforced. A device enforces incoming connections based on the access rules distributed to all devices in your tailnet. Rule enforcement happens on each device directly, without further involvement from Tailscale's coordination server. ACLs do not affect what a device can or cannot access on its local network. For more information about Tailscale's approach to access control, refer to RBAC like it was meant to be. If you don't define any access control policies, Tailscale applies the default allow all ACL policy. To deny all traffic, use an empty object for the acls section in your tailnet policy file. Edit ACLs You can edit your tailnet's access rules by using the Access controls page of the admin console, GitOps for Tailscale ACLs, or the Tailscale API. Refer to Editing ACLs for more information. Refer to tailnet policy file syntax to learn about creating access control policies or the sample ACLs for examples of common policies. Availability by plan ACLs are available on all plans, but certain functionality might be restricted on some plans. AvailabilityOn all plansOn the Personal, Personal Plus, Premium, and Enterprise plansAccess rules for...AnyTailscale IPSubnet CIDR RangeAutogroupsTagsHostsIP setsAnyTailscale IPSubnet CIDR RangeAutogroupsGroupsUsersTagsHostsIP setsAccess rules specifying...PortsProtocolsACL sections for...aclhoststeststagOwnersautoApproversnodeAttrspostures with default device posture attributes onlyipsetsaclgroupshoststeststagOwnersautoApproversssh for Tailscale SSHnodeAttrs for Tailscale Funnelpostures with default, custom, and third-party attributes (Personal, Personal Plus, and Enterprise plans only)ipsets --- # Key Expiry in Tailscale **Source:** https://tailscale.com/kb/1028/key-expiry --- ## Overview Tailscale implements periodic reauthentication as a security measure. The default expiration period is 180 days for newly created domains. When keys expire, connections from that endpoint stop functioning. ## Managing Key Expiry ### Disabling Expiry Users can disable key expiration on specific devices through the admin console's Machines page by selecting the menu and choosing **Disable Key Expiry**. This option suits trusted servers, subnet routers, and remote devices that are difficult to access. ### Enabling Expiry To re-enable expiration, users follow the same process in the admin console and select **Enable Key Expiry**. ## Renewing Expired Keys For devices with the Tailscale CLI, running `tailscale up --force-reauth` renews expired keys. However, this command may temporarily disconnect the device—a concern for remote systems accessed via SSH or RDP. When a device becomes inaccessible due to key expiration, administrators can temporarily extend the key's lifetime by 30 minutes through the admin console. This window allows the device owner to reauthenticate or disable key expiry entirely. ## Custom Settings Administrators can configure custom authentication periods between 1 and 180 days via the Device Management settings. Changes apply to newly logged-in devices; existing sessions remain unaffected until the next login. ## Tagged Devices Note Tagged devices have key expiry disabled by default upon initial authentication. --- # Installation on Linux **Source:** https://tailscale.com/kb/1054/install-linux --- Docs›How-to Guides›Route Traffic›Use DNSDNS in TailscaleManaging DNS is available for all plans. Tailscale provides each device on your Tailscale network (known as a tailnet) with a unique IP address that stays the same no matter where your devices are. However, IP addresses aren't very memorable, and can be unwieldy to work with. You can map Tailscale IP addresses to human-readable names using DNS. Manage DNS in Tailscale Clients must be configured to use Tailscale DNS settings for the settings on this page to take effect. You can manage DNS for your tailnet using MagicDNS, your tailnet DNS settings, or public DNS records. You can also use the tailscale dns command. MagicDNS You can leverage Tailscale's MagicDNS feature, which is enabled by default, to automatically assign DNS names for devices in your tailnet. The MagicDNS setting determines whether your tailnet uses MagicDNS to automatically assign DNS names to devices in your tailnet. MagicDNS is optional and not required to use other DNS settings. It's not possible to add arbitrary records to MagicDNS. Subscribe to or comment on this GitHub issue for updates. Read more about MagicDNS → Tailscale DNS settings You can manage the DNS settings for your tailnet from the DNS page of the admin console. This includes settings for MagicDNS, nameservers, and search domains. Nameservers Nameservers are the IPv4 or IPv6 addresses of the DNS servers you want devices to use when connected to your tailnet. You can use public nameservers or private name servers that include mappings for devices in your private network. There are two types of nameservers: restricted nameservers and global nameservers. Restricted nameservers A restricted nameserver only applies to DNS queries matching a specific search domain. Using a restricted nameserver is also known as split DNS. An example of a split DNS scenario would be if you configure 1.1.1.1 as a nameserver for the domain example.com. This tells devices in your tailnet to only use the 1.1.1.1 name server to look up DNS queries that match \*.example.com (such as foo.example.com and bar.example.com). Global nameservers A global nameserver handles DNS queries for any domain. You can use a public DNS nameserver or run your own that to include additional DNS mappings. When you use a public global nameserver, such as Cloudflare or Google, Tailscale automatically uses DNS-over-HTTPS (DoH) to ensure your DNS queries are encrypted before traversing the internet. Some public global DNS nameservers include: Quad9: 9.9.9.9, 149.112.112.112, 2620:fe::fe, and 2620:fe::9. Google: 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, and 2001:4860:4860::8844. Cloudflare: 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111, and 2606:4700:4700::1001. You can also set a personalized DNS nameserver, such as NextDNS or Control D, as your global nameserver. These nameservers are available when you add a nameserver using the DNS page of the admin console. Tailscale considers each global DNS nameserver's list of addresses as one entity. For example, if you add one of Google's nameservers, Tailscale automatically includes all of Google's nameserver addresses. This is true whether you add the addresses manually or through the DNS page of the admin console. It's best practice to use more than one global nameserver (which can be from the same provider) to ensure redundancy. However, keep in mind that using multiple global nameservers can bypass explicit content restrictions if they aren't the same across all the nameservers. By default, your tailnet's devices use their local DNS settings for all queries. To force clients to always use the nameservers you define, you can enable the Override DNS servers toggle. Unless your nameservers are public, or using Tailscale IP addresses, you probably need to configure subnet routing to allow your devices to reach the private DNS servers. Nameservers and exit nodes By default, when you configure a device to use an exit node, the device also uses the exit node as a DNS resolver for all domains, regardless of configuration of global and restricted (split DNS) nameservers. You can override this behavior per nameserver through the admin console by configuring the nameserver to be included when devices are using an exit node. To include a nameserver in DNS resolution for devices using an exit node: Go to the DNS of the admin console. Locate the Nameservers section, then select the three dots next to the nameserver to enable. This opens the Edit nameserver options. Enable the Use with exit node setting. Select Save. You can also enable this setting when adding a nameserver through the Add nameserver dialog. Search domains Only devices running Tailscale v1.34 or later can use search domains. Search domains provide a convenient way for users to access local network resources without having to specify the full domain path every time they connect to a resource. A user can specify a list of domain suffixes that are automatically appended to any domain name that is not a fully qualified domain name (FQDN). For example, if a tailnet has example.com and test.com configured as search domains, and a user enters the phrase server, Tailscale uses the phrase to search for server.example.com against the tailnet's configured nameservers (such as 8.8.8.8 or 1.1.1.1). If no match is returned, it searches for server.test.com against the tailnet's configured nameservers. When MagicDNS is enabled, it is always the first domain in the Search Domains list. This is not configurable by a user. You can add, reorder, modify, and remove your search domains. Public DNS records If you prefer not to manage DNS settings through the admin console, you can instead publish records on your public-facing DNS server if you have one. The DNS names can be looked up (converted to a private IP address) by anyone on the internet, but because Tailscale IP addresses are only accessible to users of your network, this is relatively harmless. Almost every organization already has a public DNS server for routing email and publishing a website, so this is easier than setting up an internal private DNS server. Tailscale does not offer a DNS server, so you need to use one you run yourself or one offered by your cloud, domain host, or DNS provider. Public DNS names might take a while to propagate after you add them. Test DNS configurations Traditionally, network admins use tools like nslookup to review DNS responses for various domains. However, on some platforms, nslookup doesn't use DNS information provided by the operating system, and returns incorrect results. You'll likely notice this issue when using split DNS or MagicDNS, which rely on advanced DNS features. To test DNS settings on different platforms, Tailscale recommends the following approaches: macOSWindowsLinuxUse the native dscacheutil command:dscacheutil -q host -a name For example, searching for the IP address for a MagicDNS hostname returns:$ dscacheutil -q host -a name my-server name: my-server.example.ts.net ip\_address: 100.15.193.72 Override DNS servers By default, devices in your tailnet prefer their local DNS settings and only use the tailnet's DNS servers when needed. However, you might want to prevent devices in your tailnet from using their local DNS settings. For example, you might want to: Ensure devices have access to private DNS records. Prevent devices from using untrusted nameservers. Require all traffic to go through a specific DNS server that filters traffic. Tailscale lets you force any device in your tailnet to use your tailnet DNS settings instead of its local DNS settings. To force tailnet devices to use the tailnet-defined DNS settings, enable Override DNS servers. When enabled, devices connected to your tailnet ignore their local DNS settings and always use the global nameservers defined for the tailnet. To override DNS server settings: Go to the DNS page of the admin console. Under Global nameservers, enable Override DNS servers. Make sure all devices in your tailnet have access to your global nameservers before you force them to use the tailnet DNS settings. If an ACL or grant prevents a device from accessing the global nameserver for the tailnet, the device won't be able to resolve DNS queries. The order of DNS resolvers You might expect to be able to give an operating system a list of DNS nameservers in order, and that operating system will try each of those nameservers in sequence to find a given domain. However, as increasingly more systems and software applications require a connection to the internet to function, even small delays or rare hiccups in DNS lookup can result in a degraded user experience. In response, many modern operating systems have adopted more complicated rules for how to optimize response time when multiple DNS nameservers are available. For example, operating systems might: Query nameservers in order, with small delays in between each attempt. Query all nameservers in parallel. Change the order of nameservers based on past performance. Change the order of nameservers based on known geographic proximity. Load balance queries between nameservers. Because each operating system handles resolver ordering a little differently, Tailscale cannot guarantee that the DNS resolvers you add to the DNS page of the admin console will be queried in the exact order that you've specified. Depending on your DNS settings and your operating system, Tailscale either proxies all DNS requests (in which case Tailscale queries all nameservers in parallel and uses the quickest response) or defers to the operating system. If you need nameservers to be in a specific order because you expect one of them (such as a private DNS service you run) to have different responses than the others. In that case, you're probably better off using the split DNS feature or setting up conditional forwarding on your private DNS service and only using that resolver in your settings. --- # Three Ways to Run Tailscale on macOS **Source:** https://tailscale.com/kb/1065/macos-variants --- ## Overview Tailscale requires macOS 12.0 (Monterey) or later. The application offers three installation variants, each with distinct features and trade-offs for different use cases. ## Installation Options ### 1. Standalone Variant (Recommended) The Standalone variant uses Apple's system extensions framework, introduced in macOS 10.15. This approach provides: - **No Apple ID required** for installation - **Faster security updates** without App Store review delays - **Conflict detection** for third-party VPN tools - Access to more features than App Store limitations allow - Direct installation from Tailscale's package server ### 2. Mac App Store Variant Available through the official Mac App Store, this option features: - **Easy setup** for users already in the Apple ecosystem - **Sandboxed operation** for enhanced isolation - **Apple ID requirement** for installation and updates - Notable limitation: incompatibility with Screen Time web filter - Restricted functionality due to App Sandbox constraints ### 3. Open Source CLI Variant (tailscaled) The command-line only distribution offers: - **No GUI required** — full management via terminal commands - **Open source code** available on GitHub - **Recommended only for experienced administrators** managing unattended installations - Limited Taildrop support and no exit node usage capability ## Comparison Summary | Feature | App Store | Standalone | CLI (tailscaled) | |---------|-----------|-----------|------------------| | **GUI** | Yes | Yes | No | | **Apple ID Required** | Yes | No | No | | **Auto-Updates** | App Store managed | In-app | Manual | | **Screen Time Compatible** | No | Yes | Yes | | **MDM Support** | Yes | Yes | No | | **Open Source** | No | No | Yes | ## Recommendation Begin with the Standalone variant unless you specifically need App Store deployment. Install the Mac App Store version only if Standalone installation isn't feasible or your deployment strategy requires it. **Warning:** Never run both Standalone and App Store variants simultaneously on the same machine, as this prevents the extension from launching properly. --- # Custom DERP Servers **Source:** https://tailscale.com/kb/1069/custom-derp --- Docs›Start›Install Tailscale›Uninstall TailscaleUninstall TailscaleHere's how to uninstall Tailscale from your device, or completely reset Tailscale for debugging purposes. WindowsmacOS (App Store)macOS (Standalone)iOStvOSAndroidLinuxSynologyTailscale for Windows can be uninstalled like any Windows app, by using the Windows Control Panel. Go to Settings > Apps, find Tailscale, and press the Uninstall button.If you'd like to completely delete Tailscale, destroying any state or local information, you can also remove the files at the following paths:C:\ProgramData\Tailscale C:\Users\%USERNAME%\AppData\Local\Tailscale C:\Windows\System32\config\systemprofile\AppData\Local\Tailscale The path under System32 was only used in older versions of the Tailscale client and may not be present on your system.After uninstalling Tailscale, if you install Tailscale on a device again at a later time, it will have a new IP address. --- # Tailscale CLI Documentation **Source:** https://tailscale.com/kb/1080/cli --- ## Overview Tailscale includes a built-in command-line interface for managing devices within a Tailscale network (tailnet). The CLI is available across all pricing plans and supports tab-completion for enhanced usability. ## Getting Started ### Platform-Specific Access **Linux:** The `tailscale` binary is typically in your `$PATH`: ```shell tailscale ``` **macOS & Windows:** Access varies by installation method. Refer to platform-specific documentation. **Mobile:** No CLI support exists for iOS or Android. ### Tab Completion Enable shell completion with: ```shell tailscale completion [--flags] [--descs] ``` Supported shells: Bash, Zsh, Fish, PowerShell ## Essential Commands ### Connection Management **`tailscale up`** - Connect to Tailscale with optional authentication ```shell tailscale up [flags] ``` Key flags include `--accept-routes`, `--advertise-exit-node`, `--shields-up`, and `--ssh` **`tailscale down`** - Disconnect from Tailscale ```shell tailscale down ``` **`tailscale login`** - Authenticate and join your tailnet ```shell tailscale login [flags] ``` **`tailscale logout`** - Sign out and invalidate credentials ### Network Diagnostics **`tailscale status`** - View connection status to network peers ```shell tailscale status [--json] ``` Returns peer information including IP addresses, machine names, connection types, and traffic metrics. **`tailscale ping`** - Test connectivity over Tailscale ```shell tailscale ping ``` **`tailscale netcheck`** - Report physical network conditions and relay latencies **`tailscale whois`** - Identify machines and users by Tailscale IP ```shell tailscale whois ip[:port] [--json] ``` ### File & Service Sharing **`tailscale file`** - Transfer files via Taildrop ```shell tailscale file cp : tailscale file get ``` **`tailscale serve`** - Share local services within the tailnet ```shell tailscale serve ``` **`tailscale funnel`** - Expose local services to the internet ```shell tailscale funnel ``` ### Advanced Configuration **`tailscale ssh`** - Establish secure SSH sessions ```shell tailscale ssh ``` **`tailscale set`** - Modify specific preferences without full reconnection ```shell tailscale set [flags] ``` **`tailscale cert`** - Generate Let's Encrypt certificates ```shell tailscale cert hostname.tails-scales.ts.net ``` **`tailscale lock`** - Manage Tailnet Lock security features ```shell tailscale lock ``` ### System Information **`tailscale version`** - Display Tailscale version details ```shell tailscale version [flags] ``` **`tailscale ip`** - Retrieve device Tailscale IP address ```shell tailscale ip [flags] [] ``` **`tailscale bugreport`** - Generate diagnostic data for troubleshooting ## Additional Commands - **`dns`** - Configure Tailscale DNS settings - **`drive`** - Manage Taildrive shares - **`configure`** - Set up resources (Kubernetes, VPN, Synology, etc.) - **`exit-node`** - List and manage exit nodes - **`metrics`** - Expose client metrics - **`nc`** - Connect to remote ports - **`switch`** - Manage multiple accounts - **`update`** - Update Tailscale client version - **`web`** - Start web interface server - **`syspolicy`** - Inspect system policy settings - **`appc-routes`** - View app connector route status ## Common Flags All commands accept: - `--socket=` - Specify tailscaled socket location - `--help` - Display command documentation --- # DNS and MagicDNS **Source:** https://tailscale.com/kb/1082/dns --- What firewall ports should I open to use Tailscale?Most of the time, you don't need to open any firewall ports for Tailscale. Tailscale uses various NAT traversal techniques to safely connect to other Tailscale nodes without manual intervention—it "just works." However, when both devices are on difficult networks Tailscale may not be able to connect devices peer-to-peer. You'll still be able to send and receive traffic, thanks to our secure relays (DERP), but the relayed connection won't be as fast as a peer-to-peer one. In these cases, you may consider opening a firewall port to help Tailscale connect peer-to-peer: Let your internal devices start TCP connections to \*:443. Connections to the control server and other backend systems and data connections to the DERP relays use HTTPS on port 443. The set of DERP relays, in particular, grows over time. We recommend \*:443 because attempting to enumerate the set of allowed destinations is almost certain to break your connectivity in the future in ways which won't immediately resemble a firewall issue. Nodes might lose all contact, or might only partially lose contact between what will appear to be random pairs of devices because one of them is blocked from communicating with a specific DERP. Let your internal devices start UDP from :41641 to \*:\*. Direct WireGuard tunnels use UDP with source port 41641. We recommend \*:\* because you cannot possibly predict every guest Wi-fi, coffee shop, LTE provider, or hotel network that your users may be using. Let your internal devices start UDP to \*:3478. The STUN protocol lets a machine behind NAT ask a machine on the open internet what IP address it sees, allowing the machine behind NAT to figure out its public IP address. STUN also reports the port number seen, which lets tailscaled to determine if it is behind "easy NAT" (source port maps to the same external port for all destinations) or "hard NAT" (port number varies per destination). tailscaled only sends STUN to DERP servers, but the set of DERP servers expands over time so we recommend \*:3478 in the rule. Let your internal devices start HTTP (TCP) connections to \*:80. For captive portal detection and notifications, Tailscale attempts to contact a set of relay servers that are known to accept incoming connections on TCP port 80. The client executes an unencrypted HTTP request reaching out to a /generate\_204 endpoint on the relay server. This endpoint is expected to return an HTTP response with a 204 status code. It is not mandatory to allow these connections, and you can safely drop them in your firewall rules, resulting in a timeout. However, captive portal detection won't function properly if disabled. In July of 2025, the domains login.tailscale.com and controlplane.tailscale.com began resolving to static IP address ranges registered to Tailscale.We recommend configuring firewalls using domain names rather than hardcoding IP addresses. However, if IP-based rules are required, the following ranges should be explicitly allowed: IPv4: 192.200.0.0/24 IPv6: 2606:B740:49::/48 Scheduled for November of 2025, the domain log.tailscale.com will resolve to static IP address ranges registered to Tailscale.We recommend configuring firewalls using domain names rather than hardcoding IP addresses. However, if IP-based rules are required, the following ranges should be explicitly allowed: IPv4: 199.165.136.0/24 IPv6: 2606:B740:1::/48 How can I tell if my devices are using a relay? Relays are used per-device-pair. To check if a device is talking to another device over a relay, run tailscale status (docs) from either device. The tailscale status command will return a table of results for every device it can access over Tailscale. For example: 1 2 3 4 5 100.1.2.3 device-a alice@ linux active; direct , tx 1116 rx 1124 100.4.5.6 device-b bob@ macOS active; relay , tx 1351 rx 4262 100.7.8.9 device-c charlie@ windows idle; tx 1214 rx 50 100.0.1.2 device-d diane@ iOS - If a device is active in the tailnet, for the connection status (column 5) will contain "direct" for peer-to-peer connections, along with the IP address used to connect, or "relay" for connections using DERP, along with a city code, such as nyc or fra, for the respective location. My devices are using a relay. What can I do to help them connect peer-to-peer? If two of your devices are on difficult networks, allowing connections to UDP port 41641 on one of them may help Tailscale make a peer-to-peer connection, rather than falling back to a relay. On Ubuntu, for example, you can do this with the built-in ufw command by running: sudo ufw allow 41641/udp For more information on NAT traversal, our blog post How NAT Traversal Works shares all the details. What if I really, really want to specify the hostnames that Tailscale uses to operate its service? In situations where this is unavoidable you can allow exceptions for a list of fully qualified domain names (FQDNs). We strongly recommend automating the process of keeping the allowed hostnames in sync to ensure you minimize disruption from changes made to Tailscale's infrastructure. The list of coordination servers (required for authentication, key exchange, firewall updates, and so on) is likely to change, but infrequently: console.tailscale.com controlplane.tailscale.com log.tailscale.com login.tailscale.com Additionally, the DERP relay servers (which will definitely change from time to time) are accessed at TCP port 443. DERP servers are named as derpN where 1 <= \*N\* <= 28 as of August 2025 (the upper range for N is likely to increase). Tailscale creates a derpN-all entry with multiple A (IPv4) and AAAA (IPv6) records, one record per DERP server in the region. So your allowlist of DERP DNS entries would look like: derp1-all.tailscale.com derp2-all.tailscale.com ... derp28-all.tailscale.com If you have removed Tailscale's DERP regions from your DERP map, you can skip the DNS entries for the removed regions. DERP servers are frequently added or changed, depending on user locations, to optimally serve Tailscale customers. After a DERP server is added or changed, Tailscale updates DNS entries about 15 minutes later. To access the up-to-date list of Tailscale DERP servers, visit the DERP map. Alternatively, you can run this command: curl https://login.tailscale.com/derpmap/default | jq Once you've identified the servers, add the relevant A and AAAA records to your firewall configuration. If your firewall is able to accept a DNS entry to add L3 tailnet policy file entries, will add all the A and AAAA records it finds, and will periodically refresh its tailnet policy file entries by re-fetching from DNS, you can configure the derpN-all.tailscale.com entries and then not need to constantly update the list of DERP servers. --- # Authentication Keys **Source:** https://tailscale.com/kb/1085/auth-keys --- Docs›How-to Guides›Set Up Servers›Use auth keysAuth keysAuth keys are available for all plans. Pre-authentication keys (called auth keys) let you register new nodes without needing to sign in using a web browser. This is most useful when spinning up containers, IoT devices, or using infrastructure-as-code systems like Terraform. An auth key authenticates a device as the user who generated the key. That is, if Alice generates an auth key, and uses it to add a server to her tailnet, then that device is authenticated with Alice's identity. Think of it as logging into a device. However, if you use tags with an auth key, after a device logs in as the user who generated the auth key, the device assumes the identity of the auth key's tags. As an alternative to directly creating auth keys, consider using an OAuth client. You can use an OAuth client and the Tailscale API to programmatically create auth keys. Types of auth keys Auth keys can either be: One-off, for one-time use. They can only be used to connect a device or server one time. This is meant for situations where you can't authenticate on the device yourself, so using a key is more practical. For example, a cloud server might use a one-off key to connect. Reusable, for multiple uses. They can be used to connect multiple devices. For example, multiple instances of an on-premises database might use a reusable key to connect. Be very careful with reusable keys! These can be very dangerous if stolen. They're best kept in a key vault product specially designed for the purpose. Key expiry An auth key automatically expires after the number of days you specified when you generated the key. You can choose the number of days, between 1 and 90 inclusive, for the key expiry. If you don't specify an expiry time, the auth key will expire after the maximum of 90 days. If you want to continue using an auth key after it expires, you need to generate a new key. You can enable or disable key expiry on a device by using the Machines page of the admin console and by using the Update device key method in the Tailscale API. If an auth key expires, any device authorized by it remains authorized until its node key expires. Each device generates a node key when you log in to Tailscale and uses it to identify itself to the tailnet. By default, node keys automatically expire every 180 days. You can change the default node key expiry from the Key Expiry section of the Device management page of the admin console. Learn more about key management. Key expiry for tagged devices Key expiry for tagged devices is disabled by default. If you change the tags on the device through the admin console, Tailscale CLI, or Tailscale API, the device's key expiry will not change unless you re-authenticate. That is, if it is enabled, it stays enabled; and if it is disabled, it stays disabled. After you re-authenticate, the device's key expiry will be disabled. You can find recently revoked or expired keys on the Keys page of the admin console. Generate an auth key You must be an Owner, Admin, IT admin, or Network admin of a tailnet to generate a key. To generate an auth key: Open the Keys page of the admin console. Select Generate auth key. Fill out the form fields to specify characteristics about the auth key, such as the description, whether its reusable, when it expires, and device settings. The device settings section lets you set special characteristic for the auth key: Enable Ephemeral to automatically remove the auth key after the device goes offline. Enable Pre-approved to automatically authorize a device if you have device approval enabled for your tailnet. Enable Tags to automatically tag devices that use the auth key. Select Generate key. Register a node with the auth key When you register a node, use the --auth-key option in the tailscale up command to supply the key and bypass interactive login: sudo tailscale up --auth-key=tskey-abcdef1432341818 Tailscale-generated auth keys are case-sensitive. Revoke an auth key You must be an Owner, Admin, IT admin, or Network admin of a tailnet to revoke a key. And you can revoke only your own keys. Tailscale automatically revokes one-off keys after they are used. To revoke a key: Open the Keys page of the admin console. Locate the key in the table at the bottom, and select Revoke. Revoking a key does not deauthorize nodes using the key. To deauthorize a node, delete it from the Machines page. Best practices Depending on what devices you're authenticating, consider using an auth key that is: Ephemeral, for authenticating ephemeral nodes as part of short-lived workloads. Because node keys do not persist when a workload restarts, they reconnect as a different node. Tailscale automatically removes inactive nodes. For example, containers or Lambda functions should use an ephemeral key to connect. Pre-approved, for servers. If your tailnet has device approval enabled, this lets you add a device to your tailnet without further authorization. For example, shared devices, such as servers, should use a pre-approved auth key to connect in a network with device approval. Pre-signed, for nodes whose auth keys are signed locally on a signing node, which applies to tailnets with Tailnet Lock enabled. You can make an auth key (created by any means) pre-signed only by using the tailscale lock sign CLI command. Tagged, for servers. You can automatically apply a tag to a device by including the tag in the auth key. Access control policies restricting the device's permissions based on the tag apply after provisioning the device. For example, shared devices, such as servers, should use a tagged auth key to connect. --- # Access Azure Windows VMs Privately Using Tailscale **Source:** https://tailscale.com/kb/1143/headscale --- ## Overview This guide demonstrates how to securely connect Windows virtual machines running on Microsoft Azure to a Tailscale network for private access and connectivity. ## Prerequisites You'll need an active Tailscale network with at least one device already configured. Reference the official getting started materials if you're new to Tailscale setup. ## Setup Steps ### Step 1: Configure the Windows VM Create a Windows Datacenter Edition virtual machine in Azure. During the networking configuration phase: - Select **Advanced** for the network security group - Create a policy permitting UDP port 41641 ingress to enable direct connections and reduce latency - Consider temporarily allowing RDP and SSH for initial setup Download the Windows installer and either: - Use browser-based login (if the system has GUI access), or - Execute the CLI command via `cmd.exe` with an authentication key, specifying `--accept-dns=false` to preserve Azure's DNS configuration ### Step 2: Configure Route Advertisement From `cmd.exe`, advertise both your subnet and Azure's DNS server: ```shell tailscale set --advertise-routes=10.1.0.0/24,168.63.129.16/32 --accept-dns=false ``` (Replace the subnet address with your actual range) ### Step 3: Set Up Split DNS In the admin console's DNS section, add the Azure DNS server as a resolver "restricted to the `internal.cloudapp.net` domain" to make internal hostnames accessible across your Tailscale network. ### Step 4: Remove Public Access Once connected through Tailscale, delete the public SSH ingress rule from your network security settings. ## Advanced: 4via6 Subnet Routers For networks with overlapping IPv4 address ranges, implement 4via6 subnet routing to direct traffic appropriately. --- # Tailscale SSH Documentation **Source:** https://tailscale.com/kb/1193/tailscaled-macos --- ## Overview Tailscale SSH enables centralized authentication and authorization for SSH connections within your tailnet. Rather than managing individual SSH keys, Tailscale leverages its existing WireGuard infrastructure and identity system. ## Key Capabilities ### Authentication & Encryption - Tailscale manages authentication using node keys distributed across your network - Connections receive dual encryption: WireGuard at the network layer plus SSH protocol encryption - "SSH as normal" workflow—no new binaries or configurations required ### Access Control Tailscale enforces SSH policies through its access control system, allowing administrators to: - Restrict SSH access by user, group, or device tags - Require periodic re-authentication via check mode - Revoke access instantly by updating policies ### Session Management - Optional check mode requires users to re-authenticate for high-risk connections - Default check period is 12 hours; customizable down to 1 minute - Sessions terminate if access policies are modified ## Configuration Steps ### Prerequisites Server support is limited to: - Linux systems - macOS (open source `tailscaled` variant only) Clients may run any Tailscale-supported platform. ### Setup Process 1. **Enable SSH on destination host:** ``` tailscale set --ssh ``` This generates cryptographic material and configures port 22 interception. 2. **Configure access policies** via the admin console's Access Controls section to define: - Network connectivity rules (any connections between source and destination) - SSH-specific rules (users and destinations permitted for SSH) 3. **Connect via hostname:** ``` ssh user@device.tailnet-name.ts.net ``` Or using Tailscale IP addresses (format: 100.x.x.x) ## Policy Structure SSH access rules require: - **Source:** User, group, tag, or autogroup originating the connection - **Destination:** Tagged device or autogroup receiving the connection - **Users:** Host-level usernames allowed (e.g., `autogroup:nonroot`) - **Action:** Either `accept` or `check` (with optional `checkPeriod`) Rules are evaluated by restrictiveness—check policies override accept policies for the same connection. ## Important Limitations - Tailscale SSH only works on Tailscale-connected devices; subnet router devices cannot participate - SSH port cannot be customized from port 22 - Restarting the Tailscale daemon terminates active sessions - Incompatible with Synology and QNAP devices - Any OS user on the client can initiate connections (lacks traditional SSH key file restrictions) ## Disabling Tailscale SSH To disable on a single device: ``` tailscale set --ssh=false ``` To disable network-wide, remove SSH rules from access control policies and disable SSH on all hosts.