12

What is the difference in functionality between the two? I'm a bit confused by it.

Local forwarding makes a remote port locally available.

Remote forwarding makes a local port remotely available.

But this 'availability' will work in both directions... or does it?

E.g. the following (issued from a host 'home')

ssh -R 1234:localhost:2345 user@work

This will establish a secure tunnel between work::1234 and home::2345, right?

If I put in anything on one end, it will come out on the other end.

But then, I can achieve the same by the following call from the host 'work':

ssh -L 1234:localhost:2345 user@home

So, the only difference is the where I call it from, correct?

1
  • In your example there is no difference in functionality. You sort-of self-compensate for using the opposite argument by interchanging target hosts. Had you not done this and used both of them from within 1 single host - it would already trigger a completely opposite behavior.
    – XXL
    Nov 2, 2011 at 18:28

5 Answers 5

4

The major practical difference, is that if connecting 2 computers A and B, and B is behind a firewall or NAT Router that you don't control, and it's blocking incoming.. You're sitting at A. You can't get A to connect to B. But B won't block outgoing.. So you get B to connect to A.

--added clarification--

The above, which the questioner understood.. means the major practical difference between local and remote forwarding. ssh -L and ssh -R when you'd use each. I wasn't commenting on the specific example commands he gave, where he switches -L and -R, and which sshd server he connects to. But now I will attempt to comment on it.. With the ssh commands he gave, from the perspective of the regular client and regular server, there appears to be no difference,as it doesn't say "ah this is an ssh client and this is an ssh server.." it doesn't know ssh , and which is the client/server aspect of ssh is irrelevant and unknown to the regular client and regular server too. They just care about who is listening, and from their perspective, it looks the same. The work computer is listening and on 1234. They don't notice that in one case it's an sshd.exe ssh server, and in the other case it's an ssh.exe, ssh client. By the way, where the ssh client is, is considered local.

2
  • ok, thank you, that exactly answered my question! :-)
    – nandaloo
    Nov 4, 2011 at 0:50
  • @nandaloo I think it's called a reverse ssh tunnel. If we use made up terms initiator and listener ('cos those terms are less ambiguous than client and server). The idea is that you have your regular initiator and listener and your ssh initiator and listener. You can't choose where your regular initiator and listener are. e.g. HTTP server(regular listener) is on B. B is behind a firewall. A has the HTTP client(regular initiator). You put your SSH initiator on B. See with a reverse tunnel the SSH initiator and listener, are on opposite computers to the regular initiator and listener.
    – barlop
    Nov 4, 2011 at 1:15
10

Yes, if I understand it correctly, local port forwarding from a to b should be identical to remote port forwarding from b to a (and vice versa). An outgoing tunnel from a to b (viewed from a) should be equal to an incoming tunnel from a to b (viewed from b).

Local port forwarding creates an outgoing tunnel which can be used to bring a public internet computer to local machine. A local user can access a remote host:port combination on a local host, because the given port on the local (client) host is forwarded to the given host and port on the remote side:

ssh -L local_port:remote_host:remote_port user@hostname

Remote port forwarding creates an incoming tunnel which can be used to bring a local computer into the public internet. An internet user can access a certain local host:port combination on a remote host. The given port on the remote (server) host is forwarded to the given host and port on the local side:

ssh -R local_port:remote_host:remote_port user@hostname
3
  • 1
    I suppose another difference, besides the syntax, would be the process that listens for the user to connect. ssh.exe -L tells ssh.exe to listen(besides the outgoing connection it's already making). ssh.exe -R tells sshd.exe to listen(besides the listening it's already doing).
    – barlop
    Jun 7, 2013 at 19:51
  • @0x4a6f4672, What does 0x4a6f4672 mean?
    – Pacerier
    Jan 16, 2015 at 6:21
  • @Pacerier just my initials “JoFr” in hexadecimal notation :-)
    – 0x4a6f4672
    Jan 16, 2015 at 9:39
3

With local port forwarding you (the client) open a listening socket on your computer and connect your application-level protocol client to this socket. Now the connection is forwarded over SSH to the server. The server connects to the remote host and tunnels the data from your protocol client to the final destination.

With remote port forwarding the server opens a listening socket on the server host. Some remote application connects to this host and sends information which is transferred to your client computer. Here the connection is established to the final destination (some application-level protocol server running on your computer or on your network) and the data is transferred from remote application to the final destination.

1
  • thanks, that made it clearer how port forwarding works. And thanks for moving the question - I just didn't even know about this superuser site :-)
    – nandaloo
    Nov 4, 2011 at 0:49
1

This is best understood with small examples. In these exmples the connections are structured like this:

Local Server--(LAN)--Terminal-----(SSH,usually via Internet)-----Tunnel Endpoint--(LAN)--Remote Machine

You use local port forwarding if you want to tunnel to a certain remote machine/port, reachable by the tunnel endpoint you have ssh access to. Therby, that remote machine's port is also accessible locally on your own terminal, i.e. http:// localhost:terminal_port /.

That is done using the following syntax:

ssh -L terminal_port:remote_machine_ip:remote_service_port -p tunnel_endpoint_ssh_port ssh-login@tunnel_endpoint_ip

You may use remote port forwarding if you want to enable ANYONE(!) remote, who is able to reach the tunnel endpoint's listening port to be able to remotely access an ip/port in your local LAN. To your local server, it looks like the connection from the remote machine are initiated by the terminal.

The Syntax is:

ssh -R tunnel_endpoint_listen_port:local_server_ip:local_server_port -p tunnel_endpoint_ssh_port ssh-login@tunnel_endpoint_ip
0

The manpage for socat clarifies this very well. Yes, I know ssh and socat are two entirely different things - but socat's documentation is just very good.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .