Port forwarding on Linux

SSH:

this is called GatewayPorts in SSH. An excerpt from ssh_config(5):

GatewayPorts
        Specifies whether remote hosts are allowed to connect to local
        forwarded ports.  By default, ssh(1) binds local port forwardings
        to the loopback address.  This prevents other remote hosts from
        connecting to forwarded ports.  GatewayPorts can be used to spec‐
        ify that ssh should bind local port forwardings to the wildcard
        address, thus allowing remote hosts to connect to forwarded
        ports.  The argument must be “yes” or “no”.  The default is “no”.

And you can use localhost instead of M in the forwarding, as you’re forwarding to the same machine as you’re SSH-ing to — if I understand your question correctly.

So, the command will become this:

ssh -g -L 8001:localhost:8000 -f -N user@remote-server.com
OR
ssh -g -L 2222:localhost:8888 -N -o GatewayPorts=yes hostname-of-M

(/usr/bin/ssh -g -vvvvv -L 0.0.0.0:29906:localhost:1337 localhost -N )

and will look like this in netstat -nltp:

tcp        0      0    0.0.0.0:2222   0.0.0.0:*  LISTEN  5113/ssh

Now anyone accessing this machine at port 2222 TCP will actually talk to localhost:8888 as seen in machine M. Note that this is not the same as plain forwarding to port 8888 of M.

OR

he command for forwarding port 80 from your local machine (localhost) to the remote host on port 8000 is:

ssh -R 8000:localhost:80 oli@remote-machine

This requires an additional tweak on the SSH server, add the lines to /etc/ssh/sshd_config:

Match User oli
   GatewayPorts yes

Next, reload the configuration by server executing sudo reload ssh.

The setting GatewayPorts yes causes SSH to bind port 8000 on the wildcard address, so it becomes available to the public address of remote-machine (remote-machine:8000).

If you need to have the option for not binding everything on the wildcard address, change GatewayPorts yes to GatewayPorts clientspecified. Because ssh binds to the loopback address by default, you need to specify an empty bind_address for binding the wildcard address:

ssh -R :8000:localhost:80 oli@remote-machine

The : before 8000 is mandatory if GatewayPorts is set to clientspecified and you want to allow public access to remote-machine:8000.

Relevant manual excerpts:

ssh(1)

-R [bind_address:]port:host:hostport
Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side. This works by allocating a socket to listen to port on the remote side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the local machine. By default, the listening socket on the server will be bound to the loopback interface only. This may be overridden by specifying a bind_address. An empty bind_address, or the address ‘*’, indicates that the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if the server’s GatewayPorts option is enabled (see sshd_config(5)).

sshd_config(5)

GatewayPorts
Specifies whether remote hosts are allowed to connect to ports forwarded for the client. GatewayPorts can be used to specify that sshd should allow remote port forwardings to bind to non-loopback addresses, thus allowing other hosts to connect. The argument may be ‘no’ to force remote port forwardings to be available to the local host only, ‘yes’ to force remote port forwardings to bind to the wildcard address, or ‘clientspecified’ to allow the client to select the address to which the forwarding is bound. The default is ‘no’.

See also:

 

Change_IPTABLE:

There is another way. You may set up port forwarding from S:2222 to W:8888 with iptables. Single command:

iptables -t nat -A PREROUTING -p tcp --dport 2222 \
         -j DNAT --to-destination 1.2.3.4:8888

where 1.2.3.4 is M’s IP address. It is called NAT (Network Address Translation).

 

Another Sample:

iptables -t nat -I PREROUTING 1 -p 6 –dport 9222 -j DNAT  –to 10.0.1.1:1337
iptables -t nat -I POSTROUTING 1 -p 6 -d 10.0.1.1 –dport 1337 -j SNAT –to-source 10.0.1.2

 

e.g.:

I would like do some NAT in iptables. So that, all the packets coming to 192.168.12.87 and port 80 will be forwarded to 192.168.12.77 port 80.

 

#!/bin/sh

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -F
iptables -t nat -F
iptables -X

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77:80
iptables -t nat -A POSTROUTING -p tcp -d 192.168.12.77 --dport 80 -j SNAT --to-source 192.168.12.87

 

 

 

Using NetCat:

A naive try would be something like this:

$ nc -l 8082 | nc remote_host 80

Yes, it does forward the request from local port 8082 to remote_host:80, but the response is dumped to stdout, not routed back to the client as expected.

Using a named pipe makes it work:

$ mkfifo backpipe
$ nc -l 8082 0<backpipe | nc remote_host 80 1>backpipe

Use tee to get a glimpse of the response through the pipe (I wasn’t able to find a way to dump the request):

$ nc -k -l 8082 0<backpipe | nc localhost 80 | tee backpipe
HTTP/1.1 200 OK
Date: Fri, 30 Sep 2011 22:11:27 GMT
Server: Apache/2.2.16 (Unix)
Last-Modified: Sat, 20 Nov 2004 20:16:24 GMT
ETag: "2d0945-2c-3e9564c23b600"
Accept-Ranges: bytes
Content-Length: 44
Content-Type: text/html

<html><body><h1>It works!</h1></body></html>

