Virtual Tunnel Interface (VTI) Design Guide

Corporate Headquarters:

Virtual Tunnel Interface (VTI) Design Guide

This design guide is written for systems engineers and support engineers to provide guidelines and best practices for deploying virtual tunnel interfaces (VTIs).

This design guide defines the comprehensive functional components required to build an enterprise virtual private network (VPN) solution that can transport IP telephony and video. It identifies the individual hardware requirements and their interconnections, software features, management needs, and partner dependencies. This helps a customer deploy a manageable and maintainable enterprise VPN solution. It is assumed that the reader has a basic understanding of IP Security (IPsec).

This design guide is part of an ongoing series that addresses VPN solutions, using the latest VPN technologies from Cisco, and based on practical, tested designs.

Contents

Introduction

Design Overview

Starting Assumptions

Design Components

Comparing DVTI with other VPN Topologies

Understanding Scalability Results

Best Practices and Known Limitations

Best Practices Summary

General Best Practices

Headend Best Practices

Branch Office Best Practices

Known Limitations Summary

General Limitations

Headend Limitations

Branch Office Limitations

Design and Implementation

Overview

Design Considerations

Virtual Tunnel Interface

Virtual Template Interface Service

Per-Tunnel Features

Encapsulation

QoS Service Policy

Easy VPN with Dynamic Virtual Tunnel Interface Support

Configuration and Implementation

Topology

VTI Configuration Overview

QoS Configuration

ISAKMP DSCP Value

Trustpoints

ISAKMP Policy

IPsec Profile

Headend Router Configuration

Branch Router Configuration

Dynamic VTI for EZVPN Remote and Server—Dual Tunnel Support

IP Multicast

Topology

EIGRP Headend Router Configuration

EIGRP Branch Router Configuration

OSPF and PIM Headend Router Configuration

OSPF and PIM Branch Router Configuration

Caveats

Address Conservation

Overview of IP Unnumbered

Loopback versus Inside Ethernet/FastEthernet

Examples

High Availability

Interaction with other Networking Functions

Network Address Translation and Port Address Translation

Dynamic Host Configuration Protocol

Firewall Considerations

Common Configuration Mistakes

Transform Set Matching

ISAKMP Policy Matching

Scalability Considerations

QoS Configuration for Performance Testing

Policy Map for Branch and Headend

Branch Configuration

Headend using Virtual Template Interface

Target-Shaped Rate

Scaling Recommendations

Scalability Test Results (Unicast Only)

Scalability Test Methodology

Scalability Test Bed Network Diagram

Voice Performance for the Control Branch

Headend CPU Utilization (by Number of Branches)

Tests Varying the Shaped Rate

Scalability Conclusion

Software Releases Evaluated and Caveats

Scalability Test Bed Configuration Files

Cisco 7200VXR Headend Configuration

Branch Office Configuration

Alternate Method for Scaling Traffic Shaping Using an ATM PA-A3 Interface

Goal

Performance Testing Overview

QoS Configuration for Performance Testing

ATM Shaping Pre-Crypto

Testbed Network Topology

Test Results

Comments and Observations

Scalability Test Bed Configuration Files

Crypto Cisco 7200VXR Headend Configuration

ATM Cisco 7200VXR Headend Configuration

Branch Office Configuration

Alternate Scaling Using PA ATM-PA3 Conclusion

Headend Scale Testing—No QoS on the Logical Interface

Test Overview

Test Results

Analysis of Performance Data

Appendix A—Detailed Test Results

Netflow Summary Table

Control Branch

Branch to Headend Upstream

Headend-to-Branch Downstream

Cisco IOS Software Versions Tested

Caveats and DDTS Filed

Line Protocol

Appendix B—Peer has IPsec Interface Support

Appendix C—Output for debug crypto ipsec client ezvpn Command

Appendix D—Output for show crypto session detail Command

Appendix D—References

Appendix E—Acronyms and Definitions

Introduction

The IPsec VPN wide area network (WAN) architecture is described in multiple design guides based on the type of technology used, as shown by the list in Figure 1:

Figure 1 IPsec VPN WAN Design Guides

Each technology uses IPsec as the underlying transport mechanism for each VPN. The operation of IPsec is outlined in the IPsec VPN WAN Design Overview, which also outlines the criteria for selecting a specific IPsec VPN WAN technology. This document should be used to select the correct technology for the proposed network design.

This design guide builds on the following series of design guides, which are available at http://cco.cisco.com/go/srnd/:

• Voice and Video Enabled IPsec VPN (V3PN) Design Guide

• Enterprise Class Teleworker: V3PN for Teleworkers Design Guide IPsec VPN WAN Design Overview

(OL-9021-01) Topologies

Point-to-Point GRE over IPsec Design Guide

(OL-9023-01)

Virtual Tunnel Interface (VTI) Design Guide

(OL-9025-01)

Service and Specialized Topics IPsec VPN Redundancy and Load Sharing

Design Guide (OL-9025-01)

Voice and Video IPsec VPN (V3PN): QoS and IPsec Design Guide

(OL-9027-01)

Multicast over IPsec VPN Design Guide (OL-9028-01)

Digital Certification/PKI for IPsec VPN Design Guide

(OL-9029-01)

Enterprise QoS Design Guide (OL-9030-01)

Dynamic Multipoint VPN (DMVPN) Design Guide

(OL-9024-01) IPsec Direct Encapsulation

Design Guide (OL-9022-01)

148756

• Enterprise Class Teleworker: Teleworker Design Guide

• IPsec V3PN: Redundancy and Load Sharing

This design guide is based on Cisco VPN routers running Cisco IOS software, with IPsec as the tunneling method, using site-to-site VPN topologies. This guide helps evaluate Cisco VPN product performance in scalable and resilient designs and addresses the following applications of the solution:

• Dead Peer Detection (DPD)

• Converged data and VoIP traffic requirements

• Quality of service (QoS) features enabled

• Use of Enhanced Interior Gateway Routing Protocol (EIGRP) and Open Shortest Path First (OSPF) as the routing protocol across the VPN

Design Overview

This section provides an overview of the design considerations when implementing VTIs.

Starting Assumptions

Enterprise customers deploy IPsec-based VPNs over public and private networks for secrecy, authentication, and data integrity. However, IPsec is viewed as a tunnel between two IPsec peers regardless of the underlying WAN transport.

A VTI is an interface that supports native IPsec tunneling, and allows you to apply interface commands directly to the IPsec tunnels. The configuration of this tunnel interface is similar to a GRE tunnel interface and is well understood.

A VTI has most of the properties of a physical interface. It provides a comprehensive solution, creating dynamic virtual tunnel interfaces (similar to what is currently done in the dialup world) to enable the deployment of large-scale IPsec networks with minimal configuration.

