Documentation

• Start
  • Quickstart
  • Install Tailscale
  • Quick guides
  • OpenVPN migration guide
  • Legacy VPN migration guide
  • Set up an identity provider
  • What is Tailscale?
• How-to Guides
  • Manage Access
    • Manage access control
    • Manage just-in-time access
    • Manage devices
    • Manage users
    • Tailnet Lock
  • Route Traffic
    • Set up a subnet router
    • Set up an exit node
    • Set up an app connector
    • Use DNS
    • Set up MagicDNS
    • Set up high availability
  • Set Up Servers
    • Set up a server
    • Use tags
    • Install Tailscale with cloud-init
    • Use auth keys
    • Automate key expiry
    • Use Tailscale SSH
    • Set up HTTPS certificates
    • Run an ephemeral node
    • Run unattended
  • Access & Share Services
    • Tailscale services
    • Endpoint collection
    • Share nodes
    • Use Taildrop
  • Share a web server
    • Tailscale Funnel
    • Tailscale Serve
  • Solutions
    • Secure traffic with Apple TV
    • Secure GitHub Actions runners
    • Block ads with a Raspberry Pi
    • Access remote desktops with Windows RDP
    • Access remote desktops with RustDesk
    • Connect to MongoDB Atlas
    • Code from your iPad
    • Lock down a server
    • Protect production databases
    • Access a PiKVM
    • Secure external services
    • Just-in-time access
    • Automation
• Integrations
  • Cloud servers
  • Containers and virtualization
  • Serverless apps
  • Databases
  • Remote environments
  • Developer tools
  • Firewalls
  • Web servers
  • NAS
• FAQ
• Logging, Streaming, and Events
  • Logging overview
  • Configuration audit logging
  • Network flow logs
  • Log streaming
  • SSH session recording
  • Client metrics
  • Webhooks
• Manage Your Organization
  • Contact preferences
  • Pricing and billing
  • Tailnet name
  • Domain ownership
• Reference
  • Tailnet policy file syntax
    • Grants syntax
    • IP sets
    • Via in grants
  • ACL examples
  • Grant examples
  • CLI
  • API
  • Key prefixes
  • Production best practices
  • Shared responsibility
  • Technical overviews
  • Terminology and concepts
  • Tailscale messages
  • GitHub ↗
• Get Support
  • Troubleshooting
  • Support options
  • Contact support ↗
  • Generate a bug report
• Resources
  • Changelog ↗
  • Comparisons ↗
  • Release stages
  • Security ↗
  • Tailscale Community Projects
  • Versions
  • Use cases
  • Invite only features

You can write Tailscaleaccess control rules such asACLs andgrants in the tailnet policy file, which is expressed inhuman JSON (HuJSON).

The tailnet policy file has the following top-level sections:

Grants

Grants are a new, more powerful approach to access control. They let you do everything you can with ACLs, plus more. When communicating with a destination device, you can grantapplication layer capabilities to a set of devices or users. You can also continue to define traditionalnetwork layer capabilities. For example, you can use a grant rule to give a group of users access to port8443 on a server,and define the files they can edit on that server.

The grants system combines network layer and application layer capabilities into a shared syntax. As a result, it offers enhanced flexibility and fine-grained control over resource access. Each grant only requires a source and a destination. Because Tailscale takes a deny-by-default approach, each grant has an impliedaccept action.

ACLs

Theacls section lists access rules for your tailnet. Each rule grants access from a set of sources to a set of destinations.

Access rules can usegroups andtags to grant access to pre-defined sets of users and assign service role accounts to nodes. Together, groups and tags let you build powerfulrole-based access control (RBAC) policies.

Tailscale automatically translates all ACLs to lower-level rules that allow traffic from a source IP address to a destination IP address and port.

The following example shows an access rule with anaction,src,proto, anddst.

