WireGuard

WireGuard moves SSH and NoMachine off the public zone without turning the host into a full-tunnel Internet gateway. The router forwards one UDP listener to Rocky Linux. firewalld's public zone accepts that listener but not management services; authenticated tunnel traffic enters a dedicated WireGuard zone that permits SSH and NoMachine. The services then apply independent authentication boundaries: SSH uses public key plus TOTP, while NoMachine uses system password plus TOTP.

Route and exposure decisions

The tunnel subnet must not overlap local networks, corporate VPNs, container networks, or Kubernetes networks. Client AllowedIPs are restricted to destinations that need the tunnel. Console or another trusted access path is preserved while removing management services from the public zone.

A handshake is only one layer of evidence. Network-path tests cover the tunnel handshake, ping, SSH, NoMachine, the absence of public SSH/NoMachine exposure, and persistence after a Rocky Linux reboot. Service authentication is checked separately: a fresh SSH transport must complete key plus TOTP, while a fresh NoMachine client must complete password plus TOTP before any recovery session is closed. Together these checks exercise router forwarding, zone assignment, reachability, authentication, and reboot behavior rather than treating a WireGuard handshake as sufficient proof.

Competing VPN routes

Cisco Secure Client on macOS can replace or remove routes. After it disconnects, WireGuard destinations should use the WireGuard tunnel interface while the server's LAN address follows the normal Wi-Fi route. Cycling the WireGuard client rebuilds a missing tunnel route. Permanent manual host routes are avoided because they conceal which VPN owns a route and can be wrong on another network.

This boundary keeps private administration away from public ingress, but it does not replace careful router, firewall, route-table, SSH-authentication, or NoMachine-authentication validation.