Noiptun Documentation
Copyright (C) 2003 Herman Sheremetyev
---------------------------------------------------------------------

(For installation instructions see the INSTALL file)

Noiptun is a client-server based application that allows full TCP/IP 
communication with computers that have no IP addresses.  The concept 
is fairly simple: packets destined for a virtual address are 
encapsulated in the payload of packets traveling to real addresses 
and sent over the network creating a tunnel.  Noiptun is run on both 
ends of the tunnel and takes care of picking up the packets, 
extracting the payload, and passing it to the kernel making it appear
as if they came directly from the network.  All this is made possible
through the magic of libnet for creating the packets, libpcap for 
picking up the packets, and tun devices for allowing an easy way to 
pass the packets to the kernel.

In order to set up a noiptun tunnel, the connecting side (the server)
must know an IP address that is either "behind" the no-IP box (if 
that box is bridging traffic) or one that is on a shared network 
segment with the target.  Since noiptun was developed specifically to
solve the problem of connecting to "cloaked" IDS/IPS boxes, running 
Hogwash or inline Snort for example, it's usually assumed that the 
target box is bridging traffic so the IP address used to connect is 
somewhere "behind" the target box.
 
The server is invoked with the '-s' option to noiptun and is meant 
to be a gateway to the 'client' computer which has no real IP
address.  When you run noiptun -s, it sets up a tun device with a 
an IP address specified as IP_ADDR in the config file, this is the
address the remote end will communicate with.  The server will also
open a UDP socket on its real network interface through which it
will send and receive the tunnel traffic.  Noiptun will capture any 
traffic going to the tun device on the server, optionally encrypt it
using the wonderful OpenSSL cryto library, and send it through the 
tunnel to the client.  When it receives traffic on the UDP socket,
the server will examine it to match it with the client, optionally
decrypt it, and then write it to the tun device making it appear as
though it came directly from the network.

On the client side, i.e. on the remote machine with no IP, noiptun 
is started with the '-c' option to run in client mode.  The client 
version of noiptun opens a network interface (e.g. eth0) in 
promiscuous mode and registers a tun device just like the server 
version.  The client end also binds an IP address to the tun device
specified in the config file as IP_ADDR, this is the IP address the
traffic coming from the server should be destined for.  Any traffic 
that the client receives from the network that meets some preassigned
criteria (at the moment this is limited to the port on which the
traffic comes in and a CLIENT_ID number identifier) will be
optionally decrypted and passed to the kernel. As a result, any 
applications listening on the IP address assigned to the tun device 
will receive it just as if it came directly from the network.  The 
client then picks up the return traffic coming in on the tun device,
optionally encrypts it, encapsulates it in the payload of a UDP 
packet and sends it back to the server by using the MAC address of
the last packet it received and the DEST_IP variable in the config
file.

If you've been paying careful attention you will have noticed that
there has been no mention of any mechanism to prevent the traffic 
from continuing on to its intended destination, i.e. the IP address 
the server was using to route the traffic to the client machine.  The
answer is that noiptun has no way to handle this issue and it must
be dealt with through other means if deemed important enough.  Some 
of the ways this can be solved is by creating an appopriate Hogwash
or inline Snort rule to drop the traffic, using firewall rules to 
filter the traffic is also possible.  Please note however that
noiptun makes no attempt to deal with this issue whatsoever and
it's up to you to make sure the traffic is dropped and doesn't 
waste unnecessary bandwidth.