Troubleshooting guide

This article contains various suggestions and tips to help troubleshoot setup and connectivity issues. If you have additional issues, contact support.

I can’t send/receive pings from Windows or macOS

Windows generally has aggressive firewall rules set up, even for ICMP (ping) traffic (both incoming and outgoing). Be sure that you’ve enabled your Windows machines to be able to both send and receive ICMP traffic.

A faster, but riskier approach to test this is to (temporarily) disable the Windows firewalls to see if it makes any impact.

Similarly, macOS’ “stealth mode” will prevent macOS from responding to pings. This can be enabled/disabled in your Mac’s Security & Privacy settings.

Refer to this issue for updates on improving related notifications and user experience.

My macOS client gets stuck at Loading backend...

Do you have a virus scanner (or other form of endpoint security) such as ESET installed? In some cases we’ve found that security measures interfere with Tailscale’s operation.

My firewall blocks everything by default. Which ports do I need to open?

Refer to this article.

Two of my devices have the same 100.x IP address

This can occur if you use a backup of one machine to create another, or clone a filesystem from one machine to another. The Tailscale configuration files are duplicated. The Tailscale files will need to be removed from one of the two.

You can identify duplicated devices in the admin console by looking for a “Duplicate node key” badge underneath the device name.

On one of the systems, uninstall and completely delete the Tailscale app. It is especially important to remove the files listed for your platform, the goal is to make a new Tailscale IP address when it is installed again.

Then, reinstall the app.

I have managed to set up Tailscale on my Mac and iPhone. How do I access my Mac’s files from my iPhone?

  1. Open the Files app on your iPhone.
  2. Go to the Browse tab.
  3. Tap the ... in the top right.
  4. Tap Connect to Server and enter your Mac’s Tailscale IP address.

At this point, any folders shared by your Mac (via SMB) are browseable.

How do I know if my traffic is being routed through DERP?

Use the Tailscale CLI to run the tailscale status command. If you see output in the form of relay "code", then your traffic is being routed via a relay server that has “code” as its location. For example, the second line in this tailscale status output indicates traffic is being routed through the “sea” (Seattle) relay server:

100.99.98.97 node1 linux active; direct 1.2.3.4:1234; tx 1000 rx 1000
100.99.98.96 node2 linux active; relay "sea", tx 1000 rx 1000

If there is no relay "code" line in the tailscale status output, then your traffic is not being routed through DERP.

Also, the tailscale ping command will indicate whether a successful ping was by direct path or via DERP. tailscale ping will keep trying until it either sends 10 pings (the default if not using the --c flag) through the relays, or finds a direct path. For example, if the first five pings were relayed and the sixth ping was a direct path, tailscale ping will stop. This tailscale ping node2 example indicates the node was reached via the “sea” relay on the first ping, and via direct path on the second ping, at which time tailscale ping stopped.

tailscale ping node2

pong from node2 (100.99.98.96) via DERP(sea) in 242ms
pong from node2 (100.99.98.96) via 1.2.3.4:1234 in 127ms

Can I route all of my traffic through a default route?

Yes! On Tailscale, you can define an exit node, which automatically configures default routes on your behalf.

If you want to force your traffic through a particular IP (to handle an IP blocklist — a.k.a. an IP allowlist) you can also route only a subset of your traffic using subnets. See the article on connecting to external services with IP blocklists via Tailscale for more details.

Why do I get an error about IP forwarding when using advertise-routes?

Tailscale’s routing features (subnet routers and exit nodes) require IP forwarding to be enabled. If it is not enabled, you may see an error when using --advertise-routes or --advertise-exit-node.

To learn how to do this for your Linux device, see how to enable IP forwarding.

How can I see the IP routes Tailscale installs?

As of v0.99 Tailscale routes moved into a separate routing table (to prevent routing loops in subnet routers), which the legacy netstat tool doesn’t display.

To see routes installed by Tailscale use ip route instead

ip route show table 52

How can I disable subnet route masquerading?

You can disable subnet route masquerading with

tailscale up --snat-subnet-routes=false

Note that SNAT allows transparent communication to the rest of the network by re-writing the source IP address to that of the subnet router. If you disable subnet route masquerading, NAT traffic to local routes that are advertised with --advertise-routes will need to have routing manually configured.

How do I deploy Tailscale to a large fleet of devices?

You’ll want to use Tailscale’s pre-authenticated keys feature, which let you authenticate devices by key rather than in-browser.

As an admin, you can create keys in the admin console once you’re logged in.

I set up –advertise-routes=172.0.0.0/8 for AWS access, and now Google doesn’t work

Only part of the 172.0.0.0/8 range is private, the rest is public address space and Google has IP addresses in that range for some of its datacenters.

You can safely advertise the 172.16.0.0/12 range instead:

tailscale up --advertise-routes=172.16.0.0/12

I use the Tally ERP software package, which says “Unable to access the configured Tally Gateway Server” when Tailscale is active

Tally appears to bind to interfaces in a way which conflicts with VPN software like Tailscale. If the license server is running on the local PC, changing the Tally configuration via the UI or by editing Tally.ini to use “127.0.0.1:9999” as the license server instead of using the PC hostname allows it to work.

Updated Windows machine stops connecting to Tailscale

As part of some Windows 10 and Windows 11 updates, the SYSTEM user’s %LocalAppData%, usually at C:\WINDOWS\system32\config\systemprofile\AppData\Local, is wiped. This directory is where Tailscale 1.14.3 and earlier stored its internal state.

