Skip to main content

header

To make it quick, I wish I would have known earlier about port forwarding and tunneling. I've never bothered to look into it, and therefore, this is fairly new to me too. With this blog post I try to understand it better myself, and share some experience and tips with you.

General links:
SSH manual
sshd_config manual

What is port forwarding and tunneling used for?

What is it

Encrpted TCP connection between SSH client and SSH server. TCP ports or UNIX sockets can be used. If I you see port, I mean only TCP.

Use cases #

SSH tunneling can be used for many use cases. I won't go into details, but the following post should show enough examples and options to find use in your day-to-day work.

Security:
encrypt insecure connection (FTP, other legacy protocols)
access webadmin panel via secure SSH tunnel (Pub Key Authentication)
less ports exposed (only 22, instead of 80/443)
Troubleshooting:
different routes
bypassing firewalls/content filters
Connection:
reach server behind NAT
use jumphost to reach internal servers over the internet
exposing local ports to the internet

There are many more use cases, but this overview should give you a sense of possibilities.

WHY: Not sure about the format

Limitations #

UDP

SSH depends on a reliable delivery to be able to decrypt everything correctly. UDP does not offer any realibility and is therefore not support and recommended to use over the SSH tunnel.

That said, there are ways to do it, like described in this post. I've not tested it yet!

TCP-over-TCP

It lowers the throughput due to more overhead and increases the latency. On connections with packet loss or really high latencies (e.x. satelite) it easily can cause a TCP meltdown.

This post is a great write-up.

Nevertheless, I've been using a OpenVPN-over-TCP for a while, and it worked flawlessly. Less throughput than UDP, but reliable. So, it highly depends on your setup.

Not a VPN replacement

Overall, it is not a VPN replacement. SSH tunneling can be used as such, but a VPN is better suited for better perfomance.

Potential security risk

As everything it can be used by criminals for firewall and IDP evasion, and more. It is recommended to turn it off, if it not needed.

Port forwarding

Before we start: the options of the following examples and be combined, and configured to suit your setup. As a side note: if the bind_address isn't set, localhost will the default

Configuration / Preperation #

  • The local and remote user must have the necessary permissions on the local and remote machine respectivly to open ports. 0-1024 requires root privileges - if not configured differently - and the rest of the ports can be configured by standard users.
  • configure clients and network firewalls accordingly
SSH port forwarding must be enabled on the server:
AllowTcpForwarding yes
It is enabled by default, if I recall it correctly
If you farwad ports on interfaces other than 127.0.01 then you'll need to enabl GatewayPorts on the SSH server:
GatewayPorts yes

Don't forget to restart the ssh server service.

SSH Jumphost / SSH tunnel #

Transparently connecting to a remote host through one or more hosts.

ssh -J user@REMOTE-MACHINE:22 -p 22 user@10.99.99.1

ssh-port-forwarding-info

Side note: The port addressing can be removed, if the default port 22 is used!

On REMOTE-MACHINE as jumphost:

[user@REMOTE-MACHINE]$ ss | grep -i ssh      
tcp   ESTAB 0      0                                             167.135.173.108:ssh    192.160.140.207:45960        
tcp   ESTAB 0      0                                             10.99.99.2:49770      10.99.99.1:ssh   
Explanation:
167.135.173.108 - public IP of REMOTE-MACHINE
92.160.120.207 - public IP of LOCAL-MACHINE
10.99.99.2 - internal IP of REMOTE-MACHINE
10.99.99.1 - internal IP of REMOTE-WEBAPP
Using multiple jumphosts
Jumphosts must be separated by commas:
ssh -J user@REMOTE-MACHINE:22,user@ANOTHER-REMOTE-MACHINE:22 -p 22 user@10.99.99.1

Local Port Forwarding #

Example 1
ssh -L 10.10.20.2:8001:localhost:8000 remotesuser@195.201.0.13

ssh-port-forwarding-info

Access logs of the webserver on REMOTE-MACHINE that only listens on 127.0.0.1:
127.0.0.1 - - [30/Dec/2022 18:05:15] "GET / HTTP/1.1" 200
the request originates from LOCAL-MACHINE
Example 2
ssh -L 8001:10.20.10.8:8000 remotesuser@195.201.0.13

ssh-port-forwarding-info

Access logs of the webserver on REMOTE-WEBAPP:
10.20.10.7 - - [30/Dec/2022 21:28:42] "GET / HTTP/1.1" 200
the request originates from LOCAL-MACHINE

Remote Port Forwarding #

Example 1+2
ssh -R 8000:localhost:8001 user@REMOTE-MACHINE

ssh-port-forwarding-info

ssh -R 8000:10.10.10.2:8001 user@REMOTE-MACHINE

ssh-port-forwarding-info

Example 3
ssh -R 10.99.99.2:8000:10.10.10.2:8001 user@REMOTE-MACHINE

ssh-port-forwarding-info

Important: GatewayPorts yes must be enabled on the SSH server to listen on another interface than the loopback interface.

Dynamic port forwarding #

To forward more than one port, SSH uses the SOCKS protocol. This is a transparent proxy protocol and SSH makes us of the most recent version SOCKS5.

Default port for SOCKS5 server is 1080 as defined in RFC 1928.

The client must be configured correctly to use a SOCKS proxy. Either on the application or OS layer.

Example

ssh -D [bind_address:]port user@REMOTE-MACHINE

ssh-port-forwarding-info

Use curl on a 'LOCAL' client to test the correct connection/path:
curl -L -x socks5://10.10.10.1:5555 itt.sh/ip
If everything works out, you should get the public IP of the REMOTE-MACHINE back

SSH TUN/TAP tunneling

I won't go into detail, but you can create a bi-directional TCP tunnel with the -w flag. The interfaces must be created beforehand, and I haven't tested it yet.

-w local_tun[:remote_tun]

How to run in the backround #

The native way to run the tunnel in the background would be -fN:
-f - run in the background
-N - no shell

ssh -fN -L 8001:127.0.0.1:8000 user@REMOTE-MACHINE

Others than that: use screen or some other tools.

Remove tunnel running in the background
user@pleasejustwork:~$ ps -ef | grep ssh
[...]
user      19255       1  0 11:40 ?        00:00:00 ssh -fN -L 8001:127.0.0.1:8000 user@REMOTE-MACHINE
[...]
Kill the process with the PID:
kill 19255

The inspiration of this blog post are the following unix.stackexchange answer and blog post of Dirk Loss.

Thanks to Frank and ruffy for valuable feedback!


E-Mail hellofoo@ittafoovern.comcom
Fediverse @itt@fosstodon.org
Twitter ITTavernCom
Matrix #lounge:matrix.ittavern.com

More reading: