Cisco AAVID Enterprise VPN Design
Content
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
Solution Reference Network Design
Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100
Customer Order Number: 956377
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
y g y p g g Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That’s Possible, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, GigaStack, IOS, IP/TV, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries. All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0201R)
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design Copyright © 2002, Cisco Systems, Inc. All rights reserved.
C ON T E N T S
Preface Scope vii vii vii
Intended Audience
Obtaining Documentation viii World Wide Web viii Documentation CD-ROM viii Ordering Documentation viii Documentation Feedback viii Obtaining Technical Assistance ix Cisco.com ix Technical Assistance Center ix Cisco TAC Web Site x Cisco TAC Escalation Center
1
x 1-1
CHAPTER
Cisco AVVID Network Infrastructure VPN Solution Overview Site-to-Site VPN Benefits References and Reading 1-2 1-3 2-1
CHAPTER
2
Enterprise Site-to-Site IPSec VPNs Solution Overview 2-3 Starting Assumptions 2-3 Design Overview 2-3 Cisco VPN Product Overview
2-5
Solution Design Recommendations 2-6 General Design Considerations 2-7 Solution Characteristics 2-8 IPSec for Data Encryption 2-9 Implementing Generic Route Encapsulation (GRE) Ensuring High Availability and Resiliency 2-10 Head-end Load Distribution 2-11 Number of Tunnels per Device 2-12 Alternative Network Topologies 2-13 Using a Routing Protocol Across the VPN 2-13 Route Propagation Strategy 2-13
2-9
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
iii
Contents
Alternatives to Using a Routing Protocol 2-16 Layer 3 Fragmentation 2-17 Path MTU Discovery 2-18 Planning for Security 2-18 Placement of VPN Head-ends Relative to Firewall 2-18 Split Tunneling 2-19 Supporting Multicast 2-19 IPSec Interactions with Other Networking Functions 2-19 Routing Protocols 2-19 IP Addressing 2-19 Network Address Translation (NAT) and Port Address Translation (PAT) Dynamic Host Configuration Protocol (DHCP) 2-20 Service Provider Dependencies 2-20 Management 2-21 Solution Component Recommendations 2-21 Scalability Testing Methodology 2-21 Hardware-Accelerated Encryption 2-22 Head-end Devices 2-23 Sizing the Head-end 2-23 Cisco VPN Routers for Head-ends 2-26 New Cisco Head-end Products 2-27 Other Cisco Products 2-27 Branch Site Devices 2-27 Sizing the Branch Site 2-27 Cisco VPN Routers for Branch Sites 2-28 New Cisco Branch Site Products 2-29 Other Cisco Products 2-29 Network Performance/Convergence 2-29 Software Releases Evaluated 2-30 Additional Considerations for Latency-Sensitive Traffic 2-30 Quality of Service (QoS) 2-31 Pre-classification of Traffic 2-31 Lower Link Speeds 2-31 Hardware-Accelerated versus Software-Based Encryption Compressed RTP Not Supported by IPSec 2-32 Additional Service Provider Considerations 2-32 Enterprise Site-to-Site VPN Case Study 2-33 Enterprise Organization Overview 2-33 Design Considerations 2-35
2-20
2-32
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
iv
EDCS-202049
Contents
Preliminary Design Considerations 2-35 Sizing the Case Study Head-end 2-36 Sizing the Case Study Branch Sites 2-37 Tunnel Aggregation and Load Distribution 2-37 Network Layout 2-38 Configuration Discussion 2-39 IKE Policy Configuration 2-39 IPSec Transform and Protocol Configuration 2-40 Access List Configuration for Encryption 2-40 Crypto Map Configuration 2-41 Applying Crypto Maps 2-41 Dynamic Crypto Maps 2-42 Common Configuration Mistakes 2-43 ACL Mirroring Error 2-43 Peer Address Mismatch 2-43 Transform Set Mismatch 2-43 IKE Policy Mismatch 2-43
A
APPENDIX
Enterprise Site-to-Site VPN Scalability Test Configuration Scalability Testbed Network Diagram A-1 Scalability Testbed Configuration Files A-3 Head-end Configuration A-3 Branch Site Configuration A-5 High-Level IPSec Overview B-1
A-1
APPENDIX
B
Tunneling Protocols B-1 Introduction to IPSec B-1 IPSec Protocols B-2 Encapsulating Security Protocol (ESP) Authentication Header (AH) B-4 IPSec Modes B-5 Tunnel Mode B-5 Transport Mode B-6 Internet Key Exchange (IKE) B-6 Security Association (SA) B-7 IKE Phase 1 B-7 IKE Phase 2 B-7 IKE Authentication B-7 Pre-shared Keys B-7
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
B-2
v
Contents
Digital Certificates
INDEX
B-8
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
vi
EDCS-202049
Preface
This preface summarizes the following general topics:
• • • •
Scope Intended Audience Obtaining Documentation Obtaining Technical Assistance
Scope
This publication defines the comprehensive functional components required to build a Site-to-Site Enterprise Virtual Private Network (VPN) solution. Cisco Solutions Engineering is dedicated to producing high quality, tested designs that are intended to help deploy the solution product set with confidence. This publication is part of an ongoing series that addresses VPN solutions, using the latest VPN technologies from Cisco, and based on practical design principles that have been tested to scale. This publication focuses on Enterprise site-to-site Virtual Private Networks (VPN) solutions. It addresses the following solution characteristics and technologies:
• • • • • •
IP Security (IPSec) in combination with Generic Routing Encapsulation (GRE) Site-to-site VPN topologies Cisco VPN routers running Cisco Internetwork Operating System (Cisco IOS) Use of Enhanced Interior Gateway Routing Protocol (EIGRP) as a routing protocol across the VPN Data as the primary traffic component Evaluation of Cisco VPN product performance in scalable and resilient designs
Intended Audience
This document covers site-to-site VPN design, planning, and implementation in Enterprise environments. Intended audiences include:
• •
Cisco Systems Engineers (SEs) and Customer Support Engineers (CSEs) Customer and partner network designers, architects, and managers
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
vii
Preface Obtaining Documentation
Obtaining Documentation
The following sections explain how to obtain documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following URL: http://www.cisco.com Translated documentation is available at the following URL: http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.
Ordering Documentation
Cisco documentation is available in the following ways:
•
Registered Cisco Direct Customers can order Cisco product documentation from the Networking Products MarketPlace: http://www.cisco.com/cgi-bin/order/order_root.pl Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store: http://www.cisco.com/go/subscription Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
•
•
Documentation Feedback
If you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click Leave Feedback at the bottom of the Cisco Documentation home page. After you complete the form, print it out and fax it to Cisco at 408 527-0730. You can e-mail your comments to [email protected].
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
viii
EDCS-202049
Preface Obtaining Technical Assistance
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address: Cisco Systems Attn: Document Resource Connection 170 West Tasman Drive San Jose, CA 95134-9883 We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world. Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to
• • • • •
Streamline business processes and improve productivity Resolve technical issues with online support Download and test software packages Order Cisco learning materials and merchandise Register for online skill assessment, training, and certification programs
You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL: http://www.cisco.com
Technical Assistance Center
The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center. Inquiries to Cisco TAC are categorized according to the urgency of the issue:
• •
Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration. Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
ix
Preface Obtaining Technical Assistance
• •
Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available. Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.
Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.
Cisco TAC Web Site
The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL: http://www.cisco.com/tac All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register: http://www.cisco.com/register/ If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL: http://www.cisco.com/tac/caseopen If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case. To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL: http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
x
EDCS-202049
C H A P T E R
1
Cisco AVVID Network Infrastructure VPN Solution Overview
This publication identifies the functional requirements to build Cisco AVVID Network Infrastructure (Cisco AVVID NI) Virtual Private Network (VPN) solutions. It identifies individual hardware components and their interconnections, software features, management needs, and service provider (SP) dependencies necessary to facilitate deployment of a manageable and maintainable enterprise VPN solution. This chapter presents benefits and background information as a context for the design recommendations presented in subsequent chapters.
Note
This release of Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design focuses on enterprise site-to-site implementation considerations. Information will be integrated emphasizing other elements of VPN solutions as appropriate. The design scheme presented is based on the Cisco SAFE VPN Architecture. This publication is intended to provide an additional level of information on how to deploy Cisco SAFE VPN. The reader should first be familiar with the Cisco SAFE VPN White Paper. Cisco SAFE documentation can be found at the following URL: http://www.cisco.com/go/safe As an introduction to site-to-site VPN, this chapter presents the following specific topics:
• •
Site-to-Site VPN Benefits References and Reading
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
1-1
Chapter 1 Site-to-Site VPN Benefits
Cisco AVVID Network Infrastructure VPN Solution Overview
Site-to-Site VPN Benefits
This solution design offers a number of advantages over competing approaches to deploying site-to-site VPNs. Table 1-1 summarizes primary benefits of deploying the solution described in this publication.
Table 1-1 VPN Solution Benefits Summary
Solution Design Criteria
Security
VPN Benefits Traffic between branch offices and the central site is encrypted using Triple Data Encryption Standard (Triple DES). A level of redundancy is provided at the head-end, such that the design can tolerate a complete failure of a head-end and recover quickly. A dynamic routing protocol, such as Enhanced Internet Gateway Routing Protocol (EIGRP), can be used to manage network routing and provide fast convergence.
High Availability
Scalability
A building-block approach to scalability is used, such that the design can support thousands of branch-offices, limited only by the number of head-end devices deployed. Scalability testing verified performance with up to 240 branches per head-end device.
Flexibility
Cisco VPN router product line allows customization of head-end and branch office routers. Permits deployment of hardware-accelerated or software-supported encryption. Use of hardware-accelerated encryption is highly recommended. With generic routing encapsulation (GRE), it is possible to build a VPN network that can handle diverse network traffic requirements, including multicast, multi-protocol, and network-layer routing.
Reducing Costs
Many VPN services offer the Enterprise some level of cost reduction.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
1-2
EDCS-202049
Chapter 1
Cisco AVVID Network Infrastructure VPN Solution Overview References and Reading
References and Reading
Table 1-2 and Table 1-3 provide references to related publications relevant when considering VPN deployment.
Table 1-2 Request For Comment (RFC) Papers
RFC RFC2401 RFC2402 RFC2403 RFC2404 RFC2405 RFC2406 RFC2407 RFC2408 RFC2409 RFC2410 RFC2411 RFC2412
Topic Security Architecture for the Internet Protocol IP Authentication Header The Use of HMAC-MD5-96 within ESP and AH The Use of HMAC-SHA-1-96 within ESP and AH The ESP DES-CBC Cipher Algorithm With Explicit IV IP Encapsulating Security Payload (ESP) The Internet IP Security Domain of Interpretation for ISAKMP Internet and Key Management Protocol (ISAKMP) The Internet Key Exchange (IKE) The NULL Encryption Algorithm and Its Use With IPsec IP Security Document Roadmap The OAKLEY Key Determination Protocol
Table 1-3
Related Enterprise VPN Websites
Topic Enterprise VPNs Cisco SAFE Blueprint Cisco Network Security Cisco AVVID Partner Program Cisco VPN Product Documentation Download VPN Software from CCO Improving Security on Cisco Routers
Link http://www.cisco.com/go/evpn http://www.cisco.com/go/safe http://www.cisco.com/go/security http://www.cisco.com/go/securityassociates http://www.cisco.com/univercd/cc/td/doc/product/vpn/ http://www.cisco.com/kobayashi/sw-center/sw-vpn.shtml http://www.cisco.com/warp/public/707/21.html
Essential Cisco IOS Features Every ISP http://www.cisco.com/warp/public/707/EssentialIOSfeatures_pdf.zip Should Consider Increasing Security on IP Networks Cisco TAC Security Technical Tips IP Security (IPSec) Support Page Networking Professionals Connection http://www.cisco.com/cpress/cc/td/cpress/ccie/ndcs798/nd2016.htm http://www.cisco.com/warp/public/707/ http://www.cisco.com/cgi-bin/Support/PSP/psp_view.pl?p=Internetworking:IPSec http://forums.cisco.com
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
1-3
Chapter 1 References and Reading
Cisco AVVID Network Infrastructure VPN Solution Overview
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
1-4
EDCS-202049
C H A P T E R
2
Enterprise Site-to-Site IPSec VPNs
This chapter addresses network design considerations to deploy a site-to-site virtual private network (VPN) based on IP Security (IPSec). Content here focuses on Cisco IOS VPN router products. This publication defines a specific VPN design including a level of resiliency and support for multi-protocols. The design presented is conservative, with an emphasis on engineering a well-performing VPN based on verified parameters. The performance data presented is specific to this design. Other designs are possible and may yield higher or lower performance. The primary topology discussed is a hub-and-spoke deployment model, where the primary enterprise resources are located in a large central site, with a number of smaller sites or branch offices connected directly to the central site over a VPN. A high-level diagram of the network topology is shown in Figure 2-1.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-1
Chapter 2
Enterprise Site-to-Site IPSec VPNs
Figure 2-1
Hub-and-Spoke VPN
Medium sized branches
Central site
Internet
Smaller branches
Corporate network
Large branches
This chapter addresses enterprise site-to-site VPN design in the following sections:
• • • • • •
“Solution Overview” section on page 2-3 “Solution Design Recommendations” section on page 2-6 “Solution Component Recommendations” section on page 2-21 “Additional Considerations for Latency-Sensitive Traffic” section on page 2-30 “Enterprise Site-to-Site VPN Case Study” section on page 2-33 “Configuration Discussion” section on page 2-39
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-2
74167
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Overview
Solution Overview
This section provides an overview of the site-to-site VPN design topology and characteristics:
• • •
Starting Assumptions Design Overview General Design Considerations
Starting Assumptions
The design approach presented in this publication makes several starting assumptions:
• • •
The design supports a typical data traffic profile. Using the VPN for transport of IP telephony and video is not covered in this version of the publication. High availability and resiliency after failover are critically important, therefore the recommendations in this publication reflect the benefits of built-in resiliency and failover with fast convergence. It is assumed that the network has a need for diverse traffic requirements, such as IP multicast, multi-protocol, and/or support for routing. Cisco products in this publication are maintained at conservative CPU utilization levels. While costs were certainly considered, the design recommendations assume that the customer will deploy current VPN technologies, including hardware-accelerated encryption. 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 also valuable for Service Provider (SP)-managed VPNs.
• • • •
Design Overview
VPNs have many applications, including extending reachability of an enterprise WAN, or replacing classic WAN technologies like Leased Line, Frame Relay (FR), and Asynchronous Transfer Mode (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 multi-protocol support, 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 serving as VPN head-end termination devices at a central campus (head-end devices) Cisco VPN access routers serving as VPN branch-end termination devices at branch office locations (branch-end devices) IPSec and GRE tunnels that interconnect the head-end and branch-end devices in the VPN Internet services procured from a third-party ISP (or ISPs) serving as the WAN interconnection medium
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-3
Chapter 2 Solution Overview
Enterprise Site-to-Site IPSec VPNs
Cisco VPN routers are a good choice for site-to-site VPN deployments because they can accommodate most any network requirement inherited from the frame relay or private line network, such as support for multicast and latency-sensitive traffic, routing for resiliency, and support for non-IP protocols like IPX or SNA. The network topology used to illustrate this design is shown below in Figure 2-2.
Figure 2-2 VPN Solution Network Topology
Central site Branch offices
Primary ISP
Secondary ISP Corporate network
IP Connectivity VPN Tunnel
The solution is a hub-and-spoke network with multiple head-end devices for resiliency. Head-ends are high-end tunnel aggregation routers servicing multiple IPSec/GRE tunnels for a prescribed number of branch office locations. In addition to terminating the VPN tunnels at the central site, the head-ends together act as the distribution point for all routing information to and from branch-end devices. Branch-ends are typically access routers that provide IPSec/GRE tunnel(s) for the branch office locations to the central site. In addition to terminating the VPN tunnels, the branch-end often provides WAN access and in some implementations can serve as a firewall. To ensure authentication and encryption, IPSec tunnels are provisioned to interconnect branch offices to the central site. In order to provide a resilient network, this design implements a routing protocol across the VPN. Since IPSec does not provide the ability to run protocols requiring IP multicast—such as Enhanced Interior Gateway Routing Protocol (EIGRP)—IPSec is used in conjunction with GRE. GRE also provides the ability for the customer to support more diverse traffic across the VPN, including IP multicast and non-IP protocols. For high-availability in the case of a failure, each branch-end access router should have two IPSec/GRE tunnels, a primary and secondary, provisioned to two different head-end tunnel aggregation routers.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-4
74168
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Overview
There are several Service Provider (SP) options available to enterprise customers today for deploying a VPN, including the enterprise owning and managing the VPN, seeking only Internet service from ISPs. Optionally an enterprise can outsource its VPN to a SP. In general, the architecture and recommendations provided in this publication are valid for either VPN deployment option— differing only in terms of edge VPN equipment ownership. This publication supports a wide variety of alternatives for deploying a flexible VPN solution that can respond to changing customer requirements. However, the scale of deployment will affect products selected and the configuration difficulty.
Cisco VPN Product Overview
The implementation presented in this publication is focused on using Cisco VPN router products in IPSec-based VPN applications. Table 2-1 provides a summary of the recommended deployment of Cisco VPN router product families to the different head-end and branch-office applications.
Table 2-1 Cisco VPN Product Applications Summary
Application
Central Head-End Site
VPN Router Family Cisco 7200 Cisco 7100 Cisco 3600
VPN Acceleration Options ISA (single or dual), VAM ISM (single or dual), VAM
Maximum Performance1 Up to 140 Mbps Up to 140 Mbps
Scalability Traffic Mix Performance 2 Up to 40 Mbps3 Up to 30 Mbps4 Up to 16 Mbps Up to 16 Mbps Up to 3 Mbps Up to 16 Mbps Up to 3 Mbps Up to 2.5 Mbps Up to 2.5 Mbps Up to 100 kbps
AIM (Base, Medium, High Perform) Up to 38 Mbps AIM (Base, Medium, High Perform) Up to 38 Mbps AIM (Base, Extended Perform) AIM (Base, Extended Perform) VPN Module VPN Module Not Available Up to 14 Mbps Up to 14 Mbps Up to 3 Mbps Up to 3 Mbps Up to 384 kbps AIM (Base, Medium, High Perform) Up to 38 Mbps
Large Branch Office
Cisco 3600 Cisco 2600 Cisco 3600 Cisco 2600 Cisco 1700
Medium Branch Office
Small Office
Cisco 1700 Cisco 800
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and single IPSec/GRE tunnel. 2. Scalability traffic mix evaluation performed with mixed packet sizes, 55 to 65 percent CPU utilization, and up to 240 IPSec/GRE tunnels (in head-end case). 3. This is single ISA performance only. VAM performance with scalability traffic mix is currently under evaluation and will be published in a later revision of this publication. 4. This is single ISM performance only. VAM performance with scalability traffic mix is currently under evaluation and will be published in a later revision of this publication.
A number of new Cisco VPN router products were not available at the time of the scalability testing performed with the design presented in this publication. These include the Cisco 7400, Cisco 3745, Cisco 3725, and Cisco 1760 VPN routers. Refer to the section titled “New Cisco Head-end Products” section on page 2-27 and “New Cisco Branch Site Products” section on page 2-29 for more information. Additional Cisco VPN products, such as the Cisco PIX series and Cisco VPN 3000 Concentrator series, will be included in this publication in a future version.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-5
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Solution Design Recommendations
In designing a VPN deployment, it is essential to integrate broader design considerations, such as high availability and resiliency, security, and potentially quality of service (QoS). This section starts with an overview of some general design considerations that need to be factored into the design. This is followed by a summary of design recommendations, and then additional detailed sections on these recommendations as required. This section presents these considerations in the following specific sections:
• • • • • • • • • • • •
General Design Considerations Solution Characteristics IPSec for Data Encryption Implementing Generic Route Encapsulation (GRE) Ensuring High Availability and Resiliency Using a Routing Protocol Across the VPN Layer 3 Fragmentation Planning for Security Supporting Multicast IPSec Interactions with Other Networking Functions Service Provider Dependencies Management
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-6
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
General Design Considerations
Table 2-2 characterizes the general factors to consider when deploying a site-to-site VPN. Keep in mind that this publication provides general design considerations. Each customer’s network can require customization due to customer-specific requirements.
Table 2-2 General Site-to-site VPN Deployment Considerations
Solution Design Criteria
Network Profile
Solution Question What applications are expected to run over the VPN?
VPN Design Relevance The recommendations in this publication focus on data applications. Multi-service applications such as IP Telephony and video require additional design considerations, such as QoS.
Is multicast and/or IPSec only supports tunneling of unicast-IP traffic. multi-protocol support required? Multicast-IP is required to run a routing protocol across the VPN and to support applications like video. GRE is used in conjunction with IPSec to support multicast and multi-protocols. Does packet fragmentation need In some customer networks, the VPN design needs to to be considered in the design? consider the amount of fragmentation that may occur.
Scalability
How many branches are expected to be aggregated to each central site?
The number of branch offices, plus the amount of traffic expected from each branch, determines how many head-end aggregation devices are required. Improper aggregation can result in a VPN with unacceptable performance. The traffic throughput to/from branches has a direct impact on the number of branches that should be aggregated by a head-end device. If not properly considered, the resulting VPN design can have unacceptable performance. As in the case of a typical enterprise network, a VPN must be resilient to recover in the event of a failure. The design discussed in this guide assumes a customer requires redundancy at the central site that allows for failover between head-end devices. Different methods of IKE authentication necessitate different levels of implementation complexity. For example, configuring pre-shared keys is the least complex method, however scalability can be an issue. Similarly, use of Certificates is highly scalable, yet they are more complex to deploy. VPNs can be deployed with dedicated function devices or as multiple function devices, providing WAN access, firewall, and VPN services.
What is the expected traffic throughput between branch offices and the central site?
Resiliency
What are the expectations for resiliency?
Security
What type of Internet Key Exchange (IKE) authentication method will be implemented?
Services
What other services will run on the device?
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-7
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Solution Characteristics
Table 2-3 summarizes the best practices for deployment of an enterprise site-to-site IPSec-based VPN.
Table 2-3 Enterprise Site-to-site IPsec-based VPN Best Practice Summary
Deployment Objective
Designing the VPN
Best Practice Summary Use IPSec (Tunnel Mode) with Triple Data Encryption Standard (Triple DES) for encryption of data transported1. See “IPSec for Data Encryption” section on page 2-9 for more information. Use GRE tunnels so that multi-service protocols, such as multicast IP, and routing protocols, such as EIGRP, are supported. See “Implementing Generic Route Encapsulation (GRE)” section on page 2-9 for more information. Even if multi-protocol support is not a current requirement, designing the VPN for future flexibility might prevent disruptive redesigns in the future. Configure two tunnels (primary and secondary) between each branch-end to different head-end devices for failover resiliency. See “Ensuring High Availability and Resiliency” section on page 2-10 for tunnel architecture recommendations. Run a routing protocol with route summarization for dynamic routing. See “Using a Routing Protocol Across the VPN” section on page 2-13 for more information. Don’t use IKE keepalives. This is not necessary due to the use of a routing protocol. Keep IPSec packet fragmentation at a minimum on the customer network. See “Layer 3 Fragmentation” section on page 2-17 for several mitigation strategies. Consider the interactions of IPSec with other networking functions. See “IPSec Interactions with Other Networking Functions” section on page 2-19 for more information.
Selecting Cisco VPN Products
Deploy hardware-accelerated encryption in all products that support it. See “Hardware-Accelerated Encryption” section on page 2-22 for more information. Calculate the number of head-end devices based on total tunnel and throughput aggregation requirements, as well as to handle failover. See “Sizing the Head-end” section on page 2-23 for recommendations on choosing the number of head-end devices. Select Cisco VPN Router products at the head-end based on:
• • •
Number of tunnels aggregated (scalability testing has verified performance up to 240 branches per head-end). Throughput aggregated up to the maximum recommendations for each product. Maintaining CPU utilization below 50 percent.
See “Sizing the Head-end” section on page 2-23 for head-end product recommendations. Select Cisco VPN Router products at the branch offices based on the need to maintain:
• • •
Throughput up to the maximum recommendations for each product Maintaining CPU utilization below 65 percent See “Sizing the Branch Site” section on page 2-27 for branch product recommendations.
Use at least the minimum levels of Cisco IOS software as indicated in “Software Releases Evaluated” section on page 2-30.
1. There are various laws and restrictions that govern domestic and international use and export of encryption technology.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-8
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Additional detailed information on these recommendations is discussed in the sections that follow, as required.
IPSec for Data Encryption
There are three elements to consider when securing the traffic which flows over the VPN:
• • •
Authentication—Ensuring the senders/receivers of traffic are known, valid entities Confidentiality—Encrypting data to render it imperceptible without the proper key Message Integrity—Identifying when data has been modified
To ensure confidentiality of data transported over the VPN, encryption algorithms such as Data Encryption Standard (DES) or Triple DES are implemented. Since Triple DES is more secure, it should be implemented if at all possible, except in cases where export restrictions limit the implementation to DES. To ensure message integrity, the IPSec protocol is used with a hash method, such as Message Digest 5 (MD5) or Secure Hash Algorithm 1 (SHA-1).
Note
It is possible to implement only a hash method or only an encryption standard to secure the VPN. However, it is highly recommended that both be implemented in combination. In this publication, the combination of Triple DES and SHA-1 is recommended. With hardware-accelerated encryption implemented, performance is not significantly affected by choice of encryption method. In the future, Advanced Encryption Standard (AES) will be another option for encryption of data. Pre-shared keys were used in the evaluations for this publication. Use of Digital Certificates will be addressed in a future version
Implementing Generic Route Encapsulation (GRE)
While IPSec provides a secure method for tunneling data across an IP network, it has several limitations. First, IPSec does not support broadcast or multicast IP which prevents the use of protocols that rely on their underlying features—such as routing protocols. Second, IPSec does not support the use of multi-protocol traffic, such as IPX or SNA. To overcome these limitations, implement GRE tunnels. GRE is a protocol that can be used to carry other passenger protocols, such as unicast, broadcast or multicast IP, as well as non-IP protocols. This is shown in Figure 2-3.
Figure 2-3 GRE as a Carrier Protocol of IP
IP Transport protocol
GRE Carrier protocol
Network packet Passenger protocol
74173
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-9
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Using GRE tunnels in conjunction with IPSec extends the functionality of the VPN, so that multicast IP can be supported on the network. This provides a critical element of the solution defined in this publication. It enables the ability to run a routing protocol across the network between the central site and branch offices. Even if requirements such as multicast IP, non-IP protocols, or supporting routing protocols do not exist in the current customer network, designing the VPN for greater flexibility prevents costly and potentially disruptive re-designs if these capabilities become requirements in the future. In a GRE-based environment, all traffic between sites is encapsulated in a GRE packet prior to the encryption process. This simplifies the access list used in the crypto map statements since it requires only one line permitting GRE (IP Protocol 47).
Ensuring High Availability and Resiliency
Data networks are often deployed as best effort networks. In such an arrangement, there is no guaranteed network performance and frequently such networks are deployed with single points of failure. With applications being increasingly dependent on network services, networks must be designed to behave in a much more predictable manner. This includes recovery from failures within specific timeframes and the ability to transport the packets to their destination with specific and repeatable (minimized) delays. In all cases, networks should be designed so that the individual elements that make up the network are operating in a resilient environment. These elements include network devices—such as routers and switches—as well as the LAN and WAN links that connect these devices together. In order to provide greater resiliency in the VPN design, Cisco recommends that two tunnels be configured—a primary and secondary—between each branch-end device and the head-ends. Under normal operating conditions, both the primary and secondary tunnels are established. The routing protocol—such as EIGRP—maintains both routes, with the secondary tunnel configured as a less preferred route. Figure 2-4 illustrates this configuration.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-10
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Figure 2-4
High-Availability Tunnel Configuration
Central site
VPN Head-ends
WAN interface router
Branch office
Internet
Primary Secondary
Corporate network
If a failure occurs at one of the head-end devices, the routing protocol detects that the route through the primary tunnel is no longer valid, and after convergence the route through the secondary tunnel is used. Once the primary is available again, traffic will be routed back to the primary tunnel as it is the preferred route in the routing metrics. The head-end resiliency design presented here allows for failure of a single head-end device, with proper failover to surviving head-ends. This is normally adequate when the number of head-ends is relatively low (such as ten or less). If the number of head-ends is relatively high (such as twenty or more), consider designing for the possibility of multiple head-end device failures. It might also be necessary to have head-end devices geographically dispersed. Although not specifically tested, the architecture presented in this publication should readily support this configuration. More information regarding this architecture is also discussed in the Cisco SAFE VPN White Paper. Cisco SAFE documentation can be found at the following URL: http://www.cisco.com/go/safe Configuration of primary and secondary tunnels to appropriate head-ends is critical to maintain network resiliency.
Head-end Load Distribution
When laying out the network topology, be sure to consider load balancing across multiple head-end devices—especially in the case of a head-end device failure. This design recommends at least two tunnels configured between a branch device and the head-end. These guidelines should be followed:
• • •
The primary tunnels should be configured to carry traffic under normal circumstances. The preferred primary tunnels should be evenly divided among the head-end devices. Secondary tunnels should be configured with a delay command statement to make the primary the preferred tunnel route.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-11
74174
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
•
The secondary tunnels for branches should be evenly spread among the remaining (surviving) head-end devices. It would be highly undesirable for all the tunnels from a failed head-end device to re-establish to a single secondary head-end device when there are other devices available to distribute the load from the failed device. Figure 2-5 illustrates a typical network topology with high resiliency.
Figure 2-5
Tunnel Aggregation for Resiliency
Head-end devices
Primary Tunnels Secondary Tunnels
Branch office devices
To plan for proper tunnel aggregation and load distribution in the case of a head-end device failure, the following algorithm should be used:
1. 2. 3. 4. 5.
Start with the number of total branch devices to be aggregated at the head-end. Divide this number by the number of head-end devices. Multiply the result by two for primary and secondary tunnels. This is the total number of tunnels per head-end device. Allocate the primary tunnels to each head-end device in the arrangement shown in Figure 2-5. For each group, allocate the secondary tunnels in a round-robin fashion to all head-end devices except the one serving as a primary for that group. This arrangement is also shown in Figure 2-5 above.
Please note that this calculation should take into account the amount of traffic being aggregated. Adjustments might be necessary to account for tunnel throughput variances.
Number of Tunnels per Device
The number of tunnels required for each head-end device should be scaled to the overall size of the network in which the VPN solution is being deployed. Please refer to “Sizing the Head-end” section on page 2-23 for more information.
Note
In testing the design presented in this publication, head-end scalability testing did not include an exhaustive evaluation of the maximum number of tunnels that may be terminated to head-end devices. In addition, scalability testing of branch site devices was performed with two tunnels per branch device and did not include exhaustive testing of the number of tunnels these different platforms can support.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-12
74175
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Alternative Network Topologies
The design presented in this publication is a typical hub-and-spoke topology. Other possible topologies include partially meshed and fully meshed networks. While these alternative topologies can be implemented in an IPSec VPN, they can increase the complexity of the design and configuration due to the number of peers per device in such a network. For example, the larger number of active tunnels per peer in a meshed network places a greater performance burden on devices running IPSec—possibly requiring more CPU and memory resources. The configuration of these devices also becomes more complex. At a minimum, an additional access list must be created for each peer connection, as well as additional crypto map entries. A new feature named Dynamic Multipoint VPN (mGRE+NHRP) will make such configurations easier in the future. In addition, the routing protocol (as is recommended in this publication) must deal with many more adjacencies, nullifying efficiencies associated with routing protocols, such as summarization and stub features. A fully meshed and partially meshed topology are possible, but like any network, these deployments should be carefully designed and tested prior to roll out. Partial- and full-mesh topologies have not been subjected to scalability testing for this publication.
Using a Routing Protocol Across the VPN
This design recommends the use of a routing protocol to propagate routes from the head-end to the branch offices. Using a routing protocol has several advantages over the current mechanisms in IPSec alone:
•
VPN receives the same benefit as using routing protocols on a traditional network—this includes receiving information about the network connectivity available over a particular interface, topology information about a network, notification when that topology changes (such as when a link fails), and information about the status of remote peers. While there are alternatives to using a routing protocol, most of these alternatives only offer the ability to verify the health of the VPN device. With a routing protocol, it is possible to verify that traffic is actually reaching its destination.
•
There are several routing protocols that are candidates for operation over the VPN, including EIGRP and Open Shortest Path First (OSPF). The principles presented in this publication use EIGRP as the routing protocol, as EIGRP was used during scalability tests conducted. EIGRP was selected due to its conservative use of router CPU and network bandwidth as well as its quick convergence. EIGRP also provides a range of options for address summarization and default route propagation. Routing protocols do increase the CPU utilization on a network device and their use must be taken into consideration when sizing those devices.
Route Propagation Strategy
There are a number of approaches to propagating routes from the head-end to the branch offices. For this design, the recommended approach is for each head-end router to advertise a default route to each of the terminated tunnels. The branch router will prefer the primary tunnel via a lower routing metric for the primary path. Consider the example topology illustrated in Figure 2-6.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-13
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Figure 2-6
Route Propagation Example
Central site
VPN Head-ends 131.108.251.2 Primary Secondary 131.108.252.2 Internet 131.108.153.2
Branch office
10.57.2.0
10.63.223.0
74603
In the example illustrated in Figure 2-6, the ISP has assigned public IP addresses 131.108.251.2 and 131.108.252.2 for our central site head ends and 131.108.153.2 for our branch office. The corporate LAN at the central site is privately addressed as network 10.57.2.0, while the branch office LAN is privately addressed as network 10.63.223.0. The configuration excerpts presented in the following sections would be used to establish appropriate tunnels and routing (assuming EIGRP as the routing protocol).
Head-end Router (Primary) Configuration Excerpt
interface Tunnel151 ip address 10.62.223.193 255.255.255.252 ip summary-address eigrp 1 10.0.0.0 255.0.0.0 5 tunnel source FastEthernet1/0 tunnel destination 131.108.153.2 crypto map static-map ! interface FastEthernet1/0 ip address 131.108.251.2 255.255.255.252 duplex full speed 100 crypto map static-map ! interface FastEthernet1/1 description FastEthernet1/1 ip address 10.57.2.1 255.255.255.0 duplex full speed 100 ! router eigrp 1 network 10.0.0.0 no auto-summary eigrp log-neighbor-changes ! ip route 0.0.0.0 0.0.0.0 131.108.251.1
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-14
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Head-end Router (Secondary) Configuration Excerpt
interface Tunnel151 ip address 10.62.223.197 255.255.255.252 ip summary-address eigrp 1 10.0.0.0 255.0.0.0 5 delay 60000 tunnel source FastEthernet1/0 tunnel destination 131.108.153.2 crypto map static-map ! interface FastEthernet1/0 ip address 131.108.252.2 255.255.255.252 duplex full speed 100 crypto map static-map ! interface FastEthernet1/1 description FastEthernet1/1 ip address 10.57.2.2 255.255.255.0 duplex full speed 100 ! router eigrp 1 network 10.0.0.0 no auto-summary eigrp log-neighbor-changes ! ip route 0.0.0.0 0.0.0.0 131.108.252.1
Branch Site Router Configuration Excerpt
Branch Site Router interface Tunnel0 ip address 10.62.223.194 255.255.255.252 ip summary-address eigrp 1 10.62.233.0 255.255.255.0 5 tunnel source Serial0/0 tunnel destination 131.108.251.2 crypto map static-map ! interface Tunnel1 ip address 10.62.223.198 255.255.255.252 ip summary-address eigrp 1 10.62.233.0 255.255.255.0 5 delay 60000 tunnel source Serial0/0 tunnel destination 131.108.252.2 crypto map static-map ! interface Serial0/0 ip address 131.108.153.2 255.255.255.252 crypto map static-map ! interface Ethernet0 ip address 10.63.223.1 255.255.255.0 ! router eigrp 1 network 10.0.0.0 no auto-summary eigrp log-neighbor-changes ! ip route 0.0.0.0 0.0.0.0 Serial0/0
IPSec/GRE tunnels are established using the public IP addresses as the tunnel sources and destinations. The central site advertises a route for 10.0.0.0/8 to the branch office. The branch advertises a more specific route for 10.62.233.0/24 to each head-end (primary and secondary).
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-15
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Note that the branch office VPN router is configured with two tunnels—one to its assigned primary head-end and one to its secondary (backup) head-end. The delay statement is used to slightly differentiate the cost of the two routes, making the primary head-end the preferred route. The delay statement must be applied on both the branch and head-end sides of the secondary tunnel. A default route is also configured with the next hop address of the ISP. This is required in order for the tunnel to be established. Once active, the more specific routes provided by dynamic EIGRP routing will be used to actually route traffic to the appropriate VPN tunnel. This example is intended to represent a fairly simple case with a single central site location and single connection to the ISP. Depending on a variety of variables—such as the specific network topology, connections to an ISP, the use of multiple central sites, and/or the use of multiple ISP connections—the routing strategy might require additional analysis and planning. For additional configuration issues, refer to “Configuration Discussion” section on page 2-39.
Alternatives to Using a Routing Protocol
For this publication, the approach recommended is the use of a routing protocol to propagate routes and network state information between the central site and branch locations. There are several alternatives to this approach:
• • •
IKE Keepalives Dead Peer Detection (DPD) Reverse Route Injection
These alternatives are useful to consider because, if an IPSec peer fails, the other peer can continue sending packets to that peer until the Security Association (SA) associated with that peer times out. To avoid this black hole effect some sort of status update is needed. Each of the three alternative to a routing protocol solution is discussed briefly in the sections that follow.
IKE Keepalives
IKE keepalives work by sending keepalive messages between IPSec peers whether or not a particular peer has had any communications with its remote peer. The resulting messages and counters cause significantly higher CPU utilization on IPSec devices, lowering the potential scalability. Using IKE keepalives is therefore not recommended in this solution design.
Note
The use of IKE Keepalives has not been evaluated for scalability as of this publication.
Dead Peer Detection (DPD)
Dead Peer Detection (DPD) is a relatively new Cisco IOS feature—targeted at providing efficient IPSec peer state detection—as a better alternative to IKE Keepalives. DPD works by sending keepalive messages to active IPSec peers that it has not received a message from within a specified period of time. This results in a lower impact on the CPU utilization of the IPSec device and corresponding higher potential scalability.
Note
The use of IPSec DPD has not been evaluated for scalability as of this publication.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-16
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Reverse Route Injection
Another relatively new Cisco IOS feature is Reverse Route Injection. Reverse Route Injection functions by taking the information derived from the negotiated IPSec SA's and injecting that information into the routing protocol running on a particular router. This reduces the need to have a routing protocol running across the actual VPN tunnels themselves. One of the limitations of Reverse Route Injection is that it will only inject information derived from the negotiated IPSec SAs. Any networks present that are not included in the access control list (ACL) that is used for the IPSec policy would not be present in the injected routes. As an example, consider an environment in which multiple networks are present behind a router functioning as the VPN termination device. Each network must be specifically called out in the ACL included in the crypto map statement if the networks are not summarized by that ACL. Another example is the use of GRE tunnels for support of other protocols (such as multicast IP). The ACL specified in the crypto map only lists the IP address of the GRE interface and the SA is not carrying information about the network traffic carried inside the GRE tunnel.
Note
The use of IPSec Reverse Route Injection has not been evaluated for scalability as of this publication.
Layer 3 Fragmentation
IPSec and GRE headers increase the size of packets being transported, as illustrated in Figure 2-7. If the size of a packet before encryption is near the Maximum Transmission Unit (MTU) of the transmission media, the encrypted packet with the additional IPsec and GRE headers can exceed the MTU of the transmitting interface.
Figure 2-7 IPSec/GRE Packet Expansion
IP packet
IP Hdr 20 bytes
Data Large
GRE added
New IP Hdr 20 bytes
GRE 4 bytes
IP Hdr 20 bytes
Data Large
IPSec added (tunnel mode)
New IP Hdr 20 bytes
IPSec 32 bytes variable
New IP Hdr 20 bytes
GRE 4 bytes
IP Hdr 20 bytes
Data Large
74176
MTU size
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-17
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
This resulting Layer 3 packet fragmentation requires these packets to be reassembled prior to the de-cryption process. In Cisco IOS implementations prior to 12.1(11)E and 12.2(12)T, for some customer networks this resulted in less than optimal throughput performance. This is avoided by either:
1. 2.
Employing path MTU discovery (PMTU discovery). See “Path MTU Discovery” section on page 2-18 for more information on this method. Setting the MTU of attached workstations to allow for packet expansion, such as 1400 bytes.
For some customer networks, it might not be possible to easily manage MTU size. For these situations, Cisco has implemented Pre-fragmentation for IPSec VPNs. This feature is available in Cisco IOS 12.1(11)E for head-end platforms and 12.2(12)T for branch platforms.
Path MTU Discovery
A feature of IP called path MTU discovery can eliminate the possibility of fragmentation if it is supported by the end stations. This is a procedure that is run between two end stations with the participation of the network devices between them. During path MTU discovery, an MTU-sized packet is sent out by an end station with the don't fragment (DF) bit set. If this packet encounters a link with a lower MTU than the packet size, an ICMP error message is generated with a value of 3 in the type field (destination unreachable), a value of 4 in the code field (fragmentation needed and DF set) and the next hop’s MTU size in the unused field of the ICMP header. In order for this process to work over an IPSec network with GRE, the GRE tunnel MTU should be set to a value low enough to ensure that the packet will make it through the encryption process without exceeding the MTU on the outbound interface—usually 1400 bytes.
Planning for Security
In planning for deployment of a site-to-site VPN topology, it is necessary to consider the integration of enterprise network security functions. There are various enterprise security components that complement and enhance the VPN solution. For more information on how to integrate these essential security components, please refer to the Cisco SAFE security blueprint and seminar series. Cisco SAFE documentation can be found at this URL: http://www.cisco.com/go/safe
Placement of VPN Head-ends Relative to Firewall
The placement of the VPN head-end devices in the network relative to the enterprise’s firewall can critically affect the security of any VPN deployment. Recommended architectures are discussed in the Cisco SAFE VPN White Paper. Cisco SAFE documentation can be found at this URL: http://www.cisco.com/go/safe
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-18
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Split Tunneling
Split tunneling is the process by which packets being transmitted from a site can be either protected by IPSec or unprotected, depending upon their destination. When split tunneling is configured for a branch site, that site must be protected by a stateful firewall.
Note
Split tunneling has not been addressed within this design.
Supporting Multicast
The popularity of multimedia applications, such as video, has led many network administrators to support multicast traffic on their networks. VPNs can also support these applications. IPSec supports only tunneling of unicast IP traffic; therefore, it is necessary to implement GRE in conjunction with IPSec to support multicast. See “Implementing Generic Route Encapsulation (GRE)” section on page 2-9 for more information.
Note
Multicast traffic is not currently supported by most firewalls. This would require the termination of the IPSec tunnels on the inside interface of the firewall.
IPSec Interactions with Other Networking Functions
Because IPSec hides the packet and increases the packet size, interactions with other networking functions must be taken into consideration. The following sections discuss various aspects to consider when deploying site-to-site IPSec-based VPNs:
• • • •
Routing Protocols IP Addressing Network Address Translation (NAT) and Port Address Translation (PAT) Dynamic Host Configuration Protocol (DHCP)
Routing Protocols
All IP routing protocols use either broadcast or multicast as a method of transmitting routing table information. Since IPSec does not support either broadcast or multicast, Cisco recommends using Generic Routing Encapsulation (GRE) as a tunneling method to overcome this limitation. See “Implementing Generic Route Encapsulation (GRE)” section on page 2-9 for more information on GRE and “Using a Routing Protocol Across the VPN” section on page 2-13 for more information on running a Routing Protocol across the VPN.
IP Addressing
Proper IP addressing is critical for a successful VPN. In order to maintain scalability, performance, and manageability, it is highly recommended that remote sites use a subnet of the major network to allow for summarization. This way the crypto Access Control Lists (ACLs) will contain a single line for every local network; possibly a single entry if the local networks can be summarized.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-19
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Proper address summarization is highly recommended. Address summarization conserves router resources making routing table sizes smaller. Address summarization also saves memory in routers, and eases troubleshooting tasks. In addition to conserving router resources, address summarization also simplifies the configuration of routers in IPSec networks. Please consult the IP Addressing section of the Cisco SAFE VPN White Paper for a more thorough discussion. Cisco SAFE documentation can be found at: http://www.cisco.com/go/safe
Network Address Translation (NAT) and Port Address Translation (PAT)
While Network Address Translation (NAT) and Port Address Translation (PAT) can result in an added layer of security and address conservation, the presence of NAT or PAT in between IPSec peers presents challenges to the implementation of an IPSec VPN. In the case of PAT, IPSec peers with a PAT process between them will fail to negotiate properly. Internet Key Management Protocol (ISAKMP) relies on an individual IP address per peer for proper operation. PAT works by masquerading multiple peers behind a single IP address. Site-to-site IPSec networks can operate between NAT processes. However, the un-translated peer must be configured with the remote peer’s translated address for proper operation.
Dynamic Host Configuration Protocol (DHCP)
In order for a host at a remote site to be able to use a Dynamic Host Configuration Protocol (DHCP) server over an IPSec tunnel at a central site, an IP helper address must be configured on the router interface associated with the host. Unfortunately, if connectivity to the central site is lost, a host at a remote site might not receive an IP address. This can prevent the host from communicating with other hosts on its local network. A Cisco IOS router can also be configured to act as a stand alone DHCP server; however, these features have not been tested with IPSec VPN in preparing this publication version.
Service Provider Dependencies
VPNs inherently rely on one or more SPs to provide Internet service to the head-end and branch offices in order to deploy the network, so choosing a SP is a critical element of deploying a VPN. Many factors have to be considered including cost, services available, reliability, and the expected geographical coverage of the customer’s VPN. At a minimum, the enterprise should have a service-level agreement (SLA) with the SP that outlines the critical service elements of its VPN. Factors to address include availability, bandwidth, and latency. When the situation requires an enterprise to use multiple SPs to cover its branch locations, an added a level of complexity can be imposed. Obtaining the desired level of end-to-end VPN service can be more difficult—especially in a case involving delay-sensitive, mission-critical applications. Future considerations of running latency-sensitive applications, such as IP Telephony and video, across the VPN must also be considered. For these reasons, Cisco recommends obtaining an SLA with a single SP that can guarantee adequate end-to-end service for all enterprise locations.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-20
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Component Recommendations
Another issue to be aware of is that some Internet SPs for DSL and cable services implement policing of traffic for residential class service. This means that protocols such as IPSec might be blocked unless a business class service subscription is established.
Management
Cisco brings all of its VPN products together through management systems that provide such status information as device availability and throughput, for example, management integration through products such as VPN/Security Management Solution (VMS) and VPN Solution Center (VPNSC). A later version of this publication will discuss how Cisco brings together configuration management, security policy management, quality-of-service management, and infrastructure management on Cisco concentrators, routers, and firewalls. For more information on how implement network management over IPSec tunnels, please refer to the Cisco SAFE security blueprint and seminar series. Cisco SAFE documentation can be found at this URL: http://www.cisco.com/go/safe
Solution Component Recommendations
This chapter presents the steps to selecting Cisco products for a deployable VPN solution, starting with sizing the head-end, and then choosing Cisco products that can be deployed for head-end devices. It concludes with product sizing and selection information for branch-end devices. Specific sections include:
• • • • • •
Scalability Testing Methodology Hardware-Accelerated Encryption Head-end Devices Branch Site Devices Network Performance/Convergence Software Releases Evaluated
Scalability Testing Methodology
The scalability testbed included 240 branch offices aggregated to two head-end devices as illustrated in Appendix A, “Enterprise Site-to-Site VPN Scalability Test Configuration.” Aggregation to three head-ends was also tested for comparison purposes. The head-ends consisted of the Cisco 7100 and Cisco 7200 Series VPN router products (see “Head-end Devices” section on page 2-23 for models tested). The branch offices consisted of Cisco VPN router products from the Cisco 800, Cisco 1700, Cisco 2600, and Cisco 3600 Series routers (see “Branch Site Devices” section on page 2-27 for models tested). Head-end products were evaluated with hardware-accelerated encryption installed, while branch products were evaluated with both software-based encryption and hardware-accelerated encryption. Triple DES was selected as the encryption standard and SHA-1 as the hash method. Each branch router was provisioned with two IPSec/GRE tunnels (primary and secondary) back to two different head-ends. EIGRP was used as the routing protocol to distribute routes from the head-ends to the branches. Note that the testing was conducted with a fully summarized network configuration.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-21
Chapter 2 Solution Component Recommendations
Enterprise Site-to-Site IPSec VPNs
Some performance tests use the IMIX standard for specification of packet sizes. Typically these tests then continually send streams of the specified packet sizes to a device under test to evaluate its performance. In this particular scalability test, instead of streams of particular packet sizes, realistic traffic flows were established using the NetIQ Chariot testing tool. The mix of traffic was approximately 35 percent UDP and 65 percent TCP. A comparison of IMIX and the traffic profile used during this evaluation is shown in Table 2-4.
Table 2-4 Comparison of IMIX and Traffic Profile
Cisco Scalability Test G.729 RTP (64-byte packets)—50 pps DNS (100-byte packets)—4 flows FTP (1400-byte packets)—1 flow
IMIX 40-byte packets—7 parts 576-byte packets—4 parts 1500-byte packets—1 part
Although not matched one-for-one with the IMIX standard, the traffic profile used in this evaluation is believed to yield conservative performance data. This is due to two factors:
• •
The Chariot streams simulate realistic traffic flows instead of packet blasting. This profile contains a significant percentage of small packets, a somewhat more aggressive profile than IMIX.
The evaluation was then performed by increasing traffic rates using this profile to find the throughput points on each product where the CPU utilization reached the defined limits (50 percent for head-ends, 65 percent for branch routers). Additionally, zero packet loss was permitted. Individual product throughput performance data is presented in “Cisco VPN Routers for Head-ends” section on page 2-26 for head-end products and “Cisco VPN Routers for Branch Sites” section on page 2-28 for branch end products. In addition to throughput testing, failover testing was also conducted. Please see to “Network Performance/Convergence” section on page 2-29 for more information on the failover test scenario. All scalability testing for this publication was performed using IPSec Tunnel Mode; the throughput results might differ in Transport Mode.
Hardware-Accelerated Encryption
The scalability testing performed as part of the VPN solution development indicates a strong need for hardware-accelerated encryption to achieve predictable performance results. For head-end devices, all throughput results presented in this design guide and the recommended architecture assume that hardware-acceleration is implemented. For branch-end devices, both software-based encryption and hardware-accelerated encryption were evaluated. Throughput performance was significantly increased (up to 80 percent) with the addition of hardware-accelerated encryption. For these reasons, Cisco strongly recommends hardware acceleration in all devices performing encryption. This is especially true if:
• •
Triple DES encryption is being implemented. Significant data throughput requirements exist.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-22
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Component Recommendations
•
Multi-service applications, such as IP Telephony, are to be run over the VPN.
Cisco has different names for the acceleration modules of the Cisco 7200 and Cisco 7100 families. The Integrated Services Adapter (ISA) be used on the Cisco 7100 or Cisco 7200. The Integrated Services Modules (ISM) can be used on the Cisco 7100. They offer comparable performance. Multiple cards (dual ISA on a Cisco 7200, ISM+ISA on Cisco 7100) can be used to increase encryption throughput. Although not yet evaluated in scalability testing, the VPN Acceleration Module (VAM) is another high-performance VPN encryption option. For branch access routers, hardware-acceleration components are typically Advanced Integration Modules (AIM). See “Cisco VPN Routers for Head-ends” section on page 2-26 and “Cisco VPN Routers for Branch Sites” section on page 2-28 for more detailed performance data that supports this recommendation.
Head-end Devices
The head-end devices are responsible for:
• • •
Originating/terminating IPSec encapsulated GRE tunnels from the branch sites Running routing protocol inside GRE tunnels to advertise internal routes to branches Providing resiliency to eliminate the possibility of a single point of failure
The next sections identify factors to take into account in sizing the head-end (or sites). Specific sections include:
• • •
Sizing the Head-end Cisco VPN Routers for Head-ends Other Cisco Products
Sizing the Head-end
Sizing the head-end correctly before choosing the devices to deploy ensures that the overall network can support the intended (and possibly future) traffic profiles to be run over the VPN. Two critical factors must be considered when sizing the head-end:
• •
How many branch offices must be connected to the head-end? This provides the number of primary tunnels requiring aggregation. What is the expected traffic profile, including the average packets-per-second (pps) and bits-per-second (bps) throughput rates for each branch office? This provides the aggregated data throughput required across the VPN.
These factors can limit sizing the head-end and must be considered together. The decision flow shown below in Figure 2-8 should be applied to size the head-end.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-23
Chapter 2 Solution Component Recommendations
Enterprise Site-to-Site IPSec VPNs
Figure 2-8
Head-end Sizing Decision Flow
Calculate Headend Devices based on Number of Tunnels C(t) Which is greater ? Consider Headend Product Options Calculate Headend Devices based on Branch Throughput C(a)
How many branches?
Throughput per branch?
Preliminary Estimate
Other Factors ?
Adjust according to other known factors
Final Estimate
74178
Note
This design assumes a level of resiliency at the head-end to handle a failover scenario. Scalability testing was conducted up to and including 240 tunnels per head-end. The Cisco VPN Router products evaluated as head-end devices are often capable of aggregating more than 240 tunnels. Ultimate peer scalability is dependent on numerous factors including resiliency design, routing, and other services running on the device. Using a routing protocol (such as EIGRP as in this design) also affects the number of peer devices that can be effectively aggregated to a particular head-end. To date, support for 240 peers has been verified in scalability testing. Again, more peers per head-end are possible, but planning using an initial limit of 240 is recommended, as this configuration has been verified. A future version of this publication will contain scalability performance data for higher than 240 peers. Based on the number of branch offices, the required number of head-end devices, C(t), can be sized with the following algorithm: N = Total number of branch offices T = Total number of tunnels = N x 2 (for primary and secondary tunnels) C(t) = (T / 240) rounded up to next full integer + 1 (for resiliency) For example, an enterprise with 950 branch offices would require nine head-end devices for a resilient design, as follows: N = 950 T = 1900 C(t) = 1900/240 rounded up + 1 = 9 The next step is to obtain traffic profile data that indicates expected average throughput (pps and bps) for each branch office and head-end device.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-24
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Component Recommendations
The aggregate throughput is then calculated by adding up all of the throughput estimates for all branch offices. Next consider the available head-end devices and the maximum throughput supported by each. The Cisco 7140 and Cisco 7200VXR routers are the preferred platforms for use as IPSec VPN head-end devices. Each of these routers has a range of options for interfaces as well as the ability to configure hardware-accelerated encryption. See “Cisco VPN Routers for Head-ends” section on page 2-26 for more details on product selection and throughput performance. Now divide the aggregate throughput requirements by the throughput value for each respective platform (please refer the values provided in Table 2-5 discussed in “Cisco VPN Routers for Head-ends” section on page 2-26). This will provide the number of head-end devices required, based on aggregate throughput: A = Sum of throughput estimates for each branch office (i.e. the aggregate) H = Single head-end device throughput C(a) = A/H, rounded up to nearest full integer, + 1 for resiliency For example, an enterprise with 300 branch offices, each having throughput requirements of 500 Kbps would require six head-end devices for a resilient design, as follows: A = 300 branches @ 500 Kbps = 300 x 0.5 Mbps = 150 Mbps H = 30 Mbps (for Cisco 7140 router) C(a) = 150/30 (rounded to next nearest integer) + 1 = 6 Compare the number of head-end devices calculated based on number of tunnels, C(t), to the number based on aggregate throughput, C(a). The greater of the two numbers is the required number of head-end devices to support the design outlined in this publication. As the number of tunnels increases there is a corresponding increase in CPU utilization. This means that a design that has a uniformly distributed traffic load from branch offices across many tunnels will require more CPU than a design where the majority of traffic load is generated from a subset of the total tunnels being aggregated. In addition to the two critical factors identified above, the following factors must also be considered at this point:
1.
Given the current network topology and traffic profile, what is the current CPU utilization on each distribution router, and how many branch offices are connected to each distribution router? This provides a baseline of expected CPU utilization levels. The combination of crypto/IPSec and GRE will add additional overhead to each distribution router.
2.
What are the aggregate WAN sizes for each respective branch? How the aggregate WAN speed is subdivided into a number of tunnels will affect the overall number of tunnels that can be supported in this design. As discussed previously, as the number of tunnels increases, there is a corresponding decrease in throughput (or an increase in CPU utilization).
3.
What other applications/protocols does the customer intend to run across the VPN? Multi-protocol implementations perform differently in a Cisco IOS environment compared to unicast-IP implementations. In the scalability testing performed to date, multi-protocols have not been comprehensively evaluated.
The end result is that the number of head-end devices might need to be adjusted upward after these additional factors are considered.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-25
Chapter 2 Solution Component Recommendations
Enterprise Site-to-Site IPSec VPNs
In the design presented in this publication, head-end device CPU utilization does not exceed 50 percent. This conservative recommendation ensures that the device has enough performance left over to deal with various events that take place during the course of normal network operations. Typical events include network reconvergence in the event of a failure, rekeying IPSec SAs, and bursts of traffic seen in a normal operating network. After initial deployment and testing, it might be possible to run head-end devices at CPU utilization levels higher than 50 percent (60 to 65 percent for example). However, this publication conservatively recommends staying at or below 50 percent—as a result the throughput results presented where chosen at the 50 percent level.
Cisco VPN Routers for Head-ends
Cisco has an array of VPN routers suitable for head-end deployments. These include the Cisco 7100, Cisco 7200, and Cisco 3600 Series routers. Specific platforms were selected from within each product family for evaluation. All products were configured with hardware-accelerated encryption enabled. Each product supports several hardware-accelerated encryption options. For example, both the Cisco 7100 and Cisco 7200 Series can be configured with one or two ISA/ISM cards or the newer VAM. The Cisco 3600 Series can be configured with different AIM performance levels, including Base (AIM-BP), Medium (AIM-MP) or High (AIM-HP) depending on platform. The configurations selected for scalability testing, along with the throughput thresholds attained (at 50 to 55 percent CPU utilization and 240 tunnels configured) are shown Table 2-5. Due to test limitations, traffic was generated over a subset of the configured tunnels in this particular scalability test.
Table 2-5 Head-end Products Throughput
Head-end Router Platform Cisco 7200VXR NPE-400
Hardware Acceleration Maximum Option Performance1 SA-ISA (1) VAM 90 Mbps 140 Mbps 90 Mbps 140 Mbps 90 Mbps 140 Mbps See branch results in Table 2-7
Scalability Traffic Mix Performance2 40.0 Mbps To be added in future publication version 30.0 Mbps To be added in future publication version 30.0 Mbps To be added in future publication version See branch results in Table 2-7.
Cisco 7200VXR NPE-300
SA-ISA (1) VAM
Cisco 7140
SA-ISM (1) VAM
Cisco 3660
AIM-HP (1)
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and single IPSec/GRE tunnel. 2. Scalability traffic mix evaluation performed with mixed packet sizes, 55 percent CPU utilization, and up to 240 IPSec/GRE tunnels.
In this version of the publication and corresponding scalability tests, the Cisco 3600 Series was evaluated only as a branch device. However, the Cisco 3600 Series can also be implemented as a head-end device. Scalability testing is currently underway for this configuration. See “Cisco VPN Routers for Branch Sites” section on page 2-28 for more information on the Cisco 3600 Series as a branch device.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-26
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Component Recommendations
New Cisco Head-end Products
A number of new Cisco VPN router products were not available at the time of the scalability testing performed with the design presented in this publication. Table 2-6 shows the latest Cisco VPN router products targeted for use as head-end devices, along with their measured maximum performance.
Table 2-6 Latest Cisco VPN Head-end Router Products
Head-end Router Platform Cisco 7400 Cisco 3745 Cisco 3725
Hardware Acceleration Option VAM AIM-EP AIM-EP
Maximum Performance1 Up to 120 Mbps Up to 40 Mbps Up to 40 Mbps
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and single IPSec/GRE tunnel.
Other Cisco Products
Several other Cisco products support IPSec VPN tunnel termination in a head-end environment, including the Cisco VPN3000 Concentrator and the Cisco PIX Firewall Series products. These platforms were not part of the scalability testing and therefore are not fully discussed. See the following links for more product information on the Cisco VPN3000 and Cisco PIX Series:
• •
http://www.cisco.com/warp/public/cc/pd/hb/vp3000/ http://www.cisco.com/warp/public/cc/pd/fw/sqfw500/
Branch Site Devices
The branch site devices are responsible for:
• •
Originating/terminating IPSec encapsulated GRE tunnels from the head-end Running a routing protocol inside of the GRE tunnels to advertise internal routes
The next sections identify factors to take into account when sizing the branch sites. Specific sections include:
• • •
Sizing the Branch Site Cisco VPN Routers for Branch Sites Other Cisco Products
Sizing the Branch Site
The most important factor to consider when choosing a product for the branch office is expected traffic throughput. Secondary factors that should be considered include:
•
Other features/functionality that the branch router will be providing, such as WAN access, IP Telephony, DHCP, or Cisco IOS firewall.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-27
Chapter 2 Solution Component Recommendations
Enterprise Site-to-Site IPSec VPNs
•
Differences in the range of features that branch devices can accommodate. For example, the Cisco 3660 supports six modular slots and various WAN adapters, while the Cisco 2600 series supports only two slots.
While the number of IPSec tunnels will not play as large a role in the branch device sizing, each branch site router must be able to terminate at least two IPSec-encapsulated GRE tunnels (primary and secondary). The principal concern is the amount of traffic throughput along with the corresponding CPU utilization. In the design presented in this publication, branch device CPU utilization does not exceed 65 percent. This conservative recommendation ensures that the device has enough performance left over to deal with various events that take place during the course of normal network operations. The CPU utilization on a branch site may run slightly higher than a head-end router due to minimal routing convergence duties associated with branch routers. After initial deployment and testing, it might be possible to run branch devices at CPU utilization levels higher than 65 percent. However, this publication conservatively recommends staying at or below 65 percent, and therefore the throughput results presented where chosen at the 65 percent level.
Cisco VPN Routers for Branch Sites
Cisco has a line of VPN routers suitable for branch site deployments. These include the Cisco 3600, Cisco 2600, Cisco 1700, and Cisco 800 Series routers. All branch devices except the Cisco 800 Series support hardware-accelerated encryption. Specific platforms were selected from within each product family for evaluation. All products were evaluated with both hardware-accelerated encryption enabled as well as software-based encryption. Throughput results (at approximately 65 percent CPU utilization) are summarized in Table 2-7.
Table 2-7 Branch Site Device Throughput
Hardware (HW) Branch Router Platform Acceleration Option Cisco 3660 Cisco 3640 Cisco 3620 Cisco 2651 Cisco 2621 Cisco 2611 Cisco 1750 Cisco 806 Cisco 805 AIM-HP AIM-MP AIM-MP AIM-BP AIM-BP AIM-BP VPN Module N/A N/A
Maximum Performance1 38.1 Mbps 14.7 Mbps 8.0 Mbps 14.0 Mbps 10.0 Mbps 8.0 Mbps 3.0 Mbps 384 Kbps N/A
Scalability Traffic Mix Performance with HW Encryption2 16.0 Mbps 3.5 Mbps 1.8 Mbps 2.8 Mbps 2.4 Mbps 2.0 Mbps 2.6 Mbps N/A N/A
Scalability Traffic Mix Performance with SW Encryption3 2.4 Mbps 900 Kbps 480 Kbps 960 Kbps 520 Kbps 380 Kbps 560 Kbps Not evaluated 100 Kbps
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and single IPSec/GRE tunnel. 2. Scalability traffic mix evaluation performed with mixed packet sizes, 65 percent CPU utilization, and two IPSec/GRE tunnels. 3. Refer to the footnote above for “Scalability Traffic Mix Performance with HW Encryption.”
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-28
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Component Recommendations
New Cisco Branch Site Products
A number of new Cisco VPN router products were not available at the time of the scalability testing performed with the design presented in this publication. Table 2-6 shows the latest Cisco VPN Router products targeted for use as branch devices, along with their measured maximum performance.
Table 2-8 Latest Cisco VPN Branch Site Router Products
Head-end Router Platform Cisco 3745 Cisco 3725 Cisco 1760
Hardware Acceleration Option AIM-EP AIM-EP VPN Module
Maximum Performance1 Up to 40 Mbps Up to 40 Mbps Up to 10 Mbps
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and single IPSec/GRE tunnel.
Other Cisco Products
Several other Cisco products support IPSec VPN tunnel termination in a branch site termination environment. These include the Cisco VPN 3002 Concentrator, Cisco PIX 501 and Cisco PIX 506 firewalls. These platforms were not part of the scalability testing and are not fully discussed in this publication. See the following links for more product information on the Cisco VPN 3000 and Cisco PIX Series:
• •
http://www.cisco.com/warp/public/cc/pd/hb/vp3000/ http://www.cisco.com/warp/public/cc/pd/fw/sqfw500/
Network Performance/Convergence
Each network deployment can have different convergence time requirements. The design principles in this guide were used to perform a scalability test with 240 branch offices aggregated to two head-end devices. Standard timer values were configured for the routing protocol being used. Traffic load was established between the 240 branches and two head-ends. Aggregation to three head-end devices was also evaluated for comparison purposes. The test was performed by powering off one of the head-end devices to simulate a complete failure. The 120 affected branches successfully failed over to the surviving head-end. In this test, the network fully converged after 22 seconds. The same test was then performed with 240 branch offices aggregated to three head-end devices. All 80 branches from the failed head-end successfully failed over to the two surviving head-ends. In this test, the network fully converged after 22 seconds. Convergence times were found to be well within the timeframe to maintain TCP connections. In both scenarios, the failed head-end device was then powered back on, resulting in the network re-converging in less than two seconds. The IPSec tunnels re-established a few at a time as their corresponding SAs were renegotiated. The last IPSec tunnels re-established after 1-1/2 to two minutes. During this recovery and SA negotiation period, network connectivity is already established.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-29
Chapter 2 Additional Considerations for Latency-Sensitive Traffic
Enterprise Site-to-Site IPSec VPNs
Software Releases Evaluated
The software releases shown in Table 2-9 were used in scalability testing:
Table 2-9 Software Releases Evaluated
Product Type Cisco Head-end Routers (Cisco 7140, Cisco 7200) Cisco Branch Office Routers (Cisco 1750, Cisco 26xx, Cisco 36xx) Cisco Catalyst Switches (Cisco 2948G, Cisco 6x00)
Software Release Cisco IOS 12.1(9)E (with Triple DES IPSec support) Cisco IOS 12.2(8)T (with Triple DES IPSec support)1 Cisco CatOS 5.5
1. Cisco IOS 12.2(8)T is the current minimum recommendation for branch products. Cisco IOS 12.2(3.5)T was the actual software evaluated for this publication, however, an interim release and is not available for external deployment.
Note
Several Cisco IOS images exist with each configured with various levels of encryption technology. There are certain restrictions and laws governing the use and export of encryption technology. With the Cisco IOS images referenced in Table 2-9, all VPN features may be enabled, including Triple DES. Before selecting Cisco IOS software, perform the appropriate research through http://www.cisco.com and consult with technical support representative. Be aware of any issues in specific levels of code that can affect other configured features.
Additional Considerations for Latency-Sensitive Traffic
VPNs are often positioned as traditional WAN replacements, since they offer the same interconnectivity between a central campus and branch offices, often with greater flexibility and lower cost. As a result, customers expect the same level of services offered by a WAN, including the ability to run latency-sensitive applications, such as IP Telephony and video, across the VPN. End-to-end QoS is required to achieve acceptable quality, including low latency and jitter. Provisioning and deploying an IPSec-based VPN with QoS enabled is currently under study and scalability testing. Some preliminary findings are important to consider when deploying a QoS enabled VPN. These are highlighted in the following subsequent sections:
• • • • • •
Quality of Service (QoS) Pre-classification of Traffic Lower Link Speeds Hardware-Accelerated versus Software-Based Encryption Compressed RTP Not Supported by IPSec Additional Service Provider Considerations
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-30
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Additional Considerations for Latency-Sensitive Traffic
Quality of Service (QoS)
Quality of Service (QoS) is an issue when significant levels of voice and video traffic is added to network with heavy data traffic. Mission-critical and time-sensitive traffic—such as voice— must receive higher QoS guarantees than less time-sensitive traffic such as file transfers and emails. Increasing bandwidth to solve this problem involves higher cost. A QoS-based solution offers the potential for optimized and differentiated use of existing bandwidth. QoS enables assignment of different qualities to different data streams. Cisco provides a number of comprehensive end-to-end QoS mechanisms to improve voice quality and to optimally utilize WAN bandwidth. Examples of these mechanisms are:
• •
Packet classification and usage policies applied at the edge of the network, such as Policy Based Routing (PBR) and Committed Access Rate (CAR). End-to-end queuing mechanisms, such as Low Latency Queuing (LLQ). Because voice is susceptible to increased latency and jitter on slow speed links, LFI may also be used to reduce delay and jitter by breaking up large datagrams and interleaving low-delay traffic with the resulting smaller packets Scheduling mechanisms to optimize bandwidth utilization on output links, such as Traffic Shaping
•
QoS is beyond the scope of this publication, but will be included in a future version after scalability testing is completed.
Pre-classification of Traffic
Starting with Cisco IOS 12.2(2)T, a new pre-classification feature provides the prerequisite traffic classification needed to provide QoS across the VPN. Pre-classification is not simply copying of the Type of Service (ToS) bits to the front of the encrypted IPSec packet. Pre-classification preserves Cisco IOS QoS functionality and must be used whenever a VPN hardware-accelerated encryption card and Cisco IOS QoS are needed on the same Cisco router. It additionally provides the ability for the Cisco VPN router to provide WAN-edge QoS, based on encrypted elements—such as User Datagram Protocol (UDP) port or source address/destination address (SA/DA). Pre-classification is currently implemented for the Cisco 2600, Cisco 3600, Cisco 7100 and Cisco 7200 Series VPN routers. This feature was not tested in the initial scalability tests conducted for this publication. For additional information on why and how to implement pre-classification, see the following link: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtqosvpn.htm Pre-classification is beyond the scope of this publication, but will be included in a future version after scalability testing is completed.
Lower Link Speeds
Link speeds can be provisioned for branch sites at varying rates, from relatively low rates to very high rates depending on throughput requirements. For VPNs where the primary traffic is data, all link speeds readily support the requirements in this publication.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-31
Chapter 2 Additional Considerations for Latency-Sensitive Traffic
Enterprise Site-to-Site IPSec VPNs
When extending a VPN to support multi-service applications, such as IP Telephony and video, latency must be considered. On interfaces with lower link speeds, link fragmentation and interleaving (LFI) is required to minimize serialization delay incurred by transmitting large packets (such as 1400-byte packets) in front of smaller IP Telephony packets (such as 64-byte packets). If you anticipate running latency-sensitive applications over the VPN, plan to implement QoS features that minimize delay.
Hardware-Accelerated versus Software-Based Encryption
In addition to the recommendations outlined in “Hardware-Accelerated Encryption” section on page 2-22, other considerations favor implementing hardware-accelerated encryption in platforms that will support latency sensitive applications. For example, with software-based encryption it is not possible to achieve acceptable levels of latency and jitter that are predictable. For example, large data packets can overwhelm the encryption software and lead to unacceptable delays in receiving IP Telephony packets. Hardware-accelerated encryption adds up to 80 percent more encryption processing capacity to prevent this from occurring.
Compressed RTP Not Supported by IPSec
Header compression provides a very valuable service to latency sensitive protocols such as IP Telephony. When using Compressed Real Time Protocol (cRTP) to transport IP Telephony, packet redundancy from the Layer 3 and Layer 4 headers is removed from the stream, resulting in a lower traffic burden. Due to the nature of IPSec as outlined in the IETF standard, use of cRTP is not possible. This is not a Cisco IOS limitation, but an inherent incompatibility between the two protocols. Alternative protocols to cRTP to achieve header compression are being investigated for future implementation. Currently the only workaround is to provision the links so that sufficient bandwidth exists to transport the whole packet without header compression.
Additional Service Provider Considerations
VPNs inherently rely on one or more SPs to provide Internet service to the head-end and branch offices in order to deploy the network. It is important to note that some service providers may or may not honor classifications of delay-sensitive traffic—referred to as type of service (ToS)—and can therefore experience unacceptable levels of delay or jitter on voice traffic. Whenever possible, SLAs with SPs should be put into place. SLAs provide a stronger guarantee that delay-sensitive traffic will be handled in a QoS-type manner across the ISP network. This enables the enterprise to achieve end-to-end QoS for this type of traffic. Complications can also arise when multiple SPs are involved. For example, one SP might not honor the ToS classification bits from another SP. Additional latency can also be introduced by having latency-sensitive traffic needing to traverse multiple SP backbones. Furthermore, when a small office subscribes to cable or DSL Internet service provisioned for residential customers, problems can be encountered. Certain traffic types might be blocked prohibiting the effective deployment of a VPN (such as IP Telephony signaling protocols). Therefore it is strongly recommended that small offices subscribe to business-level cable or DSL service.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-32
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Enterprise Site-to-Site VPN Case Study
Enterprise Site-to-Site VPN Case Study
The key objective of this case study is to provide a reference example for a site-to-site VPN design. It provides an example of how these design principles can be applied in a real-world implementation. This case study assumes that all of the design considerations in “Solution Design Recommendations” section on page 2-6 and “Solution Component Recommendations” section on page 2-21 have been addressed and that best practice design recommendations are adopted by the customer. The case study also assumes that the Cisco IOS software levels listed in “Software Releases Evaluated” section on page 2-30 are acceptable to the customer. The details of the SP backbone and WAN connectivity are not addressed in the case study because the focus is with VPN deployment on the enterprise customer side.
Enterprise Organization Overview
Moose Widgets has been developing products at their Portland, Oregon headquarters (HQ) for several years. In addition, Moose Widgets has a single distribution center and 20 retail outlets across the United States (US). Currently Moose Widgets utilizes a traditional frame relay (FR) WAN service to connect its HQ network to its distribution center network. There is currently no connectivity to retail outlets, with the exception of a few outlets that, use personal computers (PCs) to dial-up to the corporate HQ. The current network topology is illustrated in Figure 2-9.
Figure 2-9 Moose Widgets Case Study Current Topology
Distribution Ctr Seattle, WA
Moose Widgets HQ Portland, OR
Frame relay
Retail outlets (20)
Corporate network
PSTN
74180
Dialup
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-33
Chapter 2 Enterprise Site-to-Site VPN Case Study
Enterprise Site-to-Site IPSec VPNs
Moose Widgets recently acquired two companies, one in San Jose, California and the other in Great Falls, Montana. Moose Widgets wants to connect its newly acquired companies and its retail outlets to its corporate network as an intranet. In addition, Moose Widgets plans to expand its retail outlets (from its current level of 20 to between 40 and 50) over the next year. Further, Moose recognizes that it needs additional distribution centers on the east and west coasts of the US to handle this expansion. As part of a corporate initiative, Moose Widgets is implementing a centralized inventory tracking system to more cost-effectively manage inventory in its growing distribution centers and retail outlets. The existing dial-in access does not provide adequate bandwidth to support the new applications. Moose Widgets is also concerned about an anticipated escalation of dial-in charges as each retail outlet will increasingly rely on corporate resources. As a result, Moose Widgets is looking to transition to a dedicated connection for each of its retail outlets using the Internet and VPN technology. Moose Widgets is concerned about the costs of adding the connections. It is also concerned about the ability to quickly get retail outlets up and running. Moose Widgets management indicated that it is primarily concerned about data traffic today, but there is some degree of interest in adding voice services in the future. Moose Widgets estimates its traffic requirements for the different site locations as shown in Table 2-10.
Table 2-10 Moose Widgets Case Study Traffic Profile
Location Distribution Center (one today, potentially three in the future) San Jose Great Falls Retail Outlets (up to 50)
Total
Estimated Traffic 1 Mbps 4 Mbps 4 Mbps 50Kbps (typical); 40 outlets 200Kbps (larger); 10 outlets 15Mbps
Moose Widgets approached Cisco to determine how a Virtual Private Network might meet its requirements.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-34
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Enterprise Site-to-Site VPN Case Study
Design Considerations
The design adopted for Moose Widgets provides for deployment of a site-to-site IPSec VPN, with the Moose Widgets corporate HQ serving as the head-end. All other locations are treated as branch sites. This allows a branch office to subscribe to a local ISP, get authenticated, and remain inside the corporate intranet. At the same time, end-to-end encryption is enabled using IPSec tunneling. Switching to VPN offers Moose Widgets significant cost savings over dial-up solutions and the ability to outsource to a SP that has VPN service as a core competency, resulting in better cost-efficiency and scalability. The initial goal is to provide VPN connectivity to onsite employees. Following the design practice outlined in “Solution Design Recommendations” section on page 2-6 and “Solution Component Recommendations” section on page 2-21, there are four main design steps to perform:
• • • •
Preliminary Design Considerations Sizing the Case Study Head-end Sizing the Case Study Branch Sites Tunnel Aggregation and Load Distribution
Preliminary Design Considerations
The design adopted is straightforward and flexible. As new retail locations enter service, Moose Widgets can purchase Internet connectivity from the local ISP, deploy a Cisco VPN Router at the branch site, configure the IPSec tunnels to the head-end devices at the corporate headquarters, and enable secure intranet access in a short amount of time.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-35
Chapter 2 Enterprise Site-to-Site VPN Case Study
Enterprise Site-to-Site IPSec VPNs
Using the questions from “General Design Considerations”, Table 2-11 summarizes the preliminary design considerations.
Table 2-11 Preliminary Design Considerations Summary
Question What applications are expected to run over the VPN? Is multi-protocol support required? How many branches will be aggregated to the head-end? What is the expected traffic throughput to/from branch offices? What are the expectations for resiliency? What encryption level is required?
Answer Data
Comments Interested in future voice services
Yes, using EIGRP for routing is GRE tunnels will enable desired. multi-protocol traffic transport. 55 sites See Table 2-10
Resiliency is required Triple DES
1 primary, 1 backup tunnel
What type of IKE authentication Pre-shared keys is selected due method will be used? to relatively small number of sites to manage. What other services will be run on the branch VPN routers? None
Migration to digital certificates should be considered if number of branches increases beyond 50 in the future.
Sizing the Case Study Head-end
While the traffic loads involved are not expected to exceed the recommended capacity of a single head-end device, Moose Widgets indicated it desires built-in resiliency at the central location. To meet this requirement, the tunnels from the remote ends are allocated to each of the head-end devices to balance the traffic load. To provide the service resiliency needed, secondary tunnels are configured and allocated so that in the event of a head-end failure, traffic is transitioned over to the partner head-end device. Applying the sizing algorithm defined in “Sizing the Head-end” section on page 2-23 presented earlier, the calculation of head-end sizing based on number of tunnels is as follows: N = 55 T = N x 2 = 110 C(t) = (T / 240) rounded up + 1 = 110/240 rounded +1 = 1 + 1 = 2 head-ends Next, apply the sizing algorithm defined in “Sizing the Head-end” section on page 2-23 and using the throughput estimates from Table 2-10, the calculation of head-end sizing based on branch traffic throughput is as follows: A = (3*(1 Mbps)+4 Mbps+4 Mbps+40*(50kbps)+10*(200kbps)) = 15 Mbps H = 40 Mbps (for Cisco 7206VXR NPE-400) C(a) = A/H, rounded up + 1 = 15/40 rounded up + 1 = 1+1 = 2 head-ends
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-36
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Enterprise Site-to-Site VPN Case Study
Comparing the number of head-end devices calculated based on number of tunnels, C(t), to the number based on aggregate throughput, C(a), the outcomes match. Therefore it is appropriate to deploy two head-end devices. Presented with the head-end product options, the customer selects to deploy two Cisco 7206VXR NPE-400 routers, each equipped with an ISA hardware encryption adapter.
Sizing the Case Study Branch Sites
The primary consideration for sizing of branch office sites is expected traffic throughput. Accordingly, starting with Table 2-10, and applying the concepts presented in “Sizing the Branch Site” section on page 2-27 presented earlier, the branch products selected are summarized in the Table 2-12.
Table 2-12 Branch Site Product Selection Summary
Location Distribution Centers San Jose Great Falls Retail Outlets (typical) Retail Outlets (larger)
Estimated Throughput 1 Mbps 4 Mbps 4 Mbps 50 Kbps 200 Kbps
Branch Office Platform Selected Cisco 2651 Cisco 3660 Cisco 3660 Cisco 1750 Cisco 2611
At each of the acquired company locations, a Cisco 3660 VPN router is deployed with high performance hardware-accelerated encryption (AIM-HP). The choice of the Cisco 3660 platform is based on the assumption that the acquired companies are large offices with a substantial number of employees. At each of the distribution centers, a Cisco 2651 Series VPN router is deployed with base performance hardware-accelerated encryption (AIM-BP). Finally, at each of the retail locations, the Cisco 2611 is recommended for the larger retail outlets and the Cisco 1750 for smaller retail outlets.
Tunnel Aggregation and Load Distribution
Given 55 branch sites, the total number of tunnels to be aggregated 110 (including primary and secondary tunnels). The first head-end device is allocated 27 primary and 28 backup tunnels, while the second head-end device is allocated 28 primary and 27 backup tunnels.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-37
Chapter 2 Enterprise Site-to-Site VPN Case Study
Enterprise Site-to-Site IPSec VPNs
Network Layout
An example network topology is shown in Figure 2-10.
Figure 2-10 Moose Widgets Case Study VPN Topology
Moose Widgets HQ Portland, RO
Distribution centers (3)
Cisco 2651 Cisco 2651
Retail outlets (40-50)
Cisco 7206VXR NPE-400 Cisco 2611
Internet
Cisco 1750
Corporate network
Cisco 3660
Cisco 3660
Widgetvision Technologies San Jose, CA
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-38
EDCS-202049
74181
Wilderness Labs Great Falls, MT
Chapter 2
Enterprise Site-to-Site IPSec VPNs Configuration Discussion
Configuration Discussion
The configuration issues defined in this chapter are specific to VPN implementation. It is assumed that the reader is familiar with standard Cisco configuration practices at the Command Line Interface (CLI) level. All example configurations shown are for IPSec in Tunnel Mode. There are a number of configuration items that must be addressed to implement IPSec functionality. The general steps are as follows.
Step 1 Step 2 Step 3 Step 4 Step 5
Configure IKE policy—See “IKE Policy Configuration” section on page 2-39 Configure IPSec Transform and Protocol—See “IPSec Transform and Protocol Configuration” section on page 2-40 Create Access Lists for Encryption—See “Access List Configuration for Encryption” section on page 2-40 Configure Crypto Map—See “Crypto Map Configuration” section on page 2-41 Apply Crypto Map—See “Applying Crypto Maps” section on page 2-41
The sections which follow cover each of these steps in more detail. In addition, the following link offers additional information: http://www.cisco.com/cgi-bin/Support/PSP/psp_view.pl?p=Internetworking:IPSec
IKE Policy Configuration
There must be at least one matching IKE policy between two potential IPSec peers. The example configuration below shows a policy using pre-shared keys with Triple DES as the encryption transform. There is a default IKE policy that contains the default values for the transform, hash method, Diffie-Hellman group, authentication and lifetime parameters. This is the lowest priority IKE policy. When using pre-shared keys, Cisco recommends that wildcard keys be avoided. Instead, the example shows two keys configured for separate IPSec peers. The keys should be carefully chosen. Here, bigsecret is used only as an example. The use of keys containing alpha-numeric and punctuation characters is recommended.
Head-end Router
interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 ! crypto isakmp policy 1 encr 3des authentication pre-share crypto isakmp key bigsecret address 192.168.161.2
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-39
Chapter 2 Configuration Discussion
Enterprise Site-to-Site IPSec VPNs
Branch Site Router
interface s0/0 ip address 192.168.161.2 255.255.255.0 ! crypto isakmp policy 1 encr 3des authentication pre-share crypto isakmp key bigsecret address 192.168.251.1
These defaults and more information can be found at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_r/fipsencr/srfike .htm#xtocid17729
IPSec Transform and Protocol Configuration
The transform set must match on the two IPSec peers. The transform set names are only locally significant. However the encryption transform, hash method and the particular protocols used (ESP or AH) must match. You may also configure data compression here but it is not recommended on peers with high speed links. There can be multiple transform sets for use between different peers.
Head-end Router
interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 ! crypto ipsec transform-set vpn-test esp-3des esp-sha-hmac
Branch Site Router
interface s0/0 ip address 192.168.161.2 255.255.255.0 ! crypto ipsec transform-set vpn-test esp-3des esp-sha-hmac
More information can be found at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_r/fipsencr/srfips ec.htm#xtocid105784
Access List Configuration for Encryption
The access list entries defining the traffic to be encrypted must mirror each other on the IPSec peers. If access list entries include ranges of ports, then a mirror image of those same ranges must be included on the remote peer access lists. The addresses specified in these access lists are independent of the addresses used by the IPSec peers. In this example, GRE is specified on both the source and destination parts of the access list. All traffic encapsulated in the GRE packets will be protected.
Head-end Router
interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 ! ip access-list extended vpn-static1 permit gre host 192.168.251.1 host 192.168.161.2
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-40
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Configuration Discussion
Branch Site Router
interface s0/0 ip address 192.168.161.2 255.255.255.0 ! ip access-list extended vpn-static2 permit gre host 192.168.185.2 host 192.168.251.1
Crypto Map Configuration
The crypto map entry ties together the IPSec peers, the transform set used and the access list used to define the traffic to be encrypted. The crypto map entries are evaluated sequentially. In the example below, the crypto map name static-map and crypto map numbers (such as 1 and 20) are only locally significant. The first statement sets the IP address used by this peer to identify itself to other IPSec peers in this crypto map. This address must match the set peer statement in the remote IPSec peer crypto map entries. This address also needs to match the address used with any preshared keys the remote peers might have configured. The IPSec mode defaults to tunnel mode.
Head-end Router
interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 ! crypto map static-map local-address FastEthernet1/0 crypto map static-map 1 ipsec-isakmp set peer 192.168.161.2 set transform-set vpn-test match address vpn-static1
Branch Site Router
interface s0/0 ip address 192.168.161.2 255.255.255.0 ! crypto map static-map local-address Serial0/0 crypto map static-map 20 ipsec-isakmp set peer 192.168.251.1 set transform-set vpn-test match address vpn-static2
A more complete description can be found at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_r/fipsencr/srfips ec.htm#xtocid105785
Applying Crypto Maps
The crypto maps must be applied to the interfaces, both the physical interface and the logical interfaces, such as the GRE tunnel interfaces.
Head-end Router
interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 ! interface Tunnel1 ip address 10.62.1.193 255.255.255.252 tunnel source 192.168.251.1 tunnel destination 192.168.161.2
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-41
Chapter 2 Configuration Discussion
Enterprise Site-to-Site IPSec VPNs
crypto map static-map ! interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 crypto map static-map
Branch Site Router
interface s0/0 ip address 192.168.161.2 255.255.255.0 ! interface Tunnel1 ip address 10.63.25.198 255.255.255.252 tunnel source 192.168.185.2 tunnel destination 192.168.251.1 crypto map static-map ! interface Serial0/0 bandwidth 1536 ip address 192.168.161.2 255.255.255.0 crypto map static-map
Dynamic Crypto Maps
Rather than pre-define all the IPSec peers, another option is to create dynamic crypto maps. Dynamic crypto maps allow an IPSec connection between two peers when the central site peer does not have all the configuration necessary to complete an IPSec negotiation with a remote peer. This situation can occur when the remote peer has its IP address dynamically assigned—as in the case of a residential-class ISP connection like Cable or DSL. Since the remote peer’s IP address might be unknown, it cannot be preprogrammed into the central site device. IKE is required for authentication with dynamic crypto maps. The IKE authentication will complete based on an identity other than the remote peer’s IP address, such as the peer's fully qualified domain name (FQDN). The information from the IKE session will then be used to complete the missing information in the dynamic crypto map. Because the IP address of the peer is unknown until the IKE session is negotiated, GRE tunnels cannot be configured and cannot be used. This also prevents running a routing protocol. Resiliency can be accomplished with use of the relatively new Cisco IOS features Dead Peer Detection (DPD) and Reverse Route Injection. When dynamic crypto maps are used, an IPSec peer must accept connections from any IP address. For this reason the use of pre-shared keys is not recommended with dynamic crypto maps.
Note
Dynamic crypto maps have not been evaluated in scalability tests and are not covered further in this publication.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-42
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Configuration Discussion
Common Configuration Mistakes
The following sections outline some common mistakes and problems encountered when configuring IPSec:
• • • •
ACL Mirroring Error Peer Address Mismatch Transform Set Mismatch IKE Policy Mismatch
ACL Mirroring Error
The access lists that define the traffic to be encrypted must be mirror images of each other. The source port and source address in the access list on one peer must match the destination port and destination address on the other peer. The elimination of the source and destination ports is permissible, however the use of the keyword any for the addresses is strongly discouraged. This will ensure proper processing of encrypted traffic on the remote peer.
Peer Address Mismatch
The IP address used as the IPSec source address must match the address configured as the destination address on the IPSec peer and vice-versa. Unless the address is configured specifically, the address of the outgoing interface will be used as the IPSec peer’s address.
Transform Set Mismatch
At least one matching transform set must be configured between two IPSec peers. When specifying a particular strength of encryption algorithm, a similar strength IKE algorithm should also be configured. Failure to do so could weaken the encryption strength of the entire solution.
IKE Policy Mismatch
There is a default IKE policy present in all Cisco IOS devices. This policy uses lower security hash methods and encryption transform sets. If a stronger IKE policy is desired, at least one matching IKE policy must be configured between each IPSec peer.
Note
It is recommended to use the same transform set and hash methods in IKE and IPSec policies.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-43
Chapter 2 Configuration Discussion
Enterprise Site-to-Site IPSec VPNs
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-44
EDCS-202049
A P P E N D I X
A
Enterprise Site-to-Site VPN Scalability Test Configuration
Scalability Testbed Network Diagram
Figure A-1 illustrates the test network used for the enterprise site-to-site VPN scalability tests presented in this publication.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
A-1
Appendix A
Enterprise Site-to-Site VPN Scalability Test Configuration
Figure A-1
Scalability Testbed Network Diagram
Chariot endpoints Chariot console
Si
"Core / Campus endpoints" Sun Netras: vpn4-n1 through vpn4-n30
vpn4-2948GL2 vpn2-6500-1 vpn3-7xx0-1 vpn3-7xx0-3
vpn3-7xx0-2
Si
vpn1-6500-1 FEC vpn2-7500-2
vpn2-7505-1
FEC
(HDLC) vpn6-2948G-1 vpn6-2600-1 through vpn6-2600-30 vpn10-2600-1 vpn10-2948G-1 through vpn10-2600-30
vpn7-2948G-1
vpn7-2600-1 through vpn7-2600-30
vpn11-2600-1 vpn11-2948G-1 through vpn11-2600-30
vpn8-2948G-1
vpn8-2600-1 through vpn8-2600-30
vpn12-2600-1 vpn12-2948G-1 through vpn12-2600-30
vpn9-2948G-1
vpn9-2600-1 through vpn9-2600-30
vpn14-3620-1-5 vpn14-3660-1-5
vpn13-800 - 1-5 vpn13-1700-1-5 vpn14-2948G-1 vpn13-2600-1-5 vpn13-3640-1-5
ci13-2948G-1
"Branch endpoints" Sun Netras: vpn5-n1 through vpn5-n30 Chariot endpoints
Si
vpn2-6500-2
VPN Solution Testbed
74182
vpn5-2948GL2-1
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
A-2
EDCS-202049
Appendix A
Enterprise Site-to-Site VPN Scalability Test Configuration
Scalability Testbed Configuration Files
The configuration for the central and branch sites are listed below in the sections which follow.
Note
These configurations have been extracted from real configurations used in ESE scalability testing. They are provided as a reference only. The use of GRE as a tunneling method requires static tunnel endpoint configuration. Configuring IPSec peers was also done statically.
Head-end Configuration
The head-end is setup with two GRE tunnels (one primary and one secondary) for each branch site that it terminates. The following configuration is an excerpt and does not contain configuration commands for all branches.
! ip cef ! ! ip ssh time-out 120 ip ssh authentication-retries 3 ! xsm xsm privilege configuration level 15 xsm privilege monitor level 1 xsm vdm xsm edm no xsm history vdm no xsm history edm ! ! crypto isakmp policy 1 encr 3des authentication pre-share crypto isakmp key bigsecret address 192.168.161.2 crypto isakmp key bigsecret address 192.168.162.2 ! ! crypto ipsec transform-set vpn-test esp-3des esp-sha-hmac crypto mib ipsec flowmib history tunnel size 200 crypto mib ipsec flowmib history failure size 200 ! crypto map static-map local-address FastEthernet1/0 crypto map static-map 1 ipsec-isakmp set peer 192.168.1.2 set transform-set vpn-test match address vpn-static1 crypto map static-map 2 ipsec-isakmp set peer 192.168.2.2 set transform-set vpn-test match address vpn-static2 ! ! controller ISA 2/1 ! ! ! buffers small permanent 2048
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
A-3
Appendix A
Enterprise Site-to-Site VPN Scalability Test Configuration
buffers small max-free 10240 buffers small min-free 512 buffers middle permanent 2048 buffers middle max-free 10240 buffers middle min-free 512 buffers big permanent 2048 buffers big max-free 10240 buffers big min-free 512 buffers verybig permanent 2048 buffers verybig max-free 10240 buffers verybig min-free 512 buffers large permanent 2048 buffers large max-free 10240 buffers large min-free 512 buffers huge permanent 128 buffers huge max-free 512 buffers huge min-free 32 ! ! interface Loopback0 ip address 10.57.1.255 255.255.255.255 no ip route-cache no ip mroute-cache ! interface Tunnel1 description vpn6-2600-1 ip address 10.62.1.193 255.255.255.252 ip summary-address eigrp 1 10.0.0.0 255.0.0.0 5 load-interval 30 tunnel source 192.168.251.1 tunnel destination 192.168.1.2 crypto map static-map ! interface Tunnel2 description vpn6-2600-2 ip address 10.62.2.193 255.255.255.252 ip summary-address eigrp 1 10.0.0.0 255.0.0.0 5 load-interval 30 tunnel source 192.168.251.1 tunnel destination 192.168.2.2 crypto map static-map ! ! interface FastEthernet0/0 description FastEthernet0/0 ip address 172.26.156.17 255.255.254.0 no ip mroute-cache load-interval 30 duplex full ! interface FastEthernet1/0 description FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 load-interval 30 duplex full speed 100 crypto map static-map ! interface FastEthernet1/1 description FastEthernet1/1 ip address 10.57.1.1 255.255.255.252 no ip proxy-arp load-interval 30 duplex full
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
A-4
EDCS-202049
Appendix A
Enterprise Site-to-Site VPN Scalability Test Configuration
speed 100 ! router eigrp 1 redistribute static passive-interface FastEthernet0/0 passive-interface FastEthernet1/0 network 10.0.0.0 no auto-summary eigrp log-neighbor-changes ! ip classless ip route 0.0.0.0 0.0.0.0 192.168.251.2 ! ! ip access-list extended vpn-static1 permit gre host 192.168.251.1 host 192.168.1.2 ip access-list extended vpn-static2 permit gre host 192.168.251.1 host 192.168.2.2
Branch Site Configuration
For resiliency, two tunnels are configured (primary and secondary) to the central site.
! ip cef ! ! crypto isakmp policy 1 encr 3des authentication pre-share crypto isakmp key bigsecret address 192.168.253.1 crypto isakmp key bigsecret address 192.168.251.1 ! ! crypto ipsec transform-set vpn-test esp-3des esp-sha-hmac crypto mib ipsec flowmib history tunnel size 200 crypto mib ipsec flowmib history failure size 200 ! crypto map static-map local-address Serial0/0 crypto map static-map 10 ipsec-isakmp set peer 192.168.253.1 set transform-set vpn-test match address vpn-static1 crypto map static-map 20 ipsec-isakmp set peer 192.168.251.1 set transform-set vpn-test match address vpn-static2 ! ! interface Loopback0 ip address 10.63.25.254 255.255.255.255 ! interface Tunnel0 description Tunnel0 ip address 10.63.25.194 255.255.255.252 ip summary-address eigrp 1 10.63.25.0 255.255.255.0 5 load-interval 30 tunnel source 192.168.185.2 tunnel destination 192.168.253.1 crypto map static-map ! interface Tunnel1 description Tunnel1
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
A-5
Appendix A
Enterprise Site-to-Site VPN Scalability Test Configuration
delay 1526 ip address 10.63.25.198 255.255.255.252 ip summary-address eigrp 1 10.63.25.0 255.255.255.0 5 load-interval 30 tunnel source 192.168.185.2 tunnel destination 192.168.251.1 crypto map static-map ! interface FastEthernet0/0 description FastEthernet0/0 ip address 172.26.157.185 255.255.254.0 no ip proxy-arp no ip mroute-cache load-interval 30 speed auto half-duplex ! interface Serial0/0 description Serial0/0 bandwidth 1536 ip address 192.168.185.2 255.255.255.0 no ip mroute-cache load-interval 30 no fair-queue crypto map static-map ! interface FastEthernet0/1 description FastEthernet0/1 ip address 10.63.25.1 255.255.255.128 no ip mroute-cache load-interval 30 speed 10 full-duplex ! router eigrp 1 passive-interface Serial0/0 passive-interface FastEthernet0/1 network 10.0.0.0 no auto-summary eigrp log-neighbor-changes ! ip classless ip route 192.168.251.1 255.255.255.255 192.168.185.1 ip route 192.168.253.1 255.255.255.255 192.168.185.1 no ip http server ip pim bidir-enable ! ! ip access-list extended vpn-static1 permit gre host 192.168.185.2 host 192.168.253.1 ip access-list extended vpn-static2 permit gre host 192.168.185.2 host 192.168.251.1 !
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
A-6
EDCS-202049
A P P E N D I X
B
High-Level IPSec Overview
The purpose of this section is to provide a brief introduction to IPSec and its application in VPNs. General descriptions of the following IPsec topics are presented:
• • • • •
Tunneling Protocols Introduction to IPSec IPSec Protocols IPSec Modes Internet Key Exchange (IKE)
For a more in-depth understanding of IPSec, the reader should consult the Cisco SAFE VPN White Paper. Cisco SAFE documentation can be found at the following URL: http://www.cisco.com/go/safe
Tunneling Protocols
There are a variety of tunneling protocols from which to choose. They vary in terms of the features they support, the problems they are designed to solve, and the amount of security they provide to the data being transported. The design presented in this paper focuses on IPSec used in conjunction with GRE tunnels. When implemented individually, these tunneling protocols do not provide the necessary features to simultaneously ensure privacy and support multi-protocols. The combination of IPSec and GRE concurrently achieves both functions. Other tunneling protocols include Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP). PPTP and L2TP are intended for user or client to concentrator networks, commonly called remote access solutions and are not used in the site-to-site VPN solution.
Introduction to IPSec
The IPSec standard provides a method to manage authentication and data protection between multiple peers engaging in secure data transfer. IPSec includes Internet Security Association & Key Management Protocol (ISAKMP) and the Oakley Key Determination Protocol and two IPSec IP protocols—Encapsulating Security Protocol (ESP) and Authentication Header (AH).
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
B-1
Appendix B IPSec Protocols
High-Level IPSec Overview
IPSec uses symmetrical encryption algorithms for data protection. Symmetrical encryption transforms are more efficient and are easier to implement in hardware. These algorithms need a secure method of key exchange in order to ensure the data protection. Internet Key Exchange’s (IKE) ISAKMP/Oakley protocols provide that capability. This solution requires a standards based way to secure data from eavesdropping and modification. IPSec provides such a method. IPSec permits the network designer to choose the strength of data protection by allowing the choice of transform set. IPSec also has several hash methods to choose from, each giving different levels of protection.
IPSec Protocols
There are two IP protocols used in the IPSec standard: Encapsulating Security Protocol (ESP) and Authentication Header (AH). These protocols are summarized briefly in the next two sections:
• •
Encapsulating Security Protocol (ESP) Authentication Header (AH)
Encapsulating Security Protocol (ESP)
The ESP header (IP protocol 50) forms the core of the IPSec protocol. This protocol in conjunction with an agreed upon encryption method or transform set, protects data by rendering it un-decipherable. This protocol protects the data portion of the packet only. It can also optionally provide for authentication of the protected data. Figure B-1 shows how ESP encapsulates an IP packet:
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
B-2
EDCS-202049
Appendix B
High-Level IPSec Overview IPSec Protocols
Figure B-1
Encapsulating Security Protocol (ESP)
Original IP Packet
IP HDR
Data
Transport Mode
IP HDR
ESP HDR
Data Encrypted Authenticated
ESP ESP trailer Auth
Tunnel Mode New IP HDR ESP HDR IP HDR Data Encrypted Authenticated
74169
ESP ESP trailer Auth
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
B-3
Appendix B IPSec Protocols
High-Level IPSec Overview
Authentication Header (AH)
The AH protocol (IP protocol 51) forms the other part of IPSec. The AH does not protect data in the usual sense by hiding the data. Instead, it adds a tamper-evident seal to the data. It also protects the non-mutable fields in the IP header carrying the data. This includes the address fields of the IP header. The AH protocol should not be used alone when there is a requirement for data confidentiality. Figure B-2 illustrates how AH encapsulates an IP packet:
Figure B-2 Authentication Header (AH)
Original IP Packet
IP HDR
Data
Transport Mode
IP HDR
AH
Data
Authenticated except for mutable fields
Tunnel mode New IP HDR AH IP HDR Data
74170
Authenticated except for mutable fields in New IP header
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
B-4
EDCS-202049
Appendix B
High-Level IPSec Overview IPSec Modes
IPSec Modes
IPSec has two methods of forwarding data across a network: transport mode and tunnel mode. Each differs in their application as well as in the amount of overhead added to the passenger packet. These protocols are summarized briefly in the next two sections:
• •
Tunnel Mode Transport Mode
Tunnel Mode
Tunnel mode works by encapsulating and protecting an entire IP packet. Because tunnel mode encapsulates or hides the IP header of the packet, a new IP header must be added in order for the packet to be successfully forwarded. The encrypting devices themselves own the IP addresses used in these new headers. These addresses can be specified within the configuration of Cisco IOS routers. Tunnel mode may be employed with either or both ESP and AH. Using tunnel mode results in additional packet expansion of approximately 20 bytes associated with the new IP header. Tunnel mode expansion of the IP packet is depicted in Figure B-3.
Figure B-3 IPSec Tunnel Mode
IP HDR
Data
New IP HDR
IPsec HDR
IP HDR
Data To be protected
74171
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
B-5
Appendix B Internet Key Exchange (IKE)
High-Level IPSec Overview
Transport Mode
Because packet expansion can be a concern during the forwarding of small packets, a second forwarding method was also specified. IPSec transport mode inserts the ESP header between the IP header and the next protocol or the transport layer of the packet. Both IP addresses of the two network nodes whose traffic is being protected by IPSec are visible. This mode of IPSec can be sometimes susceptible to traffic analysis. However, since there is no additional IP header added, it results in less packet expansion. Transport mode can be deployed with either or both ESP and AH. This mode works well with GRE because GRE hides the addresses of the end stations by adding its own IP header. Transport mode expansion of the IP packet is depicted Figure B-4.
Figure B-4 IPSec Transport Mode
IP HDR
Data
IP HDR
IPsec HDR
Data To be protected
74172
Internet Key Exchange (IKE)
In order to implement a VPN solution with encryption, periodic changing of encryption keys is necessary. Failure to change these keys would make the network susceptible to brute force attacks. IPSec solves the problem of key generation with the Internet Key Exchange (IKE) protocol. This protocol uses a mathematical routine called a Diffie-Hellman exchange to generate symmetrical keys to be used by two IPSec peers. IKE also manages the negotiation of other security parameters such as the data to be protected, the strength of the keys, the hash methods used and whether or not the packets are protected from replay. IKE utilizes UDP port 500. Two elements of IKE are discussed briefly in the following sections:
• •
Security Association (SA) IKE Authentication
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
B-6
EDCS-202049
Appendix B
High-Level IPSec Overview Internet Key Exchange (IKE)
Security Association (SA)
A Security Association (SA) is an agreement between two peers engaging in an IPSec exchange. This agreement includes things like the type and strength of the encryption used to protect the data. It includes the method and strength of the data authentication (if any) and also the method of creating new keys for that data protection. SAs are performed in two phases as described in the following two sections:
• •
IKE Phase 1 IKE Phase 2
IKE Phase 1
Phase 1 is the initial negotiation of SAs between two IPSec peers. Phase 1 can optionally also include an authentication in which each peer is able to verify the identity of the other. This interaction between two IPSec peers can be subject to eavesdropping with no significant vulnerability of the keys being recovered. Phase 1 SAs are bi-directional—data may be sent and received using the same key material generated. Phase 1 has three possible authentication methods: pre-shared keys (PSK), Digital Certificates, or RSA Encryption (encrypted nonces). This publication focuses on pre-shared keys implementations.
IKE Phase 2
Phase 2 SAs are negotiated by the IKE process (ISAKMP) on behalf of other services such as IPSec, that need key material for operation. Since the SAs used by IPSec are unidirectional, a separate key exchange is needed for data flowing in the forward direction from the reverse direction. This doubles the amount of eavesdropping effort that would be required to successfully recover both sides of an interaction.
IKE Authentication
The two primary methods of configuring VPN devices to authenticate with their respective peers are:
• •
Pre-shared Keys Digital Certificates
These are discussed briefly in the sections that follow.
Pre-shared Keys
Implementing pre-shared keys involves configuration using a set of keys known in advance to both peer VPN devices. As the number of IPSec devices in the VPN grows, scalability becomes an issue because a separate key must be maintained for each IPsec peer. Replacement of a device in the network could also lead to compromise of the keys in use at the time. The scalability testing performed for this publication utilized the pre-shared keys method of authentication.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
B-7
Appendix B Internet Key Exchange (IKE)
High-Level IPSec Overview
Digital Certificates
An alternative to the pre-shared keys method is to implement the use of digital signatures contained in digital certificates. Digital signatures use a trusted third party, known as a certificate authority, to digitally sign the public key portion of the encrypted nonce. Included with the signature is a name, serial number, validity period and other information that an IPSec device can use to determine the validity of the certificate. Certificates can also be revoked, denying the IPSec device the ability to successfully authenticate. The discussion and setup of a certificate authority is beyond the scope of this paper.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
B-8
EDCS-202049
I N D EX
A
aggregation (figure) AH packet (figure)
B-4 2-12
access list for encryption applying crypto maps common mistakes crypto map convergence scenario summary crypto map dynamic
2-8 2-42 2-29 2-41 2-43
2-40
2-41
Authentication Header. See AH.
B
best practices summarized branch site sizing
2-27 2-28
D
data encryption IPSec
2-9
VPN router
Data Encryption Standard. See DES.
C
case study branch site sizing
2-37 2-35 2-33
Dead Peer Detection. See DPD. deployment considerations (table) DES compared to Triple DES design assumptions
2-3 2-3 2-4 2-9 2-7
design considerations head end sizing network layout Cisco IOS pre-classification releases evaluated configuration summary
2-39 2-31 2-36 2-38
enterprise site-to-site VPN
components summary resiliency DHCP
2-20 B-8 2-10
enterprise site-to-site VPN topology (figure)
2-30
digital certificates dynamic crypto map IPSec
2-40 2-42
configuration discussion access list configuration applying crypto maps
2-41 2-43
Dynamic Host Configuration Protocol. See DHCP.
common configuration mistakes crypto map configuration configuration example
2-41
E
EIGRP as part of VPN design
2-10
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
IN-1
Index
configuration fragment recommended for VPN use with GRE (table) encryption Cisco recommendation hardware accelerated software-based DES
2-9 2-9
2-14 2-24
placement of firewall sizing
2-23 2-26
2-18
head-end aggregation effects
2-13 2-8
VPN router
Encapsulating Security Protocol. See ESP.
2-22 2-22 2-32
I
IKE authentication
B-7 B-6
hardware versus software
2-21, 2-32
Diffe-Hellman exchange digital certificates keepalives
2-16 B-7 B-8
encryption algorithms Triple DES ESP packet (figure) summarized
B-3 B-2
pre-shared keys
security association (SA) IP addressing IPSec EIGRP
2-19
B-7
Enhanced Interior Gateway Routing Protocol. See EIGRP.
Internet Key Exchange. See IKE.
IP multicast
2-4
F
firewalls multicast (note)
2-19
IPSec
2-20 B-4 2-32
AH packet (figure) data encryption DHCP
2-20 2-9
compressed RTP not supported
G
Generic Route Encapsulation. See GRE. GRE multicast
2-19 2-17 2-9
dynamic crypto map ESP packet (figure) IP addressing multicast NAT
2-20 2-19 2-19
2-42 B-3
packet expansion protocol overview
packet expansion protocols
B-2
2-17
routing protocols
2-19 B-1
technology overview
H
hash method MD5 SHA-1 head-end load distribution
2-11 2-9 2-9
transport mode tunnel mode IP Telephony
B-6
B-5
IP Security. See IPSec. latency considerations
2-30
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
IN-2
EDCS-202049
Index
K
keys pre-shared
2-42
PAT issues with IPSec VPN performance scenario summary pre-classification pre-shared keys products VPN components summary (table)
2-32 2-5 2-29 2-20
Port Address Translation. See PAT.
L
load distribution head-end
2-11
2-31 2-42, B-7
low-speed lines QoS and VPN
Q
QoS IP Telephony support mechanisms Quality of Service. See QoS.
2-31
M
Maximum Transmission Unit. See MTU. MTU discovery multicast firewalls GRE IPSec
2-19 2-19 2-19 2-19 2-18
R
reverse route injection route propagation recommended strategy routing protocols alternatives to using
2-16 2-13 2-17
support over VPN
N
NAT IPSec
2-20
EIGRP IPSec OSPF
2-4, 2-10, 2-13, 2-21 2-19 2-13 2-13
using across VPN
Network Address Translation. See NAT.
S O
OSPF use in VPN
2-13
scalability testing branch site configuration configuration example head-end configuration methodology
2-21 A-2 A-5 A-3 A-3
P
packet expansion IPSec/GRE (figure)
2-17
network diagram
service-level agreement. See SLA. service provider. See SP.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
IN-3
Index
SLA key elements SP dependencies split tunneling
2-20 2-32 2-20
VPN considerations
2-19
starting assumptions
2-3
T
topology alternatives Triple DES compared to DES troubleshooting common configuration mistakes tunnel aggregation (figure) protocols split
2-19 2-11 B-1 2-12 2-10 2-43 2-8 2-13 2-2
hub-and-spoke
primary and secondary
VPN configuration (figure)
V
virtual primate network. See VPN. VPN Cisco product summary (table) design resiliency
2-10 2-9 2-2 2-5
encryption algorithms routing protocols
2-13
hub-and-spoke topology (figure)
site-to-site best practice summary (table) site-to-site topology (figure) tunneling protocols
B-1 2-4
2-8 2-7
site-to-site deployment considerations (table)
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
IN-4
EDCS-202049
Solution Reference Network Design
Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100
Customer Order Number: 956377
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
y g y p g g Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That’s Possible, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, GigaStack, IOS, IP/TV, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries. All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0201R)
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design Copyright © 2002, Cisco Systems, Inc. All rights reserved.
C ON T E N T S
Preface Scope vii vii vii
Intended Audience
Obtaining Documentation viii World Wide Web viii Documentation CD-ROM viii Ordering Documentation viii Documentation Feedback viii Obtaining Technical Assistance ix Cisco.com ix Technical Assistance Center ix Cisco TAC Web Site x Cisco TAC Escalation Center
1
x 1-1
CHAPTER
Cisco AVVID Network Infrastructure VPN Solution Overview Site-to-Site VPN Benefits References and Reading 1-2 1-3 2-1
CHAPTER
2
Enterprise Site-to-Site IPSec VPNs Solution Overview 2-3 Starting Assumptions 2-3 Design Overview 2-3 Cisco VPN Product Overview
2-5
Solution Design Recommendations 2-6 General Design Considerations 2-7 Solution Characteristics 2-8 IPSec for Data Encryption 2-9 Implementing Generic Route Encapsulation (GRE) Ensuring High Availability and Resiliency 2-10 Head-end Load Distribution 2-11 Number of Tunnels per Device 2-12 Alternative Network Topologies 2-13 Using a Routing Protocol Across the VPN 2-13 Route Propagation Strategy 2-13
2-9
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
iii
Contents
Alternatives to Using a Routing Protocol 2-16 Layer 3 Fragmentation 2-17 Path MTU Discovery 2-18 Planning for Security 2-18 Placement of VPN Head-ends Relative to Firewall 2-18 Split Tunneling 2-19 Supporting Multicast 2-19 IPSec Interactions with Other Networking Functions 2-19 Routing Protocols 2-19 IP Addressing 2-19 Network Address Translation (NAT) and Port Address Translation (PAT) Dynamic Host Configuration Protocol (DHCP) 2-20 Service Provider Dependencies 2-20 Management 2-21 Solution Component Recommendations 2-21 Scalability Testing Methodology 2-21 Hardware-Accelerated Encryption 2-22 Head-end Devices 2-23 Sizing the Head-end 2-23 Cisco VPN Routers for Head-ends 2-26 New Cisco Head-end Products 2-27 Other Cisco Products 2-27 Branch Site Devices 2-27 Sizing the Branch Site 2-27 Cisco VPN Routers for Branch Sites 2-28 New Cisco Branch Site Products 2-29 Other Cisco Products 2-29 Network Performance/Convergence 2-29 Software Releases Evaluated 2-30 Additional Considerations for Latency-Sensitive Traffic 2-30 Quality of Service (QoS) 2-31 Pre-classification of Traffic 2-31 Lower Link Speeds 2-31 Hardware-Accelerated versus Software-Based Encryption Compressed RTP Not Supported by IPSec 2-32 Additional Service Provider Considerations 2-32 Enterprise Site-to-Site VPN Case Study 2-33 Enterprise Organization Overview 2-33 Design Considerations 2-35
2-20
2-32
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
iv
EDCS-202049
Contents
Preliminary Design Considerations 2-35 Sizing the Case Study Head-end 2-36 Sizing the Case Study Branch Sites 2-37 Tunnel Aggregation and Load Distribution 2-37 Network Layout 2-38 Configuration Discussion 2-39 IKE Policy Configuration 2-39 IPSec Transform and Protocol Configuration 2-40 Access List Configuration for Encryption 2-40 Crypto Map Configuration 2-41 Applying Crypto Maps 2-41 Dynamic Crypto Maps 2-42 Common Configuration Mistakes 2-43 ACL Mirroring Error 2-43 Peer Address Mismatch 2-43 Transform Set Mismatch 2-43 IKE Policy Mismatch 2-43
A
APPENDIX
Enterprise Site-to-Site VPN Scalability Test Configuration Scalability Testbed Network Diagram A-1 Scalability Testbed Configuration Files A-3 Head-end Configuration A-3 Branch Site Configuration A-5 High-Level IPSec Overview B-1
A-1
APPENDIX
B
Tunneling Protocols B-1 Introduction to IPSec B-1 IPSec Protocols B-2 Encapsulating Security Protocol (ESP) Authentication Header (AH) B-4 IPSec Modes B-5 Tunnel Mode B-5 Transport Mode B-6 Internet Key Exchange (IKE) B-6 Security Association (SA) B-7 IKE Phase 1 B-7 IKE Phase 2 B-7 IKE Authentication B-7 Pre-shared Keys B-7
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
B-2
v
Contents
Digital Certificates
INDEX
B-8
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
vi
EDCS-202049
Preface
This preface summarizes the following general topics:
• • • •
Scope Intended Audience Obtaining Documentation Obtaining Technical Assistance
Scope
This publication defines the comprehensive functional components required to build a Site-to-Site Enterprise Virtual Private Network (VPN) solution. Cisco Solutions Engineering is dedicated to producing high quality, tested designs that are intended to help deploy the solution product set with confidence. This publication is part of an ongoing series that addresses VPN solutions, using the latest VPN technologies from Cisco, and based on practical design principles that have been tested to scale. This publication focuses on Enterprise site-to-site Virtual Private Networks (VPN) solutions. It addresses the following solution characteristics and technologies:
• • • • • •
IP Security (IPSec) in combination with Generic Routing Encapsulation (GRE) Site-to-site VPN topologies Cisco VPN routers running Cisco Internetwork Operating System (Cisco IOS) Use of Enhanced Interior Gateway Routing Protocol (EIGRP) as a routing protocol across the VPN Data as the primary traffic component Evaluation of Cisco VPN product performance in scalable and resilient designs
Intended Audience
This document covers site-to-site VPN design, planning, and implementation in Enterprise environments. Intended audiences include:
• •
Cisco Systems Engineers (SEs) and Customer Support Engineers (CSEs) Customer and partner network designers, architects, and managers
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
vii
Preface Obtaining Documentation
Obtaining Documentation
The following sections explain how to obtain documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following URL: http://www.cisco.com Translated documentation is available at the following URL: http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.
Ordering Documentation
Cisco documentation is available in the following ways:
•
Registered Cisco Direct Customers can order Cisco product documentation from the Networking Products MarketPlace: http://www.cisco.com/cgi-bin/order/order_root.pl Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store: http://www.cisco.com/go/subscription Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).
•
•
Documentation Feedback
If you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click Leave Feedback at the bottom of the Cisco Documentation home page. After you complete the form, print it out and fax it to Cisco at 408 527-0730. You can e-mail your comments to [email protected].
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
viii
EDCS-202049
Preface Obtaining Technical Assistance
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address: Cisco Systems Attn: Document Resource Connection 170 West Tasman Drive San Jose, CA 95134-9883 We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world. Cisco.com is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to
• • • • •
Streamline business processes and improve productivity Resolve technical issues with online support Download and test software packages Order Cisco learning materials and merchandise Register for online skill assessment, training, and certification programs
You can self-register on Cisco.com to obtain customized information and service. To access Cisco.com, go to the following URL: http://www.cisco.com
Technical Assistance Center
The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center. Inquiries to Cisco TAC are categorized according to the urgency of the issue:
• •
Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration. Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
ix
Preface Obtaining Technical Assistance
• •
Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available. Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.
Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.
Cisco TAC Web Site
The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL: http://www.cisco.com/tac All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register: http://www.cisco.com/register/ If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a Cisco.com registered user, you can open a case online by using the TAC Case Open tool at the following URL: http://www.cisco.com/tac/caseopen If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.
Cisco TAC Escalation Center
The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case. To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL: http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
x
EDCS-202049
C H A P T E R
1
Cisco AVVID Network Infrastructure VPN Solution Overview
This publication identifies the functional requirements to build Cisco AVVID Network Infrastructure (Cisco AVVID NI) Virtual Private Network (VPN) solutions. It identifies individual hardware components and their interconnections, software features, management needs, and service provider (SP) dependencies necessary to facilitate deployment of a manageable and maintainable enterprise VPN solution. This chapter presents benefits and background information as a context for the design recommendations presented in subsequent chapters.
Note
This release of Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design focuses on enterprise site-to-site implementation considerations. Information will be integrated emphasizing other elements of VPN solutions as appropriate. The design scheme presented is based on the Cisco SAFE VPN Architecture. This publication is intended to provide an additional level of information on how to deploy Cisco SAFE VPN. The reader should first be familiar with the Cisco SAFE VPN White Paper. Cisco SAFE documentation can be found at the following URL: http://www.cisco.com/go/safe As an introduction to site-to-site VPN, this chapter presents the following specific topics:
• •
Site-to-Site VPN Benefits References and Reading
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
1-1
Chapter 1 Site-to-Site VPN Benefits
Cisco AVVID Network Infrastructure VPN Solution Overview
Site-to-Site VPN Benefits
This solution design offers a number of advantages over competing approaches to deploying site-to-site VPNs. Table 1-1 summarizes primary benefits of deploying the solution described in this publication.
Table 1-1 VPN Solution Benefits Summary
Solution Design Criteria
Security
VPN Benefits Traffic between branch offices and the central site is encrypted using Triple Data Encryption Standard (Triple DES). A level of redundancy is provided at the head-end, such that the design can tolerate a complete failure of a head-end and recover quickly. A dynamic routing protocol, such as Enhanced Internet Gateway Routing Protocol (EIGRP), can be used to manage network routing and provide fast convergence.
High Availability
Scalability
A building-block approach to scalability is used, such that the design can support thousands of branch-offices, limited only by the number of head-end devices deployed. Scalability testing verified performance with up to 240 branches per head-end device.
Flexibility
Cisco VPN router product line allows customization of head-end and branch office routers. Permits deployment of hardware-accelerated or software-supported encryption. Use of hardware-accelerated encryption is highly recommended. With generic routing encapsulation (GRE), it is possible to build a VPN network that can handle diverse network traffic requirements, including multicast, multi-protocol, and network-layer routing.
Reducing Costs
Many VPN services offer the Enterprise some level of cost reduction.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
1-2
EDCS-202049
Chapter 1
Cisco AVVID Network Infrastructure VPN Solution Overview References and Reading
References and Reading
Table 1-2 and Table 1-3 provide references to related publications relevant when considering VPN deployment.
Table 1-2 Request For Comment (RFC) Papers
RFC RFC2401 RFC2402 RFC2403 RFC2404 RFC2405 RFC2406 RFC2407 RFC2408 RFC2409 RFC2410 RFC2411 RFC2412
Topic Security Architecture for the Internet Protocol IP Authentication Header The Use of HMAC-MD5-96 within ESP and AH The Use of HMAC-SHA-1-96 within ESP and AH The ESP DES-CBC Cipher Algorithm With Explicit IV IP Encapsulating Security Payload (ESP) The Internet IP Security Domain of Interpretation for ISAKMP Internet and Key Management Protocol (ISAKMP) The Internet Key Exchange (IKE) The NULL Encryption Algorithm and Its Use With IPsec IP Security Document Roadmap The OAKLEY Key Determination Protocol
Table 1-3
Related Enterprise VPN Websites
Topic Enterprise VPNs Cisco SAFE Blueprint Cisco Network Security Cisco AVVID Partner Program Cisco VPN Product Documentation Download VPN Software from CCO Improving Security on Cisco Routers
Link http://www.cisco.com/go/evpn http://www.cisco.com/go/safe http://www.cisco.com/go/security http://www.cisco.com/go/securityassociates http://www.cisco.com/univercd/cc/td/doc/product/vpn/ http://www.cisco.com/kobayashi/sw-center/sw-vpn.shtml http://www.cisco.com/warp/public/707/21.html
Essential Cisco IOS Features Every ISP http://www.cisco.com/warp/public/707/EssentialIOSfeatures_pdf.zip Should Consider Increasing Security on IP Networks Cisco TAC Security Technical Tips IP Security (IPSec) Support Page Networking Professionals Connection http://www.cisco.com/cpress/cc/td/cpress/ccie/ndcs798/nd2016.htm http://www.cisco.com/warp/public/707/ http://www.cisco.com/cgi-bin/Support/PSP/psp_view.pl?p=Internetworking:IPSec http://forums.cisco.com
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
1-3
Chapter 1 References and Reading
Cisco AVVID Network Infrastructure VPN Solution Overview
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
1-4
EDCS-202049
C H A P T E R
2
Enterprise Site-to-Site IPSec VPNs
This chapter addresses network design considerations to deploy a site-to-site virtual private network (VPN) based on IP Security (IPSec). Content here focuses on Cisco IOS VPN router products. This publication defines a specific VPN design including a level of resiliency and support for multi-protocols. The design presented is conservative, with an emphasis on engineering a well-performing VPN based on verified parameters. The performance data presented is specific to this design. Other designs are possible and may yield higher or lower performance. The primary topology discussed is a hub-and-spoke deployment model, where the primary enterprise resources are located in a large central site, with a number of smaller sites or branch offices connected directly to the central site over a VPN. A high-level diagram of the network topology is shown in Figure 2-1.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-1
Chapter 2
Enterprise Site-to-Site IPSec VPNs
Figure 2-1
Hub-and-Spoke VPN
Medium sized branches
Central site
Internet
Smaller branches
Corporate network
Large branches
This chapter addresses enterprise site-to-site VPN design in the following sections:
• • • • • •
“Solution Overview” section on page 2-3 “Solution Design Recommendations” section on page 2-6 “Solution Component Recommendations” section on page 2-21 “Additional Considerations for Latency-Sensitive Traffic” section on page 2-30 “Enterprise Site-to-Site VPN Case Study” section on page 2-33 “Configuration Discussion” section on page 2-39
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-2
74167
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Overview
Solution Overview
This section provides an overview of the site-to-site VPN design topology and characteristics:
• • •
Starting Assumptions Design Overview General Design Considerations
Starting Assumptions
The design approach presented in this publication makes several starting assumptions:
• • •
The design supports a typical data traffic profile. Using the VPN for transport of IP telephony and video is not covered in this version of the publication. High availability and resiliency after failover are critically important, therefore the recommendations in this publication reflect the benefits of built-in resiliency and failover with fast convergence. It is assumed that the network has a need for diverse traffic requirements, such as IP multicast, multi-protocol, and/or support for routing. Cisco products in this publication are maintained at conservative CPU utilization levels. While costs were certainly considered, the design recommendations assume that the customer will deploy current VPN technologies, including hardware-accelerated encryption. 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 also valuable for Service Provider (SP)-managed VPNs.
• • • •
Design Overview
VPNs have many applications, including extending reachability of an enterprise WAN, or replacing classic WAN technologies like Leased Line, Frame Relay (FR), and Asynchronous Transfer Mode (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 multi-protocol support, 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 serving as VPN head-end termination devices at a central campus (head-end devices) Cisco VPN access routers serving as VPN branch-end termination devices at branch office locations (branch-end devices) IPSec and GRE tunnels that interconnect the head-end and branch-end devices in the VPN Internet services procured from a third-party ISP (or ISPs) serving as the WAN interconnection medium
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-3
Chapter 2 Solution Overview
Enterprise Site-to-Site IPSec VPNs
Cisco VPN routers are a good choice for site-to-site VPN deployments because they can accommodate most any network requirement inherited from the frame relay or private line network, such as support for multicast and latency-sensitive traffic, routing for resiliency, and support for non-IP protocols like IPX or SNA. The network topology used to illustrate this design is shown below in Figure 2-2.
Figure 2-2 VPN Solution Network Topology
Central site Branch offices
Primary ISP
Secondary ISP Corporate network
IP Connectivity VPN Tunnel
The solution is a hub-and-spoke network with multiple head-end devices for resiliency. Head-ends are high-end tunnel aggregation routers servicing multiple IPSec/GRE tunnels for a prescribed number of branch office locations. In addition to terminating the VPN tunnels at the central site, the head-ends together act as the distribution point for all routing information to and from branch-end devices. Branch-ends are typically access routers that provide IPSec/GRE tunnel(s) for the branch office locations to the central site. In addition to terminating the VPN tunnels, the branch-end often provides WAN access and in some implementations can serve as a firewall. To ensure authentication and encryption, IPSec tunnels are provisioned to interconnect branch offices to the central site. In order to provide a resilient network, this design implements a routing protocol across the VPN. Since IPSec does not provide the ability to run protocols requiring IP multicast—such as Enhanced Interior Gateway Routing Protocol (EIGRP)—IPSec is used in conjunction with GRE. GRE also provides the ability for the customer to support more diverse traffic across the VPN, including IP multicast and non-IP protocols. For high-availability in the case of a failure, each branch-end access router should have two IPSec/GRE tunnels, a primary and secondary, provisioned to two different head-end tunnel aggregation routers.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-4
74168
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Overview
There are several Service Provider (SP) options available to enterprise customers today for deploying a VPN, including the enterprise owning and managing the VPN, seeking only Internet service from ISPs. Optionally an enterprise can outsource its VPN to a SP. In general, the architecture and recommendations provided in this publication are valid for either VPN deployment option— differing only in terms of edge VPN equipment ownership. This publication supports a wide variety of alternatives for deploying a flexible VPN solution that can respond to changing customer requirements. However, the scale of deployment will affect products selected and the configuration difficulty.
Cisco VPN Product Overview
The implementation presented in this publication is focused on using Cisco VPN router products in IPSec-based VPN applications. Table 2-1 provides a summary of the recommended deployment of Cisco VPN router product families to the different head-end and branch-office applications.
Table 2-1 Cisco VPN Product Applications Summary
Application
Central Head-End Site
VPN Router Family Cisco 7200 Cisco 7100 Cisco 3600
VPN Acceleration Options ISA (single or dual), VAM ISM (single or dual), VAM
Maximum Performance1 Up to 140 Mbps Up to 140 Mbps
Scalability Traffic Mix Performance 2 Up to 40 Mbps3 Up to 30 Mbps4 Up to 16 Mbps Up to 16 Mbps Up to 3 Mbps Up to 16 Mbps Up to 3 Mbps Up to 2.5 Mbps Up to 2.5 Mbps Up to 100 kbps
AIM (Base, Medium, High Perform) Up to 38 Mbps AIM (Base, Medium, High Perform) Up to 38 Mbps AIM (Base, Extended Perform) AIM (Base, Extended Perform) VPN Module VPN Module Not Available Up to 14 Mbps Up to 14 Mbps Up to 3 Mbps Up to 3 Mbps Up to 384 kbps AIM (Base, Medium, High Perform) Up to 38 Mbps
Large Branch Office
Cisco 3600 Cisco 2600 Cisco 3600 Cisco 2600 Cisco 1700
Medium Branch Office
Small Office
Cisco 1700 Cisco 800
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and single IPSec/GRE tunnel. 2. Scalability traffic mix evaluation performed with mixed packet sizes, 55 to 65 percent CPU utilization, and up to 240 IPSec/GRE tunnels (in head-end case). 3. This is single ISA performance only. VAM performance with scalability traffic mix is currently under evaluation and will be published in a later revision of this publication. 4. This is single ISM performance only. VAM performance with scalability traffic mix is currently under evaluation and will be published in a later revision of this publication.
A number of new Cisco VPN router products were not available at the time of the scalability testing performed with the design presented in this publication. These include the Cisco 7400, Cisco 3745, Cisco 3725, and Cisco 1760 VPN routers. Refer to the section titled “New Cisco Head-end Products” section on page 2-27 and “New Cisco Branch Site Products” section on page 2-29 for more information. Additional Cisco VPN products, such as the Cisco PIX series and Cisco VPN 3000 Concentrator series, will be included in this publication in a future version.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-5
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Solution Design Recommendations
In designing a VPN deployment, it is essential to integrate broader design considerations, such as high availability and resiliency, security, and potentially quality of service (QoS). This section starts with an overview of some general design considerations that need to be factored into the design. This is followed by a summary of design recommendations, and then additional detailed sections on these recommendations as required. This section presents these considerations in the following specific sections:
• • • • • • • • • • • •
General Design Considerations Solution Characteristics IPSec for Data Encryption Implementing Generic Route Encapsulation (GRE) Ensuring High Availability and Resiliency Using a Routing Protocol Across the VPN Layer 3 Fragmentation Planning for Security Supporting Multicast IPSec Interactions with Other Networking Functions Service Provider Dependencies Management
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-6
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
General Design Considerations
Table 2-2 characterizes the general factors to consider when deploying a site-to-site VPN. Keep in mind that this publication provides general design considerations. Each customer’s network can require customization due to customer-specific requirements.
Table 2-2 General Site-to-site VPN Deployment Considerations
Solution Design Criteria
Network Profile
Solution Question What applications are expected to run over the VPN?
VPN Design Relevance The recommendations in this publication focus on data applications. Multi-service applications such as IP Telephony and video require additional design considerations, such as QoS.
Is multicast and/or IPSec only supports tunneling of unicast-IP traffic. multi-protocol support required? Multicast-IP is required to run a routing protocol across the VPN and to support applications like video. GRE is used in conjunction with IPSec to support multicast and multi-protocols. Does packet fragmentation need In some customer networks, the VPN design needs to to be considered in the design? consider the amount of fragmentation that may occur.
Scalability
How many branches are expected to be aggregated to each central site?
The number of branch offices, plus the amount of traffic expected from each branch, determines how many head-end aggregation devices are required. Improper aggregation can result in a VPN with unacceptable performance. The traffic throughput to/from branches has a direct impact on the number of branches that should be aggregated by a head-end device. If not properly considered, the resulting VPN design can have unacceptable performance. As in the case of a typical enterprise network, a VPN must be resilient to recover in the event of a failure. The design discussed in this guide assumes a customer requires redundancy at the central site that allows for failover between head-end devices. Different methods of IKE authentication necessitate different levels of implementation complexity. For example, configuring pre-shared keys is the least complex method, however scalability can be an issue. Similarly, use of Certificates is highly scalable, yet they are more complex to deploy. VPNs can be deployed with dedicated function devices or as multiple function devices, providing WAN access, firewall, and VPN services.
What is the expected traffic throughput between branch offices and the central site?
Resiliency
What are the expectations for resiliency?
Security
What type of Internet Key Exchange (IKE) authentication method will be implemented?
Services
What other services will run on the device?
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-7
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Solution Characteristics
Table 2-3 summarizes the best practices for deployment of an enterprise site-to-site IPSec-based VPN.
Table 2-3 Enterprise Site-to-site IPsec-based VPN Best Practice Summary
Deployment Objective
Designing the VPN
Best Practice Summary Use IPSec (Tunnel Mode) with Triple Data Encryption Standard (Triple DES) for encryption of data transported1. See “IPSec for Data Encryption” section on page 2-9 for more information. Use GRE tunnels so that multi-service protocols, such as multicast IP, and routing protocols, such as EIGRP, are supported. See “Implementing Generic Route Encapsulation (GRE)” section on page 2-9 for more information. Even if multi-protocol support is not a current requirement, designing the VPN for future flexibility might prevent disruptive redesigns in the future. Configure two tunnels (primary and secondary) between each branch-end to different head-end devices for failover resiliency. See “Ensuring High Availability and Resiliency” section on page 2-10 for tunnel architecture recommendations. Run a routing protocol with route summarization for dynamic routing. See “Using a Routing Protocol Across the VPN” section on page 2-13 for more information. Don’t use IKE keepalives. This is not necessary due to the use of a routing protocol. Keep IPSec packet fragmentation at a minimum on the customer network. See “Layer 3 Fragmentation” section on page 2-17 for several mitigation strategies. Consider the interactions of IPSec with other networking functions. See “IPSec Interactions with Other Networking Functions” section on page 2-19 for more information.
Selecting Cisco VPN Products
Deploy hardware-accelerated encryption in all products that support it. See “Hardware-Accelerated Encryption” section on page 2-22 for more information. Calculate the number of head-end devices based on total tunnel and throughput aggregation requirements, as well as to handle failover. See “Sizing the Head-end” section on page 2-23 for recommendations on choosing the number of head-end devices. Select Cisco VPN Router products at the head-end based on:
• • •
Number of tunnels aggregated (scalability testing has verified performance up to 240 branches per head-end). Throughput aggregated up to the maximum recommendations for each product. Maintaining CPU utilization below 50 percent.
See “Sizing the Head-end” section on page 2-23 for head-end product recommendations. Select Cisco VPN Router products at the branch offices based on the need to maintain:
• • •
Throughput up to the maximum recommendations for each product Maintaining CPU utilization below 65 percent See “Sizing the Branch Site” section on page 2-27 for branch product recommendations.
Use at least the minimum levels of Cisco IOS software as indicated in “Software Releases Evaluated” section on page 2-30.
1. There are various laws and restrictions that govern domestic and international use and export of encryption technology.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-8
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Additional detailed information on these recommendations is discussed in the sections that follow, as required.
IPSec for Data Encryption
There are three elements to consider when securing the traffic which flows over the VPN:
• • •
Authentication—Ensuring the senders/receivers of traffic are known, valid entities Confidentiality—Encrypting data to render it imperceptible without the proper key Message Integrity—Identifying when data has been modified
To ensure confidentiality of data transported over the VPN, encryption algorithms such as Data Encryption Standard (DES) or Triple DES are implemented. Since Triple DES is more secure, it should be implemented if at all possible, except in cases where export restrictions limit the implementation to DES. To ensure message integrity, the IPSec protocol is used with a hash method, such as Message Digest 5 (MD5) or Secure Hash Algorithm 1 (SHA-1).
Note
It is possible to implement only a hash method or only an encryption standard to secure the VPN. However, it is highly recommended that both be implemented in combination. In this publication, the combination of Triple DES and SHA-1 is recommended. With hardware-accelerated encryption implemented, performance is not significantly affected by choice of encryption method. In the future, Advanced Encryption Standard (AES) will be another option for encryption of data. Pre-shared keys were used in the evaluations for this publication. Use of Digital Certificates will be addressed in a future version
Implementing Generic Route Encapsulation (GRE)
While IPSec provides a secure method for tunneling data across an IP network, it has several limitations. First, IPSec does not support broadcast or multicast IP which prevents the use of protocols that rely on their underlying features—such as routing protocols. Second, IPSec does not support the use of multi-protocol traffic, such as IPX or SNA. To overcome these limitations, implement GRE tunnels. GRE is a protocol that can be used to carry other passenger protocols, such as unicast, broadcast or multicast IP, as well as non-IP protocols. This is shown in Figure 2-3.
Figure 2-3 GRE as a Carrier Protocol of IP
IP Transport protocol
GRE Carrier protocol
Network packet Passenger protocol
74173
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-9
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Using GRE tunnels in conjunction with IPSec extends the functionality of the VPN, so that multicast IP can be supported on the network. This provides a critical element of the solution defined in this publication. It enables the ability to run a routing protocol across the network between the central site and branch offices. Even if requirements such as multicast IP, non-IP protocols, or supporting routing protocols do not exist in the current customer network, designing the VPN for greater flexibility prevents costly and potentially disruptive re-designs if these capabilities become requirements in the future. In a GRE-based environment, all traffic between sites is encapsulated in a GRE packet prior to the encryption process. This simplifies the access list used in the crypto map statements since it requires only one line permitting GRE (IP Protocol 47).
Ensuring High Availability and Resiliency
Data networks are often deployed as best effort networks. In such an arrangement, there is no guaranteed network performance and frequently such networks are deployed with single points of failure. With applications being increasingly dependent on network services, networks must be designed to behave in a much more predictable manner. This includes recovery from failures within specific timeframes and the ability to transport the packets to their destination with specific and repeatable (minimized) delays. In all cases, networks should be designed so that the individual elements that make up the network are operating in a resilient environment. These elements include network devices—such as routers and switches—as well as the LAN and WAN links that connect these devices together. In order to provide greater resiliency in the VPN design, Cisco recommends that two tunnels be configured—a primary and secondary—between each branch-end device and the head-ends. Under normal operating conditions, both the primary and secondary tunnels are established. The routing protocol—such as EIGRP—maintains both routes, with the secondary tunnel configured as a less preferred route. Figure 2-4 illustrates this configuration.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-10
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Figure 2-4
High-Availability Tunnel Configuration
Central site
VPN Head-ends
WAN interface router
Branch office
Internet
Primary Secondary
Corporate network
If a failure occurs at one of the head-end devices, the routing protocol detects that the route through the primary tunnel is no longer valid, and after convergence the route through the secondary tunnel is used. Once the primary is available again, traffic will be routed back to the primary tunnel as it is the preferred route in the routing metrics. The head-end resiliency design presented here allows for failure of a single head-end device, with proper failover to surviving head-ends. This is normally adequate when the number of head-ends is relatively low (such as ten or less). If the number of head-ends is relatively high (such as twenty or more), consider designing for the possibility of multiple head-end device failures. It might also be necessary to have head-end devices geographically dispersed. Although not specifically tested, the architecture presented in this publication should readily support this configuration. More information regarding this architecture is also discussed in the Cisco SAFE VPN White Paper. Cisco SAFE documentation can be found at the following URL: http://www.cisco.com/go/safe Configuration of primary and secondary tunnels to appropriate head-ends is critical to maintain network resiliency.
Head-end Load Distribution
When laying out the network topology, be sure to consider load balancing across multiple head-end devices—especially in the case of a head-end device failure. This design recommends at least two tunnels configured between a branch device and the head-end. These guidelines should be followed:
• • •
The primary tunnels should be configured to carry traffic under normal circumstances. The preferred primary tunnels should be evenly divided among the head-end devices. Secondary tunnels should be configured with a delay command statement to make the primary the preferred tunnel route.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-11
74174
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
•
The secondary tunnels for branches should be evenly spread among the remaining (surviving) head-end devices. It would be highly undesirable for all the tunnels from a failed head-end device to re-establish to a single secondary head-end device when there are other devices available to distribute the load from the failed device. Figure 2-5 illustrates a typical network topology with high resiliency.
Figure 2-5
Tunnel Aggregation for Resiliency
Head-end devices
Primary Tunnels Secondary Tunnels
Branch office devices
To plan for proper tunnel aggregation and load distribution in the case of a head-end device failure, the following algorithm should be used:
1. 2. 3. 4. 5.
Start with the number of total branch devices to be aggregated at the head-end. Divide this number by the number of head-end devices. Multiply the result by two for primary and secondary tunnels. This is the total number of tunnels per head-end device. Allocate the primary tunnels to each head-end device in the arrangement shown in Figure 2-5. For each group, allocate the secondary tunnels in a round-robin fashion to all head-end devices except the one serving as a primary for that group. This arrangement is also shown in Figure 2-5 above.
Please note that this calculation should take into account the amount of traffic being aggregated. Adjustments might be necessary to account for tunnel throughput variances.
Number of Tunnels per Device
The number of tunnels required for each head-end device should be scaled to the overall size of the network in which the VPN solution is being deployed. Please refer to “Sizing the Head-end” section on page 2-23 for more information.
Note
In testing the design presented in this publication, head-end scalability testing did not include an exhaustive evaluation of the maximum number of tunnels that may be terminated to head-end devices. In addition, scalability testing of branch site devices was performed with two tunnels per branch device and did not include exhaustive testing of the number of tunnels these different platforms can support.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-12
74175
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Alternative Network Topologies
The design presented in this publication is a typical hub-and-spoke topology. Other possible topologies include partially meshed and fully meshed networks. While these alternative topologies can be implemented in an IPSec VPN, they can increase the complexity of the design and configuration due to the number of peers per device in such a network. For example, the larger number of active tunnels per peer in a meshed network places a greater performance burden on devices running IPSec—possibly requiring more CPU and memory resources. The configuration of these devices also becomes more complex. At a minimum, an additional access list must be created for each peer connection, as well as additional crypto map entries. A new feature named Dynamic Multipoint VPN (mGRE+NHRP) will make such configurations easier in the future. In addition, the routing protocol (as is recommended in this publication) must deal with many more adjacencies, nullifying efficiencies associated with routing protocols, such as summarization and stub features. A fully meshed and partially meshed topology are possible, but like any network, these deployments should be carefully designed and tested prior to roll out. Partial- and full-mesh topologies have not been subjected to scalability testing for this publication.
Using a Routing Protocol Across the VPN
This design recommends the use of a routing protocol to propagate routes from the head-end to the branch offices. Using a routing protocol has several advantages over the current mechanisms in IPSec alone:
•
VPN receives the same benefit as using routing protocols on a traditional network—this includes receiving information about the network connectivity available over a particular interface, topology information about a network, notification when that topology changes (such as when a link fails), and information about the status of remote peers. While there are alternatives to using a routing protocol, most of these alternatives only offer the ability to verify the health of the VPN device. With a routing protocol, it is possible to verify that traffic is actually reaching its destination.
•
There are several routing protocols that are candidates for operation over the VPN, including EIGRP and Open Shortest Path First (OSPF). The principles presented in this publication use EIGRP as the routing protocol, as EIGRP was used during scalability tests conducted. EIGRP was selected due to its conservative use of router CPU and network bandwidth as well as its quick convergence. EIGRP also provides a range of options for address summarization and default route propagation. Routing protocols do increase the CPU utilization on a network device and their use must be taken into consideration when sizing those devices.
Route Propagation Strategy
There are a number of approaches to propagating routes from the head-end to the branch offices. For this design, the recommended approach is for each head-end router to advertise a default route to each of the terminated tunnels. The branch router will prefer the primary tunnel via a lower routing metric for the primary path. Consider the example topology illustrated in Figure 2-6.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-13
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Figure 2-6
Route Propagation Example
Central site
VPN Head-ends 131.108.251.2 Primary Secondary 131.108.252.2 Internet 131.108.153.2
Branch office
10.57.2.0
10.63.223.0
74603
In the example illustrated in Figure 2-6, the ISP has assigned public IP addresses 131.108.251.2 and 131.108.252.2 for our central site head ends and 131.108.153.2 for our branch office. The corporate LAN at the central site is privately addressed as network 10.57.2.0, while the branch office LAN is privately addressed as network 10.63.223.0. The configuration excerpts presented in the following sections would be used to establish appropriate tunnels and routing (assuming EIGRP as the routing protocol).
Head-end Router (Primary) Configuration Excerpt
interface Tunnel151 ip address 10.62.223.193 255.255.255.252 ip summary-address eigrp 1 10.0.0.0 255.0.0.0 5 tunnel source FastEthernet1/0 tunnel destination 131.108.153.2 crypto map static-map ! interface FastEthernet1/0 ip address 131.108.251.2 255.255.255.252 duplex full speed 100 crypto map static-map ! interface FastEthernet1/1 description FastEthernet1/1 ip address 10.57.2.1 255.255.255.0 duplex full speed 100 ! router eigrp 1 network 10.0.0.0 no auto-summary eigrp log-neighbor-changes ! ip route 0.0.0.0 0.0.0.0 131.108.251.1
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-14
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Head-end Router (Secondary) Configuration Excerpt
interface Tunnel151 ip address 10.62.223.197 255.255.255.252 ip summary-address eigrp 1 10.0.0.0 255.0.0.0 5 delay 60000 tunnel source FastEthernet1/0 tunnel destination 131.108.153.2 crypto map static-map ! interface FastEthernet1/0 ip address 131.108.252.2 255.255.255.252 duplex full speed 100 crypto map static-map ! interface FastEthernet1/1 description FastEthernet1/1 ip address 10.57.2.2 255.255.255.0 duplex full speed 100 ! router eigrp 1 network 10.0.0.0 no auto-summary eigrp log-neighbor-changes ! ip route 0.0.0.0 0.0.0.0 131.108.252.1
Branch Site Router Configuration Excerpt
Branch Site Router interface Tunnel0 ip address 10.62.223.194 255.255.255.252 ip summary-address eigrp 1 10.62.233.0 255.255.255.0 5 tunnel source Serial0/0 tunnel destination 131.108.251.2 crypto map static-map ! interface Tunnel1 ip address 10.62.223.198 255.255.255.252 ip summary-address eigrp 1 10.62.233.0 255.255.255.0 5 delay 60000 tunnel source Serial0/0 tunnel destination 131.108.252.2 crypto map static-map ! interface Serial0/0 ip address 131.108.153.2 255.255.255.252 crypto map static-map ! interface Ethernet0 ip address 10.63.223.1 255.255.255.0 ! router eigrp 1 network 10.0.0.0 no auto-summary eigrp log-neighbor-changes ! ip route 0.0.0.0 0.0.0.0 Serial0/0
IPSec/GRE tunnels are established using the public IP addresses as the tunnel sources and destinations. The central site advertises a route for 10.0.0.0/8 to the branch office. The branch advertises a more specific route for 10.62.233.0/24 to each head-end (primary and secondary).
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-15
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Note that the branch office VPN router is configured with two tunnels—one to its assigned primary head-end and one to its secondary (backup) head-end. The delay statement is used to slightly differentiate the cost of the two routes, making the primary head-end the preferred route. The delay statement must be applied on both the branch and head-end sides of the secondary tunnel. A default route is also configured with the next hop address of the ISP. This is required in order for the tunnel to be established. Once active, the more specific routes provided by dynamic EIGRP routing will be used to actually route traffic to the appropriate VPN tunnel. This example is intended to represent a fairly simple case with a single central site location and single connection to the ISP. Depending on a variety of variables—such as the specific network topology, connections to an ISP, the use of multiple central sites, and/or the use of multiple ISP connections—the routing strategy might require additional analysis and planning. For additional configuration issues, refer to “Configuration Discussion” section on page 2-39.
Alternatives to Using a Routing Protocol
For this publication, the approach recommended is the use of a routing protocol to propagate routes and network state information between the central site and branch locations. There are several alternatives to this approach:
• • •
IKE Keepalives Dead Peer Detection (DPD) Reverse Route Injection
These alternatives are useful to consider because, if an IPSec peer fails, the other peer can continue sending packets to that peer until the Security Association (SA) associated with that peer times out. To avoid this black hole effect some sort of status update is needed. Each of the three alternative to a routing protocol solution is discussed briefly in the sections that follow.
IKE Keepalives
IKE keepalives work by sending keepalive messages between IPSec peers whether or not a particular peer has had any communications with its remote peer. The resulting messages and counters cause significantly higher CPU utilization on IPSec devices, lowering the potential scalability. Using IKE keepalives is therefore not recommended in this solution design.
Note
The use of IKE Keepalives has not been evaluated for scalability as of this publication.
Dead Peer Detection (DPD)
Dead Peer Detection (DPD) is a relatively new Cisco IOS feature—targeted at providing efficient IPSec peer state detection—as a better alternative to IKE Keepalives. DPD works by sending keepalive messages to active IPSec peers that it has not received a message from within a specified period of time. This results in a lower impact on the CPU utilization of the IPSec device and corresponding higher potential scalability.
Note
The use of IPSec DPD has not been evaluated for scalability as of this publication.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-16
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Reverse Route Injection
Another relatively new Cisco IOS feature is Reverse Route Injection. Reverse Route Injection functions by taking the information derived from the negotiated IPSec SA's and injecting that information into the routing protocol running on a particular router. This reduces the need to have a routing protocol running across the actual VPN tunnels themselves. One of the limitations of Reverse Route Injection is that it will only inject information derived from the negotiated IPSec SAs. Any networks present that are not included in the access control list (ACL) that is used for the IPSec policy would not be present in the injected routes. As an example, consider an environment in which multiple networks are present behind a router functioning as the VPN termination device. Each network must be specifically called out in the ACL included in the crypto map statement if the networks are not summarized by that ACL. Another example is the use of GRE tunnels for support of other protocols (such as multicast IP). The ACL specified in the crypto map only lists the IP address of the GRE interface and the SA is not carrying information about the network traffic carried inside the GRE tunnel.
Note
The use of IPSec Reverse Route Injection has not been evaluated for scalability as of this publication.
Layer 3 Fragmentation
IPSec and GRE headers increase the size of packets being transported, as illustrated in Figure 2-7. If the size of a packet before encryption is near the Maximum Transmission Unit (MTU) of the transmission media, the encrypted packet with the additional IPsec and GRE headers can exceed the MTU of the transmitting interface.
Figure 2-7 IPSec/GRE Packet Expansion
IP packet
IP Hdr 20 bytes
Data Large
GRE added
New IP Hdr 20 bytes
GRE 4 bytes
IP Hdr 20 bytes
Data Large
IPSec added (tunnel mode)
New IP Hdr 20 bytes
IPSec 32 bytes variable
New IP Hdr 20 bytes
GRE 4 bytes
IP Hdr 20 bytes
Data Large
74176
MTU size
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-17
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
This resulting Layer 3 packet fragmentation requires these packets to be reassembled prior to the de-cryption process. In Cisco IOS implementations prior to 12.1(11)E and 12.2(12)T, for some customer networks this resulted in less than optimal throughput performance. This is avoided by either:
1. 2.
Employing path MTU discovery (PMTU discovery). See “Path MTU Discovery” section on page 2-18 for more information on this method. Setting the MTU of attached workstations to allow for packet expansion, such as 1400 bytes.
For some customer networks, it might not be possible to easily manage MTU size. For these situations, Cisco has implemented Pre-fragmentation for IPSec VPNs. This feature is available in Cisco IOS 12.1(11)E for head-end platforms and 12.2(12)T for branch platforms.
Path MTU Discovery
A feature of IP called path MTU discovery can eliminate the possibility of fragmentation if it is supported by the end stations. This is a procedure that is run between two end stations with the participation of the network devices between them. During path MTU discovery, an MTU-sized packet is sent out by an end station with the don't fragment (DF) bit set. If this packet encounters a link with a lower MTU than the packet size, an ICMP error message is generated with a value of 3 in the type field (destination unreachable), a value of 4 in the code field (fragmentation needed and DF set) and the next hop’s MTU size in the unused field of the ICMP header. In order for this process to work over an IPSec network with GRE, the GRE tunnel MTU should be set to a value low enough to ensure that the packet will make it through the encryption process without exceeding the MTU on the outbound interface—usually 1400 bytes.
Planning for Security
In planning for deployment of a site-to-site VPN topology, it is necessary to consider the integration of enterprise network security functions. There are various enterprise security components that complement and enhance the VPN solution. For more information on how to integrate these essential security components, please refer to the Cisco SAFE security blueprint and seminar series. Cisco SAFE documentation can be found at this URL: http://www.cisco.com/go/safe
Placement of VPN Head-ends Relative to Firewall
The placement of the VPN head-end devices in the network relative to the enterprise’s firewall can critically affect the security of any VPN deployment. Recommended architectures are discussed in the Cisco SAFE VPN White Paper. Cisco SAFE documentation can be found at this URL: http://www.cisco.com/go/safe
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-18
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Design Recommendations
Split Tunneling
Split tunneling is the process by which packets being transmitted from a site can be either protected by IPSec or unprotected, depending upon their destination. When split tunneling is configured for a branch site, that site must be protected by a stateful firewall.
Note
Split tunneling has not been addressed within this design.
Supporting Multicast
The popularity of multimedia applications, such as video, has led many network administrators to support multicast traffic on their networks. VPNs can also support these applications. IPSec supports only tunneling of unicast IP traffic; therefore, it is necessary to implement GRE in conjunction with IPSec to support multicast. See “Implementing Generic Route Encapsulation (GRE)” section on page 2-9 for more information.
Note
Multicast traffic is not currently supported by most firewalls. This would require the termination of the IPSec tunnels on the inside interface of the firewall.
IPSec Interactions with Other Networking Functions
Because IPSec hides the packet and increases the packet size, interactions with other networking functions must be taken into consideration. The following sections discuss various aspects to consider when deploying site-to-site IPSec-based VPNs:
• • • •
Routing Protocols IP Addressing Network Address Translation (NAT) and Port Address Translation (PAT) Dynamic Host Configuration Protocol (DHCP)
Routing Protocols
All IP routing protocols use either broadcast or multicast as a method of transmitting routing table information. Since IPSec does not support either broadcast or multicast, Cisco recommends using Generic Routing Encapsulation (GRE) as a tunneling method to overcome this limitation. See “Implementing Generic Route Encapsulation (GRE)” section on page 2-9 for more information on GRE and “Using a Routing Protocol Across the VPN” section on page 2-13 for more information on running a Routing Protocol across the VPN.
IP Addressing
Proper IP addressing is critical for a successful VPN. In order to maintain scalability, performance, and manageability, it is highly recommended that remote sites use a subnet of the major network to allow for summarization. This way the crypto Access Control Lists (ACLs) will contain a single line for every local network; possibly a single entry if the local networks can be summarized.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-19
Chapter 2 Solution Design Recommendations
Enterprise Site-to-Site IPSec VPNs
Proper address summarization is highly recommended. Address summarization conserves router resources making routing table sizes smaller. Address summarization also saves memory in routers, and eases troubleshooting tasks. In addition to conserving router resources, address summarization also simplifies the configuration of routers in IPSec networks. Please consult the IP Addressing section of the Cisco SAFE VPN White Paper for a more thorough discussion. Cisco SAFE documentation can be found at: http://www.cisco.com/go/safe
Network Address Translation (NAT) and Port Address Translation (PAT)
While Network Address Translation (NAT) and Port Address Translation (PAT) can result in an added layer of security and address conservation, the presence of NAT or PAT in between IPSec peers presents challenges to the implementation of an IPSec VPN. In the case of PAT, IPSec peers with a PAT process between them will fail to negotiate properly. Internet Key Management Protocol (ISAKMP) relies on an individual IP address per peer for proper operation. PAT works by masquerading multiple peers behind a single IP address. Site-to-site IPSec networks can operate between NAT processes. However, the un-translated peer must be configured with the remote peer’s translated address for proper operation.
Dynamic Host Configuration Protocol (DHCP)
In order for a host at a remote site to be able to use a Dynamic Host Configuration Protocol (DHCP) server over an IPSec tunnel at a central site, an IP helper address must be configured on the router interface associated with the host. Unfortunately, if connectivity to the central site is lost, a host at a remote site might not receive an IP address. This can prevent the host from communicating with other hosts on its local network. A Cisco IOS router can also be configured to act as a stand alone DHCP server; however, these features have not been tested with IPSec VPN in preparing this publication version.
Service Provider Dependencies
VPNs inherently rely on one or more SPs to provide Internet service to the head-end and branch offices in order to deploy the network, so choosing a SP is a critical element of deploying a VPN. Many factors have to be considered including cost, services available, reliability, and the expected geographical coverage of the customer’s VPN. At a minimum, the enterprise should have a service-level agreement (SLA) with the SP that outlines the critical service elements of its VPN. Factors to address include availability, bandwidth, and latency. When the situation requires an enterprise to use multiple SPs to cover its branch locations, an added a level of complexity can be imposed. Obtaining the desired level of end-to-end VPN service can be more difficult—especially in a case involving delay-sensitive, mission-critical applications. Future considerations of running latency-sensitive applications, such as IP Telephony and video, across the VPN must also be considered. For these reasons, Cisco recommends obtaining an SLA with a single SP that can guarantee adequate end-to-end service for all enterprise locations.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-20
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Component Recommendations
Another issue to be aware of is that some Internet SPs for DSL and cable services implement policing of traffic for residential class service. This means that protocols such as IPSec might be blocked unless a business class service subscription is established.
Management
Cisco brings all of its VPN products together through management systems that provide such status information as device availability and throughput, for example, management integration through products such as VPN/Security Management Solution (VMS) and VPN Solution Center (VPNSC). A later version of this publication will discuss how Cisco brings together configuration management, security policy management, quality-of-service management, and infrastructure management on Cisco concentrators, routers, and firewalls. For more information on how implement network management over IPSec tunnels, please refer to the Cisco SAFE security blueprint and seminar series. Cisco SAFE documentation can be found at this URL: http://www.cisco.com/go/safe
Solution Component Recommendations
This chapter presents the steps to selecting Cisco products for a deployable VPN solution, starting with sizing the head-end, and then choosing Cisco products that can be deployed for head-end devices. It concludes with product sizing and selection information for branch-end devices. Specific sections include:
• • • • • •
Scalability Testing Methodology Hardware-Accelerated Encryption Head-end Devices Branch Site Devices Network Performance/Convergence Software Releases Evaluated
Scalability Testing Methodology
The scalability testbed included 240 branch offices aggregated to two head-end devices as illustrated in Appendix A, “Enterprise Site-to-Site VPN Scalability Test Configuration.” Aggregation to three head-ends was also tested for comparison purposes. The head-ends consisted of the Cisco 7100 and Cisco 7200 Series VPN router products (see “Head-end Devices” section on page 2-23 for models tested). The branch offices consisted of Cisco VPN router products from the Cisco 800, Cisco 1700, Cisco 2600, and Cisco 3600 Series routers (see “Branch Site Devices” section on page 2-27 for models tested). Head-end products were evaluated with hardware-accelerated encryption installed, while branch products were evaluated with both software-based encryption and hardware-accelerated encryption. Triple DES was selected as the encryption standard and SHA-1 as the hash method. Each branch router was provisioned with two IPSec/GRE tunnels (primary and secondary) back to two different head-ends. EIGRP was used as the routing protocol to distribute routes from the head-ends to the branches. Note that the testing was conducted with a fully summarized network configuration.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-21
Chapter 2 Solution Component Recommendations
Enterprise Site-to-Site IPSec VPNs
Some performance tests use the IMIX standard for specification of packet sizes. Typically these tests then continually send streams of the specified packet sizes to a device under test to evaluate its performance. In this particular scalability test, instead of streams of particular packet sizes, realistic traffic flows were established using the NetIQ Chariot testing tool. The mix of traffic was approximately 35 percent UDP and 65 percent TCP. A comparison of IMIX and the traffic profile used during this evaluation is shown in Table 2-4.
Table 2-4 Comparison of IMIX and Traffic Profile
Cisco Scalability Test G.729 RTP (64-byte packets)—50 pps DNS (100-byte packets)—4 flows FTP (1400-byte packets)—1 flow
IMIX 40-byte packets—7 parts 576-byte packets—4 parts 1500-byte packets—1 part
Although not matched one-for-one with the IMIX standard, the traffic profile used in this evaluation is believed to yield conservative performance data. This is due to two factors:
• •
The Chariot streams simulate realistic traffic flows instead of packet blasting. This profile contains a significant percentage of small packets, a somewhat more aggressive profile than IMIX.
The evaluation was then performed by increasing traffic rates using this profile to find the throughput points on each product where the CPU utilization reached the defined limits (50 percent for head-ends, 65 percent for branch routers). Additionally, zero packet loss was permitted. Individual product throughput performance data is presented in “Cisco VPN Routers for Head-ends” section on page 2-26 for head-end products and “Cisco VPN Routers for Branch Sites” section on page 2-28 for branch end products. In addition to throughput testing, failover testing was also conducted. Please see to “Network Performance/Convergence” section on page 2-29 for more information on the failover test scenario. All scalability testing for this publication was performed using IPSec Tunnel Mode; the throughput results might differ in Transport Mode.
Hardware-Accelerated Encryption
The scalability testing performed as part of the VPN solution development indicates a strong need for hardware-accelerated encryption to achieve predictable performance results. For head-end devices, all throughput results presented in this design guide and the recommended architecture assume that hardware-acceleration is implemented. For branch-end devices, both software-based encryption and hardware-accelerated encryption were evaluated. Throughput performance was significantly increased (up to 80 percent) with the addition of hardware-accelerated encryption. For these reasons, Cisco strongly recommends hardware acceleration in all devices performing encryption. This is especially true if:
• •
Triple DES encryption is being implemented. Significant data throughput requirements exist.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-22
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Component Recommendations
•
Multi-service applications, such as IP Telephony, are to be run over the VPN.
Cisco has different names for the acceleration modules of the Cisco 7200 and Cisco 7100 families. The Integrated Services Adapter (ISA) be used on the Cisco 7100 or Cisco 7200. The Integrated Services Modules (ISM) can be used on the Cisco 7100. They offer comparable performance. Multiple cards (dual ISA on a Cisco 7200, ISM+ISA on Cisco 7100) can be used to increase encryption throughput. Although not yet evaluated in scalability testing, the VPN Acceleration Module (VAM) is another high-performance VPN encryption option. For branch access routers, hardware-acceleration components are typically Advanced Integration Modules (AIM). See “Cisco VPN Routers for Head-ends” section on page 2-26 and “Cisco VPN Routers for Branch Sites” section on page 2-28 for more detailed performance data that supports this recommendation.
Head-end Devices
The head-end devices are responsible for:
• • •
Originating/terminating IPSec encapsulated GRE tunnels from the branch sites Running routing protocol inside GRE tunnels to advertise internal routes to branches Providing resiliency to eliminate the possibility of a single point of failure
The next sections identify factors to take into account in sizing the head-end (or sites). Specific sections include:
• • •
Sizing the Head-end Cisco VPN Routers for Head-ends Other Cisco Products
Sizing the Head-end
Sizing the head-end correctly before choosing the devices to deploy ensures that the overall network can support the intended (and possibly future) traffic profiles to be run over the VPN. Two critical factors must be considered when sizing the head-end:
• •
How many branch offices must be connected to the head-end? This provides the number of primary tunnels requiring aggregation. What is the expected traffic profile, including the average packets-per-second (pps) and bits-per-second (bps) throughput rates for each branch office? This provides the aggregated data throughput required across the VPN.
These factors can limit sizing the head-end and must be considered together. The decision flow shown below in Figure 2-8 should be applied to size the head-end.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-23
Chapter 2 Solution Component Recommendations
Enterprise Site-to-Site IPSec VPNs
Figure 2-8
Head-end Sizing Decision Flow
Calculate Headend Devices based on Number of Tunnels C(t) Which is greater ? Consider Headend Product Options Calculate Headend Devices based on Branch Throughput C(a)
How many branches?
Throughput per branch?
Preliminary Estimate
Other Factors ?
Adjust according to other known factors
Final Estimate
74178
Note
This design assumes a level of resiliency at the head-end to handle a failover scenario. Scalability testing was conducted up to and including 240 tunnels per head-end. The Cisco VPN Router products evaluated as head-end devices are often capable of aggregating more than 240 tunnels. Ultimate peer scalability is dependent on numerous factors including resiliency design, routing, and other services running on the device. Using a routing protocol (such as EIGRP as in this design) also affects the number of peer devices that can be effectively aggregated to a particular head-end. To date, support for 240 peers has been verified in scalability testing. Again, more peers per head-end are possible, but planning using an initial limit of 240 is recommended, as this configuration has been verified. A future version of this publication will contain scalability performance data for higher than 240 peers. Based on the number of branch offices, the required number of head-end devices, C(t), can be sized with the following algorithm: N = Total number of branch offices T = Total number of tunnels = N x 2 (for primary and secondary tunnels) C(t) = (T / 240) rounded up to next full integer + 1 (for resiliency) For example, an enterprise with 950 branch offices would require nine head-end devices for a resilient design, as follows: N = 950 T = 1900 C(t) = 1900/240 rounded up + 1 = 9 The next step is to obtain traffic profile data that indicates expected average throughput (pps and bps) for each branch office and head-end device.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-24
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Component Recommendations
The aggregate throughput is then calculated by adding up all of the throughput estimates for all branch offices. Next consider the available head-end devices and the maximum throughput supported by each. The Cisco 7140 and Cisco 7200VXR routers are the preferred platforms for use as IPSec VPN head-end devices. Each of these routers has a range of options for interfaces as well as the ability to configure hardware-accelerated encryption. See “Cisco VPN Routers for Head-ends” section on page 2-26 for more details on product selection and throughput performance. Now divide the aggregate throughput requirements by the throughput value for each respective platform (please refer the values provided in Table 2-5 discussed in “Cisco VPN Routers for Head-ends” section on page 2-26). This will provide the number of head-end devices required, based on aggregate throughput: A = Sum of throughput estimates for each branch office (i.e. the aggregate) H = Single head-end device throughput C(a) = A/H, rounded up to nearest full integer, + 1 for resiliency For example, an enterprise with 300 branch offices, each having throughput requirements of 500 Kbps would require six head-end devices for a resilient design, as follows: A = 300 branches @ 500 Kbps = 300 x 0.5 Mbps = 150 Mbps H = 30 Mbps (for Cisco 7140 router) C(a) = 150/30 (rounded to next nearest integer) + 1 = 6 Compare the number of head-end devices calculated based on number of tunnels, C(t), to the number based on aggregate throughput, C(a). The greater of the two numbers is the required number of head-end devices to support the design outlined in this publication. As the number of tunnels increases there is a corresponding increase in CPU utilization. This means that a design that has a uniformly distributed traffic load from branch offices across many tunnels will require more CPU than a design where the majority of traffic load is generated from a subset of the total tunnels being aggregated. In addition to the two critical factors identified above, the following factors must also be considered at this point:
1.
Given the current network topology and traffic profile, what is the current CPU utilization on each distribution router, and how many branch offices are connected to each distribution router? This provides a baseline of expected CPU utilization levels. The combination of crypto/IPSec and GRE will add additional overhead to each distribution router.
2.
What are the aggregate WAN sizes for each respective branch? How the aggregate WAN speed is subdivided into a number of tunnels will affect the overall number of tunnels that can be supported in this design. As discussed previously, as the number of tunnels increases, there is a corresponding decrease in throughput (or an increase in CPU utilization).
3.
What other applications/protocols does the customer intend to run across the VPN? Multi-protocol implementations perform differently in a Cisco IOS environment compared to unicast-IP implementations. In the scalability testing performed to date, multi-protocols have not been comprehensively evaluated.
The end result is that the number of head-end devices might need to be adjusted upward after these additional factors are considered.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-25
Chapter 2 Solution Component Recommendations
Enterprise Site-to-Site IPSec VPNs
In the design presented in this publication, head-end device CPU utilization does not exceed 50 percent. This conservative recommendation ensures that the device has enough performance left over to deal with various events that take place during the course of normal network operations. Typical events include network reconvergence in the event of a failure, rekeying IPSec SAs, and bursts of traffic seen in a normal operating network. After initial deployment and testing, it might be possible to run head-end devices at CPU utilization levels higher than 50 percent (60 to 65 percent for example). However, this publication conservatively recommends staying at or below 50 percent—as a result the throughput results presented where chosen at the 50 percent level.
Cisco VPN Routers for Head-ends
Cisco has an array of VPN routers suitable for head-end deployments. These include the Cisco 7100, Cisco 7200, and Cisco 3600 Series routers. Specific platforms were selected from within each product family for evaluation. All products were configured with hardware-accelerated encryption enabled. Each product supports several hardware-accelerated encryption options. For example, both the Cisco 7100 and Cisco 7200 Series can be configured with one or two ISA/ISM cards or the newer VAM. The Cisco 3600 Series can be configured with different AIM performance levels, including Base (AIM-BP), Medium (AIM-MP) or High (AIM-HP) depending on platform. The configurations selected for scalability testing, along with the throughput thresholds attained (at 50 to 55 percent CPU utilization and 240 tunnels configured) are shown Table 2-5. Due to test limitations, traffic was generated over a subset of the configured tunnels in this particular scalability test.
Table 2-5 Head-end Products Throughput
Head-end Router Platform Cisco 7200VXR NPE-400
Hardware Acceleration Maximum Option Performance1 SA-ISA (1) VAM 90 Mbps 140 Mbps 90 Mbps 140 Mbps 90 Mbps 140 Mbps See branch results in Table 2-7
Scalability Traffic Mix Performance2 40.0 Mbps To be added in future publication version 30.0 Mbps To be added in future publication version 30.0 Mbps To be added in future publication version See branch results in Table 2-7.
Cisco 7200VXR NPE-300
SA-ISA (1) VAM
Cisco 7140
SA-ISM (1) VAM
Cisco 3660
AIM-HP (1)
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and single IPSec/GRE tunnel. 2. Scalability traffic mix evaluation performed with mixed packet sizes, 55 percent CPU utilization, and up to 240 IPSec/GRE tunnels.
In this version of the publication and corresponding scalability tests, the Cisco 3600 Series was evaluated only as a branch device. However, the Cisco 3600 Series can also be implemented as a head-end device. Scalability testing is currently underway for this configuration. See “Cisco VPN Routers for Branch Sites” section on page 2-28 for more information on the Cisco 3600 Series as a branch device.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-26
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Component Recommendations
New Cisco Head-end Products
A number of new Cisco VPN router products were not available at the time of the scalability testing performed with the design presented in this publication. Table 2-6 shows the latest Cisco VPN router products targeted for use as head-end devices, along with their measured maximum performance.
Table 2-6 Latest Cisco VPN Head-end Router Products
Head-end Router Platform Cisco 7400 Cisco 3745 Cisco 3725
Hardware Acceleration Option VAM AIM-EP AIM-EP
Maximum Performance1 Up to 120 Mbps Up to 40 Mbps Up to 40 Mbps
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and single IPSec/GRE tunnel.
Other Cisco Products
Several other Cisco products support IPSec VPN tunnel termination in a head-end environment, including the Cisco VPN3000 Concentrator and the Cisco PIX Firewall Series products. These platforms were not part of the scalability testing and therefore are not fully discussed. See the following links for more product information on the Cisco VPN3000 and Cisco PIX Series:
• •
http://www.cisco.com/warp/public/cc/pd/hb/vp3000/ http://www.cisco.com/warp/public/cc/pd/fw/sqfw500/
Branch Site Devices
The branch site devices are responsible for:
• •
Originating/terminating IPSec encapsulated GRE tunnels from the head-end Running a routing protocol inside of the GRE tunnels to advertise internal routes
The next sections identify factors to take into account when sizing the branch sites. Specific sections include:
• • •
Sizing the Branch Site Cisco VPN Routers for Branch Sites Other Cisco Products
Sizing the Branch Site
The most important factor to consider when choosing a product for the branch office is expected traffic throughput. Secondary factors that should be considered include:
•
Other features/functionality that the branch router will be providing, such as WAN access, IP Telephony, DHCP, or Cisco IOS firewall.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-27
Chapter 2 Solution Component Recommendations
Enterprise Site-to-Site IPSec VPNs
•
Differences in the range of features that branch devices can accommodate. For example, the Cisco 3660 supports six modular slots and various WAN adapters, while the Cisco 2600 series supports only two slots.
While the number of IPSec tunnels will not play as large a role in the branch device sizing, each branch site router must be able to terminate at least two IPSec-encapsulated GRE tunnels (primary and secondary). The principal concern is the amount of traffic throughput along with the corresponding CPU utilization. In the design presented in this publication, branch device CPU utilization does not exceed 65 percent. This conservative recommendation ensures that the device has enough performance left over to deal with various events that take place during the course of normal network operations. The CPU utilization on a branch site may run slightly higher than a head-end router due to minimal routing convergence duties associated with branch routers. After initial deployment and testing, it might be possible to run branch devices at CPU utilization levels higher than 65 percent. However, this publication conservatively recommends staying at or below 65 percent, and therefore the throughput results presented where chosen at the 65 percent level.
Cisco VPN Routers for Branch Sites
Cisco has a line of VPN routers suitable for branch site deployments. These include the Cisco 3600, Cisco 2600, Cisco 1700, and Cisco 800 Series routers. All branch devices except the Cisco 800 Series support hardware-accelerated encryption. Specific platforms were selected from within each product family for evaluation. All products were evaluated with both hardware-accelerated encryption enabled as well as software-based encryption. Throughput results (at approximately 65 percent CPU utilization) are summarized in Table 2-7.
Table 2-7 Branch Site Device Throughput
Hardware (HW) Branch Router Platform Acceleration Option Cisco 3660 Cisco 3640 Cisco 3620 Cisco 2651 Cisco 2621 Cisco 2611 Cisco 1750 Cisco 806 Cisco 805 AIM-HP AIM-MP AIM-MP AIM-BP AIM-BP AIM-BP VPN Module N/A N/A
Maximum Performance1 38.1 Mbps 14.7 Mbps 8.0 Mbps 14.0 Mbps 10.0 Mbps 8.0 Mbps 3.0 Mbps 384 Kbps N/A
Scalability Traffic Mix Performance with HW Encryption2 16.0 Mbps 3.5 Mbps 1.8 Mbps 2.8 Mbps 2.4 Mbps 2.0 Mbps 2.6 Mbps N/A N/A
Scalability Traffic Mix Performance with SW Encryption3 2.4 Mbps 900 Kbps 480 Kbps 960 Kbps 520 Kbps 380 Kbps 560 Kbps Not evaluated 100 Kbps
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and single IPSec/GRE tunnel. 2. Scalability traffic mix evaluation performed with mixed packet sizes, 65 percent CPU utilization, and two IPSec/GRE tunnels. 3. Refer to the footnote above for “Scalability Traffic Mix Performance with HW Encryption.”
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-28
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Solution Component Recommendations
New Cisco Branch Site Products
A number of new Cisco VPN router products were not available at the time of the scalability testing performed with the design presented in this publication. Table 2-6 shows the latest Cisco VPN Router products targeted for use as branch devices, along with their measured maximum performance.
Table 2-8 Latest Cisco VPN Branch Site Router Products
Head-end Router Platform Cisco 3745 Cisco 3725 Cisco 1760
Hardware Acceleration Option AIM-EP AIM-EP VPN Module
Maximum Performance1 Up to 40 Mbps Up to 40 Mbps Up to 10 Mbps
1. Maximum performance evaluated with 1400-byte packet size, full CPU utilization, and single IPSec/GRE tunnel.
Other Cisco Products
Several other Cisco products support IPSec VPN tunnel termination in a branch site termination environment. These include the Cisco VPN 3002 Concentrator, Cisco PIX 501 and Cisco PIX 506 firewalls. These platforms were not part of the scalability testing and are not fully discussed in this publication. See the following links for more product information on the Cisco VPN 3000 and Cisco PIX Series:
• •
http://www.cisco.com/warp/public/cc/pd/hb/vp3000/ http://www.cisco.com/warp/public/cc/pd/fw/sqfw500/
Network Performance/Convergence
Each network deployment can have different convergence time requirements. The design principles in this guide were used to perform a scalability test with 240 branch offices aggregated to two head-end devices. Standard timer values were configured for the routing protocol being used. Traffic load was established between the 240 branches and two head-ends. Aggregation to three head-end devices was also evaluated for comparison purposes. The test was performed by powering off one of the head-end devices to simulate a complete failure. The 120 affected branches successfully failed over to the surviving head-end. In this test, the network fully converged after 22 seconds. The same test was then performed with 240 branch offices aggregated to three head-end devices. All 80 branches from the failed head-end successfully failed over to the two surviving head-ends. In this test, the network fully converged after 22 seconds. Convergence times were found to be well within the timeframe to maintain TCP connections. In both scenarios, the failed head-end device was then powered back on, resulting in the network re-converging in less than two seconds. The IPSec tunnels re-established a few at a time as their corresponding SAs were renegotiated. The last IPSec tunnels re-established after 1-1/2 to two minutes. During this recovery and SA negotiation period, network connectivity is already established.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-29
Chapter 2 Additional Considerations for Latency-Sensitive Traffic
Enterprise Site-to-Site IPSec VPNs
Software Releases Evaluated
The software releases shown in Table 2-9 were used in scalability testing:
Table 2-9 Software Releases Evaluated
Product Type Cisco Head-end Routers (Cisco 7140, Cisco 7200) Cisco Branch Office Routers (Cisco 1750, Cisco 26xx, Cisco 36xx) Cisco Catalyst Switches (Cisco 2948G, Cisco 6x00)
Software Release Cisco IOS 12.1(9)E (with Triple DES IPSec support) Cisco IOS 12.2(8)T (with Triple DES IPSec support)1 Cisco CatOS 5.5
1. Cisco IOS 12.2(8)T is the current minimum recommendation for branch products. Cisco IOS 12.2(3.5)T was the actual software evaluated for this publication, however, an interim release and is not available for external deployment.
Note
Several Cisco IOS images exist with each configured with various levels of encryption technology. There are certain restrictions and laws governing the use and export of encryption technology. With the Cisco IOS images referenced in Table 2-9, all VPN features may be enabled, including Triple DES. Before selecting Cisco IOS software, perform the appropriate research through http://www.cisco.com and consult with technical support representative. Be aware of any issues in specific levels of code that can affect other configured features.
Additional Considerations for Latency-Sensitive Traffic
VPNs are often positioned as traditional WAN replacements, since they offer the same interconnectivity between a central campus and branch offices, often with greater flexibility and lower cost. As a result, customers expect the same level of services offered by a WAN, including the ability to run latency-sensitive applications, such as IP Telephony and video, across the VPN. End-to-end QoS is required to achieve acceptable quality, including low latency and jitter. Provisioning and deploying an IPSec-based VPN with QoS enabled is currently under study and scalability testing. Some preliminary findings are important to consider when deploying a QoS enabled VPN. These are highlighted in the following subsequent sections:
• • • • • •
Quality of Service (QoS) Pre-classification of Traffic Lower Link Speeds Hardware-Accelerated versus Software-Based Encryption Compressed RTP Not Supported by IPSec Additional Service Provider Considerations
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-30
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Additional Considerations for Latency-Sensitive Traffic
Quality of Service (QoS)
Quality of Service (QoS) is an issue when significant levels of voice and video traffic is added to network with heavy data traffic. Mission-critical and time-sensitive traffic—such as voice— must receive higher QoS guarantees than less time-sensitive traffic such as file transfers and emails. Increasing bandwidth to solve this problem involves higher cost. A QoS-based solution offers the potential for optimized and differentiated use of existing bandwidth. QoS enables assignment of different qualities to different data streams. Cisco provides a number of comprehensive end-to-end QoS mechanisms to improve voice quality and to optimally utilize WAN bandwidth. Examples of these mechanisms are:
• •
Packet classification and usage policies applied at the edge of the network, such as Policy Based Routing (PBR) and Committed Access Rate (CAR). End-to-end queuing mechanisms, such as Low Latency Queuing (LLQ). Because voice is susceptible to increased latency and jitter on slow speed links, LFI may also be used to reduce delay and jitter by breaking up large datagrams and interleaving low-delay traffic with the resulting smaller packets Scheduling mechanisms to optimize bandwidth utilization on output links, such as Traffic Shaping
•
QoS is beyond the scope of this publication, but will be included in a future version after scalability testing is completed.
Pre-classification of Traffic
Starting with Cisco IOS 12.2(2)T, a new pre-classification feature provides the prerequisite traffic classification needed to provide QoS across the VPN. Pre-classification is not simply copying of the Type of Service (ToS) bits to the front of the encrypted IPSec packet. Pre-classification preserves Cisco IOS QoS functionality and must be used whenever a VPN hardware-accelerated encryption card and Cisco IOS QoS are needed on the same Cisco router. It additionally provides the ability for the Cisco VPN router to provide WAN-edge QoS, based on encrypted elements—such as User Datagram Protocol (UDP) port or source address/destination address (SA/DA). Pre-classification is currently implemented for the Cisco 2600, Cisco 3600, Cisco 7100 and Cisco 7200 Series VPN routers. This feature was not tested in the initial scalability tests conducted for this publication. For additional information on why and how to implement pre-classification, see the following link: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/dtqosvpn.htm Pre-classification is beyond the scope of this publication, but will be included in a future version after scalability testing is completed.
Lower Link Speeds
Link speeds can be provisioned for branch sites at varying rates, from relatively low rates to very high rates depending on throughput requirements. For VPNs where the primary traffic is data, all link speeds readily support the requirements in this publication.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-31
Chapter 2 Additional Considerations for Latency-Sensitive Traffic
Enterprise Site-to-Site IPSec VPNs
When extending a VPN to support multi-service applications, such as IP Telephony and video, latency must be considered. On interfaces with lower link speeds, link fragmentation and interleaving (LFI) is required to minimize serialization delay incurred by transmitting large packets (such as 1400-byte packets) in front of smaller IP Telephony packets (such as 64-byte packets). If you anticipate running latency-sensitive applications over the VPN, plan to implement QoS features that minimize delay.
Hardware-Accelerated versus Software-Based Encryption
In addition to the recommendations outlined in “Hardware-Accelerated Encryption” section on page 2-22, other considerations favor implementing hardware-accelerated encryption in platforms that will support latency sensitive applications. For example, with software-based encryption it is not possible to achieve acceptable levels of latency and jitter that are predictable. For example, large data packets can overwhelm the encryption software and lead to unacceptable delays in receiving IP Telephony packets. Hardware-accelerated encryption adds up to 80 percent more encryption processing capacity to prevent this from occurring.
Compressed RTP Not Supported by IPSec
Header compression provides a very valuable service to latency sensitive protocols such as IP Telephony. When using Compressed Real Time Protocol (cRTP) to transport IP Telephony, packet redundancy from the Layer 3 and Layer 4 headers is removed from the stream, resulting in a lower traffic burden. Due to the nature of IPSec as outlined in the IETF standard, use of cRTP is not possible. This is not a Cisco IOS limitation, but an inherent incompatibility between the two protocols. Alternative protocols to cRTP to achieve header compression are being investigated for future implementation. Currently the only workaround is to provision the links so that sufficient bandwidth exists to transport the whole packet without header compression.
Additional Service Provider Considerations
VPNs inherently rely on one or more SPs to provide Internet service to the head-end and branch offices in order to deploy the network. It is important to note that some service providers may or may not honor classifications of delay-sensitive traffic—referred to as type of service (ToS)—and can therefore experience unacceptable levels of delay or jitter on voice traffic. Whenever possible, SLAs with SPs should be put into place. SLAs provide a stronger guarantee that delay-sensitive traffic will be handled in a QoS-type manner across the ISP network. This enables the enterprise to achieve end-to-end QoS for this type of traffic. Complications can also arise when multiple SPs are involved. For example, one SP might not honor the ToS classification bits from another SP. Additional latency can also be introduced by having latency-sensitive traffic needing to traverse multiple SP backbones. Furthermore, when a small office subscribes to cable or DSL Internet service provisioned for residential customers, problems can be encountered. Certain traffic types might be blocked prohibiting the effective deployment of a VPN (such as IP Telephony signaling protocols). Therefore it is strongly recommended that small offices subscribe to business-level cable or DSL service.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-32
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Enterprise Site-to-Site VPN Case Study
Enterprise Site-to-Site VPN Case Study
The key objective of this case study is to provide a reference example for a site-to-site VPN design. It provides an example of how these design principles can be applied in a real-world implementation. This case study assumes that all of the design considerations in “Solution Design Recommendations” section on page 2-6 and “Solution Component Recommendations” section on page 2-21 have been addressed and that best practice design recommendations are adopted by the customer. The case study also assumes that the Cisco IOS software levels listed in “Software Releases Evaluated” section on page 2-30 are acceptable to the customer. The details of the SP backbone and WAN connectivity are not addressed in the case study because the focus is with VPN deployment on the enterprise customer side.
Enterprise Organization Overview
Moose Widgets has been developing products at their Portland, Oregon headquarters (HQ) for several years. In addition, Moose Widgets has a single distribution center and 20 retail outlets across the United States (US). Currently Moose Widgets utilizes a traditional frame relay (FR) WAN service to connect its HQ network to its distribution center network. There is currently no connectivity to retail outlets, with the exception of a few outlets that, use personal computers (PCs) to dial-up to the corporate HQ. The current network topology is illustrated in Figure 2-9.
Figure 2-9 Moose Widgets Case Study Current Topology
Distribution Ctr Seattle, WA
Moose Widgets HQ Portland, OR
Frame relay
Retail outlets (20)
Corporate network
PSTN
74180
Dialup
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-33
Chapter 2 Enterprise Site-to-Site VPN Case Study
Enterprise Site-to-Site IPSec VPNs
Moose Widgets recently acquired two companies, one in San Jose, California and the other in Great Falls, Montana. Moose Widgets wants to connect its newly acquired companies and its retail outlets to its corporate network as an intranet. In addition, Moose Widgets plans to expand its retail outlets (from its current level of 20 to between 40 and 50) over the next year. Further, Moose recognizes that it needs additional distribution centers on the east and west coasts of the US to handle this expansion. As part of a corporate initiative, Moose Widgets is implementing a centralized inventory tracking system to more cost-effectively manage inventory in its growing distribution centers and retail outlets. The existing dial-in access does not provide adequate bandwidth to support the new applications. Moose Widgets is also concerned about an anticipated escalation of dial-in charges as each retail outlet will increasingly rely on corporate resources. As a result, Moose Widgets is looking to transition to a dedicated connection for each of its retail outlets using the Internet and VPN technology. Moose Widgets is concerned about the costs of adding the connections. It is also concerned about the ability to quickly get retail outlets up and running. Moose Widgets management indicated that it is primarily concerned about data traffic today, but there is some degree of interest in adding voice services in the future. Moose Widgets estimates its traffic requirements for the different site locations as shown in Table 2-10.
Table 2-10 Moose Widgets Case Study Traffic Profile
Location Distribution Center (one today, potentially three in the future) San Jose Great Falls Retail Outlets (up to 50)
Total
Estimated Traffic 1 Mbps 4 Mbps 4 Mbps 50Kbps (typical); 40 outlets 200Kbps (larger); 10 outlets 15Mbps
Moose Widgets approached Cisco to determine how a Virtual Private Network might meet its requirements.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-34
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Enterprise Site-to-Site VPN Case Study
Design Considerations
The design adopted for Moose Widgets provides for deployment of a site-to-site IPSec VPN, with the Moose Widgets corporate HQ serving as the head-end. All other locations are treated as branch sites. This allows a branch office to subscribe to a local ISP, get authenticated, and remain inside the corporate intranet. At the same time, end-to-end encryption is enabled using IPSec tunneling. Switching to VPN offers Moose Widgets significant cost savings over dial-up solutions and the ability to outsource to a SP that has VPN service as a core competency, resulting in better cost-efficiency and scalability. The initial goal is to provide VPN connectivity to onsite employees. Following the design practice outlined in “Solution Design Recommendations” section on page 2-6 and “Solution Component Recommendations” section on page 2-21, there are four main design steps to perform:
• • • •
Preliminary Design Considerations Sizing the Case Study Head-end Sizing the Case Study Branch Sites Tunnel Aggregation and Load Distribution
Preliminary Design Considerations
The design adopted is straightforward and flexible. As new retail locations enter service, Moose Widgets can purchase Internet connectivity from the local ISP, deploy a Cisco VPN Router at the branch site, configure the IPSec tunnels to the head-end devices at the corporate headquarters, and enable secure intranet access in a short amount of time.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-35
Chapter 2 Enterprise Site-to-Site VPN Case Study
Enterprise Site-to-Site IPSec VPNs
Using the questions from “General Design Considerations”, Table 2-11 summarizes the preliminary design considerations.
Table 2-11 Preliminary Design Considerations Summary
Question What applications are expected to run over the VPN? Is multi-protocol support required? How many branches will be aggregated to the head-end? What is the expected traffic throughput to/from branch offices? What are the expectations for resiliency? What encryption level is required?
Answer Data
Comments Interested in future voice services
Yes, using EIGRP for routing is GRE tunnels will enable desired. multi-protocol traffic transport. 55 sites See Table 2-10
Resiliency is required Triple DES
1 primary, 1 backup tunnel
What type of IKE authentication Pre-shared keys is selected due method will be used? to relatively small number of sites to manage. What other services will be run on the branch VPN routers? None
Migration to digital certificates should be considered if number of branches increases beyond 50 in the future.
Sizing the Case Study Head-end
While the traffic loads involved are not expected to exceed the recommended capacity of a single head-end device, Moose Widgets indicated it desires built-in resiliency at the central location. To meet this requirement, the tunnels from the remote ends are allocated to each of the head-end devices to balance the traffic load. To provide the service resiliency needed, secondary tunnels are configured and allocated so that in the event of a head-end failure, traffic is transitioned over to the partner head-end device. Applying the sizing algorithm defined in “Sizing the Head-end” section on page 2-23 presented earlier, the calculation of head-end sizing based on number of tunnels is as follows: N = 55 T = N x 2 = 110 C(t) = (T / 240) rounded up + 1 = 110/240 rounded +1 = 1 + 1 = 2 head-ends Next, apply the sizing algorithm defined in “Sizing the Head-end” section on page 2-23 and using the throughput estimates from Table 2-10, the calculation of head-end sizing based on branch traffic throughput is as follows: A = (3*(1 Mbps)+4 Mbps+4 Mbps+40*(50kbps)+10*(200kbps)) = 15 Mbps H = 40 Mbps (for Cisco 7206VXR NPE-400) C(a) = A/H, rounded up + 1 = 15/40 rounded up + 1 = 1+1 = 2 head-ends
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-36
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Enterprise Site-to-Site VPN Case Study
Comparing the number of head-end devices calculated based on number of tunnels, C(t), to the number based on aggregate throughput, C(a), the outcomes match. Therefore it is appropriate to deploy two head-end devices. Presented with the head-end product options, the customer selects to deploy two Cisco 7206VXR NPE-400 routers, each equipped with an ISA hardware encryption adapter.
Sizing the Case Study Branch Sites
The primary consideration for sizing of branch office sites is expected traffic throughput. Accordingly, starting with Table 2-10, and applying the concepts presented in “Sizing the Branch Site” section on page 2-27 presented earlier, the branch products selected are summarized in the Table 2-12.
Table 2-12 Branch Site Product Selection Summary
Location Distribution Centers San Jose Great Falls Retail Outlets (typical) Retail Outlets (larger)
Estimated Throughput 1 Mbps 4 Mbps 4 Mbps 50 Kbps 200 Kbps
Branch Office Platform Selected Cisco 2651 Cisco 3660 Cisco 3660 Cisco 1750 Cisco 2611
At each of the acquired company locations, a Cisco 3660 VPN router is deployed with high performance hardware-accelerated encryption (AIM-HP). The choice of the Cisco 3660 platform is based on the assumption that the acquired companies are large offices with a substantial number of employees. At each of the distribution centers, a Cisco 2651 Series VPN router is deployed with base performance hardware-accelerated encryption (AIM-BP). Finally, at each of the retail locations, the Cisco 2611 is recommended for the larger retail outlets and the Cisco 1750 for smaller retail outlets.
Tunnel Aggregation and Load Distribution
Given 55 branch sites, the total number of tunnels to be aggregated 110 (including primary and secondary tunnels). The first head-end device is allocated 27 primary and 28 backup tunnels, while the second head-end device is allocated 28 primary and 27 backup tunnels.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-37
Chapter 2 Enterprise Site-to-Site VPN Case Study
Enterprise Site-to-Site IPSec VPNs
Network Layout
An example network topology is shown in Figure 2-10.
Figure 2-10 Moose Widgets Case Study VPN Topology
Moose Widgets HQ Portland, RO
Distribution centers (3)
Cisco 2651 Cisco 2651
Retail outlets (40-50)
Cisco 7206VXR NPE-400 Cisco 2611
Internet
Cisco 1750
Corporate network
Cisco 3660
Cisco 3660
Widgetvision Technologies San Jose, CA
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-38
EDCS-202049
74181
Wilderness Labs Great Falls, MT
Chapter 2
Enterprise Site-to-Site IPSec VPNs Configuration Discussion
Configuration Discussion
The configuration issues defined in this chapter are specific to VPN implementation. It is assumed that the reader is familiar with standard Cisco configuration practices at the Command Line Interface (CLI) level. All example configurations shown are for IPSec in Tunnel Mode. There are a number of configuration items that must be addressed to implement IPSec functionality. The general steps are as follows.
Step 1 Step 2 Step 3 Step 4 Step 5
Configure IKE policy—See “IKE Policy Configuration” section on page 2-39 Configure IPSec Transform and Protocol—See “IPSec Transform and Protocol Configuration” section on page 2-40 Create Access Lists for Encryption—See “Access List Configuration for Encryption” section on page 2-40 Configure Crypto Map—See “Crypto Map Configuration” section on page 2-41 Apply Crypto Map—See “Applying Crypto Maps” section on page 2-41
The sections which follow cover each of these steps in more detail. In addition, the following link offers additional information: http://www.cisco.com/cgi-bin/Support/PSP/psp_view.pl?p=Internetworking:IPSec
IKE Policy Configuration
There must be at least one matching IKE policy between two potential IPSec peers. The example configuration below shows a policy using pre-shared keys with Triple DES as the encryption transform. There is a default IKE policy that contains the default values for the transform, hash method, Diffie-Hellman group, authentication and lifetime parameters. This is the lowest priority IKE policy. When using pre-shared keys, Cisco recommends that wildcard keys be avoided. Instead, the example shows two keys configured for separate IPSec peers. The keys should be carefully chosen. Here, bigsecret is used only as an example. The use of keys containing alpha-numeric and punctuation characters is recommended.
Head-end Router
interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 ! crypto isakmp policy 1 encr 3des authentication pre-share crypto isakmp key bigsecret address 192.168.161.2
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-39
Chapter 2 Configuration Discussion
Enterprise Site-to-Site IPSec VPNs
Branch Site Router
interface s0/0 ip address 192.168.161.2 255.255.255.0 ! crypto isakmp policy 1 encr 3des authentication pre-share crypto isakmp key bigsecret address 192.168.251.1
These defaults and more information can be found at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_r/fipsencr/srfike .htm#xtocid17729
IPSec Transform and Protocol Configuration
The transform set must match on the two IPSec peers. The transform set names are only locally significant. However the encryption transform, hash method and the particular protocols used (ESP or AH) must match. You may also configure data compression here but it is not recommended on peers with high speed links. There can be multiple transform sets for use between different peers.
Head-end Router
interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 ! crypto ipsec transform-set vpn-test esp-3des esp-sha-hmac
Branch Site Router
interface s0/0 ip address 192.168.161.2 255.255.255.0 ! crypto ipsec transform-set vpn-test esp-3des esp-sha-hmac
More information can be found at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_r/fipsencr/srfips ec.htm#xtocid105784
Access List Configuration for Encryption
The access list entries defining the traffic to be encrypted must mirror each other on the IPSec peers. If access list entries include ranges of ports, then a mirror image of those same ranges must be included on the remote peer access lists. The addresses specified in these access lists are independent of the addresses used by the IPSec peers. In this example, GRE is specified on both the source and destination parts of the access list. All traffic encapsulated in the GRE packets will be protected.
Head-end Router
interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 ! ip access-list extended vpn-static1 permit gre host 192.168.251.1 host 192.168.161.2
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-40
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Configuration Discussion
Branch Site Router
interface s0/0 ip address 192.168.161.2 255.255.255.0 ! ip access-list extended vpn-static2 permit gre host 192.168.185.2 host 192.168.251.1
Crypto Map Configuration
The crypto map entry ties together the IPSec peers, the transform set used and the access list used to define the traffic to be encrypted. The crypto map entries are evaluated sequentially. In the example below, the crypto map name static-map and crypto map numbers (such as 1 and 20) are only locally significant. The first statement sets the IP address used by this peer to identify itself to other IPSec peers in this crypto map. This address must match the set peer statement in the remote IPSec peer crypto map entries. This address also needs to match the address used with any preshared keys the remote peers might have configured. The IPSec mode defaults to tunnel mode.
Head-end Router
interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 ! crypto map static-map local-address FastEthernet1/0 crypto map static-map 1 ipsec-isakmp set peer 192.168.161.2 set transform-set vpn-test match address vpn-static1
Branch Site Router
interface s0/0 ip address 192.168.161.2 255.255.255.0 ! crypto map static-map local-address Serial0/0 crypto map static-map 20 ipsec-isakmp set peer 192.168.251.1 set transform-set vpn-test match address vpn-static2
A more complete description can be found at: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_r/fipsencr/srfips ec.htm#xtocid105785
Applying Crypto Maps
The crypto maps must be applied to the interfaces, both the physical interface and the logical interfaces, such as the GRE tunnel interfaces.
Head-end Router
interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 ! interface Tunnel1 ip address 10.62.1.193 255.255.255.252 tunnel source 192.168.251.1 tunnel destination 192.168.161.2
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-41
Chapter 2 Configuration Discussion
Enterprise Site-to-Site IPSec VPNs
crypto map static-map ! interface FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 crypto map static-map
Branch Site Router
interface s0/0 ip address 192.168.161.2 255.255.255.0 ! interface Tunnel1 ip address 10.63.25.198 255.255.255.252 tunnel source 192.168.185.2 tunnel destination 192.168.251.1 crypto map static-map ! interface Serial0/0 bandwidth 1536 ip address 192.168.161.2 255.255.255.0 crypto map static-map
Dynamic Crypto Maps
Rather than pre-define all the IPSec peers, another option is to create dynamic crypto maps. Dynamic crypto maps allow an IPSec connection between two peers when the central site peer does not have all the configuration necessary to complete an IPSec negotiation with a remote peer. This situation can occur when the remote peer has its IP address dynamically assigned—as in the case of a residential-class ISP connection like Cable or DSL. Since the remote peer’s IP address might be unknown, it cannot be preprogrammed into the central site device. IKE is required for authentication with dynamic crypto maps. The IKE authentication will complete based on an identity other than the remote peer’s IP address, such as the peer's fully qualified domain name (FQDN). The information from the IKE session will then be used to complete the missing information in the dynamic crypto map. Because the IP address of the peer is unknown until the IKE session is negotiated, GRE tunnels cannot be configured and cannot be used. This also prevents running a routing protocol. Resiliency can be accomplished with use of the relatively new Cisco IOS features Dead Peer Detection (DPD) and Reverse Route Injection. When dynamic crypto maps are used, an IPSec peer must accept connections from any IP address. For this reason the use of pre-shared keys is not recommended with dynamic crypto maps.
Note
Dynamic crypto maps have not been evaluated in scalability tests and are not covered further in this publication.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-42
EDCS-202049
Chapter 2
Enterprise Site-to-Site IPSec VPNs Configuration Discussion
Common Configuration Mistakes
The following sections outline some common mistakes and problems encountered when configuring IPSec:
• • • •
ACL Mirroring Error Peer Address Mismatch Transform Set Mismatch IKE Policy Mismatch
ACL Mirroring Error
The access lists that define the traffic to be encrypted must be mirror images of each other. The source port and source address in the access list on one peer must match the destination port and destination address on the other peer. The elimination of the source and destination ports is permissible, however the use of the keyword any for the addresses is strongly discouraged. This will ensure proper processing of encrypted traffic on the remote peer.
Peer Address Mismatch
The IP address used as the IPSec source address must match the address configured as the destination address on the IPSec peer and vice-versa. Unless the address is configured specifically, the address of the outgoing interface will be used as the IPSec peer’s address.
Transform Set Mismatch
At least one matching transform set must be configured between two IPSec peers. When specifying a particular strength of encryption algorithm, a similar strength IKE algorithm should also be configured. Failure to do so could weaken the encryption strength of the entire solution.
IKE Policy Mismatch
There is a default IKE policy present in all Cisco IOS devices. This policy uses lower security hash methods and encryption transform sets. If a stronger IKE policy is desired, at least one matching IKE policy must be configured between each IPSec peer.
Note
It is recommended to use the same transform set and hash methods in IKE and IPSec policies.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
2-43
Chapter 2 Configuration Discussion
Enterprise Site-to-Site IPSec VPNs
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
2-44
EDCS-202049
A P P E N D I X
A
Enterprise Site-to-Site VPN Scalability Test Configuration
Scalability Testbed Network Diagram
Figure A-1 illustrates the test network used for the enterprise site-to-site VPN scalability tests presented in this publication.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
A-1
Appendix A
Enterprise Site-to-Site VPN Scalability Test Configuration
Figure A-1
Scalability Testbed Network Diagram
Chariot endpoints Chariot console
Si
"Core / Campus endpoints" Sun Netras: vpn4-n1 through vpn4-n30
vpn4-2948GL2 vpn2-6500-1 vpn3-7xx0-1 vpn3-7xx0-3
vpn3-7xx0-2
Si
vpn1-6500-1 FEC vpn2-7500-2
vpn2-7505-1
FEC
(HDLC) vpn6-2948G-1 vpn6-2600-1 through vpn6-2600-30 vpn10-2600-1 vpn10-2948G-1 through vpn10-2600-30
vpn7-2948G-1
vpn7-2600-1 through vpn7-2600-30
vpn11-2600-1 vpn11-2948G-1 through vpn11-2600-30
vpn8-2948G-1
vpn8-2600-1 through vpn8-2600-30
vpn12-2600-1 vpn12-2948G-1 through vpn12-2600-30
vpn9-2948G-1
vpn9-2600-1 through vpn9-2600-30
vpn14-3620-1-5 vpn14-3660-1-5
vpn13-800 - 1-5 vpn13-1700-1-5 vpn14-2948G-1 vpn13-2600-1-5 vpn13-3640-1-5
ci13-2948G-1
"Branch endpoints" Sun Netras: vpn5-n1 through vpn5-n30 Chariot endpoints
Si
vpn2-6500-2
VPN Solution Testbed
74182
vpn5-2948GL2-1
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
A-2
EDCS-202049
Appendix A
Enterprise Site-to-Site VPN Scalability Test Configuration
Scalability Testbed Configuration Files
The configuration for the central and branch sites are listed below in the sections which follow.
Note
These configurations have been extracted from real configurations used in ESE scalability testing. They are provided as a reference only. The use of GRE as a tunneling method requires static tunnel endpoint configuration. Configuring IPSec peers was also done statically.
Head-end Configuration
The head-end is setup with two GRE tunnels (one primary and one secondary) for each branch site that it terminates. The following configuration is an excerpt and does not contain configuration commands for all branches.
! ip cef ! ! ip ssh time-out 120 ip ssh authentication-retries 3 ! xsm xsm privilege configuration level 15 xsm privilege monitor level 1 xsm vdm xsm edm no xsm history vdm no xsm history edm ! ! crypto isakmp policy 1 encr 3des authentication pre-share crypto isakmp key bigsecret address 192.168.161.2 crypto isakmp key bigsecret address 192.168.162.2 ! ! crypto ipsec transform-set vpn-test esp-3des esp-sha-hmac crypto mib ipsec flowmib history tunnel size 200 crypto mib ipsec flowmib history failure size 200 ! crypto map static-map local-address FastEthernet1/0 crypto map static-map 1 ipsec-isakmp set peer 192.168.1.2 set transform-set vpn-test match address vpn-static1 crypto map static-map 2 ipsec-isakmp set peer 192.168.2.2 set transform-set vpn-test match address vpn-static2 ! ! controller ISA 2/1 ! ! ! buffers small permanent 2048
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
A-3
Appendix A
Enterprise Site-to-Site VPN Scalability Test Configuration
buffers small max-free 10240 buffers small min-free 512 buffers middle permanent 2048 buffers middle max-free 10240 buffers middle min-free 512 buffers big permanent 2048 buffers big max-free 10240 buffers big min-free 512 buffers verybig permanent 2048 buffers verybig max-free 10240 buffers verybig min-free 512 buffers large permanent 2048 buffers large max-free 10240 buffers large min-free 512 buffers huge permanent 128 buffers huge max-free 512 buffers huge min-free 32 ! ! interface Loopback0 ip address 10.57.1.255 255.255.255.255 no ip route-cache no ip mroute-cache ! interface Tunnel1 description vpn6-2600-1 ip address 10.62.1.193 255.255.255.252 ip summary-address eigrp 1 10.0.0.0 255.0.0.0 5 load-interval 30 tunnel source 192.168.251.1 tunnel destination 192.168.1.2 crypto map static-map ! interface Tunnel2 description vpn6-2600-2 ip address 10.62.2.193 255.255.255.252 ip summary-address eigrp 1 10.0.0.0 255.0.0.0 5 load-interval 30 tunnel source 192.168.251.1 tunnel destination 192.168.2.2 crypto map static-map ! ! interface FastEthernet0/0 description FastEthernet0/0 ip address 172.26.156.17 255.255.254.0 no ip mroute-cache load-interval 30 duplex full ! interface FastEthernet1/0 description FastEthernet1/0 ip address 192.168.251.1 255.255.255.0 load-interval 30 duplex full speed 100 crypto map static-map ! interface FastEthernet1/1 description FastEthernet1/1 ip address 10.57.1.1 255.255.255.252 no ip proxy-arp load-interval 30 duplex full
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
A-4
EDCS-202049
Appendix A
Enterprise Site-to-Site VPN Scalability Test Configuration
speed 100 ! router eigrp 1 redistribute static passive-interface FastEthernet0/0 passive-interface FastEthernet1/0 network 10.0.0.0 no auto-summary eigrp log-neighbor-changes ! ip classless ip route 0.0.0.0 0.0.0.0 192.168.251.2 ! ! ip access-list extended vpn-static1 permit gre host 192.168.251.1 host 192.168.1.2 ip access-list extended vpn-static2 permit gre host 192.168.251.1 host 192.168.2.2
Branch Site Configuration
For resiliency, two tunnels are configured (primary and secondary) to the central site.
! ip cef ! ! crypto isakmp policy 1 encr 3des authentication pre-share crypto isakmp key bigsecret address 192.168.253.1 crypto isakmp key bigsecret address 192.168.251.1 ! ! crypto ipsec transform-set vpn-test esp-3des esp-sha-hmac crypto mib ipsec flowmib history tunnel size 200 crypto mib ipsec flowmib history failure size 200 ! crypto map static-map local-address Serial0/0 crypto map static-map 10 ipsec-isakmp set peer 192.168.253.1 set transform-set vpn-test match address vpn-static1 crypto map static-map 20 ipsec-isakmp set peer 192.168.251.1 set transform-set vpn-test match address vpn-static2 ! ! interface Loopback0 ip address 10.63.25.254 255.255.255.255 ! interface Tunnel0 description Tunnel0 ip address 10.63.25.194 255.255.255.252 ip summary-address eigrp 1 10.63.25.0 255.255.255.0 5 load-interval 30 tunnel source 192.168.185.2 tunnel destination 192.168.253.1 crypto map static-map ! interface Tunnel1 description Tunnel1
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
A-5
Appendix A
Enterprise Site-to-Site VPN Scalability Test Configuration
delay 1526 ip address 10.63.25.198 255.255.255.252 ip summary-address eigrp 1 10.63.25.0 255.255.255.0 5 load-interval 30 tunnel source 192.168.185.2 tunnel destination 192.168.251.1 crypto map static-map ! interface FastEthernet0/0 description FastEthernet0/0 ip address 172.26.157.185 255.255.254.0 no ip proxy-arp no ip mroute-cache load-interval 30 speed auto half-duplex ! interface Serial0/0 description Serial0/0 bandwidth 1536 ip address 192.168.185.2 255.255.255.0 no ip mroute-cache load-interval 30 no fair-queue crypto map static-map ! interface FastEthernet0/1 description FastEthernet0/1 ip address 10.63.25.1 255.255.255.128 no ip mroute-cache load-interval 30 speed 10 full-duplex ! router eigrp 1 passive-interface Serial0/0 passive-interface FastEthernet0/1 network 10.0.0.0 no auto-summary eigrp log-neighbor-changes ! ip classless ip route 192.168.251.1 255.255.255.255 192.168.185.1 ip route 192.168.253.1 255.255.255.255 192.168.185.1 no ip http server ip pim bidir-enable ! ! ip access-list extended vpn-static1 permit gre host 192.168.185.2 host 192.168.253.1 ip access-list extended vpn-static2 permit gre host 192.168.185.2 host 192.168.251.1 !
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
A-6
EDCS-202049
A P P E N D I X
B
High-Level IPSec Overview
The purpose of this section is to provide a brief introduction to IPSec and its application in VPNs. General descriptions of the following IPsec topics are presented:
• • • • •
Tunneling Protocols Introduction to IPSec IPSec Protocols IPSec Modes Internet Key Exchange (IKE)
For a more in-depth understanding of IPSec, the reader should consult the Cisco SAFE VPN White Paper. Cisco SAFE documentation can be found at the following URL: http://www.cisco.com/go/safe
Tunneling Protocols
There are a variety of tunneling protocols from which to choose. They vary in terms of the features they support, the problems they are designed to solve, and the amount of security they provide to the data being transported. The design presented in this paper focuses on IPSec used in conjunction with GRE tunnels. When implemented individually, these tunneling protocols do not provide the necessary features to simultaneously ensure privacy and support multi-protocols. The combination of IPSec and GRE concurrently achieves both functions. Other tunneling protocols include Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP). PPTP and L2TP are intended for user or client to concentrator networks, commonly called remote access solutions and are not used in the site-to-site VPN solution.
Introduction to IPSec
The IPSec standard provides a method to manage authentication and data protection between multiple peers engaging in secure data transfer. IPSec includes Internet Security Association & Key Management Protocol (ISAKMP) and the Oakley Key Determination Protocol and two IPSec IP protocols—Encapsulating Security Protocol (ESP) and Authentication Header (AH).
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
B-1
Appendix B IPSec Protocols
High-Level IPSec Overview
IPSec uses symmetrical encryption algorithms for data protection. Symmetrical encryption transforms are more efficient and are easier to implement in hardware. These algorithms need a secure method of key exchange in order to ensure the data protection. Internet Key Exchange’s (IKE) ISAKMP/Oakley protocols provide that capability. This solution requires a standards based way to secure data from eavesdropping and modification. IPSec provides such a method. IPSec permits the network designer to choose the strength of data protection by allowing the choice of transform set. IPSec also has several hash methods to choose from, each giving different levels of protection.
IPSec Protocols
There are two IP protocols used in the IPSec standard: Encapsulating Security Protocol (ESP) and Authentication Header (AH). These protocols are summarized briefly in the next two sections:
• •
Encapsulating Security Protocol (ESP) Authentication Header (AH)
Encapsulating Security Protocol (ESP)
The ESP header (IP protocol 50) forms the core of the IPSec protocol. This protocol in conjunction with an agreed upon encryption method or transform set, protects data by rendering it un-decipherable. This protocol protects the data portion of the packet only. It can also optionally provide for authentication of the protected data. Figure B-1 shows how ESP encapsulates an IP packet:
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
B-2
EDCS-202049
Appendix B
High-Level IPSec Overview IPSec Protocols
Figure B-1
Encapsulating Security Protocol (ESP)
Original IP Packet
IP HDR
Data
Transport Mode
IP HDR
ESP HDR
Data Encrypted Authenticated
ESP ESP trailer Auth
Tunnel Mode New IP HDR ESP HDR IP HDR Data Encrypted Authenticated
74169
ESP ESP trailer Auth
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
B-3
Appendix B IPSec Protocols
High-Level IPSec Overview
Authentication Header (AH)
The AH protocol (IP protocol 51) forms the other part of IPSec. The AH does not protect data in the usual sense by hiding the data. Instead, it adds a tamper-evident seal to the data. It also protects the non-mutable fields in the IP header carrying the data. This includes the address fields of the IP header. The AH protocol should not be used alone when there is a requirement for data confidentiality. Figure B-2 illustrates how AH encapsulates an IP packet:
Figure B-2 Authentication Header (AH)
Original IP Packet
IP HDR
Data
Transport Mode
IP HDR
AH
Data
Authenticated except for mutable fields
Tunnel mode New IP HDR AH IP HDR Data
74170
Authenticated except for mutable fields in New IP header
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
B-4
EDCS-202049
Appendix B
High-Level IPSec Overview IPSec Modes
IPSec Modes
IPSec has two methods of forwarding data across a network: transport mode and tunnel mode. Each differs in their application as well as in the amount of overhead added to the passenger packet. These protocols are summarized briefly in the next two sections:
• •
Tunnel Mode Transport Mode
Tunnel Mode
Tunnel mode works by encapsulating and protecting an entire IP packet. Because tunnel mode encapsulates or hides the IP header of the packet, a new IP header must be added in order for the packet to be successfully forwarded. The encrypting devices themselves own the IP addresses used in these new headers. These addresses can be specified within the configuration of Cisco IOS routers. Tunnel mode may be employed with either or both ESP and AH. Using tunnel mode results in additional packet expansion of approximately 20 bytes associated with the new IP header. Tunnel mode expansion of the IP packet is depicted in Figure B-3.
Figure B-3 IPSec Tunnel Mode
IP HDR
Data
New IP HDR
IPsec HDR
IP HDR
Data To be protected
74171
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
B-5
Appendix B Internet Key Exchange (IKE)
High-Level IPSec Overview
Transport Mode
Because packet expansion can be a concern during the forwarding of small packets, a second forwarding method was also specified. IPSec transport mode inserts the ESP header between the IP header and the next protocol or the transport layer of the packet. Both IP addresses of the two network nodes whose traffic is being protected by IPSec are visible. This mode of IPSec can be sometimes susceptible to traffic analysis. However, since there is no additional IP header added, it results in less packet expansion. Transport mode can be deployed with either or both ESP and AH. This mode works well with GRE because GRE hides the addresses of the end stations by adding its own IP header. Transport mode expansion of the IP packet is depicted Figure B-4.
Figure B-4 IPSec Transport Mode
IP HDR
Data
IP HDR
IPsec HDR
Data To be protected
74172
Internet Key Exchange (IKE)
In order to implement a VPN solution with encryption, periodic changing of encryption keys is necessary. Failure to change these keys would make the network susceptible to brute force attacks. IPSec solves the problem of key generation with the Internet Key Exchange (IKE) protocol. This protocol uses a mathematical routine called a Diffie-Hellman exchange to generate symmetrical keys to be used by two IPSec peers. IKE also manages the negotiation of other security parameters such as the data to be protected, the strength of the keys, the hash methods used and whether or not the packets are protected from replay. IKE utilizes UDP port 500. Two elements of IKE are discussed briefly in the following sections:
• •
Security Association (SA) IKE Authentication
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
B-6
EDCS-202049
Appendix B
High-Level IPSec Overview Internet Key Exchange (IKE)
Security Association (SA)
A Security Association (SA) is an agreement between two peers engaging in an IPSec exchange. This agreement includes things like the type and strength of the encryption used to protect the data. It includes the method and strength of the data authentication (if any) and also the method of creating new keys for that data protection. SAs are performed in two phases as described in the following two sections:
• •
IKE Phase 1 IKE Phase 2
IKE Phase 1
Phase 1 is the initial negotiation of SAs between two IPSec peers. Phase 1 can optionally also include an authentication in which each peer is able to verify the identity of the other. This interaction between two IPSec peers can be subject to eavesdropping with no significant vulnerability of the keys being recovered. Phase 1 SAs are bi-directional—data may be sent and received using the same key material generated. Phase 1 has three possible authentication methods: pre-shared keys (PSK), Digital Certificates, or RSA Encryption (encrypted nonces). This publication focuses on pre-shared keys implementations.
IKE Phase 2
Phase 2 SAs are negotiated by the IKE process (ISAKMP) on behalf of other services such as IPSec, that need key material for operation. Since the SAs used by IPSec are unidirectional, a separate key exchange is needed for data flowing in the forward direction from the reverse direction. This doubles the amount of eavesdropping effort that would be required to successfully recover both sides of an interaction.
IKE Authentication
The two primary methods of configuring VPN devices to authenticate with their respective peers are:
• •
Pre-shared Keys Digital Certificates
These are discussed briefly in the sections that follow.
Pre-shared Keys
Implementing pre-shared keys involves configuration using a set of keys known in advance to both peer VPN devices. As the number of IPSec devices in the VPN grows, scalability becomes an issue because a separate key must be maintained for each IPsec peer. Replacement of a device in the network could also lead to compromise of the keys in use at the time. The scalability testing performed for this publication utilized the pre-shared keys method of authentication.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
B-7
Appendix B Internet Key Exchange (IKE)
High-Level IPSec Overview
Digital Certificates
An alternative to the pre-shared keys method is to implement the use of digital signatures contained in digital certificates. Digital signatures use a trusted third party, known as a certificate authority, to digitally sign the public key portion of the encrypted nonce. Included with the signature is a name, serial number, validity period and other information that an IPSec device can use to determine the validity of the certificate. Certificates can also be revoked, denying the IPSec device the ability to successfully authenticate. The discussion and setup of a certificate authority is beyond the scope of this paper.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
B-8
EDCS-202049
I N D EX
A
aggregation (figure) AH packet (figure)
B-4 2-12
access list for encryption applying crypto maps common mistakes crypto map convergence scenario summary crypto map dynamic
2-8 2-42 2-29 2-41 2-43
2-40
2-41
Authentication Header. See AH.
B
best practices summarized branch site sizing
2-27 2-28
D
data encryption IPSec
2-9
VPN router
Data Encryption Standard. See DES.
C
case study branch site sizing
2-37 2-35 2-33
Dead Peer Detection. See DPD. deployment considerations (table) DES compared to Triple DES design assumptions
2-3 2-3 2-4 2-9 2-7
design considerations head end sizing network layout Cisco IOS pre-classification releases evaluated configuration summary
2-39 2-31 2-36 2-38
enterprise site-to-site VPN
components summary resiliency DHCP
2-20 B-8 2-10
enterprise site-to-site VPN topology (figure)
2-30
digital certificates dynamic crypto map IPSec
2-40 2-42
configuration discussion access list configuration applying crypto maps
2-41 2-43
Dynamic Host Configuration Protocol. See DHCP.
common configuration mistakes crypto map configuration configuration example
2-41
E
EIGRP as part of VPN design
2-10
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
IN-1
Index
configuration fragment recommended for VPN use with GRE (table) encryption Cisco recommendation hardware accelerated software-based DES
2-9 2-9
2-14 2-24
placement of firewall sizing
2-23 2-26
2-18
head-end aggregation effects
2-13 2-8
VPN router
Encapsulating Security Protocol. See ESP.
2-22 2-22 2-32
I
IKE authentication
B-7 B-6
hardware versus software
2-21, 2-32
Diffe-Hellman exchange digital certificates keepalives
2-16 B-7 B-8
encryption algorithms Triple DES ESP packet (figure) summarized
B-3 B-2
pre-shared keys
security association (SA) IP addressing IPSec EIGRP
2-19
B-7
Enhanced Interior Gateway Routing Protocol. See EIGRP.
Internet Key Exchange. See IKE.
IP multicast
2-4
F
firewalls multicast (note)
2-19
IPSec
2-20 B-4 2-32
AH packet (figure) data encryption DHCP
2-20 2-9
compressed RTP not supported
G
Generic Route Encapsulation. See GRE. GRE multicast
2-19 2-17 2-9
dynamic crypto map ESP packet (figure) IP addressing multicast NAT
2-20 2-19 2-19
2-42 B-3
packet expansion protocol overview
packet expansion protocols
B-2
2-17
routing protocols
2-19 B-1
technology overview
H
hash method MD5 SHA-1 head-end load distribution
2-11 2-9 2-9
transport mode tunnel mode IP Telephony
B-6
B-5
IP Security. See IPSec. latency considerations
2-30
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
IN-2
EDCS-202049
Index
K
keys pre-shared
2-42
PAT issues with IPSec VPN performance scenario summary pre-classification pre-shared keys products VPN components summary (table)
2-32 2-5 2-29 2-20
Port Address Translation. See PAT.
L
load distribution head-end
2-11
2-31 2-42, B-7
low-speed lines QoS and VPN
Q
QoS IP Telephony support mechanisms Quality of Service. See QoS.
2-31
M
Maximum Transmission Unit. See MTU. MTU discovery multicast firewalls GRE IPSec
2-19 2-19 2-19 2-19 2-18
R
reverse route injection route propagation recommended strategy routing protocols alternatives to using
2-16 2-13 2-17
support over VPN
N
NAT IPSec
2-20
EIGRP IPSec OSPF
2-4, 2-10, 2-13, 2-21 2-19 2-13 2-13
using across VPN
Network Address Translation. See NAT.
S O
OSPF use in VPN
2-13
scalability testing branch site configuration configuration example head-end configuration methodology
2-21 A-2 A-5 A-3 A-3
P
packet expansion IPSec/GRE (figure)
2-17
network diagram
service-level agreement. See SLA. service provider. See SP.
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design EDCS-202049
IN-3
Index
SLA key elements SP dependencies split tunneling
2-20 2-32 2-20
VPN considerations
2-19
starting assumptions
2-3
T
topology alternatives Triple DES compared to DES troubleshooting common configuration mistakes tunnel aggregation (figure) protocols split
2-19 2-11 B-1 2-12 2-10 2-43 2-8 2-13 2-2
hub-and-spoke
primary and secondary
VPN configuration (figure)
V
virtual primate network. See VPN. VPN Cisco product summary (table) design resiliency
2-10 2-9 2-2 2-5
encryption algorithms routing protocols
2-13
hub-and-spoke topology (figure)
site-to-site best practice summary (table) site-to-site topology (figure) tunneling protocols
B-1 2-4
2-8 2-7
site-to-site deployment considerations (table)
Cisco AVVID Network Infrastructure Enterprise Site-to-Site VPN Design
IN-4
EDCS-202049
