IP-IP Tunnel

Tunneling is a somewhat misleading term; there is nothing to actually "dig" through. Network tunnels consist only of two endpoints (an encapsulator and a decapsulator), gateways, a passenger, and a transport protocol. Granted, these are point-to-point links. In between, ordinary destination prefix-based routing and best-effort delivery over IP infrastructures occurs.

In the case of IP-IP tunneling (RFC 1853, RFC 2003), an IP datagram (passenger) travels encapsulated in another IP datagram (transport). The inner IP header is not changed by the encapsulator, except to decrement the Time To Live (TTL) by 1 if the tunneling is carried out as part of forwarding the datagram. The decapsulator does not alter the TTL value, though. An encapsulator must not encapsulate an inner datagram with TTL=0; and vice versa, if after decapsulation the inner TTL equals 0, the decapsulator must discard the datagram.

There is no tunnel management besides the usual Internet Control Message Protocol (ICMP) mechanisms. Obvious applications are policy routing, multicasting and tunneling of RFC 1918 address space, connecting discontinuous subnetworks, providing multiprotocol transport, and overcoming hop-count limits of certain protocols. However, IP-IP tunnels don't work from behind Network Address Translation (NAT) gateways. RFC 2003 does not specify an authentication mechanism; however, header authentication could be used in between the original inner and transport outer header.

IP-IP tunneling is supported by Linux and all BSD operating systems. They are not necessarily compatible with the Cisco IP-IP tunnel implementation. Cisco has introduced an authentication option. Take a look at the article "Configuring Logical Interfaces" (http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a0080087093.html).

Lab 11-1: IP-IP Tunnel Linux-to-FreeBSD

FreeBSD Tunnel setup for either IP-IP or generic routing encapsulation (GRE) involves three steps. Step one involves establishing the tunnel endpoints; in essence, this means two addresses that can reach and ping each other. These addresses constitute the outer transport header. In a Cisco tunnel setup, the tunnel source could also be a directly connected routable interface and the tunnel endpoint an unnumbered interface.

Step two consists of adding IP addresses to the tunnel itself, usually a /30 RFC 1918 address pair. This is optional, but it is beneficial for debugging and routing purposes. Note that route utilities that cannot route a network toward a tunnel device such as Linux require these addresses for forwarding purposes.

The third step involves adding routing entries for prefixes that are reachable via the tunnel. Whether you use the near or far end as a next hop depends on the pickiness of your underlying operating system (trial and failure). As a rule of thumb, use the near end on UNIX. Figure 11-2 shows the lab topology for this and the following labs in this chapter.

Figure 11-2. Lab Setup for Tunnel Demonstrations

[View full size image]

The Linux ip tunnel command sequence (Example 11-1) offers several other options such as tunnel keys, TTL/TOS manipulation, and other features. I do not recommend using keys or TOS options for tunnel setup with non-Linux/Cisco gateways for compatibility reasons. The Linux IP-IP tunnel supports tunnel checksum, sequence datagrams, and path maximum transmission unit (MTU) discovery compatible with Cisco IOS IP-IP tunnels. Example 11-1 demonstrates inheritance of TTL from the payload datagrams; this is not always desirable. If you encounter problems, add the ttl 255 statement to the ip tunnel setup line to alter this inheritance behavior.

Example 11-1. Linux IP-IP Tunnels (iptunnel Is Equivalent to ip tunnel)

### Establish Tunnel:

