Tailscale

All platforms

• New: The --reason flag is added to the tailscale down command.
• New: ReconnectAfter policy setting, which configures the maximum period of time between a user disconnecting Tailscale and the client automatically reconnecting.
• Changed: Tailscale CLI commands throw an error if multiple of the same flag are detected.
• Fixed: Network connectivity issues when creating a new profile or switching profiles while using an exit node.

Linux

• Fixed: DNS-over-TCP fallback works correctly with upstream servers reachable only via the tailnet. Windows
• New: AlwaysOn.Enabled and AlwaysOn.OverrideWithReason policy settings, which enable and configure a Tailscale client mode where the client stays connected at all times, unless an exception applies.
• New: When Always On mode is enabled, Tailscale connects as soon as a user signs in to the device and stays connected, regardless of whether the GUI is running. This enables access to tailnet resources, such as network-mapped drives, earlier in the sign-in process, and can also be used on headless Windows environments.
• New: EnableDNSRegistration policy setting, which configures whether Tailscale IP addresses should be registered with Active Directory DNS.
• New: The Tailscale GUI starts for all signed-in users when the client is installed.
• Fixed: DNS-over-TCP fallback works correctly with upstream servers reachable only via the tailnet.
• Fixed: Issue where the Tailscale GUI would not start if the client was installed via Group Policy or mobile device management (MDM) while a user was already signed in.
• Fixed: Issue where the Tailscale GUI did not auto-start after a client update.

macOS

• New: AlwaysOn.Enabled and AlwaysOn.OverrideWithReason policy settings, which enable and configure a Tailscale client mode where the client stays connected at all times, unless an exception applies. Changed: ForceEnabled policy setting is deprecated in favor of the AlwaysOn policy setting.
• Fixed: DNS-over-TCP fallback works correctly with upstream servers reachable only via the tailnet.
• Fixed: Tailscale automatically recreates and/or reactivates its VPN configuration on start.
• Fixed: Occasional crash in client during engine updates.
• Fixed: Taildrop share sheet displays the correct error page when the tunnel is not connected.
• Fixed: Hostname detection is improved in macOS clients running on macOS v15.x.
• Fixed: Client (GUI) logs are properly captured and recorded in bug reports.

iOS

• New: AlwaysOn.Enabled and AlwaysOn.OverrideWithReason policy settings, which enable and configure a Tailscale client mode where the client stays connected at all times, unless an exception applies.
• Changed: ForceEnabled policy setting is deprecated in favor of the AlwaysOn policy setting.
• Fixed: Taildrop share sheet displays the correct error page when the tunnel is not connected.
• Fixed: Tailscale automatically recreates and/or reactivates its VPN configuration on start.
• Fixed: Client (GUI) logs are properly captured and recorded in bug reports.
• Fixed: Occasional crash in client during engine updates. tvOS
• Fixed: Tailscale automatically recreates and/or reactivates its VPN configuration on start.
• Fixed: Client (GUI) logs are properly captured and recorded in bug reports.
• Fixed: Occasional crash in client during engine updates.

Android

• Fixed: Issue where Tailscale was disconnecting after excluding apps via split tunneling.

cross-posted from: https://infosec.pub/post/28466166

If you've followed any of my self-hosted headscale with Podman series, I wrote up another "bonus" post talking about OIDC configuration with Authelia. Took some trial and error, so I figured I'd document it in the public notebook.

Tailscale v1.82.1

• Note: v1.82.1 includes fixes for Android devices only, and is exclusively released for Android.

Android

• NEW: Device search is available on Android TV running Android 13 or later.

• NEW: Enhanced device search UI is available on all devices running Android 13 or later.

Tailscale v1.82.0

All platforms

• NEW: DERP functionality within the client supports certificate pinning for self-signed IP address certificates for those unable to use Let's Encrypt or WebPKI certificates.

• CHANGED: Go is updated to version 1.24.1

• CHANGED: NAT traversal code uses the DERP connection that a packet arrived on as an ultimate fallback route if no other information is available, in the event of a slow or misbehaving server.

• FIXED: Captive portal detection reliability is improved on some in-flight Wi-Fi networks, including British Airways and WestJet.

• FIXED: Port mapping success rate is improved by retrying in additional error cases.

macOS

• CHANGED: The .pkg installer size is decreased by 35%.
• FIXED: Memory leak issue related to shortcuts is resolved.
• FIXED: MagicDNS intermittent configuration failures no longer occur when waking from sleep.
• FIXED: Seamless key renewals occur as expected, ensuring the client remains connected.

iOS

• FIXED: Memory leak issue related to shortcuts is resolved.
• FIXED: MagicDNS intermittent configuration failures no longer occur when waking from sleep.

