Make Tailscale NAT Traversal More Stable with Peer Relay

Dec 18, 2025

In a Tailscale network, when two devices can’t establish a direct P2P connection, traffic usually has to go through a DERP (Designated Encrypted Relay for Packets) server. In October 2025, Tailscale introduced the Peer Relay feature, making NAT traversal simpler and more stable.

Peer Relay lets you designate any device in your Tailnet as a relay node to forward encrypted traffic between other devices. When two devices can’t connect directly, Tailscale will try Peer Relay first, and only fall back to the official DERP servers if no relay is available.

TL;DR: Peer Relay turns one of your own machines into a dedicated relay station.

Peer Relay vs DERP

DERP characteristics

DERP servers are maintained by Tailscale with global node coverage, automatically selecting the nearest node. No extra configuration needed. But self-hosted DERP requires a domain and SSL certificate, and in some regions requires domain registration (ICP filing). There’s also the concern of many users sharing the same DERP node.

Tailscale doesn’t have DERP servers in certain regions, so the experience can be poor.

Peer Relay characteristics

Peer Relay doesn’t need a domain, certificate, or registration. Free users can configure up to 2 relay nodes.

Prerequisites

Before starting, make sure: (1) All devices are running Tailscale 1.86 or later. (2) You have at least one server accessible to other nodes.

Configuration Tutorial

Step 1: Prepare a server with a public IP

You need a server with a public IP as the relay node. This can be:

A VPS from a cloud provider
A home broadband device with a public IP
A device in a Full Cone NAT environment

Step 2: Enable Peer Relay on the relay server

Run the following command on the server acting as a relay:

tailscale set --relay-server-port=40000

Notes:

The port number 40000 can be changed to any open UDP port
Use a high port number above 20000 to avoid blocked ports

Firewall configuration:

Make sure the UDP port is open on both the server firewall and cloud provider security group:

# If using UFW
sudo ufw allow 40000/udp

# If using firewalld
sudo firewall-cmd --permanent --add-port=40000/udp
sudo firewall-cmd --reload

# If using iptables
sudo iptables -A INPUT -p udp --dport 40000 -j ACCEPT

Also open the port in your cloud provider’s security group console.

Step 3: Configure ACL rules

Method 1: Using device IP (recommended, no tags needed)

Add the following to the grants section:

"grants": [
    {
        "src": ["*"],
        "dst": ["100.x.x.x"],  // Replace with the relay server's Tailscale IP
        "app": {"tailscale.com/cap/relay": []},
    },
    {
        "src": ["*"],
        "dst": ["*"],
        "ip":  ["*"],
    }
],

Configuration notes:

src: ["*"]: Allow all devices to use this relay
dst: ["100.x.x.x"]: The relay server’s Tailscale IP
The second rule allows devices to access the relay node itself

Method 2: Using tags (suitable for multiple nodes)

If you have multiple relay nodes or need fine-grained control, use tags:

1. Tag the relay server:

tailscale up --advertise-tags=tag:relay

2. Configure tag owners in ACL:

"tagOwners": {
    "tag:relay": ["autogroup:member"],
    "tag:srv": ["autogroup:member"],
},

3. Configure grants rules:

"grants": [
    {
        "src": ["tag:srv"],
        "dst": ["tag:relay"],
        "app": {"tailscale.com/cap/relay": []},
    },
    {
        "src": ["tag:srv"],
        "dst": ["tag:relay"],
        "ip":  ["*"],
    }
],

Note: Using tags disables Tailscale’s file transfer feature (Taildrop). If you use Taildrop frequently, use Method 1 instead.

Step 4: Verify the configuration

On any client device, run:

tailscale ping <target device's Tailscale IP or hostname>

If configured correctly, you’ll see output like:

pong from device (100.x.x.x) via DERP(xxx) in 82ms
pong from device (100.x.x.x) via peer-relay(14.103.xx.xx:40000) in 12ms
pong from device (100.x.x.x) via peer-relay(14.103.xx.xx:40000) in 11ms

The first connection may go through DERP, but it quickly switches to peer-relay with noticeably lower latency.

You can also check the status with:

tailscale status

If you see peer-relay in the output, the relay is working.

FAQ

1. Can Peer Relay fully replace DERP?

No. Peer Relay only forwards traffic. It can’t replace DERP’s NAT traversal (STUN) functionality. Keep DERP as a fallback.

2. Can I use Peer Relay without a public IP?

In theory, Port Forwarding can work in a Full Cone NAT environment, but in practice the external IP may not match what Tailscale shows, causing issues. A server with a public IP is recommended.

3. Where’s the bandwidth bottleneck?

The relay node’s bandwidth is the bottleneck. Choose a server with sufficient bandwidth.