Portable UDP port forwarding in user space

Vancea Florin*, Vancea Codruţa**

*
Department of Computers,
University of Oradea, Faculty of Electrical Engineering and Information Technology,
Universităţii st. 1, 410087 Oradea, Romania, E-Mail:fvancea@uoradea.ro
**
Department EMUEE,
University of Oradea, Faculty of Electrical Engineering and Information Technology,
Universităţii st. 1, 410087 Oradea, Romania, E-Mail:cvancea@uoradea.ro

Abstract – Port forwarding is frequently used to
selectively expose services available on remote
machines to clients running on the local machine or
on machines connected to the local network. Services
running over TCP are easy to forward using SSH, at
least as long as the details of the transported protocol
are transparent. Tools are available for other classes of
tunneling, including UDP tunneling. However, these
tools are not very portable and may be limited to
root/admin usage or may simply not be available. We
are presenting a Java client/server pair that may be
successfully used in almost any environment to
forward a UDP dialog over an existing forwarded TCP
connection. The tool is tested for traffic like SNMP
with multiple clients and multiple targets.
Keywords: TCP, UDP, port forwarding,
I. INTRODUCTION
There are many scenarios where traffic should be
carried at the transport level between two hosts on
different networks even if normally no traffic can (or
should) traverse the internetwork from the first host to
telnet access from a client on network A behind a
firewall to a network-enabled simple device placed on
network B, behind another firewall.
The above-described telnet requirement can be
solved rather easily with TCP port-forwarding over SSH
and some network address translation or with an IP
tunnel established between network A and network B.
One possible setup is presented in Figure 1. The client
establishes a SSH session with the remote border router
and configures port forwarding over this session. Due to
port forwarding, SSH will listen to a local port and
forward all connections attempts to the remote target.
We assume that border router B supports SSH with port
forwarding. If not, the diagram should be extended with
a “relay” host on B side, supporting SSH with port
forwarding and the border router B should do reverse
address translation to expose the SSH service for the
inner host.
As long as the transport involved is TCP or an IP
tunnel can be established between the two networks the
setup is fairly common. However, some particular
situations require UDP traffic to flow from network A to
network B and due to other restrictions no IP tunnel can
be established.
Our target example is to allow SNMP traffic between

Network A Border router A Border router B Network B

SSH connection
NAT with forwarding

inter-net

Figure 1. TCP forwarded

Forwarded TCPby SSH
Local TCP
connection connection

the second one. A reasonable example would be remote a client (or several clients) on network A to a target

75
 Network A