The design approach presented in this design guide makes several starting assumptions.

• All performance tests were executed with the following:

– A hierarchical Class-Based Weighted Fair Queuing (CBWFQ), which provides queuing within a shaped rate, on the VTI interface pre-crypto on both headend and branch routers

– Dynamic VTI (DVTI) on headend crypto systems, and static VTI on the branches

• The design supports a typical converged traffic profile for customers (see Scalability Test Results (Unicast Only), page 54).

• It is assumed that the customer has a need for diverse traffic requirements, such as IP multicast (IPmc), and support for routing. The use of VTI and routing protocols are also discussed in more detail in Design and Implementation, page 11.

• Cisco products should be maintained at reasonable CPU utilization levels. This is discussed in more detail in Scalability Considerations, page 51, including recommendations for both headend and branch routers, and software revisions.

• Although costs are certainly considered, the design recommendations assume that the customer deploys current VPN technologies, including hardware-accelerated encryption.

• Voice over IP (VoIP) and video are assumed to be requirements in the network. Detailed design considerations for handling VoIP and other latency-sensitive traffic are not explicitly addressed in this design guide, but may be found in Voice and Video Enabled IPsec VPN (V3PN) Design Guide at the following URL: http://www.cisco.com/go/srnd

• This design is targeted for deployment by enterprise-owned VPNs. However, the concepts and conclusions are valid regardless of the ownership of the edge tunneling equipment, and are therefore valuable for service provider-managed VPNs as well.

Design Components

VPNs have many applications, including extending reachability of an enterprise WAN, or replacing classic WAN technologies such as leased lines, Frame Relay, and ATM. Site-to-site VPNs are primarily deployed to connect branch office locations to the central site (or sites) of an enterprise.

The requirements of enterprise customers for traditional private WAN services, such as high availability, scalability, and security, are also requirements for VPNs. VPNs can often meet these requirements more cost effectively and with greater flexibility than private WAN services.

The key components of this site-to-site VPN design are the following:

• Cisco high-end VPN routers serve as VPN headend termination devices at a central campus (headend devices)

• Cisco VPN access routers serve as VPN branch termination devices at branch office locations (branch devices)

• Dynamic VTI (DVTI) performs headend-to-branch interconnections

• Internet services are provided by a third-party ISP (or ISPs) serving as the WAN interconnection medium

Cisco VPN routers are a good choice for site-to-site VPN deployments because they can accommodate any network requirement inherited from a Frame Relay or private line network, such as support for multicast and latency-sensitive traffic, and routing for resiliency. See Scalability Considerations, page 51 for a discussion about selecting headend and branch products.

In a VTI design, a hub-and-spoke topology is used, as shown in Figure 2.

Figure 2 Hub-and-Spoke Topology

Comparing DVTI with other VPN Topologies

Table 1 shows a comparison of DVTI with other VPN topologies for a headend deployment.

Corporate Network

Primary ISP

IP Connectivity VPN Tunnel (IPSEC)

Secondary ISP Central Site

Branch Offices

126121

Table 1 Dynamic Virtual Tunnel Interface (DVTI)

Common Features Advantages Disadvantages

IPsec Direct Encapsulation

(Dynamic crypto map)

Simple configuration of headend

“once and done”

• DVTI uses virtual templates

• IPsec uses dynamic crypto maps

Support for IPmc

Support for IGP dynamic routing protocol over the VPN (EIGRP or OSPF, and so forth)

Support for per-branch QoS and traffic shaping (pre-crypto)

Larger packet header bloat:

• VTI = +4 bytes

• IPsec = +0 bytes DVTI requires IP unnumbered p2p GRE over IPsec

(p2p GRE over an IPsec dynamic crypto map)

Support for IPmc

Support for IGP dynamic routing protocol over the VPN (EIGRP or OSPF, and so forth)

Support for per branch QoS and traffic shaping (pre-crypto)

Backward compatibility with IPsec direct encapsulation branches

Smaller packet header bloat:

• VTI = +4 bytes

• p2p GRE = +24 bytes Simple configuration of headend

“once and done”

• DVTI uses virtual templates

• p2p GRE uses statically defined independent tunnel interfaces per branch

No support for non-IP protocol (multiprotocol) No support for IPsec transport mode DVTI requires IP unnumbered

DMVPN (hub-and-spoke)

Support for IPmc

Support for IGP dynamic routing protocol over the VPN (EIGRP or OSPF, and so forth)

Supports only IPsec tunnel mode Simple configuration of headend

“once and done”

• DVTI uses virtual templates

• DMVPN uses a common mGRE interface

Backward compatibility with IPsec direct encapsulation branches

Smaller packet header bloat:

• VTI = +4 bytes

• mGRE = +28 bytes

Support for per branch QoS and traffic shaping (pre-crypto) No NHRP required

DVTI requires IP unnumbered

Understanding Scalability Results

In the Cisco test lab, all headend scalability results were performed on a Cisco 7200VXR with NPE-G1 with Dual SA-VAM2. Results were obtained with an LLQ service policy with Generic Traffic Shaping applied per virtual access or branch tunnel interface. The rationale for this testing methodology was to find out the scalability of the platform with the service policies applied to the following issues:

• Removing anti-replay issues induced by the crypto routers

• Gaining the ability to shape per tunnel to avoid overrunning the branch router downlink speed The current performance results proved less than desirable. The primary reason for this degradation is because of the Generic Traffic Shaping feature being process-switched and CPU-intensive. Note that in a p2p GRE over IPsec design, if the identical service policies are applied to the same number of p2p GRE tunnel interfaces, the performance would likely be similar. The impact of queuing on performance is described later in this document.

Best Practices and Known Limitations

The following sections contain a summary of the best practices and limitations for the design. More detailed information is provided in Design and Implementation, page 11.

Best Practices Summary

This section summarizes the best practices for a VTI deployment.

General Best Practices

The following are general best practices:

• When using Traffic Shaping on a tunnel interface or a virtual template interface, do not use the qos pre-classify command because it is not required or useful in this topology.

• Headend and branch routers should use the “ip unnumbered” interface in their VTI configurations.

• If EZVPN is configured on the branch router, see EZVPN Remote Client—Mode Network-Plus, page 22 for implementation details.

• Use PKI/Digital Certificates or IKE aggressive mode as the IKE authentication method.

• Use IPsec tunnel mode for transform sets in IPsec.

• Configure Triple DES (3DES) or AES for encryption of transported data (exports of encryption algorithms to certain countries may be prohibited by law).

• Implement DPD to detect loss of communication between crypto peers.

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

• Keep IPsec packet fragmentation to a minimum on the customer network by setting MTU size or using Path MTU Discovery (PMTUD).

• Configure a routing protocol (for example, EIGRP or OSPF) with route summarization for dynamic routing.

Headend Best Practices

The following are best practices that should be implemented on the headend device:

• Create a virtual template for each unique branch characteristic so that branches that share these characteristics can all reference the appropriate common virtual template.

• Summarize network advertisements to the fullest extent possible on the virtual template.

• Use a loopback interface address as the “borrowed” address for the “ip unnumbered” interface configuration on the virtual template. All configured virtual templates may reference the same loopback.

• If high availability is a requirement, implement a design with redundancy of headend equipment and WAN circuits.

• Distribute branch office tunnels across a number of headend routers to balance loading and aggregation capacity of the hub(s).

• Select Cisco VPN router products at the headend based on considerations for the following:

– Number of tunnels to be aggregated

– Maximum throughput in both pps and bps to be aggregated – Performance margin for resiliency and failover scenarios – Maintaining CPU utilization below design target

– Whether a traffic shaper is applied “pre-crypto”

See Scalability Considerations, page 51 for more information.

Branch Office Best Practices

The following are best practices that should be implemented on the branch office device:

• If EIGRP is the routing protocol, EIGRP Stub should be configured

• If the inside LAN interface is the “borrowed” address for the “ip unnumbered” interface configuration of the tunnel interface, disable interface keepalives (no keep) so the interface line protocol is always up. For branch routers with VLAN interfaces, an Ethernet crossover cable connecting two switch ports ensures that the VLAN interface line protocol is up.

• Configure multiple VTI tunnels to redundant headends.

• Select Cisco VPN router products at the branch offices based on considerations for the following:

– Maximum throughput in both pps and bps

– Allowances for other integrated services that may be running on the router (for example, firewall, IPS, NAT/PAT, and so forth)

– Maintaining CPU utilization below 65–80 percent See Scalability Considerations, page 51 for more information.

Known Limitations Summary

This section provides a high-level summary of the known limitations for a VTI deployment.

General Limitations

The following are the general limitations that apply to the solution:

• VTI is not currently available in the Cisco Catalyst 6500 or Cisco 7600 Series routers.

• Tunnel interface keepalives are not supported. A dynamic routing protocol must be used because the headend interface is dynamic, a virtual access interface.

• “ip unnumbered” interfaces may confuse some NMS network mapping abilities.

• There are significant scalability limitations for supporting IPmc over VTI tunnel designs. For more information, see the Multicast over IPsec VPN Design Guide at the following URL:

http://www.cisco.com/go/srnd.

• All VTI implementations can be implemented only in a Single Tier Headend Architecture.

• There are additional limitations specific to EZVPN; see Easy VPN with Dynamic Virtual Tunnel Interface Support, page 16.

Headend Limitations

Using optional downstream traffic shaping, although effective for preserving voice quality, consumes too many CPU cycles while shaping is active. When the shaper is engaged, packets are process-switched.

Branch Office Limitations

The following limitations apply to the branch office device:

• Do not use IP unnumbered on the headend and a static IP address on the branch tunnel interface.

• A static VTI tunnel must be initiated by the remote branch to a DVTI headend. The crypto headend cannot initiate the tunnel to the branch.

Additional detailed information about these recommendations is discussed in the sections that follow.

Design and Implementation

This section addresses design and implementation issues and provides implementation examples for reference.

Overview

The VTI is characterized by the following features:

• Provides a routable interface

• Supports per-tunnel features (or peer) configurations

• Reordering of packets by QoS features occurs pre-encryption; anti-replay drops because of QoS on originating router are eliminated

• Supports encryption of IPmc

• Headend routers can be configured with virtual templates, rather than a static tunnel interface per remote peer

• Load balancing and high availability (failover) are functions of the routing protocol in use

• The virtual access/virtual template interfaces are point-to-point, unlike the point-to-multipoint used with DMVPN. The point-to-multipoint interface of DMVPN does not currently support capability to do per-tunnel features.

A limitation of VTI is the lack of an interface keepalive equivalent to a GRE keepalive. Many network managers prefer to use a GRE keepalive and a redistributed static route to the tunnel interface instead of using a routing protocol hello and adjacency over the interface. Although the routing protocol and GRE keepalive can be functionally equivalent, there may be less CPU overhead incurred by using a GRE keepalive.

Design Considerations

This section defines the design considerations for implementing VTIs.

Virtual Tunnel Interface

VTI may be configured statically on both peers. Alternatively, the headend can use a dynamic VTI configuration. This topology allows a “once and done” configuration of the headend and also incorporates a tunnel interface by way of a virtual access interface for each remote router.

When EZVPN is configured on the branch router, VTI is configured as dynamic on both the branch and headend router.

Note Do not confuse virtual tunnel interface with virtual template interface service. See the next section for details.

Virtual Template Interface Service

Virtual template interface service originally was for use primarily with large numbers of dial-in users.

Virtual templates can be configured independently of any physical interface and applied dynamically, per “session”, to create virtual access interfaces. Virtual templates have been used for virtual private dialup networks (VPDN), with PPP over ATM, in a multilink PPP, or in a multichasses multilink PPP configuration.

The virtual tunnel interface makes use of the virtual template interface service feature on the headend crypto router. An example of a show interface command from a crypto headend router is as follows:

CRYPTO_HEADEND#show int virtual-access 4 | inc Tunnel|Inter|is up Virtual-Access4 is up, line protocol is up

Interface is unnumbered. Using address of Loopback1 (10.8.100.1) Tunnel vaccess, cloned from Virtual-Template1

Tunnel source 192.168.131.39, destination 192.168.128.198 Tunnel protocol/transport IPSEC/IP

Tunnel TTL 255

Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps)

Tunnel protection via IPsec (profile "VirtualTunnelInterface")

In the above example, the tunnel source IP address of 192.168.131.39 is an address on this router, the IP address of the remote router is 192.168.128.198, and in this example is dynamically assigned to the remote (branch) router by DHCP. Note from the display that this interface is cloned from

Virtual-Template1. The unique configuration characteristics of the virtual template are applied to the virtual access interface on a session-by-session, peer-by-peer basis.

VTI provides for a dynamically cloned point-to-point logical interfaces for each branch. For more information about virtual templates, see the following website:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/vtemp.htm

Per-Tunnel Features

VTI enables the implementation of QoS and other features from a crypto headend to a branch router on a per-crypto peer basis. An ISAKMP and IPsec security association between two crypto peers is a

“session”, similar to a PPP session; therefore, per-tunnel features can be implemented on a session-by-session basis.

A branch router can be configured to have multiple sessions between the same or multiple crypto headend routers. Later in this document is an example where two branch routers have sessions or tunnels to a single crypto headend router. One branch has one tunnel to the crypto headend and the other branch has two tunnels to the same crypto headend. The early scale testing of this feature had two Cisco 7200VXR routers; one branch and one crypto headend with sixteen tunnels and sixteen equal cost paths in the routing table between the two routers. This configuration is not recommended, but it can be configured.

Branch routers that share a common per-tunnel feature, such as a downlink QoS shaper rate, can reference the same virtual template on the crypto headend router. The crypto headend virtual template that is invoked is determined by the branch router configuration. The tunnel destination IP address on the branch router determines the virtual template to use. The crypto headend router has a unique IP address per virtual template. This concept is illustrated in Figure 3.

Figure 3 Virtual Template Invoked by Branch Router

IKE pkts to 192.168.2.1

148742

interface Tunnel0

ip unnumbered Loopback1 tunnel source FastEthernet0 tunnel destination 192.168.2.1 tunnel mode ipsec ipv4

tunnel protection ipsec profile VTI Branch

Crypto Head End

Tunnel protect ipsec profile …

192.168.2.1

Data Plane crypto isakmp profile

Control Plane service-policy output VTI-1.4Mdown-shaper

interface Virtual-Template n interface Virtual-Access n

A crypto headend router can have multiple virtual templates defined. The ISAKMP packets of the branch router destination address select the ISAKMP profile to use on the headend, which is then

cross-referenced to a IPsec profile and virtual template. The virtual access interface is spawned from the virtual template and inherits the configured QoS service policy. The control plane selects the appropriate QoS service policy for the data plane.

The actual limit of the number of virtual templates permitted in the configuration of a Cisco 7200VXR Series router in Cisco IOS 12.3(14)T2 is 1000. However, most deployments require only less than a dozen. From the standpoint of downlink shaping, most customer deployments would likely have 768 Kbps, 1.4 Mbps, or T1, E1, and perhaps 3 Mbps and 4 Mbps. These data rates are commonly seen on broadband links and T1/E1 serial links.

Encapsulation

For Cisco Express Forwarding to work, a dummy four-byte encapsulation string is used. The encapsulation string is stripped off during the fixup. Figure 4 illustrates this.

Figure 4 Encapsulation

The additional overhead of the four-byte VTI header is the same as p2p GRE (in transport mode) but less than mGRE. p2p GRE has a four-byte header and mGRE has an eight-byte header. VTI does not add an extra encapsulating IP header because both p2p GRE and mGRE add to a transiting packet.

QoS Service Policy

In this guide, the QoS service policy is applied to the tunnel interface on the branch router and to the virtual template on the crypto headend router, which is beneficial of two reasons: it reduces ESP replay check (anti-replay) errors, and invokes downstream QoS capability where not provisioned by the ISP.

4

20 IP Hdr

UDP Hdr

8 n

payload

N + 28

148743

8 UDP

Hdr

ESP Hdr

3DES IV

8 8 n

pad ESP Pad/NH

ESP Auth

2 12

20 IP Hdr

With NAT-T

With AES-128

16

N + 32 VTI encapsulation

IPSec encapsulation

IP MTU 1408 Dummy

Encapsulation Header

Anti-Replay

The Voice and Video Enabled IPsec VPN (V3PN) Design Guide explains the concept of IPsec anti-replay in great detail. To summarize, a function of IPsec, and more specifically Encapsulating Security Payload (ESP), is to provide a means to detect whether packets have been captured in transit and changed and replayed, or simply duplicated and replayed between sender and receiver. This function is described in RFC 2406 in Section 3.4.3 “Sequence Number Verification” at the following URL:

ftp://ftp.isi.edu/in-notes/rfc2406.txt

In configurations where the encrypting router re-orders packets post-encryption (after the ESP sequence number is assigned) as a function of an output interface QoS service policy, the likelihood of anti-replay drops induced by the sending crypto router and then received by the other crypto peer increases.

Pre-Encryption QoS

One advantage of VTI with the QoS service policy applied to the tunnel (or virtual access interface on the headend) is that packets are re-ordered before encryption and assignment of the ESP sequence number. In performance testing, the QoS service policy is applied pre-encryption. The net result of this is no re-ordering by the originating router post-ESP encapsulation.

To illustrate this point, a single branch router test is run to quantify the benefit of pre-encryption QoS (tunnel) compared to post-encryption (physical interface, FE0/1) QoS. The same traffic profile is used in two ten-minute tests. In these tests, QoS in the core network is not an issue; no core congestion or re-ordering takes place. Figure 5 shows the tested topology.

Figure 5 Pre-Encryption QoS Compared to Post-Encryption QoS

The first test was run with the service policy on the outside interface. This configuration is similar to a V3PN teleworker deployment where the outside interface is connected to a cable or DSL modem or bridge.

interface FastEthernet0/1 description FastEthernet0/1

ip address 192.168.192.22 255.255.255.0 …

service-policy output Shaper-768K

ip route 192.168.136.0 255.255.255.0 192.168.192.2 name ISP_router

At the end of the test, the replay error counter is displayed on the headend crypto peer.

show pas isa int

VPN Acceleration Module Version II in slot : 5

Statistics for Hardware VPN Module since the last clear of counters 620 seconds ago

342948 packets in 342948 packets out 88060130 bytes in 87867591 bytes out

148744

vpn-jk3-2651xm-2 Branch Router

10.0.84.1

Internet Service Provider

AS 65002

IP

192.168.136.17 F0/1 - Static IP

IPSec Tunnel 192.168.192.0/18

Crypto HE wpoc1-r1

553 paks/sec in 553 paks/sec out 1135 Kbits/sec in 1133 Kbits/sec out ....

Errors:

ppq full errors : 0 ppq rx errors : 0 cmdq full errors : 0 cmdq rx errors : 0 ppq down errors : 0 cmdq down errors : 0 no buffer : 0 replay errors : 3297

There are 3297 replay errors out of 342,948 input packets; less than one percent of the total packets, which is a typical result based on past V3PN tests.

Now the service policy is removed from the outside interface and applied to the tunnel interface instead.

interface Tunnel1

description VTI to wpoc1-r1 …

service-policy output Shaper-768K

The headend counters are cleared between tests and the test profile is executed for another ten minutes.

At the end of this test, the counters are displayed again.

show pas isa int

VPN Acceleration Module Version II in slot : 5

Statistics for Hardware VPN Module since the last clear of counters 620 seconds ago

354714 packets in 354714 packets out 99807349 bytes in 99953205 bytes out 572 paks/sec in 572 paks/sec out 1287 Kbits/sec in 1289 Kbits/sec out ...

Errors:

ppq full errors : 0 ppq rx errors : 0 cmdq full errors : 0 cmdq rx errors : 0 ppq down errors : 0 cmdq down errors : 0 no buffer : 0 replay errors : 0

For a similar pps rate (actually slightly higher), all anti-replay drops have been eliminated. There are configurations where it continues to be desirable to apply a service policy on the output interface, specifically in split tunnel or “spouse and child” configurations. However, these configurations are more typical with a teleworker deployment than a branch deployment.

