How an SSH Local Forward Carries a TCP OpenVPN Session

Three transports stack here, and each one has its own framing. The VPN payload travels inside a TLS session, that TLS session travels inside a TCP connection to a loopback port, and the bytes of that connection travel inside SSH to a relay host, which opens the real TCP connection to the VPN listener. Nothing about the arrangement changes what OpenVPN authenticates, and nothing about it makes a UDP listener reachable over TCP. Read the rest of this as a description of the byte path, not as a recipe for bypassing a network control.

What the local forward actually moves

The SSH client listens on a local port. When a local process connects, the client packages the bytes into its encrypted channel, and the server side opens a new TCP connection to the destination named in the forward request.

That destination is resolved by the relay, not by your machine, which is why a name that only exists inside the remote network still works. It also means the relay must be able to reach the VPN listener and route back to it. A name that resolves on your laptop tells you nothing about what the relay can see.

Starting the SSH session proves only that the relay is reachable and authenticated. It says nothing about whether the onward listener is up, whether a firewall between the relay and the listener accepts the connection, or whether the VPN will accept your profile.

Point the client at the local listener

A declared example: the relay can reach a TCP listener at gw.internal.example:443, and a high local port exposes that path to this machine only.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

The OpenSSH manual describes the local forward as accepting TCP connections locally and opening the onward connection from the remote side. Bind the listener to loopback rather than to every interface, because a forward reachable from the network is an open relay with your name on it. A wildcard bind also exposes the port to any other local account on a shared machine.

Then set the VPN client to its TCP mode and point it at 127.0.0.1:24011. If the profile uses UDP, this design cannot help: the forward carries a byte stream, and there is no datagram path through it.

Keep the two authentications separate

SSH authenticates the relay host. OpenVPN still authenticates the VPN peer, and the loopback destination does not change that requirement. Disabling certificate checks because the socket now points at localhost is the single worst shortcut available in this design. It converts a transport arrangement into a trust arrangement, and nobody signed off on the second one.

Keep the profile's trust anchor, server-role check and name verification intact. If your client compares the server name against the address it dialled, loopback may need an explicit name setting rather than a disabled check, and the profile documentation is the place to confirm which field is compared.

Treat the relay as a second party in the trust story: its administrator can see connection metadata and can redirect the forward if the configuration is changed. The arrangement needs approval from both the relay and the VPN service owner, not just from whoever needs it today.

Do not build a loop under the tunnel

Once the VPN installs routes, the SSH connection carrying it still needs a path to the relay that does not run through the tunnel. If the default route moves to the VPN and the relay is only reachable through that same tunnel, the transport collapses and the VPN goes with it. The failure looks like a dropped tunnel rather than a routing mistake, which is why it gets misdiagnosed.

The usual fix is a host route to the relay address pinned to the physical interface before the tunnel comes up, plus a check that the route survives a reconnect. Verify it with a route lookup for the relay address rather than by assuming the ordering was correct.

Also expect this stack to be slower and more fragile than a direct connection, because there are now two ordered transports and another endpoint to maintain. It is a way to cross a network boundary, not a performance technique.

Close the listener when you are done

Stop the SSH session when the tunnel is no longer needed, and confirm the local port is released. A forgotten forward keeps an authenticated path open on a machine that may be shared.

Review the relay's permitted forwarding destinations as well, since a permissive configuration turns any compromised account into a general pivot. Record the port, the relay and the destination together, so the next person can tell what the forward was for and whether it is still approved.