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
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
*:443because 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
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
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
tailscaledto 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).
tailscaledonly sends STUN to DERP servers, but the set of DERP servers expands over time so we recommend
*:3478in the rule.
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.
tailscale status command will return a table of results for every device it can see over Tailscale. For
1 2 3 4 5
220.127.116.11 device-a alice@ linux active; direct <ip-port>, tx 1116 rx 1124
18.104.22.168 device-b bob@ macOS active; relay <relay-server>, tx 1351 rx 4262
22.214.171.124 device-c charlie@ windows idle; tx 1214 rx 50
126.96.36.199 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
fra, etc.) for the respective location.
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.
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:
Additionally, the DERP relay servers (which will definitely change from time to time) are accessed via TCP port
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:
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.