7 min read

WSL2 SSH RemoteForward Deep Dive for a Windows Proxy

Configuration

Host ubunldd
  HostName 10.20.30.199
  Port 22066
  User ludd50155
  IdentityFile ~/.ssh/id_ed25519
  RemoteForward 127.0.0.1:5780 10.188.129.243:5780
  ServerAliveInterval 30
  ServerAliveCountMax 3

What This Configuration Actually Does

This SSH stanza turns the remote machine ubunldd into a consumer of a proxy that is actually running on a Windows host reachable from the current WSL2 environment.

After ssh ubunldd is established:

  • the remote Ubuntu machine listens on 127.0.0.1:5780
  • any process on that remote machine can connect to 127.0.0.1:5780
  • that traffic is carried backward through the SSH session
  • on the client side, SSH connects to 10.188.129.243:5780
  • 10.188.129.243 is the Windows host providing the proxy service

So the remote box gets a local-looking proxy endpoint, but the real proxy server still lives on Windows.

Topology

+-------------------+                SSH client runs here
| WSL2 environment  |-----------------------------------+
| ssh ubunldd       |                                   |
| can reach         |                                   |
| 10.188.129.243    |                                   |
+-------------------+                                   |
          |                                             |
          | TCP to Windows proxy                        | encrypted SSH session
          v                                             v
+-------------------+                           +-------------------+
| Windows host      |                           | Remote machine    |
| 10.188.129.243    |                           | ubunldd           |
| proxy on :5780    |                           | 10.20.30.199      |
+-------------------+                           | listens on        |
                                                | 127.0.0.1:5780    |
                                                +-------------------+

Line-by-Line Analysis

Host ubunldd

This is only a local alias. Running:

ssh ubunldd

expands to the rest of the block.

HostName 10.20.30.199

This is the real SSH server address for the remote Ubuntu machine.

Port 22066

The SSH daemon is not listening on the default port 22. The client must connect to 10.20.30.199:22066.

User ludd50155

This sets the remote login identity. The effective command becomes conceptually:

ssh -p 22066 ludd50155@10.20.30.199

IdentityFile ~/.ssh/id_ed25519

This selects the private key used for public key authentication.

In a WSL2 setup, this path is resolved inside the Linux filesystem of WSL, not against Windows %USERPROFILE%\.ssh unless that path is explicitly mounted and referenced.

RemoteForward 127.0.0.1:5780 10.188.129.243:5780

This is the key line.

It means:

  • ask the remote SSH server to bind 127.0.0.1:5780
  • when something on the remote machine connects there, tunnel that connection back through SSH
  • from the SSH client side, open a TCP connection to 10.188.129.243:5780

The subtle but important point is this:

  • 127.0.0.1:5780 exists on the remote machine
  • 10.188.129.243:5780 is reached from the client side, which here is WSL2

This does not mean the remote Ubuntu host directly reaches 10.188.129.243.

SSH is bridging the two sides.

ServerAliveInterval 30

Every 30 seconds, the SSH client sends a keepalive message over the encrypted session.

This helps detect broken state when:

  • WSL2 network changes
  • Wi-Fi sleeps or roams
  • NAT devices silently expire idle sessions
  • the Windows host or local network path changes underneath WSL2

ServerAliveCountMax 3

If three consecutive keepalive responses are missed, SSH terminates the session.

With the current values, the connection is usually dropped after about 90 seconds of unanswered keepalives.

That is useful here because a dead SSH session should not leave you assuming the remote proxy forward still works.

Why RemoteForward Fits This Use Case

The goal is not to make the local WSL2 environment use a remote service. It is the reverse:

  • the remote machine needs access to a proxy
  • that proxy already exists on the Windows side near the SSH client
  • the remote machine may not have direct routing to that Windows host

RemoteForward is the correct mechanism because it publishes a listening port on the remote machine and sends connections back toward the client side.

If you had used LocalForward instead, you would expose a local listener in WSL2, which does not help software running on the remote Ubuntu host.

Effective Behavior on the Remote Machine

Once connected, software on ubunldd can use:

http://127.0.0.1:5780

or, for SOCKS-aware tooling if the service is SOCKS-compatible:

socks5://127.0.0.1:5780

Whether the remote application should use http:// or socks5:// depends on what the Windows service on 10.188.129.243:5780 actually provides.

