Overlapping subnets

When you need sites

Two LANs behind different gateways often use the same subnet — say, 192.168.1.0/24 in two offices or at home and at your parents'. Ordinary subnet routes can't tell them apart: 192.168.1.10 would mean two different hosts. Sites solve this with Tailscale's 4via6: each LAN gets a site number, and a host is reached by its address and the number.

• Host 192.168.1.10 of site 7 is reached by the name 192-168-1-10-via-7 or by its IPv6 address fd7a:115c:a1e0:b1a:0:7:c0a8:10a.
• The same host address at site 8 is 192-168-1-10-via-8 — a different host.
• The gateway of a site is a device of the network inside that LAN; it advertises the site's routes, you approve them, and access rules decide who reaches the site.
• 4via6 addresses are IPv6, so the devices you connect from need working IPv6. Where they don't have it, see Alternative: 1:1 subnet mapping — it works over IPv4.

Sites live on the Sites tab of the network page, under Sites (overlapping subnets). A site that waits for you — not approved yet, or no access rule opens it — is unfolded; an approved one is a single line: click it for the routes, the command and the host names.

Add a site

Add the gateway to the network first — a Linux device inside the site's LAN works best, since the command is written for it. Then press Add a site and fill in the form:

Press Add site. The site appears with the state not advertised: the gateway doesn't know about it yet.

