I’ve worked in a similar environment before … Maybe my approach will work?

USE AT YOUR OWN RISK

But I used MacOS and Linux for this. Or more specifically: The OpenSSH clients and tools such as “nc” (BSD NetCat) these OS come with. The only way I ever managed to reproduce this on Windows 10 back then was via using CygWin …

Also: you’d need an OpenSSH server (BSD, Linux, MacOS … these days Windows 10/11 would probably work too) somewhere somehow outside your company network, e.g. at home. I always used my own little Linux server at home for this.

So what I write here is with OpenSSH and “nc” (BSD NetCat) in mind.

Let’s also assume that I want to access a remotely running RDP-server in my LAN (could be Windows, could be Linux via “xrdp” … e.g. because I don’t want my browsing history on my local company web browser …)

Thus:

ssh -p $REMOTESSHPORT -L 3389:192.168.1.39:3389 user@remote -o "ProxyCommand=nc -X connect -x proxy.hostname.net:$PROXYPORT %h %p"

=> the RDP server (port 3389/tcp) running on my LAN host “192.168.1.39” becomes available as “localhost:3389” on my end, thanks to this SSH connection. And it will remain available for as long as this connection stays open.

Filled with actual numbers and names this could look like this:

ssh -p 2243 -L 3389:192.168.1.39:3389 myuser@myhost.athome.ddns-domain.nu -o "ProxyCommand=nc -X connect -x clientproxy.corporation.net:8079 %h %p"

Why port “-p 2243” => my router at home is set to port-forward SSH from 2243 to 22; I don’t use the standard port 22 on the outside because there are too many script-kiddies out there who otherwise keep hammering that port with login attempts… Not that I am worried (I do SSH-key based logins and not password-based logins …) but I just find the flood of failed login attempts annoying. So I moved the SSH port to something above 1024.

How this works:

What happens here is that the “nc” tool will first pretend to be a standard SSL client (e.g. a web browser wishing to communicate via “https” …) and connect to the corporate web proxy on the port the proxy expects (“8079/tcp” in my example) … and then keep the connection open. And then the actual SSH connection goes through that tunnel and connects to my actual target host: my machine at home.

In case you don’t have an OS with BSD’s flavour of “nc” (BSD NetCat) but something that uses e.g. Red Hat’s “socat” instead: The syntax changes.

ssh -p 2243 -L 3389:192.168.1.39:3389 myuser@myhost.athome.ddns-domain.nu -o "ProxyCommand=socat - PROXY:clientproxy.corporation.net:%h:%p,proxyport=8079"

… but it should work just the same. For as long as this SSH connection remains open the RDP-server running on the LAN host “192.168.1.39” becomes available as “localhost:3389” … so you RDP into your LAN, you open your web browser at home, you can surf away as you want … And your browsing history stays at home and unless you somehow activated some cloud-sync feature (… why oh why would you?) it should never ever end up on your work machine.

Feel free to expand the number of ports (e.g. 5901 for VNC in addition to 3389 for RDP?).

File-transfer protocols such as SFTP or “rsync” of course work too … In case you downloaded something and need it transferred:

sftp -P2243 -o "ProxyCommand=nc -X connect -x clientproxy.corporation.net:8079 %h %p" myuser@myhost.athome.ddns-domain.nu

rsync -av --progress -e ssh -p 2243 -o "ProxyCommand=nc -X connect -x clientproxy.corporation.net:8079 %h %p" 2>/dev/null myuser@myhost.athome.ddns-domain.nu:/path/to/remote/source/fileorfolder /local/path/to/destination/folder

​

Disclaimer: USE AT YOUR OWN RISK.

In my experience in most places where they catch you doing this at work and without permission, they fire + sue you.

Again: USE AT YOUR OWN RISK.