Tailscale ports: what to open on your firewall

Which ports does Tailscale use?

Tailscale ports are almost all outbound, so most setups need no inbound firewall port at all. Each device starts its own connections out to Tailscale's servers. It then uses NAT (network address translation) traversal to reach other devices directly, and it falls back to Tailscale's DERP (designated encrypted relay for packets) servers when a direct path fails. An inbound port only helps direct connections, and it is optional.

Tailscale's own firewall FAQ, last validated on 2 February 2026, lists the traffic a device must be able to start. If your firewall blocks outbound traffic, these are the rules to add:

• TCP 443 outbound, to any address. Connections to the coordination server use HTTPS on port 443. The DERP relay servers are also reached on TCP 443, and Tailscale says their addresses will change from time to time. That is why the FAQ recommends allowing *:443 instead of a list of hosts.
• TCP 80 outbound, not mandatory. The coordination server prefers port 80 and falls back to HTTPS on 443 when 80 does not answer. If you block 80, clients can be slow to connect, and captive portal detection does not work properly.
• UDP 3478 outbound. This is STUN (session traversal utilities for NAT). STUN lets a machine behind NAT ask a machine on the open internet which IP address it sees. Tailscale uses the answer to work out what kind of NAT it is behind.
• UDP 41641, the WireGuard port. Direct WireGuard tunnels use UDP with a source port that defaults to 41641. The FAQ also suggests allowing outbound UDP from port 41641 to any address and port.

A firewall that already allows outbound traffic needs none of these rules. Tailscale's Ubuntu server guide, for example, sets sudo ufw default allow outgoing, and that one policy covers every item above. If you are new to the product itself, what Tailscale is and how it builds a mesh network explains the coordination server and the relays in more depth.

Tailscale does not use port 51820

Many forum answers tell you to open UDP 51820 for Tailscale. That port belongs to plain WireGuard examples. WireGuard's own quick start uses it in one command, wg set wg0 listen-port 51820, as an example listen port. Tailscale's firewall FAQ never mentions 51820. Its documented default is 41641.

The mix-up happens because Tailscale carries its traffic in WireGuard tunnels, but tailscaled manages those tunnels and uses its own port. A rule for 51820 matches nothing tailscaled is listening on, so it does not help Tailscale. If you also run a hand-built WireGuard server on the same VPS, keep its rule, because that is a different service. The difference between plain WireGuard and Tailscale covers when you would run each.

Do you need to open UDP 41641 on a VPS?

Not to make Tailscale work. A VPS with no inbound rule for Tailscale still joins the tailnet, because every connection it needs starts from the VPS. The inbound rule has one job. In the words of Tailscale's FAQ, permitting connections to that UDP port "may help Tailscale make a peer-to-peer connection, rather than falling back to a relay". It matters most when the device on the other end sits on a difficult network. Without the rule, traffic still flows through the relays, only more slowly.

On Ubuntu with ufw, this is the rule from Tailscale's FAQ. It is correct when the device uses the default port:

sudo ufw allow 41641/udp
sudo ufw status

The new rule should appear in the ufw status list. If you have not set ufw up yet, start with the ufw basics for a VPS and add the SSH rule before you enable it.

On Rocky Linux, AlmaLinux or Fedora with firewalld, the equivalent uses standard firewalld syntax. Tailscale's docs do not give a firewalld command, so this is firewalld's own --add-port option, not a Tailscale instruction:

sudo firewall-cmd --permanent --add-port=41641/udp
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

--permanent writes the rule to the saved configuration only. --reload makes the saved configuration the running one, so without it the rule does nothing until the next restart. The firewalld basics for a VPS explain zones, which decide where a port rule applies.

The provider's firewall is a separate layer

Many VPS providers offer a network firewall in their control panel. It filters traffic before the traffic reaches your server. A packet that the provider's firewall drops never arrives at ufw or firewalld, so a host rule alone cannot open the port. Tailscale's own Hetzner guide shows this. It allows UDP 41641 to ingress through Hetzner's cloud firewall so that Hetzner nodes can make direct connections. If your provider has a firewall like this and you want direct connections, add the same UDP rule there too.

Changing the port

Tailscale's FAQ says to set the port through the FLAGS variable in /etc/default/tailscaled, which the systemd unit includes. The tailscaled flag that does the work is --port, and its documented value 0 means "auto-select". Look at what your install actually ships before you edit anything:

systemctl cat tailscaled
cat /etc/default/tailscaled

In Tailscale's source tree, the defaults file sets PORT="41641" and an empty FLAGS="", and the unit runs tailscaled with --port=${PORT} $FLAGS. If your unit looks like that, change the PORT value. Adding --port to FLAGS as well would pass the flag twice. Then restart the daemon and check which UDP port it holds:

sudo systemctl restart tailscaled
sudo ss -ulpn | grep tailscaled

Run the restart from a public SSH session, not over Tailscale, because the restart stops the daemon that carries your session. Whatever port you choose, the ufw, firewalld and provider rules must name the same port.

Expose a service only to your tailnet

On a server, the most useful ufw rule for Tailscale is not about 41641 at all. Tailscale's Ubuntu server guide uses this pattern so that services are reachable only over Tailscale:

sudo ufw allow in on tailscale0
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw reload

allow in on tailscale0 accepts incoming packets that arrive on the Tailscale interface, tailscale0. With default deny incoming, a service that listens on every interface now answers devices in your tailnet and nothing on the public IP address. The guide then deletes the public SSH rule. Before you do that, open a second SSH session over Tailscale and confirm it works. If Tailscale is down when the public rule goes away, you are locked out and need your provider's console. Delete the rule by its number, which works however the rule was first written:

sudo ufw status numbered
sudo ufw delete 1

Use the number that ufw status numbered shows next to the public SSH rule. Do not type 1 blindly.

Docker breaks this pattern. Docker's own documentation says traffic to a published container port "gets diverted before it goes through the ufw firewall settings". A container started with -p 8080:80 is reachable on the public IP even when ufw denies 8080. Why Docker-published ports bypass ufw shows how to close that gap.

Relayed connections and Funnel

If Tailscale works but feels slow, the connection may be going through a relay. How to tell a direct Tailscale connection from a relayed one walks through the diagnosis. Funnel, which publishes a service to the public internet, has its own port rules, covered in Tailscale Funnel limits and the ports it allows.

FAQ

Do I need to open any ports for Tailscale?

Usually not. Tailscale's firewall FAQ says that most of the time you do not need to open any firewall ports. Each device starts its own outbound connections, on TCP 443 for the coordination server and the DERP relays, and uses NAT traversal to connect to other devices. If a direct connection fails, traffic goes through a relay instead.

Does Tailscale use port 51820?

No. 51820 is the port that plain WireGuard examples use, including WireGuard's own quick start. Tailscale's documented default for direct WireGuard tunnels is UDP 41641, and you can change it with tailscaled's --port flag. A firewall rule for 51820 does nothing for Tailscale.

Should I open UDP 41641 on my VPS?

It is optional. Tailscale says allowing connections to that port may help a peer-to-peer connection form instead of a relayed one. On Ubuntu the rule is sudo ufw allow 41641/udp. If your provider runs its own network firewall, the port must be allowed there too, because a packet dropped by the provider never reaches your server.

How do I make a service reachable only over Tailscale?

Use ufw with sudo ufw allow in on tailscale0, sudo ufw default deny incoming and sudo ufw default allow outgoing, then reload ufw. Services on the server then answer tailnet devices and not the public internet. Docker-published ports are the exception, because Docker routes that traffic before ufw sees it.