Tunnelling UDP Traffic Through An SSH Connection: Difference between revisions
Line 25: | Line 25: | ||
== Use: "'''nc'''" To Translate TCP To UDP On The SSH Server Side == | == Use: "'''nc'''" To Translate TCP To UDP On The SSH Server Side == | ||
On the remote '''NST''' probe ('''SSH''' server side), we need to open a port listener for '''TCP''' port: "'''9999'''" | On the remote '''NST''' probe ('''SSH''' server side), we need to open a port listener for '''TCP''' port: "'''9999'''" and translate all network traffic to '''UDP''' port: "'''623'''" for the '''IP Address''' assigned to the '''X4200''' server's '''ILOM''' network interface. | ||
We will first need to create a "'''[http://en.wikipedia.org/wiki/FIFO fifo]'''". The "'''[http://en.wikipedia.org/wiki/FIFO fifo]'''" will be necessary to maintain a two-way communication channel between the '''TCP''' port listener and the '''UDP''' port. A simple shell pipe would '''NOT''' work. It would only communicate left process' standard output to right process' standard input. We will use the '''Linux''' command [http://en.wikipedia.org/wiki/List_of_Unix_programs mkfifo] to establish the "'''[http://en.wikipedia.org/wiki/FIFO fifo]'''". | We will first need to create a "'''[http://en.wikipedia.org/wiki/FIFO fifo]'''". The "'''[http://en.wikipedia.org/wiki/FIFO fifo]'''" will be necessary to maintain a two-way communication channel between the '''TCP''' port listener and the '''UDP''' port. A simple shell pipe would '''NOT''' work. It would only communicate left process' standard output to right process' standard input. We will use the '''Linux''' command [http://en.wikipedia.org/wiki/List_of_Unix_programs mkfifo] to establish the "'''[http://en.wikipedia.org/wiki/FIFO fifo]'''". |
Revision as of 19:19, 22 March 2007
Overview
This section describes how to use NST to tunnel a UDP traffic conversation through a SSH connection. For our example we will tunnel IPMItool traffic (UDP Port: "623") through an SSH connection to a Sun Fire X4200 server's Integrated Lights Out Manager (ILOM) service processor network interface. Three systems are involved, 2 NST probes and the X4200 server. Reference information was taken from: "Performing UDP tunneling through an SSH connection".
Step By Step:
Tunnel A TCP Forward Port Through SSH
First we need to establish the tunnel for a "non-used" TCP port from the local NST probe to the remote NST probe SSH server which shares the same LAN as the destination X4200 server.
root@55.44.22.178's password: Last login: Thu Mar 22 11:18:59 2007 from cpe-72-222-76-188.nycaper.res.rdr.com =============================================== = Linux Network Security Toolkit (NST v1.5.0) = ===============================================
In this example SSH traffic is being NATed through a firewall. The SSH filtered port at the dirty side of the firewall is: "31222". We have chosen to use TCP port forwarding for the "non-used" TCP port: "9999". The remote NST probe's IP Address is: "55.44.22.178". On the local NST probe, TCP port: "9999" is bound to the localhost IP Address: "127.0.0.1".
Use: "nc" To Translate TCP To UDP On The SSH Server Side
On the remote NST probe (SSH server side), we need to open a port listener for TCP port: "9999" and translate all network traffic to UDP port: "623" for the IP Address assigned to the X4200 server's ILOM network interface.
We will first need to create a "fifo". The "fifo" will be necessary to maintain a two-way communication channel between the TCP port listener and the UDP port. A simple shell pipe would NOT work. It would only communicate left process' standard output to right process' standard input. We will use the Linux command mkfifo to establish the "fifo".
prw-r--r-- 1 root root 0 Mar 22 19:37 /tmp/fifo
Next we will use "nc" (netcat) the "TCP/IP Swiss Army Knife" to perform the TCP/IP to UDP translation.
This command sequence will allow all TCP traffic on the remote NST probe for port: "9999" to be forwarded using the UDP network protocol to the X4200 server's ILOM network interface: 172.19.1.28 UDP port: "623" and receive network traffic responses back.