Tailscale and HearthGate: Network Layer vs Mac Gateway Layer

A thoughtful Reddit comment put the challenge clearly: if Tailscale already lets you reach every Mac, PC, VM, and NAS from anywhere, why does a Mac remote-access gateway need to exist at all?

That is a fair question. Tailscale is very good at what it does. It creates a private mesh network between devices, built on WireGuard, and removes a lot of the pain around NAT traversal, changing IP addresses, and router setup. For many people, that is enough: install Tailscale, reach the Mac over its Tailscale address, and use Apple Screen Sharing or another remote desktop path.

The important distinction is layer. Tailscale is primarily the network reachability layer: how a device can reach another device. HearthGate is the Mac-side gateway and hardening layer: what the Mac permits, records, packages, restricts, and restores after it becomes reachable.

The strongest argument for Tailscale is that it makes the network feel sane again. A Mac mini at home, a MacBook on the road, a Windows VM, and a NAS can all live on the same private tailnet. In many cases, that means no public VNC port, no router port-forwarding, and no manual SSH tunnel to remember.

That is a real win. It is also why HearthGate should not pretend Tailscale is irrelevant. If your only problem is "I need my devices to see each other privately," Tailscale may already be the answer.

But reachability is not the whole remote-access story. Once the Mac is reachable, the Mac still needs a host-side policy. Which key can connect? Is the screen port reachable directly or only through a local tunnel? Can a key be LAN-only or internet-only? Is password SSH disabled? Can access be revoked immediately? Are sessions and connection history visible? Can the system be restored to its pre-install state?

HearthGate starts where the network layer stops. It keeps Apple Screen Sharing on the Mac, but wraps the access path in managed SSH, restricted keys, connection packages, optional firewall-enforced VNC lockdown, session visibility, audit-friendly exports, System Controls, and connection hooks.

That means HearthGate can be useful with or without Tailscale. Without Tailscale, you might reach the Mac through LAN, DDNS, a router-forwarded SSH port, or another private route. With Tailscale, the Tailscale address can become the SSH host while HearthGate still controls the Mac-side gateway behavior.

In that combined model, Tailscale gives you the private road to the house. HearthGate decides which door opens, what the key is allowed to do, whether the screen port is reachable directly, what gets logged, and how the changes can be undone.

A Tailscale user can reasonably say, "I do not need SSH tunnels; I can just reach the Mac and use Screen Sharing." In a trusted personal tailnet, that may be perfectly acceptable.

HearthGate is aimed at the next layer of caution. Some users do not want the screen service to be directly reachable even on a private overlay network. Some want each connection artifact to be explicit and revocable. Some want the VNC side to stay localhost-only while SSH key policy controls access. Some want scripts for Windows, macOS, Linux, FreeBSD, iOS, and Android workflows instead of hand-maintained notes.

That is not a claim that every Tailscale user needs HearthGate. It is a claim that reachability and host hardening are separate jobs. If a user wants both, the tools can complement each other.

Tailscale has a strong security story, and its data plane uses WireGuard. The remaining trust question is operational: the coordination/control plane, identity provider, policy model, and device enrollment are part of the system. For many users, that is exactly what they want.

HearthGate takes a narrower app-level position. It does not run a relay, does not provide a cloud coordination plane, and does not require a third-party identity provider for its connection model. It uses the Mac-side services and connection material you control: OpenSSH, Apple Screen Sharing, restricted keys, bundles, scripts, and local logs.

That is the same broad instinct that makes some administrators comfortable paying for SSH tooling such as VanDyke VShell, SecureCRT, SecureFX, or nsoftware server tools: they want explicit protocols, explicit keys, and operational control. nsoftware has started moving the older PowerShell Server line into the CoreSSH Server product family; public product pages now redirect from the PowerShell Server URL to CoreSSH Server, and the public documentation identifies the line as CoreSSH Server 2024. HearthGate is not a replacement for those Windows and SSH ecosystems. It is the Mac-side secure screen gateway for people who think in those terms.

VanDyke VShell, SecureCRT, SecureFX, and nsoftware tools live in a world where SSH, terminal access, secure file transfer, and server-side control are normal vocabulary. In nsoftware/CoreSSH terminology, this now means CoreSSH Server for the product line that used to be commonly searched as nsoftware PowerShell Server. The clearest public timestamp is the CoreSSH Server 2024 documentation generation rather than a specific launch-day announcement.

HearthGate borrows that seriousness, but applies it to a different Mac problem: secure screen access through the native macOS stack. It is not trying to be SecureCRT. It is not trying to be SecureFX. It is not a general Windows SSH server. It is a Mac-native way to make Screen Sharing safer to operate from mixed clients without turning VNC into a public or casually reachable service.

That is also why common viewers still matter. A person may use Screens on iOS, TightVNC on Windows, Remmina on FreeBSD, MobaXterm on Windows, or RealVNC in a familiar workflow. HearthGate focuses on the Mac-side gate those clients pass through.

If every device is yours, every user is you, the tailnet is already trusted, and you are happy using Screen Sharing directly over the Tailscale address, then Tailscale alone may be the simplest answer.

That is not a weak answer. It is clean, inexpensive for many personal use cases, and widely loved because it removes networking pain. HearthGate does not need to argue with that user. The better product posture is to say: good, you already solved reachability.

HearthGate becomes interesting when the Mac itself needs a stricter access posture. That might be a headless Mac mini, a studio workstation, a customer Mac, a local AI machine, a homelab host, or a shared Mac where remote access should be deliberate and revocable.

In those cases, the question is no longer "can I reach the Mac?" The question is "what exactly happens when someone reaches it?" HearthGate answers with restricted keys, VNC-over-SSH connection packages, firewall-enforced VNC lockdown, SSH hardening from the UI, session history, logs, clipboard guard, System Controls, connection hooks, and restore behavior.

You can use that over a normal LAN. You can use it through a router-forwarded SSH endpoint. You can use it over a mesh VPN such as Tailscale. HearthGate is not the road. It is the gate at the Mac.

Tailscale is excellent at making private devices reachable. HearthGate is built for Mac users who want the reached Mac to enforce a clearer, narrower, more auditable remote-screen path.

If Tailscale already works for you, HearthGate does not ask you to throw it away. It asks a different question: once the path reaches your Mac, do you want the Mac-side access model to be explicit, packaged, restricted, visible, and reversible?