• Subnets behind one gateway can't overlap — neither within a site nor with the gateway's other sites.
• 100.64.0.0/10 (the network's own addresses), loopback, link-local, multicast and reserved ranges can't be a site's LAN.
• A number is also taken if another device of the network already advertises a 4via6 route with it.

Run the command on the gateway

The site's card shows the command for the gateway, for example:

printf 'net.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\n' | sudo tee /etc/sysctl.d/99-tailscale.conf && sudo sysctl -e -p /etc/sysctl.d/99-tailscale.conf && sudo tailscale set --advertise-routes=fd7a:115c:a1e0:b1a:0:7:c0a8:100/120

Its first part turns on IP forwarding on the gateway, for good; then tailscale set advertises the routes. Without forwarding the site is approved, but no traffic flows. The gateway's own page has the same command under LAN gateway.

• tailscale set keeps the gateway's other settings, the exit node too. If you use tailscale up instead, repeat every flag the gateway was brought up with.
• When the gateway already advertises exactly this list, the card says so — nothing to run.
• If the gateway is offline, the command is built from the routes it advertised when last connected.
• If the gateway advertises 4via6 routes that belong to no site of the network, the card names them: the command stops advertising them.
• The forwarding part is for Linux. When the gateway has reported that it runs Windows, the command is just tailscale set … without sudo — run it in PowerShell as administrator; on macOS — just sudo tailscale set ….

Approve the site

When the gateway advertises the routes, the state becomes waiting for approval. Press Approve: exactly the site's routes are approved on the gateway, its other approved routes stay. The state turns approved. If you press it too early, the message repeats the command to run first.

Access rules for sites

With visual access rules, devices reach a site only when a rule lets them — without one they don't even get its route. The default Everything rule covers every site, and so does a rule to All subnets once the gateway advertises the site's routes. For a narrower rule, in To pick the site under Sites (4via6), for example “All devices → Site 7 · Web 80, 443”. While no rule covers a site, its card warns about it.

• A rule on the site's IPv4 subnet, like 192.168.1.0/24, doesn't open the site: the site is reached through its 4via6 route. Pick the site itself.
• The table Who can reach whom has a column per subnet of a site, and Check access can test a site too.

Devices must accept routes

Devices that should reach the sites must accept routes — on Linux it's off by default:

sudo tailscale set --accept-routes=true

Reaching hosts at a site

Each site's card has a small calculator: type a host's address into Name and address of a host at this site and press Show. You get:

• the name, like 192-168-1-10-via-7 — use it only like this, without the network's domain: ssh admin@192-168-1-10-via-7, http://192-168-1-10-via-7:8080;
• the IPv6 address, like fd7a:115c:a1e0:b1a:0:7:c0a8:10a, for programs that want an address — in a URL write it in brackets: http://[fd7a:115c:a1e0:b1a:0:7:c0a8:10a]/.

The device table shows a site's routes as “site 7 · 192.168.1.0/24”; the raw IPv6 prefix is in the tooltip and is copied by a click.

Sites with custom HuJSON

If the network uses custom HuJSON, your policy decides who reaches the sites, and it must allow a site by its 4via6 route — a rule on its IPv4 subnet doesn't open it. The policy page lists the hosts to add (one per subnet of a site) and an example rule:

"hosts": {
  "site-7": "fd7a:115c:a1e0:b1a:0:7:c0a8:100/120",
},
"acls": [
  {"action": "accept", "src": ["*"], "dst": ["site-7:*"]},
],

Delete a site

Delete site on the site's card, after a confirmation: its routes stop being approved on the gateway, and access rules that use the site are deleted too. The page then shows a new command for the gateway — its full list of routes without the deleted site; run it so the gateway stops advertising them. With custom HuJSON, remove the site's routes from your policy yourself. When a gateway device is deleted from the network, its sites go with it.

If a site doesn't answer

1. The site is approved, but hosts behind it don't answer: check IP forwarding on the gateway — sysctl net.ipv4.ip_forward must show 1. If it shows 0, run the command from the site's card again: it turns forwarding on for good. The network can't see this from its side — Tailscale doesn't report it.
2. The device you connect from accepts routes, and an access rule lets it reach the site.
3. You use the site's name or address (Reaching hosts at a site), not the plain LAN address.
4. Your device has working IPv6. If a device of the network answers its 100.x address but not its IPv6 address (tailscale ip -6 on it shows that one), IPv6 is probably blocked on your side — often by another VPN app that blocks IPv6 against leaks. Turn that VPN off, or use 1:1 mapping, which needs only IPv4.

More checks — in A subnet behind a router doesn't answer.

Limits

• A site holds up to 16 subnets; a network holds up to 256 sites.
• Site numbers are 0–65535 and unique within the network.

Alternative: 1:1 subnet mapping

Sites need IPv6 on the devices you connect from. Where IPv6 doesn't work — for example, another VPN app on the device blocks it against leaks — sites don't answer, while ordinary IPv4 subnet routes still do. Then map the LAN on its gateway onto another IPv4 range of the same size: the network sees the LAN 192.168.0.0/23 as 10.69.0.0/23, and 10.69.0.5 is the host 192.168.0.5. The gateway advertises the mapped range as an ordinary subnet and rewrites the destination of every connection that comes from the network; the answers get the mapped address back on their way out. Each LAN gets a range of its own, so LANs with the same addresses don't clash either.

Sites or mapping

What mapping costs:

• You set up the gateway by hand. The dashboard neither builds nor checks the rule: for it, the mapped range is an ordinary subnet route.
• Every host has another address when reached from the network: 10.69.0.5 from the network, 192.168.0.5 inside the LAN.
• Names from the LAN's DNS don't follow: a name that the LAN's router resolves to 192.168.0.5 is no use from the network — use the mapped address.
• The mapping rewrites only packet headers. Protocols that put IP addresses into their own data — SIP telephony, FTP in active mode — fail through it, and so does a web interface that redirects you to its own LAN address.
• It carries only connections from the network into the LAN. LAN hosts reaching the network is another job — see the gateway script.

Choose the range

• The same size as the LAN: for 192.168.0.0/23 also a /23. The mapping keeps the host part of each address, so with a range of another size the addresses don't match one to one.
• Used nowhere else: not the LAN of any device of the network (at home, in the office, in a hotel), not another gateway's range, not a site's LAN, and not 100.64.0.0/10 — the network's own addresses.
• Easy to read: change the first two numbers and keep the rest. 192.168.0.0/23 becomes 10.69.0.0/23, 192.168.5.0/24 becomes 10.69.5.0/24, and the host 192.168.5.20 is 10.69.5.20. A second LAN with the same subnet takes another second number, say 10.70.0.0/23.

The mapping rule on the gateway

The gateway is a Linux device of this network inside the LAN, as for any subnet router. The rule takes the connections that come from the network — through the tailscale0 interface — to the mapped range and sends them to the same host number in the LAN. Use iptables or nftables, whichever your system has; one of them is enough. If a firewall manager such as ufw or firewalld runs on the gateway, add and keep the rule through it instead: the ways below can clash with it — installing iptables-persistent, for one, removes ufw.

With iptables:

sudo iptables -t nat -A PREROUTING -i tailscale0 -d 10.69.0.0/23 -j NETMAP --to 192.168.0.0/23

To keep it after a reboot, install the iptables-persistent package — sudo apt install iptables-persistent — and answer “Yes” when it offers to save the current IPv4 rules. After any later change, save them again:

sudo netfilter-persistent save

The rules go to /etc/iptables/rules.v4 and are loaded at boot, before Tailscale starts. Tailscale's own chains (ts-…) get saved with them; that's harmless — Tailscale rebuilds them when it starts.

With nftables — the rule in a file of its own, loaded right away:

sudo tee /etc/netmap.nft >/dev/null <<'EOF'
table ip netmap
delete table ip netmap
table ip netmap {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    iifname "tailscale0" ip daddr 10.69.0.0/23 counter dnat ip prefix to ip daddr map { 10.69.0.0/23 : 192.168.0.0/23 }
  }
}
EOF
sudo nft -f /etc/netmap.nft

