{"slug":"what-firewall-ports-should-i-open-to-use-tailscale","title":"What firewall ports should I open to use Tailscale?","tags":["tailscale"],"agent_summary":"Last validated: Feb 2, 2026","trigger_phrases":[],"runnable":false,"markdown":"\r\n# What firewall ports should I open to use Tailscale?\r\n\r\nLast validated: Feb 2, 2026\r\n\r\nMost of the time, you [don't need to open any firewall ports for Tailscale](https://tailscale.com/docs/integrations/firewalls). Tailscale uses\r\n[various NAT traversal techniques](https://tailscale.com/blog/how-nat-traversal-works) to safely connect to other Tailscale nodes\r\nwithout manual intervention—it \"just works.\"\r\n\r\nHowever, when both devices are on difficult networks Tailscale may not be able to\r\nconnect devices peer-to-peer. You'll still be able to send and receive traffic,\r\nthanks to [our secure relays (DERP)](https://tailscale.com/docs/reference/derp-servers),\r\nbut the relayed connection won't be as fast as a peer-to-peer one.\r\n\r\nIn these cases, you may consider opening a firewall port to help Tailscale\r\nconnect peer-to-peer:\r\n\r\n- Let your internal devices start TCP connections to `*:443`.\r\n\r\nConnections to the [coordination server](https://tailscale.com/docs/concepts/control-data-planes#coordination-server) and other backend systems and data connections to the DERP relays use HTTPS on port `443`.\r\nThe set of DERP relays, in particular, grows over time. We recommend `*:443` because attempting to enumerate the set of\r\nallowed destinations is almost certain to break your connectivity in the future in ways which won't immediately resemble a\r\nfirewall issue. Nodes might lose all contact, or might only partially lose contact between what will appear to be random\r\npairs of devices because one of them is blocked from communicating with a specific DERP.\r\n\r\n- Let your internal devices start UDP **from**`:41641` to `*:*`.\r\n\r\nDirect WireGuard tunnels use UDP with source port `41641`. We recommend `*:*` because you cannot possibly predict every guest\r\nWi-fi, coffee shop, LTE provider, or hotel network that your users may be using.\r\n\r\n- Let your internal devices start UDP to `*:3478`.\r\n\r\nThe STUN protocol lets a machine behind NAT ask a machine on the open internet what IP address it sees, allowing the machine\r\nbehind NAT to figure out its public IP address. STUN also reports the port number seen, which lets `tailscaled` to\r\ndetermine if it is behind \"easy NAT\" (source port maps to the same external port for all destinations) or \"hard NAT\" (port\r\nnumber varies per destination). `tailscaled` only sends STUN to DERP servers, but the set of DERP servers expands over time\r\nso we recommend `*:3478` in the rule.\r\n\r\n- Let your internal devices start HTTP (TCP) connections to `*:80`.\r\n\r\nConnections to the [coordination server](https://tailscale.com/docs/concepts/control-data-planes#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`.\r\n\r\nFor [captive portal](https://tailscale.com/docs/integrations/captive-portals) 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.\r\n\r\nIt is not mandatory to allow 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.\r\n\r\n\r\nIn July of 2025, the domains `login.tailscale.com` and `controlplane.tailscale.com` began resolving to static IP address ranges registered to Tailscale.\r\n\r\nWe recommend configuring firewalls using domain names rather than hardcoding IP addresses. However, if IP-based rules are required, the following ranges should be explicitly allowed:\r\n\r\n- **IPv4**: `192.200.0.0/24`\r\n- **IPv6**: `2606:B740:49::/48`\r\n\r\nScheduled for November of 2025, the domain `log.tailscale.com` will resolve to static IP address ranges registered to Tailscale.\r\n\r\nWe recommend configuring firewalls using domain names rather than hardcoding IP addresses. However, if IP-based rules are required, the following ranges should be explicitly allowed:\r\n\r\n- **IPv4**: `199.165.136.0/24`\r\n- **IPv6**: `2606:B740:1::/48`\r\n\r\n## [How can I tell if my devices are using a relay?](https://tailscale.com/docs/reference/faq/firewall-ports\\#how-can-i-tell-if-my-devices-are-using-a-relay)\r\n\r\nRelays are used per-device-pair. To check if a device is talking to another device over a relay, run\r\n`tailscale status` ( [docs](https://tailscale.com/docs/reference/tailscale-cli)) from either device.\r\n\r\nThe `tailscale status` command will return a table of results for every device it can access over Tailscale. For\r\nexample:\r\n\r\n```markup\r\n1 2 3 4 5\r\n100.1.2.3 device-a alice@ linux active; direct , tx 1116 rx 1124\r\n100.4.5.6 device-b bob@ macOS active; relay , tx 1351 rx 4262\r\n100.7.8.9 device-c charlie@ windows idle; tx 1214 rx 50\r\n100.0.1.2 device-d diane@ iOS -\r\n```\r\n\r\nIf a device is active in the tailnet, for the connection status (column 5) will contain \"direct\" for peer-to-peer connections,\r\nalong 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.\r\n\r\n## [My devices are using a relay. What can I do to help them connect peer-to-peer?](https://tailscale.com/docs/reference/faq/firewall-ports\\#my-devices-are-using-a-relay-what-can-i-do-to-help-them-connect-peer-to-peer)\r\n\r\nIf two of your devices are on difficult networks, allowing connections to UDP\r\nport `41641` on one of them may help Tailscale make a peer-to-peer connection,\r\nrather than falling back to a relay.\r\n\r\nOn Ubuntu, for example, you can do this with the built-in `ufw` command by running:\r\n\r\n```shell\r\nsudo ufw allow 41641/udp\r\n```\r\n\r\nFor more information on NAT traversal, our blog post [_How NAT Traversal Works_](https://tailscale.com/blog/how-nat-traversal-works)\r\nshares all the details.\r\n\r\n## [What if I really, really want to specify the hostnames that Tailscale uses to operate its service?](https://tailscale.com/docs/reference/faq/firewall-ports\\#what-if-i-really-really-want-to-specify-the-hostnames-that-tailscale-uses-to-operate-its-service)\r\n\r\nIn situations where this is unavoidable you can allow exceptions for a list of fully qualified domain names (FQDNs). We\r\nstrongly recommend automating the process of keeping the allowed hostnames in sync to ensure you minimize disruption from\r\nchanges made to Tailscale's infrastructure.\r\n\r\nThe list of **coordination servers** (required for authentication, key exchange, firewall updates, and so on) is likely\r\nto change, but infrequently:\r\n\r\n- `console.tailscale.com`\r\n- `controlplane.tailscale.com`\r\n- `log.tailscale.com`\r\n- `login.tailscale.com`\r\n\r\nAdditionally, the **DERP relay servers** (which will definitely change from time to time) are accessed at TCP port `443`.\r\nDERP 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.\r\n\r\nSo your allowlist of DERP DNS entries would look like:\r\n\r\n- `derp1-all.tailscale.com`\r\n- `derp2-all.tailscale.com`\r\n- `...`\r\n- `derp28-all.tailscale.com`\r\n\r\nIf you have [removed Tailscale's DERP regions](https://tailscale.com/docs/reference/derp-servers/custom-derp-servers#optional-remove-tailscales-derp-servers) from your DERP map, you can skip the DNS entries for the\r\nremoved regions.\r\n\r\nDERP servers are frequently added or changed, depending on user locations, to optimally serve Tailscale customers. After\r\na DERP server is added or changed, Tailscale updates DNS entries about 15 minutes later. To access the up-to-date list of\r\nTailscale DERP servers, visit the [DERP map](https://login.tailscale.com/derpmap/default).\r\nAlternatively, you can run this command:\r\n\r\n```shell\r\ncurl https://login.tailscale.com/derpmap/default | jq\r\n```\r\n\r\nOnce you've identified the servers, add the relevant A and AAAA records to your firewall configuration.\r\n\r\nIf your firewall is able to accept a DNS entry to add L3 tailnet policy file entries, will add all the A and AAAA\r\nrecords 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.\r\n\r\n![Project Logo](https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed)\r\n\r\nAsk AI\r\n\r\nreCAPTCHA\r\n\r\nRecaptcha requires verification.\r\n\r\nprotected by **reCAPTCHA**\r\n","html":"

What firewall ports should I open to use Tailscale?

\n

Last validated: Feb 2, 2026

\n

Most of the time, you don't need to open any firewall ports for Tailscale. Tailscale uses\r\nvarious NAT traversal techniques to safely connect to other Tailscale nodes\r\nwithout manual intervention—it \"just works.\"

\n

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

\n

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

\n\n

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

\n\n

Direct WireGuard tunnels use UDP with source port 41641. We recommend *:* because you cannot possibly predict every guest\r\nWi-fi, coffee shop, LTE provider, or hotel network that your users may be using.

\n\n

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

\n\n

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.

\n

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.

\n

It is not mandatory to allow 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.

\n

In July of 2025, the domains login.tailscale.com and controlplane.tailscale.com began resolving to static IP address ranges registered to Tailscale.

\n

We recommend configuring firewalls using domain names rather than hardcoding IP addresses. However, if IP-based rules are required, the following ranges should be explicitly allowed:

\n\n

Scheduled for November of 2025, the domain log.tailscale.com will resolve to static IP address ranges registered to Tailscale.

\n

We recommend configuring firewalls using domain names rather than hardcoding IP addresses. However, if IP-based rules are required, the following ranges should be explicitly allowed:

\n\n

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

\n

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

\n

The tailscale status command will return a table of results for every device it can access over Tailscale. For\r\nexample:

\n
1           2         3          4         5\r\n100.1.2.3   device-a  alice@     linux     active; direct <ip-port>, tx 1116 rx 1124\r\n100.4.5.6   device-b  bob@       macOS     active; relay <relay-server>, tx 1351 rx 4262\r\n100.7.8.9   device-c  charlie@   windows   idle; tx 1214 rx 50\r\n100.0.1.2   device-d  diane@     iOS       -\n
\n

If a device is active in the tailnet, for the connection status (column 5) will contain \"direct\" for peer-to-peer connections,\r\nalong 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.

\n

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

\n

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

\n

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

\n
sudo ufw allow 41641/udp\n
\n

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

\n

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

\n

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

\n

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

\n\n

Additionally, the DERP relay servers (which will definitely change from time to time) are accessed at TCP port 443.\r\nDERP 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.

\n

So your allowlist of DERP DNS entries would look like:

\n\n

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

\n

DERP servers are frequently added or changed, depending on user locations, to optimally serve Tailscale customers. After\r\na DERP server is added or changed, Tailscale updates DNS entries about 15 minutes later. To access the up-to-date list of\r\nTailscale DERP servers, visit the DERP map.\r\nAlternatively, you can run this command:

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

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

\n

If your firewall is able to accept a DNS entry to add L3 tailnet policy file entries, will add all the A and AAAA\r\nrecords 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.

\n

\"Project

\n

Ask AI

\n

reCAPTCHA

\n

Recaptcha requires verification.

\n

protected by reCAPTCHA

\n"}