If you upgraded your Windows machine and lost connectivity to Tailscale, you can either:

  1. (Recommended) Remove the old machine using the admin console, and then re-login to Tailscale from the affected Windows device. This needs both a Tailscale admin and someone with access to the device to take action.
    • Navigate to the Machines tab of the admin console. Find the row corresponding to the machine that is affected. Click on the ellipsis icon at the far right and select the Remove option. This will remove the machine from your tailnet.
    • Upgrade the affected Windows device to Tailscale v1.14.4 or later.
    • The affected Windows device should now prompt you to log in again to rejoin your tailnet. If device authorization is enabled, the device will need to be re-authorized.
    • With this option, the machine will retain the same name, but have a new IP address.
  2. Remove the remaining Tailscale state files from the Windows device, and then re-login to Tailscale. This does not require an admin to take action, unless device authorization is enabled.
    • For the affected machine, remove all files in the %LocalAppData%\Tailscale directory. To do this, you can open cmd.exe and run
      rmdir /s %LocalAppData%\Tailscale\
    • Upgrade the affected Windows device to Tailscale v1.14.4 or later.
    • Re-login to Tailscale on the device. If device authorization is enabled, the device will need to be re-authorized by an administrator.
    • With this option, the machine will be assigned a new name (e.g., old-name-1), and have a new IP address. The machine’s old name will still be listed in the admin console until it is removed. At that time, the admin can rename the new device to the old name.

To avoid this issue in the future, upgrade Windows machines to 1.14.4 or later prior to performing a Windows update.

Unable to log in from legacy Windows

If you are using Windows 7 or Windows Server 2008, and there is no response when you click the Tailscale Login button, it is possibly due to a silent failure. To correct this issue, try installing the Microsoft hotfix.

If you do not want to install the hotfix, an alternative is to run tailscale up from the command line.

My mobile device’s battery drains too quickly

Unfortunately, this is a known issue, particularly where a device is using an exit node for all traffic. This is because all traffic, including background traffic, from the mobile device will go through the exit node.

If possible, use Tailscale without an exit node.

Unable to make a TCP connection between two nodes

If your nodes are visible in the admin console, and there is no ACL rule blocking connections between the nodes, check the level of connectivity with Tailscale’s three types of ping: ping 100.x.x.x tells the OS to send an ICMP ping across the tailnet. tailscale ping 100.x.x.x tests whether the two tailscaled processes can communicate at all, and how (direct, or relayed). tailscale ping --tsmp 100.x.x.x sends a packet that goes one level further than tailscale ping, also going through the WireGuard level, but doesn’t involve the host’s networking stack.

Packet size limits can also cause connection problems on certain types of networks.

Tailscale uses a MTU of 1280. If there are other interfaces which might send a packets larger than this, those packets might get dropped silently. These can be verified by using tcpdump.

In order to solve this, we can set the MTU at the LAN level to a lower value, or use MSS (Maxiumum Segment Size) clamping..

Unable to connect to internal services with DNS errors

If you are using DNS names to access internal services and some people have difficulty connecting to those services, the problem may be caused by DNS Rebinding Protection.

How to prioritize LAN traffic with overlapping subnet routes

You may have a LAN subnet that contains a mix of both Tailscale nodes, and non-Tailscale nodes that all must accept routes in order to communicate with a second subnet. In this condition routing can become asymmetric leading to new configuration challenges. In order to work around this challenge, there are different solutions depending on the operating system of the affected node.

Using the solutions described below on non-fixed network interfaces, such as WiFi on a laptop could lead to a situation where the node sends traffic to a public LAN network that was intended for the Tailscale network. We recommend that these solutions only be used where the network configurations of the subnets and nodes that access them are well known and fixed.
Windows & macOS

On both Windows and macOS, routes are accepted by default. The operating system will prioritize routes with the longest prefix match, or in other words the most specific of all configured routes. A solution for overlapping subnet routers is therefore to adjust the Tailscale advertised route to be less specific than the LAN subnets that you wish to avoid routing conflicts with. If for example you have a LAN subnet of 192.168.2.0/24 and you wish to avoid routing traffic to that subnet through Tailscale when nodes are on this LAN segment, you can configure the subnet router to advertise a route of 192.168.2.0/23.

Linux

On Linux, the --accept-routes flag must be passed explicitly to tailscale up in order to accept subnet routes from other nodes on the tailnet. Tailscale on Linux uses a routing feature known as policy routing that introduces an additional layer of prioritization to routing.

Tailscale uses ip rules in the priority range of 5200 to 5500 to prioritize routes, at this time 5210, 5230, 5250 and 5270.

On OpenWRT systems detected as running mwan3, Tailscale rules are installed at a lower priority for compatibility reasons. On such systems, ip rules are installed with priorities ranging 1300-1400 instead of 5200-5300.

Install a rule ahead of the Tailscale rules that uses lookup to jump over them:

ip rule add to 192.168.2.0/24 priority 2500 lookup main

The above command installs a rule that matches traffic destined for 192.168.2.0/24 in a rule with priority 2500 (a higher priority than the Tailscale rules). When matched, the rule jumps to the main routing table, which is the default routing table. This rule will therefore take precedence over the Tailscale rules, and use the regular LAN routes in the main routing table.

Note that this change is not persistent, and will need to be applied on boot. systemd-networkd users may look to the RoutingPolicyRule configuration option in systemd.network(5). The configuration can also be applied in a “oneshot” service as described in systemd.service(5).

Last updated

WireGuard is a registered
trademark of Jason A. Donenfeld.

© 2022 Tailscale Inc.

Privacy & Terms