The first two lines make the file safe to load again: the table is replaced, not doubled. To load it at boot, include the file in /etc/nftables.conf and turn the nftables service on:

echo 'include "/etc/netmap.nft"' | sudo tee -a /etc/nftables.conf
sudo systemctl enable nftables

The rule needs Tailscale's tailscale0 interface, which a normal install has. With Tailscale in userspace networking mode (--tun=userspace-networking, as in a container without /dev/net/tun) there is no such interface, and the rule never sees the connections.

Advertise and approve the range

Advertise the mapped range — not the LAN's own subnet — with IP forwarding, as the device's page does:

printf 'net.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\n' | sudo tee /etc/sysctl.d/99-tailscale.conf && sudo sysctl -e -p /etc/sysctl.d/99-tailscale.conf && sudo tailscale set --advertise-routes=10.69.0.0/23

Its first part turns IP forwarding on for good, in /etc/sysctl.d/99-tailscale.conf. --advertise-routes replaces the gateway's whole list, so if it advertises other routes, put them into the same list, separated by commas. Then on the gateway's page, under Routes, tick 10.69.0.0/23 and press Apply.

• The devices you connect from must accept routes, as for sites.
• The network knows only the mapped range. With visual access rules, the default Everything rule and a rule to All subnets cover it; for a narrower rule, pick 10.69.0.0/23 in To. In custom HuJSON, allow 10.69.0.0/23 too, not 192.168.0.0/23.

How the answers get back

Tailscale on Linux gives the connections it lets into the LAN the gateway's own LAN address as their source — this is on by default (--snat-subnet-routes=true). So the host 192.168.0.5 answers the gateway, and the gateway, which remembers the connection, gives the answer the source 10.69.0.5 and sends it on to the device. Nothing else is needed.

If you turned this off (--snat-subnet-routes=false), for example so that the hosts see the devices' own 100.x addresses, the LAN must send the answers for the network to the gateway: a route on each host, or one static route on the LAN's router (192.168.0.10 is the gateway's LAN address):

ip route add 100.64.0.0/10 via 192.168.0.10

Without it the answers go to the LAN's router and get lost.

Check that it works

From a device of the network:

ping 10.69.0.5

On the gateway, the rule's counter shows whether connections from the network reach it — the pkts column of the NETMAP line:

sudo iptables -t nat -L PREROUTING -v -n

With nftables, sudo nft list table ip netmap shows the rule's counter. Both count new connections rather than packets, so a working ping run adds just one.

• The counter stays at zero: the connections don't reach the gateway. Check that the route is approved, that your device accepts routes and that an access rule lets it in.
• The counter grows, but there's no answer: check IP forwarding on the gateway — sysctl net.ipv4.ip_forward must show 1 — and that the gateway itself reaches the host: ping 192.168.0.5. If you turned the source replacement off, check the route back (How the answers get back).