Outcome
You will reach a selected lab host from another trusted device over a private network, with a written way to revoke access. This recipe uses Tailscale as an example because its device and access-control documentation is public. Its account and coordination service are an external dependency; check its privacy terms and pricing for your use. A private overlay is an access method, not proof that every application behind it is safe. No PebbleRack device or remote-management feature has been tested here.
Before you start
Have a working local console path to the lab host in case remote access fails. Use a current supported OS, an account protected by strong authentication, and a second trusted device such as a laptop or phone. List exactly which service you need: SSH to a Linux guest, or perhaps the Proxmox web interface. Avoid starting with an entire subnet. Record existing firewall and router settings so you can reverse changes.
Steps
- Confirm that your router does not already forward Proxmox management port 8006, SSH port 22, or the application port to the public internet. Do not close a port blindly if someone else relies on it; document who owns it and remove it in a planned change. Keep Proxmox management reachable through a known local console path.
- Follow the current Tailscale installation instructions on one selected host or guest and on your client device. A guest dedicated to access may have a smaller scope than installing new software on the Proxmox host itself. Join both devices to the same tailnet. In the admin console, verify both device identities, owner, last-seen state, and whether an unfamiliar device is present.
- Inspect the tailnet's access policy before assuming it is restrictive. Tailscale documentation notes that default policies may allow connections among all devices. Add a scoped rule or grant that permits only your identity and client device to reach the chosen service, then test allowed and denied paths. Follow the policy editor and validation tools for the version currently offered in your account. Do not rely on a device name alone as an authorization boundary.
- From the client while still at home, use the host's tailnet address or MagicDNS name to reach the selected service. For SSH, connect with your usual SSH client or the documented Tailscale SSH path. If enabling Tailscale SSH, read its separate access rules and know that enabling it can interrupt an existing SSH connection to the tailnet address. For the Proxmox web UI, retain its normal login and multifactor protection where available.
- Move the client to a different network, such as a phone hotspot, and repeat the connection. Also attempt a path you intentionally denied. Record whether the allowed service works, the denied service fails, and the public internet cannot reach the management port. Test with an actual outside network rather than assuming that local success proves remote access.
- Revoke one test client in the admin console and confirm the session can no longer reconnect. Document device removal, account recovery, and who can change policy. Periodically remove stale devices and review access logs.
Check it worked
The authorized client reaches exactly the intended service from an outside network; an unauthorized path is denied; the lab remains reachable locally; and revocation works. The Proxmox or Linux application still enforces its own login. Keep screenshots or notes private because addresses and device identities are sensitive.
If it fails / rollback
First confirm both devices are online and signed into the intended tailnet. Check policy, DNS, host firewall, and service status in that order. If remote access breaks local administration, use the local console to remove the new software or rules. Revert only the changes made in this procedure. Do not “fix” a policy failure by exposing a public port.
Safety and data notes
A subnet router exposes a wider network and requires IP forwarding; introduce it only after the single-host pattern works and you can test least-privilege routing. Tailscale SSH is limited to documented host platforms and has separate network and SSH permissions. Do not share tailnet join links, auth keys, or screenshots of access policies publicly.
Sources
Official sources checked 2026-09-29: Tailscale connection guide; access control; Tailscale SSH; subnet routers.
Next guide
Continue with UPS and graceful shutdown.