What firewall ports should I open to use Tailscale?

Most 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 start TCP connections to *:443.

  Connections to the coordination 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 permitted 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 start UDP from :41641 to *:*.

  Direct WireGuard tunnels use UDP with a source port that defaults to 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.

  41641 is the default port but it can be reconfigured. If you have changed the port on a device, substitute your configured value. For guidance on changing the port on each platform, refer to Confirm or change the UDP port.

• Let your internal devices start UDP to *:3478.

  The STUN protocol lets a machine behind NAT ask a machine on the open internet what IP address it sees, so that the machine behind NAT can figure out its public IP address. STUN also reports the port number seen, which lets 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.

• Let your internal devices start HTTP (TCP) connections to *:80.

  Connections to the coordination server prefer to use HTTP on port 80 with an efficient encrypted transport. However, if the coordination server doesn't respond on this port, the client will fall back to using HTTPS on port 443.

  For captive portal detection and notifications, Tailscale attempts to contact a set of relay servers that are known to accept incoming connections on TCP port 80. The client executes an unencrypted HTTP request reaching out to a /generate_204 endpoint on the relay server. This endpoint is expected to return an HTTP response with a 204 status code.

  It is not mandatory to permit these connections, and you can choose to drop them in your firewall rules, resulting in a timeout. If disabled, clients might experience delays when connecting to Tailscale and captive portal detection won't function properly.

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 access 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 in the tailnet, for the connection status (column 5) will contain "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, permitting connections to the UDP port that one of them listens on may help Tailscale make a peer-to-peer connection, rather than falling back to a relay.

41641 is the default UDP port, but it can be reconfigured, so confirm which port a device uses before you write firewall rules for it. For more information, refer to Confirm or change the UDP port.

On Ubuntu, for example, if a device uses the default port, you can permit it with the built-in ufw command by running:

sudo ufw allow 41641/udp

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

Confirm or change the UDP port

Tailscale listens for direct peer-to-peer WireGuard traffic on UDP port 41641 by default. You can reconfigure this port, so the value a given device uses might differ. How you set it depends on the platform.

• Linux: Set the port through the FLAGS variable in /etc/default/tailscaled, which the systemd unit definition includes.
• NixOS: NixOS manages /etc/default/tailscaled as part of its declarative configuration, so set the port through your NixOS configuration rather than editing the file directly.
• Windows: The port defaults to 41641. You can change it by setting PORT=N in the tailscaled-env.txt file.

For more on setting tailscaled flags and environment variables on each platform, including the --port flag, refer to the tailscaled daemon reference.

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

In situations where this is unavoidable you can permit exceptions for a list of fully qualified domain names (FQDNs). We strongly recommend automating the process of keeping the permitted 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:

• console.tailscale.com
• controlplane.tailscale.com
• log.tailscale.com
• login.tailscale.com

Additionally, the DERP relay servers (which will definitely change from time to time) are accessed at TCP port 443. DERP servers are named as derpN where 1 <= *N* <= 28 as of August 2025 (the upper range for N is likely to increase). Tailscale creates a derpN-all entry with multiple A (IPv4) and AAAA (IPv6) records, one 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
• ...
• derp28-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 access the up-to-date list of Tailscale DERP servers, visit the DERP map. 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 tailnet policy file entries, will add all the A and AAAA records it finds, and will periodically refresh its tailnet policy file entries by re-fetching from DNS, you can configure the derpN-all.tailscale.com entries and then not need to constantly update the list of DERP servers.