JConsole Connected to the Registry, Then RMI Sent It Elsewhere

Connect to the registry port over the tunnel, watch the handshake begin, and then watch JConsole time out anyway. That happens because the first TCP connection is not the management connection: it is a lookup. The RMI registry answers with a reference that names a host and a second port, and JConsole then goes wherever it was told. If the tunnel only reaches the server's first port, or the reference names an address that only exists on the server's own LAN, the client stalls after apparently succeeding.

The myth: one open port is one connection

Remote JMX over RMI involves at least two endpoints, and they are chosen by different parts of the system. The registry port is what you type into the client, and it exists to hand out the stub that describes the actual connector. Treating the first successful socket as proof that the management path is open is what turns a two-minute diagnosis into an afternoon of firewall tickets.

Watch the client's own error rather than the server's listener list. A failure after the handshake begins is telling you that the second connection, not the first, did not complete.

What the registry hands back

The stub contains an address and a port, serialised at the moment the connector was created. On a server with several interfaces, the stack may have chosen an address that is reachable from the local network and unreachable from yours. The client does not know the difference; it simply dials the value it was given, and the packet then follows whatever route exists for that address, which on a VPN client is often nothing at all. That is the moment the second connection is attempted.

This is also why the failure is intermittent across environments: the same server can behave differently for a user on the LAN and a user on the tunnel, with no change to the JMX configuration at all.

Two ports, and two properties that pin them

The registry port comes from com.sun.management.jmxremote.port, and the connector can be pinned with com.sun.management.jmxremote.rmi.port rather than left to whatever the stack allocates. Set both explicitly when the path has a firewall or a security group between the client and the server, because an unpredictable second port cannot be allowed in advance and a wide range opened to accommodate it is worse than pinning one value.

Then confirm with ss -ltn or netstat -an on the server that both ports are listening and on which addresses. A listener bound to loopback is correct for a local-only deployment and useless for this one.

When the advertised name is wrong

The hostname that appears in the remote reference is set by java.rmi.server.hostname. It affects what the stub advertises; it is not by itself an instruction to bind every listener to one interface, which is why setting it does not always produce the single-port behaviour people expect. Set it, restart the process, then verify what the stub actually contains. Choose a name or address that the client can resolve and reach through the tunnel, and restart the process so the stub is rebuilt.

Container networking makes this worse, because the address the process sees may be an internal one that nothing outside the container can route. Publish the intended hostname explicitly rather than letting the platform pick.

If you are tunnelling with SSH instead of a VPN, the same problem appears in a different costume: forwarding the registry port alone leaves the second endpoint pointing at an address your client cannot reach. Forward both ports and make the advertised name resolve to something the client can reach locally.

Do not disable management security to simplify it

Snippets that turn off authentication and TLS are easy to find and make the connection work in a way you will have to undo later. Remote JMX is a management interface with the same privileges as the process it inspects; keep its access controls, and if the client cannot present credentials, fix that instead.

After the endpoints are correct, preserve the next error you see. A trust store or account rejection is a later stage than an unreachable connector, and it means the network work is finished.