Americas

  • United States
sandra_henrystocker
Unix Dweeb

Port Forwarding with Perl

Analysis
Sep 10, 20083 mins
Data CenterLinuxNetworking

Many people are thinking of ssh tunnels when they talk about port forwarding. It’s easy to set up and you probably have everything you need (i.e., ssh) on most any system you want to use it on. Port forwarding does not have to be done through a tunnel, however, nor does it require ssh. Any script or program that rewrites packets in such a way as to accomplish the forwarding of packets from one port or system to another can be used for port forwarding. This doesn’t mean that it’s easy to build this kind of script or program, but it does mean thay tools like this are available.

One good example of a port forwarding script is Accordata’s Port-Proxy. A Perl script which uses a number of modules such as IO::Socket and IO::Select, port-proxy.pl requires that you install your port forwarding specifications in a configuration file which it reads when invoked. The line “forward=1111, localhost:2222”, for example, forwards connections sent to port 1111 to port 222 on the same system. If you put the following lines in your configuration file, port-proxy will listen on both ports 1111 and 3333 and will pass connections to the latter to fermion.particles.net.

Listen on 1111; forward to localhost:2222
Listen on 3333; forward to fermion.particles.net:4444

You can see that the specified ports are listening using netstat. One thing you might notice in this netstat output that is different than what we would see if we were forwarding the ports using ssh is that these LISTENs will accept connections from any system; unlike ssh, they do not listen only for connection requests generated locally. This means that you could easily set up systems to “daisy chain” port connections from one system to the next.

tcp4       0      0  *.1111          *.*             LISTEN
tcp4       0      0  *.3333          *.*             LISTEN

NOTE: The “*” in “*.1111” and “*.3333” means listen for requests from any system.

You can download port-proxy from Accordata GmbH using this URL:

http://www.accordata.de/downloads/port-proxy/index.html

The site is both in German and English. The notes online say that port-proxy has been tested with Linux and Windows, but I’ve used it on Solaris and Mac OS X as well. If you have Perl installed on your system and a reasonable set of modules, it will probably work for you as well.

If you test with two systems, you can run a listen script like that I wrote about last week on, say, port 4444 on the remote system. If you then forward port 3333 on the local system to port 4444 on the remote as shown in the example above, you should see something like this when you telnet to the local port 3333:

boson> telnet localhost 3333
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
------------------------------
You have connected to fermion
------------------------------
Connection closed by foreign host.

The features of port-proxy include:

    * Port forwarding on the same system
    * Port forwarding to a remote system
    * Forwarding over https-tunnel to port 443
    * Forwarding over https-tunnel to any port
    * Tested with Linux, Windows, Solaris and Mac OS X

To install port-proxy:

    * Install Perl
    * Download the zip file
    * Unzip to an any directory
    * Edit the configuration file
    * Start the program

If you don’t require the security of a tunnel or want to work through an https, this tool might be just what you need. Since it’s written in Perl, you can take as close a look as you like on how the port forwarding in accomplished. Nice tool!

sandra_henrystocker
Unix Dweeb

Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as "USL" (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she's chasing the bears away from her bird feeders.

The opinions expressed in this blog are those of Sandra Henry-Stocker and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.

More from this author