I ask you to help me establish tunnels to meet the following needs:

There is server LocalTest, on which I am root, so I can do anything (Debian SSH). This server is enabled to access (IP filtering is present on the other party) port 443 a server which we can call WebserviceServer. I want to enable person who can not open SSH to localtest to reach WebserviceServer:443. So I need to open a server port on Localtest (for example 10000), and forward all content to WebserviceServer:443. This is the first task.

The second task is, that on a specific port LocalTest is listening as web service server (8099). I need to forward it time by time to the port of different workstations for testing reasons. So all traffic and connection coming to LocalTest:8099 needs to be forwarded to somestation(call it John):someport(5000).

Could you help me with the ssh commands I need to issue on Localtest to meet the needs?


Both of your problems don't sound to me like ssh tunnelling would be the best solution.

but still here are some of the ideas I came up with to achieve these goals:

Problem 1: using LocalTest as a reverse proxy for WebserviceServer

localtest:~ $ ssh -L *:10000:webserviceserver:443 localhost

make sure you allow "GatewayPorts" and "AllowTcpForwarding" in /etc/ssh/sshd_config on LocalTest and sshd is restarted.


this opens up a connection from localtest to it self and at the same time creates a tunnel listening on port 10000 on all interfaces of localtest redirecting traffic to webserviceserver port 443

Problem 2: redirecting traffic to test workstations

with ssh this is actually the same as Problem 1

localtest:~ $ ssh -L *:8099:somestation1:5000 localhost

if you want to connect to another Test Workstation simply quit the first connection and use something like

localtest:~ $ ssh -L *:8099:somestation2:5002 localhost


as it is basically the same solution as with problem 1 it has also the same explanation (just different hosts and ports :-) )

some thoughts

Keep in mind that both of the previous solutions open up the target systems (webserviceserver, somestationX) to anyone with access to LocalTest

And as I mentioned in the beginning I don't think ssh is the right tool to do this for a few reasons. Some of them being:

  • with ssh you can only tunnel tcp traffic easily
  • ssh is rarely the best solution for permanent tunnels
  • Problem 1 sounds more like a case for a reverse proxy to me (or iptables as mentioned by others)
  • Problem 2 definitely sounds like a case for iptables to me

I'd personally setup a simple script for the second problem which allows you to reset the iptables rules for each test system you want to use, something like

localtest:~ # reset_target somestation

such a script would have to delete an old redirect (to another test workstation) in iptables and then setup the new one. I'm not quite fluent with the iptables syntax at the moment and so I can't provide such a script right away but I'm sure somebody here could help you out with something like that if needed.


What it sounds like your asking for should be able to be achieved by using IPTables and simple port forwarding - at least the first part.

As for the second part, you state that on port 8099 there is a 'web service server', the traffic of which you would like to forward on to 'John'. I assume you would want to still let the 'web service server' process the information, in which case a bridge between the 'web service server' and 'John' might be what you're looking for. For this, you can use probably use netcat.

Learn about port forwarding with IPTables: http://www.socialhacker.com/howtos/port_forwarding.php

Learn about using Netcat: http://www.sans.org/security-resources/sec560/netcat_cheat_sheet_v1.pdf (Netcat Relays are what you want, I believe).

Hope this information is of some help.

  • First part: echo 1 > /proc/sys/net/ipv4/ip_forward; iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 10000 -j DNAT --to-destination WebServiceServer:443 # check that eth0 is the incoming interface – LatinSuD Oct 14 '10 at 10:08
  • Second part: looks like you want load balancing besides SSH tunneling or not. – LatinSuD Oct 14 '10 at 10:09
  • Not loadbalancing, but reaching 3rd party test system with restricted access from your workspace – Gábor Lipták Oct 14 '10 at 11:41

TYou are going to want to use the -L or -R flag with the appropriate :IP: specified, as well as enabling Gateway ports in the sshd config

  • I spent a lot of time with trying, but in vain. Concrete example would help. – Gábor Lipták Oct 14 '10 at 11:40
  • LocalTest$> ssh -L LocalTest:1000:otherserver:443 user@LocalTest, need to make sure that the gateway flag and the firewalls are set correctly to allow other server to connect to 1000, – Jimsmithkka Oct 15 '10 at 3:15
  • i have used this method to circumvent a block of port 25 for a server test, forwarding traffic in on a system that can listen on 25 to the server that was disallowed 25 on the port 2525 – Jimsmithkka Oct 15 '10 at 3:18
  • note, the 3rd host that needs to acces the remote host will need to connect to LocalTest instead of the locked out host – Jimsmithkka Oct 15 '10 at 9:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.