# Tailscale Mesh Networking

A peer-to-peer VPN creating a private network across devices without exposing services publicly or configuring firewalls.

**Rests on:** WSL and VM Setup

*MLOps and Platform · Self-Hosting*


## Why learn this

This is the key that lets you reach your self-hosted services from anywhere — your phone, your laptop, a friend's house — without opening a single port to the public internet. It unlocks the rest of your self-hosting journey: you can run a private ChatGPT-style model at home and talk to it on the bus; you can check your security cameras from a hotel; you can log into your server remotely from a coffee shop. Without it, every one of those services either stays locked behind your home router or gets exposed to every bot on the internet. Master this and you'll be ready for the next steps: setting up automatic secure web certificates, managing groups of software containers, and planning backups that work across machines.


## The intuition

Think of your home network as a private club. The front door is your router — it decides who gets in. Normally, the only way to let an outsider in is to give them a key (a port forward) and leave the door unlocked, which also lets in anyone else who finds that key. Tailscale builds a secret tunnel that connects your devices directly, no matter where they are. Your phone, laptop, and server each install a small app, log in with your personal identity, and suddenly they can talk to each other as if they were all in the same room — but the tunnel is encrypted, and nobody outside can even see it exists. You don't open any ports, you don't configure firewalls, you don't expose anything to the public internet. Your devices find each other through a coordination server, but all the actual traffic goes directly from device to device (peer-to-peer), encrypted, between your own machines.


## An analogy

Imagine you have a group of friends, each in a different city, and you want to share a private letter-writing circle. Normally, to send a letter to one friend, you'd have to use their home address — and that address is public, so anyone could knock on their door. Tailscale is like giving each friend a secret mailbox that only the group knows about. The post office (Tailscale's coordination server) knows where each mailbox is, but it doesn't have the keys — only you and your friends do. When you want to send a message, the post office helps you find your friend's real location, but the actual letter travels in a sealed, encrypted envelope, and only your friend can open it. The post office never reads it, and crucially, the outside world never even knows the mailbox exists — there's no open door for strangers to find.

But the analogy has limits. The post office isn't just a directory — it also helps make the initial connection, and if your devices are on very restrictive networks, it might relay the traffic (encrypted) through its own servers, so it does see the envelope's outer wrapper, just not the contents. Also, the 'secret mailbox' isn't a physical box — it's a virtual network interface on each device. And the group isn't a fixed list; you join and leave different private networks (tailnets) as you please, and you can grant access to friends or family, not just your own devices.


## Definition

Tailscale is a direct-device-to-device private network that creates a secure overlay across all your devices using personal identity verification and encryption, so you can reach any device in the group from anywhere without opening ports or configuring firewalls.


## How it connects

This topic fits directly into your Self-Hosting series, right after you've got a server running with Docker Compose and before you add a secure web gateway. It answers the question 'how do I actually get to my services from outside my house?' The book 'Self-Hosting with Docker & Linux' specifically recommends a mesh private network like Tailscale over port-forwarding, because it lets you reach your services without exposing them to the public internet. You already have notes on Secure Web Gateway and Encryption — that's about giving your services a clean HTTPS entry point inside your network. Tailscale is the outer layer: it gets you into the network at all. You might also connect it to Container Management, because with Tailscale you can access containers on your server as if they were local, which makes finding services simpler. And it supports your Data Ownership and Privacy goals: nothing leaves your hardware except encrypted tunnel traffic, so your private data never touches a third-party server other than the coordination server, which only sees basic connection details.


## The mathematics

