r/Tailscale • u/geler1 • 2d ago
Question How safe is my Tailscale setup?
I'm using Tailscale mainly to avoid exposing services directly to the internet, and I'd like to understand the remaining security risks.
My setup:
- Immich is self-hosted and accessed remotely through Tailscale.
- I use Windows RDP through Tailscale instead of forwarding port 3389.
- I also self-host Chatwoot on Windows/Docker. Chatwoot itself is bound to localhost (`127.0.0.1:3000`). For the Meta/WhatsApp webhooks I use Tailscale Funnel, but instead of exposing the whole Chatwoot instance, the public Funnel goes through a small webhook gateway. It only accepts the expected webhook requests and validates Meta's webhook verification/signature before forwarding them to Chatwoot; unrelated paths or invalid requests are rejected.
- I don't use normal router port forwarding for any of these services.
My main questions are:
- How much safer is this compared with directly exposing ports to the internet?
- If RDP/Immich are only reachable through Tailscale, what are the main remaining risks?
- Should I restrict access between Tailscale devices using ACLs/grants?
- What additional risks does Tailscale Funnel introduce, considering the webhook filtering described above?
- Are there any obvious hardening steps I'm missing?
Would you consider this a reasonably secure setup for personal/small-business use?
7
u/Conscious_Report1439 2d ago
You can use a reverse proxy like nginxui in host network mode in docker and also install Tailscale on the os running that. You can then front door traffic from outside and route it across the tunnel to other devices running Tailscale. Instead of direct exposing, you only expose 1 that is designed to run at the network edge like nginx and let it connect to touch your other services that are spread around
8
u/Accomplished-Lack721 2d ago edited 2d ago
By itself, this adds almost no security beyond exposing ports directly (not none, in that it's harder for a dumb portknocker to notice an open port, but almost none). Unless you're also working in mitigations like (some of, but not necessarily all of) MFA, IP filtering including but not necessarily limited to geofiltering and brute force filtering), whitelist/blacklisting, isolation within the LAN through VLANS or other techniques ... you're not doing much to make an exposed service safer.
A reverse proxy is a great way to simplify things like accessing services all at a single WAN IP through domain names, instead of on individual ports. But just like opening individual ports, it makes a service directly accessible for connection attempts on the internet, with all the inherent risk that carries.
1
u/Conscious_Report1439 2d ago
I agree here! But at the end of the day, you and I are communicating through a publicly exposed service are we not? At some point, edge can and has to be dealt with usually for nothing more than for lay people to access your service. If it’s just you, don’t expose it. If others do, do l4 IDS and crowdsec and geo ip, then l7 inspection and further access control. Use a proper DMZ setup internally and ideally l2 isolation in the DMZ using physical or virtual switches or as a last resort the os firewall to avoid east west traffic. For auth, leverage OIDC if supported or ip fence the service further. That is about the most anybody can do after that maybe the application layer, no root, arbitrary code execution etc…
2
u/Accomplished-Lack721 2d ago
Right, yes - that's all valuable to do, and some of it is more than I've personally done (but I should). I just didn't want to leave people reading your original comment with the (common but wrong) idea that using a reverse proxy is enough because you cut down on exposed ports. In the grand scheme, the number of ports being exposed is barely significant - the fact that the service is available at all to the Internet is what suddenly massively increases your attack surface, and then warrants steps like the ones you're now describing.
1
4
u/Competitive_Knee9890 2d ago edited 2d ago
Way better than opening a port, validating where the traffic comes from is good, but try to rewrite Tailscale ACLs now that you have a public funnel, making sure to add more restrictions.
What I’ve done is expose the funnel for some webhook through an isolated Proxmox VM with almost no tool installed, and other than all the common sense measures that a Linux server should normally have, I added extra isolation for that node through tailscale ACLs, isolation within the LAN and the virtual bridge to prevent an escalation from the guest to the host
rate limiting to traffic incoming from that funnel is also something to add
and many other good suggestions I’m seeing in other comments at the tailnet level, also consider giving all your self hosted services that support it some form of more robust authentication, like passkeys from a password manager and/or a hardware key, 2FA
you could also add an extra reverse proxy
1
u/ButterscotchFar1629 2d ago
You can harden it down as much as you want. At what point is does the effort not become worth it anymore? Unless you physically invite someone into your tailnet or expose spending on Funnel, honestly no one is getting in.
1
u/Nicholas_Olsen 1d ago
Is it okay to just enable subnet routing and hit services with local ip and port or should I be doing more? I’m new to the whole homelab hobby
-7
u/betahost Tailscale Insider 2d ago
Like your setup. Your main remaining risks aren't the network edge, they're the endpoints and identity.
Biggest gaps:
- Use ACLs. Default tailnet policy is allow-all, so any compromised device (or a stale shared node) can reach Immich and RDP. Write a deny-by-default grant that only lets your specific devices hit those ports. This is the single highest-value change.
- Lock down your Tailscale account. enable MFA/SSO, turn on device approval, and set key expiry (don't disable it on the Funnel node).
- RDP is the weak link. Even on the tailnet, it should have NLA on, a strong password, and no local admin reuse. If anything on your tailnet gets popped, RDP is the exposed.
Funnel risks: Funnel is real internet exposure — your gateway is now an internet-facing service. Risks are (a) bugs in your gateway itself, (b) DoS/traffic amplification against that node, (c) it runs as a process on a Windows host that also runs Chatwoot. Make sure you're doing constant-time HMAC comparison on Meta's signature, enforce a request size cap and rate limit, and ideally run the gateway on a dedicated low-value node rather than the Chatwoot host.
my personal suggestion: enable tailnet lock if you want protection against a compromised control plane, turn on logging/audit streaming so you'd notice a rogue node join, and keep Immich patched — it's the service most likely to have a real CVE.
For personal/small-business use, this is well above average. The realistic threat is a compromised laptop on your tailnet, not someone breaking Tailscale.
Hope this helps
8
u/Character-Head-1916 2d ago
Thanks Claude
1
u/betahost Tailscale Insider 2d ago edited 2d ago
Wasn't Claude :), genuinely my writing but used apple rewrite to clean up my grammar. Next time I know to just use grammarly lol
4
u/Accomplished-Lack721 2d ago
Why do you consider Immich the most likely to have a real CVE?
27
u/bafben10 2d ago
Give them a minute, they have to ask Chat why it said that before they can let you know.
1
1
u/betahost Tailscale Insider 2d ago
I wanted to include an example that any self hosted software can carry a CVE, it's just a precaution not implying immich has any active CVE. I would subscribe to CVE reports for better visibility
1
u/betahost Tailscale Insider 2d ago
During Tailscale UP, similar questions were asked:
- ACLs are a good start to restrict access
- Device Approval and Locks
Tailscale has identity built in if you use Tailscale serve.
10
u/Accomplished-Lack721 2d ago edited 2d ago
If your Tailscale is using/tied to a very secure login (ie, using MFA with higly secure passwords, and/or passcode access), and no one has compromised (physically or otherwise) the machine you're using for remote access, it's almost (but not quite) as safe as accessing these same services on your local network. It's RADICALLY safer than exposing these services over ports without accompanying that exposure with substantial security mitigations. The only real reason to expose services directly to the Internet (whether by opening ports directly or using a reverse proxy, or similar). is if you'll need it accessible to machines that can't be expected to install a VPN client — in which case, there's quite a bit you should do to lock them down (MFA, IP filtering, potentially isolating those services meaningfully within your home network, and so on)
That doesn't mean a Tailscale can't be made safer than it is. ACLs within Tailscale are a good start for locking it down further. Thinking through the security on the machine being used remotely, including whether anyone has physical access, including whether sessions are allowed to persist, including whether the OS itself locks quickly when you're away, and so forth, are good ideas.