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.

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. External-network tests covered the tunnel handshake, ping, SSH, NoMachine, the absence of public SSH/NoMachine exposure, and persistence after a Rocky Linux reboot. Those tests exercise router forwarding, zone assignment, service reachability, and reboot behavior as well as WireGuard itself.

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, and route-table validation.