192.168.100.0/24 Border router A
inter-net
SNMP dialog over UDP
Figure 2. Target scenario
SNMP host (or several ones) on network B. All SNMP
traffic is initiated on network A (i.e. there is no need for
SNMP-trap). Furthermore, no other type of traffic
should freely flow from network A to network B or in
the reverse direction and one limitation to consider is
that due to administrative constraints an IP tunnel
between the two networks is to be avoided. The target
requirement is presented in Figure 2.
II. POSSIBLE SOLUTIONS
First, let us consider that IP tunneling is still a
possible choice. In this case we can establish an IP
tunnel between network A and network B using the
corresponding border routers. If confidentiality or
integrity of transiting data is a concern, the tunnel can be
protected using VPN techniques. The tunnel solution
will effectively make possible any IP traffic between
network A and network B, so to observe the limited
traffic requirement we will also have to install filtering
rules in the border routers. The solution is depicted in
Figure 3.
The tunnel solution has some disadvantages. First of
all, it requires additional configuration of the border
routers. This can be only an additional administration
complication or it can be a major difficulty if the border
routers are not under our control.
The tunnel also offers wider transport abilities than
the minimum we need. We have to take steps to limit the
traffic only to the SNMP over UDP we are strictly
interested in. All the additional filter rules may be
complicated to set up right and maintain over time.
Network A Network B
Filtering rules
IP tunnel
inter-net
Figure 3. IP tunnel and filtering
76
Network B
Border router B 10.0.10.0/24
However, the tunnel and filter solution is acceptable
if we have full control over both border routers and the
required connection is a long-term one (i.e. the effort
required to set it up is justified).
Another possible solution is to use ready-made tools
available in the Unix world (and not only there). There
is an simple but powerful utility called netcat. Half of its
main function is to accept a TCP stream or a stream of
UDP datagrams and cleanly pipe the payload data into
its standard output. The other half is the reverse process:
payload data coming from standard input is piped into a
TCP connection or pushed as UDP datagrams. We can
build a pipe of netcat instances using shell scripting
capabilities and use the SSH TCP port forwarding
capabilities to cross the inter-net. The principle is
presented in Figure 4.
The first netcat instance listens on a UDP socket for
datagrams from the actual client. All data is piped
through netcat standard output to the next netcat
instance standard input. The second netcat instance
pipes the payload data into a TCP connection
established with the local port where SSH is listening.
Since SSH forwards the port to the remote SSH server,
the TCP connection ends on network B where the third
netcat instance is listening. The third netcat instance
pipes further the data into its standard output. Finally,
the last netcat instance takes the data stream and pushes
it into UDP datagrams towards the actual UDP server
listening for data. Of course, the whole chain has to be
replicated for the reverse direction.
The complex pipe can also be built without netcat, or
UDP listening port
TCP forwarded port
OS pipe
Network A
netcat netcat SSH
client
SSH netcat netcat UDP
server server
TCP Network B
OS pipe
listening port
Figure 4. netcat chain
only partially with netcat, by using another feature
available in some operation systems. Certain Linux
distributions have special virtual /dev/udp and /dev/tcp
devices that allow plain shell scripts to access UDP and
TCP functionality. Of course, setting up such “pipe
dreams” can become quite complicated, especially for
multiple targets or multiple local clients, because each
chain supports only one dialog.
The main advantage of such complex pipes is that
they can be built whenever needed, with much less
overhead than the IP tunnel solution. Furthermore, they
may not require enhanced privileges on the endpoint
hosts. If you can SSH to a remote host and do port
forwarding, you may be also able to build a UDP pipe.
However, the netcat pipe suffers from a fundamental
problem. The pipe does not preserve the datagram
alignment. If the protocol that uses UDP as transport
relies on UDP to preserve message boundary then it may
not work over the pipe. The reason is that netcat does
not introduce any kind of message delimiter and TCP
does not guarantee anything beyond the sequentiality of
the data stream. For the chain to work, a sum of special
conditions should be attained:
- messages must be reasonably small
- messages must come widely spaced in time
- the quality of the IP chain below TCP
connection should be quite reliable
If the conditions are not perfectly met, two or more
original messages may aggregate in the same TCP
segment and surface at the other end of the pipe as a
single (probably ill-formed) message. If a single large
message is segmented by TCP during transit, it will
produce two or more smaller messages, again without
meaning for the protocol above UDP.
III. JAVA-BASED SOLUTION
Network A
SSH connection
with port forwarding
NAT
Forwarded TCP
connection
Agent accepts
UDP traffic
Local
agent
Figure 5. UDP tunnel layout
77
The proper way to relay UDP datagrams over a TCP
connection is to handle explicitly the message
boundaries at source, transmit them in-band over the
TCP connection and rebuild the UDP datagrams at the
other end in strict conformity with the original
messages. This is a rather complex task that requires a
specialized pair of programs to handle properly all the
details. As long as the participating networks are known
in advance and stable, almost any language able to
handle TCP and UDP will do. However, when the
connection has to be established ad-hoc with a variety of
target networks it may be difficult to work with binaries
or to recompile source. The remote machine may run an
unusual or unfamiliar OS, for which there are no
prebuilt relay binaries or which has no preinstalled
compiler.
Luckily, more and more systems have nowadays a
JVM installed because many applications are at least
partly written in Java or allow Java-based extensions.
Therefore Java is the language of choice for the tool we
want to build.
To achieve the goal set in the introductory part we
will need a local converting half and a remote
converting half. The two halves are connected through
TCP and this connection can be comfortably forwarded
over SSH. The local half listens for UDP, wraps the
messages with boundary delimiters and other
information, then pushes the resulting data units over the
TCP connection. On other side, the remote half unwraps
the data units and acts as a proxy, relaying the messages
unchanged to the actual target. In fact, the pair acts like
a tunnel for UDP over TCP with a proxy at the remote
end. The solution is shown in Figure 5.
The pair creates effectively a new layer in ISO-OSI
acception and each half is the implementation for this
Network B
Agent forwards
UDP traffic
NAT
inter-net
Remote
agent
layer. Local UDP ports are SAP’s of this layer, paired
with remote targets. UDP datagrams are SDU’s
presented to the new layer. Those SDU are wrapped in
custom protocol PDU and multiplexed over the TCP
connection offered by SSH. The layer communicates in
connected mode. Each local SAP – remote target forms
a virtual connection that has to be established in
advance.
In order to allow for coherent reverse traffic, the
remote half has to offer SAP’s, too. Those SAP’s are
actually the UDP ports on the remote host, used to
originate the UDP datagrams to the targets. The remote
SAP’s are in turn paired with local client originating
addresses, creating a parallel set of virtual connections
for the reverse traffic.
With this setup, an arbitrary number of local clients
can send UDP datagrams to a UDP socket where the
local agent listens. Each client will receive UDP replies
properly coming from the same socket, exactly as if the
remote target is listening on local relay host. On the
remote side, the agent can initiate UDP client-server
sessions with multiple targets, using a different
originating UDP socket for each local client represented.
Its operation is very close to a proxy. Each remote target
sees one or several distinct sessions, all originating from
the same host (the relay).
The setup required for this tunnel is minimal. On the
remote half the only configuration required is the TCP
port where the SSH forwarding should terminate. On the
local side, each forward connection should be
configured, in a manner similar to SSH port forwarding.
Each tunnel requires a triple
local_port:target_IP:target_port which is specified in
the command line that starts the local half. The two
halves perform upon start a setup phase that associates
identifiers to the channels to reduce traffic PDU size.
After that, each PDU will contain only the forward
tunnel identifier, which is a small integer.
To implement the reverse pairing, the local half
maintains a client table updated on the fly and marks
PDU’s from different clients with a different reverse
tunnel identifier. Thus, each PDU contains minimal
overhead: two tunnel identifiers and a message length.
We have successfully implemented a pair of agents
and tested it against real SNMP traffic. Common SNMP
traffic is not dependent on the IP of the originator and
the proxying principle is not impacting the operation of
the SNMP requests. The multiple client / multiple target
ability is quite comfortable. The only drawback is that
the whole setup has a slightly higher latency, otherwise
all traffic operates as if the targets are present on the
local network.
IV. SECURITY NOTES
As in many other cases, the tool we have developed
is a double-edged sword. On one hand, a legitimate user
operating on network A may quickly access SNMP
targets on remote networks where no direct IP is
possible or desirable. An example of such use case
78
would be a consulting representative which needs to
temporarily monitor or configure network devices
placed at the customer site using SNMP. No intervention
to the network infrastructure is required, which
minimizes the chances for misconfiguration leading to
security hazards. The tunnel can be set up whenever is
needed and can also be shutdown quickly. The
requirements are:
- a remote host on network B accessible by SSH
with port forwarding
- a JVM on the remote host
No other special privileges are required on any of the
relay hosts involved. To establish the tunnel, the jar
containing the remote half has to be copied to the remote
side, then it has to be started with appropriate
configuration. All further operation and configuration
can be done from the local end of the tunnel. Once the
tunnel is started it can be transparently used without
intervention to the tunnel itself.
A careful reader would already have noticed that all
these advantages for legitimate use are also great news
for unauthorized use. Any host accepting UDP packets
on the remote network is instantly accessible to a
malicious user on the local side. Furthermore, the
process can be arranged to pass almost un-noticed.
On the other hand, the main issue here is not the tool
itself, but the SSH ability to forward ports. Even if a
user is granted access to a host on a limited account and
the host appears to be the only one accessible by reverse
NAT, the port forwarding feature spoils this fragile
security. The security-conscious administrator that must
allow SSH to unprivileged accounts on a particular host
should disable the port forwarding feature.
IV. CONCLUSIONS
We have described a method to build an additional
layer over TCP that can tunnel and proxy UDP traffic.
The particular implementation we have developed
turned to be portable, easy to use and almost transparent.
The tool can be useful, but in the wrong hands it may be
a security hazard, not by itself but by exploiting weak
configuration setups.
REFERENCES
[1] T. Ylonen, C. Lonvick, ″The Secure Shell (SSH) Protocol
Architecture ″, RFC4251.
[2] T. Ylonen, C. Lonvick, “The Secure Shell (SSH)
Authentication Protocol″, RFC4252.
[3] T. Ylonen, C. Lonvick, “The Secure Shell (SSH)
Transport Layer Protocol″, RFC4253.
[4] T. Ylonen, C. Lonvick, “The Secure Shell (SSH)
Connection Protocol″, RFC4254.
[5] A. S. Tannenbaum, ″Computer networks, Fourth Edition″,
Pearson 2002, ISBN-13: 9780130661029.
[6] Sun Microsystems, “Java Custom Networking”, available
online at http://java.sun.com/docs/books/tutorial/
networking/index.html.