Easy VPN with Dynamic Virtual Tunnel Interface Support

As of Cisco IOS version 12.4(4), Easy VPN (EZVPN) and DVTI incorporate features that allow network managers to position EZVPN to support branch offices as well as teleworker deployments.

These features include the following:

• Dual Tunnel

• Routing protocol support, enabling load sharing

• IPmc support

• Network-plus mode

The following two other features are available but are likely more suitably targeted at a remote access or teleworker deployment rather than a branch router deployment:

• Pushing a banner by the EZVPN server

• Pushing a configuration URL through a mode-configuration exchange

This section provides an overview of these features. Configuration and Implementation, page 25 shows sample configurations as a guide for implementation.

Dual Tunnel

EZVPN now includes a feature named Easy VPN Dual Tunnel, which supports a configuration with two EZVPN tunnels that have the same inside and outside interfaces.

Note For more information on Easy VPN Dual Tunnel, see the following URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_7/ftezvpnr.htm

#wp1292665

Several caveats govern the use of this feature; these restrictions are incorporated into the configuration examples shown later in this document.

The restrictions are that both tunnels cannot do the following:

• Terminate on the same peer

• Use a non-split tunnel policy

The restriction on both tunnels terminating on the same peer is not important because the best practice is to terminate each tunnel on a separate headend router. This provides hardware redundancy if a headend fails, or is taken out of service for a software upgrade or other maintenance activity.

The second restriction is that both tunnels are not permitted to use a non-split tunnel policy; that is, one tunnel must be split tunnel and the other can be non-split tunnel. Although this may seem to be an issue for many network managers that are governed by security policies that require non-split tunnel, the configuration illustrates a workaround to this restriction. In the example, both headend routers are configured with an ACL keyword, enabling split tunnel, while using the routing protocol network advertisements to route all enterprise traffic into one or both tunnels. This effectively circumvents the split tunnel EZVPN configuration.

The branch configuration has two separate crypto ipsec client ezvpn configurations along with the associated virtual templates:

crypto ipsec client ezvpn VTI_SECOND connect auto

group RTP_ezvpn_group key MrExcitement mode network-plus

peer 192.168.136.19 virtual-interface 52

username EZVPN_Test_user password JimmyS xauth userid mode local

!

crypto ipsec client ezvpn VTI connect auto

group RTP_ezvpn_group key MrExcitement mode network-plus

peer 192.168.136.17 virtual-interface 51

username EZVPN_Test_user password JimmyS xauth userid mode local

!

interface Virtual-Template52 type tunnel description ->

no ip address ip mtu 1408

ip pim sparse-mode ip route-cache flow

tunnel mode ipsec ipv4

!

interface Virtual-Template51 type tunnel description ->

no ip address ip mtu 1408

ip pim sparse-mode ip route-cache flow tunnel mode ipsec ipv4

!

The outside interface references both crypto ipsec client ezvpn configurations as well as the inside interface:

!

interface FastEthernet0/1

description Outside [VLAN 51 AS 65001]

ip address dhcp

crypto ipsec client ezvpn VTI_SECOND crypto ipsec client ezvpn VTI

!

interface Ethernet1/0

description VLAN 208 Inside ip address 10.0.76.1 255.255.255.0

crypto ipsec client ezvpn VTI_SECOND inside crypto ipsec client ezvpn VTI inside

!

!

Note CSCsc63242 (Cannot remove EZVPN configuration from inside interface) prevents the configuration from being removed as would be expected.

Routing Protocol Configuration

The branch and headend routers run EIGRP as the routing protocol. On the branch router, there is a static route for network 192.168.136.0/24 to the DHCP-learned default gateway. Both headend routers fall into this network, and it is assumed that only IPsec headend devices exist on the 192.168.136.0/24 network.

In this example, the DHCP server that supplies the IP address of the outside interface of the branch router advertises the DHCP server as the next-hop address for the default route. Cisco IOS DHCP clients use 254 by default as the administrative distance of the DHCP-learned default route.

Given the split tunnel configuration, the EZVPN server advertises in the EZVPN mode_config_msg the network 192.0.2.0/24 to the remote router. This network is inserted in the routing table of the branch router with an administrative distance of 1, using the virtual access interface as the next hop.

The headend EIGRP neighbor advertises through the VTI tunnel a default route with an administrative distance of 170 to the branch router. Because 170 is lower (more preferred) than the DHCP default route (254), the default route learned from EIGRP is inserted into the branch routing table. This overrides the split tunnel configuration and forces all user traffic into the virtual access interface to the headend.

The relationship of these routing information sources is shown in Figure 6. Only one headend router is shown for clarity.

Figure 6 Routing Information Sources

For purposes of documentation, assume that 192.168.0.0/16 and 172.26.0.0/16 represent Internet routable address space and 10.0.0.0/8 represents enterprise address space. The following is the branch router configuration:

router eigrp 100 network 10.0.0.0 no auto-summary eigrp stub connected

!

ip route 192.168.136.0 255.255.255.0 dhcp

! end

The following commands are for one of the two headend routers. Both headend routers are configured similarly. The client configuration on the EZVPN server references an ACL, and thus split tunnel is enabled.

crypto isakmp client configuration group RTP_ezvpn_group …

acl SPLIT_TUNNEL_LIST

!

In this example, the headend also runs EIGRP. The virtual-template interface 154 is referenced by the distribute list statement under the routing protocol definition.

!

crypto isakmp profile VTI_IKE_Profile_alpha …

virtual-template 154

!

!

crypto ipsec profile EZVPN_VTI set transform-set 3DES_SHA_TUNNEL set isakmp-profile VTI_IKE_Profile_alpha

…

148776

EZVPN

"mode_config_msg"

192.0.2.0/24 [1]

EIGRP 0.0.0.0 / 0.0.0.0 [170]

Static route 192.168.136.0/24 t DHCP assigned gateway as next hop [1]

DHCP server 0.0.0.0 / 0.0.0.0 to DHCP assigned gateway as next hop [254]

192.168.136.17 WPOC1-r1 EZVPN VTI

Tunnel

Note: The number in square brackets is the administrative distance of the route specified.

Example, [170] is an EIGRP external.

Backup only 10.0.76.1

interface Virtual-Template154 type tunnel …

tunnel mode ipsec ipv4

tunnel protection ipsec profile EZVPN_VTI

!

In the EIGRP configuration, only a default route is advertised out the virtual access interfaces cloned from virtual-template 154.

The network listed in the SPLIT_TUNNEL_LIST ACL is a special use IP address; it is reserved and not routed over the Internet. Any IP network in use by the Internet or by the enterprise can be used instead.

