标签：#tailscale

tailscale up --tun=userspace-networking gets you a green dot in the admin console and almost nothing else. The node appears in your tailnet, tailscale status looks healthy, and then you try to SSH into that container from your laptop and the connection hangs until TCP gives up. Two lines in the LXC config file fix it, and the container stays unprivileged. That's the whole post, really. But those two lines only make sense once you understand why every guide pushes you toward userspace mode in the first place, and what you're giving up by staying there. Who should care Anyone running services in unprivileged LXC containers on Proxmox who wants those containers to be real tailnet members with their own 100.64.0.0/10 address. Not reachable through something else. Reachable directly, over WireGuard, with a kernel network interface that ip addr can see. If you're already routing everything through a subnet router, you have a working setup and this is an optional upgrade. I covered that pattern in Tailscale Subnet Routers . Treat this as the next rung on the ladder: instead of one node advertising routes on behalf of everyone else, each container carries its own identity, its own ACL surface, and its own direct path to peers. What userspace networking actually costs you Every LXC-and-Tailscale guide I've read lands on the same instruction: pass --tun=userspace-networking and move on. It works because it sidesteps the problem entirely. Rather than asking the kernel for a TUN device, tailscaled runs a userspace TCP/IP stack (gVisor's netstack) inside its own process and never opens /dev/net/tun . Those costs stay invisible until you trip over one. Outbound traffic needs a proxy. In userspace mode, tailscaled exposes SOCKS5 and HTTP proxies on a local port. Nothing on the system routes to 100.64.0.0/10 automatically, because there is no interface and no route. Every client has to be told about the proxy: # userspace mode: this is the only way out export ALL_PROXY = socks5://l

If you've ever needed to let a third-party service talk to your local dev environment, you've probably reached for ngrok. I've been moving some of that over to Tailscale Funnel instead — here's what works, what broke, and how it stacks up against Cloudflare Tunnel. Key takeaways Tailscale Funnel exposes a local dev server to the public internet, similar to ngrok or Cloudflare Tunnel — useful for testing webhooks, payment callbacks, or anything a third party needs to reach on your machine. It's free for solo/small use, with no device limit on the Personal plan (up to 6 users). tailscale serve is tailnet-private; tailscale funnel is what actually makes something public — easy to mix up. Getting it working behind Caddy + Symfony in Docker means fixing two separate redirect loops (one from Symfony, one from Caddy's own auto-HTTPS) and explicitly telling Symfony to trust the proxy. The one real trade-off versus Cloudflare Tunnel: no custom domain with a valid cert — you're stuck with the ts.net hostname unless you accept a browser cert warning. This isn't a "ngrok / local tunnel / Cloudflare tunnel is bad" post. It's a "here's another tool that does the same job, and here's exactly what broke when I set it up" post. Why bother? A few reasons I looked at Tailscale instead of just defaulting to ngrok again: Stable hostname. ngrok's free tier gives you a random URL that changes every time you restart it. Tailscale Funnel gives you a fixed hostname tied to your machine ( your-machine.your-tailnet.ts.net ) that doesn't change. Genuinely free for solo/small use. Tailscale's free Personal plan covers up to 6 users with no device limit at all — plenty for a solo dev juggling a laptop, a desktop, and a couple of test machines. No "3 device" ceiling to bump into. Already in my toolchain. I use Tailscale for other things, so there's no new account, no new pricing tier to think about. Automatic HTTPS. Tailscale handles certificate provisioning for you — no separate cert step. The tr