Tailscale and Atlas Interconnect both let a device reach machines it could not reach before, and both are often described as “connecting networks”. They answer different questions. A Tailscale tailnet is one network under one coordination server, and a subnet router extends it to a LAN of devices that do not run Tailscale. Atlas Interconnect joins two separate Atlas networks, each with its own keys, members and operator, at one host called the seam, and lets an allow-listed set of hosts on each side reach the other. This page explains both mechanisms, the two modes Interconnect offers, and where each design is the better fit.
An Atlas network is sealed: its own keys, its own address space, forwarding only among its own members. To join two of them, an operator runs one daemon per network on a single host and connects the two daemons with a link that exists only inside that host. Everything that crosses is data between hosts both sides have agreed to expose. Nothing about either network’s structure crosses at all.
Each Atlas daemon owns one tunnel interface, one identity and one address space. The seam host runs two of them: daemon A is an ordinary member of network A, admitted under A’s rules, and daemon B is an ordinary member of network B under B’s. Neither network grants the other anything. Either operator ends the join by revoking the seam host’s membership, exactly as it would revoke any other member.
The two daemons peer over a link of type local, which config load refuses to bind anywhere but loopback. It is an ordinary Atlas link with its usual encryption, so the seam reuses the transport rather than adding a second one; it simply cannot be reached from outside the host.
Each daemon carries an export list naming the hosts or prefixes of its own network, always inside its own subnet, that may take part. The list gates both directions: an unexported host can neither be reached from the other side nor send across to it. Each operator writes only its own list, so neither side can widen what the other exposes.
Nothing is redistributed, and a packet that arrived across one seam is never sent across another, so seams cannot be strung together into a path nobody approved and loops cannot form. Two seam hosts joining the same pair are two parallel seams: every member agrees on one owner of each address the seams serve, and the other takes over within seconds when the first one becomes unreachable.
Link-state adverts, full topology exchanges and membership gossip are never sent across the seam and are ignored if they arrive; the seam is not even listed as a link. Neither network gains a node of the other in its topology, learns the other’s keys or sees its admission decisions. Members keep the configuration they have.
A seam carries traffic in one of two ways, chosen per entry. Mapped mode makes a host of the other network appear at an address inside your own subnet, so members reach it with what they already have. Prefix mode routes a whole prefix of the other Atlas network through the seam with real addresses and nothing rewritten, so its members are reached at the addresses they already have. One seam can carry both at once.
Each host the operator maps is given an address inside this network’s own /24, chosen by this network’s operator. The seam daemon advertises that address as one it serves, so every member reaches it with the subnet route and the shortest-path tree it already has. At the seam the destination is rewritten to the host’s real address on the other side, the source is rewritten to the sender’s mapped address there, and IPv4 and TCP/UDP checksums are repaired in flight. Each side writes only its own map, so nobody renumbers anybody.
The mapped address is one more address in the member’s own subnet. Phones, whose app has a fixed address space, reach the far side as easily as a laptop does, and so do members running older builds.
Nothing of the far network’s numbering enters your routing: each host you map takes an address you choose inside your own subnet. The two networks joined at a seam must not share an address space; partners that happen to be numbered alike as each other each join you through their own seam.
The other side does not change its plan for you. It admits the seam host as a member and writes its own export list and map; you write yours. Neither side needs the other’s keys or topology.
Some joins need more than a handful of hosts: a partner’s ground-control network whose ROS 2 bridge node, video node and operator consoles must all be reachable, or a second organisation’s whole network. Prefix mode routes a prefix of the other Atlas network, its members’ tunnel addresses, through the seam with real addresses in both directions and nothing rewritten. The seam daemon carries the prefix as an imported route in its network’s signed link-state adverts, and each member’s daemon installs it on its own tunnel interface ([routing] install_learned_routes, on by default), so the member reaches a far host by the address that host already has. The reply path is the mirror image: the far seam daemon imports this network’s prefix with its own route entry and advertises it in its network. A prefix crosses only when both sides list it, one side’s route and the other side’s export, for each direction.
Far members are reached at the addresses they already have, and they see the real address of the member that called them. Applications that write addresses into their own payloads, such as stream URLs and configured peer lists, keep working without translation.
The prefix arrives in the same signed adverts that carry the rest of the network’s routing, and each daemon installs it on its own tunnel interface. Withdraw it at the seam and it leaves every member. A member that already has a route overlapping the prefix keeps its own and logs the skip.
What prefix mode routes is the other network’s own members. Atlas has no subnet-router role: a LAN of hosts that do not run Atlas, sitting behind a node, is not routed. The mobile app’s address space is fixed, so phones reach the other network through mapped mode.
[peer.interconnect]
export = ["10.0.101.0/24"] # this network's hosts that take part
[[peer.interconnect.map]] # mapped mode
remote = "10.0.9.130/32"
local = "10.0.101.130/32"
[[peer.interconnect.route]] # prefix mode: the other network's prefix, real addresses
prefix = "10.0.9.0/25"
# on every member: the default
[routing]
install_learned_routes = trueTailscale builds a single private network, a tailnet, out of devices that run its client. A coordination server distributes public keys, addresses and access policy; the traffic itself flows over WireGuard between the devices. A subnet router extends the tailnet to a LAN of devices that run nothing. The summary below follows Tailscale’s public documentation.
Devices register with the coordination server, which shares each device’s public key and address with the others and pushes the access policy to every node. Private keys stay on the devices and policy is enforced on each device, so the server distributes configuration rather than carrying traffic.
Devices connect to each other over WireGuard. Tailscale traverses NAT with techniques based on STUN and ICE to reach a direct connection, which usually gives the lowest latency and the highest throughput. Where a direct connection fails, typically behind blocked UDP or hard NAT, traffic goes through a peer relay in the same tailnet or through DERP servers, which forward packets that remain encrypted end to end. A connection starts on DERP and is upgraded when a better path is found.
Access rules live in the tailnet policy file, edited in the admin console, through GitOps or through the API, as ACLs or grants. With no policy defined, everything may reach everything; once rules are written they are deny-by-default and directional. MagicDNS gives each device a name.
A device runs tailscale set --advertise-routes with one or more prefixes. An admin approves them in the console, or an autoApprovers rule approves them automatically. Android, iOS, macOS, tvOS and Windows clients pick up approved routes; Linux clients opt in with --accept-routes. Devices on the LAN need no software. By default the router translates the source address, so LAN devices see traffic coming from the router; keeping the real source is a Linux-only option that needs a return route for the tailnet’s range. Several routers can advertise the same routes for high availability.
When two sites use the same IPv4 range, a 4via6 subnet router advertises each one under a unique IPv6 prefix built from a site ID, and Tailscale translates back to IPv4 at the router. Clients reach those devices at the IPv6 address or by MagicDNS names such as 10-1-1-16-via-7, and access rules name the IPv6 destination.
An exit node, once allowed by an admin, carries the internet traffic of every device that opts in to it. To work with another organisation, a tailnet can invite external users, who then have access like other members, including subnet routes, or share a single machine into another tailnet. A shared machine accepts connections from the other tailnet but does not start them, and it does not advertise its subnets there.
Most rows below follow from one design choice. Tailscale makes one trust domain reach further. Interconnect keeps two trust domains whole and lets a narrow, allow-listed flow pass between them at a host both have admitted.
| Tailscale, with a subnet router | Atlas Interconnect | |
|---|---|---|
| Trust domains | One tailnet: one coordination server, one policy file, one set of admins | Two networks, each with its own keys, admission and operator; the seam host is a member of both |
| Working with another organisation | Invite its users into the tailnet, or share single machines that accept connections, do not start them and carry no subnet routes | Each side admits the seam host as an ordinary member and writes its own export list; either side ends the join by revoking it |
| What clients do | Install the approved route; most platforms do so automatically, Linux opts in with --accept-routes | Mapped mode: nothing, the far host is an address in their own subnet. Prefix mode: the daemon installs the advertised prefix on its own tunnel interface (install_learned_routes, on by default) |
| Approving a route | An admin approves each advertised prefix, or an autoApprovers rule does | A prefix crosses only when both sides list it: one side’s route, the other side’s export, for each direction |
| The far side | A LAN of devices that do not run Tailscale, reached through the subnet router | Members of another Atlas network. Atlas has no subnet-router role: a LAN of hosts that do not run Atlas is not routed |
| Failover | Several subnet routers can advertise the same routes for high availability | Two seam hosts serving the same addresses: the other takes over within seconds, in both modes |
| Path | Tailnet devices connect directly where NAT allows, else through a peer relay or DERP; LAN traffic goes through the subnet router | Always through the seam host; on each side, the traffic takes that network’s own routed paths |
| Address the far side sees | The subnet router’s, by default; the real tailnet address on Linux with source translation turned off and a return route in place | Mapped mode: the sender’s mapped address in the far subnet. Prefix mode: the sender’s real address, nothing rewritten |
| Identical numbering | 4via6: each overlapping IPv4 site is reached under its own IPv6 prefix or a -via- name | Not supported: the two networks must not share an address space, in either mode. Mapped mode imports none of the far numbering into your routing, and partners numbered alike as each other each join you through their own seam |
| Bearers | WireGuard over the IP path the device has; each connection is direct, peer-relayed or through DERP | Atlas links on both sides: cellular, satellite, serial and mesh radios, hosted relays, scored and scheduled per packet, bonded where there are several |
| Encryption at the boundary | WireGuard between tailnet devices; the subnet router decrypts and forwards onto the LAN as plain IP | Encrypted on every link on both sides; payloads sealed end to end are opened at the seam and re-sealed for the far side |
| Who learns what | Every device and approved route of the tailnet is listed in its admin console | Neither network learns the other’s topology, members or keys; each sees only the addresses the other exports |
Tailscale rows follow Tailscale’s public documentation on subnet routers, 4via6, sharing, exit nodes, connection types and access control. Where a specific deployment differs, bring it to the conversation.
Both are sound designs for the problem each sets out to solve. The lists below are written for the same reader: someone choosing how to let one group of machines reach another.
-via- names rather than ordinary IPv4 addresses.A subnet router answers one question well, and it is one Interconnect does not answer: how do the devices of one tailnet reach a LAN that cannot run the client. The cases Atlas is built for ask different questions, and the two modes together answer them without asking any member, or any partner, to change.
A team’s phones, a relay on a mast and a drone on a serial radio cannot all be asked to accept new routes before a mission. Mapped mode makes the partner’s console one more address in their own subnet; prefix mode brings a partner’s whole ground-control network to the laptops whose daemons learn it from the adverts. Neither waits on a route approval or a client setting, and the traffic keeps riding the bonded links it already uses.
An agency and a contractor rarely agree to one set of admins over both their devices. With a seam, each keeps its own network, keys and admission. Each admits one host and writes one export list, and either side ends the join by revoking a single member.
Partners that use the same ranges as each other are routine in coalition and multi-vendor work. Mapped mode places each far host at an address chosen inside your own subnet, so nothing of a partner’s numbering enters your routing, and partners numbered alike as each other each join you through their own seam. The one rule: the two networks joined at a seam must not share an address space.
A partner should see the ground station and the video encoder, not the fleet. Export lists on both sides name exactly what takes part, gate both directions, and stop at the seam: nothing is redistributed, nothing chains, and neither network learns the other’s shape.
Tell us who runs each side, how each is numbered and what has to cross. The answer is a seam placement, a mode per flow and an export list for each side.