What firewall ports should I open to use Tailscale?

Nearly all of the time, you don't need to open any firewall ports for Tailscale. Tailscale uses various NAT traversal techniques to safely connect to other Tailscale nodes without manual intervention—it "just works."

However, when both devices are on difficult networks Tailscale may not be able to connect devices peer-to-peer. You'll still be able to send and receive traffic, thanks to our secure relays (DERP), but the relayed connection won't be as fast as a peer-to-peer one.

In these cases, you may consider opening a firewall port to help Tailscale connect peer-to-peer:

Let your internal devices initiate TCP connections to *:443.

Connections to the control server and other backend systems and data connections to the DERP relays use HTTPS on port 443. The set of DERP relays, in particular, grows over time. We recommend *:443 because attempting to enumerate the set of allowed destinations is almost certain to break your connectivity in the future in ways which won't immediately resemble a firewall issue. Nodes might lose all contact, or might only partially lose contact between what will appear to be random pairs of devices because one of them is blocked from communicating with a specific DERP.
Let your internal devices initiate UDP from :41641 to *:*.

Direct WireGuard tunnels use UDP with source port 41641. We recommend *:* because you cannot possibly predict every guest Wi-fi, coffee shop, LTE provider, or hotel network that your users may be using.
Let your internal devices initiate UDP to *:3478.

The STUN protocol lets a machine behind NAT ask a machine on the open internet what IP address it sees, allowing the machine behind NAT to figure out its public IP address. STUN also reports the port number seen, which allows tailscaled to determine if it is behind "easy NAT" (source port maps to the same external port for all destinations) or "hard NAT" (port number varies per destination). tailscaled only sends STUN to DERP servers, but the set of DERP servers expands over time so we recommend *:3478 in the rule.

How can I tell if my devices are using a relay?

Relays are used per-device-pair. To check if a device is talking to another device over a relay, run tailscale status (docs) from either device.

The tailscale status command will return a table of results for every device it can see over Tailscale. For example:

1           2         3          4         5
100.1.2.3   device-a  alice@     linux     active; direct <ip-port>, tx 1116 rx 1124
100.4.5.6   device-b  bob@       macOS     active; relay <relay-server>, tx 1351 rx 4262
100.7.8.9   device-c  charlie@   windows   idle; tx 1214 rx 50
100.0.1.2   device-d  diane@     iOS       —

If a device is active on the tailnet, for the connection status (column 5) you'll see "direct" for peer-to-peer connections, along with the IP address used to connect, or "relay" for connections using DERP, along with a city code, such as nyc or fra, for the respective location.

My devices are using a relay. What can I do to help them connect peer-to-peer?

If two of your devices are on difficult networks, allowing connections to UDP port 41641 on one of them may help Tailscale make a peer-to-peer connection, rather than falling back to a relay.

On Ubuntu, for example, you can do this with the built-in ufw command by running:

sudo ufw allow 41641/udp

For more details on NAT traversal, our blog post How NAT Traversal Works shares all the details.

What if I really, really want to specify the hostnames that Tailscale uses to operate its service?

In situations where this is unavoidable you can allow exceptions for a list of fully qualified domain names (FQDNs). We strongly recommend automating the process of keeping the allowed hostnames in sync to ensure you minimize disruption from changes made to Tailscale's infrastructure.

The list of coordination servers (required for authentication, key exchange, firewall updates, and so on) is likely to change, but infrequently:

login.tailscale.com
controlplane.tailscale.com
log.tailscale.com
log.tailscale.io

Additionally, the DERP relay servers (which will definitely change from time to time) are accessed via TCP port 443. DERP servers are named as derpN where 1 <= *N* <= 25 as of January 2024 (the upper range for N is likely to increase). Tailscale creates a derpN-all entry with multiple A records, one A record per DERP server in the region.

So your allowlist of DERP DNS entries would look like:

derp1-all.tailscale.com
derp2-all.tailscale.com
...
derp25-all.tailscale.com

If you have removed Tailscale's DERP regions from your DERP map, you can skip the DNS entries for the removed regions.

DERP servers are frequently added or changed, depending on user locations, to optimally serve Tailscale customers. After a DERP server is added or changed, Tailscale updates DNS entries about 15 minutes later. To see the up-to-date list of Tailscale DERP servers, view the DERP map at https://login.tailscale.com/derpmap/default. Alternatively, you can run this command:

curl https://login.tailscale.com/derpmap/default | jq

Once you've identified the servers, add the relevant A and AAAA records to your firewall configuration.

If your firewall is able to accept a DNS entry to add L3 ACL entries, will add all of the A and AAAA records it finds, and will periodically refresh its ACL entries by refetching from DNS, you can configure the derpN-all.tailscale.com entries and then not need to constantly update the list of DERP servers.