The network address referenced by the split tunnel ACL is inserted into the routing table of the branch router, with the virtual access interface as the next hop.

The routing protocol advertises a default route through the VTI tunnel, effectively circumventing the split tunnel configuration.

This configuration is implemented on both headend routers to implement this concept.

crypto isakmp client configuration group RTP_ezvpn_group …

acl SPLIT_TUNNEL_LIST

…

router eigrp 100

redistribute static metric 256 100 255 1 1408 route-map REDIST_STATIC network 10.0.0.0

network 192.168.130.0 0.0.1.255 network 192.168.136.0 0.0.1.255

distribute-list ROUTES_for_REMOTE out Virtual-Template154 no auto-summary

!

ip route 0.0.0.0 0.0.0.0 Null0 20

ip route 192.0.2.0 255.255.255.0 Null0 240 name TEST-NET

!

ip access-list standard ROUTES_for_REMOTE permit 0.0.0.0

deny any

!

ip access-list extended SPLIT_TUNNEL_LIST permit ip 192.0.2.0 0.0.0.255 any

!

!

route-map REDIST_STATIC permit 10 match ip address ROUTES_for_REMOTE

! end

In the routing table of the branch router, EZVPN inserts a static route for 192.0.2.0/24 to both tunnel (virtual access) interfaces. The EIGRP routing protocol advertises a default route from both headend routers, providing load sharing across both headends.

vpn-jk3-2651xm-3#show ip route | beg Gateway

Gateway of last resort is 10.9.100.1 to network 0.0.0.0 C 192.168.128.0/24 is directly connected, FastEthernet0/1 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks C 10.0.76.0/24 is directly connected, Ethernet1/0 C 10.8.100.21/32 is directly connected, Loopback0 C 10.9.100.26/32 is directly connected, Loopback1 S 192.168.136.0/24 [1/0] via 192.168.128.1

S 192.0.2.0/24 [1/0] via 0.0.0.0, Virtual-Access2 [1/0] via 0.0.0.0, Virtual-Access3

D*EX 0.0.0.0/0 [170/297270016] via 10.9.100.1, 03:02:55, Virtual-Access3 [170/297270016] via 10.8.100.1, 03:02:55, Virtual-Access2

Looking now at the relevant portion of the routing table of one of the two headend routers, the branch advertises the remove subnet and the loopback interface to the headend.

wpoc1-r1#show ip route | inc Vi

S 10.0.76.0/24 [1/0] via 0.0.0.0, Virtual-Access2

[90/297372416] via 10.9.100.26, 03:03:22, Virtual-Access2 S 10.9.100.26/32 [1/0] via 0.0.0.0, Virtual-Access2

In summary, when an EZVPN server pushes split tunnel networks to a remote router, the remote router inserts those specific routes to the split network in its routing table, directing the traffic out the virtual tunnel interfaces. A routing protocol is then run to advertise a default route to the branch, directing all user traffic to the headend through the virtual tunnel interfaces. The configuration is such that the default route overrides any default route learned via DHCP or configured statically in the branch router.

If load sharing is not desired, all traffic should use a primary headend; the secondary headend is intended to be used only as a backup, and the cost or metric component is changed to make the tunnel less preferred. In the case of EIGRP shown in this example, change the delay to a value greater than the default of 50,000 on both the branch and headend router.

!

interface Virtual-Template52 type tunnel

….

delay 60000

…

tunnel mode ipsec ipv4 end

After clearing the EZVPN connections, only one route is now in the routing table for the default route.

vpn-jk3-2651xm-3#show ip route | beg Gateway

Gateway of last resort is 10.9.100.1 to network 0.0.0.0 C 192.168.128.0/24 is directly connected, FastEthernet0/1 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks C 10.0.76.0/24 is directly connected, Ethernet1/0 C 10.8.100.22/32 is directly connected, Loopback1 C 10.9.100.27/32 is directly connected, Loopback0 S 192.168.136.0/24 [1/0] via 192.168.128.1

S 192.0.2.0/24 [1/0] via 0.0.0.0, Virtual-Access3 [1/0] via 0.0.0.0, Virtual-Access2

D*EX 0.0.0.0/0 [170/297270016] via 10.9.100.1, 00:00:17, Virtual-Access3

The EIGRP topology table continues to have both:

vpn-jk3-2651xm-3#show ip eigrp topology | beg 0.0.0.0 P 0.0.0.0/0, 1 successors, FD is 297270016

via 10.9.100.1 (297270016/10025472), Virtual-Access3 via 10.8.100.1 (299830016/10025472), Virtual-Access2

The less preferred path is inserted into the routing table in the event that the primary peer is unreachable or out of service.

IP Multicast

IPmc can be configured on the virtual template interfaces, and IPmc routing is supported with the EZVPN configuration shown in this guide. The following display is from the branch router:

vpn-jk3-2651xm-3#show ip pim neighbor PIM Neighbor Table

Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 10.9.100.1 Virtual-Access3 00:20:33/00:01:23 v2 1 / S

10.8.100.1 Virtual-Access2 00:20:32/00:01:21 v2 1 / S

Note that there are PIM neighbors on both tunnel interfaces.

EZVPN Remote Client—Mode Network-Plus

Network extension plus (mode network-plus) is similar to network extension mode, except that an IP address is allocated from the address pool configured on the headend router and automatically assigned to an available loopback interface on the branch router. In effect, the pool is created on the headend when the branch router requests or initiates this mode. The branch router CLI is as follows:

vpn-jk3-2651xm-3(config)#crypto ipsec client ezvpn VTI vpn-jk3-2651xm-3(config-crypto-ezvpn)#mode ?

client Client

network-extension Network Extension

network-plus Request a IP address identifier in NEM

Best Practices

The headend router defines a pool, in this case named MODE_network-plus, and allocates a range of IP addresses out of the 10.9.100.0/24 block. The first IP address in this block is configured on a loopback address. This loopback address is the borrowed IP address for the “ip unnumbered” statement in the virtual template.

crypto isakmp client configuration group RTP_ezvpn_group …

pool MODE_network-plus !

…

interface Loopback901 description Anchor for VTI

ip address 10.9.100.1 255.255.255.255

…

ip local pool MODE_network-plus 10.9.100.2 10.9.100.253 interface Virtual-Template154 type tunnel

ip unnumbered Loopback901

The branch router uses this dynamically allocated loopback interface by default as the source of the borrowed address for the branch virtual template. As such, with the above configuration, the headend router sees the branch router identified as an address allocated from the pool MODE_network-plus, as follows:

wpoc1-r1#show ip eigrp neighbors | inc Vi

21 10.9.100.26 Vi2 12 00:22:56 103 5000 0 192

The branch router can identify the respective headend router as the first address from the 10.9.100.0/24 network, 10.9.100.1, as follows:

