ssh -L X:third:Y Server
Three (depends how you count) things happen here:
* You connect to remote machine Server, there is now a "SSH tunnel" your machine and Server
* The ssh client in your machine listens port tcp/X of your machine
* When you write something to localhost:X, ssh forwards it via tunnel to Server, where the sshd initiates connection to third:Y
The firewall of your machine must allow connections to localhost:X, the firewall on Server must allow outbound connections (app in Server, sshd, connects out), and naturally the third must allow connections to its Y.
Only the Server needs to know (have route) how to connect to third, not your machine.
The third will think that it talks to Server (so essentially ssh does NAT your connection to third:Y).
SSH has also options -R and -D.
The -R makes sshd listen on a port and forward connections to it into our client machine via the tunnel. (Default config on server probably disables this.)
The -D makes ssh client listen on a port like it were a SOCKS5 proxy. Tell your browser to use localhost as proxy and then you can connect anywhere "from Server".
[Edit]
Then you have -J, ProxyJump. Say ssh -J A,B,C D
This makes ssh to connect to A, but not create shell session in it.
Instead, the A opens ssh connection to B. The B opens ssh connection to C, and the C opens ssh connection to D.
What you see is authentication to A, B, C, and D (ssh keys are awesome), and shell session on D.
Why do that? When you, A, and B can't connect to D, but C can, and you can't directly connect to B either (but A can).
You naturally can have the -L, -R, and -D on such proxied tunnel too.