The core mathematical idea here is encryption, but you don't need to compute anything yourself — the software does it. Still, to understand what's happening, you need to know about the two main building blocks. First, there's a *shared secret*: two devices agree on a secret key (a long, random number) that both know but nobody else does. They use that key to scramble messages (encrypt) and unscramble them (decrypt). Anyone who intercepts the scrambled message sees only gibberish without the key. Second, there's the idea of a *handshake*: before two devices start chatting, they perform a cryptographic dance to prove each other's identity and agree on a session key. This uses public-key cryptography, where each device has a *public key* (which can be shared freely) and a *private key* (which is kept secret). A message can be encrypted with the public key, and only the matching private key can decrypt it. This lets two strangers verify each other and agree on a secret without ever sending the secret itself.

The mathematics of the encryption itself is beyond what we need — it's number theory, specifically modular arithmetic and prime numbers, but Tailscale uses well-tested algorithms (like WireGuard) that handle all that for you. What you, the learner, need is the conceptual model: there's a way for two devices to agree on a secret without sharing it, and that secret is used to encrypt all traffic. The rest is logistics — keeping track of which devices are on the network and how to reach them.

The shared secret agreement (Diffie–Hellman) is: 

1. A and B agree on a public prime `p` and base `g`.
2. A sends `g^a mod p`; B sends `g^b mod p`.
3. A computes `(g^b)^a mod p`; B computes `(g^a)^b mod p`.
4. Both get `g^(a*b) mod p` — the shared secret.

Here, `a` and `b` are the private random numbers, `^` means exponentiation, and `mod` gives the remainder after division by `p`.


## A worked example

```
Let's simplify the math to show the *concept* of a shared secret, using small numbers. Imagine two devices, A and B. They want to agree on a secret number, but they can only send numbers in public — anyone can read them.

Step 1: Device A picks a private number: a = 3   # This is A's secret, never sent.
Step 2: Device B picks a private number: b = 5   # B's secret, also never sent.
Step 3: They agree on a public base and modulus: g = 2, p = 11   # These can be public, but p must be a prime number.
Step 4: A sends to B: g^a mod p = 2^3 mod 11 = 8   # This is A's public message, computed as 2 to the power of 3, then the remainder when divided by 11.
Step 5: B sends to A: g^b mod p = 2^5 mod 11 = 32 mod 11 = 10   # B's public message.
Step 6: A computes: (B's message)^a mod p = 10^3 mod 11 = 1000 mod 11 = 10   # A takes the received 10 and raises it to their private number 3, then mod 11. The result is 10.
Step 7: B computes: (A's message)^b mod p = 8^5 mod 11 = 32768 mod 11 = 10   # B takes the received 8 and raises it to their private number 5, then mod 11. The result is also 10!
Step 8: Both now share the secret: 10   # An eavesdropper saw the numbers 2, 11, 8, and 10, but cannot compute the shared secret without brute-forcing the private numbers.

Result: Both devices now have the same secret number (10) without ever sending it directly. In reality, the numbers are huge (hundreds of digits), making brute-force impossible. That shared secret becomes the key for encrypting all subsequent traffic.
```


## From scratch, in Python

```python
# We won't implement real cryptography, but we'll show the *concept*
# of two devices agreeing on a secret, using the same steps as the maths section.

# Python's built-in pow() can do modular exponentiation efficiently.
# pow(base, exponent, modulus) = base^exponent mod modulus

p = 11   # a public prime (in real life, this is huge)
g = 2    # a public base

# Device A's private number (kept secret)
a = 3

# Device B's private number (kept secret)
b = 5

# Each device computes its public message
alice_public = pow(g, a, p)   # 2^3 mod 11 = 8
bob_public = pow(g, b, p)     # 2^5 mod 11 = 10

# They exchange public messages (in real life, over the wire)
# Now each device computes the shared secret using the other's public message

alice_shared_secret = pow(bob_public, a, p)     # 10^3 mod 11 = 10
bob_shared_secret = pow(alice_public, b, p)     # 8^5 mod 11 = 10

print("Alice's shared secret:", alice_shared_secret)
print("Bob's shared secret:", bob_shared_secret)

# Both print 10 — they agree on the same secret.
```


## What the code does