From the remote machine’s perspective, it does not matter that the real service is on Windows. It only sees a local loopback endpoint.

Why the Bind Address Is 127.0.0.1

Binding the remote side to 127.0.0.1 means:

  • only the remote machine itself can use the forwarded port
  • other hosts on the remote LAN cannot connect to it
  • the proxy is not accidentally published as a shared network service

This is the safer default.

If the config had been:

RemoteForward 0.0.0.0:5780 10.188.129.243:5780

then other machines that can reach ubunldd might also be able to use the forwarded proxy, depending on the SSH server’s GatewayPorts policy. That would be a very different security posture.

End-to-End Connection Flow

Assume a process on ubunldd tries to use http://127.0.0.1:5780.

The flow is:

  1. The process connects to remote loopback 127.0.0.1:5780.
  2. sshd on ubunldd accepts that connection because of the negotiated RemoteForward.
  3. The byte stream is sent through the existing encrypted SSH session to the client side in WSL2.
  4. The SSH client opens a new outbound TCP connection to 10.188.129.243:5780.
  5. The Windows proxy handles the request.
  6. Response traffic returns through the same path in reverse.

The remote machine never needs native reachability to 10.188.129.243.

Why WSL2 Matters Here

The client endpoint for RemoteForward is defined from the viewpoint of the SSH client process. In this case, that process runs inside WSL2.

That has several consequences:

  • name resolution for 10.188.129.243 or any hostname on the right side happens from WSL2
  • TCP reachability to the Windows proxy must work from WSL2
  • if WSL2 loses reachability to the Windows host, the remote forward stops being useful even if the SSH session itself looks momentarily alive

In practice, this design works well when:

  • the Windows host IP is stable from WSL2
  • the proxy service is bound on an address reachable by WSL2, not Windows loopback only
  • WSL2 to Windows routing is consistently available

Common Misunderstanding to Avoid

A frequent mistake is reading:

RemoteForward 127.0.0.1:5780 10.188.129.243:5780

as if the remote host itself will directly dial 10.188.129.243:5780.

That is not how this works.

The remote host only exposes the listening side. The connection toward 10.188.129.243:5780 is performed on the SSH client side, which here is WSL2.

That distinction explains why this setup can work even when:

  • ubunldd cannot route to 10.188.129.243
  • but WSL2 can

Operational Checks

Useful checks from WSL2:

ssh -v ubunldd
nc -vz 10.188.129.243 5780
ss -tnp | grep 22066

Useful checks on the remote machine after login:

ss -ltn | grep 5780
curl -x http://127.0.0.1:5780 https://example.com

If the remote proxy listener exists, you should see a listener on 127.0.0.1:5780 on ubunldd.

Failure Modes

1. SSH session is up, but the proxy target is unreachable from WSL2

Symptoms:

  • remote software connects to 127.0.0.1:5780 but requests fail
  • SSH login still works

Cause:

  • WSL2 cannot reach 10.188.129.243:5780
  • the Windows proxy service is down
  • Windows firewall or binding changed

2. The remote listener is missing

Symptoms:

  • nothing is listening on remote 127.0.0.1:5780

Possible causes:

  • remote forwarding rejected by sshd
  • policy such as AllowTcpForwarding is disabled
  • port 5780 is already in use on the remote host

3. Keepalives eventually kill the session

Symptoms:

  • SSH disconnects after network instability

Cause:

  • the keepalive settings are doing their job and removing a stale tunnel instead of leaving a half-dead one in place

Security Posture

This setup is relatively controlled because:

  • SSH authentication is key-based
  • the forwarded proxy is only exposed on remote loopback
  • the Windows proxy service is not directly opened to the remote network through SSH

Still, there are real trust implications:

  • any process running as the remote user can use the forwarded proxy
  • if that remote account is compromised, the attacker gains indirect access to the Windows-side proxy
  • proxy logs and traffic policy remain enforced by whatever service runs on 10.188.129.243:5780

Bottom Line

This SSH configuration makes ubunldd borrow a proxy from the WSL2/Windows side.

The critical design is:

  • remote consumer: ubunldd
  • remote listening endpoint: 127.0.0.1:5780
  • client-side actual target: 10.188.129.243:5780
  • transport in the middle: the SSH session from WSL2 to 10.20.30.199:22066

That makes the remote machine behave as if it had a local proxy, while the real proxy service remains on the Windows host near the SSH client.

Backlinks

Graph View