Chapter 9: IPsec and SSL VPN Design (Part03)

Using IPsec VPN Technologies

Several types of IPsec VPNs are used to permit secure, encrypted communication between network devices.

IPsec VPN Overview

IPsec functionality provides data encryption at the IP packet level, offering a robust, standards-based security solution.

Basic IPsec provides secure point-to-point tunnels between two peers, such as two routers. These tunnels are actually sets of security associations (SA) that are established between two IPsec peers. The SAs define which protocols and algorithms should be applied to sensitive packets and specify the keying material to be used by the two peers. SAs are unidirectional and are established per security protocol, either Authentication Header (AH) or Encapsulating Security Payload (ESP).

With IPsec, the network manager can define which traffic should be protected between two IPsec peers by configuring ACLs and applying these ACLs to interfaces by way of crypto maps. The ACLs used for IPsec are used only to determine which traffic should be protected by IPsec, not which traffic should be blocked or permitted through the interface. Separate ACLs define blocking and permitting at the interface.

IPsec can support certain traffic that is receiving one combination of IPsec protection (for example, authentication only) and other traffic that is receiving a different combination of IPsec protection (for example, both authentication and encryption), by using two different crypto ACLs to define the two different types of traffic. These different ACLs are then used in different crypto map entries, which specify different IPsec policies.

Standard IPsec VPNs support only unicast traffic, which is an issue for deploying them within an enterprise.

Extensions to Basic IPsec VPNs

Several site-to-site VPN solutions extend the capabilities of basic IPsec VPNs.

Cisco provides several site-to-site VPN solutions that support routing to deliver reliable transport for complex mission-critical traffic, such as voice and client/server applications. These solutions are built on five underlying VPN technologies:

• Cisco Easy VPN

• GRE tunneling

• Dynamic Multipoint VPN (DMVPN)

• Virtual tunnel interfaces (VTIs)

• Group Encrypted Transport VPN (GET VPN)

Each technology is customized to meet specific deployment requirements.

Cisco Easy VPN

The Cisco Easy VPN solution provides simple VPN deployments for remote offices and teleworkers.

Ease of deployment is critical when technical resources are not available for VPN configuration at remote offices and for teleworkers. The Cisco Easy VPN solution centralizes VPN management across all Cisco VPN devices and reduces the management complexity of VPN deployments. The Cisco Easy VPN Remote feature and the Cisco Easy VPN Server feature offer flexibility, scalability, and ease of use for site-to-site and remote-access VPNs.

The Cisco Easy VPN Remote feature allows Cisco routers running Cisco IOS Software Release 12.2(4)YA (or later releases), Cisco PIX Firewalls, and Cisco hardware clients to act as remote VPN clients. These devices can receive predefined security policies and configuration parameters from the VPN headend at the central site, which minimizes the VPN configuration required at the remote location. Parameters such as internal IP addresses, internal subnet masks, DHCP server addresses, Microsoft WINS server addresses, and split-tunneling flags are all pushed to the remote device.

The Cisco Easy VPN Server feature, available in Cisco IOS Software Release 12.2(8)T or later releases, increases compatibility of Cisco VPN products, and allows Cisco VPN concentrators, Cisco ASA/PIX Firewalls, or Cisco routers to act as VPN headend devices in site-to-site or remote-access VPNs. With this feature, security policies defined at the headend can be pushed to the remote-office devices running the Cisco Easy VPN Remote feature.

Overview of Cisco Easy VPN Server Wizard on Cisco SDM

The Cisco Router and Security Device Manager (SDM) Easy VPN Server Wizard can configure the Cisco Easy VPN Server on Cisco routers.

The Cisco Easy VPN solution is ideal for remote offices with little IT support or for large customer deployments where it is impractical to individually configure multiple remote devices. This feature makes VPN configuration as easy as entering a password, which minimizes local IT support, increases productivity, and lowers costs. Figure 9-8 shows the starting Cisco SDM screen for the Easy VPN Server Wizard that can configure the Cisco Easy VPN Server. The Easy VPN Server Wizard guides network administrators in performing the following tasks to successfully configure a Cisco Easy VPN Server on a router:

• Selecting the interface on which the client connections will terminate

• Configuring Internet Key Exchange (IKE) policies

• Configuring the Group Policy lookup method

• Configuring user authentication

• Configuring group policies on local database, if needed

• Configuring an IPsec transform set

Figure 9-8: Easy VPN Server Wizard on Cisco SDM

