Test before you trust
Before removing any broader firewall rules, verify all three paths work from an external connection — not from within the server itself:
# Tailscale path — from any device on your mesh
ssh username@100.100.100.100 -p 22
# With MagicDNS enabled (if you set it up in Tailscale)
ssh username@servername -p 22
# Direct from home — force IPv4
ssh username@server.example.com -p 22 -4
# Direct from home — force IPv6
ssh username@server.example.com -p 22 -6
The -4 and -6 flags tell SSH to use only that protocol. If your domain has an A and AAAA record pointing to the server, you can test both paths without remembering raw IP addresses. If you use Cloudflare for DNS, make sure the hostname you use for SSH is unproxied — grey cloud. SSH doesn't work through Cloudflare's proxy, and a proxied record resolves to Cloudflare's IPs, not your server's. The cloud firewall would drop it. A dedicated subdomain like randomname.example.com with the cloud toggled grey handles this cleanly without affecting your website's proxied records. If any path fails, fix it before tightening the firewall. Keeping your current SSH session open in a separate terminal while testing is cheap insurance — if you lock yourself out, you can still revert from the existing session.
Why not Tailscale-only?
It's tempting to allow only the Tailscale path and close direct SSH entirely. Tailscale authenticates every connection cryptographically. No port exposed to scanners. One path, one policy, simple.
The risk: if Tailscale is down — an update breaks the tunnel, a DERP relay is unreachable, your mesh configuration gets corrupted — you have no way in. The cloud provider's emergency console (Lish, VNC, serial console) still works, but that's a last resort, not a daily driver. Keeping one direct path from a known network is a seatbelt. You'll probably never need it. The one time you do, it saves you time.
If your home IP is truly static — a business connection with a fixed allocation, or an ISP that hasn't changed your address in years — the direct IPv4 rule is set-and-forget. If it rotates, the IPv6 /64 is the more stable direct path. Either way, one direct fallback plus Tailscale for everywhere else gives you convenience without painting yourself into a corner.
No cloud firewall? If your provider doesn't offer an infrastructure-level firewall, you can still apply the same logic at the host level. Add your home IPv4, IPv6 /64, and the entire Tailscale subnet (100.64.0.0/10) to fail2ban's ignoreip directive in /etc/fail2ban/jail.local:
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1
203.0.113.50 # home IPv4
2001:db8:abc:def::/64 # home IPv6 /64
100.64.0.0/10 # Tailscale mesh subnet
This doesn't stop bots from reaching your SSH port — the packets still hit your server, sshd still rejects them, and fail2ban still processes the logs. What it does is guarantee that fail2ban never bans an IP you use. You still get the brute-force protection for every other address on the internet, and you never lock yourself out because you mistyped a password or a key didn't load. The fail2ban guide covers ignoreip in the jail configuration section. It's not as clean as a cloud firewall — your server still does the work of rejecting the connections — but it's available everywhere, costs nothing, and takes thirty seconds to configure.
Where this fits
Tailscale shows up in a few places across this site — each article covers a different use for the same mesh network:
- The reverse proxy guide uses Tailscale to tunnel PHP requests from a VPS to a home server without exposing the home IP. Same WireGuard mesh, different application.
- The automated backups guide uses Tailscale for SFTP-based rclone backups to a home server. The Tailscale IP is the backup target.
- The cloud firewall guide covers the web traffic lockdown — ports 80 and 443 restricted to Cloudflare IPs. This article is the SSH companion to that one.
- The Hardening SSH guide covers key-based authentication, sshd_config lockdown, and fail2ban integration — the host-level security that sits behind the cloud firewall rules.
This guide documents a three-path SSH access architecture using Tailscale as the primary mesh layer with direct IPv4 and IPv6 fallbacks, enforced at the cloud firewall level. The cloud firewall drops all SSH traffic except from known home IPs and Tailscale's WireGuard port — packets never reach the server kernel.
Compatibility: The cloud firewall rules apply to any provider with an infrastructure-level firewall — Linode Cloud Firewall, Vultr Firewall, DigitalOcean Cloud Firewall, AWS Security Groups, Hetzner Firewall. Tailscale is available for Linux, macOS, Windows, iOS, and Android. The sshd ListenAddress configuration works on any OpenSSH 7.0+ installation.
2026-05-29: Initial publication — Tailscale SSH access architecture with cloud firewall enforcement. Covers the three-path model (home IPv4, home IPv6 /64, Tailscale WireGuard mesh), cloud firewall rule configuration, sshd ListenAddress setup for Tailscale interfaces, and the rationale for keeping a direct fallback path. Cross-linked to cloud firewall guide, reverse proxy guide, automated backups guide, Hardening SSH, and fail2ban.