We started using Tailscale because SSH access had become annoying.
PANDAROSE operates systems across several cloud providers, internal networks, development environments, and client infrastructure. Our old approach relied on public IP allowlists, SSH tunnels, traditional VPNs, and enough firewall rules that changing Internet providers could become a small administrative event. The setup was reasonably secure. It was also becoming complicated to maintain.
An administrator working from a known office IP could reach SSH. The same administrator working from home, a client site, or a hotel needed another rule, another tunnel, or another VPN profile. Residential IP addresses changed. Cloud providers each had their own firewall interfaces. Internal machines required their own paths. Every reasonable exception added another small piece of operational archaeology.
Moving SSH to a strange port does not solve this problem. It mostly makes the log file more hipster.
We wanted developers and administrators to reach the systems they were authorized to use without publishing those services to the Internet and without treating every new location as a firewall project.
Tailscale gave us a cleaner answer. Then it kept becoming useful in places we had not originally considered. The question gradually changed from:
How do we expose this service safely?
to:
Why does this service need to be publicly exposed at all?
That change now influences how we handle SSH, internal applications, IBM i systems, development environments, cloud administration, security monitoring, remote work, and selected backup paths. Port forwarding is wonderfully simple right up until Shodan sends you a Christmas card.
Tailscale changed the access model
Tailscale is a mesh VPN built on WireGuard. Its control plane coordinates identities, public keys, devices, routes, and policy, while the encrypted data plane runs between the participating devices. Tailscale tries to establish direct peer-to-peer connections and can fall back to encrypted relays when network conditions prevent a direct path.
For the user, the practical result is straightforward. An approved laptop can reach an approved private resource even when the two systems are behind different firewalls, hosted by different providers, or connected through different Internet services.
For the administrator, access becomes organized around identity and policy rather than a growing scrapbook of public IP addresses.
We use Microsoft Entra ID as the identity provider. Tailscale can authenticate users through Entra, and its access controls tie users, devices, tags, and resources together. Current Tailscale grants follow a deny-by-default model, allowing administrators to specify which identities or systems can reach particular destinations.
That lets us express a business rule directly. A development group may reach selected development systems. An administrator may reach protected infrastructure. A client laptop may reach the IBM i resources it needs without inheriting access to every other device on the client network. In other words, the policy starts resembling the organization rather than the physical location of the firewall.
Traditional hub-and-spoke VPNs remain useful, especially for stable site-to-site connections and environments already designed around a central gateway. Tailscale gives us another option for distributed users and systems. It removes a surprising amount of routing and firewall ceremony while preserving narrowly defined access.
The tool should fit the access problem. Networking becomes expensive when the architecture turns into a religious affiliation.
Tailscale and YubiKey-backed SSH changed the equation
The moment that fully sold me involved combining Tailscale with YubiKey-backed SSH authentication.
Our SSH services are reachable from approved PANDAROSE devices through the private Tailscale network. The public Internet does not receive an ordinary path to those services. Reaching the server still requires the correct SSH credential, which we protect with YubiKeys for privileged access. You see, OpenSSH supports FIDO2-backed SSH credentials. Thus, the private credential remains protected by the hardware security key, and cryptographic operations can require physical user presence through a touch. In general, we also encourage all of our team to use PIN verification, and thus have another layer of protection.
That gives us several separate controls. Entra establishes the organizational identity. Tailscale determines whether the user and device can reach the server. SSH still verifies its own credential. The YubiKey keeps the privileged key material attached to a physical authenticator. In other words, stealing a laptop does not automatically provide the SSH credential.
This does not make a compromised endpoint harmless. Malware controlling an active session can still cause serious trouble, and a YubiKey does not replace endpoint protection, patching, monitoring, or judgment. What it does mean is that an attacker must defeat several independent controls instead of finding one password that somebody reused during the Obama administration.
We discussed our broader use of physical security keys in Microsoft Is Retiring Native SMS MFA. Honestly, Good. Phishing-resistant identity and private network access complement each other extremely well. T
ailscale makes the service difficult to reach from the wrong device. The YubiKey makes the credential difficult to use without the correct physical token. That feels considerably healthier than trusting a password and the comforting belief that nobody knows the port number.
MagicDNS turned the tailnet into a private intranet
MagicDNS initially looks like a small convenience. Tailscale automatically gives devices on the tailnet sensible internal names, so authorized users can connect to monitoring, development, or another recognizable machine name instead of memorizing private IP addresses or maintaining a spreadsheet that slowly becomes archaeological evidence.
That feature is useful on its own. IP addresses are implementation details, and most people have better things to remember.
The larger DNS capability is considerably more interesting.
Tailscale can direct queries for selected internal domains to private DNS servers reachable through the tailnet. This split-DNS approach lets an organization maintain an internal namespace while ordinary public DNS continues operating normally. Tailscale refers to these as restricted nameservers because they apply only to the specified internal domains.
We use that model to create ordinary, browsable names for internal applications, dashboards, documentation, administrative tools, development systems, and security infrastructure. Those resources do not require public DNS records or public login pages. They exist inside the private environment for the people and devices authorized to reach them.
Internally, this larger collection is what we casually mean when we refer to “the tailnet.” It has become less like a list of connected computers and more like a sprawling private intranet.
Applications can link to one another. Documentation can point directly at the system it describes. A developer, administrator, or support person can move through the environment much as they would through the public web, except the useful parts only exist for approved identities and devices.
We add another identity layer at the application itself. Tailscale determines whether the device has a network path to the service. Our OAuth-based application controls determine whether the person using that device is allowed through the front door. YubiKey-backed authentication adds physical credential protection where the risk justifies it.
The result feels almost absurdly convenient.
Open the laptop. Authenticate properly. Visit an internal hostname. The network, DNS, organizational identity, and application authorization quietly line up behind the request.
There is no public port, no public login page, and no bookmark folder full of IP addresses and strange port numbers. The employee does not need to know which subnet, tunnel, or cloud provider happens to contain the system they need.
It is difficult not to call that magic.
The IBM i stopped feeling remote
One of our favourite client uses involves IBM i, still commonly called AS400 by almost everyone who has to use one.
These systems often live inside private networks and cannot simply run the Tailscale client directly. A Tailscale subnet router can advertise a route to devices on that network, including legacy systems and appliances where installing Tailscale is not practical. Access-control policy still limits which tailnet identities can reach the advertised subnet.
For one class of client setup, an approved laptop can reach only the IBM i resources required by that user. The employee signs into the laptop, and the IBM i feels as though it is simply available, whether the person is working from the office, home, or somewhere else.
The user does not have to launch a broad VPN, find the correct profile, or understand which internal route contains the green screen.
The experience became easier while the access became narrower.
IT has spent decades teaching people to assume those goals are natural enemies.
This approach can be particularly useful for remote employees, multiple offices, industrial sites, travelling staff, and businesses that depend on legacy systems without wanting those systems exposed publicly. Our AS400 and IBM i support team can preserve the existing system of record while creating a carefully controlled path from modern devices.
We explored the same philosophy in Green Screens, Dot Matrix Printers, and the Business Logic Nobody Wants to Admit Is Brilliant. Modernization often works best when it builds a sane bridge to the system that still knows the truth.
Tailscale has become one of the more useful bridge components in our toolbox.
Private systems can behave like ordinary applications
PANDAROSE operates internal dashboards, security systems, administrative tools, monitoring interfaces, and development environments that need to be available from several locations.
I am extremely happy those systems exist.
I am equally happy the public Internet cannot see them.
I am not going to describe the architecture in detail because this is a marketing article rather than a treasure map.
The useful point is that authorized machines can reach these services through the private network while public traffic has no ordinary route to them. Internal applications can use the private DNS namespace, application-level authentication, and narrowly scoped access policy.
This has changed what we are willing to build internally. A security dashboard can remain private from its first deployment. A development system can behave like a real networked application without becoming an Internet-facing service merely because a developer needs to reach it from home. Internal CRM and administrative tools can remain available to approved staff without being published for every automated scanner on Earth to inspect.
The architecture also supports centralized monitoring and auditing across systems hosted with several providers. Limited webhooks and tightly controlled integration points can feed internal tools without requiring the tools themselves to become public.
This builds on the philosophy in Why We Trust Boring Infrastructure. Good infrastructure removes recurring pain and fragile exceptions until secure access feels ordinary.
The underlying engineering may be sophisticated.
The employee experience should not require a CompTIA certification.
Remote access should feel as though the user never left
The owner travelling internationally should be able to open an approved laptop, authenticate properly, and reach the private systems the business has authorized.
The developer working from another location should reach a development environment without asking someone to whitelist the hotel’s current IP. A support technician should reach the client resource involved in a ticket without receiving the rest of the client network as a complimentary side dish.
Tailscale exit nodes provide another useful option. An approved device can route its Internet traffic through a trusted node in the tailnet. We use that selectively when working from networks we do not particularly trust. Exit-node use is explicit, and its routing and DNS effects need to be tested properly.
An exit node does not transform airport Wi-Fi into holy ground. It gives the device an encrypted path to a trusted egress point and reduces the trust placed in the local network.
The same private connectivity has helped with unusual offsite backup arrangements. Tailscale provides the route, while proper credentials, isolation, monitoring, retention, and restore testing still provide the recovery discipline.
We learned the importance of that distinction in It Wasn’t Production Until It Was. Reduced exposure prevents some incidents. Tested recovery keeps the incidents that still happen from becoming existential.
And yes, we have also used Tailscale to make Plex accessible without casually exposing another public port.
Eventually all advanced networking architecture converges on somebody wanting to watch a movie from a hotel room.
Tailscale has not replaced entropy
Tailscale has caused us a few interesting afternoons.
MagicDNS and split DNS can interact awkwardly with unusual Linux resolver configurations, containers, DHCP clients, and competing network-management tools. Tailscale’s own Linux documentation discusses the various ways DNS managers and /etc/resolv.conf can disagree about who is in charge.
We resolved the problems we encountered, although some required considerably more investigation than the word Magic suggested.
Exit nodes are useful, but they change routing and DNS behaviour. Local-network access, resolver configuration, performance, and device state all need to be understood before the company routes everybody’s traffic through one and calls it finished.
Pricing matters as well. Tailscale began as a focused solution to an SSH-access problem and has become increasingly central to our infrastructure. That makes changes to plans, entitlements, and pricing much more significant than they were during the proof of concept.
None of this diminishes the value we receive from the product. It means Tailscale has graduated from “interesting tool” to “architectural dependency.”
Dependencies deserve active management.
A product can earn trust without receiving blind trust.
Important infrastructure deserves an exit plan
Tailscale has earned an important place in our production infrastructure. That is precisely why Stefen has been lab-testing alternatives and complementary platforms.
One of those platforms is Pangolin.
Pangolin describes itself as an open-source, identity-based remote-access platform built on WireGuard. It combines reverse-proxy and VPN capabilities. Public resources can be made available through browser-based application access, while private resources can be restricted to specific users, hosts, or network ranges through a client. Pangolin can also be self-hosted.
We have not settled on Pangolin, and we are not presenting it as a production replacement for Tailscale. Our testing remains in the lab. It currently requires more technical involvement and has not given us the same confidence around nontechnical user experience.
The experiment exists because important systems deserve contingency planning.
A vendor can experience a security incident. Pricing can change. Product direction can shift. An organization’s requirements can eventually outgrow the solution that served it well for years. Waiting until that happens before learning the alternatives converts ordinary vendor dependence into an emergency.
The responsible approach is to understand the dependency, document the architecture, and preserve enough technical competence to adapt later.
Tailscale is the tool we trust in production today.
The lab makes sure that trust never becomes helplessness.
Secure access should feel easier
The most important result from our Tailscale work has been the combination of reduced exposure and simpler access.
SSH no longer needs a public listener. Internal applications can have ordinary names without public DNS records. IBM i users can reach narrowly defined resources without manually launching a broad VPN. Developers can use realistic environments from several locations. Travelling staff can open an approved laptop and work as though the private systems are nearby.
The user receives convenience. The organization retains control.
That is the experience PANDAROSE aims to create through managed IT support, security and IT risk reviews, technical consulting, enterprise integration, and secure IBM i connectivity.
A modern private network should give approved users a clear path, give everyone else no path, and retain enough logging and control that the organization understands what happened.
The safest open port is the one you stopped needing.
Companies dealing with remote employees, private applications, industrial locations, legacy systems, travelling executives, cloud servers, or a traditional VPN everybody quietly hates can talk to PANDAROSE.
We can review the existing access model, reduce unnecessary public exposure, strengthen identity, create a useful internal namespace, and give people a private environment that feels considerably simpler than the architecture underneath it.
That is the good kind of magic.
Frequently asked questions
Is Tailscale a VPN?
Yes. Tailscale is a mesh VPN built on WireGuard. It coordinates encrypted connections between authorized devices and networks, with identity and access policy managed centrally. Connections may be direct or use an encrypted relay when direct connectivity is unavailable.
Can Tailscale provide remote access to an IBM i or AS400?
Yes. A subnet router can advertise the private network containing the IBM i, allowing approved tailnet users to reach selected resources without installing Tailscale directly on the IBM i. Access policies can restrict which users and devices may use that route.
What does MagicDNS do?
MagicDNS automatically assigns human-readable names to devices in a Tailscale network. Tailscale DNS configuration can also direct selected internal domains to private nameservers, creating a split-DNS environment for private applications and infrastructure.
What does a YubiKey add to SSH security?
OpenSSH can use FIDO2-backed credentials whose private key remains protected by the YubiKey. The cryptographic operation can require a physical touch, and optional PIN verification can add user verification.
Does Tailscale replace firewalls, endpoint security, or backups?
No. Tailscale can reduce public exposure and improve private access control. Firewalls, endpoint protection, identity security, monitoring, segmentation, backups, and tested recovery remain part of the wider security architecture.
References and further reading
- Tailscale: Control and data planes
- Tailscale: WireGuard
- Tailscale: MagicDNS
- Tailscale: DNS and split DNS
- Tailscale: Grants and access controls
- Tailscale: Subnet routers
- Tailscale: Exit nodes
- Tailscale: Microsoft Entra ID integration
- Yubico: Securing SSH with FIDO2
- Pangolin: Introduction and architecture
- Pangolin: How Pangolin works