vpn-jk3-2651xm-3#show ip eigrp neighbors IP-EIGRP neighbors for process 100

H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 1 10.9.100.1 Vi3 13 00:23:17 19 5000 0 1664 0 10.8.100.1 Vi2 13 00:23:18 55 5000 0 1389

In the above example, the neighbor identified by 10.8.100.1 is the second headend, similarly configured to the primary headend but using 10.8.100.0/24 as the address block.

Caveats

There are two caveats that the network manager must consider. If a write memory or copy

running-config startup-config command is issued while the tunnels are up, the dynamically assigned loopback interfaces are saved in the startup configuration. If the router is then reloaded or ISAKMP disabled and re-enabled, new (additional) interfaces are created and addresses are assigned from the headend pool.

The following is an example from a branch router configuration where the configuration was saved with the tunnel up to the headend peer, allocating the address from the 10.8.100.0/24 block.

!

interface Loopback0

ip address 10.8.100.15 255.255.255.255

!

interface Loopback1

ip address 10.9.100.25 255.255.255.255

!

interface Loopback2

ip address 10.8.100.20 255.255.255.255

The tunnel was then re-initiated, causing the headend to allocate the Loopback2 interface with another address from the pool. To clear this condition, disable ISAKMP on the branch router (no crypto isakmp enable), delete all loopback interfaces, and then re-enable ISAKMP (crypto isakmp enable).

The second caveat is that configuring an ip unnumbered command on the branch router virtual template is ignored, and the outside IP address is used as the “borrowed” IP address when network-extension mode is used instead of network-plus.

The network manager must become familiar with, and understand the implications of, this feature along with the associated caveats related to the enterprise network management scheme. Because the IP addresses are allocated dynamically and are not associated permanently with any one branch, this feature may present problems for the support desk.

Banner

A banner can be pushed to the branch router. It is configured on the headend router.

crypto isakmp client configuration group RTP_ezvpn_group …

banner ^C

==

====

====== Hello from wpoc1-r1

====

==

^C

When the branch connects to the headend, the banner is displayed on the console and logging buffer.

Following is an example from the dual tunnel configuration used in this section:

Dec 8 14:44:34 est: %CRYPTO-6-EZVPN_CONNECTION_DOWN: (Client) User=EZVPN_Test_user Group=RTP_ezvpn_group Server_public_addr=…

==

====

====== Hello from vpn-jk3-2651xm-9

====

==

==

====

====== Hello from wpoc1-r1

====

==

Dec 8 14:44:35 est: %CRYPTO-6-EZVPN_CONNECTION_UP: (Client) User=EZVPN_Test_user Group=RTP_ezvpn_group

This feature may have applications for debugging but from a branch router perspective, the individual users are not viewing the console and do not see the message.

Configuration URL

The configuration URL feature is designed to help push a configuration template to all members of the group as part of the tunnel establishment. The file served is in Cisco IOS CLI format. By default, the commands are considered persistent, and are present whether or not the tunnel is up to the headend. The commands are not written to NVRAM. Keywords in the file identify the nature of the CLI commands that follow: !%transient (the keyword should be on a single line), or optionally !%persistent. The following examples show how this is configured on the Easy VPN server and on the FTP server from which the file is obtained by the Easy VPN remote.

The Easy VPN server configuration is as follows:

crypto isakmp client configuration group RTP_ezvpn_group …

configuration url ftp://root:[email protected]//usr/tmp/CFG-version11.txt configuration version 11

The FTP server and the source file is as follows:

# ifconfig -a | grep inet

inet 127.0.0.1 netmask ff000000

inet 172.26.157.11 netmask fffffe00 broadcast 172.26.157.255

# cat /usr/tmpCFG-version11.txt

!%persistent banner exec $

==

=== This is a persistent (tunnel up or down) configuration section

==

$

!%transient banner motd $

==

=== This is a transient (tunnel up only) configuration section

==

$ end

No configuration need be specified on the Easy VPN remote. The following is an example of verifying the configuration status. Obviously, the commands can also be viewed by issuing a show running-config from the console or VTY port of the remote router.

vpn-jk3-2651xm-3#show crypto ipsec client ezvpn Easy VPN Remote Phase: 6

Tunnel name : VTI_SECOND

Inside interface list: Ethernet1/0

Outside interface: Virtual-Access2 (bound to FastEthernet0/1) Current State: IPSEC_ACTIVE

Last Event: SOCKET_UP Address: 10.8.100.31 Mask: 255.255.255.255 Default Domain: cisco.com

Save Password: Allowed Split Tunnel List: 1

Address : 192.0.2.0 Mask : 255.255.255.0 Protocol : 0x0

Source Port: 0 Dest Port : 0

Configuration URL [version]: ftp://root:[email protected]//usr/tmp/CFG-version26.txt [26]

Config status: applied, Last successfully applied version: 26 Current EzVPN Peer: 192.168.136.19

The following two issues currently limit the functionality of this feature:

• CSCsc72005—EZVPN transient configuration not removed when tunnel down

• CSCsc77978—EZVPN configuration URL not applied

Verify the resolution and integration of these defects as part of the planning and implementation process before attempting to implement this feature.

Appendix C—Output for debug crypto ipsec client ezvpn Command, page 77 includes the complete output of a debug crypto ipsec client ezvpn command that shows the debug output associated with the configuration URL processing.

Configuration and Implementation

This section provides sample configurations for a basic deployment of VTI. Two branch routers are used, one with a static IP address and a second with a dynamic IP address assigned by the ISP equipment. One crypto headend router is shown; however, most customer deployments have two crypto headend routers for better availability. This example uses a PKI/CA infrastructure with two separate Cisco IOS CA servers. There is no requirement for this type of implementation, it is simply shown as an example.

Topology

The topology shown in Figure 7 is used for reference.

Figure 7 Basic Deployment Topology

VTI Configuration Overview

VTI is introduced in Cisco IOS release 12.3(14)T. To enable the VTI feature, use the tunnel protection interface command with the following new Cisco IOS interface command:

tunnel mode ipsec ipv4

A sample interface configuration is shown:

interface Tunnel0

ip unnumbered Loopback n tunnel source FastEthernet n/n tunnel destination n.n.n.n tunnel mode ipsec ipv4

tunnel protection ipsec profile VirtualTunnelInterface

The configuration example above is representative of a branch router. The crypto headend router configuration is shown later and is configured with DVTI in this guide.

QoS Configuration

The branch and headend routers use a similar QoS configuration, as follows:

!

class-map match-any VOICE match ip dscp ef

match ip dscp af41

class-map match-any CALL-SETUP match ip dscp af31

match ip dscp cs3

class-map match-any INTERNETWORK-CONTROL match ip dscp cs6

!

148745

Branch Router 10.0.84.1 vpn-jk3-2651xm-3