Note

Cisco SDM supports VPNs with basic IPsec tunnels, GRE over IPsec tunnels, and DMVPN.

Note

The replacement for Cisco SDM is Cisco Configuration Professional (CCP). For more information about this product, refer to http://www.cisco.com/go/ciscocp.

Overview of Easy VPN Remote Wizard on Cisco SDM

The Cisco SDM Easy VPN Remote Wizard can configure the Cisco Easy VPN Remote devices. Figure 9-9 illustrates the SDM graphical configuration interface.

Figure 9-9: Easy VPN Remote Wizard on Cisco SDM

The Cisco SDM Easy VPN Remote Wizard can configure a remote router that will be connecting to the Cisco Easy VPN Server router. To launch the wizard in Cisco SDM, on the configuration Tasks button list on the left, click VPN. Select Easy VPN Remote in the tree hierarchy on the left. With the Create an Easy VPN Remote option selected, click the Launch the Selected Task button.

Note

The Cisco Adaptive Security Device Manager (ASDM) can be used to configure Cisco Easy VPN Server or Remote operation on the Cisco ASA 5500 series Adaptive Security Appliances, Cisco PIX 500 series security appliances (running Cisco PIX Security Appliance Software Version 7.0 or later), and the Cisco Catalyst 6500 series Firewall Services Module (FWSM) Version 3.1 or later.

GRE over IPsec

Basic IPsec designs cannot transport IGP dynamic routing protocols or IP multicast traffic because the IPsec ESP only tunnels unicast IP traffic. To support the routing or IP multicast requirements of most enterprises, IPsec should be used in conjunction with other technologies, such as GRE.

GRE tunneling, as shown in Figure 9-10, encapsulates non-IP and IP multicast or broadcast packets into IP unicast packets. These GRE packets can be encrypted by the IPsec tunnel. At the remote end of the IPsec tunnel, both the IPsec encapsulation and the GRE encapsulation are removed to recover the original packet. With GRE over IPsec designs, the hub router uses a single GRE interface for each spoke.

Figure 9-10: Tunnels and IPsec

GRE over IPsec Design Recommendations

A routing protocol can dynamically rebalance traffic across redundant headend routers on failover recovery. Although IPsec can typically scale to thousands of tunnels on some platforms, a routed point-to-point GRE over IPsec design is generally limited by the routing protocol being used and the number of routing peers exchanging routing information. In an aggressive design, the headend routing protocol can scale up to 500 peers:

• Up to 500 peers for the Cisco 7200VXR series routers with Network Processing Engine-G1 (NPE-G1)

• Up to 600 peers for the Cisco 7200VXR series with NPE-G2

• Up to 1000 peers for the Cisco 7600 series router (or Cisco Catalyst 6500 series switches) with Supervisor Engine 720

EIGRP is recommended as the routing protocol because of its conservative use of router CPU and network bandwidth and its quick convergence times. EIGRP also provides a range of options for address summarization and default route propagation.

GRE keepalives can be used for failure detection in case of static routing on point-to-point tunnels. Beginning in Cisco IOS Software Release 12.2(8)T, the GRE keepalive feature is available for use on tunnel interfaces. This functionality allows the line protocol of the tunnel interface to track the reachability between the two tunnel endpoints. If GRE keepalives are sent and acknowledged by the remote router, the line protocol is “up.” If successive GRE keepalives are not acknowledged, based on the configured interval and number of retries, the tunnel line protocol is marked “down.”

Figure 9-11 shows a simple hub-and-spoke network with multiple headend devices for redundancy. Point-to-point GRE and crypto tunnels functionally coexist on the same router CPU on the headend devices. The headend supports multiple point-to-point GRE over IPsec tunnels for a prescribed number of branch-office locations. In addition to terminating the VPN tunnels at the central site, the headend can advertise branch routes using IP routing protocols such as EIGRP and Open Shortest Path First (OSPF).

Figure 9-11: GRE over IPsec

To avoid asymmetric routing when routing is running over the tunnels, one of the GRE tunnels between the headend routers and each remote site must be favored. The routing metric should be consistent both upstream and downstream to prevent asymmetric routing.

There are options for configuring different paths in this design with slightly different metrics to provide preference between the tunnels:

• Use the delay command under the GRE tunnel interface.

• Set the bandwidth value for the GRE interface on both ends to match the speed of the actual link. This practice avoids unrealistic bandwidth settings that might affect the flow control of EIGRP.

