I have the Client machine living somewhere on the Internet, and it needs to access a custom port of Target machine (or, initially any port on any reachable machine, but, eventually, particular port, say, 12345, on Target) that lives inside a private network and accepts connections only from the machines inside that network.

Client --X-->  |   Target:12345
(the Internet)   (private network)


The private network has a VPN server, but I have no root access on the Client, and I cannot use (Open)VPN there, and, hence, I have no easy access to the private network.

"Gate" without root

The first thing that, presumably, can help Client reach the Target is the Gate machine in the private network that is reachable from the outside world, and Target would accept TCP connections from Gate:

Client --?--> Gate --ok--> Target:12345

The problem is to set up transparent TCP traffic forwarding at the Gate, so that the Client connecting to Gate[:some_port] would actually talk to Target:12345.

  • If I had root access at the Gate, I would use iptables to transparently forward TCP traffic coming to Gate[:chosen_port] to Target:12345. However, I do not have root access at Gate (though, I have a user-level access there and can SSH to it).

  • If I had an SSH access to Target, I would establish an SSH tunnel between Target and Gate, making Target reachable from Client through this tunnel; however, I do not have SSH access at Target (in fact, the only thing I can do with the Target is establishing TCP connection with its port 12345 from within the private network).

Is it possible to establish the above described TCP forwarding having no root at both Client and Gate and having no SSH access to Target? If the answer is no, then there is a follow-up question.

"Gate" without root + "Insider" with root

Besides the Gate, the private network has machine Insider where I do have root access.

Client -ssh-> Gate -ssh-> Insider --?--> Target:12345

There is a reverse SSH tunnel established from Insider to Gate, so Client can SSH to Insider, and, theoretically, Insider can, then, ("manually") establish a TCP connection with Target's 12345 port. However, it is not exactly a transparent TCP traffic forwarding solution I am looking for.

In this latter situation, can my having root access at Insider help transparently forward traffic from Client to Target:12345?

Any suggestions are greatly appreciated!

1 Answer 1


You can use ssh port forwarding

ssh [email protected] -L 10000:

After you can connect on localhost:10000 and actually you will connect to the service at

You can also create a "proxy" with ssh -D parameter.

  • Thanks, Francesco. With respect to the example in my question, what is "work.example.org"?
    – victor
    Mar 11, 2015 at 8:28
  • work.example.org is the ssh server. is the address of the machine which hosts the service that you want to access.
    – Francesco
    Mar 11, 2015 at 9:04
  • In your example with local SSH port forwarding, the Client knows that its connection to destination is proxied. Is it possible to achieve the same result, but without the Client's knowing about the intermediary (that is, a program running on the Client will try to connect to, but, the Client, transparently to the program running on it, will forward the request through [email protected])?
    – victor
    Mar 11, 2015 at 10:06
  • if you have a hostname for (e.g. test-machine) and you put it into the /etc/hosts file of the client machine: "test-machine", the user (on that client machine) can connect to test-machine:10000 that it will actually use the local tunnel instead of the remote address.
    – Francesco
    Mar 11, 2015 at 10:28
  • Unfortunately, (1) the Destination is only known by its IP address, and (2) I do not have root access on the Client. I was hoping that there is some "mild" version of iptables that can capture traffic from a selected process rather than globally (which would require being root).
    – victor
    Mar 11, 2015 at 10:34

You must log in to answer this question.

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