|
August 2000
Secure Tunneling between Intranets with VTun
Adam Olson
As an organization grows in size, so does the number
of intranets within the organization. These intranets
often reside behind an external portion of the company's
network that has a connection to the public Internet. At
some point in time, a need will arise for direct, secure
connectivity between two or more separate intranets.
This article covers how to build and configure an
application called VTun in order to establish encrypted
tunnels between remote intranets.
What the Network Looks Like
Imagine a fictitious company named Cool Widgets,
which houses its corporate headquarters in Dallas. It
also has a satellite office in Seattle, where the
production of these widgets takes place. Each office has
one frame relay connection that provides access to the
Internet. Behind each external router lives an external
network using public address space and an internal
network using private address space. A firewall sits
between the external and internal networks. I will use
this network as an example during the configuration of
VTun.
Figure
1 provides an illustration.
The requirement is to connect the two internal
networks, which are using private address space, over
the existing frame relay circuit to the Internet. This
is where VTun can help.
VTun: What and Where
VTun was written by Maxim Krasnyansky and is a fast
and flexible package that allows you to create encrypted
tunnels between hosts. It supports a number of tunnel
types, compression, and traffic shaping. According to
the site, it can run on Linux, Solaris, FreeBSD, and
other BSD clones. I will be using Solaris 2.7 for the
examples in this article.
One host runs vtund as a server and the other host
runs vtund as a client. By default, the server listens
on port 5000. Keep this in mind ,as your network most
likely contains one or more firewalls and VTun traffic
will need to be permitted.
VTun can be downloaded from http://vtun.sourceforge.net/download.html.
. There is a 3.x version presently in the development
stages, but the current stable version is 2.3, which is
used in this article. First, download the source tarball
named vtun-2.3.tar.gz.
You will also want to download the following:
Source for the Universal TUN/TAP driver at http://vtun.sourceforge.net/tun/index.html.
OpenSSL 0.9.5a located at http://www.openssl.org/. You will also
need the zlib compression library if
you do not already have it.
Compiling
You should now have at least the following three
files:
vtun-2.3.tar.gz - VTun source code
tun-1.0.tar.gz
- Universal TUN/TAP driver source code
openssl-0.9.5a.tar.gz - OpenSSL source code
Copy these files into a temporary directory and
expand them:
# cp openssl-0.9.5a.tar.gz tun-1.0.tar.gz vtun-2.3.tar.gz /var/tmp
# cd /var/tmp
# gzip -d *.gz
# tar xvf vtun-2.3.tar
# tar xvf tun-1.0.tar
# tar xvf openssl-0.9.5a.tar
Build OpenSSL: # cd openssl-0.9.5a
# ./config --prefix=/usr/local --openssldir=/usr/local/openssl
# make
# make test
# make install
If you encounter any errors, check out the README
file for specific platform issues.
Build the Universal TUN/TAP driver: # cd tun-1.0
# ./configure
# make install
On Solaris, everything is automatic after running
make install. If you are using a
different platform, the README includes all the commands
you will need to execute.
Build VTun: # ./configure --with-ssl-lib=/usr/local/lib --with-ssl-headers=/usr/local/include/openssl
# make
# make install
Again, if you have any compile time problems
please check out the README. Everything compiled
smoothly for me on a number of Solaris 2.7 machines.
Creating the Configuration Files
The default configuration file is located at
/usr/local/etc/vtund.conf. Make sure to
set the permissions on this file read-write only as
root. Borrowing from the manpage, it consists of
sections in the following format:
name {
keyword value;
keyword value;
.. }
The name of each section can be one of the
following:
options - specifies general options to vtund
default - specifies default options for all hosts
hostname - defines a host connection including
specific options
Below is a sample configuration that can be used with
our network diagram. This will create a tunnel between
fwseattle and fwdallas, where fwseattle is the client
and fwdallas is the server. fwseattle /usr/local/etc/vtund.conf:
options {
ifconfig /usr/sbin/ifconfig;
route /usr/sbin/route;
}
fwseattle-fwdallas {
pass widget;
type tun;
proto udp;
encr yes;
keepalive yes;
up {
ifconfig "%% 192.168.0.1 netmask 255.255.255.255 192.168.0.2 up";
route "add net 10.2.2.0 192.168.0.2 1";
};
down {
ifconfig "%% down";
route "delete net 10.2.2.0 192.168.0.2 1";
};
}
fwdallas /usr/local/etc/vtund.conf:
options {
ifconfig /usr/sbin/ifconfig;
route /usr/sbin/route;
}
fwseattle-fwdallas {
pass widget;
type tun;
proto udp;
encr yes;
keepalive yes;
up {
ifconfig "%% 192.168.0.2 netmask 255.255.255.255 192.168.0.1 up";
route "add net 10.1.1.0 192.168.0.1 1";
};
down {
ifconfig "%% down";
route "delete net 10.1.1.0 192.168.0.1 1";
};
}
Notice how these two configuration files are quite
similar. Let's go over each of the keywords used and the
values associated with them.
The configuration can be separated into two parts.
The first part is where the options are defined, and
these are included within the first set of curly braces.
The second part is the host definition, and everything
is included within the second set of curly braces.
Our set of options is very small. The purpose of
these is to tell vtund where to find the
ifconfig and route
commands in order to bring up the tunnel interface and
install the appropriate routes.
The hostname portion includes a much larger number of
configuration directives. The name outside the curly
braces defines the hostname. The following is a
breakdown of each keyword within the curly braces:
pass widget: Password used for
authentication; must match on client and server.
type tun: Defines the tunnel type as
an IP tunnel; can also be a serial, ethernet, or pipe
tunnel.
proto udp: Protocol to use for
tunnel. vtund will use TCP by default and the vtund.conf
manpage recommends UDP for ethernet or IP tunnels.
encr yes: Enable or disable
encryption.
keepalive yes: Enable or disable
keepalives.
Note that there are two additional sets of curly
braces within the hostname definition defined as "up"
and "down." These are configuration options that vtund
uses to execute commands when the connection is
established or terminated.
Both the up and down sections tell vtund to run
ifconfig and route,
with the correct arguments, to completely establish or
tear down the tunnel between fwseattle and fwdallas.
The vtund.conf manpage includes additional options
that you may want to define. Some options are only used
by the server or client and are ignored if they don't
correlate to vtund's mode of operation.
Additional Configuration
As I mentioned earlier, a clear path must exist
between fwseattle and fwdallas to facilitate vtund
communication. This means that any firewalls or packet
filters must be modified to permit the appropriate
source/destination addresses and port number you are
using with vtund. Again, by default, the server listens
on port 5000.
If this is the first time these networks have been in
a sense directly connected, you will also need to update
/etc/netmasks so the correct route is
entered after the route command has been executed.
Using our example network, an entry of:
10.2.2.0 255.255.255.0
would be added to the bottom of fwseattle's
/etc/netmasks file.
A similar entry of:
10.1.1.0 255.255.255.0
would be added to the bottom of fwdallas's
/etc/netmasks file.
Firing Up the Tunnel!
Everything should now be in place to do a test run of
VTun. To start the vtund server process on fwdallas,
execute /usr/local/sbin/vtund -s. To
start the vtund client process on fwseattle, execute
/usr/local/sbin/vtund -p fwseattle-fwdallas
206.13.45.10.
The arguments to vtund on fwseattle (the client) are
as follows:
-p: Enable persistence which will
make the client reconnect to the server after the
connection has been terminated.
fwseattle-fwdallas: This is the
hostname vtund uses when looking up the connection in
vtund.conf.
206.13.45.10: This is the external
IP address on fwdallas to which vtund will connect.
Does It Work?
To verify that the tunnel is operating correctly, try
pinging the other side of the tunnel. (Make sure to do
the following tests on both sides of the tunnel).
On fwseattle: # ping 192.168.0.2
192.168.0.2 is alive
Examine the interface configuration:
# ifconfig -a
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
inet 127.0.0.1 netmask ff000000
le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 207.104.21.10 netmask ffffff00 broadcast 207.104.21.255
ether 8:0:20:20:18:8f
le1: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
inet 10.1.1.1 netmask ffffff00 broadcast 10.1.1.255
ether 8:0:20:20:18:8f
tun0: flags=8d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 192.168.0.1 --> 192.168.0.2 netmask ffffffff
ether 0:0:0:0:0:0
You should see output similar to that above.
Finally, check the routing table:
# netstat -nr Routing Table:
Destination Gateway Flags Ref Use Interface
--------------- ------------- ----- ----- ------ ---------
192.168.0.2 192.168.0.1 UH 3 1 tun0
10.1.1.0 10.1.1.1 U 2 1042 le1
207.104.21.0 207.104.21.10 U 2 3079 le0
10.2.2.0 192.168.0.2 UG 0 0
default 207.104.21.1 UG 0 4616
127.0.0.1 127.0.0.1 UH 0 33796 lo0
Verify that the route for 10.2.2.0 points to the
other end of the tunnel as it does here. Make sure to
perform these same checks on fwdallas and you'll be set.
End Result
We have now created an encrypted tunnel between two
remote intranets, which can be used to facilitate
connectivity between both private networks. Any host
sitting on one of the private networks, with its default
gateway pointing to its respective fw box, will have
connectivity to the other remote intranet.
Conclusion
VTun provides a quick, reliable, and affordable (it's
free!) way to create secure, encrypted tunnels between
remote intranets and other types of networks. Utilizing
existing Internet connections to tunnel traffic over
allows an organization to keep its circuit charges down.
Depending on the size of the organization, this can add
up to big savings in addition to providing increased
flexibility.
Adam Olson lives in the Bay Area. He has helped build
a successful ISP (http://www.humboldt1.com/), designed and
configured portions of the California Power Network
while working at MCI WorldCom, and is currently working
for a company targeting the e-commerce and time
management industries (http://www.quaartz.com/). Adam enjoys
playing Neil Young on acoustic guitar and snowboarding
in Tahoe. He can be
reached at [email protected].
| 