This Python script demonstrates the Diffie–Hellman key exchange, the core of how two devices agree on a secret. We use `pow(base, exponent, modulus)` — Python's built-in function for modular exponentiation, which computes `base^exponent` and then takes the remainder when dividing by `modulus`. This is exactly what the mathematics section did by hand, but with much larger, safer numbers in real use. The script sets `p = 11` and `g = 2` as public values (these are agreed upon in advance, and in reality `p` is a large prime). Then `a = 3` is Alice's private number, and `b = 5` is Bob's. Each computes a public message using `pow(g, a, p)` — Alice gets `8`, Bob gets `10`. They exchange these (that's the only thing an eavesdropper could see). Then, using the other's public message and their own private number, each computes the shared secret: Alice does `pow(10, 3, 11)`, which is `10^3 = 1000`, divided by 11 gives remainder 10; Bob does `pow(8, 5, 11)`, which is `32768`, divided by 11 also gives remainder 10. Both print 10. The magic is that they both end up with the same number without ever sending it. In Tailscale, this happens automatically for every pair of devices, using WireGuard, which is a modern implementation of this idea.


## Common misconceptions

**Tailscale is the same as a regular VPN that hides my internet activity.** — I turn on Tailscale and now my ISP can't see what websites I visit.

Tailscale is a peer-to-peer VPN for reaching *your own* devices, not for anonymising your internet traffic. It encrypts traffic between your devices, but when you access the public internet (say, to visit a website), that traffic goes out normally from your device's internet connection. Tailscale does not route your public browsing traffic through a privacy server. In fact: Tailscale creates a private network between *your own devices*. It encrypts traffic between them, but it does not hide your public internet activity. For anonymous browsing, you would use a different type of VPN (a consumer VPN) that routes all your traffic through a third-party server.

**Tailscale exposes my services to the internet.** — If I install Tailscale, my services are now accessible to anyone on the internet, like port forwarding.

This is the opposite of what Tailscale does. Tailscale does *not* open any ports on your router. Instead, it creates outbound-only encrypted tunnels. Your services are only reachable by devices that are logged into your tailnet. To a random internet scanner, your router still shows no open ports. In fact: Tailscale makes your services reachable *only* to devices in your tailnet. It does not expose them to the public internet. That is the core advantage over port forwarding.

**Tailscale has a central server that can see all my traffic.** — Tailscale's coordination server must be forwarding all my data, so the company can read my files.

The coordination server only helps devices find each other. Once a direct connection is established, all traffic goes peer-to-peer — encrypted with WireGuard. The coordination server cannot decrypt or read your traffic because it does not have the private keys. In fact: Tailscale's coordination server handles connection discovery and NAT traversal. After that, your data flows directly between your devices, encrypted end-to-end, and the server cannot read it.

**Tailscale requires opening ports or configuring firewalls.** — To use Tailscale, I need to set up port forwarding on my router or configure complex firewall rules.

This is the main reason people use Tailscale — to avoid all that. Tailscale works by making outbound connections to the coordination server, and then establishing peer-to-peer tunnels using NAT traversal (hole punching). It does not require any inbound open ports. In fact: Tailscale requires no inbound open ports or manual firewall configuration. You just install it on each device and log in, and it handles the rest.

**Tailscale is only for tech experts.** — I'm a beginner, I can't use a VPN that requires high-level networking knowledge.

Tailscale is designed to be extremely user-friendly. You install it, log in with an identity provider (like Google or GitHub), and your devices magically appear on a private network. The complexity is hidden. In fact: Tailscale is beginner-friendly. The hardest part is installing an app and logging in. The underlying technology is complex, but you don't need to understand it to benefit from it.


## In short

Tailscale lets you create a private network across all your devices using identity-based access, encryption, and peer-to-peer tunnels — no port forwarding, no firewall configuration. It is the secure, simple way to reach your self-hosted services from anywhere. You can think of it as a secret club: only members see the door, and only they have the keys. Install Tailscale on each device, log in once, and your services become reachable to you and your chosen friends, while being invisible to everyone else. Remember: it does not hide your general internet activity, but it does keep your own services private and encrypted.