The GNU netcat has a different syntax than the stock nc. It also supports different switches.

  1. To listen to port 1234:
    $ netcat -l -p 1234
    
  2. To make bash a server on port 1234:
    $ netcat -l -p 1234 -e /bin/bash
    
  3. Forward local port 8082 to remote port 80:
    $ ./netcat -L 192.168.80.143:80 -p 8082
    
  4. Port forwarding with hex dump:
    $ ./netcat -L 192.168.80.143:80 -p 8082 -x
    Received 174 bytes from the socket
    00000000  47 45 54 20  2F 20 48 54  54 50 2F 31  2E 31 0D 0A  GET / HTTP/1.1..
    00000010  55 73 65 72  2D 41 67 65  6E 74 3A 20  63 75 72 6C  User-Agent: curl
    00000020  2F 37 2E 32  31 2E 30 20  28 78 38 36  5F 36 34 2D  /7.21.0 (x86_64-
    00000030  72 65 64 68  61 74 2D 6C  69 6E 75 78  2D 67 6E 75  redhat-linux-gnu
    00000040  29 20 6C 69  62 63 75 72  6C 2F 37 2E  32 31 2E 30  ) libcurl/7.21.0
    00000050  20 4E 53 53  2F 33 2E 31  32 2E 31 30  2E 30 20 7A   NSS/3.12.10.0 z
    00000060  6C 69 62 2F  31 2E 32 2E  35 20 6C 69  62 69 64 6E  lib/1.2.5 libidn
    00000070  2F 31 2E 31  38 20 6C 69  62 73 73 68  32 2F 31 2E  /1.18 libssh2/1.
    00000080  32 2E 34 0D  0A 48 6F 73  74 3A 20 36  37 2E 31 33  2.4..Host: 67.13
    00000090  30 2E 36 39  2E 31 34 33  3A 38 30 38  32 0D 0A 41  0.69.143:8082..A
    000000A0  63 63 65 70  74 3A 20 2A  2F 2A 0D 0A  0D 0A        ccept: */*....  
    Sent 276 bytes to the socket
    00000000  48 54 54 50  2F 31 2E 31  20 32 30 30  20 4F 4B 0D  HTTP/1.1 200 OK.
    00000010  0A 44 61 74  65 3A 20 46  72 69 2C 20  33 30 20 53  .Date: Fri, 30 S
    00000020  65 70 20 32  30 31 31 20  32 32 3A 33  32 3A 30 35  ep 2011 22:32:05
    00000030  20 47 4D 54  0D 0A 53 65  72 76 65 72  3A 20 41 70   GMT..Server: Ap
    00000040  61 63 68 65  2F 32 2E 32  2E 31 36 20  28 55 6E 69  ache/2.2.16 (Uni
    00000050  78 29 0D 0A  4C 61 73 74  2D 4D 6F 64  69 66 69 65  x)..Last-Modifie
    00000060  64 3A 20 53  61 74 2C 20  32 30 20 4E  6F 76 20 32  d: Sat, 20 Nov 2
    00000070  30 30 34 20  32 30 3A 31  36 3A 32 34  20 47 4D 54  004 20:16:24 GMT
    00000080  0D 0A 45 54  61 67 3A 20  22 32 64 30  39 34 35 2D  ..ETag: "2d0945-
    00000090  32 63 2D 33  65 39 35 36  34 63 32 33  62 36 30 30  2c-3e9564c23b600
    000000A0  22 0D 0A 41  63 63 65 70  74 2D 52 61  6E 67 65 73  "..Accept-Ranges
    000000B0  3A 20 62 79  74 65 73 0D  0A 43 6F 6E  74 65 6E 74  : bytes..Content
    000000C0  2D 4C 65 6E  67 74 68 3A  20 34 34 0D  0A 43 6F 6E  -Length: 44..Con
    000000D0  74 65 6E 74  2D 54 79 70  65 3A 20 74  65 78 74 2F  tent-Type: text/
    000000E0  68 74 6D 6C  0D 0A 0D 0A  3C 68 74 6D  6C 3E 3C 62  html....<html><b
    000000F0  6F 64 79 3E  3C 68 31 3E  49 74 20 77  6F 72 6B 73  ody><h1>It works
    00000100  21 3C 2F 68  31 3E 3C 2F  62 6F 64 79  3E 3C 2F 68  !</h1></body></h
    00000110  74 6D 6C 3E                                         tml>           
    

CKDLEE Simply say, it’ll be like this:

On the server:
mkfifopipe_name
nc -l -pport_number<pipe_name  | program_name>pipe_name

On the client:
nc server_machine_name port_number

1. <“while true” should be added in shell>
jiafei427@CKUBU:~/platform_external_netcat-master$ mkfifo nidie
jiafei427@CKUBU:~/platform_external_netcat-master$ netcat -v -l 8888 0<nidie | netcat -v 127.0.0.1 9999 1>nidie
Listening on [0.0.0.0] (family 0, port 8888)
Connection to 127.0.0.1 9999 port [tcp/*] succeeded!
Connection from [127.0.0.1] port 8888 [tcp/*] accepted (family 2, sport 48926)
wocao
nidaye

2.
jiafei427@CKUBU:~/platform_external_netcat-master$ netcat 127.0.0.1 8888
wocao
nidaye

 

Ref.:

http://askubuntu.com/questions/50064/reverse-port-tunnelling

http://www.xinotes.net/notes/note/1529/

http://superuser.com/questions/607783/can-i-pipe-redirect-a-console-application-through-netcat-so-it-can-be-used-remot

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s