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
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 Where: NAME := STRING 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 192.168.2.7 local 192.168.1.1 [root@callisto:~#] ifconfig TUNNEL 10.1.1.1 netmask 255.255.255.252 pointopoint 10.1.1.2 [root@callisto:~#] route add ?net 192.168.7.0/24 gw 192.168.1.254 dev TUNNEL [root@callisto:~#] ifconfig -a TUNNEL Link encap:IPIP Tunnel HWaddr inet addr:10.1.1.1 P-t-P:10.1.1.2 Mask:255.255.255.252 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 192.168.2.7 local 192.168.1.254 ttl inherit #### Test Tunnel Itself: [root@callisto:~#] ping 10.1.1.2 PING 10.1.1.2 (10.1.1.2) from 10.1.1.1 : 56(84) bytes of data. 64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=1.15 ms 64 bytes from 10.1.1.2: icmp_seq=2 ttl=64 time=1.15 ms 64 bytes from 10.1.1.2: icmp_seq=3 ttl=64 time=1.15 ms --- 10.1.1.2 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 192.168.2.7 192.168.1.1 [root@castor:~#] ifconfig gif0 inet 10.1.1.2 10.1.1.1 netmask 255.255.255.252 [root@castor:~#] route add -net 192.168.14.0/24 10.1.1.2 [root@castor:~#] ifconfig -a gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 tunnel inet 192.168.2.7 --> 192.168.1.1 inet6 fe80::210:5aff:fec4:2c04%gif0 prefixlen 64 scopeid 0xf inet 10.1.1.2 --> 10.1.1.1 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 10.1.1.2 --> 10.1.1.1 netmask 0xfffffffc physical address inet 192.168.2.7 --> 192.168.1.1 [root@castor:~#] netstat -rn -f inet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.2.254 UGSc 8 14 xl0 10.1.1.1 10.1.1.2 UH 0 0 gif0 127.0.0.1 127.0.0.1 UH 0 0 lo0 192.168.2 link#1 UC 1 0 xl0 192.168.2.254 52:54:05:e3:e4:2f UHLW 7 0 xl0 933 192.168.7 link#2 UC 1 0 ed0 192.168.7.7 52:54:05:e3:e4:88 UHLW 0 4 lo0 192.168.14 10.1.1.2 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 192.168.2.7 992 - 1433 - - ed0 1500 192.168.7 192.168.7.7 128 - 613 - - lo0 16384 127 127.0.0.1 0 - 0 - - vlan8 1496 192.168.80 192.168.80.1 0 - 0 - - gif0 1280 10.1.1/30 10.1.1.2 0 - 0 - - [root@castor:~#] tcpdump tcpdump: listening on xl0 14:54:48.408903 192.168.1.1 > 192.168.2.7: 10.1.1.1 > 10.1.1.2: icmp: echo request (DF)(ipip) 14:54:48.409071 192.168.2.7 > 192.168.1.1: 10.1.1.2 > 10.1.1.1: 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 192.168.1.254 192.168.14.254 up [root@ganymed:~#] ifconfig gif0 10.2.2.1 10.2.2.2 netmask 255.255.255.252 up [root@ganymed:~#] route add ?host 10.0.0.1 10.2.2.1 [root@ganymed:~#] ifconfig -A gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280 physical address inet 192.168.1.254 --> 192.168.14.254 inet6 fe80::4a54:e8ff:fe8c:a3f%gif0 -> :: prefixlen 64 scopeid 0x13 inet 10.2.2.1 --> 10.2.2.2 netmask 0xfffffffc [root@ganymed:~#] netstat -rn -f inet Routing tables Internet: Destination Gateway Flags Refs Use Mtu Interface default 213.47.70.1 UGS 3 46134 1500 ne5 10.0.0.1 10.2.2.1 UGHS 0 3 1500 gif0 10.2.2.2 10.2.2.1 UH 0 10 1280 gif0 127/8 127.0.0.1 UGRS 0 0 33224 lo0 127.0.0.1 127.0.0.1 UH 2 0 33224 lo0 192.168.1/24 link#1 UC 0 0 1500 ne3 192.168.1.1 52:54:5:e3:51:87 UHL 2 59207 1500 ne3 192.168.1.2 8:0:46:64:74:1b UHL 1 11898 1500 ne3 192.168.1.254 127.0.0.1 UGHS 0 0 33224 lo0 192.168.2/24 link#2 UC 0 0 1500 ne4 192.168.2.7 0:10:5a:c4:2c:4 UHL 1 23012 1500 ne4 192.168.7/24 192.168.2.7 UGS 1 55 1500 ne4 192.168.14/24 192.168.1.1 UGS 0 21 1500 ne3 192.168.44.1 192.168.44.1 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 213.47.70.1 0:5:9a:5a:fb:fc UHL 1 0 1500 ne5 [root@ganymed:~#] traceroute 10.0.0.1 traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets 1 10.2.2.2 (10.2.2.2) 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 10.0.0.1 255.255.255.0 ! interface Tunnel0 ip address 10.2.2.2 255.255.255.252 tunnel source Ethernet1 tunnel destination 192.168.1.254 tunnel mode ipip ! interface Ethernet0 bandwidth 10000 ip address 192.168.7.254 255.255.255.0 no ip proxy-arp ip load-sharing per-packet no ip route-cache no ip mroute-cache media-type 10BaseT random-detect ! interface Ethernet1 bandwidth 10000 ip address 192.168.14.254 255.255.255.0 no ip proxy-arp ip load-sharing per-packet no ip route-cache ip ospf network broadcast no ip mroute-cache media-type 10BaseT random-detect ! ip route 0.0.0.0 0.0.0.0 192.168.14.1 ip route 0.0.0.0 0.0.0.0 192.168.7.7 2 ip route 192.168.44.1 255.255.255.255 Tunnel0 ... scar# show interface tunnel 0 Tunnel0 is up, line protocol is up Hardware is Tunnel Internet address is 10.2.2.2/30 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 192.168.14.254 (Ethernet1), destination 192.168.1.254 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 192.168.14.1 to network 0.0.0.0 C 192.168.14.0/24 is directly connected, Ethernet1 192.168.44.0/32 is subnetted, 1 subnets S 192.168.44.1 is directly connected, Tunnel0 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks C 10.2.2.0/30 is directly connected, Tunnel0 C 10.0.0.0/24 is directly connected, Loopback0 C 10.0.1.0/24 is directly connected, TokenRing0 C 192.168.7.0/24 is directly connected, Ethernet0 S* 0.0.0.0/0 [1/0] via 192.168.14.1 scar# traceroute 192.168.44.1 Type escape sequence to abort. Tracing the route to 192.168.44.1 1 192.168.44.1 4 msec 24 msec 0 msec
