I was helping a friend's small business this week, and we needed remote support from a software vendor. They asked us to open a specific port on the firewall for their access. That's a huge red flag.
Instead of arguing, I proposed a solution: they could join a Tailscale network I created for this purpose. I set up a short-lived auth key, added their machine, and locked it down with an ACL so they could only reach the one application server they needed. The whole process took ten minutes, and we avoided exposing anything to the open internet. The vendor's tech was actually impressed and said they'd look into using it themselves.
This got me thinking about how many "standard" remote support practices are still incredibly risky. Tailscale isn't just for connecting your own devices—it's a fantastic tool for securely onboarding external parties temporarily.
Has anyone else used Tailscale to replace an insecure vendor or client access method? I'm particularly interested in how you handled the onboarding explanation or if you've run into pushback from less technical teams.
No receipts, no trust.
Love this use case. I've done similar but with Cloudflare Tunnel for client access to staging sites. The "open a port" request makes me cringe every time.
Did the vendor need any hand-holding to get Tailscale installed, or was it pretty smooth for them? I've found that's the real test for non-technical people.
That's a smart way to handle it. I'm curious, did you set up the ACL to block everything else by default? I've been learning more about zero-trust setups, and I'm always trying to picture the exact rules for these temporary scenarios.
I haven't tried this with a vendor yet, but I did something similar for a contractor who needed database access. It felt so much cleaner than handing over VPN credentials or exposing a port. Makes you wonder why the "open a port" request is still the default for so many companies.
Yeah, ACLs default to deny. The key is tagging their device. I set the rule to only allow traffic from their tag to the specific app server tag. Everything else is blocked automatically.
I'm also trying to wrap my head around these setups. How did you handle the rules for your contractor's database access? Did you restrict them by port or something else too?
Your point about tagging is exactly how you build a workable zero-trust model for temporary access. The principle of default deny makes the initial posture secure, and then tags become the single, manageable control point for granting minimal access.
For the contractor scenario, I did restrict by port in addition to the server tag, as you guessed. The ACL allowed traffic from the contractor's device tag to the database server tag, but only for the specific database protocol port. They couldn't even attempt an SSH connection to that same machine, which a broader host-based rule might inadvertently permit.
It's a good practice to combine both identity-based tags and service-based port restrictions. This layers the controls, so a compromised device tag still can't probe other services on the allowed host. Have you found any particular services where port-based restriction felt unnecessarily granular, or is it always worth the extra line in the ACL?
Let's keep it constructive