 |
Using 'nos-tun' to establish an unencrypted tunnel
added 12.3.2000 -- written by David van Geyn
|
Article Description: This article will show you how to establish an unencrypted tunnel between two sites using 'nos-tun'. Establishing this kind of tunnel is good if you don't need encryption between the two sites, and you just want connectivity.
In my example, two local area networks need to have access to one another and security is not a concern.
The two local networks are 192.168.1.0/24 and 192.168.2.0/24. There is one FreeBSD system at each site, 192.168.1.1 and 192.168.2.1. These systems run natd and translate the packets from the local networks so that hosts on the local network have internet access. Let's say their external (internet routable) IP address are 1.1.1.1 and 2.2.2.2.
In order to set up an unencrypted tunnel using 'nos-tun', you must have at a 'tun' device on each system. FreeBSD installs come with at least one 'tun' device configured.
Once you are sure that you have a 'tun' device, the rest is relatively simple.
On the first system, do the following:
/sbin/nos-tun -t /dev/tun0 -s 192.168.0.1 -d 192.168.0.2 2.2.2.2
/sbin/route add 192.168.2.0/24 192.168.0.2
What this does, is run nos-tun with a source address of 192.168.0.1 and a destination of 192.168.0.2 directed at the routable internet IP address 2.2.2.2. The route command adds a route for the local network of the second system over the newly established tunnel.
On the second system, do the following:
/sbin/nos-tun -t /dev/tun0 -s 192.168.0.2 -d 192.168.0.1 1.1.1.1
/sbin/route add 192.168.1.0/24 192.168.0.1
This sets up nos-tun on the second system with a source address of 192.168.0.2 and a destination address of 192.168.0.1 directed at the routable internet IP address 1.1.1.1.
The addresses 192.168.0.1 and 192.168.0.2 are just other non-routable addresses I have picked for the two end points of the tunnel. The first system must list as its tunnel destination the source address of the second system (i.e., you should only be using two addresses in total to establish the tunnel end points.
Now your computers on the 192.168.1.0/24 network should be able to talk to the computers on the 192.168.2.0/24 network, and likewise the other direction.
A sample trace route from the 192.168.2.0/24 network to a system on the 192.168.1.0/24 network.
Tracing route to 192.168.1.24
1 <10 ms <10 ms <10 ms 192.168.2.1
2 20 ms 20 ms 50 ms 192.168.0.1
3 20 ms 50 ms 21 ms 192.168.1.24
In my application, I use this tunnel so the systems on one network can use a WINS server (Microsoft NetBios) on the other and transfer files between the Windows computers. The tunnel also allows me to do voice and/or video conferencing between computers on the two networks. As none of the data that gets transferred is confidential, security is not a concern, and I would rather have high performance and no security instead of high security and lower performance (because one of the endpoints in my example is only a 486 DX2/66, I'm pretty sure it'd guzzle up the CPU time to encrypt and decrypt the data).
|
|
|
|
