When you use an SSH tunnel, as far as the target server is concerned, its client is the SSH server, not the actual client connecting to the SSH tunnel.
For example, if you have an SSH client running on 10.1.1.1
, connecting to an SSH server on 10.2.2.2
and establishing a tunnel to 10.3.3.3
, when a client (possibly from 10.4.4.4
or anywhere else) connects to the tunnel on the 10.1.1.1
end, it gets access to 10.3.3.3
as if it was coming from 10.2.2.2.
, not 10.1.1.1
or 10.4.4.4
.
This allows such connections to bypass firewall rules regarding the target server that would have allowed connections from the machine running the SSH server, but not further.
This is typically a problem if the SSH server is a gateway between two networks, with public IP address and one private IP address, for example. A firewall rule that would only allow access to certain services within the internal LAN wouldn't catch connections from that SSH server (unless a special case was made for that machine).
The remote connections may come from much further. On the SSH client side, some SSH clients can bind their listening socket to a specific IP address (e.g. localhost
), at least to prevent connections from remote machines from that end. However, you rely on the client using these settings properly.
If your users are allowed to make this sort of connections, or if the firewall (and related) rules you use on your network handle the SSH server's IP address specifically to take this into account this, it can be fine. This being said, you may still want to check where the tunnels are established too, you could also get into trouble with other third party servers too otherwise.
If you don't need any of this, disabling this feature would be better.