One thing to add is that you can even open tunnels during an interactive session without disconnection.
To do this, type the escape command sequence ~C (will not show) and it will drop you to the control prompt. You can then add tunnels.
ssh> -L 8000:localhost:9000
When using nested ssh session, you can send escape commands to any of them by the number of tildes. For example, if you ssh into Server A and then from Server A to Server B:
~~. # drop session from Server A to Server B
~. # drop original session into Server A
ssh <target> -R <just a port number>
This opens up a localhost port on the target that acts as a socks server which tunnels all your traffic through the source machine.
This is great for machines that you can SSH into, but are otherwise completely isolated from the network, or are monitored heavily. You can jump on, and pull down everything you need from the existing SSH connection, rather than using the machine to make requests out to the internet directly.
This is also good if the source machine is a web server or something on a secured network which can SSH out, but not much else, and the destination is your command and control server on the internet. Then it opens up a socks port on the C&C machine that gives full access to the internal network, impersonating the source machine.
Every other -R is a point to point TCP connection, but setting up a SOCKS proxy with -R is magic. More analogous to a reverse -D than a reverse -L. Super useful.
Indeed: committed in September 2017, released in v7.6 in October 2017.
 : https://unix.stackexchange.com/a/118650/289353
On the remote host, have the vnc server listen only on localhost:5901
This assumes everyone who can ssh to the server should be allowed access.
On your workstation, form an ssh tunnel to that remote host and its port, and link it your own localhost:5901
Open your vnc client GUI and set it to open 127.0.0.1:5901, voila, vnc session.
More fun things: say for example you have a big remote xen dom0 with a lot of unique qemu HVM VMs running on it. Configure each of their .cfg files for xen to spawn a vnc server on localhost only and a unique port number per domU (5902,5903,5904,etc). Then use the same method to connect.
SSH supports unix domain socket forwarding and even cross unix/ip forwarding with a syntax like:
ssh -L /path/to/sock:/path/to/sock
ssh -L /path/to/sock:localhost:5901
ssh -L 5091:/path/to/sock
Unfortunately I haven't been able to convince tigervnc viewer to connect to a unix domain socket, so I don't have a fully scripted connection, but remmina and tigervnc server work fine.
Also, forwardings / connections fail if the socket already exists when the listening side starts up (often an unclosed leftover), so I rm them before starting the ssh connection / vnc server and it works reliably.
LocalForward 5903 localhost:5900
LocalForward 5904 localhost:5900
to remote into machine mac-b, in a terminal window:
After that, you can right-click on screen-sharing in the dock - even when it's not running - and you will see a context menu item for "mac-b 5904.vncloc"
By the way, mac to mac screen sharing is very well done (will they axe it next?)
- it is very fast
- the keyboard stuff just works
- you can copy/paste even rich text between the local and remote macs
- you can drag and drop files from the remote desktop to the local one
And it works just as well on a locked down corporate network as it does on a home network. Why people put up with garbage VPN software is beyond me.
A couple reasons for a regular VPN: they can be made automatic and persistent so the tunnel is always ready for use, they can tunnel other protocols besides TCP, they can tunnel entire networks, and using UDP as the tunnel protocol helps avoid the TCP-in-TCP congestion issues.
It still does have overhead, so lower bandwidth. Also, TCP, SSH and/or TLS forwarding of UDP, IP or Ethernet can have issues with delays, re-transmits etc (TCP-in-TCP).
For example, SSH port forwarding is TCP only, so if you need UDP, you‘ll need a VPN.
The ssh SOCKS proxy supports UDP. I use Firefox with a SOCKS proxy via ssh (e.g. ssh -D 2222 hostname) to get around geoblocking and accessing papers via an institutional account. The tsocks program can also let you use a SOCKS proxy for an arbitrary command in linux. I find it much more convenient than a VPN, as it can be easily applied to single programs.
The less cooperative your applications are (even though cooperation can be somewhat enforced using tsocks, as you mention, which can be further made to apply system-wide using sshuttle ), the more a VPN will start to make sense.
Alternatively, you might be unknowingly using un-proxied UDP: Many AV systems only enforce IP restrictions on the signalling protocol (which is often TCP); the actual media can then take whatever path it wants.
By the way, it seems like you can forward UDP over sshuttle  when used with tproxy (which seems to be a Linux-only feature)!
1080 is often default for socks, but I've also seen places where it's 1085 (for socks5 -- 1084 for socks4)
Ultimately it can be whatever you want.
I used to run a site-to-site VPN between two sites a couple of decades ago with a simple script doing just this. These days we'd use OpenVPN or strongSwan for such use-cases but despite the 'hackiness' of the former approach, it worked reliably for years.
Sometimes I actually wish SSH would offer UDP support for precisely this use case, but arguably, TCP VPN support is already a stretch in terms of scope for SSH.
Domain sockets can be forwarded via ssh with the same -L and -R arguments, including cross unix/ip forwardings.
Edit: Never mind, it seems it was a problem with Firefox. Chromium worked.
Reaching target hosts multiple jump-hosts away, and going the wrong way through multiple firewalls segregating those lans, is another use-case of tunnels I've found handy.
Target_host can be reached by doing tunnel-in-tunnel-in-tunnel-in-tunnel. Each tunnel gets you past one firewall. The final tunnel you can just ssh to fw3 via a local tunnel and a local port on your_remote_client now takes you straight to target_host.
I once also wrote a guide to access remote IoT devices using SSH tunnels:
I also found the following very nice: (Same info but presented in a different way.)
A lot of tunneling tutorial, medium articles and blog post mixes local and remote port forwarding and use the words interchangeably which cause a lot of confusion.