Summary

In this chapter, we've reviewed several architectural options, discussing the technical details of each and exploring their appropriateness in an IPsec VPN design. Some of the topics covered are more popular in today's networked environment than others. Yet other architectural options such as IPsec with GRE-Offload have become so popular that many IPsec VPN designers consider them to be fundamentally mainstream. Regardless, each design in this chapter has a baseline fundamental IPsec design alternative. The majority of the designs discussed in this chapter, though useful in their given place and in very specific user cases where a more mainstream design cannot be implemented, should therefore be evaluated against the fundamental designs discussed in previous chapters to determine how adequately and effectively they meet your organization's design objectives.

This chapter covers IPsec with "router-on-a-stick" design. Designs "on-a-stick" refer to features and functionality running on a device with only one interface to the network infrastructure. Examples of technologies that can exist on-a-Stick include router-on-a-stick, NAT-on-a-stick, and IPsec-on-a-stick. Many of these technologies can exist together on-a-stick, as we had discussed in our case study earlier in this text. IPsec-on-a-stick can add value in situations in which only one interface is available to the network. However, because many on-a-stick functionality requires the use of a loopback interface on lower-end routing platforms, the switching performance of an ona-stick design can be somewhat compromised compared to that of a traditional in-path design. This coupled with the fact that most on-a-stick deployments can be revamped in to a traditional in-path design rather easily and at relatively low cost make on-a-stick deployments rare.

The chapter also covers out-of-path IPsec VPN tunnels, design topologies in which encrypted data-plane traffic is directed outside of the unencrypted data-plane traffic flow due to crypto processing requirements. Out-of-path design alternatives for IPsec are perfectly valid. One such option is the termination of RAVPN clients on a concentrator cluster in the Internet-edge DMZ. As we have discussed previously in this chapter, this design calls for encrypted traffic to be passed from the outside firewall interface to the outside DMZ interface where it is decrypted at the concentrator cluster outside interface. The cleartext traffic is then forwarded from the concentrator cluster inside interface to the inner DMZ interface on the firewall where it is then allowed to pass to the firewall's inside interface and eventually in to the inside network itself. This detour for encrypted traffic through the concentrator cluster on the DMZ is an out-of-path detour from what would have occurred during an unencrypted traffic flow, flowing directly from inside to outside interfaces and vice versa. Any potential decrease in performance due to out-of-path processing is vastly outweighed by the security benefits resulting from the firewalled location of the concentrator cluster, making this further architectural IPsec VPN design option the optimal choice for many network environments.

Finally, this chapter covers IPsec+GRE with GRE-Offload. IPsec+GRE is a requirement in many networks where confidentiality of IP multicast traffic is required. Such IP multicast traffic could include not only data-plane multicast flows such as IP/TV streams, multicast VoIP flows, and real-time multicast data feeds, but also multicast control-plane traffic such as multicast routing protocol updates (RIP, OSPF, EIGRP, ISIS, PIM, and so on). This design option has become increasingly popular. And, as the switching capacity for GRE tunnels increases in IPsec VPN platforms, this design will continue to merge with the set of baseline fundamental IPsec VPN designs.