Android

• Note: The Android client release for v1.82.0 was delayed and moved into the v1.82.1 client release instead.

App connectors

• FIXED: Port mapping success rates for app connectors are improved.

I can't for the life of me figure this out:

I want to use tailscale on my home server as an exit node, but cannot seem to get it to do secure connections properly. I have Nginx Proxy Manager running on the same home server and I wonder if that's causing problems with the HTTPs encryption verification.

Has anyone had similar issues to this? I've tried messing with DNS resolution settings by overriding it to use the server's pihole setup as the DNS provider, but this hasn't helped either. I'm running out of ideas on ways I can try to solve this.

Hey all, I'm pretty illiterate when it comes to networking. I'm trying to set up a Foundry server on my PC, using Tailscale to bypass not having a public IP. The first time I set Tailscale up it worked perfectly, I asked a buddy to try and access and he reached the log in screen. The second time, when a session was supposed to happen, it didn't work; tailscaled.exe would launch and immediately quit . I was a few versions behind so I uninstalled, rebooted, installed the new version. Now, I'm getting those same errors regardless of what I do. I'm honestly not sure what to mess with to fix it. Any help would be appreciated.

I have a cloud VPS running Ubuntu with Tailscale installed directly. I also have Tailscale installed on my home server.

I'm trying to access my self-hosted applications from outside my home network which I did easily until I switched to fiber internet that uses CGNAT.

Tailscale is working locally but not outside my home network. A suggestion was to disable IP v4 on Tailscale since it conflicts with the CGNAT IP my ISP is using. However when I add the "disableIPv4": true to the config file in the access control area of Tailscale, I keep getting various errors.

Any help would be appreciated.

Hey all!

I'm trying to ssh into my tailnet-hosted (through tailscale serve) gogs instance and I can't seem to figure out how. Has anyone tried doing this? Will I need to add a user to the sidecar container and add a shim like they do in the regular gogs setup? I appreciate any insight.

Edit: Modified title for clarity

Heres the link to 1.66.1

Description: Unclear network flow logs collection status for alpha testers.

What happened?

When network flow logs first entered private alpha, tailnet admins who were interested in testing out the feature had to request to be manually opted into the alpha testing track. When we subsequently introduced admin console settings for self-serve network flow logs for the public beta launch, these settings were not properly connected to the alpha testing track. As a result, for the small number of tailnets that volunteered for alpha testing, the admin console interface did not show that logs were still being collected as initially requested.

We fixed this bug on April 25, 2024 and the admin console now correctly shows the status of network flow logs for all users.

Who was affected?

15 tailnets were opted into network flow log collection through the alpha testing track that did not re-enroll through the admin console. We notified security contacts for the affected tailnets about this bug.

What was the impact?

The admin panel did not reflect the correct status for network flow log collection for affected tailnets, and admins of these tailnets may not have realized that network flow logs were still being collected.

What do I need to do?

No action is needed at this time.

@tailscale Hello headscale users! Did anyone get headscale working in a non standard port? E.g. https://hs.example.com:8443/ ? For me It does not work and I think the tailscale clients still send some of the requests to the default port 443

Linux

• (New) Send load balancing hint HTTP request header

Windows

• (Fixed) Do not allow msiexec to reboot the operating system

macOS

• (Fixed) Issue that could cause the Tailscale system extension to not be installed upon app launch, when deploying Tailscale using MDM and using a configuration profile to pre-approve the VPN tunnel (applies to standalone variant only)

Synology

• (Fixed) IPv6 routing

Kubernetes operator

• (Fixed) Kubernetes operator proxies should not accept subnet routes

I'm looking into ways to access my home network which is behind a CGNAT. Tailscale looks like the best solution so far. I would like to clarify a doubt on Tailscale

I have a domain name registered with one of the popular services out there. I saw that Tailscale uses MagicDNS. But I wanted to use my personal domain. My doubt is if I want to use my custom domain with Tailscale, the following will be the procedure,

1. Setup Tailscale account and add machines.
2. My device inside the home network will get a Tailscale IP assigned. From 100.xx.xx.xx pool
3. Use this IP to configure an A record in my Domain registrar.

Now when I try to access this domain what will happen is,

1. DNS server will resolve the Tailscale IP.
2. The outside client will try to connect to my machine in the home network.
3. Tailscale takes care of the CGNAT part and helps to establish a direct connection.
4. Clients will use the public keys to establish trust and will communicate with each other.

If there is anything wrong in my understanding please correct me. I could not get a clear cut answer on this through searching.

Users page of the admin console updated to provide more context around user invitations, user approval, and your tailnet’s identity provider