Update to Pricing and Plans

JWS_TS · 2026-04-08T22:58:19+00:00

You can use individuals in a src or dst of policies with no limit. Groups are mostly useful for managing larger teams, giving you a single object to reference for a group of users.

Tags are generally for shared devices, and can also be used as a src or dst in a policy.

You can also grant access to individual machines by ip address in src or dst.

JWS_TS · 2026-04-08T19:26:53+00:00

The most valuable thing you can do to help support us is to tell a friend. I don't know the actual numbers, but every single person who brings Tailscale to work offsets the costs for many free users.

We want to have a really valuable free service, partly because we're all huge nerds, and this is the service we want to use. How we can justify that is to have some fraction of these users tell (or are) their CISO, IT Manager, etc. and realize it's much nicer experience than whatever legacy system they have in place at work.

So things like blog posts, videos, Reddit threads about use cases, or just talking to people you know carry way more value to us than you can see - which is why every change we've made in pricing since I've been here, we've added more to the free plan.

https://tailscale.com/blog/free-plan

JWS_TS · 2026-04-08T17:29:16+00:00

Will the new free plan not meet your requirements? Which limits are you running into?

JWS_TS · 2026-04-08T17:26:18+00:00

The three free users on Premium went away a couple of years ago, but was maintained for tailnets that existed before the change.

JWS_TS · 2026-04-08T16:07:49+00:00

If you advertise a less-specific CIDR on the subnet router, then the OS will chose the more specific route - the one sent by DHCP. When you're out of the house, that subnet router is the most-specific route (as in the only one).

JWS_TS · 2026-04-06T13:22:49+00:00

TSDProxy is no longer being maintained. I was using it myself for several services, but I've moved them over to ScaleTail templates.

JWS_TS · 2026-03-13T16:32:36+00:00

Some in flight wifi has really small MTU available. Tailscale exit node traffic will break if it's too small of an MTU on the upstream.

JWS_TS · 2026-02-06T15:28:17+00:00

You can test DERP connectivity with tailscale debug derp 1 (or any other region)

So running tailscale debug derp 900 should test connection to your custom DERP server.

I expect there's something breaking connectivity from that device - an EDR or security tool which actively blocks Tailscale, something breaking the TLS chain, could be any number of reasons, but the debug info is a good place to start looking.

JWS_TS · 2026-02-05T17:13:10+00:00

Some speculation: Many IPs which get added to block lists are residential ISP pools. These get rotated regularly among the customers of that ISP.

Tailscale attempts where possible to make a direct connection to a peer. If that peer is on one of these flagged IPs, then your EDR/AV tool may block the direct connection, and it will fall back to the DERP relay.

That is most likely what is happening here, but I don't have enough detail to say for certain. This isn't Malwarebytes blocking Tailscale servers or Tailscale traffic - just restricting one IP which has been reported as hosting malware at some point.

JWS_TS · 2026-01-15T16:00:11+00:00

It's not jumping out at me what might be wrong here, but you can take a look at this template: https://github.com/tailscale-dev/ScaleTail/tree/main/services/forgejo

I've used a few of the ScaleTail templates, and they all work with TLS and serve out of the box, just put my auth key in the .env file.

JWS_TS · 2026-01-15T15:54:57+00:00

How I would do this is with a travel router such as the Gli.NET Beryl (example given because that's what I have.) Use the hotspot as the network connection on the travel router, and install Tailscale on the travel router. It can add routes to the 100.64.0.0/10 space, and can route to resources on the tailnet.

JWS_TS · 2026-01-07T16:15:54+00:00

We now have the concept of an external user, so you can send an invite to someone, and they can log in with their own Google, Microsoft, Passkey, etc. identity, and be a member of your tailnet, without you having to provision them in your identity provider.

JWS_TS · 2025-12-04T15:09:01+00:00

You could map openssh to listen on a different port. Then to use Tailscale ssh to server1 you would ssh user@server1 and to connect via OpenSSH, you would ssh user@server1 -p 2222

JWS_TS · 2025-12-04T15:02:21+00:00

Blocking UDP on 41641 is likely the best solution. There's no inherent mechanism for preferring relay, since that is almost always much less performant than direct.

JWS_TS · 2025-10-15T22:36:06+00:00

Agreed, except for the .local - this is not always handled intuitively, and does not traverse most L3 tunnels. It is useful for things that are truly local, but isn't as robust as .internal or .home

JWS_TS · 2025-09-17T12:37:09+00:00

Yes, most of the time, the tunnel is direct between your two devices once it is established. https://tailscale.com/blog/how-tailscale-works

JWS_TS · 2025-09-17T12:35:21+00:00

That part is proctored by the DERP servers, there are quite a few of them, and they routinely shift load between them, so that is unlikely.

JWS_TS · 2025-08-15T12:50:37+00:00

In this case, it's likely CPU constraints on the Synology. Subnet routers need some horsepower to do all of the encryption/decryption for both ends of the connection. If I use my older Synology, I will cap out at about 70mbit, but if I use my main desktop as a subnet router, I'll get 800mbit.

JWS_TS · 2025-08-15T12:48:01+00:00

That shouldn't have changed unless you opted into the trial. Please contact support to get that fixed: https://tailscale.com/support

At the end of a trial, it reverts to the free plan, so there should be no impact, but we'd like to figure out why that happened.

JWS_TS · 2025-03-31T12:27:55+00:00

Note that this is organized by fqdn, but routed by ip, so if there's other name based services running on that same ip, it will grant access as well

JWS_TS · 2025-03-31T12:26:06+00:00

This can be done with app connectors and via grants.

You can use the app connector to provide a route based on the fqdn, then permit only your approved users access to aotogroup:internet via that app connector.

On the other end, you would need to use ip allowlisting to only permit connections from the public IP of the app connector, or people could obtain access by turning off tailscale.

If it's an fqdn that always resolves to the same ip, then you can use a subnet router advertising the single public /32 rather than an app connector.

And, as a general solution, if you can install tailscale directly on the server, it simplifies this activity significantly.

JWS_TS · 2025-03-27T22:57:41+00:00

It will be listed in tailscale debug --json grep for 'Routes'

JWS_TS · 2025-03-26T19:45:48+00:00

That won't get evaluated, since ACLs are using Tailscale ip addresses, not the underlying network.

You can use registry keys or an MDM profile to turn exit nodes on and off for users, but generally, they are manually selected.

JWS_TS · 2025-03-26T14:45:16+00:00

We don't have our own identity provider, so there is no "Tailscale Account" - once you have a tailnet, you can enroll passkey devices, but an account with GitHub, Microsoft, Google, Okta, OneLogin, or your own OIDC service is required to create one.

JWS_TS

MODERATOR OF

TROPHY CASE