Tailscale

226 readers
10 users here now

A community for the Tailscale WireGuard-based VPN. https://tailscale.com/

founded 2 years ago
MODERATORS
1
 
 

The goal is to share an http service privately on my tailnet but with an HTTPs connection. It seems others have spent lots of time figuring out and never sharing their solutions. I just got a setup to work satisfactorily so I'll share it. Criticism is welcome. First a few notes:

  • I'm using headscale on a VPS behind Caddy.
  • Official tailscale allegedly can do this out of the box with tailscale serve or tailscale cert.
  • Headscale supports tailscale serve but not with https. Maybe if I removed caddy and let headscale to https directly it would. I haven't tested that yet.
  • Yes I know https over wireguard is redundant. This effort is not only to make Firefox shut up but to make some clients that demand https work.

I also have deliberately avoided the "Private CA" because installing the cert of every client on my tailnet sounds like a nightmare. If someone can prove me wrong there, please share.

The context

  1. I have a VPS and a public domain with DNS A and AAAA records that point all sub domains *.mydomain.net to that VPS.
  2. The VPS runs caddy and headscale and is on the tailnet itself.
  3. Caddy route the hs subdomain to headscale.
  4. I have numerous devices on my tailnet, many running different http services but only some of them I want public.
  5. I can publicly expose a service with https by simply adding an entry to caddy like so,
publicservice.mydomain.net {
    reverse_proxy privatehost:8080
}

Restart caddy and that's it.

The solution

First, I used sub domains of the public domain instead of headscales base domain. eg Use *.ts.mydomain.net instead of ts.net. I made a *.ts.mydomain.net A record pointing to my servers public IP. Caddy will automatically fetch https certificates for any *.mydomain.net domains automatically. It cannot for a domain not routed to it. (DNS01 authentication might circumvent this but I haven't tested that yet).

Second, I restrict caddy to only accept tailscale connections by using the bind directive. Otherwise it will accept and route public traffic. A caddy entry for a private service would look like this,

privateservice.ts.mydomain.net {
    bind 100.64.0.1 [fd7a:115c:a1e0::1]
    reverse_proxy privatehost:8081
}

The IP addresses come from the output of tailscale ip on the caddy/headscale machine.

Now privateservice.ts.mydomain.net routes to the caddy server with https but it gets a default blank 200 response from caddy because its coming from the machine's public IP instead of the tailnet.

The almost last step is to configure headscale's MagicDNS to route private services to the headscale server on its its tailscale IP instead of omthe public IP. Take the IPv4 and IPv6 addresses and make an A and AAAA records,

# /etc/headscale/config.yaml
# ...
dns:
  magic_dns: true
  # base_domain is irrelevant
  nameservers:
    global: [ whatever ]
    split:
        # required to override the public dns records
        ts.mydomain.net: 100.100.100.100
  extra_records:
     - type: "A"
       name: "privateservice.mydomain.net"
       value: "100.64.0.1"
     - type: "AAAA"
       name: "privateservice.mydomain.net"
       value: "fd7a:115c:a1e0::1"
     # repeat for each service

You can have base_domain be whatever or make it ts.mydomain.net if you want to be consistent and aren't worried about collisions with your extra records.

I tried using wildcard DNS records in headscale and it didn't work. It felt like it completely broke DNS without any clear warnings or errors. Idk if that's a bug or what. DNS just timed out internally

Limitations

All internal HTTPS traffic is routed through my VPS instead of directly peer to peer, which is a real bummer for internal latency. I think the only way around that is to give each internal host their own caddy server, have the DNS records point directly to them, but then use a private CA and all the hassle that's worth. Maybe DNS01 challenges will work...

Also while I have no public records indicating what private subdomains I have beyond *.ts.mydomain.net for DNS, I do have them for my TLS certificates... somewhere. I'm not super concerned about that though. I think only a private CA will hide those.

2
3
 
 

So I use the nemo file browser. I also started using Tailscale recently. I liked the idea of using Taildrop but I wanted a way to not have to use the command line every time. (I don't mind the command line but sometimes, especially for books, I use the file browser). So in ~/.local/share/nemo/actions/taildrop.nemo_action I added the following:

[Nemo Action]
Name=Send to iPad
Comment=Send file %F to iPad
Exec=sh -c "tailscale file cp %F ipad:"
Icon-Name=edit-copy
Selection=notnone
Extensions=nodirs
Separator=,
Dependencies=tailscale

Note, you'll want to change ipad to whatever device you want to send files to. But now, I can right click on a file and click Send to iPad and off it goes! You also might need to do sudo tailscale set --operator=$USER first to be able to run as your user. But if you can run tailscale file cp ... in your terminal (without sudo) it should work.

Of course, it doesn't have to be an iPad, that's just what I have. You can make one for any device you want to send files to.

4
5
 
 

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.
6
 
 

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.

7
8
6
submitted 1 year ago* (last edited 1 year ago) by neme@lemm.ee to c/tailscale@programming.dev
 
 

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.
9
 
 

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.

10
11
12
 
 

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.

13
 
 

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.

14
 
 

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

15
16
17
18
19
20
21
7
TS-2024-004 (tailscale.com)
submitted 2 years ago* (last edited 2 years ago) by mac@programming.dev to c/tailscale@programming.dev
 
 

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.

22
 
 

@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

23
24
 
 

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
25
view more: next ›