Give a Remote Pi a SOCKS Proxy Through Your SSH Client

A remote dynamic forward puts the SOCKS listener on the Pi and makes the onward connection from your laptop's approved VPN path. No second SSH server.

You assume a SOCKS proxy has to run wherever the network access already exists. OpenSSH can place the listener somewhere else entirely. A remote dynamic forward opens the SOCKS port on a remote host and originates each connection from your local SSH client, which carries your laptop's approved VPN path. The Pi gets a scoped proxy; it does not inherit your tunnel or your privileges.

The listener and the originating side can differ

An ordinary ssh -D 1080 runs the listener on your own machine and sends connections out from there. A remote dynamic forward reverses that: the listener appears on the remote host, and every connection it accepts is opened from the local side. The OpenSSH client manual documents -R without a fixed destination as exactly this SOCKS4/5 arrangement.

A supported command from the laptop looks like this, with the account, hosts and port treated as placeholders:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Three details do useful work there. -S none keeps the session away from a shared control master, ExitOnForwardFailure fails fast instead of leaving you with a half-open session, and PermitRemoteOpen limits what the remote listener may reach. Use an authorized Pi account and verify the host key before you add any of it.

What the remote listener really exposes

Check the server's forwarding policy before you rely on the listener. With GatewayPorts no, the remote forward stays bound to loopback, which is the exposure you want. A server configured to force wildcard forwarding publishes the same port on every interface, which turns a personal proxy into something the local network can reach.

Loopback is also not a per-user boundary. Another process on the Pi can connect to 127.0.0.1:1080 if it knows the port, so the Pi's local accounts and whatever runs on it are part of your access design. That is a reason to keep the destination list narrow rather than a reason to skip the policy check.

Keep the permitted destination specific to the application you are trying to reach. Replacing it with unrestricted forwarding to make an unrelated program work widens the path far beyond the problem you started with. A destination list also records what the session was for, which helps whoever audits it later. Write it down beside the account you used.

Send one application through the proxy

A proxy-aware client on the Pi can then make the request. The socks5h prefix hands the destination name to the proxy, so the lookup and the connection both happen on the laptop side, and it matches the named destination in PermitRemoteOpen:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

Keep normal certificate validation and the application's own authentication. The proxy changes where the TCP connection is made; it does not make an unauthenticated service safe, and it does not turn a self-signed endpoint into a trusted one.

The laptop still needs its own route and resolver access to both the SSH server and the application. Its SSH client's traffic has to be selected by the approved VPN policy, and a split-tunnel exclusion can send that traffic down a different path than the one you tested.

Prove the path and close it down

Confirm the listener exists where you expect it and that only the intended destination answers:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure can prove the forwarding was established, and it still cannot certify that the application login succeeds downstream. Test the application, not just the port. A listener that accepts and then fails every request usually means the destination name or the laptop's route is wrong, not that the tunnel failed.

This arrangement carries TCP only. UDP, ICMP and programs that ignore proxy settings stay outside it, and the forwarding ends the moment the SSH session ends. Stop that session when you are done and remove the proxy setting you added to the application.

For permanent access, use the network owner's supported enrollment or managed gateway instead. A reverse proxy is the wrong tool for evading a VPN's device or resource restrictions; used inside them, it is simply one authorized application path with explicit limits.

Skyldar greinar