Hub-and-spoke topologies are the most common topologies in a point-to-point GRE over IPsec design:

• Although partial-mesh topologies are available, they are limited by both the routing protocol and the availability of static public IP addresses for the spokes.

• Full-mesh topologies in a point-to-point GRE over IPsec design are also available and have the same limitations as partial-mesh topologies. With the administrative overhead involved, a full-mesh topology is not recommended in a point-to-point GRE over IPsec design.

DMVPN

Hub-and-spoke designs do not scale well for more than 10 sites. With a traditional hub-and-spoke topology, all spoke-to-spoke traffic is through the hub. As more nodes are added to the topology, the configuration task becomes more complex because a separate GRE interface is needed on the hub for every spoke and all tunnels need to be predefined. In addition, the number of IPsec SAs grows as the number of spokes increases.

In these cases, dynamic peer discovery and on-demand tunnel creation mechanisms are required. When there is more than 20 percent spoke-to-spoke traffic or a full-mesh VPN topology is required, a DMVPN solution should be considered.

DMVPN Overview

DMVPN is a technology that supports IPsec VPNs with simplified configuration through crypto profiles and dynamic discovery of tunnel endpoints.

DMVPN enables dynamic configuration and reduces the maintenance and configuration on the hubs. DMVPN has a backbone hub-and-spoke topology, but allows direct spoke-to-spoke functionality using tunnelling to enable the secure exchange of data between two branch offices without traversing the head office. DMVPN is a combination of IPsec, GRE, and Next Hop Resolution Protocol (NHRP).

DMVPN has several advantages:

• With a dynamic mesh, the number of active tunnels is much lower on each spoke than with a full-mesh design. Smaller routers can be used at the spokes.

• The configuration scales better because there is no need for static definitions for each spoke in the hub.

• It is easier to add a node to the topology because there is no need to configure the new spoke on all the other nodes.

• The spokes can have dynamic address or be behind NAT.

Note

You can use Cisco SDM to configure a router as a DMVPN hub or as a spoke router in a DMVPN network.

Example: DMVPN Topology

Figure 9-12 shows an example of a DMVPN topology. DMVPN does not alter the standards-based IPsec VPN tunnels, but it changes their configuration.

Figure 9-12: Example: DMVPN Topology

The hub router maintains an NHRP database of public interface addresses for each spoke. The hub uses a single multipoint GRE (mGRE) tunnel interface to support multiple IPsec tunnels.

The spokes have a permanent IPsec tunnel to the hub but not to the other spokes. The spokes register as clients of the NHRP server. The spoke learns of all private networks on the other spokes and the hub through routing updates sent by the hub. A spoke queries the NHRP database for the real address of a destination spoke when it needs to communicate to another destination. The spoke uses the real destination address to build a dynamic IPsec tunnel to the target spoke. The spoke-to-spoke tunnel is also built over an mGRE interface. After the spoke-to-spoke tunnel is built, the IP next hop for the remote spoke network is the spoke-to-spoke tunnel interface. After a programmable timeout period, the NHRP entries will age out, triggering IPsec to break down the dynamic spoke-to-spoke tunnel.

In Figure 9-12, spoke A uses the real IP address of 172.16.2.1 to bring up a tunnel to spoke B.

DMVPN Design Recommendations

Cisco recommends several practices for DMVPN with the hub-and-spoke topology:

• Use tunnel protection mode to associate a GRE tunnel with the IPsec profile on the same router. Tunnel protection specifies that IPsec encryption is performed after the GRE headers are added to the tunnel packet. Both ends of the tunnel need to be protected.

• Use IPsec in tunnel mode.

• Configure 3DES or AES for encryption of transported data.

• Use digital certificates or public key infrastructure (PKI) for scalable tunnel authentication. Typically, the CA is located on the private subnet of the hub.

• Configure EIGRP with route summarization for dynamic routing.

• Deploy hardware acceleration of IPsec to minimize router CPU overhead to support traffic with low-latency and -jitter requirements, and for the highest performance for cost.

• Use an NHRP network ID and password key to prevent unauthorized nodes from joining the VPN. Provide each mGRE tunnel interface with a unique tunnel key, NHRP network ID, and IP subnet address. The mGRE tunnel key configured on the spokes must match the hub, and it is a recommended practice that the network ID matches on both sides of the tunnel.

• Use multiple NHRP servers on multiple hubs for backup and redundancy.