Headscale starts with all nodes reachable unless a policy file changes that
Headscale is a self-hosted control server compatible with the Tailscale client model. Its security posture depends on two separate layers: who can register a node, and what a registered node can reach. A successful device registration does not imply a useful network policy.
The Headscale policy documentation states that no policy is loaded by default, which allows all traffic between nodes. That default is important during an inventory review. A control server can look healthy while every enrolled device can reach every other enrolled device. The operator should explicitly load and test a policy before treating the tailnet as segmented.
Measurement evidence
On 2026-11-07 UTC, page-one count-only ZoomEye probes with sub_type=all returned 2 matches for app="Headscale", 86 for title="Headscale" and 7,347 for http.body="Headscale". These are not counts of exposed control planes. The application count is small, while title and body matches can include documentation, tutorials and repositories. Each candidate needs an ownership and service check.
Review identities and enrollment
Inventory users, pre-authentication keys, API keys, node keys and external identity providers. Pre-authentication keys should be short lived, scoped to the intended user or tag and revoked after enrollment. API keys should have an owner and a rotation date. The control server's database backup is a high-value asset because it contains the enrollment and policy state.
Review routes and exit nodes separately from the policy. A subnet router can advertise access to a network that the ACL policy does not intend to expose. Headscale's route documentation describes autoApprovers for policy-driven approval. Auto-approval is useful only when the advertised prefix and the approving identity are tightly constrained.
Test with real source and destination pairs
Build a matrix containing each user, device tag and service, then test at least an allowed, a denied and an unlisted pair. Do not rely on visual policy review. Confirm that a device cannot reach an internal service merely because both devices registered with the same control server.
Log policy changes, key creation, route approval and node removal. After a key or device is lost, revoke the credential, remove the node if necessary, rotate affected service credentials and verify that the old identity cannot reconnect. Recheck route approvals because a stale subnet route can preserve reachability after the node is thought to be gone.
The control plane provides identity. The policy provides authorization. An inventory that records only the first is incomplete.
Top comments (0)