General Tunnel and Specific IPSec Caveats

Tunnels introduce several issues unknown to regular networking connections. The following brief discussion sheds some light on these issues.

Tunnels and Firewalls

Depending on the layer on which certain tunnel solutions reside, it is necessary to configure firewalls and packet filters to pass certain IP protocol numbers or UDP/TCP ports (see Table 11-3). The lower in the stack the tunnel sits, the more transparent it usually is. The higher it sits, the more application-specific it is (for example, SSH).

Tunnels Do Not Like NAT

Most traditional tunnel approaches such as GRE and IPSec do not like NAT. This is a dislike they share with some protocols that cannot cope with NAT without help such as proxies (for example, MS NetMeeting facilitating H.323). Doing NAT and tunnel termination on an integrated gateway usually works. With IPSec, tunnel mode via ESP is the best approach to avoid NAT hassle. As already mentioned, the NAT-Traversal IETF draft deals exactly with this challenge.

Tunnels Cause MTU Issues

Tunnels add protocol overhead and reduce the effective MTU a frame can have. It is pretty much the same with VLAN tagging (giants or jumbo frames) and MPLS Layer 2 overhead that needs to be accounted for on switches. A workaround for legacy switches that are incapable of dealing with jumbo frames is VLAN trunking. If you encounter strange problems with large packets such as FTP and smaller ones such as ICMP work, it is most likely an MTU problem.

Some operating systems adjust the MTU of tunnel or pseudo-interfaces by default; others leave it to the educated system administrator. With some protocols, such as GRE or 802.1q, it is easy to derive the increment value from the protocol design; with others, such as ESP/AH, it is guesswork because of padding and variable-length headers.

There exist several misperceptions of MTU and TCP maximum segment size. Just because the standards define an MTU of 1500 for Ethernet, it does not mean that it does not work beyond that limit. Tunnels also add a new chapter to the entire issue of fragmentation. MTU symptoms are often not diagnosed correctly. Classic symptoms include web pages not displaying properly (without images) even though the host is pingable, or directory listings not displaying even though the primary connection is established.

Tunnels Add Protocol Overhead

The efficiency and attractiveness of a tunnel solution also is determined by its protocol overhead. This is the reason why user-space UDP tunneling is efficient and it is not a good idea to encapsulate tunnels within tunnels without a good reason (for instance, GRE, IPSec, and SSH in combination). Therefore, you should account for the protocol overhead when designing gateways and links.

Unnumbered Links and Tunnel Routing

Some dynamic routing protocols are somewhat sensible with regard to point-to-point links (such as tunnels), unnumbered interfaces, and NBMA issues. Keep this in mind if you encounter problems with Open Shortest Path First (OSPF) and switch to the latest Quagga sources where a lot of point-to-point fixes have been added.

Multicast Transit via Point-to-Point Tunnels

GRE is capable of transporting multicast traffic. This is useful when a multicast-incapable network cloud separates the multicast sender and receiver. It usually is configured featuring Protocol Independent Multicast (PIM). One alternative is DVMRP, which facilitates underlying IP-IP tunnels. For more detailed configuration instructions, see Chapter 14.

Crypto Performance

CPU processing of hashes (SHA, MD5) and cryptographic transforms (AES, 3DES) is considerable and starts affecting design choices starting with a few megabits-per-second tunnel performance. Whenever possible, choose AES, which considerably reduces the strain compared to 3DES. DES and 3DES originally were designed to run in hardware and poorly perform in software, whereas the AES Rijndael algorithm was chosen for its performance characteristics. In addition, for tunnel throughput beyond 10 Mbps, a hardware crypto accelerator is certainly a good idea. It relieves the CPU from the computation of transforms and even hashes. These crypto devices/cards are well supported on BSD and Linux operating systems and often are referred to as Fast IPSec.

High Availability

With the introduction of tunnels, the design and operation of high-availability gateway architectures is becoming far more challenging.

This involves clustering, virtual instances, dynamic routing protocols, heartbeat approaches, VRRP, and other measures. The biggest challenge for firewalls is to resume gigabit forwarding and crypto operation without breaking stateful inspection, existing tunnels, and NAT. Here it really becomes an art to operate two parallel firewalls that constantly mirror NAT tables and stateful inspection pseudo-caches. Takeover of authenticated tunnels bound to a particular IP address without breaking the SA or client TCP sessions is difficult, too. In this scenario, commercial approaches are ahead of the open-source community, but even they struggle to deliver on their promises.

VPN Deployment and Scalability

When you are deploying large VPN installations or a huge road-warrior (roaming user) base, consider a sound design that includes PKI, VPN concentrators, and a unified approach toward VPN clients with a clear set of policies. Also keep in mind that DHCP over IPSec is "not yet there."

Point-to-point tunnels do not scale; however, hub-and-spoke topologies remedy the problem to at least some extent. A sound IP addressing concept and routing architecture is of crucial importance, too. Keep in mind that tunnels per se do not provide security to the involved clients, hosts, or gateways, and because of their transparent nature, tunnels do nothing for malicious code defense. Therefore, it is recommended to secure tunnel termination devices with packet filters, stateful-inspection firewalls, or personal firewalls.