Subject: IPIP Tunnelling
To: None <port-mac68k@netbsd.org>
From: Richard UNGER <runger@cs.mcgill.ca>
List: port-mac68k
Date: 05/09/2000 15:04:41
Hi,

I was bothering everyone with questions about ip-tunnelling a couple of
weeks ago, but I got it all working so I thought I'd share how:

IPIP Tunnelling on NetBSD

*Why? What?

What is it anyways? ipip tunnelling is an ip tunnelling protocol. The idea
is to forward network traffic from one local network to another, but
instead of using the normal IP routing mechanisms, a single TCP/IP
connection between two gateways is used to encapsulate and transport all
the traffic.
Why would you want to use ipip tunnelling? Well, you may have two local
networks, or 'intranets', which you would like to connect, but the local
networks do not have valid internet addresses. In this case the traffic
from the local networks can be encapsulated and sent via an ipip
tunnel through the internet.

*My Example

In my specific case, I have two local networks, in seperate countries,
call them net AUST and net CAN. Both local networks use 'internal' 
internet addresses, ie. the machines on the local net have no real
assigned IP addresses, they use the 192.168.x.x network, which is reserved
for testing or other internal puposes. Network AUST uses 192.168.2.x/24,
network CAN uses 192.168.1.x/24.

Now lets add some hosts to the example:
Both networks are connected to the internet via a NetBSD computer
acting as a gateway. Since the internal addresses are not valid on the
internet, the gateway computers must also act as NAT (network address
translation) boxes. The gateway computers have two ethernet cards each,
one for the internal network, and one connected to the internet.

Call the NetBSD box on network CAN CBSD and the NetBSD box on network AUST
ABSD.
CBSD has interfaces ae0 (ip 192.168.1.1) and sn0 (ip w.x.y.z - assigned by
ISP).
ABSD has interfaces ne0 (ip 192.168.2.1) and ep0 (ip a.b.c.d - assigned by
ISP).
Network AUST has a windows box, for arguments sake, AWIN with IP
192.168.2.2 and network CAN has a Mac, CMAC with IP 192.168.1.2


*The problem

Lets imagine AWIN and CMAC want to talk to each other, lets say CMAC
wants to telnet to AWIN... what does the user on CMAC type?
'telnet 192.168.2.2' will not work, since network 192.168.2 will not
berouted correctly through the internet to the AUST network.
'telnet a.b.c.d' would allow a user on CMAC to telnet to ABSD. To telnet
to AWIN, an explicit port remapping would have to be set up on ABSD, so
that commands of the form 'telnet a.b.c.d -port 555' are sent on to port
21 on AWIN. While this works for telnet, more complicated protocols (many
games, videoconferencing) will not work across NAT gateways at all.
Often, the reason for this is that the protocols include host ip
addresses inside the actual packet data that they send, and NAT does not
examine the packet contents.

*The Solution

I set up an ipip tunnel between CBSD and ABSD. Network packets on network
CAN destined for network AUST are routed through the tunnel, likewise for
packets on network AUST, headed for netowork CAN.

*Setting up the tunnel (interfaces)

To set up the tunnel, you need the ipip interface compiled into your
kernel. To check if you have the ipip interface, try 'ifconfig -a'. One of
the listed interfaces should be ipip0 (you may have more - ipip1, ipip2,
etc...). If you have an ipip interface, you can proceed to the next step
below.

If the output of 'ifconfig -a' does not list an ipip interface,
you kernel is not configured to include ipip. To get the ipip interface
you will have to recompile your kernel. Please consult the excellent
kernel recompiling HOW-TO for instructions on compiling a kernel.

When editing the kernel configuration, add a line:
pseudo-device ipip 2
in the pseudo-devices section of the config file. This will configure
support for two ipip tunnelling interfaces in the kernel.

*Setting up the tunnel (configuring the tunnel)

I assume that both gateways are happily running, connected to the
internet, and are already correctly configured as gateways for their local
networks. ipip interfaces are available on both gateways.

On CBSD, configure the ipip interface as follows:
  ifconfig ipip0 w.x.y.z a.b.c.d netmask 0xffffffff up

On ABSD, configure the ipip interface analogously:
  ifconfig ipip0 a.b.c.d w.x.y.z netmask 0xffffffff up

This will create the tunnel.

*Setting up the tunnel (routing)

Alright, now we have a tunnel configured, but no one is using it yet. We
have to tell the gateways to connect the two local networks via the
tunnels:

On CBSD, we add a route to network 192.168.2:
  route add -net 192.168.2 a.b.c.d

On ABSD, we add a route to network 192.168.1:
  route add -net 192.168.1 w.x.y.z

Now the gateways know to forward packets destined for the other local net
through the tunnel. Effectively, its as though the local networks have
been 'connected' via a single gateway computer.

*HELP!!! My telnet/ssh/rlogin session stopped working!!

One thing to watch for while doing this whole procedure is which machine
you do the actual configuration from. If you have physical access to both
gateways, excellent. If not, and you are configuring at least one of the
gateways by remote access, you have to watch out... Once you bring up the
tunnel, AWIN and CMAC, AWIN and CBSD, CMAC and ABSD, and perhaps even CBSD
and ABSD will have trouble talking to each other until the configuration
is complete. This is because the tunnel may forward packets that are not
correctly routed back, since the routing setup is not complete, or
similar troubles. In general, you can avoid any such issues by logging
into both CBSD and ABSD from a third host on the internet. If you are
sitting at one of the gateways, or one of the local network machines, you
are probably best off accessing the other gateway by first logging into a
third computer outside either local network in order to do the
configuration.

*How do I test?

Once all is configured, you should be able to ping AWIN from CMAC, simply
by executing 'ping 192.168.2.2'. Ping times will be a little longer than
on the local network since packets have to travel through the tunnel.

A telnet from AWIN to CMAC should now work without any port remapping,
just 'telnet 192.168.1.2' on AWIN.

'netstat -i' on the gateways will give you an idea of how many packets are
flowing across your tunnel, as compared to other internet traffic.

*What can I do now?

Programs like MicroSoft Netmeeting and other complicated protocols should
now work between hosts on CAN and hosts on AUST.

*What can't I do now?

ipip tunnels only TCP/IP. If you are using another networking protocol
(IPX/SPX for Netware, for example), ipip tunnels will not help you.

ipip is not Secure Virtual Private Networking. You have implemented a
Virtual Private Network using ipip tunnelling, but there is no excryption.
While travelling though the internet, packets on the tunnel can be
intercepted and read.
Other solutions that implement encryption exist, if you need encryption 
then see IPsec and the KAME project, or investigate tunnelling using ssh.
I deliberately chose to go without encryption since 
a) I think no one is really interested in my network traffic and
b) I use the tunnel primarily for videoconferencing, and the overhead of
encryption would slow things down.


Ok, that's it! Good luck tunnelling, everyone!

Richie