{"slug":"site-to-site-networking","title":"Site-to-site networking","tags":["tailscale","networking"],"agent_summary":"Last validated: Dec 8, 2025","trigger_phrases":[],"runnable":false,"markdown":"\r\n# Site-to-site networking\r\n\r\nLast validated: Dec 8, 2025\r\n\r\nSite-to-site networking (also known as [layer 3 (L3) routing](https://tailscale.com/docs/concepts/tailscale-osi)) creates a bridge between two or more distinct networks, letting devices in different subnets communicate with each other without a direct connection. You can create a site-to-site connection using Tailscale [subnet routers](https://tailscale.com/docs/features/subnet-routers), which lets you connect entire networks (such as different physical locations or cloud environments) together securely through your Tailscale network (known as a tailnet). Example use cases include connecting branch offices to a central office or connecting cloud environments to on-premises networks.\r\n\r\nUsing Tailscale to create a site-to-site connection is a powerful alternative to traditional methods of connecting networks, such as [VPNs](https://en.wikipedia.org/wiki/Virtual_private_network) or [multi-protocol label switching (MPLS)](https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching), which often require complex configuration and management. It lets you leverage Tailscale's encrypted connections to securely connect networks without complicated configurations or management overhead.\r\n\r\n## [Requirements and limitations](https://tailscale.com/docs/features/site-to-site\\#requirements-and-limitations)\r\n\r\nThe subnets and subnet router devices within a tailnet must meet the following requirements for site-to-site networking to work:\r\n\r\n- The subnets must **not** have identical [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) ranges. If you need multiple subnet routers advertising the exact same subnet (for example, two routers both advertising `10.0.0.0/24`), use [high availability](https://tailscale.com/docs/how-to/set-up-high-availability) or [4via6 subnet routing](https://tailscale.com/docs/features/subnet-routers/4via6-subnets).\r\n- Both subnet routers must use a Linux-based operating system.\r\n\r\n### [Overlapping subnet routes with different prefix lengths](https://tailscale.com/docs/features/site-to-site\\#overlapping-subnet-routes-with-different-prefix-lengths)\r\n\r\nTailscale supports subnet routers advertising overlapping routes with different prefix lengths. When multiple subnet routers advertise overlapping subnets, Tailscale uses longest prefix matching (LPM) to route traffic to the most specific route available.\r\n\r\nFor example, if you have:\r\n\r\n- Subnet router A advertising `10.0.0.0/16`\r\n- Subnet router B advertising `10.0.0.0/24`\r\n\r\nTraffic will be routed as follows:\r\n\r\n- `10.0.0.1` routes through subnet router B (matched by the more specific `/24` route)\r\n- `10.0.1.1` routes through subnet router A (only matched by the `/16` route)\r\n\r\nThis behavior follows standard IP routing principles and can be useful for scenarios where you want more granular control over routing for specific subnets within a larger address space.\r\n\r\n## [Create a site-to-site connection](https://tailscale.com/docs/features/site-to-site\\#create-a-site-to-site-connection)\r\n\r\nCreating a site-to-site connection involves configuring a device in each subnet to act as a subnet router, approving the subnet routers from the [Machines](https://login.tailscale.com/admin/machines) of the admin console, updating the tailnet access control policies, and configuring the devices in each subnet to use the designated subnet router for the correct routes.\r\n\r\n### [Step 1: Select a subnet router](https://tailscale.com/docs/features/site-to-site\\#step-1-select-a-subnet-router)\r\n\r\nThe first step is to select a device within the subnet to act as the designated subnet router. This device must use a Linux-based operating system.\r\n\r\n### [Step 2: Configure the subnet router](https://tailscale.com/docs/features/site-to-site\\#step-2-configure-the-subnet-router)\r\n\r\nAfter selecting a device in the subnet to function as the subnet router, you must configure it to act as a subnet router. Configuring the subnet router involves [installing the Tailscale client](https://tailscale.com/docs/install), enabling IP address forwarding, starting the Tailscale client with the correct configuration options, and configuring the device's `iptables` settings.\r\n\r\n#### [IP address forwarding](https://tailscale.com/docs/features/site-to-site\\#ip-address-forwarding)\r\n\r\nIf your Linux system has a `/etc/sysctl.d` directory, use:\r\n\r\n```shell\r\necho 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf\r\necho 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf\r\nsudo sysctl -p /etc/sysctl.d/99-tailscale.conf\r\n```\r\n\r\nOtherwise, use:\r\n\r\n```shell\r\necho 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf\r\necho 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf\r\nsudo sysctl -p /etc/sysctl.conf\r\n```\r\n\r\n#### [Subnet router configuration options](https://tailscale.com/docs/features/site-to-site\\#subnet-router-configuration-options)\r\n\r\nConfiguring a device as a subnet router involves specifying the subnet routes to advertise, disabling source network address translation (SNAT), and enabling the device to accept routes. You can use the [`tailscale up`](https://tailscale.com/docs/reference/tailscale-cli#up) or [`tailscale set`](https://tailscale.com/docs/reference/tailscale-cli#set) CLI commands to set these configuration options.\r\n\r\n| **Configuration option** | **CLI flag** | **Description** |\r\n| --- | --- | --- |\r\n| Advertise subnet routes | `--advertise-routes=` | The `--advertise-routes` flag specifies a CIDR range of the IP addresses to be exposed to the tailnet. Access to those addresses is controlled by Tailscale access control policies. |\r\n| Disable source network address translation (SNAT) | `--snat-subnet-routes=false` (Linux only) | The `--snat-subnet-routes=false` flag disables source NAT (SNAT). By default, a device behind a subnet router sees traffic as originating from the subnet router. This reduces routing complexity but prevents traversing multiple networks. By disabling source NAT, the end device sees the IP address of the originating device as the source, which might be a Tailscale IP address or an address behind another subnet router. |\r\n| Accept routes | `--accept-routes` | The `--accept-routes` flag accepts the advertised routes of all other subnet routers in the tailnet. |\r\n\r\nWhen setting up subnet routers for high availability (HA), be careful with the `--accept-routes` flag. If you turn on `--accept-routes` for subnet routers that share the same routes in the same region, the standby router will accept its own advertised routes from the primary router.\r\n\r\nThis leads to an inefficient routing path. The standby router will send traffic for its directly connected subnet through the primary router instead. For example, if both subnet routers advertise and accept the same route, such as `192.168.1.0/24`, the standby router will send all `192.168.1.0/24` traffic through the primary router, even though it is directly connected to that network.\r\n\r\nFor most HA subnet router setups, use the `--advertise-routes` flag alone. Avoid using `--accept-routes` unless you specifically need that routing behavior.\r\n\r\n#### [Clamp the MSS to the MTU](https://tailscale.com/docs/features/site-to-site\\#clamp-the-mss-to-the-mtu)\r\n\r\nYou should also clamp the [maximum segment size (MSS)](https://en.wikipedia.org/wiki/Maximum_segment_size) to the [maximum transmission unit (MTU)](https://en.wikipedia.org/wiki/Maximum_transmission_unit). You can do this using [`iptables`](https://en.wikipedia.org/wiki/iptables). The following command updates the Tailscale network interface (`tailscale0`) to clamp MSS to MTU.\r\n\r\n```shell\r\niptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp \\\r\n--tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu\r\n```\r\n\r\n### [Step 3: Approve the subnet router](https://tailscale.com/docs/features/site-to-site\\#step-3-approve-the-subnet-router)\r\n\r\nAfter selecting and configuring the subnet router, you must approve it from the Machines page of the admin console. If you used an [auto approver](https://tailscale.com/docs/reference/syntax/policy-file#autoapprovers) policy in the tailnet policy file for the device, you don't need to approve the subnet router manually.\r\n\r\n1. Open the [Machines](https://login.tailscale.com/admin/machines) page of the admin console.\r\n2. Locate the subnet router devices by locating the **Subnets** badge or using the [`property:subnet`](https://login.tailscale.com/admin/machines?q=property%3Asubnet) filter.\r\n3. For each subnet router:\r\n1. Select the ![ellipsis icon](https://tailscale.com/files/images/icons/fa-ellipsis-h.svg) menu > **Edit route settings**.\r\n2. Approve the device.\r\n\r\nYou might prefer to [disable key expiry](https://tailscale.com/docs/features/access-control/key-expiry) on your subnet routers to avoid having to periodically reauthenticate. If you are using [tags](https://tailscale.com/docs/features/tags), [key expiry is disabled by default](https://tailscale.com/docs/features/tags#key-expiry).\r\n\r\n### [Step 4: Update tailnet access control policies](https://tailscale.com/docs/features/site-to-site\\#step-4-update-tailnet-access-control-policies)\r\n\r\nYou must update the [access control policies](https://tailscale.com/docs/features/access-control) for your tailnet to allow communication between the subnets by creating access rules ( [grants](https://tailscale.com/docs/features/access-control/grants)) to permit the subnets to connect.\r\n\r\nYou can do this from the [Access controls](https://login.tailscale.com/admin/acls) page of the admin console using either the [visual editor](https://tailscale.com/docs/features/visual-editor) or the JSON editor.\r\n\r\nThe following examples permit all traffic between the subnets.\r\n\r\n#### [JSON editor](https://tailscale.com/docs/features/site-to-site\\#json-editor)\r\n\r\nTo use the JSON editor to create access rules between the subnets, you must create two access rules: one for each direction of traffic between the subnets.\r\n\r\n1. Open the [Access controls](https://login.tailscale.com/admin/acls/file) page of the admin console.\r\n2. Select the **JSON editor** tab to update the tailnet policy file using JSON.\r\n3. Locate the `grants` section of the policy file.\r\n4. Add two access rules to the `grants` section of the policy file: one for each direction of traffic between the subnets.\r\n\r\nThe end result should look similar to the following example, which permits all traffic between two subnets. Replace `` and `` with the actual CIDR ranges of the subnets.\r\n\r\n```json\r\n{\r\n \"grants\": [\\\r\n {\\\r\n \"src\": [ ],\\\r\n \"dst\": [ ],\\\r\n \"ip\": [\"*\"]\\\r\n },\\\r\n {\\\r\n \"src\": [ ],\\\r\n \"dst\": [ ],\\\r\n \"ip\": [\"*\"]\\\r\n }\\\r\n ]\r\n}\r\n```\r\n\r\n#### [Visual editor](https://tailscale.com/docs/features/site-to-site\\#visual-editor)\r\n\r\nTo use the [visual editor](https://tailscale.com/docs/features/visual-editor) to create access rules between the subnets, you must create two access rules: one for each direction of traffic between the subnets.\r\n\r\n1. Create an access rule to allow traffic from the first subnet to the second subnet:\r\n1. Open the [Access controls](https://login.tailscale.com/admin/acls/file) page of the admin console.\r\n2. Select the [Visual editor](https://login.tailscale.com/admin/acls/visual) tab.\r\n3. Select **Add rule**.\r\n4. In the **Source** field, enter the CIDR range of the first subnet.\r\n5. In the **Destination** field, enter the CIDR range of the second subnet.\r\n6. In the **Port and protocol** field, select **All ports and protocols**.\r\n7. (Optional) Add a descriptive note to the access rule to help you identify it later.\r\n8. Select **Save grant**.\r\n2. Create an access rule to allow traffic from the second subnet to the first subnet:\r\n1. Open the [Access controls](https://login.tailscale.com/admin/acls/file) page of the admin console.\r\n2. Select the [Visual editor](https://login.tailscale.com/admin/acls/visual) tab.\r\n3. Select **Add rule**.\r\n4. In the **Source** field, enter the CIDR range of the second subnet.\r\n5. In the **Destination** field, enter the CIDR range of the first subnet.\r\n6. In the **Port and protocol** field, select **All ports and protocols**.\r\n7. (Optional) Add a descriptive note to the access rule to help you identify it later.\r\n8. Select **Save grant**.\r\n\r\nThis creates two access rules using the grants syntax. They apply immediately as soon as you save them.\r\n\r\n### [Step 5: Configure the other subnet devices](https://tailscale.com/docs/features/site-to-site\\#step-5-configure-the-other-subnet-devices)\r\n\r\nAfter configuring and approving the subnet router, make sure the devices in the subnet use the designated subnet router for the correct routes. The best way to configure the devices in the subnet depends on your infrastructure. For example, if the subnet devices already use the subnet router as the default gateway, you don't need to configure them because they will automatically use the subnet router for all traffic (unless a more specific route applies). If the subnet devices don't use the subnet router as the default gateway, you must configure them to use the subnet router for the correct routes.\r\n\r\nFor example, on Linux devices, you can use the [`ip route` command](https://www.man7.org/linux/man-pages/man8/ip-route.8.html). You don't need to configure the subnet devices if the subnet router you selected for the subnet is already the default gateway for the subnet.\r\n\r\n```shell\r\nip route add via \r\nip route add via \r\n```\r\n\r\nThe `ip route` commands do not persist after rebooting. You must run them again after each reboot. Depending on your setup, you can make the route settings persistent by adding them to your network manager or [`netplan`](https://netplan.io/) configuration. Alternatively, you can manage route settings with a DHCP server on your network.\r\n\r\nIf the subnet is in a cloud environment, such as [AWS](https://tailscale.com/docs/install/cloud/aws), you can usually update the cloud provider's routing tables instead of configuring each device directly.\r\n\r\n## [Example scenario](https://tailscale.com/docs/features/site-to-site\\#example-scenario)\r\n\r\nThe following sections demonstrate using two subnet routers to connect two subnets within a tailnet. The following table documents the example subnets and subnet routers.\r\n\r\n| **Subnet name** | **Subnet CIDR range** | **Subnet router IP address** |\r\n| --- | --- | --- |\r\n| Subnet A | `192.0.2.0/24` | `192.0.2.2` (subnet router A) |\r\n| Subnet B | `172.16.100.0/24` | `172.16.100.2` (subnet router A) |\r\n\r\nTo create a site-to-site connection between subnet A and subnet B, follow these steps:\r\n\r\n1. Configure both subnet routers (subnet A at `192.0.2.2` and subnet B at `172.16.100.2`):\r\n1. [Install the Tailscale client](https://tailscale.com/docs/install) on each subnet router.\r\n\r\n2. [Enable IP forwarding](https://tailscale.com/docs/features/site-to-site#ip-address-forwarding).\r\n\r\n3. [Configure the Tailscale client](https://tailscale.com/docs/features/site-to-site#subnet-router-configuration-options).\r\n\r\n For the `192.0.2.2` subnet router, use `192.0.2.0/24`:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n ```shell\r\n tailscale up --advertise-routes=192.0.2.0/24 --snat-subnet-routes=false --accept-routes\r\n ```\r\n\r\n\r\n\r\n For the `172.16.100.2` subnet router, use `172.16.100.0/24`:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n ```shell\r\n tailscale up --advertise-routes=172.16.100.0/24 --snat-subnet-routes=false --accept-routes\r\n ```\r\n\r\n\r\n\r\n\r\n\r\n The `--snat-subnet-routes` flag only works if the operating system is Linux.\r\n\r\n4. Configure `iptables` to [clamp the MSS to the MTU](https://tailscale.com/docs/features/site-to-site#clamp-the-mss-to-the-mtu).\r\n2. [Approve the subnet routes](https://tailscale.com/docs/features/site-to-site#approve-the-subnet-router).\r\n\r\n3. [Configure the subnet devices](https://tailscale.com/docs/features/site-to-site#configure-the-other-subnet-devices) by running the following commands on each device in the subnet (except the subnet router):\r\n1. For each device in the `192.0.2.0/24` subnet (except the subnet router), run the following commands:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n ```shell\r\n ip route add 100.64.0.0/10 via 192.0.2.2\r\n ip route add 172.16.100.0/24 via 192.0.2.2\r\n ```\r\n\r\n2. For each device in the `172.16.100.0/24` subnet (except the subnet router), run the following commands:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n ```shell\r\n ip route add 100.64.0.0/10 via 172.16.100.2\r\n ip route add 192.0.2.0/24 via 172.16.100.2\r\n ```\r\n4. Update the tailnet [access control policies](https://tailscale.com/docs/features/access-control) to allow communication between the subnets. In the following example, the tailnet policy file permits all traffic between the subnets using [grants](https://tailscale.com/docs/features/access-control/grants):\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```json\r\n{\r\n \"grants\": [\\\r\n {\\\r\n \"src\": [\"100.64.0.0/10\"], // CIDR range of subnet A\\\r\n \"dst\": [\"192.0.2.0/24\"], // CIDR range of subnet B\\\r\n \"ip\": [\"*\"]\\\r\n },\\\r\n {\\\r\n \"src\": [\"192.0.2.0/24\"], // CIDR range of subnet B\\\r\n \"dst\": [\"100.64.0.0/10\"], // CIDR range of subnet A\\\r\n \"ip\": [\"*\"]\\\r\n }\\\r\n ]\r\n}\r\n```\r\n\r\n5. Test the [connectivity](https://tailscale.com/docs/reference/troubleshooting/connectivity) between subnet A and subnet B:\r\n\r\nNow a device in subnet A can connect to a device in subnet B (and vice versa) without either needing to install the Tailscale client. You can test the connection by running the `ping` command from a subnet A device to a subnet B device. For example, ping `172.16.100.3` from `198.0.2.3`:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\nping 172.16.100.3\r\n\r\nPING 172.16.100.3 (172.16.100.3) 56(84) bytes of data.\r\n64 bytes from 172.16.100.3: icmp_seq=1 ttl=64 time=9.34 ms\r\n64 bytes from 172.16.100.3: icmp_seq=2 ttl=64 time=3.85 ms\r\n```\r\n\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":"

Site-to-site networking

\n

Last validated: Dec 8, 2025

\n

Site-to-site networking (also known as layer 3 (L3) routing) creates a bridge between two or more distinct networks, letting devices in different subnets communicate with each other without a direct connection. You can create a site-to-site connection using Tailscale subnet routers, which lets you connect entire networks (such as different physical locations or cloud environments) together securely through your Tailscale network (known as a tailnet). Example use cases include connecting branch offices to a central office or connecting cloud environments to on-premises networks.

\n

Using Tailscale to create a site-to-site connection is a powerful alternative to traditional methods of connecting networks, such as VPNs or multi-protocol label switching (MPLS), which often require complex configuration and management. It lets you leverage Tailscale's encrypted connections to securely connect networks without complicated configurations or management overhead.

\n

Requirements and limitations

\n

The subnets and subnet router devices within a tailnet must meet the following requirements for site-to-site networking to work:

\n
    \n
  • The subnets must not have identical CIDR ranges. If you need multiple subnet routers advertising the exact same subnet (for example, two routers both advertising 10.0.0.0/24), use high availability or 4via6 subnet routing.
    • \n
  • Both subnet routers must use a Linux-based operating system.
    • \n
\n

Overlapping subnet routes with different prefix lengths

\n

Tailscale supports subnet routers advertising overlapping routes with different prefix lengths. When multiple subnet routers advertise overlapping subnets, Tailscale uses longest prefix matching (LPM) to route traffic to the most specific route available.

\n

For example, if you have:

\n
    \n
  • Subnet router A advertising 10.0.0.0/16
    • \n
  • Subnet router B advertising 10.0.0.0/24
    • \n
\n

Traffic will be routed as follows:

\n
    \n
  • 10.0.0.1 routes through subnet router B (matched by the more specific /24 route)
    • \n
  • 10.0.1.1 routes through subnet router A (only matched by the /16 route)
    • \n
\n

This behavior follows standard IP routing principles and can be useful for scenarios where you want more granular control over routing for specific subnets within a larger address space.

\n

Create a site-to-site connection

\n

Creating a site-to-site connection involves configuring a device in each subnet to act as a subnet router, approving the subnet routers from the Machines of the admin console, updating the tailnet access control policies, and configuring the devices in each subnet to use the designated subnet router for the correct routes.

\n

Step 1: Select a subnet router

\n

The first step is to select a device within the subnet to act as the designated subnet router. This device must use a Linux-based operating system.

\n

Step 2: Configure the subnet router

\n

After selecting a device in the subnet to function as the subnet router, you must configure it to act as a subnet router. Configuring the subnet router involves installing the Tailscale client, enabling IP address forwarding, starting the Tailscale client with the correct configuration options, and configuring the device's iptables settings.

\n

IP address forwarding

\n

If your Linux system has a /etc/sysctl.d directory, use:

\n
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf\r\necho 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf\r\nsudo sysctl -p /etc/sysctl.d/99-tailscale.conf\n
\n

Otherwise, use:

\n
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf\r\necho 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf\r\nsudo sysctl -p /etc/sysctl.conf\n
\n

Subnet router configuration options

\n

Configuring a device as a subnet router involves specifying the subnet routes to advertise, disabling source network address translation (SNAT), and enabling the device to accept routes. You can use the tailscale up or tailscale set CLI commands to set these configuration options.

\n

| Configuration option | CLI flag | Description |\r\n| --- | --- | --- |\r\n| Advertise subnet routes | --advertise-routes=<CIDR> | The --advertise-routes flag specifies a CIDR range of the IP addresses to be exposed to the tailnet. Access to those addresses is controlled by Tailscale access control policies. |\r\n| Disable source network address translation (SNAT) | --snat-subnet-routes=false (Linux only) | The --snat-subnet-routes=false flag disables source NAT (SNAT). By default, a device behind a subnet router sees traffic as originating from the subnet router. This reduces routing complexity but prevents traversing multiple networks. By disabling source NAT, the end device sees the IP address of the originating device as the source, which might be a Tailscale IP address or an address behind another subnet router. |\r\n| Accept routes | --accept-routes | The --accept-routes flag accepts the advertised routes of all other subnet routers in the tailnet. |

\n

When setting up subnet routers for high availability (HA), be careful with the --accept-routes flag. If you turn on --accept-routes for subnet routers that share the same routes in the same region, the standby router will accept its own advertised routes from the primary router.

\n

This leads to an inefficient routing path. The standby router will send traffic for its directly connected subnet through the primary router instead. For example, if both subnet routers advertise and accept the same route, such as 192.168.1.0/24, the standby router will send all 192.168.1.0/24 traffic through the primary router, even though it is directly connected to that network.

\n

For most HA subnet router setups, use the --advertise-routes flag alone. Avoid using --accept-routes unless you specifically need that routing behavior.

\n

Clamp the MSS to the MTU

\n

You should also clamp the maximum segment size (MSS) to the maximum transmission unit (MTU). You can do this using iptables. The following command updates the Tailscale network interface (tailscale0) to clamp MSS to MTU.

\n
iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp \\\r\n--tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu\n
\n

Step 3: Approve the subnet router

\n

After selecting and configuring the subnet router, you must approve it from the Machines page of the admin console. If you used an auto approver policy in the tailnet policy file for the device, you don't need to approve the subnet router manually.

\n
    \n
  1. Open the Machines page of the admin console.
    2. \n
  2. Locate the subnet router devices by locating the Subnets badge or using the property:subnet filter.
    3. \n
  3. For each subnet router:
    4. \n
  4. Select the \"ellipsis menu > Edit route settings.
    5. \n
  5. Approve the device.
    6. \n
\n

You might prefer to disable key expiry on your subnet routers to avoid having to periodically reauthenticate. If you are using tags, key expiry is disabled by default.

\n

Step 4: Update tailnet access control policies

\n

You must update the access control policies for your tailnet to allow communication between the subnets by creating access rules ( grants) to permit the subnets to connect.

\n

You can do this from the Access controls page of the admin console using either the visual editor or the JSON editor.

\n

The following examples permit all traffic between the subnets.

\n

JSON editor

\n

To use the JSON editor to create access rules between the subnets, you must create two access rules: one for each direction of traffic between the subnets.

\n
    \n
  1. Open the Access controls page of the admin console.
    2. \n
  2. Select the JSON editor tab to update the tailnet policy file using JSON.
    3. \n
  3. Locate the grants section of the policy file.
    4. \n
  4. Add two access rules to the grants section of the policy file: one for each direction of traffic between the subnets.
    5. \n
\n

The end result should look similar to the following example, which permits all traffic between two subnets. Replace <first-subnet-CIDR> and <second-subnet-CIDR> with the actual CIDR ranges of the subnets.

\n
{\r\n  \"grants\": [\\\r\n    {\\\r\n      \"src\": [ <first-subnet-CIDR> ],\\\r\n      \"dst\": [ <second-subnet-CIDR> ],\\\r\n      \"ip\": [\"*\"]\\\r\n    },\\\r\n    {\\\r\n      \"src\": [ <second-subnet-CIDR> ],\\\r\n      \"dst\": [ <first-subnet-CIDR> ],\\\r\n      \"ip\": [\"*\"]\\\r\n    }\\\r\n  ]\r\n}\n
\n

Visual editor

\n

To use the visual editor to create access rules between the subnets, you must create two access rules: one for each direction of traffic between the subnets.

\n
    \n
  1. Create an access rule to allow traffic from the first subnet to the second subnet:
    2. \n
  2. Open the Access controls page of the admin console.
    3. \n
  3. Select the Visual editor tab.
    4. \n
  4. Select Add rule.
    5. \n
  5. In the Source field, enter the CIDR range of the first subnet.
    6. \n
  6. In the Destination field, enter the CIDR range of the second subnet.
    7. \n
  7. In the Port and protocol field, select All ports and protocols.
    8. \n
  8. (Optional) Add a descriptive note to the access rule to help you identify it later.
    9. \n
  9. Select Save grant.
    10. \n
  10. Create an access rule to allow traffic from the second subnet to the first subnet:
    11. \n
  11. Open the Access controls page of the admin console.
    12. \n
  12. Select the Visual editor tab.
    13. \n
  13. Select Add rule.
    14. \n
  14. In the Source field, enter the CIDR range of the second subnet.
    15. \n
  15. In the Destination field, enter the CIDR range of the first subnet.
    16. \n
  16. In the Port and protocol field, select All ports and protocols.
    17. \n
  17. (Optional) Add a descriptive note to the access rule to help you identify it later.
    18. \n
  18. Select Save grant.
    19. \n
\n

This creates two access rules using the grants syntax. They apply immediately as soon as you save them.

\n

Step 5: Configure the other subnet devices

\n

After configuring and approving the subnet router, make sure the devices in the subnet use the designated subnet router for the correct routes. The best way to configure the devices in the subnet depends on your infrastructure. For example, if the subnet devices already use the subnet router as the default gateway, you don't need to configure them because they will automatically use the subnet router for all traffic (unless a more specific route applies). If the subnet devices don't use the subnet router as the default gateway, you must configure them to use the subnet router for the correct routes.

\n

For example, on Linux devices, you can use the ip route command. You don't need to configure the subnet devices if the subnet router you selected for the subnet is already the default gateway for the subnet.

\n
ip route add <first-subnet-CIDR> via <first-subnet-router-IP-address>\r\nip route add <second-subnet-CIDR> via <second-subnet-router-IP-address>\n
\n

The ip route commands do not persist after rebooting. You must run them again after each reboot. Depending on your setup, you can make the route settings persistent by adding them to your network manager or netplan configuration. Alternatively, you can manage route settings with a DHCP server on your network.

\n

If the subnet is in a cloud environment, such as AWS, you can usually update the cloud provider's routing tables instead of configuring each device directly.

\n

Example scenario

\n

The following sections demonstrate using two subnet routers to connect two subnets within a tailnet. The following table documents the example subnets and subnet routers.

\n

| Subnet name | Subnet CIDR range | Subnet router IP address |\r\n| --- | --- | --- |\r\n| Subnet A | 192.0.2.0/24 | 192.0.2.2 (subnet router A) |\r\n| Subnet B | 172.16.100.0/24 | 172.16.100.2 (subnet router A) |

\n

To create a site-to-site connection between subnet A and subnet B, follow these steps:

\n
    \n
  1. \n

    Configure both subnet routers (subnet A at 192.0.2.2 and subnet B at 172.16.100.2):

    \n
    2. \n
  2. \n

    Install the Tailscale client on each subnet router.

    \n
    3. \n
  3. \n

    Enable IP forwarding.

    \n
    4. \n
  4. \n

    Configure the Tailscale client.

    \n

    For the 192.0.2.2 subnet router, use 192.0.2.0/24:

    \n
    tailscale up --advertise-routes=192.0.2.0/24 --snat-subnet-routes=false --accept-routes\n
    \n

    For the 172.16.100.2 subnet router, use 172.16.100.0/24:

    \n
    tailscale up --advertise-routes=172.16.100.0/24 --snat-subnet-routes=false --accept-routes\n
    \n

    The --snat-subnet-routes flag only works if the operating system is Linux.

    \n
    5. \n
  5. \n

    Configure iptables to clamp the MSS to the MTU.

    \n
    6. \n
  6. \n

    Approve the subnet routes.

    \n
    7. \n
  7. \n

    Configure the subnet devices by running the following commands on each device in the subnet (except the subnet router):

    \n
    8. \n
  8. \n

    For each device in the 192.0.2.0/24 subnet (except the subnet router), run the following commands:

    \n
    ip route add 100.64.0.0/10 via 192.0.2.2\r\nip route add 172.16.100.0/24 via 192.0.2.2\n
    \n
    9. \n
  9. \n

    For each device in the 172.16.100.0/24 subnet (except the subnet router), run the following commands:

    \n
    ip route add 100.64.0.0/10 via 172.16.100.2\r\nip route add 192.0.2.0/24 via 172.16.100.2\n
    \n
    10. \n
  10. \n

    Update the tailnet access control policies to allow communication between the subnets. In the following example, the tailnet policy file permits all traffic between the subnets using grants:

    \n
    11. \n
\n
{\r\n     \"grants\": [\\\r\n       {\\\r\n         \"src\": [\"100.64.0.0/10\"], // CIDR range of subnet A\\\r\n         \"dst\": [\"192.0.2.0/24\"], // CIDR range of subnet B\\\r\n         \"ip\": [\"*\"]\\\r\n       },\\\r\n       {\\\r\n         \"src\": [\"192.0.2.0/24\"], // CIDR range of subnet B\\\r\n         \"dst\": [\"100.64.0.0/10\"], // CIDR range of subnet A\\\r\n         \"ip\": [\"*\"]\\\r\n       }\\\r\n     ]\r\n}\n
\n
    \n
  1. Test the connectivity between subnet A and subnet B:
    2. \n
\n

Now a device in subnet A can connect to a device in subnet B (and vice versa) without either needing to install the Tailscale client. You can test the connection by running the ping command from a subnet A device to a subnet B device. For example, ping 172.16.100.3 from 198.0.2.3:

\n
ping 172.16.100.3\r\n\r\nPING 172.16.100.3 (172.16.100.3) 56(84) bytes of data.\r\n64 bytes from 172.16.100.3: icmp_seq=1 ttl=64 time=9.34 ms\r\n64 bytes from 172.16.100.3: icmp_seq=2 ttl=64 time=3.85 ms\n
\n

\"Project

\n

Ask AI

\n

reCAPTCHA

\n

Recaptcha requires verification.

\n

protected by reCAPTCHA

\n"}