After banging our heads against this particular brick wall for a while, I
thought that this information may be useful to others on this list.
-----FW: <[EMAIL PROTECTED]>-----
Date: Fri, 05 Mar 1999 09:33:59 +0000
From: "Michael J. Tubby B.Sc. G8TIC" <[EMAIL PROTECTED]>
Subject: Linux IP tunnels - how they work in practice
John/Dirk,
Since I discussed IPIP tunnels with you (both) and we had different views as
to
how they worked/didn't work, well here's the answer:
With kernel 2.0.36 you can use modular or compiled in tunneling - if you use
modules then two are required - the new encapsulator ("new_tunnel.o") and the
old/current decapsulator ("ipip.o"). The encapsulator is considered as a
network
driver (in the /drivers/net/ tree) and the decapsulator is part of the core
networking
located elsewhere.
For tunneling you have to have Network firewalls and IP firewalling in the
kernel
and IPV4 forwarding enabled otherwise outbound tunneled packets are
encapsulated
then discarded (not very useful).
The new_tunnel module is clever - more cunning than it first appears - since
it
really is a network device and can be the end-point to many tunnels which
share
the same tunneled address.
You load the modules, assign the tunl0 device an IP address from the internal
net (ie. your private net or VPN) which you wish to tunnel (not a public
address
of the tunnel) and then put in a host route to that address in order that
packets
can "land" on that address.
Next, you add a network route to the far end for the VPN addresses which you
wish to route and the IP address of the far-end public address is used as the
gateway address - you also specify the net device tunl0.
So, packets are processed by thekernel routing table, handed off to the tunl0
device which makes a retrospective look back at the kernel routing table to
pick up the IP address of the gateway which is used as the destination address
of the outer (encap) frame. The source address in the outer encap frame is
determined dynamically by the kernel using the address of the most appropriate
interface - if you are multihomed.
Example:
#
# install IPIP tunnel to lancaster university for net 44.131.96
#
/sbin/insmod new_tunnel
/sbin/insmod ipip
/sbin/ifconfig tunl0 44.131.93.96 up
/sbin/route add -host 44.131.93.96 tunl0
/sbin/route add -net 44.131.96.0 netmask 255.255.255.0 gw
lurpac.lancs.ac.uk tunl0
this routes 44.131.96 (uk ampr - lancashire class C) to the tunnel end-point
on
lurpac.lancs.ac.uk (a publically accessible machine).
I could mave many more routes, to other places sharing the same tunnel, for
example:
/sbin/route add -net 44.131.16.0 netmask 255.255.255.0 gw
g8sau.sheringham.org.uk tunl0
would send the Norfolk packets to Barry G8SAU - using the same tunl0 device.
The only time we need to start a new tunl device, eg. tunl1, is when we want a
different IP address as the near end-point on our tunneled/VPN side.
If your tunnel machine is on a network which is protected by sensible
filtering
rules on a Cisco rtouter - as mine is - then you also need to open access for
IPIP packets as otherwise they are blocked by the router, use something like:
access-list 101 permit ipinip host [ip address] host [ip address]
with the outer (public) IP addresses of both machines - you'll need a seperate
access list for in-bound and out-bound packets.
After adding the tunnel and routes the kernel routing table looks like this:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
44.131.93.96 0.0.0.0 255.255.255.255 UH 0 0 0 tunl0
194.75.130.0 0.0.0.0 255.255.255.0 U 0 0 36 eth0
44.131.96.0 148.88.12.208 255.255.255.0 UG 0 0 6 tunl0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 2 lo
0.0.0.0 194.75.130.254 0.0.0.0 UG 0 0 52 eth0
and the network interfaces look like this:
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:10797 errors:0 dropped:0 overruns:0
TX packets:10797 errors:0 dropped:0 overruns:0
eth0 Link encap:Ethernet HWaddr 00:60:97:65:F8:F9
inet addr:194.75.130.60 Bcast:194.75.130.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:16652 errors:0 dropped:0 overruns:0
TX packets:12148 errors:0 dropped:0 overruns:0
Interrupt:10 Base address:0x300
eth0:0 Link encap:Ethernet HWaddr 00:60:97:65:F8:F9
inet addr:194.75.130.61 Bcast:194.75.130.255 Mask:255.255.255.0
UP RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
tunl0 Link encap:IPIP Tunnel HWaddr
inet addr:44.131.93.96 Bcast:44.255.255.255 Mask:255.0.0.0
UP RUNNING NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:1220 errors:0 dropped:0 overruns:0
bpq0 Link encap:AMPR AX.25 HWaddr GB7BAA-1
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
UP RUNNING MTU:256 Metric:1
RX packets:71 errors:0 dropped:0 overruns:0
TX packets:15 errors:0 dropped:0 overruns:0
nr0 Link encap:AMPR NET/ROM HWaddr GB7BAA
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
UP RUNNING MTU:235 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
--------------End of forwarded message-------------------------
---
Dirk-Jan Koopman, Tobit Computer Co Ltd
At the source of every error which is blamed on the computer you will find
at least two human errors, including the error of blaming it on the computer.