Enterprise Customer AS 65030

vpn-jk3-2651xm-2

Internet Service Provider

AS 65002

IP

192.168.131.39 F0/1 - Static IP

IPSec Tunnel(s)

192.168.192.0/18

192.168.131.39 Crypto

HE

Note: Second Crypto HE not

shown – however recommended Crypto

HE Branch Router

10.0.80.1

Internet Service Provider

AS 65001

IP

F0/1 - DHCP

IPSec Tunnel 192.168.128.0/18

VLAN 102 VLAN 100 IOS CA

vpn-jk3-2651xm-9

policy-map V3PN

description Voice + VT Advantage class CALL-SETUP

bandwidth percent 2 class INTERNETWORK-CONTROL bandwidth percent 5 class VOICE

priority percent 50 class class-default fair-queue

random-detect

policy-map Shaper-1544K

description 1544Kbps * .85 = 131Kbps class class-default

shape average 1310000 13100 service-policy V3PN

policy-map Shaper-768K

description 768Kbps * .85 = 652Kbps class class-default

shape average 652000 6520 service-policy V3PN

!

In the above example, note that the VOICE class matches on either DSCP value of EF or AF41. Cisco VT Advantage marks both voice and video packets with the value of AF41 during a voice and video call.

As a result, AF41 must now be included in the VOICE class.

The VOICE class priority queue is allocated as a percentage. For ease of configuration, it is advantageous to configure this as a percentage so different shapers (parent service policies) can reference the same child service policy. In a hierarchical CBWFQ configuration, the percentage is calculated on the shaped rate.

Note In the performance testing for this design chapter, the priority queue was allocated at a fixed size, 256 Kbps, because the test profile did not include any video and at most there were four concurrent G.729 voice calls.

ISAKMP DSCP Value

In past design guides, the V3PN service policy matched ISAKMP packets and included them in the INTERNETWORK-CONTROL class and optionally set the DSCP value to CS6. For example:

ip access-list extended IKE

permit udp any eq isakmp any eq isakmp

As of 12.3(4)T, this is no longer necessary on a router configured for both crypto and QoS. The ISAKMP packets are marked as INTERNETWORK CONTROL or IP Precedence 6, DSCP CS6. See the following for more detailed information:

• CSCeb18618—IKE traffic needs to be marked as Precedence 6

• CSCdz01484—IKE keepalive packets should be IP Precedence 6

For an explanation of ISAKMP (IKE) DSCP, see the Voice and Video Enabled IPsec VPN (V3PN) Design Guide at the following URL: http://www.cisco.com/go/srnd.

Trustpoints

This sample configuration uses the PKI/CA infrastructure for authentication. The branch and the headend trustpoint configuration is shown. For more information, see the Digital Certification/PKI for IPsec VPN Design Guide at the following URL: http://www.cisco.com/go/srnd.

Branch

The two branch routers are shown in Figure 8.

Figure 8 Branch Trustpoint

In the following example, CA server at 192.168.131.25 is accessible within the sample topology and the server at 172.26.179.249 IP address.

hostname vpn-jk3-2651xm-2

!

ip host ese-ios-ca 172.26.179.249 crypto pki trustpoint ese-ios-ca enrollment url http://ese-ios-ca:80 revocation-check none

auto-enroll 70

!

crypto pki certificate chain ese-ios-ca certificate 49

certificate ca 01

!

hostname vpn-jk3-2651xm-3

ip host Joe_Cisco_LAB_ca_server 192.168.131.25 crypto pki trustpoint ESE_JK_RACK

enrollment url http://Joe_Cisco_LAB_ca_server:80 revocation-check none

auto-enroll 70

crypto pki certificate chain ESE_JK_RACK certificate 08

certificate ca 01

148746

Branch Router 10.0.84.1 vpn-jk3-2651xm-3

vpn-jk3-2651xm-2

IP

Branch Router 10.0.80.1

IP

Headend

The crypto headend makes reference to both CA servers, because one branch references a different CA server than the other branch (see Figure 9).

Figure 9 Headend

These are two independent CA servers, which are referenced in the ISAKMP profile section later in this guide.

hostname vpn-jk3-2651xm-9

ip host ese-ios-ca 172.26.179.249

ip host Joe_Cisco_LAB_ca_server 192.168.131.25

!

crypto pki trustpoint ese-ios-ca enrollment url http://ese-ios-ca:80 revocation-check crl

auto-enroll 70

!

crypto pki trustpoint ESE_JK_RACK

enrollment url http://Joe_Cisco_LAB_ca_server:80 revocation-check crl

auto-enroll 70

!

crypto pki certificate chain ese-ios-ca certificate 4B

certificate ca 01

crypto pki certificate chain ESE_JK_RACK certificate 07

certificate ca 01

!

ISAKMP Policy

All branch and headend routers use a similar ISAKMP policy configuration.

! crypto isakmp policy 1 encr 3des

group 2

crypto isakmp keepalive 10

!

148747

192.168.131.39

192.168.131.39 Crypto

HE VLAN 102 VLAN 100 IOS CA

vpn-jk3-2651xm-9

IPsec Profile

The IPsec profiles always use tunnel mode. Even if a network manager were to add a “transport mode”

transform set of a higher priority, VTI would still choose tunnel mode.

!

crypto ipsec transform-set 3DES_SHA_TUNNEL esp-3des esp-sha-hmac

!

crypto ipsec profile VirtualTunnelInterface set transform-set 3DES_SHA_TUNNEL

! Headend

interface Virtual-Template[n] type tunnel

tunnel protection ipsec profile VirtualTunnelInterface

! Branch

interface Tunnel [n]

tunnel protection ipsec profile VirtualTunnelInterface

However, VTI negotiates tunnel mode in all tested configurations.

vpn-jk3-2651xm-9# show crypto ipsec sa detail | inc peer|endpt|in use current_peer 192.168.192.22 port 500

local crypto endpt.: 192.168.131.19, remote crypto endpt.: 192.168.192.22 in use settings ={Tunnel, }

in use settings ={Tunnel, } current_peer 192.168.128.198 port 500

local crypto endpt.: 192.168.131.39, remote crypto endpt.: 192.168.128.198 in use settings ={Tunnel, }

in use settings ={Tunnel, }

Headend Router Configuration

The remaining relevant crypto headend configuration is shown in this section. In Figure 10, note that this crypto headend has two outside interfaces: 192.168.131.39 and 192.168.131.19. These outside interfaces allow the branch router configuration to select the downstream shaper rate, because the crypto peer local address and the virtual template configurations reference each other.

Figure 10 Basic Configuration—Headend Addressing

148747

192.168.131.39

192.168.131.39 Crypto

HE VLAN 102 VLAN 100 IOS CA

vpn-jk3-2651xm-9