[root@callisto:~#] iptunnel -?

Usage: iptunnel { add | change | del | show } [ NAME ]

          [ mode { ipip | gre | sit } ] [ remote ADDR ] [ local ADDR ]

          [ [i|o]seq ] [ [i|o]key KEY ] [ [i|o]csum ]

          [ ttl TTL ] [ tos TOS ] [ nopmtudisc ] [ dev PHYS_DEV ]

       iptunnel -V | --version


       ADDR := { IP_ADDRESS | any }

       TOS  := { NUMBER | inherit }

       TTL  := { 1..255 | inherit }

       KEY  := { DOTTED_QUAD | NUMBER }

[root@callisto:~#] modprobe ipip

[root@callisto:~#] iptunnel add TUNNEL mode ipip remote local

[root@callisto:~#] ifconfig TUNNEL netmask pointopoint

[root@callisto:~#] route add ?net gw dev TUNNEL

[root@callisto:~#] ifconfig -a

TUNNEL    Link encap:IPIP Tunnel  HWaddr

          inet addr:  P-t-P:  Mask:

          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1

          RX packets:48 errors:0 dropped:0 overruns:0 frame:0

          TX packets:102 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:3948 (3.8 Kb)  TX bytes:12996 (12.6 Kb)

tunl0     Link encap:IPIP Tunnel  HWaddr

          NOARP  MTU:1480  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

[root@callisto:~#] iptunnel show

tunl0:  ip/ip  remote any          local any            ttl inherit  nopmtudisc

TUNNEL: ip/ip  remote  local  ttl inherit

#### Test Tunnel Itself:

[root@callisto:~#] ping

PING ( from : 56(84) bytes of data.

64 bytes from icmp_seq=1 ttl=64 time=1.15 ms

64 bytes from icmp_seq=2 ttl=64 time=1.15 ms

64 bytes from icmp_seq=3 ttl=64 time=1.15 ms

--- ping statistics ---

3 packets transmitted, 3 received, 0% loss, time 2019ms

rtt min/avg/max/mdev = 1.154/1.156/1.159/0.039 ms

### Tear Down Tunnel:

[root@callisto:~#] iptunnel del TUNNEL

[root@callisto:~#] modprobe ?r ipip

The FreeBSD implementation facilitates the generic tunnel interface gif(4), a pseudo-device that supports all possible combinations of IPv4 and IPv6 as the transport and payload protocol. By default, gif tunnels might not be nested, and parallel tunnels are not permitted. To change this behavior, consult the gif(4) man page. Example 11-2 demonstrates the IP-IP tunnel setup. Alternatively, you can use ip-tun(8) via the tun pseudo-device on FreeBSD. Consult the manual page for further details. The highlighted text in Examples 11-2 through 11-4 emphasizes the representation of the prefix routed via the tunnel.

Example 11-2. FreeBSD IP-IP Tunnels

[root@castor:~#] ifconfig gif0 tunnel

[root@castor:~#] ifconfig gif0 inet netmask

[root@castor:~#] route add -net

[root@castor:~#] ifconfig -a

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280

        tunnel inet -->

        inet6 fe80::210:5aff:fec4:2c04%gif0 prefixlen 64 scopeid 0xf

        inet --> netmask 0xfffffffc

[root@castor:~#] gifconfig -a

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280

        inet6 fe80::210:5aff:fec4:2c04%gif0  prefixlen 64

        inet --> netmask 0xfffffffc

        physical address inet -->

[root@castor:~#] netstat -rn -f inet

Routing tables


Destination        Gateway            Flags    Refs      Use  Netif Expire

default        UGSc        8       14    xl0            UH          0        0   gif0          UH          0        0    lo0

192.168.2          link#1             UC          1        0    xl0      52:54:05:e3:e4:2f  UHLW        7        0    xl0    933

192.168.7          link#2             UC          1        0    ed0        52:54:05:e3:e4:88  UHLW        0        4    lo0

192.168.14           UGSc        0        7    xl0

192.168.80         link#14            UC          0        0  vlan8

[root@castor:~#] netstat -rn -f inet -i

Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll

xl0   1500  192.168.2          992     -     1433     -     -

ed0   1500  192.168.7          128     -      613     -     -

lo0   16384 127               0     -        0     -     -

vlan8 1496  192.168.80           0     -        0     -     -

gif0  1280  10.1.1/30               0     -        0     -     -

[root@castor:~#] tcpdump

tcpdump: listening on xl0

14:54:48.408903 > > icmp: echo request (DF) 


14:54:48.409071 > > icmp: echo reply  (DF) (ipip)

Lab 11-2: IP-IP Tunnel OpenBSD-to-Cisco

OpenBSD provides the same gif pseudo-device concept as FreeBSD. The entire configuration is done via ifconfig. Example 11-3 demonstrates the OpenBSD setup, and Example 11-4 shows the Cisco tunnel endpoint.

Example 11-3. OpenBSD IP-IP Tunnel Setup

[root@ganymed:~#] ifconfig gif0 tunnel up

[root@ganymed:~#] ifconfig gif0 netmask up

[root@ganymed:~#] route add ?host

[root@ganymed:~#] ifconfig -A

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280

        physical address inet -->

        inet6 fe80::4a54:e8ff:fe8c:a3f%gif0 -> :: prefixlen 64 scopeid 0x13

        inet --> netmask 0xfffffffc

[root@ganymed:~#] netstat -rn -f inet

Routing tables


Destination        Gateway            Flags     Refs     Use    Mtu  Interface

default          UGS         3    46134   1500   ne5            UGHS        0        3   1500   gif0            UH          0       10   1280   gif0

127/8              UGRS        0        0  33224   lo0          UH          2        0  33224   lo0

192.168.1/24       link#1             UC          0        0   1500   ne3        52:54:5:e3:51:87   UHL         2    59207   1500   ne3        8:0:46:64:74:1b    UHL         1    11898   1500   ne3          UGHS        0        0  33224   lo0

192.168.2/24       link#2             UC          0        0   1500   ne4        0:10:5a:c4:2c:4    UHL         1    23012   1500   ne4

192.168.7/24        UGS         1       55   1500   ne4

192.168.14/24        UGS         0       21   1500   ne3       UH          0        0  33224   lo1

192.168.45/24      link#1             UC          0        0   1500   ne3

192.168.80/24      link#16            UC          0        0   1496   vlan0

213.47.70/24       link#3             UC          0        0   1500   ne5        0:5:9a:5a:fb:fc    UHL         1        0   1500   ne5

[root@ganymed:~#] traceroute

traceroute to (, 64 hops max, 40 byte packets

 1 (  3.303 ms *  3.168 ms

Example 11-4. IP-IP Tunnel Setup with Cisco IOS Architecture

scar(config-if)# tunnel ?

  checksum            enable end to end checksumming of packets

  destination         destination of tunnel

  key                 security or selector key

  mode                tunnel encapsulation method

  path-mtu-discovery  Enable Path MTU Discovery on tunnel

  sequence-datagrams  drop datagrams arriving out of order

  source              source of tunnel packets

  udlr                associate tunnel with unidirectional interface

scar(config-if)# tunnel mode ?

  aurp    AURP TunnelTalk AppleTalk encapsulation

  cayman  Cayman TunnelTalk AppleTalk encapsulation

  dvmrp   DVMRP multicast tunnel

  eon     EON compatible CLNS tunnel

  gre     generic route encapsulation protocol

  ipip    IP over IP encapsulation

  iptalk  Apple IPTalk encapsulation

  nos     IP over IP encapsulation (KA9Q/NOS compatible)

scar# show running-config



interface Loopback0

 ip address


interface Tunnel0

 ip address

 tunnel source Ethernet1

 tunnel destination

 tunnel mode ipip


interface Ethernet0

 bandwidth 10000

 ip address

 no ip proxy-arp

 ip load-sharing per-packet

 no ip route-cache

 no ip mroute-cache

 media-type 10BaseT



interface Ethernet1

 bandwidth 10000

 ip address

 no ip proxy-arp

 ip load-sharing per-packet

 no ip route-cache

 ip ospf network broadcast

 no ip mroute-cache

 media-type 10BaseT



ip route

ip route 2

ip route Tunnel0


scar# show interface tunnel 0

Tunnel0 is up, line protocol is up

  Hardware is Tunnel

  Internet address is

  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

     reliability 255/255, txload 28/255, rxload 1/255

  Encapsulation TUNNEL, loopback not set

  Keepalive not set

  Tunnel source (Ethernet1), destination

  Tunnel protocol/transport IP/IP, key disabled, sequencing disabled

  Checksumming of packets disabled,  fast tunneling enabled

  Last input 00:00:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: fifo

  Output queue :0/0 (size/max)

  5 minute input rate 0 bits/sec, 1 packets/sec

  5 minute output rate 1000 bits/sec, 1 packets/sec

     140 packets input, 6615 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     118 packets output, 15128 bytes, 0 underruns

     0 output errors, 0 collisions, 0 interface resets

     0 output buffer failures, 0 output buffers swapped out

scar# show ip route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area

       * - candidate default, U - per-user static route, o - ODR

       P - periodic downloaded static route

Gateway of last resort is to network

C is directly connected, Ethernet1 is subnetted, 1 subnets

S is directly connected, Tunnel0 is variably subnetted, 3 subnets, 2 masks

C is directly connected, Tunnel0

C is directly connected, Loopback0

C is directly connected, TokenRing0

C is directly connected, Ethernet0

S* [1/0] via

scar# traceroute

Type escape sequence to abort.

Tracing the route to

  1 4 msec 24 msec 0 msec