Reach a VPN-Only HTTPS Site Through an SSH Forward

One machine already has approved VPN access, a second machine needs exactly one private HTTPS service, and an SSH local forward can bridge that gap without giving the second machine a tunnel. The forward carries one TCP destination rather than the whole network, and that limit is the point. Work through the five steps below in order, because each one fails for a different reason and a later step cannot rescue an earlier gap. If any precondition is missing, this design does not solve it and no amount of command tuning will.

Step one: confirm the three preconditions

Three things must already be true before any command matters. You need permission to use the first machine as a forwarding host, working SSH access to it, and a server policy that permits the intended destination. An SSH account created for file transfer may have forwarding disabled, and a server that allows forwarding may still restrict which destinations are reachable through it. Ask before you test, because using a colleague's workstation as a jump point without agreement is a policy problem even when the command works cleanly.

Two commands settle the technical half of that list. The first proves the account and key work without an interactive prompt, and the second prints the effective server policy rather than the commented example in the configuration file.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Step two: bind a loopback port and keep the session alive

On the machine that runs the client application, open a local forward to the private service. Bind it explicitly to loopback so it is not published to the local network, and choose a high port that no local service already holds. Keep the session running while you work, since closing it closes the listener. ExitOnForwardFailure turns a refused bind or an occupied port into an immediate exit instead of a session that stays up with no forward, which is the failure mode that wastes the most time.

The private connection is made from the jump host, so that host's DNS, routes, VPN policy and service access all have to work. The SSH session does not create reachability the jump host lacks, and it cannot repair a route the VPN never pushed. Confirm the listener where it actually is rather than trusting the command's silence.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Step three: keep the HTTPS name when the socket is local

Browsing to https://127.0.0.1:9443/ changes the TLS server name and the application authority. A certificate issued for portal.lab.example will not validate against a loopback address, and the resulting error looks like a broken certificate rather than a forwarding shortcut. For a command-line test, keep the real URL and change only the socket destination. That is what --connect-to does, and the curl manual documents the four-field form used below.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

The name stays in the URL, in the TLS handshake and in the Host header, while the TCP connection goes to the local listener. The no-proxy option keeps the test on this forward instead of letting a configured HTTP proxy intercept it, and keeping certificate verification on is what makes the result meaningful.

Step four: know what one forward cannot cover

A single TCP forward covers one destination port. A page that redirects to a second hostname, loads assets from a host inside the private network or posts to another port needs its own forward, and each of those needs the same policy check as the first. Browser workflows add requirements of their own, because the browser has to be told to send the real name to the local port through a proxy configuration or a local mapping. A command-line test that succeeds therefore does not prove the browser will, even though it proves the path.

UDP, SMB discovery and domain sign-in do not travel through a TCP forward at all. If the real requirement is general network access, this design is the wrong tool and a supported remote-access gateway is the right one.

Step five: clean up and record it

Stop the session when the test is finished and confirm the listener is gone. If the chosen port was already occupied, pick another unused loopback port and update the URL, the test command and the note together, rather than terminating an unrelated local service to free the number. Leaving a forward open on a laptop turns a diagnostic into an unmanaged service.

Write down the jump host, the forwarded destination, the local port and who approved the arrangement. A forward that only exists in someone's shell history is one reboot away from a repeat investigation, and the next person will not know which of the three preconditions was already checked.