What breaks when remote devices rely on inbound SSH behind NAT or CGNAT?

Why inbound SSH fails once the address is no longer stable

Inbound SSH is built around a reachable listener and a destination address that does not change unexpectedly. NAT and CGNAT break that assumption by hiding the device behind translated addresses, so the remote side cannot reliably target it. In practice, the protocol’s reachability model no longer matches how the network is exposed.

That matters most in remote fleets, where the operator may control the device but not the network path. Once the device sits behind translation, the access path depends on an upstream mapping that can change, expire, or refuse unsolicited inbound sessions.

For SSH operations that must remain consistent, the problem is not only authentication, but the network precondition that makes authentication possible in the first place. For guidance on managing SSH access material and reducing dependency on ad hoc inbound reachability, see the SSH Key and SSH Certificate Management Guide.

What NAT and CGNAT remove from the access model

Traditional inbound SSH assumes three things: a stable public address, an open inbound port, and a route that allows unsolicited connections to that port. NAT removes direct end-to-end addressing; CGNAT adds provider-scale translation that the device operator usually cannot control. The result is that “connect to this host on port 22” stops being a dependable operational assumption.

In a small lab, operators may work around this with port forwarding. In remote or consumer-access environments, that workaround is often unavailable or too brittle to support a fleet. Even when forwarding exists, it ties access to local network configuration rather than to the device itself, which makes remote access fragile and hard to standardise.

Address translation also changes failure behaviour. A device can be online, authenticated to the local network, and still unreachable from the outside because the translated path is not exposed. That is why access designs that depend on inbound targeting tend to fail as soon as the device leaves an environment with enterprise-controlled routing.

What reliable remote access usually needs instead

The practical fix is to stop treating the device as an inbound SSH endpoint and instead design for outbound-initiated connectivity, a relay, or a managed remote access service that survives translation layers. The access path should be something the device can establish from inside the restricted network, rather than something the outside world must discover and reach directly.

For practitioners, the key distinction is between “can I authenticate to the device?” and “can I reach the device at all?” Reachability must be solved before ssh key, accounts, or hardening matter. In translated networks, the reachability layer is the first control point, not an afterthought.

If SSH remains part of the solution, treat it as an authenticated session over a designed transport path, not as a public service exposed to every site. That means verifying where the session originates, who owns the network path, and whether the device can maintain a durable outbound control channel when the upstream address changes.

Practitioner Guidance

What to verify: Confirm whether the device can accept unsolicited inbound traffic at all, or whether every successful test is just a temporary artifact of a local port-forwarding exception. If the path depends on a customer ISP, mobile carrier, or residential NAT, assume it will not be operationally stable.

Decision rule: If the operator cannot control the public address or inbound mapping, do not design the fleet around inbound SSH. Move to an architecture that establishes connectivity from the device outward, then expose administrative access only through that controlled path.

What good looks like: The access method works consistently across sites, does not depend on per-location firewall exceptions, and can be explained without referencing a static public IP that the operator does not own.

Practitioner takeaway: Inbound SSH is not just “harder” behind NAT or CGNAT, it is structurally mismatched to the network model, so the right answer is to redesign reachability rather than try to force direct inbound access to behave like a stable endpoint.

Related resources from NHI Mgmt Group

• How should security teams provide remote access to devices behind NAT and CGNAT?
• How should security teams expose SSH access to a device behind NAT or CGNAT without opening inbound ports?
• How should security teams handle embedded SSH access in connected devices that rely on remote engineering support?
• What breaks when remote interviews rely on video alone?