## Where this is used

Tailscale is used all over the AI stack, mostly as the secure plumbing that connects the machines involved.

### Large Language Models (LLMs)
Training a large language model runs across thousands of GPUs in a data centre. The GPUs need to exchange gradients and model parameters constantly, usually over a high-speed internal network. Tailscale can be used to create an encrypted tunnel for these machines, particularly when training spans multiple clusters or cloud providers, where you don't want to expose internal services. More commonly, a developer working on fine-tuning a model on a home server uses Tailscale to SSH into that server from their laptop, or to run Jupyter notebooks hosted on the training box without opening a port. They might also use Tailscale to serve a private LLM API — you run an inference server on your own machine, and use Tailscale to give your other devices a private IP address to hit it, so the model and the data never touch a public server.

### Small Language Models (on-device)
When you run a small model locally on your phone or laptop, you often need to transfer data between the device and a bigger machine — say, to sync a local database or push new model weights. Tailscale provides a secure channel for that. A developer might write a sync script that pulls an updated model file over the tailnet, and trust that the transfer is encrypted. The key benefit is that you can run a lightweight model on your laptop and still access your full home server's model for heavy lifting, all through a virtual private network.

### Retrieval-Augmented Generation
RAG relies on embeddings and a vector database. Often the vector database lives on a home server, and the LLM runs on the edge device. Tailscale lets the edge device query the vector database over an encrypted tunnel without exposing the database to the internet. A developer writes a simple REST API call from their app, using the Tailscale-assigned IP address of the vector database host. The request travels encrypted, and the database is never port-forwarded. This is a common architecture for privacy-focused RAG, where documents never leave your control.

### Agentic Systems
Agents that plan and call tools often need to interact with many services — a calendar app, a code repository, a smart home hub. Tailscale ties all these together into a single private network. An agent running on your laptop can call a tool on your home server (e.g., a search over your personal files) using its tailnet IP. The developer writes the agent to use a list of internal addresses, and Tailscale handles authentication and encryption. No public IPs are needed, so there is no attack surface for internet scanners to find. If the agent needs to send a message to a phone, the phone is also on the tailnet, so the agent can push a notification directly.

### Everyday Machine Learning
For ordinary applied work, Tailscale is the go-to way to expose a Jupyter notebook, a model monitoring dashboard, or an API endpoint to a development team. A data scientist can start a server on their workstation and give a teammate access through Tailscale — no cloud VPS, no port forwarding, no firewall rules. It makes collaboration trivial while keeping the services private. If a model needs to be served for a small team, they can run a server on a spare machine, add all team members to the tailnet, and each one can hit the API at a private address.

### What a developer actually writes
A developer typically installs Tailscale on each device (a single command). Then they might write a small script to list their devices, or they simply use the Tailscale-assigned IP addresses (like `100.101.102.103`) in their configuration files. For example, a Docker Compose file for an LLM server might have an environment variable `API_BASE_URL=http://100.101.102.103:8080`. They don't configure any firewall rules. The heavy lifting is done by the Tailscale client, which maintains the encrypted tunnels.

### What breaks when it's done badly
If you skip Tailscale and use port forwarding, you expose your entire service to the internet — a single unpatched vulnerability can get your server compromised. If you configure Tailscale incorrectly, the most common failure is that the coordination server can't be reached (firewall blocks outbound connections to it), or you forget to enable login on a new device, so it can't join the tailnet. Another issue: if you rely on relay servers (when UDP is blocked), you get higher latency. But the biggest mistake is treating Tailscale as a security blanket and forgetting that your devices are still on a network — you must still keep software updated and use strong login methods.


---

Read this on the web: https://basavapurushottam.com/learn-ai/tailscale-mesh-networking
