NetworkManager-ssh shows connected but nothing is routed
The indicator only proves the managed SSH relationship exists. Check whether the plugin built a tunnel device or a set of forwards, then test the app path.
The menu shows the SSH connection as active, the host key was accepted, and the browser still reaches nothing it was supposed to reach. That is not a contradiction, because a NetworkManager-ssh profile can produce two quite different outcomes from the same host and key: a tunnel device that carries packets, or a set of forwards that only certain applications can use. The indicator reports that the managed SSH relationship exists. It never reports which of the two you received.
Two results behind one menu entry
Both modes authenticate the same way, which is precisely why they get confused. Selecting the profile byte-for-byte the same way, with the same credentials, can leave you with an interface you can route through or with a listening socket that one application must be told about.
Start by deciding which result the task actually needs. A whole-subnet reachability requirement needs a device. A single service on a remote host needs a forward, and building a tunnel for it usually creates more routing work than the problem deserved.
What each mode has to have before it works
The project documents both modes, and the prerequisites differ enough that a missing one looks like a protocol failure rather than a design choice.
| Mode | What must exist | What still has to be true |
|---|---|---|
| Tunnel device | Compatible TUN/TAP arrangement on both ends, permission, addressing | A route policy that actually sends the intended prefixes into it |
| Forwarding only | A chosen SOCKS, local-forward or remote-forward listener | A permitted destination path on the far side |
Read the right-hand column carefully, because it is where most of these tickets end. Even a perfectly built tunnel device covers only what routing sends into it, and even a perfect forward helps only the applications that were told to use it.
The dummy interface is not a tunnel
In forwarding mode the plugin documents a dummy interface created to satisfy the connection model. It exists so the manager has something to attach state to. It does not carry arbitrary application packets to the remote network, and nothing about its presence implies that IP routing changed.
The full-tunnel examples in the project concern OpenSSH tunnel-device support, so the word tunnel in a label describes a capability, not your effective policy. Check what the kernel will do rather than what the profile is named.
nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"Then match the result to the application. A SOCKS-aware program has to be configured to use the proxy. A local-forward consumer has to be pointed at its listener. Neither one discovers the forward on its own, and neither is helped by a connection indicator that turned green.
Prepare the remote side instead of forcing it
An ordinary SSH account can authenticate without any permission to bring up a remote tunnel device. The project documents a non-root path in which an administrator pre-creates the device for that user, and the client then picks the matching number.
That arrangement needs coordination with the server tunnel policy and with whoever owns addressing on the remote network. Creating the device does not by itself grant the resource routes, the forwarding permissions or a return path, and none of those arrive because the sample configuration looked convincing.
What you should not do is enable unrestricted forwarding or remote root login to make a sample work. Where the operator owns remote network setup, use the supported arrangement for leaving those commands to that owner, and avoid a second helper reinstating conflicting addresses on disconnect.
Authentication context, and what to put in the ticket
Authentication has its own context. The plugin looks for an SSH agent associated with the user session and requires the destination host to be known, so a key that works in one terminal does not automatically become visible to the manager authentication path. Get the host key enrolled and checked through the approved process instead of switching the check off.
For support, record four things: the plugin and version, the selected mode, the intended remote identity, and the interface or listener that should have appeared. Then test the application entry point directly. A connected indicator plus a working test is evidence; a connected indicator alone is a statement about SSH, not about the routing or resource permission you were trying to obtain.