{"action":"accept","src":[ <list-of-sources>],"proto":"tcp",// optional"dst":[ <list-of-destinations>],}

action

Tailscale access rules deny access by default. As a result, the only possibleaction isaccept.accept allows traffic from the source (src) to the destination (dst).

src

Thesrc field specifies a list of sources to which the rule applies. Each element in the list can be one of the following:

You can optionally include thesrcPosture field to further restrictsrc devices to the ones matching a set ofdevice posture conditions.

proto

Theproto field is an optional field you can use to specify the protocol to which the rule applies. Without a protocol, the access rule applies to all TCP and UDP traffic.

You can specifyproto as anIANA IP protocol number1-255 (for example,"16") or one of the supported named aliases.

dst

Thedst field specifies a list of destinations to which the rule applies. Each element in the list specifies ahost and one or moreports in the format<host>:<ports>.

Thehost can be any of the following types:

Theports field can be any of the following types:

Subnet routers and exit nodes

ACLs don't limit the discovery of routes. If a device is asubnet router, you can restrict access to it independently from the subnet. If a device is anexit node, you can restrict access to it independently from its public IP address.

To restrict access to a subnet, ensure that no ACL allows access to those routes. You can enforce this with a test that fails if any rule accidentally allows access. The following example demonstrates a test that fails ifnot-allowed@example.com is allowed access to198.51.100.7:22.

"tests":[{"src":"not-allowed@example.com","accept":["192.0.2.100:22"],// allow access to the tailscale IP"deny":["198.51.100.7:22"],// does not allow access to the subnet}],

Only devices with access toautogroup:internet can use exit nodes. All other devices (without access toautogroup:internet) cannot use exit nodes. You can enforce this with a test that fails if any rule accidentally allows access to a public address. The following example test fails ifnot-allowed@example.com can access198.51.100.8:22.

"tests":[{"src":"not-allowed@example.com","accept":["192.0.2.100:22"],// allow access to the tailscale IP"deny":["198.51.100.8:22"],// does not allow access to a public IP}],

You cannot restrict the use of specific exit nodes using ACLs. Refer toissue #1567 for updates.

Taildrop precedence

Taildrop permits you to share files between devices you're logged in to, even if you use ACLs to restrict access.

Reference users

You can specify users in an access rule's source (src) and destination (dst) fields. To specify a user, use one of the following formats (depending on how the user signs into Tailscale):

You can use groups to reference sets of users. Groups let you define role-based access controls. There are multiple types of groups:

• Auto groups that reference all users with the same property.
• Groups defined in thegroups section of the tailnet policy file as a specific list of users.
• Groups provisioned in the identity provider and synced through user and group provisioning.

Autogroups

Anautogroup is a special group that automatically includes users, destinations, or usernames with the same properties.

The following examplessh rule allows all users Tailscale SSH access to devices they own (as non-root):

"ssh":[{// All users can SSH to their own devices, as non-root"action":"accept","src":["autogroup:member"],"dst":["autogroup:self"],"users":["autogroup:nonroot"]},]

In the default ACL, thessh rule usesautogroup:self for thedst field andautogroup:nonroot in theusers field. If you change thedst field fromautogroup:self to some other destination, such as anACL tag, also consider replacingautogroup:nonroot in theusers field. If you don't removeautogroup:nonroot from theusers field, then anyone permitted by thesrc setting will be able to SSH in as any nonroot user on thedst device.

Domain based autogroups

Some autogroups include a specific domain name. For example,user:*@example.com orlocalpart:*@example.com. These autogroups include users who are both members of the tailnet and whose login is in the autogroup domain. For example, if the tailnetexample.com uses the autogroupuser:*@altostrat.com, this group includes all members of theexample.com tailnet who log in as a user at@altostrat.com (such aslaura@altostrat.com).

The following restrictions apply to the domains used in autogroups:

• The provided domain must not be a known shared domain (such asgmail.com).
• If a tailnet uses domain aliases, you must explicitly specify the aliased domains in the ACL. For example, ifexample.io is aliased toexample.com and you want to include users from bothexample.com andexample.io, use bothuser:*@example.com anduser:*@example.io.
• Although the expressions use the wildcard*, it does not support arbitrary wildcards. For example,user:b*b@example.com will not matchbob@example.com.

Groups

Thegroups section lets you create groups of users, which you can use in access rules (instead of listing users out explicitly). Any change you make to the membership of a group propagates to all the rules that reference that group.

The following example demonstrates creating anengineering group and asales group.

"groups":{"group:engineering":["dave@example.com","laura@example.com",],"group:sales":["brad@example.com","alice@example.com",],},

Every group name must start with the prefixgroup:. Each group member is specified by their full email address, as explained in theusers section above. To avoid the risk of obfuscating group membership, groups cannot contain other groups.

You can add or remove a user's group membership by editing the tailnet policy file, as shown in the examplegroups definition above, and directly from theUsers page of the admin console.

Edit a user's group membership from the Users page

You must be anOwner, Admin, or Network admin to edit a user's group membership from theUsers page.

1. Open theUsers page in the admin console.
2. Find the user by name.
3. Select the menu >Edit group membership.
4. In theEdit group membership dialog:
   1. To add a group, selectAdd to a group, then the group to add.
   2. To remove a group, select theX next to the group to delete.
5. When you finish editing the groups for the user, selectSave.

Synced groups

You can create groups in your identity provider and sync them with Tailscale's access control policies withuser and group provisioning.

You can use the same human-readable group names in your identity provider to refer to groups in your tailnet policy file. The following example shows an access rule that manages access for thesecurity-team group.

{"grants":[{"src":["group:security-team@example.com"],"dst":["tag:logging"],"ip":["*"]}],"tagOwners":{"tag:logging":["group:security-team@example.com"]}}

You can only edit groups defined in the tailnet policy file. You can use groups synced from a System for Cross-domain Identity Management (SCIM) integration or tailnet autogroups, but you cannot edit them.

Reference multiple devices

You can define access rules for sets of devices using tags or hosts. Tags let you define role-based access controls so that different services have different access rules. Hosts let you define controls based on a reference to an IP address.

• Tags reference groups of non-user devices (such as applications or servers). For example, you might have a tag that groups all servers in a particular data center.
• Hosts reference groups of devices by IP address ranges (both on and beyond the tailnet). For example, you can use hosts to address applications with fixed IP addresses that you might be unable to modify.

Tags

Thetags section of the tailnet policy file lets you createtags that group non-human devices. You can then use the tags to select these devices in an ACL.

Hosts

Thehosts section lets you define a human-friendly name for an IP address or CIDR range.

The following example shows two host definitions: one for a single IP address and one for a CIDR range.

"hosts":{"example-host-1":"198.51.100.100","example-network-1":"198.51.100.0/24",},

Postures

Thepostures section lets you define a set ofdevice posture management rules that a device must meet as part of a specific access rule.

The following example shows how to usepostures to select macOS devices runningnode version 1.40 or later.

"postures":{"posture:latestMac":["node:os IN ['macos']","node:tsReleaseTrack == 'stable'","node:tsVersion >= '1.40'",],},

Each posture must start with the prefixposture: followed by a name, a set ofposture attributes, and their allowed values, given as a list of strings.

Refer todevice posture management for more information

Tag owners

ThetagOwners section of the tailnet policy file defines the tags assignable to devices and the list of users allowed to assign each tag.

The following example shows atagOwners definition that:

• Sets theengineering group as the owner of thewebserver tag.
• Setspresident@example.com and thesecurity-admins group as owners of thesecure-server tag.
• Sets theautogroup:member autogroup as the owner of thecorp tag.

"tagOwners":{"tag:webserver":["group:engineering",],"tag:secure-server":["group:security-admins","president@example.com",],"tag:corp":["autogroup:member",],}

Every tag name must start with the prefixtag:. A tag owner can be a user's full login email address (as defined in theusers section above), agroup name, anautogroup, or another tag.

A shorthand notation,[], is available forautogroup:admin. That is, the following are equivalent:

"tag:monitoring":["autogroup:admin",],

"tag:monitoring":[],

The autogroupsautogroup:admin andautogroup:network-admin can assign all tags, so[] implicitly allows onlyautogroup:admin andautogroup:network-admin.

Auto approvers

TheautoApprovers section of the tailnet policy file defines the list of users who can perform specific actions without further approval from the admin console. Some actions in Tailscale require double opt-in: anAdmin must enable them on the device running Tailscale and in the Tailscale admin console. These actions include:

• Advertising a specified set of routes as a subnet router.
• Advertising an exit node.

For routes, this also permits the auto approvers to advertise a subnet of the specified routes.

Tailscale stops advertising a route if one of the following occurs:

• The device is re-authenticated by a different user (who cannot advertise the route or exit node).
• The user who advertised the route is suspended or deleted.

To avoid a scenario where Tailscale stops advertising a route, consider using atag as an auto approver.

The following example shows anautoApprovers definition that automatically approves the192.0.2.0/24 routes foralice@example.com, members of theengineering group, and devices tagged withfoo. It also automatically allows devices tagged withfoo to use an exit node.

"autoApprovers":{"routes":{"192.0.2.0/24":["group:engineering","alice@example.com","tag:foo"],},"exitNode":["tag:bar"],}

The auto approver of a route or exit node can be a user's full login email address (as defined in theusers section above), agroup name, anautogroup or a tag.

Tailscale SSH

Thessh section of the tailnet policy file defines lists of users and devices that can useTailscale SSH (and the SSH users). To allow a connection, the tailnet policy file must contain rules permitting both network access and SSH access:

1. An access rule to allow connections from the source to the destination on port 22.
2. An SSH access rule to allow connections from the source to the destination and the given SSH users. Tailscale SSH uses this to distribute keys to authenticating SSH connections.

The following example shows anssh definition that requires a list of sources, destinations, and SSH users to re-authenticate every 20 hours.

{"action":"check",// "accept" or "check""src":[ <list-of-sources>],"dst":[ <list-of-destinations>],"users":[ <list-of-ssh-users>],"checkPeriod":"20h",// optional, only for check actions. default 12h"acceptEnv":["GIT_EDITOR","GIT_COMMITTER_*","CUSTOM_VAR_V?"]// optional, allowlists environment variables that can be forwarded from clients to the host},

action

Specifies whether to accept the connection or to perform additional checks on it.

• accept accepts connections from users already authenticated in the tailnet.
• check requires users to periodically reauthenticate according to thecheckPeriod.

src

Specifies the source (where a connection originates from). You can only define an access rule's destination (dst) as yourself, a group, a tag, or an autogroup. You cannot use*, other users, IP addresses, or hostnames.

It's impossible to guarantee the ownership of an IP address or hostname when you create an access rule. As a security measure, Tailscale prevents using users, IP addresses, or hostnames in thedst field of access rules to protect against scenarios in which one user can unintentionally access a device that doesn't belong to them. Tailscale also prevents anysrc anddst combinations that allow multiple users to access a single user's device.

dst

Specifies the destination (where the connection goes). The destination can be a tag,autogroup:self (if the source contains only users or groups), or a single named user (if the source contains only the same named user). The reason for these limitations is Tailscale does not let a user start a Tailscale SSH session on a user-owned device, unless the source is a device owned by the same user.

You cannot specify a port for the destination because the only allowed port is22. You cannot specify* as the destination.

users

Specifies the set of allowed usernames on the host. Tailscale only uses user accounts that already exist on the host.

• Specifyautogroup:nonroot to allow any user that is notroot.
• Specifylocalpart:*@<domain> to allow the user on the host whose name matches thelocal-part of the user's login, if and only if the user's login email is in<domain>. Tailscale does not do any special processing on the local-part. For example, if the login isdave+sshuser@example.com, Tailscale will map this to the ssh userdave+sshuser.
• If no user is specified, Tailscale will use the local host's user. That is, if the user is logged in asalice locally, then connects with SSH to another device, Tailscale SSH will try to log in as useralice.

checkPeriod

Whenaction ischeck,checkPeriod specifies the time period for which to allow a connection before requiring a check. You can specify the time in minutes or hours. The time must be at least one minute and at most 168 hours (one week).

• The default check period is 12 hours.
• You can also specifyalways to require a check on every connection. Usingalways might cause unexpected behavior with automation tools that open many SSH connections in quick succession (such asAnsible).

acceptEnv

Specifies the set of allowlisted environment variable names that clients can send to the host usingSendEnv orSetEnv.

Values can contain* and? wildcard characters.* matches zero or more characters and? matches a single character.

acceptEnv examples

Order of evaluation

Tailscale evaluates SSH access rules using the most restrictive policies first:

• Check policies
• Accept policies

For example, if you have an access rule allowing the useralice@example.com to access a resource with anaccept rule, and a rule allowinggroup:devops whichalice@example.com belongs to, to access a resource with acheck rule, then thecheck rule applies.

The only types of connections that are allowed are:

• From a user to their own devices (as any user, includingroot).
• From a user to atagged device (as any user, includingroot).
• From a tagged device to another tagged device (for any tags). An SSH access rule from a tagged device cannot be incheck mode.
• From a user to a tagged device that has beenshared with them, as long as the destination host has Tailscale configured with SSH and the destination's ACL allows the user to connect over SSH.

That is, the broadest policy allowed would be:

{"grants":[{"src":["*"],"dst":["*"],"ip":["*"]}],"ssh":[{"action":"accept","src":["autogroup:member"],"dst":["autogroup:self"],"users":["root","autogroup:nonroot"]},{"action":"accept","src":["autogroup:member"],"dst":["tag:prod"],"users":["root","autogroup:nonroot"]},{"action":"accept","src":["tag:logging"],"dst":["tag:prod"],"users":["root","autogroup:nonroot"]}]}

To allow a user to only SSH to their own devices (as non-root):

{"grants":[{"src":["*"],"dst":["*"],"ip":["*"]}],"ssh":[{"action":"accept","src":["autogroup:member"],"dst":["autogroup:self"],"users":["autogroup:nonroot"]}]}

To allowgroup:sre to access devices in the production environment taggedtag:prod:

{"groups":{"group:sre":["alice@example.com","bob@example.com"]},"grants":[{"src":["group:sre"],"dst":["tag:prod"],"ip":["*"]}],"ssh":[{"action":"accept","src":["group:sre"],"dst":["tag:prod"],"users":["ubuntu","root"]}],"tagOwners":{// users in group:sre can apply the tag tag:prod"tag:prod":["group:sre"]}}

To allow Alice to access devices in the development environment taggedtag:dev that have beenshared with them:

{"ssh":[{"action":"accept","src":["alice@example.com"],"dst":["tag:dev"],"users":["root","alice"]},]}

It might be useful to match host users with login emails. For example, you can allowdave@example.com to authenticate as the host userdave.

To allow any tailnet member in the login domainexample.com to access devices in the production environment that are taggedtag:prod, as a user that matches their login email local-part:

{"grants":[{"src":["user:*@example.com"],"dst":["tag:prod"],"ip":["*"]}],"ssh":[{"action":"accept","src":["user:*@example.com"],"dst":["tag:prod"],"users":["localpart:*@example.com"]}]}

Node attributes

ThenodeAttrs section of the tailnet policy file defines additional attributes that apply to specific devices in your tailnet.

One way you could use node attributes would be to set differentNextDNS configurations for different devices in your tailnet. The following example shows anodeAttrs definition that targetsmy-kid@my-home.com andtag:server with the attributesnextdns:abc123 andnextdns:no-device-info.

"nodeAttrs":[{"target":["my-kid@my-home.com","tag:server"],"attr":["nextdns:abc123","nextdns:no-device-info",],},],

target

Specifies which nodes (devices) the attributes apply to. You can select the devices using a tag (tag:server), user (alice@example.com), group (group:kids), or*.

attr

Specifies which attributes apply to those nodes (devices).

For example:

• The attributenextdns:abc123 specifics the NextDNS configuration IDabc123. If this is used, the attribute overrides the global NextDNS configuration.
• The attributenextdns:no-device-info disables sending device metadata to NextDNS.

The following example allows members of the tailnet to useTailscale Funnel on their nodes:

"nodeAttrs":[{"target":["autogroup:members"],"attr":["funnel"],},],

You can use anodeAttrs policy to enable therandomize-client-port setting for specific devices instead of using anetwork-wide policy setting.

"nodeAttrs":[{"target":["tag:office-network","group:sea-office"],"attr":["randomize-client-port"],},],

app

Specifies which application layer capabilities apply to these nodes (devices).

The following example node attribute definition configures theexample-connector tag for theexample.com domains.

{"target":["*"],"app":{"tailscale.com/app-connectors":[{"name":"example-app","connectors":["tag:example-connector"],"domains":["example.com"],"routes":["192.0.2.0/24"],},],},}

The specific application defines the names of capabilities in the format<domainName>/<capabilityName>. The example usestailscale.com/app-connectors.

The value associated with each capability is an array of JSON objects, each containing capability-specific configuration options.

Refer to theHow app connectors work andBest practices for using app connectors topics.

Tests

Thetests section lets you write assertions about your access control policies (grants and ACLs) that run as checks each time the tailnet policy file changes. If an assertion fails, the Tailscale rejects the updated tailnet policy file with an error. The error message indicates the failing tests.

Tests let you ensure you don't accidentally revoke important permissions or expose a critical system.

Atests definition looks like this:

"tests":[{"src":"dave@example.com","srcPostureAttrs":{"node:os":"windows",},"proto":"tcp","accept":["example-host-1:22","vega:80"],"deny":["192.0.2.3:443"],},],

src

Specifies the user identity to test, which can be auser's email address, agroup, atag, or ahost that maps to an IP address. The test case runs from the perspective of a device authenticated with the provided identity.

srcPostureAttrs

Specifies thedevice posture attributes as key-value pairs to use when evaluating posture conditions in access rules. You only need to use this field if the access rules containdevice posture conditions.

proto

Specifies the IP protocol foraccept anddeny rules, similar to theproto field inACL rules. When omitted, the test checks for either TCP or UDP access.

When testing Internet Control Message Protocol (ICMP) access, set"proto": "icmp" and use port0 in your destinations since ICMP doesn't use ports. The following example tests that useralice@example.com canping devices tagged withtag:production:

"tests":[{"src":"alice@example.com","proto":"icmp","accept":["tag:production:0"],},],

accept anddeny destinations

Specifies destinations to accept or deny. Each destination in the list is of the formhost:port whereport is a single numeric port andhost is one of the following:

Sources insrc and destinations inaccept anddeny must refer to specific entities and do not support* wildcards. For example, anaccept destination cannot betags:*.

SSH Tests

ThesshTests section lets you write assertions about yourTailscale SSH access rules. SSH tests function similarly to ACLtests.

SSH tests run when the tailnet policy file changes. If an assertion fails, Tailscale rejects the updated tailnet policy file with an error detailing the failing tests.

The following example shows asshTests definition performs the following tests on connections fromdave@example.com toexample-host-1:

• If the user isdave, it accepts the connection.
• If the user isadmin, it checks the connection.
• If the user isroot, it denies the connection.

"sshTests":[{"src":"dave@example.com","dst":["example-host-1"],"accept":["dave"],"check":["admin"],"deny":["root"],},],

src

Specifies the user identity that's attempting to connect as SSH, which can be auser's email address, agroup, atag, or ahost that maps to an IP address. The test case runs from the perspective of a device authenticated with the provided identity.

dst

Specifies one or more destinations to which thesrc user is connecting, which can be auser's email address, agroup, atag, or ahost that maps to an IP address.

accept

Specifies zero, one, or more usernames to disallow on thedst host without requiring an additional check. Refer toactionaccept.

check

Specifies zero, one, or more usernames to disallow on thedst host if thesrc user passes an additional check. Refer toactioncheck.

deny

Specifies zero, one, or more usernames to disallow on thedst host (under any circumstances).

IP sets

An IP set is a way to manage groups of IP addresses. It can encapsulate a collection of IP addresses, CIDRs, hosts, autogroups, and other IP sets. The primary benefit of IP sets is that they let you group multiple network parts into a single collection, enabling you to apply access control policies to the collection rather than the individual IP addresses, hosts, or subnets.

Refer to theIP sets documentation.

Network policy options

In addition to access rules, the tailnet policy file includes a few network-wide policy settings for specialized purposes. Most networks should never need to specify these.

derpMap

ThederpMap section lets you addcustom DERP servers to your network, which your devices will use as needed to relay traffic. You can also use this section to disable using Tailscale-provided DERP servers. For example, you might want to disable tailnet-provided DERP servers to meet corporate compliance requirements. Refer torunning custom DERP servers for more information.

disableIPv4

ThedisableIPv4 field (if set totrue) stops assigning Tailscale IPv4 addresses to your devices. When IPv4 is disabled, all devices in your network receive exclusively IPv6 Tailscale addresses. Devices that do not support IPv6 (for example, systems that have IPv6 disabled in the operating system) will be unreachable. This option is intended for users with a pre-existing conflicting use of the100.64.0.0/10 carrier-grade NAT address range.

OneCGNATRoute

TheOneCGNATRoute field controls the routes that Tailscale clients generate.

Tailscale clients can have either:

• One large100.64/10 route to avoid churn in the routing table as devices go online and offline. (The churn isdisruptive to Chromium-based browsers on macOS.)
• Fine-grained/32 routes.

The possible values forOneCGNATRoute are:

• An empty string or not provided: Use default heuristics for each platform.
  • For all platforms (other than macOS), Tailscale adds fine-grained/32 routes for each device.
  • On macOS (for Tailscale v1.28 or later), Tailscale adds one100.64/10 route. Tailscale won't use one100.64/10 route if other interfaces also route IP addresses in that range.
• "mac-always": macOS clients always add one100.64/10 route.
• "mac-never": macOS clients always add fine-grained/32 routes.

randomizeClientPort

Setting therandomizeClientPort field totrue makes devices use a random port forWireGuard traffic rather than the default static port41641.