IPsec Virtual Private Network Fundamentals

Next Page

Book Cover
IPsec Virtual Private Network Fundamentals
By James Henry Carmouche, - CCIE No. 6085
...............................................
Publisher: Cisco Press
Pub Date: July 19, 2006
Print ISBN-10: 1-58705-207-5
Print ISBN-13: 978-1-58705-207-1
Pages: 480

Table of Contents | Index
Overview

An introduction to designing and configuring Cisco IPsec VPNs

  • Understand the basics of the IPsec protocol and learn implementation best practices

  • Study up-to-date IPsec design, incorporating current Cisco innovations in the security and VPN marketplace

  • Learn how to avoid common pitfalls related to IPsec deployment

  • Reinforce theory with case studies, configuration examples showing how IPsec maps to real-world solutions

IPsec Virtual Private Network Fundamentals provides a basic working knowledge of IPsec on various Cisco routing and switching platforms. It provides the foundation necessary to understand the different components of Cisco IPsec implementation and how it can be successfully implemented in a variety of network topologies and markets (service provider, enterprise, financial, government). This book views IPsec as an emerging requirement in most major vertical markets, explaining the need for increased information authentication, confidentiality, and non-repudiation for secure transmission of confidential data. The book is written using a layered approach, starting with basic explanations of why IPsec was developed and the types of organizations relying on IPsec to secure data transmissions. It then outlines the basic IPsec/ISAKMP fundamentals that were developed to meet demand for secure data transmission. The book covers the design and implementation of IPsec VPN architectures using an array of Cisco products, starting with basic concepts and proceeding to more advanced topics including high availability solutions and public key infrastructure (PKI). Sample topology diagrams and configuration examples are provided in each chapter to reinforce the fundamentals expressed in text and to assist readers in translating concepts into practical deployment scenarios. Additionally, comprehensive case studies are incorporated throughout to map topics to real-world solutions.

Next Page


Table of Contents

Previous Page
Next Page

Book Cover
IPsec Virtual Private Network Fundamentals
By James Henry Carmouche, - CCIE No. 6085
...............................................
Publisher: Cisco Press
Pub Date: July 19, 2006
Print ISBN-10: 1-58705-207-5
Print ISBN-13: 978-1-58705-207-1
Pages: 480

Table of Contents | Index

Copyright
About the Author
About the Technical Reviewers
Acknowledgments
Command Syntax Conventions
Introduction
 | Methodology
 | Who Should Read This Book?
 | How This Book Is Organized
Part I: Introductory Concepts and Configuration/Troubleshooting
 | Chapter 1. Introduction to VPN Technologies
 |  | VPN Overview of Common Terms
 |  | Characteristics of an Effective VPN
 |  | VPN Technologies
 |  | Common VPN Deployments
 |  | Business Drivers for VPNs
 |  | IPsec VPNs and the Cisco Security Framework
 |  | Summary
 | Chapter 2. IPsec Fundamentals
 |  | Overview of Cryptographic Components
 |  | Public Key Encryption Methods
 |  | The IP Security Protocol (IPsec)
 |  | IKE and ISAKMP
 |  | Summary
 | Chapter 3. Basic IPsec VPN Topologies and Configurations
 |  | Site-to-Site IPsec VPN Deployments
 |  | Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE)
 |  | Hub-and-Spoke IPsec VPN Deployments
 |  | Remote Access VPN Deployments
 |  | Summary
 | Chapter 4. Common IPsec VPN Issues
 |  | IPsec Diagnostic Tools within Cisco IOS
 |  | Common Configuration Issues with IPsec VPNs
 |  | Architectural and Design Issues with IPsec VPNs
 |  | Summary
Part II: Designing VPN Architectures
 | Chapter 5. Designing for High Availability
 |  | Network and Path Redundancy
 |  | IPSec Tunnel Termination Redundancy
 |  | Managing Peer and Path Availability
 |  | Managing Path Symmetry
 |  | Load Balancing, Load Sharing, and High Availability
 |  | Summary
 | Chapter 6. Solutions for Local Site-to-Site High Availability
 |  | Using Multiple Crypto Interfaces for High Availability
 |  | Stateless IPsec VPN High-Availability Alternatives
 |  | Stateful IPsec VPN High-Availability Alternatives
 |  | Summary
 | Chapter 7. Solutions for Geographic Site-to-Site High Availability
 |  | Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers
 |  | Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing Protocols
 |  | Dynamic Multipoint Virtual Private Networks
 |  | Summary
 | Chapter 8. Handling Vendor Interoperability with High Availability
 |  | Vendor Interoperability Impact on Peer Availability
 |  | Vendor Interoperability Impact on Path Availability
 |  | Vendor Interoperability Design Considerations and Options
 |  | Summary
 | Chapter 9. Solutions for Remote-Access VPN High Availability
 |  | IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination
 |  | IPsec RAVPN Concentrator HA Using the VCA Protocol
 |  | IPsec RAVPN Geographic HA Design Options
 |  | Summary
 | Chapter 10. Further Architectural Options for IPsec
 |  | IPsec VPN Termination On-a-Stick
 |  | In-Path Versus Out-of-Path Encryption with IPsec
 |  | Separate Termination of IPsec and GRE (GRE-Offload)
 |  | Summary
Part III: Advanced Topics
 | Chapter 11. Public Key Infrastructure and IPsec VPNs
 |  | PKI Background
 |  | PKI Components
 |  | Life of a Public Key Certificate
 |  | PKI and the IPSec Protocol SuiteWhere PKI Fits into the IPSec model
 |  | OCSP and CRL Scalability
 |  | Case Studies and Sample Configurations
 |  | Summary
 | Chapter 12. Solutions for Handling Dynamically Addressed Peers
 |  | Dynamic Crypto Maps
 |  | Tunnel Endpoint Discovery
 |  | Case StudyUsing Dynamic Addressing with Low-Maintenance Small Home Office Deployments
 |  | Summary
Appendix A. Resources
 | Books
 | RFCs
 | Web and Other Resources
Index

Previous Page


Copyright

IPsec Virtual Private Network Fundamentals

James Henry Carmouche, CCIE No. 6085

Copyright © 2007 Cisco Systems, Inc.

Published by:
Cisco Press
800 East 96th Street
Indianapolis, IN 46240 USA

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review.

Printed in the United States of America 1 2 3 4 5 6 7 8 9 0

First Printing June 2006

Library of Congress Cataloging-in-Publication Number: 2004107143

Trademark Acknowledgments

All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Warning and Disclaimer

This book is designed to provide information about IPsec virtual private networks. Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied.

The information is provided on an "as is" basis. The authors, Cisco Press, and Cisco Systems, Inc. shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the discs or programs that may accompany it.

The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc.

Corporate and Government Sales

Cisco Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales.

For more information please contact: U.S. Corporate and Government Sales 1-800-382-3419 corpsales@pearsontechgroup.com

For sales outside the U.S. please contact: International Sales international@pearsoned.com

Feedback Information

At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional technical community.

Readers' feedback is a natural continuation of this process. If you have any comments regarding how we could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at feedback@ciscopress.com. Please make sure to include the book title and ISBN in your message.

We greatly appreciate your assistance.

Publisher | Paul Boger
Cisco Representative | Anthony Wolfenden
Cisco Press Program Manager | Jeff Brady
Executive Editor | Brett Bartow
Production Manager | Patrick Kanouse
Development Editor | Andrew Cupp
Project Editor | Interactive Composition Corporation
Copy Editor | Interactive Composition Corporation
Technical Editors | Aamer Akhter, Jason Guy, Mark J. Newcomb
Editorial Assistant | Katherine Linder
Book and Cover Designer | Louisa Adair
Composition | Interactive Composition Corporation
Indexer | Tim Wright

Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100

European Headquarters
Cisco Systems International BV
Haarlerbergpark
Haarlerbergweg 13-19
1101 CH Amsterdam
The Netherlands
www-europe.cisco.com
Tel: 31 0 20 357 1000
Fax: 31 0 20 357 1100

Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
www.cisco.com
Tel: 408 526-7660
Fax: 408 527-0883

Asia Pacific Headquarters
Cisco Systems, Inc.
Capital Tower
168 Robinson Road
#22-01 to #29-01
Singapore 068912
www.cisco.com
Tel: +65 6317 7777
Fax: +65 6317 7799

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the Cisco.com Web site at www.cisco.com/go/offices.

Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China PRC • Colombia • Costa Rica • Croatia • Czech Republic • Denmark • Dubai, UAE • Finland • France • Germany • Greece • Hong Kong SAR • Hungary • India • Indonesia • Ireland • Israel • Italy • Japan • Korea • Luxembourg • Malaysia • Mexico • The Netherlands • New Zealand • Norway • Peru • Philippines • Poland • Portugal • Puerto Rico • Romania • Russia • Saudi Arabia • Scotland • Singapore • Slovakia • Slovenia • South Africa • Spain • Sweden • Switzerland • Taiwan • Thailand • Turkey • Ukraine • United Kingdom • United States • Venezuela • Vietnam • Zimbabwe

Copyright © 2003 Cisco Systems, Inc. All rights reserved. CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Net Readiness Scorecard, Networking Academy, and ScriptShare are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, 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, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, TransPath, 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. (0303R)

Printed in the USA

Dedication

For my loving wife, Kristen, and my two wonderful sons, James and Charlie. This would not have been possible without your unconditional love, support, and inspiration.


About the Author

James Henry Carmouche, CCIE No. 6085, is a technical marketing engineer on the Cisco Enterprise Systems Engineering team, where he is currently responsible for architecting, constructing, and validating enterprise-class network systems solutions. As part of his solution development responsibilities, Henry researches and publishes solution reference designs for use by customers, technical sales staff members, and marketing staff members. Prior to joining ESE, Henry worked as a technical marketing engineer in the Cisco Government Systems Unit, where he was responsible for bringing advanced security products to market, building technical marketing collateral and presentations, and designing new product introduction training for the GSU's newly introduced security platforms. In addition to his product and solution development experience, Henry has more than six years of technical consulting experience, including three years as a network consulting engineer in the Cisco Advanced Services Group. Henry earned an M.B.A. degree from UNC's Kenan-Flagler Business School and a B.S. degree in mechanical engineering from Lehigh University. Henry currently lives in Chapel Hill, NC, with his wife and two sons.


About the Technical Reviewers

Aamer Akhter, CCIE No. 4543, joined Cisco Systems in 1998 after graduating from Georgia Tech with a B.S. degree in electrical engineering to work in the Cisco Technical Assistance Center. He then supported the larger enterprise customers from Cisco in the NSA unit, where he helped design and deploy several large Layer 2 networks. Aamer later moved to Networked Solutions Integration Test Engineering (NSITE), where after a brief stint with IPsec VPNs, he moved into a new group for testing MPLS-VPNs. Five years later, MPLS-VPNS had matured much but testing of MPLS-related technologies still continues. Aamer is currently leading a team for testing Layer 3 VPNs and related technologies in a cross-Cisco effort.

Jason Guy is an engineer within the Cisco Systems' NSITE Security team, an organization responsible for network-based security solution testing. Jason is a member of a team responsible for testing, validating, scaling, and assisting in deployment of the Cisco security solution. Jason's primary focus is on firewalls, IPsec Remote Access, and SSL VPN testing. Prior to his work on the security technologies, Jason worked on the AToM Layer 2 VPN and MPLS VPN teams. Jason received his Masters of Computer Engineering degree from North Carolina State University in Raleigh, NC.

Mark J. Newcomb, CCNP, CCDP, is a retired network security engineer. Mark has more than 20 years experience in the networking industry, focusing on the financial and medical industries. Mark is a frequent contributor and reviewer for Cisco Press books.


Acknowledgments

During the development of this book, I had the privilege to work in three different groups at Cisco. Thank you to all of my teammates in Enterprise Systems Engineering, the Government Systems Unit, and Advanced Services who have lent me your professional acumen and loyal friendship over the years.

I'd like to thank Mike O'Shea for his support and friendship over the course of developing this book. Mike's sound professional and personal advice have helped me endure the ebbs and flows of sanity while balancing a challenging workload and added development responsibilities associated with writing this book.

Thank you to Pavan Reddy, one of the sharpest technical minds in Advanced Services, who was instrumental in helping me outline and define this scope of work and whose technical advice and words of encouragement throughout the course of developing this book have proven to be invaluable.

And on that note, many thanks go out to Andrew Cupp and Brett Bartow for their patience, understanding, and support during this process. An author could not have asked for a more professional team to work with while developing and publishing his work.


Command Syntax Conventions

The conventions used to present command syntax in this book are the same conventions used in the IOS Command Reference. The Command Reference describes these conventions as follows:

  • Boldface indicates commands and keywords that are entered literally as shown. In actual configuration examples and output (not general command syntax), boldface indicates commands that are manually input by the user (such as a show command).

  • Italics indicate arguments for which you supply actual values.

  • Vertical bars (|) separate alternative, mutually exclusive elements.

  • Square brackets [ ] indicate optional elements.

  • Braces { } indicate a required choice.

  • Braces within brackets [{ }] indicate a required choice within an optional element.


Introduction

In recent years, network security solutions have grown to include IPsec as a critical component of secure network architecture design. One primary objective of this publication is therefore to provide the reader with a basic working knowledge of IPsec on various Cisco routing and switching platforms and an understanding of the different components of the Cisco IPsec implementation. This book covers successful implementation of IPsec in a variety of network topologies. This book views IPsec as an emerging requirement in most major vertical markets (service provider, enterprise financial, government), explaining the need for increased information authentication, confidentiality, and non repudiation for secure transmission of confidential data (government records, financial data, billing information).

The primary development objective of this book is to create a work that aids network architects, administrators, and managers in their efforts to integrate IPsec VPN technology into their existing IP infrastructures. The focus is on IPsec deployments in Cisco network environments, from simple site-to-site virtual private network (VPN) configurations to comprehensive VPN strategies, including architectural redundancy and interoperability.


Methodology

This book follows a tiered approach toward building a working knowledge of fundamental IPsec VPN design, starting with an overview of basic IPsec business drivers and functional components. These concepts and components are then used as a foundation upon which IPsec VPN High Availability (HA) design considerations are presented. Lastly, several advanced IPsec VPN technologies that are commonly available in today's enterprise networks are presented and discussed. Within each chapter, the design concepts are presented and then reinforced with configurations, illustrations, and practical case studies where appropriate.


Who Should Read This Book?

This book presents information for technically savvy individuals who want to further their understanding of the fundamentals of this specific technology. Those parties interested in this book most likely include network engineers, network design consultants, network administrators, systems administrators, information security specialists, and all other individuals who have an interest in securing their networks with Cisco routers and VPN products. Additionally, networking professionals who have an understanding of IPsec and also want to view typical Cisco specific IPsec configurations and practical IPsec deployment examples on Cisco products may also find the design guidance provided in this book valuable. Because it provides information at a fundamental level, this book may also serve as an effective design reference for decision makers looking to make strategic decisions impacting the security of their organizations' network.


How This Book Is Organized

The organization of the book is formatted in a layered approach, starting with a basic explanation of the motivation behind IPsec's development and the types of organizations that rely on IPsec to secure data transmissions. The book then proceeds to outline the basic IPsec/Internet Security Association and Key Management Protocol (ISAKMP) fundamentals that were developed to meet demand for secure data transmission. The book proceeds to cover the design and implementation of IPsec VPN architectures using an array of Cisco products, starting with basic concepts and proceeding to more advanced topics, including HA solutions and public key infrastructure (PKI). Sample topology diagrams and configuration examples are provided to help reinforce the fundamentals expressed in the text, and to assist the reader in translating explained IPsec concepts into practical working deployment scenarios. Case studies are incorporated throughout the text in order to map the topics and concepts discussed to real-world solutions.

Chapters 1 through 4 compose Part I of this book, covering the most basic concepts required to develop an understanding of IPsec VPNs. The chapter content provided in Part I aims to help the reader achieve the following objectives:

  • Understand the background of IPsec VPN development

  • Differentiate IPSEC/SSL VPN from other VPN technologies

  • Understand the underlying cryptographic technologies that compose an IPsec VPN

  • Understand basic IPsec VPN configuration techniques

  • Understand common issues that can affect all IPsec designs

After you are familiar with the content of Part I, you should have the working knowledge of IPsec VPNs necessary to begin building a knowledge base surrounding the fundamentals of IPsec VPN High Availability using the design concepts provided in Part II. The chapters in Part I include:

  • Chapter 1, "Introduction to VPN Technologies" This chapter includes an introduction to various VPN technologies, discusses how VPNs are utilized in today's networks, and identifies the drivers for business migration to VPN technologies. The discussion in this chapter provides the reader with a high-level overview of VPN, particularly with a comparison between Multiprotocol Label Switching (MPLS), Virtual Private Dialup Network (VPDN), Secure Sockets Layer (SSL), and IPsec VPNs. After a brief comparison of the VPN technologies, the focus turns to the business drivers for VPN, which include both economics and security.

  • Chapter 2, "IPsec Fundamentals" This chapter focuses on the underlying components and mechanics of IPsec, including cryptographic components, Internet Key Exchange (IKE), and IPsec. This chapter includes basic configuration examples (not step-by-step) to demonstrate the concepts.

  • Chapter 3, "Basic IPsec VPN Topologies and Configurations" This chapter demonstrates building of basic VPN topologies using the knowledge gained in the previous chapters. Three basic topologies are discussed: hub-and-spoke without generic routing encapsulation (GRE), hub-and-spoke VPN with GRE, and remote-access VPN.

  • Chapter 4, "Common IPsec VPN Issues" IPsec deployments can involve a number of potential pitfalls if not properly addressed. Chapter 4 discusses the common IPsec VPN issues that a network engineer should take into consideration during the design and deployment process. It discusses common troubleshooting techniques to diagnose these problems should they occur in your network. Design solutions to the common VPN issues presented in this chapter are provided, along with the appropriate design verification techniques.

Part II consists of Chapters 5 through 10. The topics discussed here build on the introductory concepts from Part I, extending them to encompass a common architectural goal: High Availability. Additional architectural variations are provided so as to present a comprehensive scope of design options available. The chapters in Part II include:

  • Chapter 5, "Designing for High Availability" This chapter discusses the basic principles of an HA VPN design. Based on these principles, subsequent chapters develop solutions for local and geographical HA and discuss issues and options for achieving HA in multi-vendor VPN environments.

  • Chapter 6, "Solutions for Local Site-to-Site High Availability" This chapter uses concepts previously described to develop solutions for local HA, including the use of highly available interface for IPsec tunnel termination, stateless tunnel termination HA, and stateful tunnel termination HA.

  • Chapter 7, "Solutions for Geographic Site-to-Site High Availability" This chapter uses concepts previously described to develop solutions for geographic HA. This chapter discusses RRI, IPsec with GRE tunnels, and Dynamic Multipoint VPN.

  • Chapter 8, "Handling Vendor Interoperability with High Availability" Unfortunately, current IPsec standards do not address HA. This leads to interoperability issues among vendors. This chapter discusses common issues and details the options that exist to handle these scenarios.

  • Chapter 9, "Solutions for Remote Access VPN High Availability" This chapter discusses the HA concepts previously discussed in Chapters 6 and 7 in the context of RAVPN deployments. Additionally, it covers other HA tools commonly found in RAVPNs, including the use of VPN concentrator clustering with VCA and DNS-based load balancing.

  • Chapter 10, "Further Architectural Options for IPsec" This chapter discusses other architectural variations in designing VPN solutions. It describes each option with usage considerations and finishes with case studies of each.

IPsec VPN design concepts range from fundamental cryptographic operations to dynamic spoke-to-spoke peering and MPLS VPN routing and forwarding (VRF)-Aware IPsec VPNS. Although the scope of this book is firmly centered around the fundamental concepts of IPsec VPN design, the chapters included in Part III provide design guidance around two advanced topics of IPsec that are quite commonly deployed in today's enterprise-class IP networks:

  • Chapter 11, "Public Key Infrastructure and IPsec VPNs" This chapter discusses the usage of public key infrastructure (PKI) to authenticate IPsec peers via Rivest, Shamir, and Adelman (RSA) signatures. This method uses a certificate authority as a trusted third party to secure and scale IKE authentication. As organizations become more Public Key Infrastructure (PKI)-aware, this will become the de facto authentication mechanism.

  • Chapter 12, "Solutions for Handling Dynamically Addressed Peers" Dynamic peers allow network administrators to ensure network connectivity when remote network peers are either not known in advance or change to an unknown value over time. Dynamic peers also require less administrative effort than do static peers. This chapter addresses IPsec dynamic peering options, some of which are less commonly used, and others that are more prolific in various architectures.


Part I: Introductory Concepts and Configuration/Troubleshooting

Chapter 1 Introduction to VPN Technologies

Chapter 2 IPsec Fundamentals

Chapter 3 Basic IPsec VPN Topologies and Configurations

Chapter 4 Common IPsec VPN Issues


Chapter 1. Introduction to VPN Technologies

Modern business environments have been consistently changing since the advent of the Internet in the 1990s. Now more than ever, organizational leaders are asking themselves how efficiencies can be gained through making their workforce more mobile and thus increasing the scope of sales and distribution channels while continuing to maximize the economies of scope in their existing data infrastructure investments. Virtual private network (VPN) technologies provide a means by which to realize these business efficiencies in tandem with greatly reduced IT operational expenditures. In this chapter, we will discuss how today's VPN technologies enable enterprise workforces to share data seamlessly and securely over common yet separately maintained network infrastructures, such as through an Internet service provider (ISP) between enterprise networks or with corporate extranet partners. We will introduce several IPsec VPN topologies commonly found in today's enterprise networks, and we will conclude with the overview of two IPsec VPN business models, complete with cost savings realized by the enterprise.


VPN Overview of Common Terms

A VPN is a means to securely and privately transmit data over an unsecured and shared network infrastructure. VPNs secure the data that is transmitted across this common infrastructure by encapsulating the data, encrypting the data, or both encapsulating the data and then encrypting the data. In the context of VPN deployments, encapsulation is often referred to as tunneling, as it is a method that effectively transmits data from one network to another transparently across a shared network infrastructure.

A common encapsulation method found in VPNs today is Generic Routing Encapsulation (GRE). IP-based GRE is defined in IETF RFC 2784 as a means to enclose the IP header and payload with a GRE-encapsulation header. Network designers use this method of encapsulation to hide the IP header as part of the GRE-encapsulated payload. In doing so, they separate or "tunnel" data from one network to another without making changes to the underlying common network infrastructure. Although GRE tunnels have primitive forms of authentication, as we'll explore in later chapters when discussing dynamic multipoint VPN (DMVPN) deployments, they currently provide no means to provide confidentiality, integrity, and non-repudiation natively. Nevertheless, GRE tunneling is a fundamental component of many different IP Security Protocol (IPsec) designs, and will be discussed frequently in subsequent chapters.

Note

Although IPSec-processed data is encrypted, it is also encapsulated with either Encapsulating Standard Protocol (ESP) or Authentication Headers (AH).

Encryption refers to the act of coding a given message into a different format, while decryption refers to decoding an encrypted message into its original unencrypted format. For encryption to be an effective mechanism for implementing a VPN, this encrypted, encoded format must only be decipherable by those whom the encrypting party trusts. In order to deliver upon these requirements, encryption technologies generally require the use of a mathematical operation, usually referred to as an algorithm, or cipher, and a key. Although generally complex in nature, mathematical functions are known. It is the symmetric key, or as you'll see in the case of asymmetric cryptography, the private key, that is to be kept unknown to would-be attackers. The key is the primary way to keep the encrypted tunnel secure. This book discusses these two common types of cryptographic operations: symmetric key encryption and asymmetric key encryption. Other types of encryption discussed in the framework of this book include secure hashes and digital signatures.


Characteristics of an Effective VPN

VPNs exist to effectively, securely, and privately protect data that is transmitted between two networks from the common, shared, and separately maintained infrastructure between the two networks. In order to effectively perform this task, there are four goals that a confidential VPN implementation must meet:

  • Data confidentiality: Protects the message contents from being interpreted by unauthenticated or unauthorized sources.

  • Data integrity: Guarantees that the message contents have not been tampered with or altered in transit from source to destination.

  • Sender non-repudiation: A means to prevent a sender from falsely denying that they had sent a message to the receiver.

  • Message authentication: Ensures that a message was sent from an authentic source and that messages are being sent to authentic destinations.

Incorporating the appropriate data confidentiality capabilities into a VPN ensures that only the intended sources and destinations are capable of interpreting the original message contents. IPsec is very effective at encrypting data using the encapsulating security protocol (ESP), described in RFC 1827. Utilizing ESP, IPsec transforms clear text in to encrypted data, or cipher text. Because ESP-transformed messages are only sent across in their ciphered representations, the original contents of the message are kept confidential from would be interceptors of the message. Figure 1-1 illustrates a high-level exchange of encrypted message between to endpoints, James and Charlie.

Figure 1-1. Confidentiality and Authenticity in Encrypted Communications

[View full size image]

Encrypting messages relies on the use of a key to encrypt clear text and to decrypt ciphered messages. In the exchange of messages in Figure 1-1, both James and Charlie require the appropriate keys to encrypt and decrypt communications from each other. Assuming that these keys were exchanged or derived securely (for example, via a Diffie-Hellman exchange, which is discussed in detail in Chapter 2, "IPsec Fundamentals"), when James receives a message from Charlie that he is able to decrypt, he can be assured that the message has been delivered with full confidentiality, and vice versa.

Hashes and digital signatures protect the integrity of a specific communication of data. Hashes and digital signatures append unique messages to the original message before transmission that ensure that the message has not been tampered with in transit. Figure 1-2 illustrates the operation of a hash performed on a message to ensure data integrity.

Figure 1-2. Data Integrity, Secure Hashes

[View full size image]

By providing a unique fingerprint specific only to the sender of the message, a digital signature also provides the receiver a method of message authentication and sender non-repudiation. Notice in Figure 1-3 that digital signatures require the use of a public decryption key unique to the sender's private encryption key. The use of this cryptographic keypair thus guarantees message authenticity, ensuring that the message was sent from the authentic origin, and safeguards against sender non-repudiation, preventing a situation in which the sender of a specific message intentionally and falsely denies their transmittal of the message. While a secure hash can provide data integrity, digital signatures provide added levels of security by offering message authentication and sender non-repudiation, the operation of which is illustrated in Figure 1-3.

Figure 1-3. Message Authenticity and Data Non-Repudiation with Digital Signatures

[View full size image]


VPN Technologies

Although IPsec-based VPNs represent one of the most secure and widely deployed types of VPNs, they are only one of many VPN technologies in existence today. As we'll discuss throughout the course of this book, VPNs have been designed to protect data at almost every layer of the OSI stack. For example, customers in different market verticals will deploy a range of encryption technologies, from Layer 1 bulk encryptors to encryption technologies embedded within the applications themselves (SSL-based VPNs).

The OSI model consists of 7 layers, Physical, Data-Link, Network, Transport, Session, Presentation, and Application. Although our primary focus will be IPsec VPNs, which are a Layer 3 VPN technology, it is important to understand IPsec VPNs within the context of other VPN technologies corresponding to different layers within the OSI stack. Figure 1-4 illustrates the OSI stack and provides some examples of VPN technologies that operate at each corresponding OSI layer

Figure 1-4. VPN Technologies and the OSI Model

[View full size image]

Virtual Private Dialup Networks

Virtual private dialup networks (VPDN) are used to tunnel data across a shared media. Although the primary goal of a VPDN is to tunnel data across shared network infrastructures, some VPDNs may also incorporate data confidentiality. Most VPDNs rely on the use of PPP to encapsulate data in transit across a common network infrastructure. Typical VPDN deployments consist of one or many PPP clients establishing a PPP session that terminates on a device at the opposite end of the tunnel, usually located at a central location within the enterprise or service provider edge. In doing so, a secure point-to-point tunnel is established from the client's network to the PPP concentrator. After the tunnel has been established, the client's network appears as if it were the same network as the enterprise side, while the underlying common network infrastructure across which data is tunneled remains unchanged. Common VPDN technologies deployed in today's networks include Layer 2 Forwarding Protocol, Point-to-Point Tunneling Protocol, and Layer 2 Tunneling Protocol.

Layer 2 Forwarding Protocol

The Layer 2 Forwarding (L2F) Protocol was originally developed by Cisco Systems as a way to tunnel privately addressed IP, AppleTalk, and Novell Internet Protocol Exchange (IPX) over PPP or Serial Line Internet Protocol (SLIP) dialup connections over shared networks. In order to do this, this VPDN technology concentrates tunnels at a home gateway, allowing all dial-up networks to appear as if their physical point of termination is the home gateway itself, regardless of the location of their actual dialup termination point. L2F uses control messages on UDP port 1701 to establish the session. Once a tunnel is established, L2F-encapsulated packets are forwarded in parallel with L2F control datagrams. Both L2F control and payload datagrams are forwarded on UDP 1701. The L2F encapsulated PPP packets have the format described in Figure 1-5.

Figure 1-5. L2F Data Packet Format

During the creation of an L2F tunnel, initially a user dials into the Network Access Server (NAS), negotiates PPP, and is authenticated with either Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP), as illustrated in Figure 1-6.

Figure 1-6. L2F Topology and Tunnel Establishment

[View full size image]

Note

In an L2F environment, a "home" gateway refers to a gateway located at the corporate headquarters.

The following steps describe the creation of an L2F tunnel, as illustrated in the steps in Figure 1-6:

1.
NAS and the PPP client negotiate a PPP session. NAS authenticates the PPP client with CHAP (or, optionally, PAP).

Note

The NAS can optionally authenticate PPP connections against the AAA (or in this case, Cisco Secure Access Control Server) server in the service provider cloud. Managing user connections centrally would ease the administrative burden and provide additional accounting and user database synchronization capabilities (that is, synchronization with NT databases and automated backup of AAA data on peer CSACS databases).

Once the PPP session has been authenticated, a series of exchanges are performed to offload the termination of the dialup session to the home gateway. Figure 1-7 illustrates the CHAP handshake between the PPP client and the NAS shown in Figure 1-6.

Figure 1-7. PPP Authentication with CHAP

[View full size image]

2.
NAS initiates a tunnel connection to the home gateway.

3.
The home gateway authenticates NAS against the authentication database (RADIUS or TACACS+).

4.
The home gateway confirms acceptance of the tunnel negotiation initiation request from NAS.

5.
The home gateway and PPP client negotiate additional authentication, authorization, accounting, IP addressing, and tunneling parameters.

6.
An L2F tunnel is established and maintained between the PPP client and the home gateway.

Note

For more information on L2F, refer to RFC 2341 at http://www.ietf.org/rfc/rfc2406.txt.

Point-to-Point Tunneling Protocol

Point-to-point Tunneling Protocol (PPTP), a technology originally created by Microsoft, provides a seamless integration of remote PPP capable devices into an enterprise network. PPTP leverages authentication parameters inherent to native PPP and the tunneling capabilities of GRE to establish a VPDN. After a client has established a PPTP tunnel to a concentrator on a centralized enterprise network resource, that client appears as if it were part of the enterprise network itself, regardless of the underlying common infrastructure that the data is tunneled across. Consider the following exchange between a small remote office network (the PPP client) and a corporate VPDN (PPTP) concentrator. Figure 1-8 illustrates the order of operations executed when a client accesses the VPDN using PPTP.

Figure 1-8. PPTP Topology and Tunnel Negotiation

[View full size image]

The PPP client in this scenario needs to connect to their enterprise network. The corporation's security policy mandates that data be separated from the common service provider infrastructure and that central network connectivity provided by the service provider must remain transparent to the PPP clients, who are PSTN or ISDN attached. In order to accomplish this task, PPTP is used to provide an end-to-end tunnel for PPP connections inbound to the service provider.

Generally, there are two different types of PPTP VPDN tunnels: compulsory tunnels and voluntary tunnels. Compulsory tunnels are formed when a PPP client accesses the NAS or PPTP Access Concentrator (PAC). The NAS/PAC in turn establishes a tunnel with the PPTP Network Server (PNS). Voluntary tunnels are formed when a PPP client directly negotiates a PPTP tunnel with the PNS. The creation of a voluntary PPTP tunnel executes the following steps (illustrated in Figure 1-8):

1.
The first step in the negotiation occurs when the PPP client establishes a connection with the NAS and is authenticated through a chosen form of PPP authenticationPAP, CHAP, or Microsoft CHAP (MS-CHAP). PPTP tunnels can be encrypted through the use of Microsoft Point-to-Point Encryption (MPPE) to provide confidentiality in VPDNs. Cisco IOS supports both 40- and 128-bit MPPE encryption. In order to encrypt a PPTP tunnel using MPPE, the network administrator must use MS-CHAP to authenticate PPP connections to the NAS.

Tip

Authentication of PPP sessions can be passed to a centrally managed authentication database, such as CSACS via RADIUS or TACACS+. Authenticating PPP sessions against a CSACS database greatly eases administration of user authentication data for VPN access.

2.
Now that the PPP client has accessed the service provider network, the client has IP connectivity to the PNS at its corporate headquarters. The PPP client and the PNS must maintain two connections to one anothera control connection and a tunnel protocol connection. The PPTP control connection maintains the connection state and negotiates call setup and teardown. As such, it must be established before the tunnel protocol connection can be established. Once an NAS receives the call from the PPP client, the next step in creating the VPDN connection is to either establish a compulsory tunnel from the NAS/PAC to the PNS or to establish a voluntary tunnel from the PPP client itself to the PNS. In Figure 1-8, the PPP client elects to establish a voluntary tunnel directly to the PNS. In this scenario, the PIX is acting as the PNS for the PPTP exchange. The client initiates the tunnel by establishing a TCP connection to the PNS on port 1723.

Caution

In many cases, including the example in Figure 1-8, TCP port 1723 must be allowed through any corporate firewalls or other filtering security devices for PPTP to operate correctly. In this scenario, the PIX would be configured with the appropriate static translation and access list entry on its outside interface to allow TCP sessions from remote clients on port 1723.

3.
Once the PPP client and the PNS have TCP connectivity, they can start to exchange PPTP tunnel negotiation information between them. The tunnel negotiation process consists of exchanging connection request and reply messages as defined in RFC 2673 between the PNS and the PPP client.

Tip

As with PPP authentication on the NAS/PAC, PPTP connections on PIX firewalls and Cisco routers can be authenticated against a Cisco Secure ACS database using RADIUS or TACACS+. Implementing user accounts on a central CSACS database greatly eases administrative overhead.

4.
Once the PPTP control connection has negotiated call setup, call maintenance, and tunnel parameters accordingly, a second session is establishedthe PPTP tunnel connection itself. The PPTP tunnel connection uses a modified version of GRE to tunnel PPP frames over the IP cloud, which, in Figure 1-8, is the service provider network. The GRE-encapsulated format of the PPTP tunneled packet is illustrated in Figure 1-9.

Figure 1-9. PPTP Tunnel Protocol Data Structure

Note

The header used in the PPTP encapsulation process is similar to a GRE header, with some slight modifications to the specification outlined in RFC 1701. The PPTP version of the GRE header includes an acknowledgment field to determine the rate at which packets are traversing the PPTP tunnel.

The preceding scenario describes a voluntary PPTP tunnel negotiation between the PPP client, which also acts as its own PAC, and the corporate PIX Firewall, acting as the PNS. In a compulsory PPTP tunnel negotiation, the NAS would act as the PAC and would multiplex multiple sessions from the PPTP clients into a single tunnel to the PIX, or PNS. The exchanges in a compulsory tunnel would follow the same steps chronologically, but would appear as displayed in Figure 1-10.

Figure 1-10. A PPTP Compulsory Tunnel Setup between PAC and PNS

[View full size image]

Note

Although both L2TP and PPTP support both voluntary and compulsory tunnels, Cisco IOS only supports voluntary and compulsory tunnels for L2TP. While voluntary PPTP tunnels are supported in Cisco IOS, compulsory PPTP tunnels are currently not supported.

As depicted in Figure 1-10, only a single tunnel is negotiated between the PAC/PNS pair. In a voluntary exchange, it is possible that all 5 PPP clients dialing into the NAS terminate separate tunnels with the PIX/PNS. As such, compulsory tunnel architectures can be used to keep tunnel termination overhead low on the PNS. In the examples in this chapter, the voluntary tunnel negotiation option could yield up to five times the tunnel maintenance of a compulsory tunnel negotiation option (five PPP clients initiating tunnels to the PIX in a voluntary arrangement vs. one tunnel initiated from the NAS in a compulsory setting).

Compulsory tunnels, however, do not offer end-to-end confidentiality with MPPE. In the preceding compulsory arrangement, the PPP connections to the NAS would remain unencryptedonly the connection from the PAC to the PNS would be encrypted with MPPE. As such, those network administrators requiring fully confidential exchange of data in their PPTP environments should choose to allow their clients to voluntarily negotiate an end-to-end PPTP tunnel with the PNS or, in this case, the corporate PIX Firewall. In doing so, the network administrator can ensure that all legs of the VPDN from their remote dialup hosts using PPP to their corporate PNS are encrypted for end-to-end data confidentiality.

Layer 2 Tunneling Protocol

Layer 2 Tunneling Protocol (L2TP) is a collaborative effort to develop a standards-based VPDN protocol within IETF. Vendors collaborating on this initiative include, among others, Cisco and Microsoft. As with PPTP, L2TP is a client-server operation consisting of two main components:

  • L2TP Access Concentrator (LAC) The LAC represents the client side of this network and typically exists on the switch infrastructure between remote dialup nodes and the access server that terminates the inbound PPP sessions across the switched ISDN or PSTN infrastructure. As remote hosts initiate and terminate PPP connections on the NAS, the LAC serves as a proxy originator of L2TP control and tunnel data to the LNS at the corporate network. LACs are often collocated with the access server itself. A Cisco router or access server is capable of providing LAC functionality within a VPDN.

  • L2TP Network Server (LNS) The LNS represents the server side of this VPDN architecture. It resides within the enterprise network and terminates tunneled data from the LAC. As users connect to the LAC, connections are multiplexed across the negotiated tunnel to the LNS, where they are eventually terminated.

A typical L2TP session resembles a compulsory PPTP tunnel negotiation between a PAC and a PNS. As with PPTP, two types of data are forwarded into an L2TP tunnelcontrol data and tunnel data. Unlike PPTP, however, L2TP is not connection oriented. Instead, it is packet oriented. So, whereas PPTP relied on a TCP-based connection to establish a control channel between the PAC and PNS, L2TP uses UDP to maintain control data and tunnel data simultaneously. L2TP leverages the use of control messages and data packets as follows:

  • L2TP control messages negotiate tunnel setup and maintenance. Control messages establish tunnel IDs for new connections within an existing tunnel. They also tear down and remove previously established tunnel IDs within an existing L2TP tunnel. L2TP control messages are originated on a given source port and forwarded to UDP destination port 1701.

  • L2TP payload packets tunnel data within a given network. When data is tunneled from LAC to LNS across an IP cloud, it is encapsulated with an L2TP header. The format of the L2TP payload is illustrated in Figure 1-11. As with L2TP control messages, L2TP payload packets are forwarded to UDP 1701.

    Figure 1-11. L2TP Tunnel Protocol Data Structure

    [View full size image]

Note

L2F control and payload packets are also sent on UDP port 1701. Network devices inspect the version field to differentiate between L2F and L2TP packet formats.

Figure 1-12 depicts a sample L2TP tunnel setup in which a company uses L2TP to establish seamless, secure connectivity across an untrusted media. In this case, that shared network is the ISP cloud. The ISP owns the access server that terminates the customer's dialup connection using PPP as the Layer 2 protocol. In this example, the access server also serves as the LAC. The LNS is located on the customer premises and terminates the L2TP tunnel originated from the LAC.

Figure 1-12. L2TP Tunnel Negotiation

[View full size image]

The following steps outline the creation of the L2TP VPDN from the remote host to the corporate network as described in Figure 1-12:

1. | The user dials in to the NAS/LAC over PSTN or ISDN. The user establishes a PPP connection with the NAS and is authenticated with CHAP.
2. | The user initiates an L2TP tunnel and is prompted for a username and password. The ISP inspects the remote user's username and authenticates it against its central authentication database via TACACS+ or RADIUS.
3. | Once authenticated, the LAC initiates an L2TP tunnel to the LNS located at their corporate facility.
4. | The LNS receives the request for tunnel negotiation and optionally authenticates the request against the corporate central authentication database via TACACS+ or RADIUS. The LNS responds with either an acceptance or a rejection of the tunnel initiation to the LAC.
5. | The LNS creates a virtual interface for the tunnel ID corresponding to the requesting remote PPP client. The remote PPP client and the LNS are now able to exchange authentication, authorization, accounting, and IP addressing data with one another over the tunneled PPP session. L2TP headers are stripped on ingress at the LNS for inbound connections from the PPP client. Likewise, L2TP headers are stripped at the LAC for outbound connections from the LNS to the PPP client.
6. | A PPP connection now exists between the PPP client and the LNS. Additionally, an L2TP tunnel has been negotiated between the LAC and the LNS. When a new PPP client attempts to access the corporate network and is authenticated at the ISP, the LAC does not create a new L2TP tunnel but instead adds a new tunnel ID to the existing tunnel for that client.

Multiprotocol Label Switching VPNs

Multiprotocol Label Switching (MPLS) VPNs logically separate VPN traffic over a shared media through the use of VPN Routing and Forwarding Instances (VRFs). In an MPLS network, different devices play different roles to achieve this logical separation:

  • Provider (P) Router: P routers typically comprise the MPLS core and therefore provide transport between PE routers. Instead of using IP routing information base (RIB) or IP forwarding information base (FIB) lookups to make forwarding decisions, P routers use a label forwarding information base (LFIB) lookup to make their forwarding decisions. Convergence of the LFIB between P routers in the provider network is facilitated through the use of Label Distribution Protocol (LDP).

  • Provider Edge (PE) Routers: PE routers typically provide the interface between the service provider and the customer, and it is most common for the provider to own the PE router. PE routers communicate information about VPNv4 addresses, including the IPv4 prefix and 8-byte route descriptor, between one another using the Multiprotocol Border Gateway Protocol (MP-BGP), enabling convergence at the PE.

    Note

    MP-BGP plays a critical role in the convergence of an MPLS VPN. For more information on MP-BGP and its role in MPLS VPNs, please refer to the following IETF RFC:

    http://www.ietf.org/rfc/rfc2547.txt

  • Customer Edge (CE) Routers: CE routers provide the interface to the PE routers. CE routers typically perform forwarding decisions based on standard RIB or FIB lookups, and convergence between CE routers and the PE router can typically be achieved through the use a standard IGP.

Caution

An MPLS VPN does not provide confidentiality unless it is deployed in conjunction with IPsec.

A VRF describes a separate routing and forwarding table, enabled by the use of Route Descriptors, which are 8-byte unique identifiers derived from VPN-specific information at the provider edge (PE). MPLS VPNs enable customer edge (CE) routers to establish normal Layer 3 RP adjacencies with MPLS-aware PE routers. Each PE router is MPLS VPN aware and is able to forward traffic to its destination PE router on the opposite side of the provider core using VPNv4 addresses learned from MP-BGP advertisements from other PE routers. The provider core routers remain unaware of the customer network's routing table or IP addressing information. Instead, traffic is switched within the MPLS cloud using labels and an entry in the P router's label forwarding information base (LFIB). Figure 1-13 illustrates IP-routed and VRF-routed domains with MPLS.

Figure 1-13. Traffic is IP-Routed to the Provider Edge (PE)

[View full size image]

When the traffic from the customer edge reaches the PE router, it is then label switched across the MPLS Service Provider core to its destination PE router. In this manner, customer routing and IP addressing information is kept virtual and private from the provider corethe P routers use MPLS labels and an associated LFIB entry to forward the traffic across the MPLS core rather than IP addressing information.

When MPLS-switched traffic arrives at the destination PE router, traffic can be forwarded to neighboring CE routers based on the previously installed VPNv4 address learned from MP-BGP advertisements from neighboring MP-BGPenabled PE routers. The CE routers perform IP RIB lookups to determine the appropriate destination and forwarding decisions within the customer core IP network.

The operation of MPLS offers separation of multiple virtual data networks across a shared network such as an ISP. The addition of MPLS labels at the service provider core allows customers to separate networks from other customers virtually over a shared core network such as a service provider network. The use of route descriptors on PE nodes provides separation at the control plane, allowing customers to use overlapping address space and overlapping services that would normally present conflict within a non-MPLS environment. As mentioned previously, data-plane separation is achieved using VPN labels to make the forwarding decisions on PE routers.

IPsec VPNs

IPsec VPNs encrypt data at the Layer 3 IP packet layer, offering a comprehensively secure VPN solution through providing data authentication, anti-replay protection, data confidentiality, and data integrity protection. As such, IPsec is one of the most widespread VPN technologies in today's enterprise, service provider, and government networks. Using ESP in tunnel mode, IPsec supports the rewrite of Type of Service (ToS) bits into an outer IP header, thereby supporting encrypted data payloads while preserving quality of service (QoS) within a given network. IPsec is a standards-based protocol and therefore supports interoperability across products from multiple vendors.

Note

Although IPsec is standards based, there are many optional components of IPsec (not required for RFC compliance) and proprietary innovations that present compatibility considerations in multi-vendor environments. We will discuss these design considerations in greater detail in Chapter 8, "Handling Vendor Interoperability with High Availability."

As we will discuss, IPsec is supported within Cisco IOS on a wide array of different routers, firewalls, VPN Service Modules, VPN concentrators, and VPN clients. Likewise, Cisco offers a variety of different hardware-based VPN acceleration options for enhanced VPN performance within a network. IPsec will serve as the primary VPN discussion point for the duration of this book.

IPsec VPNs tunnel data across shared media using ESP, AH, or a combination of both. These two standards-based protocols both use symmetric encryption technology.

Note

The precise operation of ESP and AH are outlined more comprehensively in Chapter 2.

IPsec-supported symmetric encryption transforms include data encryption standard (DES, 56-bit transform), triple data encryption standard (3DES, 168-bit transform), and most recently, advanced encryption standard (AES, 256-bit transform). Security parameters, including keys used for symmetric encryption, are communicated securely using the Internet Key Exchange (IKE) protocol, which is also considered part of the IPsec protocol suite. The operation of protocols incorporated within the IPsec protocol suite is discussed in greater detail in Chapter 2. Subsequent chapters will explore design considerations of IPsec-based VPNs.

Transport Layer VPNs

Transport layer VPNs provide an additional layer of security at the transport of the OSI stack. Transport layer VPNs typically consist of a client application and a server. A transport layer VPN will undergo a handshake to agree on common parameters to use for the SSL or TLS session, including cryptographic keying material and transforms. The messages in this handshake are confidentially exchanged between client and server, typically with a form of public key encryption such as RSA encryption. During the handshake, the client and server also agree on a set of symmetric session keys and a symmetric key transform, such as DES or 3DES, for bulk data encryption over the SSL VPN.

Secure Socket Layer VPNs

In today's network architectures, Secure Socket Layer (SSL) VPNs represent one of the most popular choices for transport layer security. SSL was originally developed by Netscape in 1994 to secure client/server applications across the Internet. SSL is effective at providing data authentication, data integrity, and data confidentiality between client and server applications, but it does not offer data non-repudiation services. As discussed before, SSL is performed over TCP in the transport layer of the OSI stack, as illustrated in Figure 1-14.

Figure 1-14. SSL and the OSI Stack

SSL follows five broad steps when establishing a secure sessionclient exchange of cryptographic parameters, server exchange of cryptographic parameters, cryptographic key derivation, session authentication, and secure data exchange. Refer to the scenario illustrated in Figure 1-15 for the following description of SSL tunnel negotiation. In the SSL tunnel negotiation, public key encryption is typically used for initial client and server authentication. The client and server also exchange public keys to encrypt each message in the handshake. Once the handshake is completed, symmetric key transforms are used for bulk data encryption between client and server.

Figure 1-15. SSL Tunnel Establishment

[View full size image]

The following order of operations describes the SSL handshake illustrated in Figure 1-15:

Note

RSA signatures are commonly used to facilitate the authentication and confidential exchange of messages during the SSL handshake. RSA Signatures, including x.509-based certificates and certificate authorities, are discussed in full detail in Chapter 2 and Chapter 12, "Public Key Infrastructures and IPsec."

1.
Client Exchange of Cryptographic ParametersThe client and server must agree on the parameters used for encryption, such as the encryption algorithm, key exchange method, and hash method to use for data integrity. If the client and server have not already agreed on these parameters, then the client will initiate the exchange of messages to negotiate mutually acceptable parameters to use for future operations using by sending a CLIENT-HELLO message to the concentrator.

2.
Server Exchange of Cryptographic ParametersThe server responds to the CLIENT-HELLO message with a SERVER-HELLO message and, optionally, several other messages:

  • SERVER-CERTIFICATE Contains the servers's public key for server authentication and pre-master secret encryption.

  • SERVER-KEY-EXCHANGE Optionally used to encrypt the CLIENT-KEY-EXCHANGE message in Step 3 below.

  • CLIENT-CERTIFICATE-REQUEST The SSL concentrator or server can optionally request a client certificate for authentication. If this message is sent to the client, the client's server must be forwarded to the SSL concentrator and successfully validated.

The SERVER-HELLO will specify the parameters to use for the SSL session, including the highest version ID and the strongest supported symmetric key cipher specified in the CLIENT-HELLO message from Step 1. At this point, the client and server should have the appropriate information necessary to agree on cryptographic parameters. A SERVER-HELLO-DONE message is then forwarded to the SSL client to indicate that the SSL server has received the required information for this sequence of the handshake and is awaiting information from the client (as described in the next step).

3.
Cryptographic Key DerivationThe client is now ready to generate and share its pre-master secret key with the SSL server. The pre-master secret is comprised of a 48-byte value (in the case where RSA is used). This value is then encrypted with the SSL server's public key and forwarded to the SSL server using a CLIENT-KEY-EXCHANGE message. Optionally, the client will also forward two additional messages at this point in the SSL handshake:

  • CLIENT-CERTIFICATE The client must possess a certificate and forward it to the server using this message if the client receives a CLIENT-CERTIFICATE-REQUEST in Step 2 above.

  • CERTIFICATE-VERIFY This message is a hash of all previous handshake messages appended. It is sent to the SSL server to validate the authenticity and data integrity of the CLIENT-CERTIFICATE message (and all other previous handshake messages) if the client receives a CLIENT-CERTIFICATE-REQUEST in Step 2 above.

The SSL Server decrypts the CLIENT-KEY-EXCHANGE message to obtain the pre-master secret sent by the client. The client and server then derive the master secret by hashing the pre-master secret with the ClientRandom and ServerRandom values shared in Step 1. The master key is then used to derive 4 session keys that SSL will use to encrypt data:

  • Client Write MAC Secret Client uses this key to create a hash appended to the original message; server uses this key to verify the hash.

  • Server Write MAC Secret Server uses this key to create a hash appended to the original message; client uses this key to verify the hash.

  • Client Write Key Client uses this key to encrypt messages; server uses it to decrypt messages.

  • Server Write Key Server uses this key to encrypt messages; client uses it to decrypt message.

The client concludes this phase of the SSL handshake by sending a CLIENT-FINISHED message to the server. The FINISHED message contains a hashed value of all previous messages in the handshake to this point. The server verifies this message to determine that the previous exchanges have indeed been authentic with preserved data integrity.

4.
Session AuthenticationThe SSL concentrator or server must validate the hash (MAC) sent in the client FINISHED message received in Step 3 above. Upon successful validation of the MAC contained in the client FINISHED message, the server now safely assumes that the SSL handshake has proceeded with authenticity and preserved data integrity. The server subsequently forwards a server FINISHED message to the SSL client containing a MAC resulting from a hash of all previous messages in the handshake to this point. Upon receipt of this message, the SSL client performs a validation of the MAC received in the server FINISHED message so that it too can assume that the handshake has completed with authenticity and preserved data integrity.

5.
Confidential Exchange of Data with Preserved IntegrityThe client and server now use the session keys derived from the master secret in Step 1 to encrypt and decrypt data sent to and from one another. This is done through an agreed-upon cipher transform such as DES or, in this case, 3DES. However, to ensure data integrity, a hashed message authentication code (HMAC) is appended to the original message. The newly formed payload (original message + HMAC) is encrypted with the selected transform.

Note

The creation of hashed message authentication codes is covered in greater detail in Chapter 2.

Transport Layer Security and SSL VPNs

SSL was originally developed by Netscape and has proven to be effective for HTTPS communications. However, the IETF standards track protocol for security at the transport layer is actually transport layer security (TLS). The operation of TLS is similar to SSL 3.0 but has significant modifications, specifically with respect to support for different cryptographic algorithms, that make the two incompatible with one another.

TLS has big implications in 802.1x identity-based networking systems, because extensible authentication protocol with TLS (EAP-TLS) is part of the 802.1x standard. Additionally, TLS is a critical component in wireless network security. Although not formally a component of the newly ratified 802.11i IEEE standard for wireless network security, EAP-TLS is the de facto means of authentication in 802.11i-compliant networks.


Common VPN Deployments

Network infrastructures in which a VPN technology may be commonly deployed include, but are not limited to, trunks to Internet service provider networks, corporate extranet partner networks, or even private leased line connections in a corporate intranet. Next, we will briefly explore some of the common situations in which a VPN may be deployed.

Site-to-Site VPNs

As cryptographic technology becomes more embedded in various network elements, growth in site-to-site VPN deployments has risen. A site-to-site VPN could be as simple as encrypting the link between two different nodes on a point-to-point connection. Or it could be slightly more complex, offloading the initiation and termination of the VPN tunnel to a firewall or VPN concentrator on each organization's DMZ. Figure 1-16 illustrates a simple site-to-site IPsec VPN deployment between two networks, A and B.

Figure 1-16. Simple Site-to-Site Design Scenario

[View full size image]

Although the two IPsec tunnel implementations in Figure 1-16 use the same physical topology to accomplish a similar task, there is a significant difference between these two simple site-to-site VPN designs. For example, if a smaller router is used for the WAN connection, there could be a substantial improvement in VPN performance by processing IPsec on the VPN concentrators. In such a case, the routed IPsec tunnel between the two VPN concentrators would be an optimal choice. However, if the PIX are performing network address translation (NAT), the VPN concentrators may need support for special features, such as IPsec NAT Transversal (IPsec NAT-T), for IPsec to work properly. If the concentrators do not have the appropriate features, the IPsec tunnel built over the point-to-point line might be a better option.

In the scenario in Figure 1-16, it is critically important to note that the flexibility to choose between the two tunnel deployments is enabled by the fact that IPsec VPNs operate at Layer 3, the network layer, of the OSI model. As such, VPNs are no longer limited to bulk data-link encryption techniques on physical point-to-point links. Instead, an IPsec VPN tunnel could be used to secure traffic between two endpoints over a series of routed networks. The simple design decision presented in Figure 1-16 is just an introduction to the wide array of design options that should be considered when securing a network with a Layer 3 VPN technology such as IPsec.

Site-to-Site VPN connections are not only used to secure connectivity between two different organizations, but they are also used to secure links within an organization itself. As technology continues to evolve, network nodes such as routers and switches are becoming more and more capable of handling cryptographic operations involved with IPsec VPNs. As such, the growth of site-to-site VPNs within internal corporate enterprise networks has grown accordingly. Figure 1-17 shows a common network topology in enterprise network WANsa hub-and-spoke topology. In this scenario, the 7200 terminates multiple point-to-point connections from a combination of branch routers.

Figure 1-17. Hub-and-Spoke Networks and Site-to-Site VPNs.

[View full size image]

Tip

Hardware-based crypto-accelerators allow head-end devices to scale the number of IPsec tunnels in a hub-and-spoke network dramatically. Cisco currently offers many choices for VPN hardware-based acceleration in routers and switches designed for the data center and branch office.

Tip

In a hub-and-spoke topology, a dynamic multipoint VPN (DMVPN) configuration can help scale the number of security associations supported. DMVPNs use next hop routing protocol (NHRP) and multipoint GRE (mGRE) tunnels to establish direct security associations between the branches, as opposed to one security association (SA) from branch to head-end and another from head-end to the destination branch. Chapter 8 covers DMVPN in greater detail.

Site-to-site VPN deployments are also popular in corporate extranets. When an organization requires dedicated site-to-site connectivity to a peer organization or subsidiary, often, a dedicated, high-speed WAN circuit is provisioned, not unlike the way Enterprise Network A is connected to Enterprise Network B in Figures 1-16 and 1-17. When an organization requires multiple dedicated external connections to other peer organizations, extranets are formed. Figure 1-18 illustrates an extension of the VPN topologies illustrated in Figure 1-16 and 1-17 to include a extranet deployment comprised of multiple site-to-site IPsec VPN tunnels.

Figure 1-18. Corporate Extranet and Site-to-Site VPNs

[View full size image]

Remote Access VPNs

Remote access VPNs (RAVPN) drive workforce mobility and productivity by allowing secure connectivity from any point that can establish a Layer 3 connection (or in the case of a VPDN, a Layer 2 connection) to the network. As home high-speed Internet access has increased throughout the world with the advent and deployment of cable modem technologies and DSL technologies, more companies are turning to RAVPN solutions to allow their workforce to establish secure connectivity to central corporate resources from remote locations.

RAVPN infrastructures consist of two main componentsthe VPN client and the VPN concentrator:

  • VPN clients can either be hardware based or software based. Cisco offers the 827 VPN router or the 3002 hardware-based VPN client for RAVPN solutions. Software-based VPN clients run on the remote or mobile user's desktop or laptop PC. Cisco offers VPN client software for RAVPN software-based client implementations.

  • VPN concentrators are used to terminate RAVPN connections inbound from VPN clients. Cisco VPN concentrators offer a scalable solution for terminating large amounts of IPsec connections from VPN clients in an RAVPN solution. VPN concentrators are also capable of providing LNS/PNS functionality for VPDN implementations.

Figure 1-19 illustrates a basic example of a corporate VPN architecture that supports IPsec RAVPN, VPDN, and Extranet VPN access to enterprise networking resources.

Figure 1-19. RAVPN Implementation

[View full size image]

SSL in RAVPN Architectures

Traditionally, SSL VPNs were embedded in web browsers for securing transactions in client/server architectures. However, as SSL can be deployed in specific applications, it enables RAVPN capabilities on a per-application basis. As such, SSL RAVPN solutions offer greater granularity over pure Layer 2 or 3 RAVPN solutions. For example, security administrators for Enterprise Network A may want to allow secure access only to e-mail or only for a specific application on a given web server, as opposed to allowing all of the remote user's IP traffic through the network. To achieve this, the remote user would use SSL client software installed with their web browser. The security administrator can then configure their VPN concentrator or web server to terminate the SSL VPN connection accordingly.


Business Drivers for VPNs

As the amount of data that traverses untrusted, shared infrastructures continues to increase, so does the need for secure transmission of that data. Now that you've seen some introductory concepts related to site-to-site VPNs, here are some examples of real-world business applications for site-to-site VPN deployments.

Global financial services organizations transfer billions of dollars worth of information across data links every day. Consider the common scenario of an institutional investor making a substantial equity trade based on real-time market data. The receiver of that instruction must be assured that the originator of the trade is authentic, or else millions of dollars could be lost by executing the transaction. Multiply the number of these types of transactions by thousands, and the economics of a VPN investment become apparentthe losses resulting from a single attack on such an institution could justify the investment required for the entire VPN deployment.

Large international retailers process thousands of orders daily from huge numbers of customers. In order to expand their customer reach, retailers are relying on online ordering systems, dependant on the Internet as a critical distribution channel. In each transaction, sensitive customer data is sent over untrusted mediathe service provider core. Retailers have responded by investing in transport-layer security mechanisms such as SSL to provide authentic, confidential exchange of data with ensured integrity. Providing VPN capabilities for additional security over connectivity to the retailer guarantees the private exchange of customer data, which is critical to consumer adoption of online ordering systems.

Regional hospitals and large insurance companies have been mandated by law to ensure the privacy of patient's medical information under the Health Insurance Portability and Privacy Act (HIPPA) of 1996. Consider the frequent communication of hospitals around the world to global health-insurance providers, and the need for large-scale deployment of site-to-site technologies becomes apparent. Health care providers represent just one element of critical infrastructure in which the demand for VPN technologies is growing. IPsec VPN solutions offer a robust and scalable solution to secure connectivity between hospitals and from hospital to insurance provider.

Remote Access VPN Business DriversA Practical Example

RAVPN business drivers are largely centered on enhancing workforce productivity and workforce flexibility. Organizations are now becoming more global in reach, and the need for a flexible, productive workforce is as critical as ever.

Workforce flexibility drives workforce productivity. The following RAVPN scenario describes how RAVPN investments translate in to direct hourly labor cost savings, ultimately impacting the bottom line. The economics for workforce flexibility can be illustrated with a simple scenario. Consider an organization that employs 10,000 employees at an average salary of $64,000/year. Each employee works approximately 2065 hours/year (40 hours/week), which includes paid time off of approximately two weeks (yielding labor costs of $640,000,000/year). The organization's chief security officer has authorized a pilot deployment for 10 workers to use an RAVPN solution. After inspecting the accounting records on the RAVPN concentrator, it was observed that the workers participating in the pilot program were logged on to the network approximately 12.5 percent longer than those who were not participating in the program. This translates in to a new average realized labor output of 45 hours/week with the new RAVPN solution in place. An RAVPN solution enabling the workforce to work an extra 5 hours/week would increase the total labor hours that the organization gets per year to 2346 hours/year. The final result is that the organization's direct hourly labor cost decreases from $30.99/hr to $27.28/hr (12.9 percent) with the new RAVPN implementation.

Site-to-Site VPN Business DriversA Practical Example

In the previous example, we discussed how a standard RAVPN deployment can decrease direct labor costs by enabling greater efficiencies in a mobile workforce. While IPsec RAVPNs provide costs savings in one form, site-to-site IPsec VPNs can yield cost savings in a different form, by decreasing the overall operation expenditures associated with the enterprise's maintenance of its dedicated WAN circuits.

Consider the case of an enterprise network in which the WAN architecture consists of a hub-and-spoke model with 160 branch sites connecting to the enterprise's headquarters over dedicated T-1 circuits. The enterprise's IT staff is interested in migrating their dedicated T-1 circuits to ISP broadband connections, but they cannot do so unless their data is guaranteed to be confidentially transmitted between the branch offices and headquarters. The enterprise addresses this need for confidentiality by establishing IPsec VPN gateways at each remote branch location and by building a site-to-site IPsec VPN tunnel between each branch IPsec VPN gateway and a VPN gateway located at the corporate headquarters.

The variable costs associated with the enterprise's current dedicated circuit deployments are approximately $480/month for a single site. Business-class single-site broadband service offered to the enterprise has been quoted at approximately $35/month, yielding a decrease in variable costs of approximately 92.7 percent. Although there are added fixed costs associated with migrating to an ISP-based site-to-site IPsec VPN solution, such as the initial fixed costs of buying the IPsec VPN headend router and associated branch site IPsec VPN gateways, the decrease in variable costs ($71,200/month or $854,400/year) greatly outweighs the initial expenditures associated with the architectural shift.


IPsec VPNs and the Cisco Security Framework

Cisco's end-to-end security strategy is summarized comprehensively by the Cisco Security Wheel (illustrated in Figure 1-20). A corporate security policy should exist at the center of every end-to-end corporate security strategy. Cisco Systems builds solutions to comprehensively and securely enforce security policies in today's business environment.

Figure 1-20. VPN Implementations and the Cisco Security Wheel

This book explores many secure designs relying on IPsec for confidentiality, authentication, non-repudiation, and data authenticity. Those designs will incorporate many of the products that fit within various segments of the security wheel comprising Cisco's end-to-end security product line, including firewalls, intrusion detection systems, authentication, authorization and accounting (AAA) technologies, policy management, and, most importantly, encryption technologies. With respect to Cisco's overall security strategy, this book focuses on how the existence of IPsec helps to improve a corporate security policy and how IPsec can be deployed effectively to secure a network within the scope of that security policy.

Note

The security wheel is a common framework for developing a security policy. Cisco builds components enabling effective and comprehensive enforcements of all components of the security wheel. The Cisco Security Wheel is a component of the Cisco's SAFE architecture. For more information on SAFE, please refer to the following URL:

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


Summary

A virtual private network delivers upon business needs for data confidentiality, data integrity, data authenticity, and non-repudiation. In doing so, A VPN hardens network infrastructure against untrusted, malicious activity. As the competitive landscape of business changes over time, VPN technologies will evolve to provide organizations the flexibility and productivity needed to maintain a competitive advantage. There are many shapes and sizes of VPN implementations. This chapter discussed many popular and emerging VPN technologies within the scope of the OSI model. At this point, you should be familiar with the various types of VPN technologies, where they sit in the OSI stack, and the benefits that each brings to the table:

  • Layer 2 VPDN technologies: L2F, L2TP, and PPTP

  • Layer 3 VPN technologies: MPLS, L2TPv3, and IPsec

  • Layer 4 VPN technologies: SSL and TLS

Enterprises are now deploying VPNs in almost every area of the network in order to fully harden their data communications infrastructure against malicious activity. The following are three popular areas in which an enterprise may choose to implement a VPN:

  • Corporate WANs A company's internal links can be compromised by inside attackers seeking to steal or manipulate data as it traverses the corporate intranet. Additionally, as the business landscape becomes even more competitive, organizations must increasingly rely on communications across untrusted, shared infrastructures to communicate. This particular type of growth becomes one of the main drivers behind the implementation of site-to-site VPNs in corporate enterprise networks.

  • Corporate extranets Now more than ever, organizations are leveraging the use of the Internet to collaborate with one another. Whether the scenario describes a global investment bank relying on timely and accurate news feeds from Reuters and Bloomberg for critical large-scale financial decisions, or a large regional hospital processing thousands of claims with a global health-insurance provider, the need for confidential, secure communications becomes critically important. As such, corporate extranets are another demand driver for site-to-site VPN implementations.

  • Remote access VPN implementations This chapter discussed examples of how providing a workforce with more flexibility throughout the day drives productivity, ultimately positively impacting an organization's bottom line. A Remote Access VPN can be used to enable such flexibility. Sales and marketing staff, frequently on the move, comprise one contingent of those that will heavily use an RAVPN implementation, which almost always traverses some form of untrusted, shared infrastructuresuch as a service provider network. RAVPN technologies have evolved from Layer 2 VPDN solutions to more robust and flexible Layer 3 IPsec and Layer 4 SSL and TLS solutions in order to deliver confidential, authentic exchange of data in these scenarios.

You have seen that VPN technologies are a critical component to Cisco's end-to-end security strategythe Cisco Security Wheel. Throughout the course of this book, you will explore the VPN platforms available to effectively implement specific types of VPN architectures. The book further explores specific design scenarios and case studies to effectively illustrate common design issues and how a network architect can remediate those issues.


Chapter 2. IPsec Fundamentals

Internet Protocol Security (IPsec), as defined in RFC 2401, provides a means by which to ensure the authenticity, integrity, and confidentiality of data at the network layer of the Open System Interconnection (OSI) stack. IPsec is a suite of protocols that define standards for four key elements needed in defining a comprehensively robust Virtual Private Network (VPN) enabler:

  • Security Protocols

  • Key Exchange Mechanisms

  • Algorithms Required for Encryption and Secure Key Exchange

  • SA Definitions and Maintenance

In this chapter, we will introduce the cryptographic components and concepts necessary to understand how IPsec delivers on promises of secure transmittal of data across untrusted media. In order to understand the encryption algorithms and security protocols used by IPsec, one must first understand how encrypted messages are formed. In this chapter, we will discuss the basic elements of encryption that will clarify the cryptographic mechanisms used within the IPsec protocol suite. Additionally, we will explore IPsec's establishment of secure data tunnels, IPsec VPNs, with other peers. IPsec employs the Internet Key Exchange (IKE) protocol to exchange keys. This chapter will cover the critical importance of IKE within the IPsec protocol suite and its role in establishing IPsec Security Associations (SAs).

Note

The IKE protocol is used within the Internet Security Association and Key Management Protocol (ISAKMP) framework. However, throughout the course of this text, especially when describing SA establishment, the terms IKE and ISAKMP will be used interchangeably.


Overview of Cryptographic Components

As we had discussed briefly while introducing the criteria for defining an effective VPN, data confidentiality, data authentication, data integrity, and data nonrepudiation must be maintained. These criteria also apply to the effectiveness of any encrypted communicationthe more of these criteria are met, the more secure and private the communication channel is deemed to be.

Cryptographic processes use three basic components to deliver upon these criteria for successa key, a cryptographic mathematical function (also called a cipher), and a message to be encrypted or decrypted. A one-thousand-foot view of the process is as follows: the message is fed into the cipher algorithm, which uses the key to transform the original message into a format that is undecipherable to anybody who does not possess the appropriate decryption key.

As depicted in Figure 2-1, the exchange between James and Charlie relies heavily on encryption and decryption keys. In any cryptographic operation, these appropriate keys must be obtained in order to encrypt and decrypt messages. In some cases, the encryption key and decryption key may be one and the same. In other cases, they may be intentionally different from one another (one used for encryption, the other used for decryption). We will now explore how these two different types of encryption (symmetric and asymmetric) provide for data confidentiality in VPN deployments.

Figure 2-1. EncryptionA One-Thousand-Foot View

[View full size image]

Asymmetric Encryption

In an asymmetric encryption scheme, each party derives a private and public key pair, as shown in the following text. As noted by the name, public keys can be exchanged securely with communications partners, while private keys must be kept secret.

In asymmetric cryptographic operations, private keys are generally used to decrypt data, while public keys are used to encrypt data. In the scenario depicted in Figure 2-2, James and Charlie will exchange public keys to encrypt traffic to one another. James will then use Charlie's public key to encrypt his message to Charlie, and Charlie must use his private key to decrypt the message. The same operation will transpire in the future when Charlie replies to JamesCharlie's reply will be encrypted with his James' public key, and James will have to use his private key to decrypt Charlie's reply. Thus the requirement for James and Charlie to exchange public keys before any encrypted communication can take place. Of critical importance is that these public keys be exchanged securely and only between the appropriate parties. As we will see in later sections, effective methods exist to guarantee the authenticity of key exchange across untrusted media.

Figure 2-2. Asymmetric, Public Cryptographic Setup and Key Exchange

After having exchanged public keys, James and Charlie should be able to send messages to one another confidentially, using that key to encrypt the message. Note that private keys are never exchanged across the shared media, which lessens the influence of compromised keys. As we will discuss later in this section, a compromised symmetric key (use decryption and encryption) increases the vulnerability of impersonation and hijacking attacks on the Virtual Private Network (VPN), as the compromised key is used for encryption and decryption of data. Asymmetric key encryption lessens this effect, as a compromised public key cannot be used to decrypt dataonly to encrypt it. Figure 2-3 depicts the series of exchanges that compose James' and Charlie's confidential conversation using asymmetric cryptography.

Figure 2-3. Exchanging Messages with Asymmetric Cryptography

[View full size image]

The following sequence of events describes the exchange between James and Charlie illustrated in Figure 2-3:

1. | James encrypts a message to Charlie with Charlie's public RSA key.
2. | Charlie receives the message from Step 1 and decrypts it with his private RSA key.
3. | Charlie crafts a response to James and encrypts it with James' public RSA key.
4. | James receives the message from Step 3, and decrypts it with his private RSA key.

The original message never crosses the shared media in cleartext. Confidentiality is maintained, in that intermediary parties that exist between Charlie and James are unable to view the original, unencrypted message contents as they do not possess the required private key for decryptiononly cipher text, or encrypted text is transmitted between James and Charlie.

When Charlie receives James' message, he will be able to decrypt the message with his private key and interpret the original message contents. Charlie is now able to read the original contents of James' message to him and crafts a reply. As James had done earlier to his message to Charlie, Charlie now encrypts his reply with James' public key and forwards the cipher text over to James. Again, only cipher text traverses the shared media. Due to the fact that Charlie has encrypted his response with James' public key, James can use his private key to decrypt and interpret Charlie's reply. Let's now have a look at the effect of a compromised public key in the exchange between James and Charlie in Figure 2-4.

Figure 2-4. An Attempt to Compromise an Asymmetric Key Cryptosystem

[View full size image]

The following sequence of events describes Figure 2-4:

1. | James attempts to exchange his public key with Charlie.
2. | Olivia intercepts James' public key.
3. | Charlie exchanges his public key with James.
4. | Olivia attempts to interpret data sent from James to Charlie, but is unable to. Olivia can encrypt messages to James only with his public keyshe cannot decrypt messages from him.

If a third party, Olivia in this case, were to intercept Charlie's public key, she would be able only to encrypt data toward James, but would be unable to decrypt messages from him. To successfully facilitate this attack, she would have to fool James into thinking that she was indeed Charlie, so that she could obtain James' public key, thereby adding another layer of complexity to the attack over an attack situation on a symmetric key cryptosystem. In this regard, Olivia is attempting to act as a man in the middle. This attack is described in detail later in this chapter in Figure 2-9.

Symmetric Encryption

Symmetric key encryption is a slightly simpler operation than asymmetric encryption, and, as such, is more suited to bulk cryptographic transmission. In a symmetric cryptographic operation, James and Charlie will share the same secret key. In Figure 2-5, James and Charlie have both been given the same symmetric (encryption and decryption) key and use it to exchange confidential messages.

Figure 2-5. Symmetric Key Encryption

[View full size image]

The following sequence of events describes the symmetric encryption operation illustrated in Figure 2-5:

1. | James crafts a message to be sent to Charlie. Note that, in this step, James and Charlie are preconfigured with a shared, symmetric, key used for both encryption and decryption.
2. | James encrypts the message crafted in Step 1 with his shared symmetric key and forwards the ciphered message to Charlie.
3. | Charlie decrypts the message received in Step 2 with his shared symmetric key, making the original cleartext message available for interpretation.

Unlike asymmetric encryption, the shared secret key used in symmetric encryption is used not only to encrypt data, but also to decrypt the data. James begins the exchange by using his shared, secret key to encrypt his message to Charlie.

Because the operation is considered to be symmetric, James and Charlie have identical keys for encryption and decryption. Now that Charlie has James' message, Charlie uses the secret key shared between James and Charlie to decrypt the message.

When Charlie decides to answer James' query, the operation would follow the same procedure. Specifically, Charlie would craft his reply to James and encrypt it with the shared secret key. Upon receipt of the message, James would decrypt the message with the same key that Charlie used to encrypt it.

Note

Transforms used in IPsec Security Associations, such as Data Encryption Standard (DES), 3DES, and AES, are symmetric encryption algorithms. As such, IPsec relies heavily on symmetric key encryption to deliver confidential exchange of data.

Let's return to Olivia's attempt to compromise the confidential communication between James and Charlie. This time, Olivia intercepts the symmetric key that James and Charlie share for both encrypting and decrypting data communications between them. In this case, Olivia does not need an additional key to talk with James and Charliethe symmetric key is sufficient to both encrypt and decrypt data to and from both James and Charlie. When comparing Figure 2-6 with Figure 2-4, the simplicity of Olivia's man-in-the-middle attack on James and Charlie's symmetrically encrypted conversation relative to their asymmetrically encrypted conversation can be observed.

Figure 2-6. An Attempt to Compromise a Symmetric Key Cryptosystem

[View full size image]

Unlike asymmetric cryptographic operations, symmetric key transforms are more susceptible to attack if a symmetric key becomes compromised. For this reason, symmetric keys are typically not exchanged over an untrusted medium. Instead, they are typically derived over a secured medium.

Note

As we will discuss later in this text, IPsec uses the Diffie-Hellman algorithm to derive shared secret keys for bulk data encryption with a symmetric key transform. Diffie-Hellman is facilitated over a trusted channel secured with IKE.

The following order of operation describes the effect of a compromised symmetric key illustrated in Figure 2-6.

1. | James and Charlie create and share symmetric transform keys over an untrusted medium.
2. | Olivia intercepts the symmetric key shared between James and Charlie in Step 1 above.
3. | Olivia can now encrypt and decrypt messages to and from James and Charlie. This enables her to eavesdrop on conversations between James and Charlie. She is also able to falsely impersonate James and Charlie and craft messages to and from both of them.

Message Authentication, Message Integrity, and Sender Nonrepudiation Mechanisms

IPsec incorporates several cryptographic operations to ensure message authenticity, data integrity, and sender nonrepudiation. In this section, we will describe the mechanics of these cryptographic operations, including message hashing, message digests, and Digital Signatures.

Hashing and Message Digests

Data integrity ensures that transmitted data has not been tampered with en route to its destination. Hashes can be deployed to ensure data integrity. A hash takes an input message of variable length and outputs fixed-length code. The fixed length code is then appended to the original message before transmission. A basic hashing function consists of an algorithm and a key that is known to both sender and receiver, as described in the scenario between James and Charlie illustrated in Figure 2-7.

Figure 2-7. Creating and Verifying a Message Digest

[View full size image]

Before sending his message to Charlie in Step 1 of Figure 2-7, James performs a mathematical operation, or hashing function, on the original message. The output of that mathematical operation is called a hash value, or message digest, which is then appended to the original message and sent to Charlie.

In Step 2 of Figure 2-7, Charlie then removes the hash value from the original message and runs the same hash operation on the original message received. Charlie then compares his hash value with the one that James had sent appended to the original message. If the two hash values match, then Charlie can be assured that the message's integrity has not been compromised. That is to say that James' message to Charlie has not been modified and has not been spoofed by a source other than James himself.

Although message digests provide data integrity, they do not provide message authenticity unless the original message is hashed with a secret key shared between the two endpoints. This operation is commonly used in routing protocol authentication and also in the creation of hashed message authentication codes (HMACs) used for bulk data encryption by a symmetric key transform defined an IPsec SA.

In order for a hash to effectively provide data integrity, the hash operation must have the following characteristics:

  • Identical input messages must consistently yield the same output.

  • The input message length can vary, but the length of the output of the hash operation must be of fixed length.

  • The output must be random, or give the appearance of randomness.

  • It must be irreversible, or one wayone should never be able to determine the original message by reversing the hash operation.

  • Each unique input message should yield a unique output value.

The most widely used hash algorithms are the Secure Hash Algorithm (SHA) and the Message Digest 5 algorithm (MD5). Both MD5 and SHA process input in 512-bit blocks, but the length of their output variesMD5 outputs a 128-bit message digest, while the message digest output of SHA is 160 bits. As such, SHA is considered a stronger hash, but requires more processing power than the MD5 hash algorithm.

Note

Although SHA-1 and MD5 are 160- and 128-bit computations, respectively, the length of the resulting hash is sometimes truncated to 96 bits in length in transmission.

Secure Cisco networks use hashing operations for a variety of things, including routing protocol authentication and in various applications of IPsec and IKE. Within the IPsec framework, hashing algorithms are used when appending message digests to the messages exchanged to generate shared secret keys during IKE, when collaborating with a certificate authority, when building Digital Signatures, and when computing a keyed message authentication check for shared secret-key encryption.

Digital Signatures

Data authentication refers to information originating from the original valid source. Authentication in simple hashes can be compromised by data replay attacks and man-in-the-middle attacks. Digital Signatures use a combination of hashes and asymmetric encryption in order to secure the integrity of the hash exchanged between two peers. Preserving data integrity ensures that a message has not been altered or compromised en route to its destination. A Digital Signature is an encrypted form of a hashed message. As such, a Digital Signature can be verified only by those parties containing the necessary public key that corresponds to the private key used to encrypt the hash. Therefore, if the Digital Signature is verified, its source is deemed to be authentic, as the public key would not decrypt a message digest value encrypted by a different private key. Consider again the exchange of a message between two routers, James and Charlie. A Digital Signature can be used to provide an additional level of authenticity over a standard hash. The first step that James takes to create the Digital Signature of his original message is derivation of a public and private key pair associated with the original message. Figure 2-8 illustrates the process of creating and validating a Digital Signature.

Figure 2-8. Generating and Verifying a Digital Signature

[View full size image]

The following order of events describes the exchange in Figure 2-8:

1. | James crafts a cleartext message, performing a hash with his public key that results in a message digest. James forwards his public key to Charlie to be used for decrypting Digital Signatures from James (as in Step 2 following).
2. | James then encrypts the message digest created in Step 1 with his private key. This results in a Digital Signature that is appended to the original cleartext message. The original message is sent in cleartext to Charlie with the appended Digital Signature.
3. | Charlie uses James' public key sent in Step 1 to decrypt the Digital Signature sent in Step 2.
4. | Charlie hashes the cleartext message sent in Step 2 with the public key sent in Step 1. If the resulting message digest matches the message digest resulting from the decryption process of Step 3, the Digital Signature is deemed to be valid.

Up until this point in the exchange, the process of creating a hash value and creating a Digital Signature has been identical, save one itemJames' creation of a public and private key pair. These keys encrypt (private key is used for encryption) and decrypt (public key is used for decryption) the hash value created by the hash operation performed on the original message.

Note

In our previous discussion of public key encryption, or asymmetric encryption, two parties have exchanged keys to encrypt data to one another (public keys), and retained the corresponding private keys to decrypt data from their peers. In certain circumstances, the reverse operation may existprivate keys are used for encryption, and public keys are used for decryption. Digital Signatures typically follow this behaviorprivate keys are used to encrypt, and public keys are used to decrypt, contrary to typical asymmetric key usage.

This form of public key encryption is known as asymmetric encryption, as one key, the private key, is used to encrypt the data, while the other key, the public key, is used to decrypt the data.

Once James has created a hash value of the original message, that message is encrypted with James' private key, resulting in the creation of a Digital Signature. This chain of events shows how a Digital Signature serves as an effective fingerprint of the original messageit is derived from the original message through a hash function and encrypted for data integrity and authenticity as James' public key is the only key that can be used to decrypt the hash value. James must therefore securely forward his public key to Charlie so that Charlie can decrypt the hash for verification.

When Charlie receives the original message, a Digital Signature, and public key from James, he must attempt to verify the authenticity and integrity of the message. Charlie's first task is the decryption of the Digital Signature that James had sent with James' public key. The output of this decryption process should be the message digest of the hash of James' original message.

After decrypting the Digital Signature, Charlie now has the original message digest of James' original message. Charlie can now hash James' original message and compare the resulting message digest to the newly decrypted message digest that was sent by James. If the two message digests match, the message is believed to be authentic, with preserved integrity.


Public Key Encryption Methods

In almost every form of commercially available cryptographic scheme, which would include all of the components used in IPsec, the cipher used is generally known. It is the key that is used within the cipher that makes the encryption harder to crack. Consider the asymmetric key encryption scheme used by James and Charlie. Charlie and James must have each other's public key to encrypt communications that are decipherable by the other party. Let's say that another party, Olivia in this case, decided to play a trick on James and Charlie by convincing them that she was Charlie and James, respectively. Figure 2-9 illustrates how a public key can be compromised by a user inserting themselves between two cryptographic endpoints.

Figure 2-9. Compromised Keys in an Asymmetric Exchange

[View full size image]

Charlie's keypair has been compromised. Olivia can now send messages to Charlie and decrypt messages from Charlie originally intended for James and vice versa. The type of attack that Olivia executes on James' and Charlie's conversation is typically referred to as a man-in-the-middle attack. The steps in Figure 2-9 are as follows:

1. | Olivia authenticates herself to Charlie as James and to James as Charlie. Charlie and James intend to exchange their public keys with one another. But, because Olivia has authenticated as James to Charlie and as Charlie to James, James and Charlie actually exchange public keys with Olivia.
2. | James encrypts a message to Charlie with Olivia's public key, thinking that he is using Charlie's public key, and transmits it to Olivia unknowingly.
3. | Olivia receives the message, decrypts it with her private key, and is now able to read the original content of James' transmission to Charlie.
4. | Olivia encrypts a message and manipulates the original content to suit her needs. She encrypts the message with Charlie's public key and forwards it on.
5. | Charles receives the message from Olivia, thinking it was from James. Charlie then uses his private key to decrypt the message and reads the altered message sent by Olivia in Step 3.

Apply this type of attack to an exchange of financial account information between large global financial organizations, the exchange of patient health care records between regional hospitals and their insurance providers, or a customer and retailer exchanging credit card information over the Internet, and it becomes apparent why it is absolutely critical that the keys used in the exchange of encrypted data be exchanged securely and privately.

ISAKMP employs several operations to protect the authenticity and integrity of cryptographic keys. There are generally three different methods for doing so, all of which will be discussed later in this chapterPreshared Authentication Keys, RSA Encrypted Nonces, and RSA Signatures. As we'll discuss at several points throughout this text, many of these methods are secured by the computational difficulty of factoring two large prime numbers. Let us begin our exploration of these techniques by discussing the RSA encryption algorithm.

RSA Public-Key Technologies

Ron Rivest, Adi Shamir, and Leonard Adleman developed the RSA encryption algorithm in 1977. To this day, RSA encryption has served as a critical authentication component in many large-scale commercial ISAKMP deployments. Two key cryptographic operations that leverage the RSA encryption algorithm are RSA encryption and RSA signatures. In this section, we will explore the operation of both RSA technologies within the context of the IPsec protocol suite.

RSA Encryption

RSA encryption uses an asymmetric cryptographic exchange to secure data. However, the strength of RSA encryption lies within the generation of the public and private key pair. Although the generation of RSA keypairs is somewhat expensive computationally relative to IKE preshare keys, RSA encryption is asymmetric, and therefore yields an added level of security in authentication over manually defined IKE preshared keys (see Figures 2-4 and 2-6 for the added value of asymmetric cryptography). Consider the exchange of information between James and Charlie in Figure 2-9. Figure 2-10 shows how the encryption and decryption processes work when using RSA encryption.

Figure 2-10. Encrypting Data with the RSA Encryption Algorithm

[View full size image]

The following sequence of events describes the generation of RSA keys and the methods used to encrypt data between two cryptographic endpoints using RSA encryption:

1.
James and Charlie generate parameters needed to establish cryptographic keys:

  • Prime Number #1 (P) = a large, randomly generated prime number.

  • Prime Number #2 (Q) = another large, randomly generated prime number.

  • Modulus (M) = the factor of two large, randomly generated prime numbers. Computed by the equation M = (P 1) x (Q 1).

  • Exponent (E) = E must be selected coprime to modulus M. It is a small number that shares a greatest common denominator with M of 1.

  • Decryption (Private) RSA Key (D) = (Y x [(P 1) x (Q 1)] + 1) / E; where Y is any number divisible by 1 that yields an integer value for D.

2.
James exchanges his public exponents with Charlie. In this situation, public exponents must be exchanged so that James' peers can encrypt data, and the private exponent must be kept secret so that only James can decrypt data that is being sent using his public exponent.

Note

Public exponents must be exchanged with parties deemed to be authentic. Otherwise, a vulnerability to man-in-the-middle attacks is exposed, as described in Figure 2-9. The use of a Public Key Infrastructure (PKI) provides a scalable solution to managing the risks of public key distribution.

3.
James uses Charlie's public exponent to encrypt his data, using the encryption function depicted below. Charlie then uses his private exponent to decrypt the communication as they receive it.

The encryption function in RSA encryption is [(PT)E]mod(M) where:

  • PT is the numerical representation of the plain text message.

  • E and M are components of the RSA public key generated above.

  • Mod is the modulus of two numbers.

  • The decryption function in RSA encryption is [(CT)D]mod(M), where:

  • CT is the numerical representation of the cipher text message.

  • D and M are the RSA private key that corresponds to the RSA private key mentioned previously.

  • Mod is the modulus of two numbers.

In the above example, small prime numbers were used for generating RSA keys. In reality, these numbers must be much larger, for the larger they are, the harder RSA encrypted messages are to crack. RSA derives its strength from the computational difficulty of factoring large numbers. As such, encryption mechanisms that effectively use the RSA algorithm use values for P and Q of at least 100 decimal values in length.

Note

Cisco manufactures crypto engines that can support key length (modulus) sizes of up to 2048 bits in length. As we've discussed, generation of RSA key pairs can be computationally expensive. The longer the key modulus selected when generating RSA keypairs, the longer it takes the processor to generate the keys.

RSA encryption is useful in certain site-to-site VPN topologies. However, as the number of crypto peers scales upwards, the maintenance of RSA keypairs can become cumbersome, both in terms of processor load on network devices and in terms of key maintenance and administration required. In order to solve these issues, RSA signatures can be deployed to increase the scalability of an RSA encryption environment and ease the administrative overhead required to maintain the RSA-encrypted environment without sacrificing the cryptographic strength delivered by deploying the RSA encryption algorithm.

RSA Signatures

IPsec crypto endpoints running Cisco IOS support authentication using RSA Signatures using X.509-based Certificates and Certificate authorities. This method of authentication, though more complicated to configure, offers a more scalable configuration alternative to RSA encryption and preshared keys.

Crypto endpoints using RSA signatures use X.509 certificates to authenticate and enroll with the CA. Using a central resource for authentication services, the Certificate Authority, simplifies maintenance on both crypto endpoints. This is particularly useful in large networks, as administrators now configure each crypto endpoint to use the CA for authentication, instead of manually configuring preshared keys for each peer. Cisco IOS supports RSA signatures when negotiating ISAKMP SAs. The operation and configuration of crypto endpoints using RSA signatures is covered in greater detail in Chapter 11, "Public Key Infrastructure and IPsec VPNs."

Diffie-Hellman Key Exchange

Network infrastructures are increasingly relied on for transferring bulk amounts of data, which lends itself more to a symmetric crypto solution. Given this trend, many network architects turn to the Diffie-Hellman algorithm to securely derive shared keys across an untrusted network infrastructure.

Note

Diffie-Hellman is a core component of the IKE protocol. Aspects of the Diffie-Hellman algorithm will be covered in additional detail in the IKE and perfect forward secrecy (PFS) section of this chapter.

Diffie-Hellman key exchange was designed for crypto endpoints to derive shared secret session keys across unsecured media. The shared secret keys are negotiated between crypto endpoints dynamically. As such, administrators need to specify only the prime modulus (MODP) size for use in the Diffie-Hellman exchange. IKE uses Diffie-Hellman keys to encrypt the ISAKMP SA over which IPsec SAs are established. Likewise, Diffie-Hellman is used to generate keys to be used in the ciphers specified in IPsec transforms. These transforms, when used in conjunction with Diffie-Hellman keys, will be used by IPsec to encrypt and decrypt data as it passes through the VPN tunnel.


The IP Security Protocol (IPsec)

IPsec provides us with a framework by which to secure data communications at the network layer of the OSI model, or, more specifically, to secure IP communications. In order to do so, the IPsec standard incorporates a number of protocols into the IPsec protocol suite. As such, IPsec is not defined as a single protocol, but is instead a collection of protocols, each focusing on particular elements of the IPsec missionto secure IP communications over untrusted networks. We've discussed in detail the operation of many different cryptographic components designed to deliver services such as data authentication, data confidentiality, data integrity, and data nonrepudiation to IP communications. Within the IPsec protocol, there are protocols that provide a means by which to ensure all of these services in a VPN implementation. This assurance is the reason that IPsec is widely considered to be one of the most comprehensively effective VPN choices available in enterprise and commercial markets today. Examples of protocols included in the IPsec protocol suite that are focused on delivering message authenticity, data integrity, data confidentiality, and sender nonrepudiation include IKE for authenticity and the Encapsulating Security Payload for confidentiality. We will explore these protocols and others as we present a comprehensive overview of the mechanics of IPsec.

IPsec VPNs encrypt data at the Layer-3 IP packet layer, offering a comprehensively secure VPN solution through providing data authentication, antireplay protection, data confidentiality, and data integrity protection. As such, IPsec is one of the most widespread VPN technologies in today's enterprise, service provider, and government networks. IPsec in tunnel mode supports the rewriting of type-of-service (ToS) bits into an IP header placed directly outside of the IPsec header, and, as such, supports encrypted data payloads while preserving the operation of quality of service (QoS) in a IP network. IPsec is a standards-based protocol, and can therefore operate seamlessly across a network built with technologies from multiple vendors. As we'll see moving forward, IPsec is supported within Cisco IOS on a wide array of different routers, switches, VPN concentrators, and VPN clients. Likewise, Cisco offers a variety of different hardware-based VPN acceleration options for optimal VPN performance within a network. IPsec will serve as the primary VPN discussion point for the duration of this book. Moving forward, this chapter uses the approach in Figure 2-11 to lay out the fundamentals of IPsec communications.

Figure 2-11. An Overview of IPsec Mechanics

[View full size image]

IPsec Modes

IPsec uses two different modes to establish a secure communication channel between network nodesTransport Mode and Tunnel Mode. The secure communications channel that IPsec provides is commonly referred to as an IPsec SA. IPsec and IKE SAs are discussed in greater detail later in this chapter.

Note

IPsec security associations are unidirectional. As such, when two cryptographic endpoints use IPsec to create a secure communications channel between each other, there are two IPsec SAs involvedone in each direction.

IPsec modes have different applications in different architectures. This is due largely to the fact that tunnel and transport modes protect different parts of the IP packet, yielding different degrees of confidentiality. The key choice in selection of an IPsec operational mode is determination of what parts of IP headers and payloads are to be kept confidential.

Transport Mode

RFC 2401 defines a transport mode SA as one that connects two IPsec hosts together. In IPsec transport mode SAs using Encapsulating Security Payload (ESP), only upper-layer protocols are kept confidential. This is because the ESP-encapsulated payload starts after the IP header and options. Figure 2-12 illustrates the resulting format of an ESP-encapsulated IP packet using transport mode.

Figure 2-12. An ESP-Encapsulated IP Packet Using Transport Mode

[View full size image]

Tunnel mode places the ESP header before the IP header, offering confidentiality for IP-encapsulated payload, IP header, and options. So why would one ever choose transport mode? In some instances, features within the IP header might be better off left in the clear. Take the example of a network in which a conversation-based QoS technique, such as Weighted Fair Queuing, is critically required. In an IPsec SA using tunnel mode, this information would typically be located inside the ESP-protected boundary. As such, network devices attempting to make queuing decisions will not be able to appropriately hash the data into the correct conversation. Figure 2-13 illustrates this potential interoperability consideration.

Figure 2-13. Flow-Based QoS Inconsistency in Tunnel Mode IPsec

[View full size image]

Tip

Using the QoS preclassify feature in IOS 12.1T or later IOS can preserve the operation of Weighted Fair Queuing on the IPsec endpoint.

If the SA created in Figure 12-13 between James and Charlie were transport mode, the original source and destination addresses would be visible. If inner IP header information is not deemed to be confidential information by security administrators, then transport mode can be employed to maintain per-conversation QoS consistency. Note that the scenario above describes one such inconsistency between IPsec and QoS techniques in IP networks, but there are others. We will discuss challenges of designing QoS into an IPsec VPN in greater detail in Chapter 4, "Common IPsec VPN Issues."

Tunnel Mode

Tunnel mode IPsec SAs have different protection boundaries from transport mode SAs. In a tunnel mode SA, not only are upper-layer protocols afforded confidentiality services, but the IP header information is also protected. IP communications are maintained within the IPsec tunnel by creating an "outer" IP header that is prepended to the outside of the ESP-protected boundary. Figure 2-14 illustrates the format of an ESP-encapsulated IP packet in tunnel mode.

Figure 2-14. An ESP-Encapsulated IP Packet Using Tunnel Mode

[View full size image]

Tunnel mode defines a broader protective boundary at the packet layer, and hence provides a greater scope of confidentiality. In doing so, tunnel mode hides useful attributes of the IP header from intermediary network devices between the two tunnel endpoints. Measures can be taken to carry forward useful information from the original IP header into the outer IP header. However, when doing so, there is a corresponding decrease in the overall level of confidentiality of the packet itself. Per RFC 2401, secure IPsec gateways commonly use tunnel mode when establishing an IPsec SA with another IPsec host or IPsec secure gateway. We will explore many design concepts pertaining to the appropriateness of IPsec tunnel mode and transport mode in subsequent chapters.

IPsec Transforms

As discussed above, IPsec delivers data confidentiality services by executing a transform on plain text data. Common ciphers used in the IPsec transforms are DES, 3DES, and AES. All of these transforms conform to specifications for IPsec's symmetric-key cryptographic requirements per RFC 2401. Another item that all of these transforms have in common is that they can all be deployed in using ESP, authentication headers (AH), or a combination of the two.

ESP

ESP provides a combination of security services for IPsec-processed IP packets. Examples of the services offered by ESP include data confidentiality, data origin authentication, data integrity assurance mechanisms, and data flow confidentiality. The services offered by ESP depend on which services are negotiated during IPsec security association establishment. As such, any service, or combination of services, can be selected by the administrator before SA negotiation takes place. ESP can be deployed in transport or tunnel mode. Additionally, it can be deployed alone, or in conjunction with authentication headers.

EncryptionMessage and Traffic-Flow Confidentiality

ESP provides confidentiality services by allowing the use of popular symmetric key encryption ciphers such as DES, 3DES, and AES. Assuming that a user selects DES as their transform cipher, the encrypting device would take input data at 64-bit blocks and encrypt them using a key 56 bits in length. ESP would then "wrap," or encapsulate, the ciphered payload with an ESP header (IP protocol number 50). The 64-bit blocks of the original message can be chained together using cipher block chaining (CBC) or CFB, yielding greater antireplay and data integrity protection.

The format of an ESP-processed IP packet varies based on which IPsec transform mode is selected. In transport mode, the header is placed before the ciphered payload, and after the IP header. As such, ESP in transport mode offers only confidentiality protection for Layer 47 protocol informationit is effective at providing confidentiality to the IP-encapsulated payload of the original message. To increase the protective boundary of ESP on a per-packet basis, administrators can select tunnel mode when defining their IPsec transforms. ESP in tunnel mode includes the original IP header in the ciphered payload. The ESP header is placed before the ciphered inner IP header, and after the cleartext outer IP header. As such, IPsec in tunnel mode protects the source and destination of the IP traffic flows themselves, in addition to Layer 47 protocol information protected in transport mode.

Note

3DES and AES are considered to be stronger encryption ciphers than DES, as they use longer encryption keys (128-bit key for 3DES and 256-bit key for AES). However, they are also more computationally expensive, and administrators should therefore carefully balance the need for confidentiality with the cost of their VPN infrastructure.

Each ESP packet is marked with a security parameter index (SPI). The SPI enables encrypting and decrypting devices to understand which SA the ESP packet belongs to. SPIs are a 32-bit arbitrarily derived by the destination IPsec peer during IKE. Using SPIs to identify the packet's appropriate SA is critical, as each SA may be processed under a variety of different parameters, such as selected encryption transforms and Diffie-Hellman keys. In addition to the SPI, a sequence number is created for each ESP packet. Sequence numbers increase incrementally, per packet, offering built-in antireplay protection for ESP-processed traffic in both tunnel (Figure 2-14) and transport mode (Figure 2-12).

Data Authentication and Integrity

ESP defines a built-in authentication header, in the form of a Keyed-HMAC. This HMAC is inserted in to the ESP header to provide data integrity and authentication services to the ESP-processed traffic. In the context of IPsec, an HMAC would be specified as part of the transform selected. IPsec provides us with all of the ingredients necessary for building an HMAC, such as a shared secret key (typically derived through Diffie-Hellman exchange), a hash function (IPsec RFC accepts MD 5 and SHA-1), and fixed message input.

Note

Message input for creating an HMAC, in this case, is the ciphered format of the original message, as ESP authentication always occurs after encryption.

Warning

MD 5 HMACs, though supported, are relatively vulnerable and prone to a higher likelihood of collisions. Cisco recommends the use of SHA-1 HMACs instead of MD 5 HMAC authentication whenever possible.

The following sequence of operations is executed when dissecting a cleartext message into data blocks for symmetric encryption during ESP encapsulation and then creating and appending HMACs to each block for increased message authenticity.

1. | Message is broken in to 512-bit blocks.
2. | Shared secret key is x-or'd with specified array to create "K1."
3. | (First Message Block + K1) is hashed with a specified hash function (such as MD 5 or SHA-1) to create "Hash1."
4. | Shared secret key is x-or'd again with another specified array to create "K2."
5. | (Hash1 + K2) is hashed with a specified hash function to create "Hash2."
6. | Shared secret key is x-or'd again with another specified array to create "Kn."
7. | (Hashn + Kn) is hashed with a specified hash function to create "Hash(n+1)."

Note

Cisco VPN devices enable network administrators to specify authentication header options within ESP transforms using MD 5, SHA, or null (no authentication) hash functions.

As we've discussed before, symmetric key algorithms used in ESP can leverage mechanisms such as CBC to securely chain ESP-processed packets together. CBC leverages ensure that repetitive plain text input does not yield identical cipher text within the same sequential block. This is accomplished by including a feedback step that chains blocks together in a sequence. The feedback for the first block in the sequence is referred to as the Initialization Vector (IV), and is derived randomly. Symmetric key transforms using CBC protect data from the malicious insertion of data between chained blocks and from the malicious derivation of plain text input into a non-CBC chained cipher text stream.

AH

When confidentiality is not required, administrators can choose to deploy IPsec with AH, instead of with ESP. IPsec AH was created with the intention of providing data authenticity and integrity services to as much of the IP packet as possible. IPsec AH yields data authenticity, antireplay, and data integrity services by appending an additional field, called the authentication header, protecting the data payload and parts of the original IP header. Unlike ESP, however, IPsec AH does not provide data confidentiality. Because AH authenticates parts of the IP header, AH protects both upper- and lower-layer information within the IP header, while ESP protects only upper-layer protocols in transport mode. Figure 2-15 illustrates the format of an IP packet encapsulated with Authentication Headers using transport mode.

Figure 2-15. IPsec Authentication Headers in Transport Mode

Like ESP, AH can be deployed in transport mode and in tunnel mode. In tunnel mode, AH copies parts of the inner IP header that are used to create a new, outer IP header. AH in tunnel mode provides data authenticity and integrity to all of the original IP header and payload elements, and also to parts of the new outer IP header. Figure 2-16 illustrates the format of an IP packet encapsulated with Authentication Headers in tunnel mode.

Figure 2-16. IPsec Authentication Headers in Tunnel Mode

[View full size image]

Like ESP encapsulation, AH encapsulation also employs SPIs so that the appropriate SA can be located for a given IP packet.

IP Payload Compression Protocol (IPPCP) and LZS

When deploying confidentiality services using IPsec, encrypting the IP payloads renders many lower-layer protocol compression mechanisms, such as PPP Compression Control Protocol, ineffective. IPComp provides a framework for compressing IP packets in VPN environments that use encryption for confidentiality purposes. IPPCP compresses the IP datagram in full, including IP header. In this process, an IPPCP header is inserted immediately before this new IPPCP-compressed payload. Figure 2-17 illustrates the resulting format of an IPPCP-compressed IP packet.

Figure 2-17. Compression Results of an IP Packet Using IPPCP

IPComp is a nonlossy compression protocol, meaning that the decompression of each individual packet represents the original unencrypted packet. As such, IPComp is also considered to be statelessthe decompression and compression of a given packet does not depend on any other packet being processed.

Lempel Ziv Stac (LZS) is a very efficient compression algorithm that is being used in conjunction with IPComp in many VPN operations. LZS is capable of compression strings as short as two octets in length. In order to effectively support compression in IPsec environments that use encryption for confidentiality, compression of the data payload must occur before the packet is compressed.

IPComp requires the negotiation of an IPComp Association (IPCA) between a pair of compressing and decompressing nodes. Components that the two nodes must negotiate when building an IPCA are:

  • Compression Parameter Index

  • Compression Algorithm Selected

  • Parameters Required by the Selected Compression Algorithm

One key element of IPComp and LZS is that IPCAs can be negotiated using ISAKMP. As such, not only do IPComp and LZS provide an efficient mechanism for compressing encrypted IP packets, but it also cleanly and securely integrates into IPsec negotiation using ISAKMP and IKE.

IPsec SA

When two nodes decide to establish IPsec connectivity to one another, they must agree on certain parameters in order for the IPsec tunnel to be established and function properly. IPsec and ISAKMP both employ a SA to accomplish this. IPsec SAs negotiate a number of security parameters necessary to secure the IPsec tunnel, and for the two IPsec peers to maintain the IPsec tunnel effectively:

  • Mode The IPsec mode used for ESP and AH packet transformation. This will be either transport or tunnel, as described in preceding text.

  • Transform The IPsec encapsulation protocol and cipher used to transform the cleartext packets. This will include specification of either ESP, AH, or a combination of the two. The transform will also include the cipher, a symmetric key encryption mechanism deployed as part of the transform. This will, in most cases, be DES, 3DES, or AES, based on the strength of keys required.

  • Peer Specifies the peer with which to negotiate IPsec SAs. The IPsec peer is defined as the destination on which the IPsec tunnel is to be terminated.

    Note

    As an alternative to specifying peers for every tunnel endpoint, IPsec can dynamically establish peers and discover tunnel endpoints. This can be achieved by deploying dynamic crypto maps and tunnel endpoint discovery (TED). Dynamic crypto maps and TED are discussed in greater detail in Chapter 12, "Solutions for Handling Dynamically Addressed Peers."

  • Matched Traffic IPsec peers must be configured to encrypt and decrypt sets of the same data; otherwise, the endpoints of the IPsec tunnel will fail to negotiate an IPsec SA. If James specifies encrypted data that is outside of Charlie's data set to be decrypted from James, then the IPsec will reject the SA establishment. If James specifies encrypted data that matches Charlie's set of decrypted data, then the IPsec will accept the SA.

    Figure 2-18 illustrates a scenario in which IPsec SA negotiation fails due to a traffic set mismatch defined in the cryptographic endpoint's crypto ACLs.

    Figure 2-18. IPsec Traffic Set Mismatch and SA Negotiation

    [View full size image]

  • Path MTU IPsec tunnel endpoints must agree on, and guarantee, the MTU of the path between the two endpoints.

    Warning

    When an IPsec VPN endpoint attempts to decrypt traffic that has been fragmented after it was encrypted, it will commonly perform the decrypt action in the process switching path. In order to guarantee optimal performance of an IPsec VPN, it is critical to ensure that all packets are fragmented prior to being encrypted. As we'll discuss later in Chapter 4, this can be achieved through the proper use of tunnel path maximum transmission path (MTU) Discovery on Cisco IPsec VPN platforms.

  • SPI the IPsec SPI is a unique 32-bit value in the IPsec-transformed packet that identifies the SA that the packet belongs to. Consider the common topology of a hub-and-spoke enterprise network in which the hub router requires the maintenance of many IPsec SAs in its SA database (SADB). The hub marks IPsec packets with the appropriate SPI before sending its IPsec packets to its spokes. More importantly, the hub receives IPsec traffic from all of its spokes on many different SAs. The IPsec hub uses the SPI to determine which IPsec SA the traffic belongs to, and subsequently which security parameters to use to process the packet.

Figure 2-19 illustrates the use of SPIs in a standard IPsec VPN hub-and-spoke topology.

Figure 2-19. SPI Usage in Hub-and-Spoke IPsec VPN Deployment

[View full size image]

IPsec SAs are unidirectionalin one direction only. As such, an IPsec tunnel must establish at least two SAsone from source to destination and one from destination to source.

Note

IPsec requires the negotiation of a unique SA for each direction of the IPsec tunnel and for each protocol used (AH, ESP, or combination thereof).

Within the IPsec protocol suite, there is another, different, type of SA that must be negotiated before an IPsec SA can be negotiatedthe IKE SA. When dynamic keying is used, IKE SAs are negotiated in order to establish a secure channel over which to negotiate security parameters needed to form an IPsec SA. Figure 2-20 outlines the necessary steps that two nodes must follow when building IKE and IPsec SAs. Figure 2-20 illustrates the basic process of negotiating IKE (Phase 1) and IPsec (Phase 2) SAs.

Figure 2-20. IKE and IPsec SA Negotiation

[View full size image]

The following sequence of events describes the negotiation if IKE and IPsec SAs relate to the illustration provided in Figure 2-20:

1. | James receives a packet that meets the criteria for encryption, triggering the IKE SA negotiation.
2. | The two routers, James and Charlie, authenticate with each other by exchanging Manually Defined Preshared keys, RSA Encrypted Nonces (public only), or CA-signed RSA Certificates. An IKE SA is formed between the routers.
3. | Once the IKE session is active, the routers can use this secure channel to negotiate the IPsec SAs. This involves agreeing on an encryption algorithm (e.g., 3DES) and an authentication algorithm (e.g., SHA), and instantiating another cycle of Diffie-Hellman to establish a shared session key. As a part of the negotiation, the two peers will assign a unique SPI that will identify the encrypted packets in each established SA. This SPI number will be included in the IPsec encapsulation of every encrypted packet.
4. | The cleartext packets can now be encrypted using the agreed symmetric key transfer negotiated in Step 3; James encrypts the subsequent traffic from Workstation A accordingly and forwards to Charlie.
5. | Charlie, on receiving the packet, looks up the SPI to find out how to decrypt the packet. The encrypted payload is decrypted. Charlie uses the inner IP header to forward the unencrypted IP packet to its final destination.

For subsequent packets, the process starts at Step 4, because the SAs have been established. After a defined interval (or data volume), the SAs will time out, and the next packet after this will trigger the SA establishment process again.

IPsec Configuration Elements

There are several basic tasks that must typically be addressed when implementing IPsec. In this section, we will explore basic tasks common to most of the fundamental IPsec VPN implementations, including the creation of an IPsec transform set and the successful configuration of an IPsec crypto map.

Creating an IPsec Transform

In order to implement an IPsec VPN, the administrator must first make a series of decisions that will eventually result in the creation of the IPsec transform. The IPsec transform defines a series of parameters that will be used in transforming the packet from its cleartext input form to the cipher text output. Figure 2-21 illustrates the IPsec transform creation decision tree.

Figure 2-21. IPsec Transform Creation Decision Tree

[View full size image]

The following list and examples use Figure 2-21 to illustrate the creation of a transform set within IOS:

1.
An IPsec transform set defines the IPsec protocol to be used. This could be ESP, AH, or a combination of the two. In Example 2-1, James selects ESP and AH as his IPsec protocols.

Example 2-1. IPsec Protocol Definition and Availability

James#
James#configure terminal
*Mar  6 04:11:38.663: %SYS-5-CONFIG_I: Configured from console by console
Enter configuration commands, one per line. End with CNTL/Z.
James(config)#crypto IPsec transform-set IPSECVPN-1 ?
  ah-md5-hmac   AH-HMAC-MD5 transform
  ah-sha-hmac   AH-HMAC-SHA transform
  comp-lzs      IP Compression using the LZS compression algorithm
  esp-3des      ESP transform using 3DES(EDE) cipher (168 bits)
  esp-aes       ESP transform using AES cipher
  esp-des       ESP transform using DES cipher (56 bits)
  esp-md5-hmac  ESP transform using HMAC-MD5 auth
  esp-null      ESP transform w/o cipher
  esp-sha-hmac  ESP transform using HMAC-SHA auth

James(config)#crypto IPsec transform-set IPSECVPN-1 esp-des ah-sha-hmac
James(config)#end
James(config)#

2.
Also specified as part the IPsec transform set is the mode of the IPsec protocol. This could be either tunnel or transport mode. As discussed previously, different modes alter the packet in different waysspecifically, as it pertains to header location and the scope of the ESP or AH protection boundary. Example 2-2 illustrates the configuration of the mode that IPsec is to operate in.

Example 2-2. IPsec Protocol Mode Definition

James#
James#configure terminal
*Mar  6 04:11:38.663: %SYS-5-CONFIG_I: Configured from console by console
Enter configuration commands, one per line.  End with CNTL/Z.
James(config)#crypto IPsec transform-set IPSECVPN-1 esp-des ah-sha-hmac
James(cfg-crypto-trans)#mode ?
  transport  transport (payload encapsulation) mode
  tunnel     tunnel (datagram encapsulation) mode

James(cfg-crypto-trans)#mode tunnel
James(cfg-crypto-trans)#end
James#

3.
The symmetric key encryption cipher to be used for the IPsec SA is defined within the transform set. This could be DES, 3DES, or AES in commercial IPsec implementations, the selection of which depends on the strength of keys required in the transform cipher. In Examples 2-1 and 2-2, James has selected DES as the cipher to be used on the ESP-encapsulated data.

4.
An authentication hash operations for HMAC creation can optionally be specified within the transform set. This could be MD 5 or SHA-1. Alternately, the administrator could select not to include HMACs in the transformed packet by not selecting a hash operation in the transform set. In Examples 2-1 and 2-2, James opts to use HMACs for authentication in AH, but not in ESP. He uses the MD 5 algorithm to generate the HMAC.

As one may have inferred, not all of the above parameters must be selected. For example, one can choose not to include authentication headers in a transformed payload and only select ESP. Likewise, no authentication method can be selected when defining transforms. As such, it helps to think of transform creation as a series of sequential decisions as depicted by the flowchart in Figure 2-21.

Note

In Figure 2-21, the path that James had chosen to select his transform in Examples 2-1 and 2-2 is noted with shading.

As we'll see in later sections of this book, Charlie must be configured with a transform set that matches James' for the IPsec tunnel to negotiate properly. The transform set defines a variety of security parameters that will be negotiated over IKE when IPsec SAs are formed.

Crypto Map Configuration

Transform processes are performed at the interface level, and are therefore not activated until they are bound to an interface, or group of interfaces, using a crypto map. In IOS, crypto maps are used for a variety of different configuration items that are discussed in later sections of this chapter, including PFS, TED, x-Auth, and other options. At a minimum, a crypto map must be configured with three items before it is activated by IOS:

  • An existing crypto ACL to define traffic to be transformed.

  • An existing IPsec transform set to use when transforming packets that are inbound to the IPsec engine.

  • A peer that defines the IPsec tunnel endpoint. The defined peer is necessary for the IPsec SA to be established with the correct endpoint.

Consider Charlie's configuration of a crypto map when setting up an IPsec tunnel to James in Figure 2-20. It is assumed that Charlie has configured a transform set named "IPSECVPN-1" that matches the one that James had configured in Examples 2-1 and 2-2. Charlie matches any SMTP traffic destined James 20.0.0.0/8 network by referencing ACL 101 in his crypto map. Last, Charlie defines James' serial interface IP address as the IPsec tunnel endpoint so that IPsec understands which destination the Charlie's IPsec SA to James (rememberIPsec builds two unidirectional SAs) should reference. Example 2-3 illustrates Charlie's configuration of the three minimal objectives to establish his crypto map and the binding of the crypto map to his serial interface.

Charlie configures a crypto map to communicate with James via IPsec. To achieve this, Charlie configures a crypto map named "IPSECMAP-1," as illustrated in line 5 of Example 2-3. He then selects ISAKMP over manual keying, allowing Charlie and James to dynamically establish a secure channel over which to negotiate IPsec SAs. When Charlie builds his crypto map, IOS warns that an ACL, peer, and transform must be configured for the crypto map to be activated. Charlie references access-list 101 as traffic to be processed by IPsec in this crypto map (Example 2-3, line 8). Charlie selects the IP address of James' serial interface as the IPsec tunnel endpoint to be referenced in the IPsec SA (Example 2-3, line 9). Transform set "IPSECVPN-1" is then selected as the transform to be executed on traffic matching ACL 101, as illustrated in Example 2-3, lines 8 and 11, respectively. When Charlie wants to encrypt e-mail traffic (SMTP) destined to James (hosts on 20.0.0.0/8), he sets up ACL 101 to reference SMTP traffic destined to that subnet and tells IPsec to use ACL 101 when deciding which traffic to process in IPsec (see above crypto map entry). Finally, Charlie binds the crypto map to his egress interface toward James, the intended IPsec tunnel endpoint (Example 3-1, line 15).

To communicate with Charlie using IPsec, James first configures a crypto map named "IPSECMAP-1." He selects ISAKMP over manual keying, allowing Charlie and James to dynamically establish a secure channel over which to negotiate IPsec SAs. When James builds his crypto map, IOS warns that an ACL, peer, and transform must be configured for the crypto map to be activated. James references access-list 101 as traffic to be processed by IPsec in this crypto map, after which he selects the IP address of Charlie's serial interface as the IPsec tunnel endpoint to be referenced in the IPsec SA.

The transform set "IPSECVPN-1" is then referenced as the transform to be executed on traffic matching ACL 101 (Example 2-3, lines 25 and 27, respectively). When James wants to encrypt e-mail traffic (SMTP) destined to Charlie (hosts on 30.0.0.0/8), he sets up ACL 101 to reference SMTP traffic destined to that subnet and tells IPsec to use ACL 101 when deciding which traffic to process in IPsec (Example 2-3, line 29). James then binds the crypto map to his egress interface toward Charlie, the intended IPsec tunnel endpoint (Example 2-3, line 31).

Example 2-3. Minimum IOS Configuration Objectives for a Crypto Map

Charlie#
Charlie#configure terminal
*Mar  6 04:11:38.663: %SYS-5-CONFIG_I: Configured from console by console
Enter configuration commands, one per line. End with CNTL/Z.
Charlie(config)# crypto map IPSECMAP-1 10 IPsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
          and a valid access list have been configured.
Charlie(config-crypto-map)#match address 101
Charlie(config-crypto-map)#set peer 10.1.1.1
Charlie(config-crypto-map)#set transform IPSECVPN-1
Charlie(config-crypto-map)#exit
Charlie(config)#access-list 101 permit tcp 30.0.0.0 0.255.255.255 20.0.0.0 0.255.255.255
 eq smtp
Charlie(config)#
Charlie(config)#interface serial2/0
Charlie(config-if)#crypt map IPSECMAP-1
Charlie(config-if)#end
Charlie#

James#
James#configure terminal
*Mar 6 04:11:38.663: %SYS-5-CONFIG_I: Configured from console by console
Enter configuration commands, one per line. End with CNTL/Z.
James(config)#crypto map IPSECMAP-1 10 IPsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
          and a valid access list have been configured.
Charlie(config-crypto-map)#match address 101
James(config-crypto-map)#set peer 10.1.1.2
James(config-crypto-map)#set transform IPSECVPN-1
James(config-crypto-map)#exit
James(config)#access-list 101 permit tcp 20.0.0.0 0.255.255.255 30.0.0.0 0.255.255.255 eq
 smtp
James(config)#interface serial2/0
James(config-if)#crypt map IPSECMAP-1
James(config-if)#end
James#

Manual Keying

The above example relies on IKE/ISAKMP to establish a secure channel over which to exchange security parameters when building IPsec SAs. One of the parameters exchanged over IKE is the shared secret key that will be used in IPsec transforms. In instances in which IKE is unavailable, manual keying can be used. Such instances would include the creation of an IPsec tunnel to another vendor endpoint that does not support IKE but does support IPsec.

Note

All Cisco IOS and Cisco VPN appliances support IKE and ISAKMP protocols.

Using manual keys does not scale very well in large networks due to the exponential increase in administrative overhead with the addition of each IPsec tunnel. Likewise, in manual keying, keys must be refreshed manually, unlike dynamically derived Diffie-Hellman keys using PFS.

Note

PFS is a means by which to improve the freshness of IPsec shared secret keys generated using Diffie-Hellman. PFS is discussed in greater detail later in this chapter.

Most important, many hardware-based VPN accelerators do not support the use of manual keying. Therefore, network administrators should carefully balance the need for IPsec performance against costs of upgrading tunnel endpoints and modifying configurations to support IKE. Examples 2-4 and 2-5 illustrate configuration objectives required to create manual keys between James and Charlie.

Example 2-4. IPsec Manual Keying ConfigurationJames

James#
James#configure terminal
*Mar 6 04:11:38.663: %SYS-5-CONFIG_I: Configured from console by console
Enter configuration commands, one per line. End with CNTL/Z.
James(config)#
James(config)#crypto IPsec transform-set IPSECVPN-2 esp-des
James(cfg-crypto-trans)#mode tunnel
James(config)#crypto map IPSECMAP-2 10 IPsec-manual
James(config-crypto-map)#set peer 10.1.1.2
James(config-crypto-map)#set session-key inbound esp 1001 cipher 1234abcd1234abcd
  authenticator 01
James(config-crypto-map)#set session-key outbound esp 1000 cipher abcd1234abcd1234
  authenticator 01
James(config-crypto-map)#set transform-set IPSECVPN-2
James(config-crypto-map)#match address 101
James(config-crypto-map)#exit
James(config)#access-list 101 permit tcp 20.0.0.0 0.255.255.255 30.0.0.0 0.255.255.255 eq
 smtp
James(config)#interface serial2/0
James(config-if)#crypto map IPSECMAP-2
James(config-if)#end
James#

Once James applies the crypto map to his interface, the SA is established. In this configuration, he does not need to exchange information via IKE, as the session-keys are manually established. Example 2-5 shows the IPsec SA establishment debugging output from James' application of his IPsec policy attachment to his outbound interface.

Example 2-5. James' IPsec SA Establishment Process

James#debug crypto IPsec
*Mar  5 20:27:19.317: IPSEC(sa_request): ,
    (key eng. msg.) OUTBOUND local= 10.1.1.1, remote= 10.1.1.2,
    local_proxy= 10.1.1.1/255.255.255.255/47/0 (type=1),
    remote_proxy= 10.1.1.2/255.255.255.255/47/0 (type=1),
    protocol= ESP, transform= esp-des (Tunnel),
    lifedur= 3600s and 4608000kb,
    spi= 0x917457B8(2440320952), conn_id= 0, keysize= 0, flags= 0x400A
*Mar  5 20:27:19.317: IPsec: Flow_switching Allocated flow for flow_id 134217749
*Mar  5 20:27:19.317: IPsec: Flow_switching Allocated flow for flow_id 134217750
*Mar  5 20:27:19.317: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
*Mar  5 20:27:19.317: IPSEC(key_engine): got a queue event with 2 kei messages
*Mar  5 20:27:19.317: IPSEC(initialize_sas): ,
 (key eng. msg.) OUTBOUND local= 10.1.1.1, remote= 10.1.1.2,
    local_proxy= 10.1.1.1/255.255.255.255/47/0 (type=1),
    remote_proxy= 10.1.1.2/255.255.255.255/47/0 (type=1),
    protocol= ESP, transform= esp-des (Tunnel),
    lifedur= 3600s and 4608000kb,
    spi= 0x3E8(1000), conn_id= 134219728, keysize= 0, flags= 0xA
*Mar  5 20:27:19.321: IPSEC(initialize_sas): ,
 (key eng. msg.) INBOUND local= 10.1.1.1, remote= 10.1.1.2,
    local_proxy= 10.1.1.1/255.255.255.255/47/0 (type=1),
    remote_proxy= 10.1.1.2/255.255.255.255/47/0 (type=1),
    protocol= ESP, transform= esp-des (Tunnel),
    lifedur= 3600s and 4608000kb,
    spi= 0x3E9(1001), conn_id= 134219729, keysize= 0, flags= 0x2
*Mar  5 20:27:19.321: Crypto mapdb : proxy_match
         src addr     : 10.1.1.1
         dst addr     : 10.1.1.2
         protocol     : 47
         src port     : 0
         dst port     : 0
*Mar  5 20:27:19.321: IPSEC(crypto_IPsec_sa_find_ident_head): reconnecting with the same
  proxies and 10.1.1.2
*Mar 5 20:27:19.321: IPSEC(policy_db_add_ident): src 10.1.1.1, dest 10.1.1.2, dest_port 0

*Mar 5 20:27:19.321: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP . Peer 10.1.1.2:500
*Mar 5 20:27:19.321: IPSEC(create_sa): sa created,
  (sa) sa_dest= 10.1.1.2, sa_prot= 50,
    sa_spi= 0x3E8(1000),
    sa_trans= esp-des , sa_conn_id= 134219728
*Mar  5 20:27:19.321: IPSEC(create_sa): sa created,
  (sa) sa_dest= 10.1.1.1, sa_prot= 50,
    sa_spi= 0x3E9(1001),
    sa_trans= esp-des , sa_conn_id= 134219729
James#

Charlie must now apply a crypto map with matching session keys and matching security parameters (traffic sets and transform sets) to be able to decrypt traffic from James and encrypt traffic to James. Example 2-6 illustrates Charlie's configuration objectives. Note the direction of his session keys (his inbound session key must match James' outbound session key, and his outbound session key must match Charlie's inbound session key).

Example 2-6. IPsec Manual Keying ExampleCharlie

Charlie#configure terminal
*Mar 6 04:11:38.663: %SYS-5-CONFIG_I: Configured from console by console
Enter configuration commands, one per line. End with CNTL/Z.
Charlie(config)#crypto IPsec transform-set IPSECVPN-2 esp-des
Charlie(config)#crypto map IPSECMAP-2 10 IPsec-manual
Charlie(config-crypto-map)#set peer 10.1.1.1
Charlie(config-crypto-map)#set session-key inbound esp 1000 cipher abcd1234abcd1234
  authenticator 01
Charlie(config-crypto-map)#set session-key outbound esp 1001 cipher 1234abcd1234abcd
  authenticator 01
Charlie(config-crypto-map)#set transform-set IPSECVPN-2
Charlie(config-crypto-map)#match address 101
Charlie(config-crypto-map)#exit
Charlie(config)#access-list 101 permit tcp 30.0.0.0 0.255.255.255 20.0.0.0 0.255.255.255
  eq smtp
Charlie(config)#interface serial2/0
Charlie(config-if)#crypto map IPSECMAP-2
Charlie(config-if)#end
Charlie#

Charlie uses the same method to verify SA establishment with Jameshe debugs the output of the IPsec process, as shown in Example 2-7.

Example 2-7. Charlie's IPsec SA Establishment Process

Charlie#debug crypto IPsec
*Mar  5 20:26:57.657: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= 10.1.1.2, remote= 10.1.1.1,
    local_proxy= 10.1.1.2/255.255.255.255/47/0 (type=1),
    remote_proxy= 10.1.1.1/255.255.255.255/47/0 (type=1),
    protocol= ESP, transform= esp-des (Tunnel),
    lifedur= 3600s and 4608000kb,
    spi= 0x5DFCAE01(1576840705), conn_id= 0, keysize= 0, flags= 0x400A
*Mar  5 20:26:57.657: IPsec: Flow_switching Allocated flow for flow_id 134217749
*Mar  5 20:26:57.657: IPsec: Flow_switching Allocated flow for flow_id 134217750
*Mar  5 20:26:57.657: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
*Mar  5 20:26:57.657: IPSEC(key_engine): got a queue event with 2 kei messages
*Mar  5 20:26:57.657: IPSEC(initialize_sas): ,
  (key eng. msg.) OUTBOUND local= 10.1.1.2, remote= 10.1.1.1,
    local_proxy= 10.1.1.2/255.255.255.255/47/0 (type=1),
    remote_proxy= 10.1.1.1/255.255.255.255/47/0 (type=1),
    protocol= ESP, transform= esp-des (Tunnel),
    lifedur= 3600s and 4608000kb,
    spi= 0x3E9(1001), conn_id= 134219728, keysize= 0, flags= 0xA
*Mar  5 20:26:57.657: IPSEC(initialize_sas): ,
  (key eng. msg.) INBOUND local= 10.1.1.2, remote= 10.1.1.1,
    local_proxy= 10.1.1.2/255.255.255.255/47/0 (type=1),
    remote_proxy= 10.1.1.1/255.255.255.255/47/0 (type=1),
    protocol= ESP, transform= esp-des (Tunnel),
    lifedur= 3600s and 4608000kb,
    spi= 0x3E8(1000), conn_id= 134219729, keysize= 0, flags= 0x2
*Mar  5 20:26:57.657: Crypto mapdb : proxy_match
        src addr     : 10.1.1.2
        dst addr     : 10.1.1.1
        protocol     : 47
        src port     : 0
        dst port     : 0
*Mar  5 20:26:57.657: IPSEC(crypto_IPsec_sa_find_ident_head): reconnecting with the same
  proxies and 10.1.1.1
*Mar  5 20:26:57.657: IPSEC(policy_db_add_ident): src 10.1.1.2, dest 10.1.1.1, dest_port 0

*Mar  5 20:26:57.657: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP . Peer 10.1.1.1:500
*Mar   5 20:26:57.657: IPSEC(create_sa): sa created,
  (sa) sa_dest= 10.1.1.1, sa_prot= 50,
    sa_spi= 0x3E9(1001),
    sa_trans= esp-des , sa_conn_id= 134219728
*Mar  5 20:26:57.657: IPSEC(create_sa): sa created,
  (sa) sa_dest= 10.1.1.2, sa_prot= 50,
    sa_spi= 0x3E8(1000),
    sa_trans= esp-des , sa_conn_id= 134219729
Charlie#

Once James and Charlie have established an IPsec SA, they should be able to encrypt and decrypt traffic to and from one another. They can verify the establishment of their SAs with one another by viewing the output of the SA itself, and by looking at the active connections in their crypto engine. Example 2-8 shows encryption and decryption output in Charlie's SADB and in the crypto engine connection database.

Example 2-8. Charlie Verifies SA Establishment with James and Verifies Encryption/Decryption Activity in His IPsec Crypto Engine

Charlie#show crypto IPsec sa

interface: FastEthernet0/0
Crypto map tag: IPSECMAP-2, local addr. 10.1.1.2
protected vrf:
local  ident (addr/mask/prot/port): (10.1.1.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/47/0)
current_peer: 10.1.1.1:500
  PERMIT, flags={origin_is_acl,}
 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
 #pkts compressed: 0, #pkts decompressed: 0
 #pkts not compressed: 0, #pkts compr. failed: 0
 #pkts not decompressed: 0, #pkts decompress failed: 0
 #send errors 0, #recv errors 0

  local crypto endpt.: 10.1.1.2, remote crypto endpt.: 10.1.1.1
  path mtu 1500, media mtu 1500
  current outbound spi: 3E9

     inbound esp sas:
      spi: 0x3E8(1000)
        transform: esp-des ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 23, crypto map: IPSECMAP-2
        crypto engine type: Software, engine_id: 1
        no sa timing
        IV size: 8 bytes
        replay detection support: N

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x3E9(1001)
        transform: esp-des ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 24, crypto map: IPSECMAP-2
        crypto engine type: Software, engine_id: 1
        no sa timing
        IV size: 8 bytes
        replay detection support: N

     outbound ah sas:

     outbound pcp sas:

Charlie#show crypto engine connection active

  ID Interface          IP-Address    State  Algorithm         Encrypt Decrypt
2000 FastEthernet0/0    10.1.1.2      set    DES_56_CBC              0       0
2001 FastEthernet0/0    10.1.1.2      set    DES_56_CBC              0       0

Charlie#ping
Protocol [ip]:
Target IP address: 192.168.193.1
Repeat count [5]: 1500
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.193.2
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 1500, 100-byte ICMP Echos to 192.168.193.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.193.2
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (1499/1500), round-trip min/avg/max = 1/1/4 ms
Charlie#show crypto IPsec sa
interface: FastEthernet0/0
     Crypto map tag: IPSECMAP-2, local addr. 10.1.1.2

     protected vrf:
     local  ident (addr/mask/prot/port): (10.1.1.2/255.255.255.255/47/0)
     remote ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/47/0)
     current_peer: 10.1.1.1:500
       PERMIT, flags={origin_is_acl,}
     #pkts encaps: 1500, #pkts encrypt: 1500, #pkts digest: 0
     #pkts decaps: 1499, #pkts decrypt: 1499, #pkts verify: 0
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts compr. failed: 0
     #pkts not decompressed: 0, #pkts decompress failed: 0
     #send errors 0, #recv errors 0

     local crypto endpt.: 10.1.1.2, remote crypto endpt.: 10.1.1.1
     path mtu 1500, media mtu 1500
     current outbound spi: 3E9

     inbound esp sas:
      spi: 0x3E8(1000)
         transform: esp-des ,
         in use settings ={Tunnel, }
         slot: 0, conn id: 2001, flow_id: 23, crypto map: IPSECMAP-2
         crypto engine type: Software, engine_id: 1
         no sa timing
         IV size: 8 bytes
         replay detection support: N

     inbound ah sas:

     inbound pcp sas:

      outbound esp sas:
       spi: 0x3E9(1001)
         transform: esp-des ,
         in use settings ={Tunnel, }
         slot: 0, conn id: 2000, flow_id: 24, crypto map: IPSECMAP-2
         crypto engine type: Software, engine_id: 1
         no sa timing
         IV size: 8 bytes
         replay detection support: N

      outbound ah sas:

      outbound pcp sas:

Charlie#show crypto engine connection active

  ID  Interface         IP-Address    State  Algorithm    Encrypt  Decrypt
2000  FastEthernet0/0   10.1.1.2      set    DES_56_CBC      1500        0
2001  FastEthernet0/0   10.1.1.2      set    DES_56_CBC         0     1499

Charlie#

Now that Charlie has sent 1499 encrypted packets to James, James can take steps to see what traffic he has decrypted from Charlie, and if he's encrypted any traffic in response to Charlie. Indeed, James receives the 1499 ICMP echo requests that Charlie had sent and decrypts them, as shown in Example 2-6. James sends 1499 ICMP echo reply packets to Charlie, encrypting them before he sends them over. This activity is also shown in the SADB and in the crypto engine connection views listed in Example 2-9.

Example 2-9. James Checks Decryption of Charlie's Traffic (ICMP Echo Request) and Then Verifies That He Is Encrypting Responses to Charlie (ICMP Echo Replies)

James#show crypto IPsec sa

interface: FastEthernet0/0
    Crypto map tag: IPSECMAP-2, local addr. 10.1.1.1

   protected vrf:
   local  ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (10.1.1.2/255.255.255.255/47/0)
   current_peer: 10.1.1.2:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 1499, #pkts encrypt: 1499, #pkts digest: 0
    #pkts decaps: 1499, #pkts decrypt: 1499, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.1.1.2
     path mtu 1500, media mtu 1500
     current outbound spi: 3E8

     inbound esp sas:
      spi: 0x3E9(1001)
        transform: esp-des ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 27, crypto map: IPSECMAP-2
        crypto engine type: Software, engine_id: 1
        no sa timing
        IV size: 8 bytes
        replay detection support: N

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x3E8(1000)
        transform: esp-des ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 28, crypto map: IPSECMAP-2
        crypto engine type: Software, engine_id: 1
        no sa timing
        IV size: 8 bytes
        replay detection support: N

     outbound ah sas:

     outbound pcp sas:

James#show crypto engine connection active

  ID Interface            IP-Address      State   Algorithm         Encrypt  Decrypt
2000 FastEthernet0/0      10.1.1.1        set     DES_56_CBC           1499        0
2001 FastEthernet0/0      10.1.1.1        set     DES_56_CBC              0     1499

James#

The Need for Security Association and Key Management

Manual keying presents certain challenges in IPsec VPN deployments that must be resolved. Because session keys are manually set, there is no way for them to be updated automatically, which presents a security risk. Likewise, security associations are fixed, and do not time out even if they are not in use. This presents scalability problems both on the crypto endpoint platform itself, and in the design of the VPN. As the amount of IPsec SAs grows, session keys are less likely to be unique at each peer. Additionally, the large number of SAs that must be maintained causes inefficiencies in the amount of memory required in the SADB, as the SADB is being populated with IPsec SAs that are stale, or no longer in use. The IETF specified a framework to address these issues, called the Internet Security Association and Key Management Protocol. The Internet Key Exchange protocol is a combination of key exchange and security association protocols, including ISAKMP, which is built for IPsec. The vast majority of IPsec designs in use today leverage the scalability features provided by ISAKMP and IKE. As such, IPsec VPN topologies using manual session keys are rarely found.


IKE and ISAKMP

Internet Key Exchange and the Internet Security Association and Key Management Protocol were designed to allow crypto endpoints to dynamically exchange keys and negotiate security associations. Unlike the examples that we've discussed that use manual SAs, IKE SAs can be established on the fly and torn down at a time period negotiated. As we had discussed before, IPsec specifies two SAs. The type of SA is the IPsec SA, which we reviewed in fair detail in examples 2-1 through 2-9. The second one, which we have yet to discuss in great detail, is the IKE SA. It is over this SA, the one that IKE establishes, that IPsec can now dynamically establish and tear down its SA between crypto endpoints.

IKE and ISAKMP Terminology and Background

ISAKMP was originally defined as a framework implementing two critical services to growing IPsec environments, which are dynamic establishment of security associations and dynamic exchange of cryptographic keys over a secure channel. As such, ISAKMP defines procedures for:

  • Crypto endpoint authentication procedures

  • IPsec SA negotiation, maintenance, and timeout

  • Cryptographic key generation and exchange techniques (Diffie-Hellman)

  • Threat mitigation (antireplay, DoS mitigation techniques)

However, ISAKMP is a framework for delivering these servicesit does not define the protocol for them. As such, ISAKMP is designed to be key-exchange independent, and supports a number of key exchange protocols. In the IPsec world, we are concerned with one of these key exchange protocolsIKE.

The protocol used for key exchange and SA negotiation in IPsec today, IKE, uses the framework outlined in ISAKMP to deliver upon authentication, SA negotiation, key generation and exchange, and native threat mitigation services. IKE represents a number of key exchange and SA negotiation protocols (Oakley and SKEME) that have been combined to fit within the ISAKMP framework. Oakley is a key exchange and management protocol that allows for the exchange of multiple keys and their corresponding services. SKEME supplies anonymity and nonrepudiation using its own key exchange method. IKE combines the strengths of Oakley and SKEME in a comprehensive protocol for establishing a secure channel over which to establish IPsec SAs.

As IKE is the ISAKMP protocol for IPsec, we will be discussing Oakley and SKEME only insofar as their relevance to IKE. In-depth coverage of Oakley and SKEME is outside of the scope of this work.

IKE SA Negotiation and Maintenance

The concept of an IPsec SA lifetime does not exist when using manual keys. The security parameters that comprise an IPsec SA are all manually defined. This is not the case with IKE/ISAKMP. IKE dynamically creates IPsec SAs upon the transmittal of traffic matching the IPsec policy. This is done by exchanging a series of messages over UDP port 500. IKE allows the crypto endpoints to negotiate a lifetime for each SA. This enables network administrators to use their SADB more efficiently through establishing security associations only when needed and automatically tearing down stale SAs at the end of their agreed-upon lifetime. Example 2-10 illustrates the configuration of the IPsec SA lifetime that Charlie would like to negotiate with James during IKE.

Example 2-10. Charlie Specifies a Lifetime for His IPsec SAs, Negotiated with James During IKE

Charlie#
Charlie#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Charlie(config)#crypto isakmp policy 10
Charlie(config)#lifetime ?
  <60-86400>  lifetime in seconds

IPsec Diffie-Hellman Shared Secret Key Generation Using IKE

As we've discussed already in our overview of cryptographic components, IPsec uses symmetric key encryption. This requires the use of a shared secret key to exist on both crypto endpoints. We've seen examples of how one can preplace the session key on each endpoint to establish IPsec SAs. However, this approach presents a number of problems affecting the administrative overhead, performance, and security of an IPsec VPN:

  • Session keys for every SA (inbound and outbound at each crypto endpoint) for every IPsec tunnel. This presents greatly increased administrative overhead, especially if crypto session keys are to be changed regularly for security purposes.

  • IPsec SAs will never time out. If IPsec SAs are not in use for extended periods of time, they cannot time out and reinitiate upon matching policy traffic. As a result, manual session key configuration requires that the crypto endpoints maintain all of the SAs configured in the SADB, as opposed to just those in use with IKE.

  • Session keys never change, unless they are manually altered. The more frequently one changes the session keys, the less likely they are to be compromised.

  • Manual keying negates antireplay techniques between crypto peers.

  • There is no CA support for manual session keys.

As we've discussed, IKE exists, at least in part, as an alternative that is designed to increase scalability in IPsec VPN designs. Because keys are no longer manually configured in IKE, they must be dynamically created. IKE uses the Diffie-Hellman algorithm to dynamically create session keys exchanged over IKE. Diffie-Hellman is configured as part of the ISAKMP policy. The default MODP is 768 bits in length, denoted by group 1. Administrators have the option to choose between 3 different MODP for Diffie-Hellman secret key generation, as illustrated in Example 2-11.

Example 2-11. ISAKMP Policy Diffie-Hellman Configuration (Charlie Selects DH MODP 2)

Charlie#
Charlie#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Charlie(config)#crypto isakmp policy 10
Charlie(config-isakmp)#group ?
  1  Diffie-Hellman group 1
  2  Diffie-Hellman group 2
  5  Diffie-Hellman group 5

Charlie(config-isakmp)#group 2
Charlie(config-isakmp)#end
Charlie#

Note

Diffie-Hellman group 5 was created for ciphers requiring larger keys, such as AES. It is supported only in IOS releases later than 12.2. Like RSA keys, larger Diffie-Hellman MODPs ensure a stronger Diffie-Hellman secret key. However, as Diffie-Hellman MODP values get larger, they become more computationally expensive.

Consider once more the exchange between James and Charlie listed in Figure 2-22. Both want to exchange secure keys across the network but need an automated method to do so. As such, instead of manually configuring a shared secret key such as "abcd1234abcd1234," or some other password that could be compromised when being transported across the untrusted media between them, James and Charlie derive shared secret keys together using the Diffie-Hellman algorithm.

Figure 2-22. James and Charlie Derive Shared Secret Keys Using Diffie-Hellman

[View full size image]

The following order of operations outlines the exchange that James and Charlie will execute when deriving shared secret keys using Diffie-Hellman, as illustrated in Figure 2-22:

1. | Charlie and James derive two large, random numbers P and Q, and exchange them with one another. Usually, this is done in a master-slave relationship, where one party will derive the two numbers to be used in the DH exchange and forward them over to its peer. In this case, Charlie derives the numbers and exchanges them with his peer, James.
2. | James selects a large random number, A, which he keeps private. He uses this number to calculate the value of A*, which is defined by the equation A* = (Q ^ A) mod (P). Once he has finished his calculation, James shares the value of A* with Charlie.
3. | Charlie selects a large random number B, which he keeps private. He uses this number to calculate the value of B*, which is defined by the equation B* = (Q ^ B) mod (P). Charlie then shares this value with James.
4. | James and Charlie derive their shared, secret (Diffie-Hellman) keys from the values of B* and A*, respectively. Charlie uses the equation DHS = (A* ^ Q) mod P and James uses the equation DHS = (B* ^ Q) mod P to derive the shared key, commonly referred to as a Diffie-Hellman Secret Key.
5. | Now that James and Charlie have a shared secret key, they can choose one of many effective symmetric key encryption algorithms to use. Examples of such symmetric encryption transforms include DES, 3DES, and AES, which will be explored later in this chapter.

In the example used above, small numbers are used for illustration purposes only. In reality, the effectiveness of the Diffie-Hellman algorithm depends largely on the size of the values selected for P, Q, A, and B mentioned above. As with RSA encryption, P and Q must be large, randomly selected prime numbers. A and B can be any large, randomly selected numbersthey do not have to be prime.

A Diffie-Hellman derived keypair presents two mathematical tasks to would-be attackers who wish to compromise the shared secret key's confidentiality. First, an attacker must be able to derive A from seeing Q ^ A. This would require the computation of a discrete algorithm. The second strength is similar to one of RSA's key strengthsthe attacker must be able to factor two large prime numbers. Hence, Diffie-Hellman values for P and Q share the same requirement as an RSA key modulusit must be large and random. Diffie-Hellman does not typically specify a modulus size directly. Instead, the modulus of a Diffie-Hellman key is referred to as the Diffie-Hellman group. There are four different Diffie-Hellman Groups that yield a DHS that is approximately equal to a 7080-bit symmetric key in strength.

Note

Existing Diffie-Hellman groups have traditionally accommodated commercially available symmetric cryptographic exchanges such as DES and 3DES. But, because the AES transform supports up to 256-bit encryption, stronger symmetric keys are required. Hence, demand has been sparked for a fifth Diffie-Hellman group. RFC 3526 describes the development of DH group 5 in more detail.

Unless attackers can leap the mathematical hurdles described above, the DH secret key can be shared between the peers confidentially without an attacker being able to determine its value. IKE provides for additional confidentiality in the exchange of security parameters by encrypting the communication sessions over IKE. The encryption cipher to be used for encrypting the IKE channel is configured in Example 2-12, using the Diffie-Hellman shared secret as the symmetric encryption key on each peer.

Example 2-12. James Configures IPsec and IKE Encryption Ciphers.

James#
James#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
James(config)#crypto isakmp policy 10
James(config-isakmp)# encryption 3DES
James(config-isakmp) end
James#

Tip

The Diffie-Hellman keys used for encrypting IKE can also be used as the shared session key for the cipher specified in the IPsec transform. For stronger security, another new Diffie-Hellman key can be created over IKE for use with IPsec transform ciphers.

IKE Authentication Services

In an IPsec VPN using ISAKMP, IKE will be the channel over which security parameters are exchanged for IPsec SA negotiation. As such, it is absolutely critical that IKE SAs are established securely. To do this, IKE offers a number of robust authentication mechanisms to ensure that crypto endpoints are not exchanging information with would-be attackers instead of valid endpoints. Cisco IPsec VPN crypto endpoints support all of IKE's supported authentication protocols, which include:

  • Pre-Shared Keys

  • RSA Encryption (Encrypted Nonces)

  • RSA Signatures (X.509 certificate basedrequires X.509 CA)

Pre-Shared Keys

For smaller networks on which keys can be manually defined, IKE preshared keys (PSKs) can be used. PSKs are manually defined in the IKE policy of each crypto endpoint. Once crypto and ISAKMP policies are attached to active crypto interfaces, IKE attempts to exchange PSKs with the appropriate crypto peer, or IPsec tunnel endpoint.

Note

A defined, static PSK may specify a single peer to share a key with. Alternately, a range of peers can be specified for a single key using wildcard subnet masks in the ISAKMP key definition. A single IKE PSK defined for use with multiple peers using wildcard subnet masks is typically referred to as a wildcard preshared key.

To guarantee authenticity of this message exchange, IKE appends a message digest to the key through a user-defined hash algorithm (MD5 or SHA-1). Example 2-13 shows the required IKE configurations on James and Charlie.

Example 2-13. IKE Configurations for James and Charlie Using PSKs

Charlie#
Charlie#configure terminal
*Mar  6 04:11:38.663: %SYS-5-CONFIG_I: Configured from console by console
Enter configuration commands, one per line.  End with CNTL/Z.
Charlie(config)#crypto isakmp key unctarheels address 10.1.1.1
Charlie(config)#crypto isakmp policy 10
Charlie(config-isakmp)# encryption 3des
Charlie(config-isakmp)# authentication pre-share
Charlie(config-isakmp)# group 2
Charlie(config-isakmp)# lifetime 50000
Charlie(config-isakmp)#end
Charlie#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Charlie(config)#crypto map IPSECMAP-3 10 IPsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
Charlie(config-crypto-map)#set peer 10.1.1.1
Charlie(config-crypto-map)#set transform-set IPSECVPN-2
Charlie(config-crypto-map)#match address 101
Charlie(config-crypto-map)#end
Charlie#

James(config)#crypto isakmp policy 10
James(config-isakmp)# encryption 3des
James(config-isakmp)# authentication pre-share
James(config-isakmp)# group 2
James(config-isakmp)# lifetime 50000
James(config-isakmp)#exit
James(config)#crypto isakmp key unctarheels address 10.1.1.2
James(config)#crypto map IPSECMAP-3 10 IPsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
James(config-crypto-map)#match address 101
James(config-crypto-map)#set transform
James(config-crypto-map)#set transform-set IPSECVPN-2
James(config-crypto-map)#set peer 10.1.1.2
James(config-crypto-map)#end

While pre-shared keys are effective in smaller, trusted environments, the obvious pitfalls associated with manual keying exist. Somebody could verbally compromise the key, or the key could be a simple key that is easily guessed (administrator's home town, favorite baseball team, birthday, and so on). Because all peers share the same wildcard PSK, that key must be changed on all peers using that key, which can lead to increased administrative overhead. As such, wildcard PSKs have inherent security flaws primarily related to inability to effectively manage the eviction of a once-trusted IPsec peer in the group and are generally not recommended without the use of added authentication capabilities such as IKE extended authentication (x-Auth). IKE x-Auth and wildcard PSKs are discussed in greater detail in Chapter 12. In addition to IKE PSKs with x-Auth, IKE incorporates options for stronger keying in environments that require stronger security. Two such options are RSA Encryption (nonces), and RSA Signatures (CA-signed certificates), which enable administrators to have the crypto endpoint dynamically generate a pair of cryptographic keys for authentication.

Remember that IKE is designed to enable the setup and teardown of SAs dynamically, which means that key exchange will be done more often. As such, the low computational overhead that PSK authentication offers makes it an attractive design option when their VPN performance is the top design criterion.

RSA Encryption (Encrypted Nonces)

A nonce is a random, or "nonsense," number. IKE can be configured to use the RSA cryptographic algorithm to verify the identity of peers before continuing IKE Phase I negotiation. Nonces are used to add randomness to the exchange, making it harder to crack. Figure 2-23 illustrates the creation and exchange of RSA encrypted nonces.

Figure 2-23. RSA-Encrypted Nonce Authentication

[View full size image]

When using the RSA encrypted nonce method of ISAKMP authentication, the cryptographic endpoints follow the following series of exchanges, as numbered in Figure 2-23:

1. | Initiator (James) and Responder (Charlie) generate an RSA public and private keypair.
2. | Initiator and Responder exchange public keys.
3. | The Initiator creates a nonce and forwards it to the Responder.
4. | The Responder encrypts the nonce with the Initiator's public RSA key (obtained in Step 1), and forwards the ciphered message to the Initiator.
5. | The Initiator decrypts the ciphered nonce from the Responder. If the value matches the original nonce, the Responder has authenticated with the Initiator (Hash_I).
6. | The Responder creates a nonce and forwards it to the Initiator.
7. | The Initiator encrypts the nonce with the Initiator's public RSA key (obtained in Step 1), and forwards the ciphered nonce to the Responder (Hash_R).
8. | The Responder decrypts the ciphered message with its own private RSA key. If the decrypted nonce matches the original nonce sent from the Responder, the Initiator has authenticated with the responder.

Note

In practice, RSA cookies, Diffie-Hellman secrets, and other items specific to the identity of each crypto endpoint are combined with the nonce before they are ciphered at Initiator and Responder. The output of the cipher is usually noted as "Hash_I" and "Hash_R" for Initiator and Responder, respectively.

RSA Signatures and X.509 Certificates

RSA signatures are a form of Digital Signature, the operation of which is described previously in Figure 2-8. RSA signatures, however, combine the strength of a standard Digital Signature with the strength of the RSA encryption algorithm, also described above, to yield an RSA signature. Crypto-enabled network devices often will use RSA signatures when exchanging X.509-based certificates with an X.509 compliant Certificate Authority (CA).

ITU-T X.509 Certificates and CAs were developed to aid administrative burden in asymmetric cryptographic deployments through leveraging a central point of administration, or a CA, for cryptographic endpoints to register their public keys and to obtain the public keys of their peers. In order to effectively exchange this information, the CA must communicate certificates in a standard format that is agreed upon with its peers. ITU-T X.509 formatted certificates are commonly accepted as the standard for this type of public key cryptosystem.

Note

X.509 is discussed in greater detail in Chapter 11, "Public Key Infrastructure and IPsec VPNs." Figure 11-2 illustrates the format of an X.509v3 certificate.

Certificate Authorities enable network administrators to effectively manage large-scale crypto deployments by concentrating the administration of public key distribution into one source. In doing so, administrators can be assured that keys are exchanged with authentic sources and destinations. The use of CA-based PKI does not enhance the level of confidentiality exchanged in an asymmetric key crypto deployment. It does, however, enforce data authentication in a fashion that enables enhanced scalability in the number of encrypting/decrypting peers.

Endpoints using RSA signatures for IKE authentication will enroll using Simple Certificate Enrollment Protocol (SCEP), as defined by the X.509 standard. The transport used to distribute certificates in the exchange previously described uses a client-server application such as HTTP, FTP, or Lightweight Directory Access Protocol (LDAP). Cisco Systems manufactures a full set of network devices and appliances that use X.509-based PKI cryptosystems that leverage protocols such as HTTP for certificate transport, including firewalls, intrusion detection systems, routers, switches, and VPN concentrators.

Note

Public Key Infrastructures using the RSA Signatures method of IKE authentication are discussed in greater detail in Chapter 11, including design concepts and a more detailed description of the Endpoint-CA relationship within a PKI. The mechanics for configuring and troubleshooting IKE authentication with RSA-sigs is also discussed in greater detail in Chapter 11. The process of enrolling VPN endpoints in to the PKI using a CA and RSA-sigs is discussed in greater detail in Chapter 11 and summarized in Appendix A of this text.

IKE Phase I Negotiation

As we've discussed, the goal of IKE is establishment of a secure channel over which to exchange security parameters, such as those that comprise IPsec SA. This negotiation is referred to as Phase I of IKE negotiation. In order to complete IKE Phase I negotiation, and hence to establish a secure channel for security parameter negotiation, both peers must agree on the following parameters:

  • Authentication Method

  • Authentication Hash Algorithm

  • Encryption Cipher

  • Diffie-Hellman Group Number (MODP size)

Once these methods are agreed upon, the peers begin the negotiation process. The result of Phase I IKE negotiation is the establishment of an ISAKMP SA. Once ISAKMP SA has been negotiated between crypto endpoints, an authenticated channel for confidential establishment IPsec SAs can be established.

Main Mode

Main mode IKE negotiation provides identity protection between the two crypto endpoints. It does, however, consume more resources than aggressive mode. Likewise, main mode involves a more complicated exchange than aggressive mode. Main mode enables two crypto endpoints to establish an ISAKMP SA securely, without ever exchanging the identity of either crypto endpoint in clear text. To do this, IKE in Main Mode follows three steps with a set of three messages. Consider the main mode exchange between James and Charlie in Figure 2-24.

Figure 2-24. ISAKMP Negotiation in Main Mode

[View full size image]

The following sequence of events describes the negotiation of the IKE SA in main mode as illustrated in Figure 2-24:

1. | Charlie and James exchange to agree upon a set of security parametersencryption cipher, authentication hash, authentication method, and Diffie-Hellman Group number. James initiates the process by sending a list of available proposals. Charlie responds by selecting a proposal from James' list of options and replying to James.
2. | Charlie and James exchange Diffie-Hellman public keys and nonces. The two parties are able to derive shared Diffie-Hellman keys from this information.
3. | Charlie and James are now able to authenticate each other. Now that they have shared session keys derived from Diffie-Hellman exchange, and an agreed-upon cipher, the authentication messages can be encrypted. This allows for a purely confidential exchange when establishing ISAKMP SA, as identity messages are never sent in the clear and are sent with appended hashes for message authentication.

Tip

IOS always attempts to negotiate IKE Phase I in main mode before attempting aggressive mode. However, IOS can be configured not to attempt aggressive mode upon failure to negotiate main mode. IOS will respond to crypto endpoints initiating aggressive mode exchanges.

Aggressive Mode

Unlike IKE negotiation in main mode, which involves three exchanges, aggressive mode involves only two exchanges. As with main mode, aggressive mode exchange involves an exchange of messages targeted at agreeing on encryption cipher, authentication hash, authentication method, and Diffie-Hellman group number. Unlike main mode, in aggressive mode the sender's and receiver's identities are not encrypted because they are sent concurrently with cryptographic elements needed for encryption in the first IKE aggressive mode exchange. In an aggressive mode exchange, the Diffie-Hellman group number and encryption cipher are negotiated only in the IPsec SA. Once a security proposal has been agreed upon, the two crypto endpoints authenticate each other in clear text.

In summary, IKE aggressive mode exchanges all of the information that IKE main mode does, but instead of using a 3-step exchange, aggressive mode uses a 2-step exchange. Condensing the number of exchanges weakens the security of the process, as the sender's and receiver's identities are exchanged in cleartext. Figure 2-25 illustrates the negotiation of an IKE SA using aggressive mode.

Figure 2-25. IKE Exchange in Aggressive Mode

[View full size image]

Aggressive mode is useful for VPNs that require rapid ISAKMP SA establishment. They are also useful on crypto endpoints with low processing resources, such as software-based VPN clients on low-end workstations. The obvious tradeoff is that authentication information in ISAKMP SA negotiation is performed in the clear, and is only protected by the insertion of a message digest using the selected authentication hash algorithm.

By default, Cisco IOS will attempt to negotiate Phase 1 using main mode. If main mode fails, the default behavior is to automatically try to negotiate the SA using aggressive mode. Cisco IOS can be configured to disallow the use of aggressive mode as an option for Phase 1 negotiation, as illustrated in Example 2-14.

Example 2-14. Disallowing Aggressive Mode as an Option for Phase 1 Negotiation

James(config)#crypto isakmp aggressive-mode disable

IKE Phase II Negotiation

The goal of IKE Phase II negotiation is establishment of IPsec SAs between two endpoints. IKE uses Diffie-Hellman key exchange to negotiate the shared secret key to be used in the encryption cipher specified in the IPsec transform set. The IPsec SA can include the shared Diffie-Hellman key used to encrypt the ISAKMP SA, or it can be renegotiated over the ISAKMP SA during Phase II negotiation.

Quick Mode

IKE Phase II negotiation is done in only one mode, quick mode. Due to the fact that Phase II negotiation's goal is establishment of an IPsec SA, quick mode exchange must inform both crypto endpoints of the IPsec mode to use ESP and AH and all other relevant variables needed to populate the IPsec SA. To do this, quick mode uses a two-step exchange composed of four messages sent between initiator (James) and responder (Charlie), as illustrated in Figure 2-26.

Figure 2-26. IPsec Quick-Mode Negotiation

[View full size image]

After IKE Phase II negotiation has successfully completed quick mode exchange, both crypto endpoints should have three established security associations in their SADB:

  • ISAKMP SA This is a bidirectional SA that is used to dynamically establish a secure channel for the negotiation of IPsec SAs.

  • Outbound IPsec SA This unidirectional SA is used to provide protection services offered by IPsec to traffic that is to be transmitted to the remote tunnel endpoint, identified by the SPI within the IPsec header.

  • Inbound IPsec SA This unidirectional SA is used to process inbound IPsec traffic from from a remote crypto endpoint. Again, this traffic is identified by the SPI that was inserted into the IPsec header by the transmitting IPsec endpoint.

PFS

PFS guarantees that session keys are generated independently from previous session keys. With PFS enabled, would-be attackers are unable to use old session keys that have been compromised to compromise the integrity and confidentiality of current and future session keys. PFS does this by forcing renegotiation of shared Diffie-Hellman keys whenever a new negotiation of ISAKMP and IPsec SAs occurs. In doing so, PFS offers greater confidentiality, but also consumes more processing resources on the crypto endpoints, elongating the time that it takes to establish ISAKMP and IPsec SAs. As PFS is a feature based on Diffie-Hellman, the strength of PFS relies on the prime modulus size used to derive the shared secret keys. There are three prime modulus sizes offering increasing level of security (groups 1, 2, and 5). PFS is enabled when configuring the IPsec crypto map, as illustrated in Example 2-15.

Example 2-15. Configuring PFS

Charlie#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Charlie(config)#crypto map IPSECMAP-3 10 IPsec-isakmp
Charlie(config-crypto-map)#set pfs ?
  group1  D-H Group1 (768-bit modp)
  group2  D-H Group2 (1024-bit modp)
  group5  D-H Group5 (1536-bit modp)
  <cr>

Charlie(config-crypto-map)#set pfs group5
Charlie(config-crypto-map)#end
Charlie#

Note

PFS requires IKE. As such, PFS can be configured only on crypto maps that are configured for IKE/ISAKMP. Crypto maps using manually set session keys do not support PFS.

Dead Peer Detection and IKE Keepalives

Crypto endpoints use IKE keepalives to poll the validity of active ISAKMP SAs. IKE keepalives enable routers to quickly detect when IPsec and ISAKMP SAs become inactive, or stale. This enables the crypto endpoints to optimally maintain the SADB, which also enables greater IPsec SA scalability on crypto endpoints. When a crypto endpoint does not receive three keepalives in a row, it tears down the SAs associated with that peer and initiates IKE Phase 1 negotiation with the next peer referenced in the crypto map. Figure 2-27 illustrates the process of detecting a stale SA with IKE Keepalives.

Figure 2-27. Detecting Stale SAs with IKE Keepalives

[View full size image]

Example 2-16 illustrates Kristen's configuration for failover using IKE DPD to a redundantly defined IPsec peer. To do this, Kristen specifies the use of IKE keepalives. If Kristen's primary peer, 10.1.1.2, goes offline, she will attempt to negotiate another IPsec VPN tunnel with 10.1.1.3 after missing three IKE keepalives spaced 10s apart (Example 2-16, line 9). In addition, Kristen must have two peers defined in her crypto map in order to facilitate this failover (Example 2-16, lines 16 and 17). Because Kristen uses IKE PSKs, she must also have the shared secret key defined with both peers (Example 2-16, lines 10 and 11).

Example 2-16. Kristen Uses DPD and IKE Keepalives for VPN High Availability

Kristen
Kristen#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Kristen(config)#crypto isakmp policy 10
Kristen(config-isakmp)#hash sha
Kristen(config-isakmp)#authentication pre-share
Kristen(config-isakmp)#encryption 3des
Kristen(config-isakmp)#exit
Kristen(config)#crypto isakmp keepalive 10
Kristen(config)#crypto isakmp key ncstatewolfpack address 10.1.1.2
Kristen(config)#crypto isakmp key ncstatewolfpack address 10.1.1.3
Kristen(config)#crypto map IPSECVPN-1 10 IPsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
        and a valid access list have been configured.
Kristen(config-crypto-map)#match add 101
Kristen(config-crypto-map)#set peer 10.1.1.2
Kristen(config-crypto-map)#set peer 10.1.1.3
Kristen(config-crypto-map)#set trans IPSECVPN-1
Kristen(config-crypto-map)#end
Kristen#

Dead Peer Detection (DPD) refers to a crypto endpoint's ability to detect when one of its peers goes offline. DPD can be useful on highly available peers that are receiving traffic from its remote crypto endpoints. With DPD, crypto endpoints will not send keepalives if they are sending traffic to their peers. This keeps the processing of keepalives relatively low on crypto endpoints and decreases use on links between crypto endpoints.

Configuring ISAKMP

In order to successfully configure two crypto endpoints to establish an ISAKMP SA, the security administrator must instruct the crypto endpoints to accept the appropriate security proposals, apply those ISAKMP security proposals to a crypto map, and apply that crypto map to the appropriate crypto interface or interfaces. The following provides a brief list of tasks to be executed when creating an ISAKMP policy:

Step 1.
Define the ISAKMP policy. Within the ISAKMP policy, define security parameters to be used with ISAKMP provided in the following list:

  • Authentication Method

  • Authentication Hash Algorithm

  • Encryption Cipher

  • Diffie-Hellman MODP Group

Step 2.
Instruct the crypto map to reference ISAKMP policies to negotiate ISAKMP SAs and IPsec SAs.

Step 3.
Apply the crypto map to the appropriate crypto interfaces. This will enable ISAKMP in the router, and will enable ISAKMP and IPsec SA negotiation using IKE on those crypto interfaces.

When ISAKMP policies are referenced in crypto maps, the priority keyword identifies the preference that the initiator expresses to the responder when selecting security proposals in IKE Phase I exchange. In Example 2-17, James requests that ISAKMP policy 20 be selected for IKE Phase I negotiation with Charlie. Charlie will try to accept ISAKMP policy 20, but, because he has no matching security proposal, he will select ISAKMP policy 10. James and Charlie will use ISAKMP policy 20 for IKE Negotiation, as illustrated in Figure 2-28. Example 2-17 provides the ISAKMP policy configuration corresponding to the exchange illustrated in Figure 2-28.

Figure 2-28.

[View full size image]

Example 2-17. James and Charlie Use ISAKMP Policies for IKE Negotiation

James#
James#configure terminal
James(config)#crypto isakmp policy 10
James(config-isakmp)#encryption 3des
James(config-isakmp)#authentication pre-share
James(config-isakmp)#group 2
James(config-isakmp)#lifetime 50000
James(config-isakmp)#exit
James(config)#crypto isakmp policy 20
James(config-isakmp)#hash md5
James(config-isakmp)#authentication rsa-encr
James(config-isakmp)#group 5
James(config-isakmp)#exit
James(config)#crypto isakmp key unctarheels address 10.1.1.2
James(config)#crypto IPsec transform-set IPSECVPN-1 esp-des
James(config)#crypto map IPSECMAP-1 10 IPsec-isakmp
James(config-crypto-map)#set peer 10.1.1.2
James(config-crypto-map)#set transform-set IPSECVPN-1
James(config-crypto-map)#match address 101
James(config-crypto-map)#exit
James(config)#interface serial2/0
James(config-if)#crypto map IPSECMAP-1
James(config-if)#end
James#

Charlie#
Charlie#configure terminal
Charlie(config)#crypto isakmp policy 10
Charlie(config-isakmp)#encryption 3des
Charlie(config-isakmp)#authentication pre-share
Charlie(config-isakmp)#group 2
Charlie(config-isakmp)#lifetime 50000
Charlie(config-isakmp)#exit
Charlie(config)#crypto isakmp key unctarheels address 10.1.1.1
Charlie(config)#crypto IPsec transform-set IPSECVPN-2 esp-des
Charlie(config)#crypto map IPSECVPN-1 10 IPsec-isakmp
Charlie(config-crypto-map)#set peer 10.1.1.1
Charlie(config-crypto-map)#set transform-set IPSECVPN-2
Charlie(config-crypto-map)#match address 101
Charlie(config-crypto-map)#exit
Charlie(config)#interface serial2/0
Charlie(config-if)#crypto map IPSECMAP-1
Charlie(config-if)#end
Charlie#

IKE with RAVPN Extensions

There are extensions specified to IKE that can aid in designing certain IPsec VPN models. In this section, we will explore the usefulness of two such extensions in a remote access VPN topology (RAVPN):

  • IKE Mode Configuration

  • IKE Extended Authentication (x-Auth)

We will use an RAVPN topology in which remote clients with software-based IPsec VPN clients installed use mode configuration for client IP address assignment and IKE x-Auth to enable administrators to provision increased granularity when authenticating client sessions.

Mode Configuration

Using mode config, administrators can dynamically manage RAVPN client addressing, domain names, WINS servers, and DNS servers on the RAVPN concentrator itself. This greatly simplifies administrative overhead of the RAVPN for both network administrators and users. Mode config will provide the RAVPN client with an IP address that will be used as the IP address of the inner ESP or AH header. The client's publicly available address, usually assigned by the clients' ISP, will populate the outer ESP or AH header.

IKE mode config offers a scalable alternative to manually assigning tunneled IP address space to each RAVPN client. With mode config, IP addresses and other parameters are configured on the concentrator and pushed to the clients after they have been authenticated in Phase I negotiation. Mode config does this by dynamically assigning IP addresses from a pool configured on the concentrator and referenced in the ISAKMP group policy. A VPN concentrator can initiate assignment of addresses to RAVPN clients, respond to requests for addresses from RAVPN clients, or both. In Figure 2-29, Kristen initiates address assignment to Charlie, and responds to James' request for an IP address. Example 2-18 illustrates the necessary configuration on Kristen, the IOS VPN concentrator in this topology. In this specific example, Kristen is configured to assign IP addresses from a locally defined pool, "RAVPN-pool." Kristen is configured to assign addresses in one of two ways:

  • Address assignment in response to a request (Charlie's request in Figure 2-29).

  • Address assignment when initiating an IPsec VPN tunnel (James' IP address assignment in Figure 2-29).

    Figure 2-29. Address Assignment with IKE Extended Authentication

    [View full size image]

Example 2-18. VPN Concentrator Settings for Extended Authentication

Kristen#
Kristen#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Kristen(config)#aaa new-model
Kristen(config)#aaa authentication login RAVPN-aaa group tacacs+
Kristen(config)#aaa authorization network RAVPN-aaa group tacacs+
Kristen(config)#crypto isakmp policy 10
Kristen(config-isakmp)#hash md5
Kristen(config-isakmp)#authentication pre-share
Kristen(config-isakmp)#crypto isakmp client configuration group RAVPN-group
Kristen(config-isakmp-group)#key ncstatewolfpack
Kristen(config-isakmp-group)#domain cisco.com
Kristen(config-isakmp-group)#pool RAVPN-pool
Kristen(config-isakmp-group)#exit
Kristen(config)#crypto IPsec transform-set RAVPN-transform esp-aes esp-sha-hmac
Kristen(cfg-crypto-trans)#mode tunnel
Kristen(cfg-crypto-trans)#exit
Kristen(config)#crypto dynamic-map RAVPN-dyn 10
Kristen(config-crypto-map)#set transform-set RAVPN-1
Kristen(config-crypto-map)#exit
Kristen(config)#crypto map RAVPN-map client authentication list RAVPN-aaa
Kristen(config)#crypto map RAVPN-map isakmp authorization list RAVPN-aaa
Kristen(config)#crypto map RAVPN-map client configuration address respond
Kristen(config)#crypto map RAVPN-map client configuration address initiate
Kristen(config)#crypto map RAVPN-map 10 IPsec-isakmp dynamic RAVPN-dyn
Kristen(config)#interface FastEthernet0/0
Kristen(config-if)#crypto map RAVPN-map
Kristen(config-if)#exit
Kristen(config)#ip local pool RAVPN-pool 10.1.1.1 10.1.1.254
Access-list 101 permit
Kristen(config)#tacacs-server host 100.1.1.254
Kristen(config)#tacacs-server directed-request
Kristen(config)#tacacs-server key Cisco

X-Auth

As confidentiality continues to become increasingly important in VPNs, network administrators are increasingly turning to IPsec as a solution in Remote Access VPN deployments. We've covered, in brief, RAVPN architectures, which typically describe a large number of IPsec tunnels concentrated on one or more VPN concentrators. In this type of deployment, the ability to extend authentication (x-Auth) services down to the user level greatly enhances network administrators' granularity and flexibility when authenticating IPsec Remote Access VPN connections. For example, administrators configuring x-Auth in RAVPN deployments can offload user authentication to AAA servers such as CSACS.

X-Auth is not a replacement for IKE Phase I's existing authentication capabilities. Instead, x-Auth occurs in addition to IKE Phase I negotiation and occurs after IKE authenticates the crypto endpoint.

Tip

As x-Auth is not exactly described in Phase I negotiation, and Phase II negotiation cannot complete before Phase I negotiation (and subsequently x-Auth), x-Auth is commonly said to occur during Phase 1.5 negotiation.

As such, to use x-Auth, administrators must configure native Phase I authentication schemes and x-Auth parameters. Example 2-18 shows IPsec RAVPN configurations on an IOS-based VPN concentrator configured for x-Auth and authentication, authoring, and accounting (AAA) (as displayed in Figure 2-29).

Note

Example 2-18 contains dynamic crypto maps and wildcard PSKs, both of which are outside of the scope of this chapter. These topics are covered in greater detail in Chapter 14.

In the scenario in Example 2-18, Kristen is a router running Cisco IOS that is concentrating IPsec tunnels used for remote access by James and Charlie. Kristen uses several parameters to authenticate her remote access clientsgroup ID and key. All remote access clients must be configured with these keys in order to authenticate with Kristen. This is done in IKE Phase I negotiation. Additionally, Kristen uses x-Auth to authenticate and authorize James and Charlie against an AAA database on the TACACS+ server, 100.1.1.254. Kristen is configured to serve her remote clients with an address from the pool "RAVPN-pool," and assign them a domain name of "cisco.com."

Tip

In the configuration in Example 2-18, Kristen will attempt to authenticate any remote client that attempts to connect to her. An ACL can be configured under the ISAKMP group to prevent malicious hosts from continuously trying to connect to the concentrator, initiate authentication processes, and consume unacceptable amounts of processing overhead. Likewise, a dynamic crypto map is used, which does not define a traffic set to protect traffic (protects all traffic from concentrator to client). An access list can be added to the dynamic crypto map to provide further granularity in the protected traffic set definition.


Summary

At this point, you should be familiar with all of the cryptographic components used to create an IPsec VPN. Additionally, you should also be aware of the fundamental mechanics that underpin the establishment of an IPsec VPN itself. The material we've covered thus far is dissected into several major topics that build upon one another:

  • Overview of Cryptographic Components

  • Overview of IPsec Operation

  • Overview of ISAKMP Operation

As we've discussed earlier in this chapter, IPsec relies on many fundamental cryptographic operations to provide authenticity, integrity, confidentiality, and nonrepudiation services to IP data transmissions. Examples of such cryptographic components discussed include hashing functions and message digest creations, Digital Signatures, asymmetric key encryption, and symmetric key encryption.

A secure hash ensures data integrity by performing a mathematical operation based on the original contents of the cleartext message. The resulting value of this mathematical operation is called a message-digest. The sender appends the message digest to the cleartext message and sends both to the receiver. The receiver then performs the same mathematical operation, or hash, on the received cleartext message. The results of this mathematical operation are then compared to the message digest sent from the sender. If the receiver's message digest compares to the sender's message digest, then the message's integrity has not been compromised. In this operation, data authenticity, sender nonrepudiation, or confidentiality have not been provided.

A Digital Signature provides data integrity, just as a hash function would. However, unlike a simple message digest, Digital Signatures also provide data authenticity and sender nonrepudiation. Digital Signatures do this by performing a hash based on the original message contents and a public cryptographic key (of a public/private asymmetric keypair). The resulting message digest is then encrypted with the private key of the asymmetric key pair, resulting in a Digital Signature. The sender sends its public key, the original cleartext message, and an appended Digital Signature to the receiver. The receiver then decrypts the Digital Signature with the public key received from the sender. At this point, the receiver performs the same hashing function on the cleartext message contents and the public key received from the sender. If the resulting message digest matches the decrypted message digest received from the sender, then the message is said to be authentic with preserved data integrity. Note that the original message was sent in the clear, and that Digital Signatures therefore do not provide data confidentiality services to the original message.

In different areas of the IPsec framework (including IKE), encryption and decryption can occur in one of two ways: symmetric key encryption and asymmetric key encryption. Symmetric key encryption refers to a cipher algorithm that uses the same key for encryption and decryption. Symmetric key encryption is therefore not suited for sharing keys over an untrusted medium. IPsec uses symmetric key transforms in its Phase II SA, as symmetric key transforms are better suited for bulk data transfer. Examples of symmetric key encryption ciphers include DES, 3DES, and AES.

Asymmetric key encryption refers to a cipher algorithm that uses one key for encryption (typically the public key) and one key for decryption (typically the private key). Asymmetric key encryption provides increased flexibility with key exchange, enabling a public key to be exchanged over a relatively untrusted medium. Asymmetric encryption, however, is computationally more expensive than symmetric encryption and is therefore less suited to performing bulk data transfer. IKE commonly uses asymmetric key encryption for Phase I SA authentication. Examples of such asymmetric key encryption techniques include RSA-encrypted nonces and RSA Signatures.

IPsec provides data authenticity, sender nonrepudiation, data integrity, and data confidentiality. At this point, we've discussed the mechanics of IPsec with and without IKE. Because IPsec ciphers require a symmetric key for bulk data encryption, keys must be defined manually on IPsec endpoints when IKE is not used. IPsec secures data by creating two unidirectional security associations between the two cryptographic endpoints. Those security associations specify the following components required to secure data transmissions between the endpoints:

  • IPsec Transform Mode: IPsec operates in either tunnel or transport mode.

  • IPsec Symmetric Transform: This is the cipher to be used when encrypting data. Examples include DES, 3DES, and AES.

  • IPsec Peer: Defines the opposite end of the IPsec tunnel.

  • Traffic Encryption/Decryption Sets (Crypto ACL): The two endpoints must agree on the encryption and decryption data sets to successfully negotiate an IPsec SA.

  • Path MTU: Defines the MTU for the path along the IPsec SA.

  • Security Parameter Index (SPI): The SPI is a unique identifier that the cryptographic endpoint uses to select an SA when processing cleartext data matching a valid crypto ACL

  • Security Association Lifetimes: Lifetimes specify the useful life of an IPsec SA.

IPsec specifies two protocols for data transformation: ESP, IP Protocol 50 or AH IP Protocol 51. ESP provides data confidentiality, while AH does not. Yet AH provides a broader scope of data authenticity and integrity than does ESP. In addition to the symmetric transform executed with AH or ESP, optional HMAC authentication can be performed on the data cipher blocks using either MD5 or SHA-1 hash algorithms.

As we've discussed thus far, IPsec must use symmetric key transforms for bulk data ciphering. This requires that the symmetric key must be manually defined for every SA on each cryptographic endpoint. This presents substantial key and SA management scalability issues. The IKE protocol can be used in conjunction with IPsec to dynamically negotiate the elements required to establish an IPsec (Phase II) SA over an untrusted medium. IKE does this by first establishing an authenticated, secure channel across the untrusted medium using either one of three authentication methods:

  • PSKs: Keys used to negotiate are manually defined by the administrator on the crypto endpoints.

  • RSA Encrypted Nonces: public/private RSA keypairs are generated on the crypto endpoints. Public keys are then manually shared with remote endpoints.

  • RSA Signatures: RSA public/private keypairs are generated on the crypto endpoints. Cryptographic endpoints then use a central, commonly trusted entity (a Certificate Authority) to facilitate key exchange.

The secure channel that IKE creates is referred to as the IKE security association (Phase I SA). This SA can be created using one of two modes: main mode or aggressive mode. Though main mode requires more exchanges to establish a Phase I SA, IKE main mode is more secure than aggressive mode as IKE aggressive mode sends both sender and receiver identities in cleartext. Once an IKE SA is established securely, an IPsec SA (Phase II) can be negotiated over the secure channel provided by IKE. This enables both cryptographic endpoints to agree upon Phase II lifetimes, SPIs, peers, cipher methods, and symmetric keys over the network. Unlike IPsec without IKE, cryptographic endpoints that have established a Phase I SA execute Diffie-Hellman over the Phase I SA to derive joint symmetric keys to use when ciphering data with their agreed-upon symmetric key transforms.

In this chapter, we use cryptographic building blocks to lay the foundation for building an understanding of IPsec and IKE mechanics. We've covered the fundamental operation of IPsec without IKE (manual keying) and the operation of IPsec with IKE. The information presented in this chapter on cryptographic components, IPsec, and IKE will serve as the foundation for developing an understanding of basic IPsec deployment topologies, common troubleshooting issues with IPsec VPNs, and resilient IPsec VPN design strategies presented in subsequent chapters.


Chapter 3. Basic IPsec VPN Topologies and Configurations

In this chapter, we will review several common deployments of IPsec virtual private networks (VPNs). We will begin by reviewing the typical site-to-site IPsec model over a dedicated circuit between two endpoints, then discuss some of the design implications as that dedicated circuit grows to include an entire routed domain. We will discuss aggregation of many site-to-site IPsec VPNs at an aggregation point, or hub IPsec router, in a standard hub-and-spoke design and extend the IPsec aggregation concept to include Remote Access VPN (RAVPN) design considerations. Figure 3-1 illustrates a loose process that may be helpful when configuring a crypto endpoint for basic IPsec operations. Though effective IPsec VPN design drives the complexity of configuration far beyond what is depicted in Figure 3-1, most of the basic topologies we will discuss will relate to this procedure on a fundamental level.

Figure 3-1. High-Level Configuration Process for IPsec VPN

[View full size image]

Each of the following deployments requires the configuration of IPsec in a point-to-point fashion in one way or another. As such, all of the topologies discussed share common configuration tasks to establish the IPsec tunnel:

Step 1.
Decide how strong the IPsec transform must be and what mode the tunnel must use (define IPsec Transform Set).

Step 2.
Decide how the session keys must be derived and if IKE is necessary (create ISAKMP Policy or Session Keys within Crypto Map).

Step 3.
If IKE is required, decide on ISAKMP policy parameters (create Internet Security Association and Key Management Protocol policy), addressing the following tasks in your configuration:

  • Authentication method (select one of the following):

    Assign key and peer if pre-shared.

    Create and share RSA public keys if RSA-encr.

    Authenticate and enroll with CA if RSA-sig.

  • Diffie-Hellman Key Modulus (Group #)

  • Hash used for IKE authentication

  • Encryption method used for IKE channel

Step 4.
Identify and assign IPsec peer and any High-Availability requirements. (Create crypto map.)

Note

In this chapter, topologies will include only limited discussions of IPsec High-Availability (HA) design concepts. IPsec HA design and examples are discussed in greater detail in Chapters 5 9.

Step 5.
Define traffic sets to be encrypted (Crypto ACL Definition and Crypto Map Reference).

Step 6.
Identify requirement for PFS and reference PFS group in crypto map if necessary.

Step 7.
Apply crypto map to crypto interfaces.


Site-to-Site IPsec VPN Deployments

The most basic form of IPsec VPN is represented with two VPN endpoints communicating over a directly connected shared media, or dedicated circuit, which closely resembles bulk encryption alternatives at Layer 1 and 2 of the OSI stack (see Table 1-1 for VPN technologies and the OSI stack). This scenario, while simple to deploy and manage, can be cost prohibitive and does not yield many of the benefits of IPsec VPN connectivity over a routed domain (multiple Layer 3 hops between endpoints).

Indeed, because IPsec is a Layer 3 VPN technology, it was designed to function across multiple Layer 3 hops in order to circumvent many of the scalability and manageability issues in previous VPN alternatives. As such, IPsec deployed over a routed domain will also provide further scalability, flexibility, and availability over and beyond the simple dedicated-circuit model. In this section, we will explore design concepts related to both topologies and the corresponding configuration and verification processes required.

Site-to-Site VPN Architectural Overview for a Dedicated Circuit

Site-to-site IPsec VPNs are typically deployed when two or more autonomous systems wish to communicate with each other over an untrusted media when confidential exchange of data is required. Consider the situation described in Figure 3-2, where three autonomous systems wish to communicate using dedicated T-1 circuits between each pair.

Figure 3-2. Site-to-Site IPsec VPN Topology Using Dedicated T-1 Circuits for Communications

[View full size image]

It is important to note that, assuming that each autonomous system (AS) does not act as a transit AS, there is only one path between each AS. Therefore, in this specific case, there is no benefit to configuring redundant peering options or sourcing IPsec tunnel endpoints from highly available IP addresses (such as a loopback address). In this simple site-to-site topology, it is most common to source IPsec VPN tunnel endpoints on the physical interfaces (DS-3 in this case) themselves. This type of topology does not leave room for much in the way of IPsec HA design, and therefore, it is relatively simple to deploy. We will now explore the configuration steps necessary to establish the basic site-to-site IPsec VPN described earlier, and then we will outline some common techniques used to verify the establishment and operation of the IPsec VPN tunnel.

Cisco IOS Site-to-Site IPsec VPN Configuration

The configurations in the following examples were all built using the process described in Figure 3-1 and pertain to the topology depicted in Figure 3-2. Some design considerations for these particular IPsec VPNs are as follows:

  • Tunnel mode is used to keep the original IP header confidential.

  • The routers are capable of handling 256-bit AES ESP transforms in hardware. Hash-based Message Authentication Codes (HMAC) are implemented in the transform to ensure integrity in the cipher block chain of encrypted packets traversing the IPsec security association (SA).

  • The DH group is 5 in order to accommodate the large key material needed by the AES transform.

  • There is no certification authority (CA), and the administrators want to use hardware acceleration, which rules out the RSA-encrypted nonces method of authentication. So preshared keys are used for Internet Security Association and Key Management Protocol (ISAKMP) authentication.

  • Strong authentication is required during ISAKMP, so the hash is SHA-1 and the symmetric transform for the IKE SA is 3DES.

  • It is desirable to have the IPsec session keys derived independently (as opposed to derived from the ISAKMP DH shared secret keys). As such, perfect forward secrecy (PFS) is enabled. Again, the group is 5 to generate the appropriate key material for the IPsec transform (AES).

Note

The preceding VPN considerations describe a relatively strong cryptographic suite. As such, computation resources on the routers must be somewhat substantial to accommodate them. It is important that one weigh the amount of available computational resources against the organization's performance and security requirements before building IPsec VPN configurations.

Example 3-1 provides a configuration for the AS1-7301A in Figure 3-2. This router's configuration employs all of the elements necessary to accommodate a site-to-site IPsec VPN, including the IPsec transform, crypto ACL, and IPsec peer. In this case, AS1-7301A uses two site-to-site IPsec VPNs, to AS#2 and AS#3, respectively. This is accomplished by using two process IDs within the same crypto map (AS1VPN 10 and AS1VPN 20). AS1VPN, process 10, protects traffic from AS1 to AS2, as defined in Crypto ACL 101. AS1VPN, process 20, protects traffic from AS1 to AS3 (Example 3-1, line 14), as defined in Crypto ACL 102 (Example 3-1, line 15).

Example 3-1. Site-to-Site VPN Configuration on AS1-7301A

AS1-7304A#show running-config
!
crypto ipsec transform-set ivdf3-1 esp-aes esp-sha-hmac
crypto map AS1VPN 10 ipsec-isakmp
 set peer 200.1.1.2
 set transform-set ivdf3-1
 match address 101
 set pfs group5
crypto map AS1VPN 20 ipsec-isakmp
 set peer 200.1.1.10
 set transform-set ivdf3-1
 match address 102
 set pfs group5
access-list 101 permit ip 211.0.0.0 0.255.255.255 212.0.0.0 0.255.255.255
access-list 102 permit ip 211.0.0.0 0.255.255.255 213.0.0.0 0.255.255.255
!
interface HSSI1/0
 ip address 200.1.1.1 255.255.255.252
 encapsulation HDLC
 crypto map AS1VPN
   interface HSSI2/0
   ip address 200.1.1.9 255.255.255.252
 encapsulation HDLC
 crypto map AS1VPN

Example 3-2 provides the configuration for the IPsec VPN gateway for AS2, AS2-3745A. Like AS1-7304A, AS2-3745A uses a single crypto map with two process IDs to protect traffic flows to AS1 and AS3. AS2VPN 10 protects traffic to AS1 (endpoint 200.1.1.1), and references ACL101 for crypto-protected traffic and IPsec transform "ivdf3-1." AS2VPN 20 protects traffic to AS3 (endpoint 200.1.1.6), and references ACL102 for crypto-protected traffic and IPsec transform "ivdf3-1." AS2-3745 uses a relatively strong transform, AES cipher with SHA1 HMAC authentication. PFS is also configured to refresh the symmetric transform key each time an IPsec SA is negotiated.

Example 3-2. Site-to-Site VPN Configuration on AS2-3745A

AS2-3745A#show running-config
!
crypto ipsec transform-set ivdf3-1 esp-aes esp-sha-hmac crypto map AS2VPN 10 ipsec-isakmp
 set peer 200.1.1.1
 set transform-set ivdf3-1
 match address 101
 set pfs group5
crypto map AS2VPN 20 ipsec-isakmp
 set peer 200.1.1.6
 set transform-set ivdf3-1
 match address 102
 set pfs group5
access-list 101 permit ip 212.0.0.0 0.255.255.255 211.0.0.0 0.255.255.255
access-list 102 permit ip 212.0.0.0 0.255.255.255 213.0.0.0 0.255.255.255
!
interface HSSI1/0
 ip address 200.1.1.2 255.255.255.252
 encapsulation HDLC
 crypto map AS2VPN
interface HSSI2/0
 ip address 200.1.1.5 255.255.255.252
 encapsulation HDLC
 crypto map AS2VPN

Example 3-3 provides the configuration for the IPsec VPN gateway for AS3, AS3-3745A. Like AS1-7304A and AS2-3745A, AS3-3745A uses a single crypto map with two process IDs to protect traffic flows to AS1 and AS3. AS3VPN 10 protects traffic to AS1 (endpoint 200.1.1.9), and references ACL101 for crypto-protected traffic and IPsec transform "ivdf3-1." AS3VPN 20 protects traffic to AS3 (endpoint 200.1.1.5), and references ACL102 for crypto-protected traffic and IPsec transform "ivdf3-1." AS2-3745 uses a relatively strong transform, AES cipher with SHA1 HMAC authentication. PFS is also configured to refresh the symmetric transform key each time an IPsec SA is negotiated.

Example 3-3. Site-to-Site VPN Configuration on AS3-3745A

AS3-3745A#show run
!
crypto ipsec transform-set ivdf3-1 esp-aes esp-sha-hmac
crypto map AS3VPN 10 ipsec-isakmp
 set peer 200.1.1.9
 set transform-set ivdf3-1
 match address 101
 set pfs group5
crypto map AS3VPN 20 ipsec-isakmp
 set peer 200.1.1.5
 set transform-set ivdf3-1
 match address 102
 set pfs group5
access-list 101 permit ip 213.0.0.0 0.255.255.255 211.0.0.0 0.255.255.255
access-list 102 permit ip 213.0.0.0 0.255.255.255 212.0.0.0 0.255.255.255
!
interface HSSI1/0
 ip address 200.1.1.10 255.255.255.252
 encapsulation HDLC
 crypto map AS3VPN
interface HSSI2/0
 ip address 200.1.1.6 255.255.255.252
 encapsulation HDLC
 crypto map AS3VPN

Verifying Cisco IOS Site-to-Site IPsec VPN Operation

Now that we have configured a full mesh of IPsec VPN tunnels between AS#1, AS#2, and AS#3, we must take some basic precautionary measures to guarantee that the VPN is operating successfully:

Step 1. | Verify the establishment of ISAKMP SAs.
Step 2. | Verify the establishment of IPsec SAs.
Step 3. | Verify that basic network connectivity has been established over the VPN.
Step 4. | Verify that the Crypto Engine is actively participating in IPsec and that protected traffic is being encrypted and decrypted.
Step 5. | Check physical interface statistics for errors.

Examples 3-4 through 3-7 provide examples of these verification tasks on AS1-7304A in Figure 3-2. First, we verify that an ISAKMP SA has been successfully established. Example 3-4 confirms that there are indeed two ISAKMP SAs established to AS2-3745A and AS3-3745A. Note that these SAs are in "QM_IDLE" state, meaning that the ISAKMP SA is authenticated and can be used for subsequent Quick Mode (Phase 2) exchanges. The ISAKMP SA can exist in a number of other states. These states are described in Table 3-1 for ISAKMP SA negotiation in Main Mode.

Table 3-1. ISAKMP SA States for IKE Main Mode SA Negotiation

IKE SA State (Main Mode)

Description

MM_NO_STATE

The ISAKMP SA has been created, but nothing else has happened yet. It is "larval" at this stagethere is no state.

MM_SA_SETUP

The peers have agreed on parameters for the ISAKMP SA.

MM_KEY_EXCH

The peers have exchanged Diffie-Hellman public keys and have generated a shared secret. The ISAKMP SA remains unauthenticated.

MM_KEY_AUTH

The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to QM_IDLE, and a Quick Mode exchange begins.

Though the SA described in Example 3-4 was negotiated using Main Mode, Aggressive Mode could have been used instead. Table 3-2 presents the ISAKMP SA states and their descriptions for SAs negotiated with Aggressive Mode. Note that in Table 3-2, there are inherently fewer states described for Aggressive Mode, because Aggressive Mode involves fewer message exchanges than does Main Mode.

Table 3-2. ISAKMP SA States for IKE Aggressive Mode Negotiation

IKE SA State (Aggressive Mode)

Description

AG_NO_STATE

The ISAKMP SA has been created, but nothing else has happened yet. It is "larval" at this stagethere is no state.

AG_INIT_EXCH

The peers have done the first exchange in Aggressive Mode, but the SA is not authenticated.

AG_AUTH

The peers have done the first exchange in Aggressive Mode, but the SA is not authenticated.

Example 3-4. Verification of ISAKMP SAs for AS1-7304A

AS1-7304A#show crypto isakmp sa
dst             src             state         conn-id slot
200.1.1.10      200.1.1.9       QM_IDLE             2    0
200.1.1.1       200.1.1.2       QM_IDLE             1    0

After we can verify that Phase 1 SAs are established (by examining the output listed in Example 3-4), we are then ready to verify the establishment of IPsec SAs. Example 3-5 provides output needed to verify several important elements of Phase 2 SA establishment:

  • The IPsec VPN Peer Address for the SA (200.1.1.2 for AS1VPN process 10 and 200.1.1.10 for AS1VPN process 20).

  • The crypto-protected IPsec address sets specified in the Crypto ACLs for this SA (211.0.0.0/8->212.0.0.0/8 for AS1VPN process 10 and 211.0.0.0/8->213.0.0.0/8 for AS1VPN process 20).

  • Inbound SA information, including IPsec transform used, crypto map used, initialization value (IV), and replay information. Note that there are fields for ESP, PCP, and Authentication Header (AH)only the ESP fields are populated because there is no AH specified in the transform set for this IPsec SA.

  • Outbound SA information, including IPsec Transform used, crypto map used, IV, and replay information. Note that there are fields for ESP, PCP, and AHonly the ESP fields are populated as there is no AH specified in the transform set for this IPsec SA.

  • The peering encryption/decryption activity for this security association.

Note

These statistics will change to match the crypto engine statistics listed in Example 3-7 after traffic is sent across the tunnel in Example 3-6.

Example 3-5. Verification of IPsec SAs for AS1-7304A

AS1-7304A#show crypto IPsec sa

interface: HSSI1/0
  Crypto map tag: AS1VPN, local addr. 200.1.1.1
 protected vrf:
 local  ident (addr/mask/prot/port): (211.0.0.0/255.0.0.0/0/0)
 remote ident (addr/mask/prot/port): (212.0.0.0/255.0.0.0/0/0)
 current_peer: 200.1.1.2:500
  PERMIT, flags={origin_is_acl,}
 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
 #pkts compressed: 0, #pkts decompressed: 0
 #pkts not compressed: 0, #pkts compr. failed: 0
 #pkts not decompressed: 0, #pkts decompress failed: 0
 #send errors 1, #recv errors 0

 local crypto endpt.: 200.1.1.1, remote crypto endpt.: 200.1.1.2
 path mtu 1500, media mtu 1500
 current outbound spi: 770BFB0E
 inbound esp sas:
  spi: 0xBAB54AEB(3132443371)
  transform: esp-aes esp-sha-hmac ,
    in use settings ={Tunnel, }
    slot: 0, conn id: 2000, flow_id: 7, crypto map: AS1VPN

    crypto engine type: Software, engine_id: 1
    sa timing: remaining key lifetime (k/sec): (4439346/3318)
    ike_cookies: 3A2297BC 4BED61BF 7571B28B 40217AB8
    IV size: 16 bytes
    replay detection support: Y

inbound ah sas:

inbound pcp sas:
outbound esp sas:
spi: 0x770BFB0E(1997273870)
 transform: esp-aes esp-sha-hmac ,
 in use settings ={Tunnel, }
 slot: 0, conn id: 2001, flow_id: 8, crypto map: AS1VPN
 crypto engine type: Software, engine_id: 1
 sa timing: remaining key lifetime (k/sec): (4439347/3316)
 ike_cookies: 3A2297BC 4BED61BF 7571B28B 40217AB8
 IV size: 16 bytes
 replay detection support: Y

outbound ah sas:

outbound pcp sas:

interface: HSSI2/0
  Crypto map tag: AS1VPN, local addr. 200.1.1.9
 protected vrf:
 local ident (addr/mask/prot/port): (211.0.0.0/255.0.0.0/0/0)
 remote ident (addr/mask/prot/port): (213.0.0.0/255.0.0.0/0/0)
 current_peer: 200.1.1.10:500
  PERMIT, flags={origin_is_acl,}
  #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
  #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
  #pkts compressed: 0, #pkts decompressed: 0
  #pkts not compressed: 0, #pkts compr. failed: 0
  #pkts not decompressed: 0, #pkts decompress failed: 0
  #send errors 6, #recv errors 0

  local crypto endpt.: 200.1.1.9, remote crypto endpt.: 200.1.1.10
  path mtu 1500, media mtu 1500
  current outbound spi: E60B73DB
  inbound esp sas:
  spi: 0x1A397721(439973665)
    transform: esp-aes esp-sha-hmac ,
    in use settings ={Tunnel, }
    slot: 0, conn id: 2002, flow_id: 9, crypto map: AS1VPN
    crypto engine type: Software, engine_id: 1
    sa timing: remaining key lifetime (k/sec): (4594078/3450)
    ike_cookies: BB9827E5 847ADAE6 4ED69C6A 7546D684
    IV size: 16 bytes
    replay detection support: Y

  inbound ah sas:

  inbound pcp sas:
  outbound esp sas:
  spi: 0xE60B73DB(3859510235)
    transform: esp-aes esp-sha-hmac ,
    in use settings ={Tunnel, }
    slot: 0, conn id: 2003, flow_id: 10, crypto map: AS1VPN
    crypto engine type: Software, engine_id: 1
    sa timing: remaining key lifetime (k/sec): (4594079/3450)
    ike_cookies: BB9827E5 847ADAE6 4ED69C6A 7546D684
    IV size: 16 bytes
    replay detection support: Y

  outbound ah sas:

  outbound pcp sas:

In Example 3-6, we will attempt to send traffic across both IPsec VPN tunnels to the remote peers on AS2-3745A and AS3-3745A, respectively. First, we display the crypto-protected address spaces by displaying the ACLs referenced in the crypto map. Next, we send 100 ICMP echo requests to both peers. Note that in both cases, we drop the first ICMP packet during IKE and IPsec SA negotiation.

Example 3-6. Verification of Connectivity along the Crypto Path

AS1-7304A#show access-list 102
Extended IP access list 102
    10 permit ip host 201.1.1.1 host 202.1.1.1
AS1-7304A#show access-list 103
Extended IP access list 103
    10 permit ip host 201.1.1.1 host 203.1.1.1
AS1-7304A#ping
Protocol [ip]:
Target IP address: 202.1.1.1
Repeat count [5]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 201.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 202.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 201.1.1.1

.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (99/100), round-trip min/avg/max = 44/46/48 ms
AS1-7304A#ping
Protocol [ip]:
Target IP address: 203.1.1.1
Repeat count [5]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 201.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 203.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 201.1.1.1
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (99/100), round-trip min/avg/max = 44/46/52 ms

After we have successfully sent traffic to the remote crypto endpoints, we must then verify that it was successfully encrypted by the IPsec crypto engine. Example 3-7 provides the active IKE and IPsec SAs resident in the crypto engine for AS1-7304A. Note that the SAs with IDs 1 and 2 have not increased their packet count. This is expected, because these are the ISAKMP SAs (the same ones previously displayed in Example 3-4). Because IPsec SAs are unidirectional, we confirm that there are 4 SAs present in AS1-7304A's SADB:

  • SA ID #2000: Inbound SA to AS2-3745A

  • SA ID #2001: Outbound SA from AS2-3745A

  • SA ID #2002: Inbound SA from AS3-3745A

  • SA ID #2003: Outbound SA to AS3-3745A

We can confirm that the SA from AS1-7304A is actively encrypting echo requests to AS2-374A (99/100 corresponds to the success rate of Example 3-6) and that the SA received from AS2-3745A is actively decrypting the echo replies sent from AS2-3745A to AS1-7304A (also 99/100, corresponding to the success rate of Example 3-6). The same behavior is confirmed for the two SAs built between AS1-7304A and AS3-3745A (Example 3-7, SA ID #2002 and #2003).

Example 3-7. Crypto Engine Verification

AS1-7304A#show crypto engine connections active

ID Interface       IP-Address    State  Algorithm           Encrypt  Decrypt
   1 Se0/0.12      200.1.1.1     set    HMAC_SHA+3DES_56_C        0        0
   2 Se0/0.13      200.1.1.9     set    HMAC_SHA+3DES_56_C        0        0
2000 Se0/0.12      200.1.1.1     set    HMAC_SHA+AES_CBC          0       99
2001 Se0/0.12      200.1.1.1     set    HMAC_SHA+AES_CBC         99        0
2002 Se0/0.13      200.1.1.9     set    HMAC_SHA+AES_CBC          0       99
2003 Se0/0.13      200.1.1.9     set    HMAC_SHA+AES_CBC         99        0

Site-to-Site Architectural Overview over a Routed Domain

The design considerations of a site-to-site IPsec VPN change considerably once the underlying transit media changes. Consider the preceding site-to-site IPsec VPN examplehow would our design change if we were to replace the existing dedicated DS-3 links between ASs with DS-3 uplinks to an Internet service provider? Network designers face the challenge of dealing with multicast traffic in the crypto switching path.

Multicast traffic, including Interior Gateway Protocol (IGP) multicast hellos and multicast data feeds, cannot be sent natively across an IPsec VPN tunnel. Instead, the multicast data must be encapsulated with unicast header (such as IP generic routing encapsulation (GRE)) before being presented to the IPsec crypto engine.

Typically, these design considerations have encouraged the use of leased-line connectivity for VPN extension and the insertion of GRE tunnels through the IPsec tunnel (commonly referred to as IPsec+GRE) to accommodate the multicast traffic associated with the routing protocol updates and hellos. The need for enterprise connectivity extension across intermediate routed domains is growing rapidly. Two common enterprise IPsec deployments that are driving this growth are corporate extranet deployments and RAVPN deployments.

Consider the following example, in which a large automotive manufacturer wants to securely extend connectivity from its corporate headquarters network to a series of smaller home offices over an independently maintained routed domain, such as the Internet. The smaller branch offices consist of a number of routed nodes and, as such, would benefit from getting Route Processor (RP) updates from the campus network. Figure 3-3 demonstrates how the addition of a site-to-site IPsec VPN across the independently maintained routed domain would preclude the smaller home offices from exchanging RP updates with the campus network at the corporate HQ.

Figure 3-3. IPsec RAVPN Extension to Small Home Office over the Internet

[View full size image]

Due to IPsec's inability to natively encrypt multicast traffic, the design in Figure 3-3 presents the following design considerations:

  • When the branches recover from Integrated Services Digital Network (ISDN) failover, routing protocol updates to from Branch1 and Branch2 will not be encrypted. In this scenario, IGP updates are multicast based and will not be included in the crypto switching path.

  • Any changes that occur in Branch1 Net and Branch2 Net will trigger RP update information to the corporate HQ. These updates will be sent in the clear.

  • Any changes within the "HQ Campus Net" will trigger RP updates to the branches that will be sent in the clear.

The solution to these design considerations is to add GRE tunnels to the IPsec VPN implementation. RP traffic between the corporate HQ and branch networks will then be encapsulated with GRE headers and forwarded in the crypto switching path across the ISP network. We will discuss IPsec+GRE architectures in greater detail later in this chapter.

Consider the following example, in which a corporation, a large global financial organization, wants to allow extranet connectivity to its partners. The primary use of this extranet connection is to stream multicast data containing video and market information to decision makers within the global financial organization. This must be done securely and with confidentiality. The insertion of an independently maintained routed domain between the corporate extranet partner and the global financial organization breaks the multicast tree between the two parties, as illustrated in Figure 3-4.

Figure 3-4. Corporate Extranet Connection Using Internet Uplinks and IPsec VPNs

[View full size image]

The extranet model breaks multicast in two areas. First, underlying media is not configured to support peripheral interface manager (PIM) or multicast routing. Therefore, even without IPsec, the multicast tree would never form properly with this deployment. Second, assuming that the multicast tree could be established, IPsec would fail to send multicast flow in ciphered format. Again, the addition of GRE to the corporate extranet would allow extension of PIM traffic across the Internet. Additionally, because the PIM updates are encapsulated in GRE prior to encryption, the PIM packets encapsulated in GRE would be processed in the crypto switching path and forwarded securely across the IPsec VPN.

Tip

The Cisco V3PN solution outlines a VPN architecture that accommodates voice and video over IPsec. Because IP multicast is a key component of many voice and video streaming technologies, V3PN requires the use of IPsec+GRE. For more information on V3PN, please refer to the following documentation on CCO

http://www.cisco.com/en/US/partner/netsol/ns340/ns394/ns171/ns241/networking_solutions_sub_solution_home.html


Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE)

At the core of IPsec is point-to-point functionality, which is not suited for all of today's IP communications. Indeed, many of today's voice and video applications require point-tomultipoint connectivity. As such, they leverage IP multicast techniques to selectively flood data to interested parties. Traditionally, IP multicast traffic has not effectively been passed through the crypto switching path on IPsec routers. As we have discussed, this precludes users from encrypting multicast applications such as multicast voice (hoot-n-holler), multicast video (IPTV), and routing protocols (OSPF, ISIS, RIP, EIGRP). The current solution for accommodating these types of traffic in cipher-text is IPsec+GRE.

Site-to-Site IPsec+GRE Architectural Overview

The IPsec+GRE model is used most commonly when there are traffic types that require confidentiality which are not traditionally suited for IPsec point-to-point traffic. IP multicast-based applications, such as routing protocols that use multicast updates and multicast applications for streaming voice and video over IP, would fall in to this category. Through the use of GRE, these multicast traffic types can be represented (encapsulated with a unicast GRE header) in a format acceptable to the IPsec crypto engine. Figure 3-5 illustrates the process of encrypting a multicast data feed with IPsec+GRE. Note that the original IP multicast header will not present an IP packet format acceptable for IPsec direct encapsulation. Because of this, GRE is used to encapsulate the multicast header and payload with a unicast header, resulting in a packet that can then be encapsulated with either ESP or AH. The GRE header and original IP multicast header will be encrypted as they are both part of the ESP-protected payload.

Figure 3-5. Multicast Packet GRE Encapsulation (IP Multicast Encapsulated GRE Encapsulated in ESP)

[View full size image]

Although IPsec+GRE does provide a wider scope of confidentiality when applying the ESP encapsulation, and enables confidentiality for additional IP applications, increased maximum transmission unit (MTU) sizes of encapsulated packets become an increased design concern.

Increased Packet Size and Path MTU Considerations

Packets continue to get larger and larger as continuous layers of encapsulation are added to the original IP payload. For example, an IP-encapsulated RTP packet for voice of 64 bytes in length grows to approximately 128 bytes after it is encapsulated in RTP (12 bytes), UDP (8 bytes), IP (20 bytes), and GRE (24 bytes), and to 184 bytes after the GRE-encapsulated RTP packet is encapsulated again with an ESP header, padding and authentication fields, and trailer (subtotal of approximately 56 bytes). Increasing packet sizes in this fashion also increases the chances that the packet will be fragmented after it has been encrypted, as would be the case if the encrypted packet exceeds the MTU of a link somewhere in the path between the two VPN endpoints. This can cause problems on the decrypting router, which will attempt to decrypt the fragmented packets in the process switching path (without hardware assist), causing scalability issues in terms of performance. Path MTU discovery can be deployed in conjunction with the Cisco IOS IPsec prefragmentation, enabling the encrypting router to dynamically determine the smallest MTU of the path between VPN endpoints. The encrypting VPN router is then capable of fragmenting to the appropriate MTU for the path on a per-SA basis using IPsec prefragmentation, assuring that the fragmentation of IPsec packets always occurs prior to encryption and is therefore done in the fast path.

Note

Common fragmentation issues in IPsec VPNs are discussed in detail in Chapter 4, "Common IPsec VPN Issues." Available solutions for fragmenting prior to encryption, including path MTU discovery and IPsec prefragmentation, are also discussed in Chapter 4.

GRE and Weighted Fair Queuing

Some quality of service (QoS) techniques, such as weighted fair queuing (WFQ), perform conversation hashing decisions based on the original source and destination IP address, which can be ubiquified after IPsec or GRE encapsulation. While DiffServ markings are copied to the outer IP header in tunnel mode IPsec, the original source and destination are not carried forward into outer IP header. In order to appropriately execute hashing decisions in WFQ operations, packets must therefore be classified prior to encapsulation. Cisco IOS supports IPsec QoS pre-classify functionality on IOS VPN endpoints to assure that flow and conversation-based queuing decisions can be executed accurately in IPsec VPN environments.

QoS and the IPsec Anti-Replay Window

Altering the scheduling of packets before IPsec processing (as is the case with QoS pre-classify) conflicts with sequencing schemes native to IPsec that are used for anti-replay protection. Cisco IOS offers IPsec QoS Pre-Classify, which allows packets to be queued prior to ESP, AH, or GRE encapsulation. Alternatively, anti-replay windows can be increased to ensure that IPsec packets are received within the anti-replay window even when reordered and delayed due to queuing decisions on nodes between IPsec VPN endpoints. When deploying QoS in vendor-diverse environments, it is recommended that the operation be monitored to ensure that packet reordering does not conflict with anti-replay functions native to IPsec.

Site-to-Site IPsec+GRE Sample Configurations

Thus far, we have introduced the requirement of unicast presentation of data flows to the IPsec crypto engine. In this section, we will discuss working IPsec+GRE configuration procedures, examples, and verification techniques to use when encapsulating multicast traffic with a unicast header so that it can be processed with encrypted with IPsec.

Cisco IOS Site-to-Site IPsec+GRE Configuration

We will now alter the configurations that we built in Examples 3-1 through 3-3 to include GRE encapsulation prior to the encapsulation of ESP. The IPsec transform and ISAKMP polices will remain consistent with Examples 3-1 through 3-3, as will the some of the crypto map configuration elements, such as the PFS and peering configurations. However, other crypto map configuration elements, such as the crypto ACLs, will change to accommodate GRE traffic. We will also demonstrate IOS QoS for IPsec VPNs by configuring the routers to classify packets prior to GRE encapsulation and crypto processing. The topology used for these configurations is depicted in Figure 3-2, but instead of native IPsec ESP tunnels, the ESP-encapsulated point-to-point GRE tunnels are used between the edge routers of AS#1, AS#2, and AS#3.

Example 3-8 illustrates some of the configuration changes made to AS1-7304A to accommodate IPsec+GRE. One of the most important differences in this configuration compared to Example 3-1 is the change in the crypto ACLs. Note that in Example 3-8, the crypto ACLs protect GRE traffic from the GRE tunnel source and destination address from AS1-7304A to AS2-3745A and AS3-3745A, respectively. This will effectively encrypt all traffic passing over the GRE tunnels from AS1-7304A to AS2-3745A and AS3-3745A.

In addition to the crypto ACL change on ASS1-7304A, several measures are taken to guarantee that encrypted packets are not fragmented. AS1-7304A's crypto engine will attempt to fragment packets to the path MTU (discovered through path MTU discovery between the two VPN endpoints) of the appropriate SA in the SADB. Additionally, AS1-7304A is configured to set the DF bit in the outer IP header of the encrypted fragments, effectively ensuring that network nodes between the two crypto endpoints are not able to fragment encrypted messages while in transit.

Example 3-8. Site-to-Site VPN Configuration on AS1-7301A

AS1-7304A#show run
!
crypto df-bit set
!
crypto ipsec fragmentation before-encryption
!
!
access-list 101 permit gre host 201.1.1.1 host 202.1.1.1
access-list 102 permit gre host 201.1.1.1 host 203.1.1.1
!
interface Tunnel12
 ip address 200.1.12.1 255.255.255.252
 qos pre-classify
 tunnel source 201.1.1.1
 tunnel destination 202.1.1.1
!
interface Tunnel13
 ip address 200.1.13.1 255.255.255.252
 qos pre-classify
 tunnel source 201.1.1.1
 tunnel destination 203.1.1.1
!
interface Loopback1
 ip address 201.1.1.1 255.255.255.255
!

Example 3-9 provides the IPsec+GRE configuration for the IPsec VPN gateway for AS2. Like AS1-7304A, AS2-3745A is configured to protect all GRE-encapsulated data from a local GRE tunnel source to the appropriate GRE tunnel endpoints on AS1-7304A and AS3-3745A. AS2-3745A also is configured to prevent fragmentation after encryption and to classify packets with QoS prior to encryption.

Example 3-9. Site-to-Site VPN Configuration on AS2-3745A

AS2-3745A#show run
!
crypto df-bit set
!
crypto ipsec fragmentation before-encryption
!
!
access-list 101 permit gre host 202.1.1.1 host 201.1.1.1
access-list 102 permit gre host 202.1.1.1 host 203.1.1.1
!
interface Tunnel12
 ip address 200.1.12.2 255.255.255.252
 qos pre-classify
 tunnel source 202.1.1.1
 tunnel destination 201.1.1.1
!
interface Tunnel23
 ip address 200.1.23.1 255.255.255.252
 qos pre-classify
 tunnel source 202.1.1.1
tunnel destination 203.1.1.1
!
interface Loopback1
 ip address 202.1.1.1 255.255.255.255
!

Example 3-10 provides the IPsec+GRE configuration for the IPsec VPN gateway for AS3. Like AS1-7304A, AS3-3745A is configured to protect all GRE-encapsulated data from a local GRE tunnel source to the appropriate GRE tunnel endpoints on AS1-7304A and AS2-3745A. AS3-3745A also is configured to prevent fragmentation after encryption and to classify packets with QoS prior to encryption.

Example 3-10. Site-to-Site VPN Configuration on AS3-3745A

AS3-3745A#show run
!
crypto df-bit set
!
crypto ipsec fragmentation before-encryption
!
!
access-list 101 permit gre host 203.1.1.1 host 201.1.1.1
access-list 102 permit gre host 203.1.1.1 host 202.1.1.1
!
interface Tunnel13
 ip address 200.1.13.2 255.255.255.252
 qos pre-classify
 tunnel source 203.1.1.1
 tunnel destination 201.1.1.1
!
interface Tunnel23
 ip address 200.1.23.2 255.255.255.252
 qos pre-classify
 tunnel source 203.1.1.1
 tunnel destination 202.1.1.1
!
interface Loopback1
 ip address 203.1.1.1 255.255.255.255
!

Verification of IPsec+GRE Tunnel Establishment

Verifying an IPsec+GRE tunnel begins with the same steps that are taken in the verification of a standard IPsec tunnel. Verification of ISAKMP and IPsec SAs must be done, and basic connectivity through the GRE tunnel must be established. However, when GRE is added to the VPN, steps must be taken to verify tunneled connectivity prior to the addition of IPsec:

  • Verification of tunnel establishment

  • Verification of RP (including PIM) adjacencies through the tunnel

Once these basic tunneling operations have been verified, they must be re-verified after the addition of IPsec. In addition to that re-verification, the administrator should also verify the establishment of ISAKMP SA, IPsec SA, and that traffic passed over the IPsec+GRE tunnel is actually being encrypted, as we explored in Examples 3-4 through 3-7. Example 3-8 demonstrates the non-crypto GRE verification steps on AS1-7304A (prior to the addition of the crypto map to the physical interface) and the verification of the full IPsec+GRE tunnel (after the crypto map has been applied to the physical interface). Again, note that all EIGRP traffic is kept confidential from the OSPF core via IPsec processing of all GRE traffic (which in this case includes all EIGRP traffic192.168.x.x/16 address space) between endpoints. Example 3-11 illustrates several typical diagnostic steps needed to verify the establishment of a GRE tunnel and of RP adjacencies using that GRE tunnel, including:

  • Verify GRE tunnel establishment and interface status.

  • Verify basic connectivity through the GRE tunnel.

  • Verify RP adjacencies across the GRE tunnel.

Example 3-11. Verification of GRE Tunnels and Tunneled Routing Protocols on AS1-7304A

AS1-7304A#show ip int brief
Interface             IP-Address      OK? Method Status                Protocol
FastEthernet0/0       unassigned      YES NVRAM  administratively down down
Serial0/0             unassigned      YES NVRAM  up                    up
Serial0/0.12          200.1.1.1       YES manual up                    up
Serial0/0.13          200.1.1.9       YES manual up                    up
Loopback0             201.1.1.1       YES manual up                    up
Loopback1             192.168.1.1     YES manual up                    up
Tunnel12              192.168.12.1    YES manual up                    up
Tunnel13              192.168.13.1    YES manual up                    up
AS1-7304A#ping 192.168.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/34/36 ms
AS1-7304A#ping 192.168.13.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.13.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/34/36 ms
AS1-7304A#show ip eigrp interfaces
IP-EIGRP interfaces for process 192

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Lo1                0        0/0         0       0/10           0           0
Tu12               1        0/0       736      71/2702      6362           0
Tu13               1        0/0       277      71/2702      3710           0
AS1-7304A#sh ip eigrp neighbors
IP-EIGRP neighbors for process 192
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   192.168.13.2            Tu13              12 00:18:36  277  5000  0  41
0   192.168.12.2            Tu12              12 00:19:01  736  5000  0  48

After we have verified the basic operation of the routing protocol adjacencies and updates over the GRE tunnels, we are ready to verify that the crypto engine is processing the GRE tunnel through which subsequent control and data plane traffic will traverse. The diagnostic output in Example 3-12 verifies that protected traffic (in this case all GRE traffic) is being processed by the crypto engine. This output reflects statistics after 100 pings are forwarded across each GRE (and subsequently IPsec) tunnel. Note that there are more than 100 packets processed by the crypto enginethese extra packets are GRE-tunneled packets using various control plan traffic including RP updates and adjacency maintenance.

Example 3-12. Verification of Crypto-Processed Traffic after Crypto Maps Have Been Applied to Physical Interfaces That Will Protect All GRE Traffic Between the Two GRE Tunnel Endpoints

AS1-7304A#sh crypto engine conn active

  ID Interface       IP-Address      State  Algorithm          Encrypt  Decrypt
   1 Se0/0.12        200.1.1.1       set    HMAC_SHA+3DES_56_C       0        0
   2 Se0/0.13        200.1.1.9       set    HMAC_SHA+3DES_56_C       0        0
2002 Se0/0.13        200.1.1.9       set    HMAC_SHA+AES_CBC         0      145
2003 Se0/0.13        200.1.1.9       set    HMAC_SHA+AES_CBC       146        0
2004 Se0/0.12        200.1.1.1       set    HMAC_SHA+AES_CBC         0      139
2005 Se0/0.12        200.1.1.1       set    HMAC_SHA+AES_CBC       139        0

Tip

It is recommended that the administrator re-verify the steps taken in Example 3-11 to confirm the operation of GRE and RPs after the crypto map has been added. It is further recommended that the administrator verify the cryptographic elements added to the GRE tunnel using the techniques outlined in our discussion of site-to-site VPNs in Examples 3-4 through 3-7.


Hub-and-Spoke IPsec VPN Deployments

Most of today's enterprise class IPsec VPN deployments incorporate hub-and-spoke IPsec designs. These designs extend from the principles that we have discussed previously in this chapter, whether the situation describes the aggregation of native spoke IPsec VPNs at a hub IPsec aggregation point or the aggregation of IPsec+GRE VPNs at a hub IPsec and GRE concentrator. As the number of spoke connections increases, so do the number of design considerations surrounding the hub IPsec router. These include the following:

  • SA Scalability The number of security associations actively supported and dangling SA detection, elimination, and management capabilities. This is less of a concern on spokes as they will only maintain SAs relevant to hub connectivity. Hub SA maintenance becomes an issue, as it must maintain an SADB comprehensive of all spoke VPN connectivity.

  • IPsec Tunnel Capacity In addition to the number of SAs that the endpoint's memory can accommodate, one must pay careful attention to the security policy of the tunnel itself and the impact on the CPU that this policy has. Selection of the strongest cryptographic suites comes with a cost of increased computational burden. IPsec VPN design at a hub router that concentrates IPsec VPNs with strong security policies must be sized to accommodate the computational overhead required for tunnel maintenance of the appropriate anticipated scale.

  • Crypto Path Switching Capacity The throughput, in packets per second (pps), of the traffic that is processed in the router's crypto (IPsec) switching path must also be considered. Or, if GRE is used, we must look at the throughput in (pps) of the GRE+IPsec switching path.

  • GRE Tunnel Maintenance Capacity Although most routers will support GRE encapsulation, they do not necessarily do it in the fast switching path (in hardware). When selecting a hub router that will be concentrating GRE tunnels, care must be taken to ensure that extensive GRE encapsulation and decapsulation does not limit throughput or overburden the hub's CPU.

  • Fragmentation Capabilities Because each spoke router in the network discovers the MTU en route to its destination, the amount of fragmented packets can potentially increase at IPsec aggregation points. Hub IPsec aggregation/concentration devices must be specified appropriately so as to handle potentially large amounts of fragmented packets sent from adjacent spoke IPsec peer endpoints.

Additionally, the urgency for HA at the hub router increases dramatically as additional spokes are reliant on the hub for connectivity to the enterprise's centrally located resources.

Note

This section on hub-and-spoke architecture only discusses HA items directly relevant to the physical layout of the IPsec VPNs themselves. IPsec HA design optimization in IOS, ASA, and VPN3K appliances is discussed comprehensively in Chapters 6 through 10.

Hub-and-Spoke Architectural Overview

In this section, we will explore three common layouts for hub-and-spoke IPsec VPNs. The huband-spoke IPsec VPN model is one of the most commonly used and widely varied topologies in the IPsec VPN world today. Though the three models outlined in Figure 3-6 do not touch on all of these variations, we will use these three topologies as a framework for reviewing architectural considerations that are most commonly present in today's hub-and-spoke IPsec VPN designs.

Figure 3-6. Hub-and-Spoke IPsec VPN Variations

[View full size image]

Standard Hub-and-Spoke Design without High Availability

The simplest hub-and-spoke design consists of single-circuit, single-spoke connectivity to a hub router at a central facility, as described in the first design of Figure 3-6. This design, while simple from an architectural standpoint, does not allow much in the way of HA design enhancements, because this design is typically found in branch deployments that do not require high degrees of network uptime.

From a performance perspective, the design considerations are focused largely on the hub. Because the spoke devices are maintaining minimal IPsec VPN tunnels and GRE tunnels, the IPsec and GRE performance is likely to be at the platform maximum when stressed. This is not the case for the hub router, which is responsible for SA and GRE maintenance to all of the spoke routers. This poses several design issues that must be addressed at the hub:

  • SADB Scalability The hub router must have the appropriate amount of memory to accommodate the SADB for the whole hub/spoke deployment. Remember from our previous discussions in Chapter 2, "IPsec Fundamentals," that the number of IPsec SAs needed will be the twice the number of IPsec connections plus one SA for each IKE channel.

  • Switching Capacity for IPsec Aggregation The hub router must have the appropriate amount of switching capacity (in pps) to support the performance requirements in the IPsec+GRE switching path.

  • Excessive Encrypt/Decrypt Action for Spoke-Spoke Traffic For spoke-spoke connectivity, the hub router will be decrypting traffic from the sending spoke and re-encrypting it before sending it to the destination spoke. For networks that have a substantial amount of spoke-spoke traffic, the hub router that has enough processing power to support substantial amounts of decrypt/re-encrypt behavior must be selected.

    Tip

    Cisco IOS offers Dynamic Multipoint VPN (DMVPN) features that support the dynamic, direct establishment of spoke-to-spoke SAs in hub-and-spoke deployments. When deployed effectively, this solution can dramatically improve the performance of hub-and-spoke IPsec VPN deployments because IPsec processing is partially transitioned from the hub router to the spokes themselves. DMVPN is discussed in greater detail in Chapter 8, "Handling Vendor Interoperability with High Availability."

  • Multicast Fanout In this design, the hub router is performing the multicast fanout for traffic to all of the spoke routers that are subscribed to the multicast group. For traffic profiles that have substantial amounts of multicast traffic, the hub router must be capable of accommodating the appropriate amount of packet duplication, the encapsulation of those fanned-out packets in GRE, and the increased amount of IPsec processing that is required as those fanned-out packets are processed by the crypto engine.

Clustered Spoke Design to Redundant Hubs

The second design in Figure 3-6 describes the addition of two hub IPsec aggregation points into the design. This allows network designers to deploy redundancy in the spoke uplinks to the hub routers. It also allows network designers to address the design concerns raised in the first design of Figure 3-6. Deploying redundancy at the hub location of the IPsec hub-and-spoke network presents some key design advantages, including, but not limited to, the following:

  • Increased Tunnel Termination/Maintenance Capacity Using multiple hub routers decreases the amount of memory required for SA maintenance on a per-platform basis, because the SAs are spread across three aggregation points (as opposed being concentrated on only one). The distribution of hub processing capabilities also eases the computational burden in terms of IPsec VPN termination, GRE tunnel termination, and the decryption/re-encryption overhead of spoke-to-spoke communication discussed previously.

  • Increased Multicast Fanout Capacity Distributed Hub IPsec processing also presents two additional multicast fanout points to the design. This type of distribution at the multicast fanout points can dramatically improve the switching performance of the hub-and-spoke deployment, because computational resources for copying multicast packets, encapsulating them in GRE, and encrypting them are tripled at the aggregation points.

  • Load Balancing and Redundancy In addition to the redundancy provided to the spokes by the two redundant uplinks to their corresponding aggregation points, the correct deployment of redundant circuits allows for a primitive form of load balancing across the three aggregation pointsHubs A, B, and C. Each spoke terminates its primary uplinks on different hubs so that in a nonfailover scenario IPsec VPNs are distributed evenly across the three aggregation points. Each spoke's backup links are distributed in the same fashion, so as to provide the same load-balancing effect when there is a failover scenario at the spoke.

Redundant Clustered Spoke Design to Redundant Hubs

Design #3 in Figure 3-6 describes a topology similar to Design #2, but with redundant routers at the spoke. This is the most highlyavailable design discussed in this chapter, and it will lead us in to design concepts discussed in Chapters 6 10. It is also the most expensive of the three designs to deploy, as it doubles the amount of hardware to be purchased at the spoke level.

With respect to the design of the IPsec VPNs themselves, the addition of redundant spoke routers could boost performance of the IPsec VPN, especially if both IPsec tunnels were concurrently active and traffic from the spoke is load-balanced across the two redundant spoke routers. These benefits, however, although useful, are only local to the spoke itself, which is why it is more common to invest in redundancy and load-balancing improvements at the hub before adding it to the spokes. Additionally, large-scale deployment of redundant spoke routers will require more processing capability to accommodate increased IKE processing, or increased SADB capacity if a "hot" standby model is required (see Chapters 6 10 for design concepts surrounding IPsec HA in IOS).

Because of this, the primary benefit of adding an additional, redundant, router to a spoke in the greater hub/spoke design is redundancy at that particular branch. For this reason, it is most common to see only highly-available branches pursue this design, while other spokes are deployed using the framework we have discussed in Designs #1 or #2. The cost-benefit analysis of pursuing redundant uplinks and redundant routers at the spoke must be weighed carefully against the cost (both computational and monetary) of deployment. It is rare to see blanket rollouts of Designs #1, #2, or #3 shown in Figure 3-6. Instead, it is much more common to see designs that incorporate elements of all three designs on a per-spoke performance and HA-requirementbasis.


Remote Access VPN Deployments

As workforces become increasingly mobile in nature, this changes the dynamics of a secure IP network. Remote Access VPN deployments have become the central focus of secure connectivity in enterprise mobility, allowing secure Layer 3 communications to any VPN endpoint that has an internet connection to the appropriate VPN concentrator. We've discussed some of the business drivers for enterprise adoption of RAVPN deployments during our introduction to VPNs in Chapter 1. Now we will explore some common architectures for delivering RAVPN services to the enterprise.

Note

Cisco Systems Business Ready Teleworker Solutions fully outlines the business justification for RAVPN deployments. Please refer to the following resources on CCO for more information on Cisco Business Ready Teleworker Solutions:

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns241/c649/ccmigration_09186a00801ea79d.pdf

RAVPN Architectural Overview

As we discussed in Chapter 1, "Introduction to VPN Technologies," the two core elements that comprise an RAVPN topology are VPN concentrators and VPN clients. These two elements communicate with one another over a predefined media at Layer 3 of the OSI Model. As such, these two entities can be connected over any media that will support Layer 3 between concentrator and client, including dial-up networks, Internet connections using DSL, and 802.11 wireless media. Because the underlying communications are relatively independent on the IPsec portion of the RAVPN, we will discuss clients and concentrators communicating with one another over a ubiquitous Internet connection, and will discuss RAVPN design in greater detail in Chapter 10, "Further Architectural Options for IPsec."

RAVPN Clients

RAVPN clients typically come in two general flavors, hardware-based clients and software-based clients. Software-based VPN clients run locally on the user's remote workstation or laptop, and they are used to connect to a centrally managed VPN concentrator, typically located on the enterprise campus. The strength of software-based VPN clients is rooted in the mobility that they provide. When deployed on a user's laptop, a software-based VPN client can securely extend confidential communications from the campus to anywhere that a VPN client can access Layer 3 communications. Software-based VPN clients are therefore useful for tunneling data from centrally located campus resources to the end user. However, they do have limitations, and because of these limitations, the use of hardware-based VPN clients is merited in some situations. Specifically, software-based VPN clients terminate VPN connectivity locally on teleworkers' laptops and do not allow for the secure networking of other Layer 3 devices at the remote end of the VPN (such as a hardware-based IP Phone) over that VPN. Additionally, software-based clients will not support the termination of GRE locally, and therefore they will not typically support multicast data flows. Hardware-based clients, though inherently less mobile, address many of the functional limitations found in software-based IPsec VPN clients.

Hardware-based VPN clients are typically found in small, remote locations that do not have dedicated connectivity to a central hub IPsec router. These devices are commonly found at home offices that have DSL- or cable-modem connectivity to the Internet. The hardware-based VPN client maintains the IPsec VPN (and GRE tunnel termination) to the concentrator, while allowing cleartext IP communications locally within the small home office or branch. Therefore, hardware-based VPN components add a networked element to the SOHO (small office, home office) or small branch environment that allows users to extend voice, video, and data securely from the campus.

In order to deliver both mobility and breadth of services to remote teleworkers, it is very common to see users deploy both software-based VPN clients and hardware-based VPN clients at the same time. Having the hardware-based VPN connectivity extends virtually all IP services available on the campus to relatively fixed remote locations. Software-based VPN communications allows users to extend communications in highly mobile scenarios. All of these services must be accommodated on the concentrator side of the VPN. For this reason, the variation in RAVPN topology is most commonly seen at the concentrator end of the design, which is what we will focus the remainder of this chapter's RAVPN discussion on.

Standalone VPN Concentrator Designs

Due to the nature of IPsec and firewalls, the placement of the VPN concentrator in a DMZ design is critical to the success of the greater RAVPN architecture. Figures 3-7 through 3-10 outline several DMZ topologies that we will use to explore common design issues which must be addressed in RAVPN design. Each of these designs pertains to an IPsec VPN concentrator deployment for effective termination of client IPsec VPN tunnels in an RAVPN environment.

Figure 3-7. VPN Concentrator Placement in Single-DMZ Design

VPN Concentrator on Outside Network with Single DMZ

The DMZ layout illustrated in Figure 3-7 is one of the most common, and most effective, designs in RAVPN/DMZ integration. This design allows for increased security, because inside traffic from the VPN concentrator is firewalled from the firewall's DMZ interface to its inside interface.

Also, the firewall can add an additional layer of proxy authentication AAA authentication in conjunction with an ACS server located on the inside network, offering a comprehensive authentication, authorization, and accounting solution for traffic types all the way up to Layer 7. The processing of traffic inbound from the DMZ can be further inspected for network attacks using either the PIX IOS-based signature set or a compatible, more comprehensive, signature set maintained on an external Network Intrusion Detection Systems (NIDS) appliance.

As we will also see with the design in Figure 3-8, there are no IPsec-specific modifications that need to be added to the firewall ACL configuration. Likewise, there are no additional Network Address Translation (NAT) considerations to account for on the firewall. This design does, however, require marginally increased filtering capability on the firewall, as cleartext traffic from the IPsec VPN concentrator is now being processed on the DMZ interface on its way to the inside network.

Figure 3-8. Parallel VPN Concentrator and Firewall DMZ Design

VPN Concentrator and Firewall in Parallel

Placing the VPN concentrator in parallel with the firewall eliminates the possibility of human error when opening up holes in the firewall ACL to allow IPsec traffic from inbound VPN clients to the concentrator (as with the design illustrated in Figure 3-10). Figure 3-8 provides an illustration of a standard DMZ design that places the VPN concentrator in parallel with the firewall.

Additionally, this topology presents no computational overhead on the firewall for processing IPsec traffic in to the VPN concentrator. Instead, that traffic is focused solely on the VPN concentrator. Likewise, the concentrator is not burdened by non-VPN traffic, as would be the case if the concentrator were placed in series with the firewall on the outside network.

The parallel configuration described in the design of Figure 3-8 also simplifies the NAT configuration on both the firewall and the DMZ. Although IPsec itself can accommodate environments where addresses are being translated, this topology eliminates the NAT processing of VPN traffic firewall and concentrator. Therefore, for RAVPN IPsec tunnels, the need for vendor-specific IPsec extensions such as NAT-T (IPsec NAT Transparency) is avoided.

Note

NAT can cause implementation issues in IPsec networks if not properly designed for. For more information concerning common issues related to NAT in IPsec networks, please refer to Chapter 4, "Common IPsec VPN Issues." Solutions for IPsec in NAT environments, such as IPsec NAT-T, are also discussed in Chapter 4.

VPN Concentrator with Dual DMZs to Firewall

Using two DMZ interfaces for inside and outside VPN traffic, as described in the design shown in Figure 3-9, can also be an effective means by which to integrate a VPN concentrator into a DMZ. This design should be deployed when increased protection of the VPN concentrator itself is desired. Designs similar to this one are also commonly found when the enterprise does not have control over the Internet gateway directly outside of the DMZ, as would be the case when the enterprise contracts with a service provider that wishes to maintain the Internet gateway itself. In such a case, the enterprise would rely on the firewall, as opposed to the Internet gateway, to switch packets to the appropriate directly connected interface. As a result, it would be the firewall's responsibility to forward VPN traffic directly connected to DMZ1 interface and allowed NAT'd (if necessary) enterprise traffic directly to the inside interface.

Figure 3-9. VPN Concentrator with Dual DMZs to Firewall

Figure 3-10. What to Avoid in DMZ/VPN Concentrator Topologies

Locating the VPN concentrator's outside interface behind the DMZ inserts a layer of filtering and authentication of IPsec traffic before the concentrator, thereby adding another layer of hardening to the design. There are also tradeoffs to the design, because the outside ACL of the firewall must be altered to allow ISAKMP, ESP, and AH traffic through to the concentrator. In addition to punching holes through the ACL to accommodate VPN traffic, this design also increases the computation overhead associated with VPN traffic on the firewall, because traffic is processed twice (once on the outside interface, and again as traffic is received from the concentrator on the second DMZ interface).

What to Avoid in DMZ/VPN Concentrator Topologies

We will use the design shown in Figure 3-10 to highlight a few things to avoid when positioning a VPN concentrator in a DMZ. The fourth design places the concentrator in a position that requires VPN traffic to be processed serially between the firewall and concentrator with little additional value. Although the concentrator is located in a more secure environment (Location A), the concentrator can be secured just as effectively by placing it in the DMZ. Additionally, when placing the concentrator in the DMZ, traffic can be sent directly from the outside interface to the concentrator itself without NAT. Alternatively, the location in this design will likely require NAT, leading to a more complicated firewall configuration and increased processing overhead.

Locating the VPN concentrator serially outside of the firewall (moving the concentrator from Location A to Location B, as shown in Example 3-10) can have an equally adverse effect. This type of design requires that all traffic be processed by the concentrator, as opposed to just the VPN traffic, leading to increased overhead. While this alteration eliminates the need to NAT inbound VPN traffic, it does place the concentrator in a relatively unsecured location, presenting the opportunity for denial of service (DoS) attacks for all network traffic destined to the enterprise (single point of failure).

Clustered VPN Concentrator Designs

The RAVPN designs we have discussed thus far only assume the use of a single VPN concentrator. However, all of these designs can be hardened further through the deployment of multiple concentrators in the appropriate location, commonly referred to as "clustering." The deployment of a VPN cluster offers redundancy locally at the concentrator level, and it also allows for increased scalability in terms of the number of inbound IPsec VPN tunnels from VPN clients that the design can support. Figure 3-11 illustrates a typical clustered IPsec VPN concentrator deployment in a DMZ design.

Figure 3-11. Clustered RAVPN Concentrator Deployment

The clustered design presented in Figure 3-11 is a variation on the recommended RAVPN/DMZ shown in Figure 3-7. The altered design allows for triple redundancy relative to the original design, and it also allows the design to scale up to three times the amount of VPN tunnels during peak traffic hours for the remote access to central enterprise resources. We will discuss this design and several other effective designs for RAVPN High Availability in Chapter 9, "Solutions for Remote Access VPN High Availability."


Summary

In this chapter, we have discussed several prevalent IPsec VPN topologies, including the following:

  • Site-to-site IPsec VPNs

  • Site-to-site IPsec+GRE VPNs

  • Hub-and-spoke IPsec VPN topologies

  • Remote access VPN topologies

At this point, you should be familiar with the basic layout of the preceding topologies, because they will serve as the basis for the explanation of more advanced concepts, such as local and geographic site-to-site IPsec HA and Remote Access VPN HA. Each of the preceding topologies is loosely grouped into a given design category, but you should be familiar with the design variants of each. For example, two important variations on a simple site-to-site IPsec topology are site-to-site IPsec VPN over a dedicated circuit and site-to-site IPsec VPN over a routed domain. The introduction of a routing protocol between the two crypto endpoints provides a material alteration to the VPN topology.

As with site-to-site IPsec VPN design variations, we have also covered several variations of huband-spoke IPsec VPN deployments, including the following:

  • Standard hub-and spoke design (no hub redundancy)

  • Clustered hub-and-spoke design to redundant hubs

  • Clustered hub-and-spoke design to redundant hubs with redundant spokes

Our discussion in this chapter of the basic advantages to each of the preceding hub-and-spoke variations will provide useful context when discussing resilient IPsec VPN design strategies in future chapters.

Finally, we have introduced several common DMZ designs with various IPsec VPN concentrator placement alternatives. These design alternatives included the following:

  • Standalone VPN concentrator DMZ design

  • Parallel VPN concentrator and firewall DMZ design

  • Dual DMZ VPN concentrator design

  • Serial VPN concentrator placement on inside firewall interface

At this point, you should have a basic familiarity with VPN concentrator placement in a firewalled DMZ design, as well as a basic understanding of the dangers of placing IPsec VPN concentrators serially inside a firewalled domain. We raised the advantages and disadvantages of each design in preparation for discussing remote access VPN HA concepts in Chapter 9," Solutions for Remote Access VPN High Availability."


Chapter 4. Common IPsec VPN Issues

In this chapter, we will discuss several areas of IPsec virtual private network (VPN) design that commonly present obstacles to successful deployment. We will begin our discussion with a brief overview of the diagnostic tools available within IOS commonly used to diagnose and correct issues with IPsec VPN deployments. After presenting the tools needed to troubleshoot IPsec, we will begin to explore two broad categories of common IPsec VPN issues: configuration and architecture. The IPsec VPN configuration issues we will explore in this chapter include:

  • IKE SA Proposal Mismatches

  • IKE Authentication Failures

  • IPsec SA Proposal Mismatches

  • Crypto ACL Mismatches

Unlike configuration issues, architectural issues do not require a misconfiguration by the administrator. Architectural issues are often introduced by incompatibilities between IPsec and other networking technologies. The architectural IPsec VPN issues we will discuss in this chapter include:

  • IPsec in Firewalled Environments

  • IPsec in NAT Environments

  • IPsec and Quality of Service

  • IPsec and Fragmentation

  • IPsec and Recursive Routing


IPsec Diagnostic Tools within Cisco IOS

The most commonly used categories of diagnostic tools used within Cisco IOS are show and debug commands. Throughout the course of this chapter, we will use variations of these two command sets to diagnose issues commonly found within Cisco IOS. As we've discussed, there are detailed steps that occur during the formation of Internet Security Association and Key Management Protocol (ISAKMP) and IPsec negotiation between two IPsec VPN endpoints. We will examine common errors in these steps through execution of the following debugging commands within IOS:

  • debug crypto isakmp

  • debug crypto IPsec

Additionally, we will explore several show commands necessary to uncover common errors and performance issues related to the negotiate of IPsec VPN tunnels, including fragmentation/maximum transmission unit (MTU) issues, quality of service (QoS) issues, Network Address Translation (NAT) issues, and issues relating to recursive routing. A subset of the commands we will discuss to address these issues includes:

  • show crypto isakmp sa

  • show crypto isakmp sa nat

  • show crypto IPsec sa

  • show crypto engine connections active

  • show crypto engine connections dropped-packet

  • show crypto engine connections flow

  • show crypto engine qos


Common Configuration Issues with IPsec VPNs

There are many parameters and features to understand when deploying IPsec VPNs. In this section, we will discuss configuration issues presented when one or more IPsec VPN gateways are configured incorrectly. After discussing the nature of each of the above commonly experienced IPsec VPN configuration issues, we will discuss the methods used to effectively diagnose and remedy these issues.

IKE SA Proposal Mismatches

Unless IPsec session keys are manually defined, two crypto endpoints must agree upon an ISAKMP policy to use when negotiating the secure Internet Key Exchange (IKE) channel, or ISAKMP security association (SA). As such, when two VPN endpoints fail to agree upon a usable ISAKMP policy, IPsec SA negotiation cannot initiate, and traffic will continue to flow unencrypted.

Figure 2-24 and Figure 2-25 provide a brief description of ISAKMP policy negotiation process in main mode and aggressive mode respectively and the involved configuration on two VPN endpoints. Also remember from our discussions in Chapter 2 that ISAKMP policies are listed in order of priority (the lower number being the highest priority). The initiator will offer the highest priority proposal, and the responder will search its locally configured ISAKMP policies for a match. If there are none, the initiator will propose the next highest ISAKMP policy and define its local configuration. This process will continue until the initiator has no proposals left to offer the responder. The result, in this case, would be an ISAKMP SA proposal mismatch. Using the configurations provided in Example 4-1 and Example 4-2, Router_A and Router_B will attempt to form an IKE SA between one another using the topology illustrated in Figure 4-1.

Figure 4-1. ISAKMP SA Negotiation Resulting in ISAKMP Proposal Mismatch

[View full size image]

Example 4-1 provides the ISAKMP policies configured for Router_A in Figure 4-1. Note that, in this configuration, there are no ISAKMP proposals configured that match those configured on Router_B in Example 4-2.

Example 4-1. Crypto ISAKMP Policy Definition for Router_A in Figure 4-1 (Mismatch with Router_B, Example 4-2)

Router_A#show crypto isakmp policy

Global IKE policy
Protection suite of priority 10
        encryption algorithm:   Three key triple DES
        hash algorithm:         Message Digest 5
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #2 (1024 bit)
        lifetime:               86400 seconds, no volume limit
Protection suite of priority 20
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #2 (1024 bit)
        lifetime:               86400 seconds, no volume limit
Protection suite of priority 30
        encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit
Default protection suite
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit

Example 4-2 provides the ISAKMP policy configuration on Router_B of Figure 4-1. Router_B will use this policy when building an ISAKMP SA to Router_A, whose ISAKMP policy is provided in Example 4-1. Because Router_B's ISAKMP configuration contains no matching proposals with Router_A's configuration provided in Example 4-1, ISAKMP negotiation will fail.

Example 4-2. Crypto ISAKMP Policy Definition for Router_B in Figure 4-1 (Mismatch with Router_B, Example 4-1)

Router_B#show crypto isakmp policy

Global IKE policy
Protection suite of priority 10
        encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
        hash algorithm:         Message Digest 5
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #5 (1536 bit)
        lifetime:               86400 seconds, no volume limit
Protection suite of priority 20
        encryption algorithm:   Three key triple DES
        hash algorithm:         Message Digest 5
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit
Protection suite of priority 30
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #2 (1024 bit)
        lifetime:               86400 seconds, no volume limit
Default protection suite
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit

The following numbered sequence of events describes the ISAKMP proposal mismatch between the configurations provided in Example 4-1 for Router_A in Figure 4-1 and Example 4-2 for Router_B in Figure 4-1.

1. | Router A sends its configured ISAKMP policies 10, 20, and 30 to Router B.
2. | Router B checks policy 10 obtained in step 1 against its own configured policies, beginning with the lowest numbered policy and ending with the highest.
3. | If Router B does not find a match in step 2, it checks policy 20 obtained in step 1 against its own configured policies, starting with the lowest numbered and ending with the highest.
4. | If Router B does not find a match in step 3, it checks policy 30 obtained in step 1 against its own configured policies, starting with the lowest numbered and ending with the highest.
5. | If Router B does not find a match in step 4, then a proposal mismatch has occurred, and the Phase 1 negotiation times out.

In order to confirm that IKE proposal mismatches have occurred in an IPsec VPN tunnel negotiation, we will inspect the output of the ISAKMP SA negotiation between Routers A and B. Routers A and B are using preshared IKE authentication in a site-to-site VPN, but have not been configured with matching ISAKMP policies. We will execute the command debug crypto isakmp on routers A and B to highlight that an IKE proposal mismatch is indeed the cause of ISAKMP SA negotiation failure. Example 4-3 displays debugging output as ISAKMP policies proposed by Router_A are checked against locally configured policies on Router_B.

In the diagnostic output shown in Example 4-3, Router_B checks proposals sent from Router_A for potential matches. Router_B begins by checking the ISAKMP proposals sent from Router_A against its own configured ISAKMP proposals. It does this by checking all of the proposals received (starting with lowest numbered and ending with highest) against favored policy (lowest numbered). If there are no matches, it checks the received policies in the same order against its next-lowest-numbered policy. This process continues until a match is found or all policies have been checked and no match has been found. In this specific proposal, the encryption proposed for encrypting the IKE channel does not match (see Examples 4-2 and 4-3 for ISAKMP proposal information for Router_A and Router_B), and Router B continues to check other offered proposals against its locally configured ISAKMP policies. Example 4-3, line 12, confirms that a proposal mismatch has occurred. Router_B finds that no ISAKMP proposals sent from Router_A match its own configured ISAKMP policies and therefore deletes the Phase1 SA and Phase1 negotiation times out on Router_A, as confirmed in Example 4-3, line 18.

Example 4-3. Isolating IKE Proposal Mismatches on the Initiating VPN Endpoint (Router A)

1  Router_B#debug crypto isakmp
2  Crypto ISAKMP debugging is on
3  !
4  !
5  *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 1 against priority
     10 policy
6  *Feb 16 12:11:02.379: ISAKMP:      encryption 3DES-CBC
7  *Feb 16 12:11:02.379: ISAKMP:      hash MD5
8  *Feb 16 12:11:02.379: ISAKMP:      default group 2
9  *Feb 16 12:11:02.379: ISAKMP:      auth pre-share
10 *Feb 16 12:11:02.379: ISAKMP:      life type in seconds
11 *Feb 16 12:11:02.379: ISAKMP:      life duration (VPI) of 0x0 0x1 0x51 0x80
12 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):Encryption algorithm offered does not match
     policy!
13 !
14 !
15 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):no offers accepted!
16 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0): phase 1 SA policy not acceptable! (local
     200.0.0.2 remote 200.0.0.1)
17 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):peer does not do paranoid keepalives.
18 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):deleting SA reason "Phase1 SA policy proposal
     not accepted" state (R) MM_NO_STATE (peer 200.0.0.1)

Until the two endpoints can agree on an ISAKMP policy to use when securing the IKE channel and negotiating a Diffie-Hellman key to use when encrypting the IKE exchanges and in the IPsec transform, IPsec VPN tunnel negotiation cannot continue. Another task that must be performed successfully for IPsec VPN tunnel negotiation to continue is IKE authentication.

IKE Authentication Failures and Errors

Recall from our previous discussions that, in Cisco IOS, there are three methods offered to authenticate peers wanting to negotiate an ISAKMP SA: preshared keys (PSKs), RSA signatures, or RSA encryption. As we had discussed in Chapter 2, all three authentication methods have distinct elements used when authenticating IKE Peers. We will discuss common IKE authentication failure issues within the context of each of these three authentication methods.

IKE Authentication Errors and PSKs

There are two conditions that must be met for two IPsec VPN endpoints to authenticate each other using IKE PSKs. First, matching keys must be configured on the two endpoints. Second, the endpoints must be configured to share these keys with the correct peer. Router_A and Router_B are now configured with matching ISAKMP policies for Phase 1 negotiation, but still have problems preventing them from authenticating one another. We will examine debugging output on the routers in Figure 4-2 to highlight authentication failures directly attributable to mismatched keys and mismatched peers.

Figure 4-2. Troubleshooting IKE PSK Authentication

[View full size image]

Example 4-4 provides the configuration of Router_A in Figure 4-2. Note that, unlike Router_A's configuration in Figure 4-1, Router_A is now configured with an ISAKMP policy that contains a matching proposal (Example 4-4, priority 30) with Router_B (Example 4-5, priority 10). In this case, however, IKE will still fail to negotiate due to a mismatched PSK on Router_A (Example 4-4, line 32) and Router_B (Example 4-5, line 32).

Example 4-4. Mismatched IKE PSK on Router_A (Corresponds with Mismatched Key for Router_B in Example 4-5)

1  Router_A#show crypto isakmp policy
2
3  Global IKE policy
4  #<--ISAKMP Policy 10 Matches Router_B's ISAKMP Proposal 30 (Example 4-5 below)-->
5  Protection suite of priority 10
6          encryption algorithm:   Three key triple DES
7          hash algorithm:         Message Digest 5
8          authentication method:  Pre-Shared Key
9          Diffie-Hellman group:   #2 (1024 bit)
10          lifetime:               86400 seconds, no volume limit
11 Protection suite of priority 20
12         encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
13         hash algorithm:         Secure Hash Standard
14         authentication method:  Pre-Shared Key
15         Diffie-Hellman group:   #2 (1024 bit)
16         lifetime:               86400 seconds, no volume limit
17 Protection suite of priority 30
18         encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
19         hash algorithm:         Secure Hash Standard
20         authentication method:  Pre-Shared Key
21         Diffie-Hellman group:   #5 (1536 bit)
22         lifetime:               86400 seconds, no volume limit
23 Default protection suite
24         encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
25         hash algorithm:         Secure Hash Standard
26         authentication method:  Rivest-Shamir-Adleman Signature
27         Diffie-Hellman group:   #1 (768 bit)
28         lifetime:               86400 seconds, no volume limit
29 Router_A#show crypto isakmp key
30 Keyring               Hostname/Address                   PSK
31
32 default               200.0.0.2                          tarheels

Example 4-5 provides the configuration of Router_B in Figure 4-2. Note that Router_B's ISAKMP proposal listed with priority 10 (Example 4-4, lines 5-10) will match Router_A's proposal listed with priority 30 (Example 4-4, lines 17-22). However, IKE will still fail because of mismatched PSKs on Router_A (Example 4-4, line 32) and Router_B (Example 4-5, line 32).

Example 4-5. Mismatched IKE PSK on Router_B (Corresponds with Mismatched Key for Router_A in Example 4-4)

1  Router_B#show crypto isakmp policy
2
3  Global IKE policy
4  Protection suite of priority 10
5          encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
6          hash algorithm:         Secure Hash Standard
7          authentication method:  Pre-Shared Key
8          Diffie-Hellman group:   #5 (1536 bit)
9          lifetime:               86400 seconds, no volume limit
10 Protection suite of priority 20
11         encryption algorithm:   Three key triple DES
12         hash algorithm:         Message Digest 5
13         authentication method:  Rivest-Shamir-Adleman Signature
14         Diffie-Hellman group:   #1 (768 bit)
15         lifetime:               86400 seconds, no volume limit
17  #<--ISAKMP Policy 30 Matches Router_A's ISAKMP Proposal 10 (Example 4-4 above)-->
17 Protection suite of priority 30
18         encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
19         hash algorithm:         Secure Hash Standard
20         authentication method:  Pre-Shared Key
21         Diffie-Hellman group:   #2 (1024 bit)
22         lifetime:               86400 seconds, no volume limit
23 Default protection suite
24         encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
25         hash algorithm:         Secure Hash Standard
26         authentication method:  Rivest-Shamir-Adleman Signature
27         Diffie-Hellman group:   #1 (768 bit)
28         lifetime:               86400 seconds, no volume limit
29 Router_A#show crypto isakmp key
30 Keyring               Hostname/Address                   PSK
31
32 default               200.0.0.1                          bluedevils

Mismatched Keys

Note that, in Example 4-4 and Example 4-5, the Router_A fails to negotiate an IKE SA due to mismatched PSKs. The diagnostic output provided in Example 4-6, line 13, confirms that the two crypto peers have agreed on an IKE proposal. However, Example 4-6, line 18, confirms that the SA fails negotiation due to a PSK mismatch.

Example 4-6. PSK Authentication Failure Between Two IKE Endpoints

1  Router_A#debug crypto isakmp
2  Crypto ISAKMP debugging is on
3  !
4  !
5  *Feb 16 14:20:44.991: ISAKMP (0:1): Checking ISAKMP transform 1 against priority
     30 policy
6  *Feb 16 14:20:44.991: ISAKMP:      encryption AES-CBC
7  *Feb 16 14:20:44.991: ISAKMP:      keylength of 128
8  *Feb 16 14:20:44.991: ISAKMP:      hash SHA
9  *Feb 16 14:20:44.991: ISAKMP:      default group 5
10 *Feb 16 14:20:44.991: ISAKMP:      auth pre-share
11 *Feb 16 14:20:44.991: ISAKMP:      life type in seconds
12 *Feb 16 14:20:44.995: ISAKMP:      life duration (VPI) of 0x0 0x1 0x51 0x80
13 *Feb 16 14:20:44.995: ISAKMP (0:1): atts are acceptable. Next payload is 0
14 !
15 !
16 *Feb 16 14:20:45.319: ISAKMP (0:1): received packet from 200.1.1.2 dport 500 sport
     500 Global (I) MM_KEY_EXCH
17 *Feb 16 14:20:45.319: ISAKMP: reserved not zero on NOTIFY payload!
18 *Feb 16 14:20:45.319: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 200.0.0.2     failed
     its sanity check or is malformed

Mismatched Peer Addresses in IKE PSK Definition

As we have discussed, there are two elements to troubleshoot in a PSK authentication scheme. Thus far, we've covered IKE failure due to PSK mismatches. Now, let's turn our attention to IKE issues surrounding peering specification on PSKs. Suppose that, in Figure 4-2, Router_A decides to source all peering sessions from its loopback interface (loopack 1, ip=201.0.0.1/32).

The default behavior of an IOS IPsec endpoint is to source the IPsec VPN tunnel from the IP address of the physical interface where the crypto map is applied. Example 4-7 changes IPsec peering behavior from the router's default settings by instructing the router to use a loopback interface for sourcing the IPsec VPN tunnel.

Example 4-7. Router_A Sources IPsec VPNs from Its Loopback1 Interface (201.0.0.1)

!
crypto map Router____A____Map local-address Loopback1
!
interface Loopback1
 ip address 201.0.0.1 255.255.255.255

The administrators of Router_B must make two basic changes to accommodate this change on Router_A. They must first change their IPsec peering definition in their crypto map to point to Router_A's new source (its loopback address, 201.0.0.1). This change is illustrated in the configuration fragment provided in Example 4-8.

Example 4-8. Necessary Peering Changes Required on Router_B

!
crypto isakmp key tarheels address 201.0.0.1
!
crypto map Router____B____Map 10 IPsec-isakmp
 set peer 201.0.0.1

Assume, though, that the administrators of Router_B did not correctly modify the peer address on their PSK statement to accurately reflect the changes on Router_A. This too would result in an IKE authentication failure, ultimately causing IPsec VPN tunnel negotiation to stop before Phase 1 negotiation can complete. The debugging output in Example 4-9 can be inspected to confirm that, although IKE PSKs do match, they are not being shared with the correct peers. Due to the fact that the IPsec peer has been updated to point to 201.0.0.1 (Example 4-8), the IKE engine will try to look for a key to use with that peer. In this case, the case described in Example 4-9, the IKE PSK statement has not been updated, and the IKE Phase 1 negotiation subsequently fails to kick off. Note that the peer statement in Example 4-8 has been changed to 201.0.0.1, but the IKE PSK statement is still 200.0.0.1. The diagnostic output provided in Example 4-9 confirms this error, as IKE cannot find a matching key to use with the new IPsec peer statement in the crypto map (201.0.0.1).

Example 4-9. IKE Authentication Failure Due to PSKs Not Being Shared with the Correct Peer Addresses

!
!
*Feb 16 14:30:00.595: ISAKMP:(0:0:N/A:0):Can not start Aggressive mode, trying Main mode.
*Feb 16 14:30:00.595: ISAKMP: Looking for a matching key for 201.0.0.1 in default
*Feb 16 14:30:00.595: ISAKMP:(0:0:N/A:0):No pre-shared key with 201.0.0.1!
!

Solving Key Mismatch and Peer Mismatch Issues on Router_A and Router_B

Indeed, the administrators of Router_B realize that they had made a mistake in selecting "bluedevils" as the IKE PSK and fix the problem. Additionally, all of the ISAKMP address information on PSK definitions on Router_A and Router_B have changed to be consistent. Now that Router_A and Router_B can agree on an ISAKMP policy and PSK with the appropriate peering information intact, an IKE can successfully be negotiated as evidenced by debugging output from IKE Phase 1 negotiation on Router_B (Example 4-10). Example 4-10, line 13, confirms that the two crypto peers have agreed on an ISAKMP proposal, and Example 4-10 line 22 confirms that the SA has been authenticated. Once Phase 1 negotiation is complete, the ISAKMP SA can be verified without debugging, using show commands, as illustrated in Example 4-10, lines 2325.

Example 4-10. Successful IKE Authentication Using PSKs (Router_B)

1  Router_B#debug crypto isakmp
2  Crypto ISAKMP debugging is on
3  !
4  !
5  *Feb 16 14:44:55.063: ISAKMP (0:1): Checking ISAKMP transform 1 against priority 30 policy
6  *Feb 16 14:44:55.063: ISAKMP:       encryption AES-CBC
7  *Feb 16 14:44:55.063: ISAKMP:       keylength of 128
8  *Feb 16 14:44:55.063: ISAKMP:       hash SHA
9  *Feb 16 14:44:55.063: ISAKMP:       default group 5
10 *Feb 16 14:44:55.063: ISAKMP:       auth pre-share
11 *Feb 16 14:44:55.063: ISAKMP:       life type in seconds
12 *Feb 16 14:44:55.063: ISAKMP:       life duration (VPI) of 0x0 0x1 0x51 0x80
13 *Feb 16 14:44:55.063: ISAKMP (0:1): atts are acceptable. Next payload is 3
14 !
15 !
16 *Feb 16 14:44:55.431: ISAKMP (0:1): SA authentication status:
17         Authenticated
18 *Feb 16 14:44:55.431: ISAKMP (0:1): Process initial contact,
19 bring down existing phase 1 and 2 SA's with local 200.1.1.2 remote 201.0.0.1 remote
     port 500
20 *Feb 16 14:44:55.431: ISAKMP (0:1): SA authentication status:
21         authenticated
22 *Feb 16 14:44:55.431: ISAKMP (0:1): SA has been authenticated with 201.0.0.1
23 Router_B#sh crypto isakmp sa
24 dst             src               state        conn-id slot
25 200.0.0.2       201.0.0.1         QM_IDLE            1    0

IKE Authentication Errors with RSA Encryption

As with the PSK method of authenticating IKE peers, IKE authentication failures using RSA encryption are commonly attributed to two categoriesmismatched keys or mismatched peers. As such, we will begin our RSA encryption discussion with a scenario in which RSA public keys are not matched correctly. Remember that RSA encryption algorithm is asymmetric, consisting of two keysthe public/decryption key and the private/encryption key. If the incorrect keys are provided to IPsec VPN peers using RSA Encryption, Phase 1 negotiation will time out due to IKE authentication errors. The endpoints in Figure 4-3 are set up to do RSA encryption for IKE authentication.

Figure 4-3. IKE Authentication FailureMismatched RSA Public Keys

[View full size image]

Example 4-11 provides the RSA key configuration of Router_A in Figure 4-3. The router uses RSA encryption as the IKE authentication method, requiring a public (encryption) key and a private (decryption) key to authenticate the SA. Router_A's private key is manually generated, and is listed in Example 4-11, lines 3-9. The administrator of Router_A has manually entered Router_B's encryption key, as listed in Example 4-11, lines 20-29.

Example 4-11. Router_A's (Figure 4-3) RSA Key Configuration for IKE SA Establishment with Router_B

1  Router_A#show crypto key mypubkey rsa
2  % Key pair was generated at: 8:56:03 UTC Feb 17 2005
3  <-- Router_A's Private RSA Key used for decryption -->
4  Key name: Router_A.cisco.com
5   Usage: General Purpose Key
6   Key is not exportable.
7   Key Data:
8    305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2
9    415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B
10    4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001
11 % Key pair was generated at: 10:56:04 UTC Feb 17 2005
12 Key name: Router_A.cisco.com.server
13  Usage: Encryption Key
14  Key is exportable.
15  Key Data:
16   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B86AD5 F0E1D956
17   E29630DC 64D5FAE8 F6FA9E74 3894D9B9 0DCA97AE 454F4937 063499B2 2B84C46E
18   7D5D2647 22D3AC56 DC9017DC 5D6938AD A57C4629 098C2DA3 8F16376A DDD145DA
19   70712AD0 EB07850F 5B96A6E2 7CCA8D60 3783E7D9 30EE2DD8 3B020301 0001
20
21 <-- RSA Key used to encrypt data to Router_B (200.0.0.2) -->
22 Router_A#show crypto key pubkey-chain rsa add 200.0.0.2
23 Key address:         200.0.0.2
24  Usage: General Purpose Key
25  Source: Manually entered
26  Data:
27   30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF
28   64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE
29   28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162
30   C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4
31   5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001

Example 4-12 provides the RSA key configuration of Router_B in Figure 4-3. Note that Router B has mistakenly been configured with Router_A's private key, rather than its public key.

Example 4-12. Router_B's (Figure 4-3) RSA Key Configuration for IKE SA Establishment with Router_A

1  Router_B#show crypto key mypubkey rsa
2  % Key pair was generated at: 08:59:17 UTC Feb 17 2005
3  <-- Router_B's Private RSA Key used for decryption -->
4  Key name: Router_B.cisco.com
5   Usage: General Purpose Key
6   Key is not exportable.
7   Key Data:
8    30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF
9    64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE
10    28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162
11   C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4
12   5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001
13 % Key pair was generated at: 09:59:18 UTC Feb 17 2005
14 Key name: Router_B.cisco.com.server
15  Usage: Encryption Key
16  Key is not exportable.
17  Key Data:
18   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00CCB92C 23D6CA83
19   1BD6D9D3 7F569F4F 6AF576C8 AD682B20 3E9B054B 8C75CD54 4B6FDB7F 71524C5F
20   C117056E 15A86DA7 26AB1B92 23958CB9 1134C6A1 AF8ACDBE 8E1F8C30 0468E46B
21   36CFA390 0B0CE8BE 622B0266 E10342DF FD2D50E0 A6460363 37020301 0001
22
23 Router_B#show crypto key pubkey-chain rsa address 200.0.0.1
24 <-- RSA Key used to encrypt data to Router_A (200.0.0.1) -->
25 Key address:        200.0.0.1
26  Usage: General Purpose Key
27  Source: Manually entered
28  Data:
29   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B86AD5 F0E1D956
30   E29630DC 64D5FAE8 F6FA9E74 3894D9B9 0DCA97AE 454F4937 063499B2 2B84C46E
31   7D5D2647 22D3AC56 DC9017DC 5D6938AD A57C4629 098C2DA3 8F16376A DDD145DA
32   70712AD0 EB07850F 5B96A6E2 7CCA8D60 3783E7D9 30EE2DD8 3B020301 0001

Example 4-13, line 5, confirms that ISAKMP SA negotiation is initiated with RSA Encryption for authentication. Output from Example 4-13, line 8, indicates that IKE messages cannot be decrypted, because Router_B is mistakenly using Router_A's decryption key for encrypting IKE messages to Router_A, rather than using Router_A's proper encryption key to do so. Example 4-13, lines 19-40, illustrate that the same key misconfiguration on Router_A is causing IKE SA authentication to fail on Router_B for the same reasons it failed earlier on Router_A.

Example 4-13. Troubleshooting IKE Authentication Failures with RSA Encryption

1  Router_A#debug crypto isakmp
2  Crypto ISAKMP debugging is on
3  !
4  !
5  *Feb 17 10:58:20.066: ISAKMP (0:1): SA is doing RSA encryption authentication using
     id type ID_IPV4_ADDR
6  !
7  !
8  *Feb 17 10:58:20.554: %CRYPTO-6-IKMP_CRYPT_FAILURE: IKE (connection id 1) unable to
     decrypt (w/RSA private key) packet
9  !
10 !
11 *Feb 17 10:58:41.706: ISAKMP (0:1): retransmitting phase 1 MM_SA_SETUP...
12 *Feb 17 10:58:41.706: ISAKMP (0:1): incrementing error counter on sa: retransmit phase 1
13 !
14 !
15 *Feb 17 10:59:19.918: ISAKMP (0:1): deleting SA reason "gen_IPsec_isakmp_delete but
     doi isakmp" state (I) MM_SA_SETUP (peer 200.0.0.2) input queue 0
16 *Feb 17 10:59:19.918: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
17 *Feb 17 10:59:19.918: ISAKMP (0:1): Old State = IKE_I_MM3 New State = IKE_DEST_SA
18
19 Router_B#debug crypto isakmp
20 Crypto ISAKMP debugging is on
21 !
22 !
23 *Feb 17 10:01:10.930: ISAKMP:(0:1:SW:1):SA is doing RSA encryption authentication
     using id type ID_IPV4_ADDR
24 !
25 !
26 *Feb 17 10:01:21.658: ISAKMP:(0:1:SW:1): retransmitting phase 1 MM_KEY_EXCH
27 *Feb 17 10:01:21.658: ISAKMP:(0:1:SW:1): sending packet to 200.1.1.1 my_port
     500 peer_port 500 (R) MM_KEY_EXCH
28 !
29 !
30 *Feb 17 10:01:55.466: ISAKMP: quick mode timer expired.
31 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):src 200.0.0.1 dst 200.0.0.2, SA is not
     authenticated
32 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):peer does not do paranoid keepalives.
33 !
34 !
35 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):deleting SA reason "QM_TIMER expired" state (R)
     MM_KEY_EXCH (peer 200.0.0.1)
36 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):deleting SA reason "QM_TIMER expired" state (R)
     MM_KEY_EXCH (peer 200.1.1.1)
37 *Feb 17 10:01:55.466: ISAKMP: Unlocking IKE struct 0x65C405A8 for isadb_mark_
     sa_deleted(), count 0
38 *Feb 17 10:01:55.466: ISAKMP: Deleting peer node by peer_reap for 200.1.1.1: 65C405A8
39 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
40 *Feb 17 10:01:55.466: ISAKMP:(0:1:SW:1):Old State = IKE_R_MM4 New State = IKE_DEST_SA

Cisco IOS VPN endpoints can be instructed to use certain RSA public keys with certain peers, a similar functionality to standard PSK authentication. As such, it is important that each VPN endpoint is using the correct key for the correct peer. Consider once again the situation in which the administrators of Router_A choose to source the VPN tunnel endpoint from their loopback1 (201.0.0.1) interface. The administrators of Router_B have fixed the mismatching key problem in Example 4-11 through Example 4-13, and have updated their IPsec configuration to peer with Router_A's loopback address. However, they have not updated the address that ISAKMP should use when authenticating the IKE channel with Router_B's public/encryption key (see configurations listed in Figure 4-4). Therefore, Router_B cannot select the appropriate public key to authenticate the IKE channel with Router_A. Once again, this leads to an IKE Authentication error, which eventually causes ISAKMP SA negotiation to time out.

Figure 4-4. RSA Encryption and ISAKMP Peer Mismatches

[View full size image]

Example 4-14 provides the RSA key configuration for Router_A in Figure 4-4.

Example 4-14. Router_A RSA Encryption Key Peer Mismatch with Router_B in Figure 4-4 (Router_B Configuration Provided in Example 4-15)

1  Router_A#show crypto key mypubkey rsa
2  % Key pair was generated at: 10:56:03 UTC Feb 17 2005
3  Key name: Router_A.cisco.com
4   Usage: General Purpose Key
5   Key is not exportable.
6   Key Data:
7    305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2
8    415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B
9    4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001
10 % Key pair was generated at: 11:56:05 UTC Feb 17 2005
11 Key name: Router_A.cisco.com.server
12  Usage: Encryption Key
13  Key is not exportable.
14  Key Data:
15   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00A233B3 3A58DDB2
16   D578B1A4 0125E1CD 1594C9F2 24DACE5E 65A276C7 640E9A13 B8DC4EEC F332B8D8
17   80127FD6 07A579F6 A280DF7D 2ED2CA8B 3457F5DE 53DAB835 C2845EB6 42F89BB0
18   C7130F67 B10FD71E 30A1FB1E 812CA1A6 26F43DCA 7BDDA01D 65020301 0001
19
20 Router_A#show crypto key pubkey-chain rsa address 200.0.0.2
21 Key address:        200.0.0.2
22 Usage: General Purpose Key
23 Source: Manually entered
24 Data:
25  30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF
26  64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE
27  28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162
28  C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4
29  5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001

Example 4-15 provides the RSA key configuration for Router_B in Figure 4-4. Note that, although the public and private keys have been correctly configured on Router_A and Router_B, Router_B is not configured with the correct peering information in its encryption key settings to be used with Router_A. This peer mismatch is illustrated in Example 4-15, lines 22-23.

Example 4-15. Router_B RSA Encryption Key Peer Mismatch with Router_A in Figure 4-4 (Router_A Configuration Provided in Example 4-14)

1  Router_B#show crypto key mypubkey rsa
2  % Key pair was generated at: 09:59:17 UTC Feb 17 2005
3  Key name: Router_B.cisco.com
4   Usage: General Purpose Key
5   Key is not exportable.
6   Key Data:
7    30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF
8    64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE
9    28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162
10   C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4
11   5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001
12 % Key pair was generated at: 10:59:18 UTC Feb 17 2005
13 Key name: Router_B.cisco.com.server
14  Usage: Encryption Key
15  Key is not exportable.
16  Key Data:
17   307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00CA138A 38268367
18   9FB2BDA8 A5C4677B 06A0FA1C 7811BAA6 C6FA48A7 E3DE55D0 B6967E71 DF076209
19   1F3CCA1E A7F40179 B4013CC8 ADCB15DD FFDAFAC3 9210BEA7 894DEEDA 1BF59C4B
20   B0143E21 80559A4D 4F8A512E DB739E8B 576E61FD 650BDA6B 87020301 0001
21
22 Router_B#show crypto key pubkey-chain rsa address 200.0.0.1
23 Key address:             200.0.0.1
24  Usage: General Purpose Key
25  Source: Manually entered
26  Data:
27   305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2
28   415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B
29   4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001

Once the configuration on Router_B (Example 4-15, lines 22-23) has been updated to use Router_A's public key with Router_A's new peering information (lo1=201.0.0.1), then the ISAKMP SA can be negotiated successfully using RSA Encryption as confirmed in Example 4-16.

Example 4-16. Updated Peer Configuration on Router_B, and ISAKMP SA Confirmation

1  Router_B#sh run
2  Building configuration...
3  crypto key pubkey-chain rsa
4   addressed-key 201.0.0.1
5    address 201.0.0.1
6    key-string
7     305C300D 06092A86 4886F70D 01010105 00034B00 30480241 00BF6D28 71EE1FF2
8     415E4001 23F4D08C 62DFEAA8 4C0682A4 39D66B5D DC275EAB C95DE5A4 1C87700B
9     4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001
10   quit
11
12 Router_B#ping
13 !
14 !
15 Sending 5, 100-byte ICMP Echos to 202.1.1.1, timeout is 2 seconds:
16 Packet sent with a source address of 202.2.2.1
17 .!!!!
18 Success rate is 80 percent (4/5), round-trip min/avg/max = 40/43/44 ms
19 *Feb 17 11:21:41.570: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP  . Peer
201.0.0.1:500       Id: 201.0.0.1
20 Router_B#show crypto isakmp sa
21 dst         src             state          conn-id      slot
22 201.0.0.1   200.1.1.2       QM_IDLE              1         0
23 Router_B#show crypto key pubkey-chain rsa
24 Codes: M - Manually configured, C - Extracted from certificate
25
26 Code Usage         IP-Address/VRF         Keyring           Name
27 M    General        201.0.0.1             default

Note

In the preceding examples pertaining to RSA encryption, Router_A (512 bit-mod) and Router_B (1024-bit mod) have been using mismatched key modulus. This will not cause IKE authentication errors, but does not provide the same strength in authentication as using 1024-bit keys on both sides.

Last, it is important to note that the configurations above use IP addresses (addressed-key) selecting public keys to use with their corresponding peer. Alternately, administrators can use hostnames to identify peers, instead of IP addresses. When using hostnames, administrators must verify that the hostname can be resolved to an IP address via DNS or manually using the ip host [ip-address] [hostname] command in the local router configuration. Additionally, each peer using a hostname for ISAKMP identification must be instructed to do so using the crypto isakmp identity [hostname] command, as the default is use of the IP address associated with the physical interface where the crypto map is applied.

IKE Authentication Errors with RSA Signatures

As we'll discuss later in Chapter 11, the dynamics of authentication change dramatically when RSA signatures are used. Until now, we've discussed IKE SA authentication methods that require direct key exchange between crypto endpoints, including both IKE PSK and RSA Encrypted Nonce methods of IKE authentication. Now we will discuss the RSA Signatures method of IKE SA authentication, in which both endpoints are authenticated indirectly using a centralized trusted resource, a Certificate Authority (CA), during Phase 1 negotiation. As such, our focus will not be on endpoint-endpoint authentication and peering, but instead will explore common IKE authentication issues attributable to endpoint-CA operation:

  • Authenticating the CA and Obtaining the CA Certificate

  • Enrolling with the CA and Obtaining Public Key Certificates

We will examine debugs and diagnostics for each of these processes using the topology in Figure 4-5, as Routers A and B obtain certificates from IOS_CAROOT needed for IKE authentication using RSA Signatures. It has been confirmed that Router_A and Router_B can reach the CA.

Figure 4-5. Troubleshooting IKE Authentication Errors with RSA Signatures

[View full size image]

Example 4-17 provides the configuration for Router_A in Figure 4-5. We will use this configuration while troubleshooting and validating IKE SA authentication with RSA Signatures later in this chapter.

Example 4-17. RSA Signatures Configuration on Router_A (Figure 4-5)

Router_A#show crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 03
  Certificate Usage: General Purpose
  Issuer:
    cn=IOS_CAROOT
  Subject:
    Name: Router_A.cisco.com
    IP Address: 192.168.1.1
    Serial Number: 01C2F27F
    serialNumber=1C2F27F+ipaddress=192.168.1.1+hostname=Router_A.cisco.com
  Validity Date:
    start date: 10:12:45 UTC Feb 24 2005
    end   date: 10:12:45 UTC Feb 24 2006
    renew date: 00:00:00 UTC Jan 1 1970
  Associated Trustpoints: IOS_CAROOT

CA Certificate
  Status: Available
  Certificate Serial Number: 01
  Certificate Usage: Signature
  Issuer:
    cn=IOS_CAROOT
  Subject:
    cn=IOS_CAROOT
  Validity Date:
    start date: 09:06:11 UTC Feb 24 2005
    end   date: 09:06:11 UTC Feb 24 2008
  Associated Trustpoints: IOS_CAROOT

Router_A#show crypto key mypubkey rsa
% Key pair was generated at: 10:11:30 UTC Feb 24 2005
Key name: Router_A.cisco.com
 Usage: General Purpose Key
 Key is not exportable.
 Key Data:
  30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00AF2FC9
  1919ECF1 DE24C37D 796658E2 2B186600 98EB5CE3 AE0E53FE B1F736EA CE417989
  F3029E25 594B9BCB 30DD0A2D 799814B1 555071FE BFB081E1 80548F91 3021F997
  0FBC0B62 4A6284A4 22175B89 4D5C00B2 4DE6F657 F6CA00DA E8629294 413487F6
  6AB72BAF 071F4C63 CD813C3A 8925B95D F3DE265C CCFA3AA5 C38386DA 25020301 0001
% Key pair was generated at: 10:11:31 UTC Feb 24 2005
Key name: Router_A.cisco.com.server
 Usage: Encryption Key
 Key is exportable.
 Key Data:
  307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00C7CE18 CD11DBAE
  6FE6999B 15E81063 998CD039 91677AAD 9E310C38 9CF10010 EE3BBD5C 574837E8
  08098084 D1F09C7D 9143F22C 6684AAA5 9B518676 AB205A9B 2681B77A 24E69ABA
  734AB29C 28D4A672 4C93B3B4 DE27CB77 FF0DBBF0 2A5ABF1F AF020301 0001

Router_A#show crypto key pubkey-chain rsa
Codes: M - Manually configured, C - Extracted from certificate

Code  Usage       IP-Address/VRF         Keyring           Name
C     Signing                            default           X.500 DN name:
                             cn=IOS_CAROOT

C     Signing     192.168.2.1/           default           Router_B.cisco.com

Example 4-18 provides the configuration for Router_B in Figure 4-5. We will use this configuration while troubleshooting and validating IKE SA authentication with RSA Signatures later in this chapter.

Example 4-18. RSA Signatures Configuration on Router_B (Figure 4-5)

Router_B#show crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 02
  Certificate Usage: General Purpose
  Issuer:
    cn=IOS_CAROOT
  Subject:
    Name: Router_B.cisco.com
    IP Address: 192.168.2.1
    Serial Number: 46DDB4F1
    serialNumber=46DDB4F1+ipaddress=192.168.2.1+hostname=Router_B.cisco.com
  Validity Date:
    start date: 10:12:14 UTC Feb 24 2005
    end   date: 10:12:14 UTC Feb 24 2006
    renew date: 00:00:00 UTC Jan 1 1970
  Associated Trustpoints: IOS_CAROOT

CA Certificate
  Status: Available
  Certificate Serial Number: 01
  Certificate Usage: Signature
  Issuer:
    cn=IOS_CAROOT
  Subject:
    cn=IOS_CAROOT
  Validity Date:
    start date: 09:06:11 UTC Feb 24 2005
    end date: 09:06:11 UTC Feb 24 2008
  Associated Trustpoints: IOS_CAROOT

Router_B#show crypto key mypubkey rsa
% Key pair was generated at: 10:11:24 UTC Feb 24 2005
Key name: Router_B.cisco.com
 Usage: General Purpose Key
 Key is not exportable.
 Key Data:
  30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00BED6DA
  A5B2F28A 344B205F 3DA673FF C68454E4 68CF0E46 C798BA58 03599AB0 AFF59A8C
  7BACFF5B C99549D5 8F74A7CE 70A2DF07 32961389 47CBA640 20BC3680 8A45309D
  775E3233 F491738D 345B59EE 4FAA2086 BCE01E7B 0BF8337B CEB74FF0 8464AC03
  161AD316 D18B1720 A24AC357 DF990577 C170BB0F 652DA98A 49E165C4 45020301 0001
% Key pair was generated at: 10:11:25 UTC Feb 24 2005
Key name: Router_B.cisco.com.server
 Usage: Encryption Key
 Key is not exportable.
 Key Data:
  307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B0EF99 26A348E9
  DCEEA144 54CA48F4 B396BBA6 E9973EC8 58B5A3D5 2B9339EC D3B26894 FBA3F6C5
  50864ECD 4329EE58 4291FAE0 4E9C02EF C0FE117C 77E1E7E7 F871B74D 2012BF25
  56C60BAF 33F7C29D 8B79FDCF D4ACE6E9 9DCD1DB6 92E62427 2B020301 0001

Router_B#show crypto key pubkey-chain rsa
Codes: M - Manually configured, C - Extracted from certificate

Code Usage         IP-Address/VRF         Keyring          Name
C    Signing                              default          X.500 DN name:
                              cn=IOS_CAROOT
C    Signing       192.168.1.1            default          Router_A.cisco.com

Authenticating the CA and Obtaining the CA Certificate

During the process of CA authentication on a Cisco IOS VPN endpoint, the administrator of the VPN endpoint visually inspects the CA certificate fingerprint and manually accepts the corresponding CA certificate. Aside from human error in the inspection and acceptance of the CA fingerprint and certificate described above, one of the most common errors observed during this process is attributable to inconsistencies in clock settings between the endpoint and the CA. The CA's certificate has a lifetime associated with it. When a public-key infrastructure (PKI) endpoint receives the CA certificate during the authentication process and has an incorrect clock setting, the CA certificate could appear to be invalid. Consider Example 4-19 in which Router_B attempts to enroll with the CA, RSA_CAROOT. Router_B's clock is set incorrectly, which leads the router to believe that the CA certificate is outside of the appropriate period of validity.

Example 4-19. CA Authentication Failure Due to Inconsistent Clock Settings

Router_B#sh clock
09:55:30.262 UTC Wed Apr 26 2002
Router_B(config)#crypto pki authenticate IOS_CAROOT
% Error in saving certificate: status = FAIL
%CRYPTO_PKI: CA Cert not yet valid or is expired -
    start date: 14:40:58 UTC Feb 17 2005
    end   date: 14:40:58 UTC Feb 17 2008

Once Router_B's clock has been synchronized with the PKI (and subsequently the CA's), Router_B can then authenticate the CA in the PKI by verifying the CA certificate's thumbprint, as illustrated in Example 4-20, lines 3-5. The debugging output from Example 4-20, lines 10 and 11, verifies that a CA certificate has been received by Router_B. We can further confirm that a CA certificate exists on Router_B via the show command executed in Example 4-20, line 13, and the resulting diagnostic output in Example 4-20, lines 14-25.

Example 4-20. Authenticating and Obtaining the CA Certificate

1  Router_B(config)#crypto pki authenticate IOS_CAROOT
2  Certificate has the following attributes:
3  Fingerprint: 743A3CD1 14293369 3CB5D70C BDB96C7F
4  % Do you accept this certificate? [yes/no]: yes
5  Trustpoint CA certificate accepted.
6
7  IOS_CAROOT#debug crypto pki server
8  !
9  !
10 Feb 22 10:54:12.715: CRYPTO_CS: received a SCEP GetCACert request
11 Feb 22 10:54:12.715: CRYPTO_CS: CA certificate sent
12
13 Router_B#show crypto pki certificates
14 CA Certificate
15   Status: Available
16   Certificate Serial Number: 01
17   Certificate Usage: Signature
18   Issuer:
19     cn=IOS_CAROOT
20   Subject:
21     cn=IOS_CAROOT
22   Validity Date:
23     start date: 14:40:58 UTC Feb 17 2005
24     end   date: 14:40:58 UTC Feb 17 2008
25   Associated Trustpoints: IOS_CAROOT

Now that we have verified that we have the CA's certificate, we can proceed to enroll the VPN endpoint in the PKI.

Enrolling in the PKI

In order to enroll in the PKI, the VPN endpoint must have successfully authenticated the CA to which it will enroll. Additionally, the VPN endpoint subscribing to the PKI must successfully obtain the CA's signing certificate from the CA after enrolling. In order to successfully accomplish this, two things must occur. First, the CA must receive the appropriate request from the VPN endpoint. This requires that the VPN endpoint use the required communication method configured on the CA. Consider the case below in which Router_A wants to enroll with IOS_CAROOT in Figure 4-5. We can confirm through the PKI server operation debugging output on the IOS CA provided in Example 4-21 that the requests for enrollment have indeed been received from Router_A.

Example 4-21. Verifying That Enrollment Requests Are Received by the CA

IOS_CAROOT#debug crypto pki server
!
!
Feb 22 10:41:06.119: CRYPTO_CS: received a SCEP request
Feb 22 10:41:06.119: CRYPTO_CS: read SCEP: registered and bound service SCEP_READ_DB_26
Feb 22 10:41:06.127: CRYPTO_CS: scep msg type - 19
Feb 22 10:41:06.127: CRYPTO_CS: trans id - A758860CFBEAC6B6720A8650A1046863
Feb 22 10:41:06.199: CRYPTO_CS: read SCEP: unregistered and unbound service SCEP_READ_DB_26
Feb 22 10:41:06.199: CRYPTO_CS: received an enrollment request

The second task that must be accomplished in PKI enrollment is verification that the router has indeed received the CA's certificate. Remember that, when enrolling in the PKI, the CA administrator must grant the VPN endpoint its certificate before it can be issued to the VPN endpoint. It is therefore quite possible to authenticate a CA successfully, while not enrolling successfully. The following diagnostic output on the IOS command-line interface (CLI) of the CA in line 4 confirms that the CA has granted and sent its certificate to a requestor (Router_A). The output provided in line 7 of Example 4-22 confirms that Router_A has indeed received its signed certificate from the CA.

Example 4-22. Router_A's Certificate Is Signed by the CA, Sent by the CA, and Received by Router_A

1  IOS_CAROOT#debug crypto pki server
2  !
3  !
4  Feb 22 10:41:13.871: CRYPTO_CS: Certificate generated and sent to requestor
5
6  Router_A#
7  *Feb 22 10:56:12.299: %CRYPTO-6-CERTRET: Certificate received from Certificate Authority

After a crypto endpoint has successfully authenticated and enrolled with the PKI, IKE SA negotiation must still occur for two crypto endpoints to establish an IPsec VPN tunnel between each other. It is, therefore, important to verify ISAKMP SA establishment using the verification methods described earlier in this chapter after peers can successfully authenticate and enroll to the PKI to ensure that the remaining mechanics of IKE SA negotiation have been successfully executed. It is equally important to inspect the certificates for validity after PKI authentication and enrollment, in order to avoid IKE authentication errors with RSA signatures. Once certificates have been received by each VPN endpoint, they should be checked for consistency. Consider once again the IKE authentication exchange between Router_A and Router_B in Figure 4-5. We can confirm the existence of signed certificates on both Router_A and Router_B, as illustrated in Example 4-23.

Example 4-23. Verifying the Existence of Certificates on IOS PKI VPN Endpoints

Router_A#show crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 07
  Certificate Usage: General Purpose
  Issuer:
    cn=IOS_CAROOT
  Subject:
    Name: Router_A.cisco.com
    IP Address: 202.0.0.1
    Serial Number: 01C2F27F
    serialNumber=1C2F27F+ipaddress=202.0.0.1+hostname=Router_A.cisco.com
  Validity Date:
    start date: 15:21:49 UTC Feb 22 2005
    end   date: 15:21:49 UTC Feb 22 2006
    renew date: 00:00:00 UTC Jan 1 1970
  Associated Trustpoints: IOS_CAROOT

Router_B#show crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 06
  Certificate Usage: General Purpose
  Issuer:
    cn=IOS_CAROOT
  Subject:
    Name: Router_B.cisco.com
    IP Address: 202.0.0.2
    Serial Number: 46DDB4F1
    serialNumber=46DDB4F1+ipaddress=202.0.0.2+hostname=Router_B.cisco.com
  Validity Date:
    start date: 15:20:38 UTC Feb 22 2005
    end   date: 15:20:38 UTC Feb 22 2006
    renew date: 00:00:00 UTC Jan 1 1970
  Associated Trustpoints: IOS_CAROOT

Finally, the certificates displayed above are used to authenticate the IKE channel during Phase1 negotiation. Diagnostic and debugging output from Example 4-24 confirms that RSA Signatures are indeed used for IKE authentication, and that an ISAKMP SA has successfully been established using the RSA Signatures method of authentication.

Example 4-24. Verifying the Establishment of an ISAKMP SA Using RSA Signatures on Router_A

Router_A#debug crypto isakmp
!
!
*Feb 22 15:22:47.943: ISAKMP (0:1): SA is doing RSA signature authentication using id type
ID_FQDN
!
!
*Feb 22 15:22:47.947: ISAKMP (0:1): constructing CERT payload for
serialNumber=1C2F27F+ipaddress=202.0.0.1+hostname=Router_A.cisco.com
*Feb 22 15:22:47.947: ISAKMP (0:1): using the IOS_CAROOT trustpoint's keypair to sign
!
!
*Feb 22 15:22:52.987: ISAKMP (0:1): processing SIG payload. message ID = 0
*Feb 22 15:22:52.991: ISAKMP (0:1): SA authentication status:
        authenticated
*Feb 22 15:22:52.991: ISAKMP (0:1): SA has been authenticated with 200.0.0.2

Router_A#show crypto isakmp sa
dst          src            state            conn-id slot
200.0.0.2    200.0.0.1      QM_IDLE                1    0

Router_A#show crypto engine connections active

  ID Interface           IP-Address    State   Algorithm          Encrypt  Decrypt
   1 FastEthernet0/0     200.0.0.1     set     HMAC_SHA+3DES_56_C       0        0
2000 FastEthernet0/0     200.0.0.1     set     HMAC_SHA+AES_CBC         0        2
2001 FastEthernet0/0     200.0.0.1     set     HMAC_SHA+AES_CBC         2        0

IPsec SA Proposal Mismatches

Recall from our IPsec overview in Chapter 2 that the IPsec SAs cannot be established until there is an ISAKMP SA (unless manual keying is used). Up until this point, we've discussed common troubleshooting tactics for debugging Phase 1 negotiation errors. Now we will assume that an ISAKMP SA has been established and explore some common issues to troubleshoot in Phase 2 negotiation of the IPsec SA.

In order for two peers to successfully negotiate an IPsec SA, they must agree on three things specific to Phase 2 negotiation:

  • The IP addresses used for IPsec tunnel termination

  • The symmetric IPsec transforms to use on crypto-protected traffic after an IPsec SA has been negotiated

  • The scope of protected traffic in the crypto switching path

Note

Other items in the crypto path can be negotiated during Phase 2 negotiation even if they are mismatched. Such elements of the IPsec SA include the SA lifetime and perfect forward secrecy (PFS) group modulus.

Now that the routers in Figure 4-5 have been able to authenticate one another using RSA Signatures, and can establish an ISAKMP SA, we will insert an error in to the crypto map that prevents us from negotiating an IPsec SA. On Router_B, we will change the peering address to point to Router_C instead of Router_A. In Example 4-25, we will intentionally insert an incorrect peer on Router_B in order to illustrate peer mismatch diagnostic output on the IOS CLI in Example 4-26.

Example 4-25. Inserting a Peering Error on Router_B

Router_B#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router_B(config)#crypto map pki4 10
Router_B(config-crypto-map)#set peer 200.0.0.10
Router_B(config-crypto-map)#end
Router_B#

As expected, Router_A and Router_B can establish an ISAKMP SA, but are unable to complete Phase 2 negotiation due to the peering inconsistency introduced in Example 4-25. We can confirm the inconsistency by debugging the Phase 2 negotiation process using the debug crypto IPsec command. Example 4-26 provides diagnostic output indicating a peering address inconsistency on Router_B causing the IPsec SA negotiation to fail.

Example 4-26. Identifying IPsec Proposal Mismatch Issues

Router_A#debug crypto IPsec
Router_A#
Feb 24 11:52:30.196: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= 200.0.0.1, remote= 200.0.0.2,
    local_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
    lifedur= 5000s and 4608000kb,
    spi= 0x59ABE066(1504436326), conn_id= 0, keysize= 128, flags= 0x400B.....

Router_B#debug crypto IPsec
Router_B#
Feb 24 11:52:30.627: IPSEC(key_engine): got a queue event with 1 kei messages
Feb 24 11:52:30.791: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 200.0.0.2, remote= 200.0.0.1,
    local_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42
Feb 24 11:52:30.791: Crypto mapdb : proxy_match
        src addr     : 202.2.2.0
        dst addr     : 202.1.1.0
        protocol     : 0
        src port     : 0
        dst port     : 0
Feb 24 11:52:30.791: IPSEC(validate_transform_proposal): peer address 200.0.0.1 not found
Feb 24 11:52:30.795: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer
at 200.0.0.1
Feb 24 11:53:00.315: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 200.0.0.2, remote= 200.0.0.1,
    local_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42
Feb 24 11:53:00.315: Crypto mapdb : proxy_match
        src addr     : 202.2.2.0
        dst addr     : 202.1.1.0
        protocol     : 0
        src port     : 0
        dst port     : 0
Feb 24 11:53:00.315: IPSEC(validate_transform_proposal): peer address 200.0.0.1 not found

Let us now insert another error that causes Phase 2 negotiation failure. In Example 4-27, we will remedy the peering issue introduced in Example 4-25 and diagnosed in Example 4-26. We will also reconfigure the crypto transform in transform set "pki4," introducing a transform set mismatch with Router_A (Router_A uses esp-aes esp-sha-hmac for its transform).

Example 4-27. Correcting the Peering Inconsistency in Example 4-15 and Example 4-16 and Creating a Mismatched IPsec Transform Set on Router_B

Router_B#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router_B(config)#crypto map pki4 10
Router_B(config-crypto-map)#no set peer 200.0.0.3
Router_B(config-crypto-map)#set peer 200.0.0.1
Router_B(config-crypto-map)#exit
Router_B(config)#crypto IPsec transform-set pki4 esp-aes esp-md5-hmac
Router_B(cfg-crypto-trans)#end
Router_B#

As with IPsec peering inconsistencies, an IPsec transform set mismatch will not prevent the establishment of an ISAKMP SA. Indeed, the agreement of a transform to use occurs in Phase 2 negotiationthe negotiation of the IPsec SA. The routers in Figure 4-5 are now configured to use different transforms. Originally, Router_A and Router_B would use SHA1 Hash-based Message Authentication Code (HMAC) authentication in their transform sets. But, Router_B now uses the incorrect algorithm (MD-5 vs. SHA-1) to create the HMACs. As such, the routers are not able to agree on an IPsec proposal. As before, we will confirm this by debugging the IPsec crypto engine (debug crypto IPsec). The diagnostic output in Example 4-28 highlighted below confirms a mismatch in the IPsec transform causing a quick mode to fail to negotiate an IPsec SA.

Example 4-28. Diagnosing IPsec Proposal InconsistenciesIdentifying Mismatched IPsec Transform Sets

Router_A#
Feb 24 12:01:01.121: IPSEC(key_engine): request timer fired: count = 1,
  (identity) local= 200.0.0.1, remote= 200.0.0.2,
    local_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4)
Feb 24 12:01:01.121: IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= 200.0.0.1, remote= 200.0.0.2,
    local_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
    lifedur= 5000s and 4608000kb,
    spi= 0xEBD24B7A(3956427642), conn_id= 0, keysize= 128, flags= 0x400B

Router_B#
Feb 24 12:00:31.537: IPSEC(key_engine): got a queue event with 1 kei messages
Feb 24 12:00:31.705: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 200.0.0.2, remote= 200.0.0.1,
    local_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4),
    remote_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-aes esp-sha-hmac (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42
Feb 24 12:00:31.705: Crypto mapdb : proxy_match
        src addr     : 202.2.2.0
        dst addr     : 202.1.1.0
        protocol     : 0
        src port     : 0
        dst port     : 0
Feb 24 12:00:31.705: IPSEC(validate_transform_proposal): transform proposal not supported
  for identity:
    {esp-aes esp-sha-hmac }
Feb 24 12:00:31.705: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer
  at 200.0.0.1

Crypto-Protected Address Space Issues (Crypto ACL Errors)

As we had mentioned during our IPsec overview in Chapter 2 and earlier in this chapter, crypto-protected address spaces between VPN endpoints must be consistent for an IPsec SA to be established. These crypto-protected address spaces are defined with ACLs, commonly referred to as crypto ACLs.

When crypto ACLs specify inconsistent scopes of addresses between two peers, the expected result is that ISAKMP SA negotiation will complete successfully, but IPsec SA negotiation will fail. We will now walk through several examples of acceptable and unacceptable crypto ACL definition, and then explore some methods for diagnosing crypto ACL definition problems using Cisco IOS IPsec debugging capabilities.

Note

The protected address and port ranges specified in crypto ACLs are commonly shown as "proxies" in the crypto debugging output in Cisco IOS and ASA IPsec VPN endpoints.

The first case we will discuss demonstrates a crypto ACL definition that will facilitate successful IPsec SA negotiation. However, the next three examples of crypto ACLs present inconsistencies in crypto-protected address spaces that will cause Phase 2 SA proposals to be rejected. Configurations illustrating a valid crypto ACL match for Router_A and Router_B are provided in Example 4-29.

Note

The crypto ACL's described in Cases 2 through 4 below will not preclude Phase 2 SA negotiation when TEDv3 is used. Although the ACL's are inconsistent, TEDv3 probes will dynamically discover consistent crypto-protected scopes and install the appropriate information in the IPsec SADB. The use of TED is discussed in greater detail in Chapter 12, "Solutions for Handling Dynamically Addressed Peers."

Example 4-29. Crypto ACL Match

Router_A#show access-list 101
Extended IP access list 101
    10 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
Router_A#

Router_B#show access-list 101
Extended IP access list 101
    10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
Router_B#

In Example 4-30, Router_B has an extra access-list entry (ACE) in the crypto ACL (ACE #20). However, ACE 10 is consistent between routers A and B. As such, traffic matching ACE 10 will facilitate successful Phase1 and 2 SA negotiations. Traffic matching ACE 20 on Router-B will initiate a Phase 2 SA proposal that will be rejected by Router_A, which has no corresponding ACE in its Crypto ACL for Router_B's ACE 20 in crypto ACL 101. The traffic matching ACE 20 will subsequently be dropped. Example 4-30 provides the configurations on Router_A and Router_B illustrating the missing crypto ACE on Router_A.

Example 4-30. Crypto ACL Mismatch Due to Missing ACE on Router_A

Router_A#sh access-list 101
Extended IP access list 101
    10 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
Router_A#

Router_B#sh access-list 101
Extended IP access list 101
    10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
    20 permit ip 192.168.2.0 0.0.0.255 202.1.3.0 0.0.0.255
Router_B#

Example 4-31 provides a configuration in which the crypto ACLs on both Router_A and Router_B define scopes of protected address spaces that are inconsistent with the opposite peer's scope of protected source addresses. For example, Router_A protects traffic destined for any IP address that is sourced from 192.168.1.0/24. What would occur if traffic was sent from 192.168.1.1 to Router_A's physical IP address, 200.0.0.2? Router_A would encrypt the traffic as it matches ACE 10 in ACL 101. Router_B, however, would not encrypt the return traffic, as traffic sourced from 200.0.0.2 is not defined anywhere in its crypto ACL. For this reason, Phase 2 SA negotiation will fail when such an inconsistency is defined in the crypto ACL's of two IPsec peers.

Example 4-31. Crypto ACL Mismatch Due to Inconsistent Destination Address Ranges

Router_A#show access-list 101
Extended IP access list 101
    10 permit ip 192.168.1.0 0.0.0.255 any
Router_A#

Router_B#show access-list 101
Extended IP access list 101
    10 permit ip 192.168.2.0 0.0.0.255 any
Router_B#

In the case provided in Example 4-32, the ACL defines a tighter scope of address space on Router_B's crypto ACL. As such, if Router_B initiates the Phase 2 exchange, then an IPsec SA will be established successfully in the SADB, and traffic will pass. However, if Router_A initiates the Phase 2 exchange, the IPsec SA proposal will be rejected by Router_B for the same reasons discussed in Example 4-31.

Example 4-32. Crypto ACL Mismatch Due to Inconsistent Destination Address Scope on Router_B

Router_A#sh access-list 101
Extended IP access list 101
    10 permit ip 192.168.1.0 0.0.0.255 any (24 matches)
Router_A#

Router_B#sh access-list 101
Extended IP access list 101
    10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
Router_B#


Architectural and Design Issues with IPsec VPNs

Aside from issues related to configuring ISAKMP and IPsec policy, there is a variety of network elements that can interfere with optimal operation of an IPsec VPN if it is not managed correctly. In this section, we will discuss several of the most common troubleshooting challenges present IPsec VPN implementations today face. We will also discuss several effective techniques for diagnosing the problems that can result from improper design, and the appropriate solutions to remediate those problems.

Troubleshooting IPsec VPNs in Firewalled Environments

As we've discussed in our overview of the IPsec protocol in Chapter 2, many items need to be passed between two VPN endpoints in order to dynamically create tunnels securely using IKE and to successfully pass IPsec packets once a Phase 2 SA has been established. Most firewalls, by default, employ a "closed" model of security (by default, nothing is allowed) in which the firewall must be explicitly instructed to allow the required protocols through by an administrator. When deploying IPsec in firewalled environments, care must be taken to allow the required elements to securely pass, or problems could arise with VPN operation and performance. We will discuss two common issues in firewalled VPN environmentsfirewall fragmentation handling, filtering of required IPsec protocols, and filtering of Internet Control Message Protocol (ICMP) unreachables.

Allowing the Required IPsec Protocols to Pass

It is very common to see IPsec VPN sessions that traverse firewalls. One such example that we've discussed in Chapter 2 is in a DMZ design. Another popular application for such a design is in secure extranet designs. Most firewalls available in today's marketplace employ a closed policy by default, allowing no traffic to pass from low-security interfaces to interfaces assigned higher security levels. This includes protocols necessary for IPsec and IKE to operate effectively.

Unless manual IPsec session keys are used, firewalls between IPsec peers must allow ISAKMP traffic (UDP port 500) to pass between the IPsec VPN endpoints. Additionally, IPsec traffic must be allowed through the firewall, or encrypted traffic will get blocked at the firewall outside interface. These protocols include Encapsulating Security Payload (ESP) (IP Protocol 50) and Authentication Header (AH) (IP Protocol 51), depending on which of the two are included in the IPsec transforms used in that SA.

Note

Although IPsec transforms can include the ESP protocol, AH protocol, or both ESP and AH protocols together, it may not be necessary to open up firewall configurations to allow them both. Figure 4-6 assumes that all Remote Nets use ESP and AH. Administrators should verify the protocol selected in their IPsec transforms, as it may not be necessary to allow both ESP and AH through the firewall.

Figure 4-6. IPsec VPN Traffic Through Firewalls

[View full size image]

Figure 4-6 illustrates a firewalled IPsec VPN tunnel deployment in which tunnels are built from a central, firewalled aggregation site out to smaller remote locations.

Example 4-33 provides the firewall ACL configuration that is employed to enable IPsec tunnels to be built between the Campus_Net and Remote_Nets A, B, and C in Figure 4-6.

Example 4-33. Firewall Configuration for Crypto Traffic in Figure 4-6

DMZ-PIX-MAIN(config)#show access-list 101
access-list 101; 9 elements
access-list 101 line 1 permit udp host 160.1.0.2 host 201.1.1.1 eq isakmp
access-list 101 line 2 permit udp host 160.1.0.2 eq isakmp host 201.1.1.1
access-list 101 line 3 permit esp host 160.1.0.2 host 201.1.1.1
access-list 101 line 3 permit ah host 160.1.0.2 host 201.1.1.1
access-list 101 line 4 permit udp host 160.1.0.6 host 201.1.1.1 eq isakmp
access-list 101 line 5 permit udp host 160.1.0.6 eq isakmp host 201.1.1.1
access-list 101 line 6 permit esp host 160.1.0.6 host 201.1.1.1
access-list 101 line 3 permit ah host 160.1.0.2 host 201.1.1.1
access-list 101 line 7 permit udp host 160.1.0.10 host 201.1.1.1 eq isakmp
access-list 101 line 8 permit udp host 160.1.0.10 eq isakmp host 201.1.1.1
access-list 101 line 9 permit esp host 160.1.0.10 host 201.1.1.1
access-list 101 line 3 permit ah host 160.1.0.2 host 201.1.1.1
DMZ-PIX-MAIN(config)#show access-group
access-group 101 in interface outside

Firewall's Handling of Fragmented IPsec Packets

In addition to ensuring that the appropriate protocols are allowed to communicate through the firewall, it is critical that network designers should also account for the design considerations presented by the way that firewalls handle fragmented packets. When an IPsec packet is fragmented, the information relevant to the firewall's filtering decision, such as data found in the Layer 3 and 4 headers, is obscured in noninitial fragments.

Note

All fragments of a fragmented IPsec packet must be decrypted before they can be reassembled. This behavior can bypass the crypto hardware switching path, leading to performance degradation in IPsec networks. It is therefore critical to account for fragmentation issues in IPsec designs. We will discuss IPsec MTU and fragmentation issues and available solutions for fragment handling in IPsec networks (virtual fragmentation reassembly, IPsec prefragmentation, and path MTU discovery) later in this chapter.

As such, the firewall will potentially allow fragments to pass without inspection, as shown in Figure 4-7.

Figure 4-7. Firewall Fragment Handling in IPsec Networks

[View full size image]

Cisco PIX firewalls by default are configured to detect when a fragmented packet has been received and to make filtering decisions on the initial fragment and all noninitial fragments without actually reassembling the packet. This feature is called Virtual Fragment Reassembly. Virtual Fragmentation Reassembly provides the firewall with the ability to make filtering decisions on fragments without having to decrypt each packet in the fragmented chain. Virtual Fragmentation Reassembly does indeed consume computational resources on the firewall, but does provide an ideal solution when filtering decisions must be made on noninitial IPsec packet fragments.

Figure 4-7 demonstrates the improved handling of fragmented packets in IPsec networks. In the case illustrated in Figure 4-7 above, packets are being fragmented at an intermediary point between the two IPsec VPN gateways, ISP_GW_A and ENT_DMZ_IN. The DMZ firewall, ENT_FW, receives the fragments, and is configured for virtual fragmentation reassembly. The firewall therefore does not do any reassembly. Instead, it will initially allow only the first fragment in the fragment chain through without being inspected. Virtual Fragment Reassembly enables the firewall to inspect the remaining fragments of the original packet without reassembling the packet. Virtual Fragmentation Reassembly therefore plays a vital role in this example, as the firewall would have to decrypt each fragment in the chain in order to reassemble the packet, which it is not configured to do.

Filtering of ICMP Unreachables

ICMP unreachables are commonly used by hackers to find and exploit network vulnerabilities, and are a fundamental component of scanning techniques used to find openings in firewalled environments. As such, it is very common that firewalls not reply to filtered messages with ICMP unreachables. This behavior breaks a fundamental tool that IPsec can use to avoid the performance problems that can arise from fragmenting packets after encryptionPath MTU Detection (PMTUD).

As discussed in greater detail later in this chapter, PMTUD sends ICMP messages along the path, relying on information in ICMP unreachable messages to throttle down the MTU that the PMTUD device must fragment to before encrypting with IPsec. The insertion of a firewall along the PMTUD path effectively breaks this model, because it will suppress the response of the ICMP unreachable that is to carry MTU sizing information back to the fragmenting PMTUD device.

NAT Issues in IPsec VPN Designs

NAT was introduced to solve problems with the depletion of publicly available address space. It does this by translating the private source or destination IP addresses into public ones. As we had discussed previously in Chapter 2, "IPsec Fundamentals," IPsec was designed, in part, to prevent the manipulation of data while in transit between the two endpoints of the IPsec VPN tunnel. Considering that IPsec in tunnel mode protects the IP header from manipulation, incompatibilities arise when a device attempts to perform NAT on an IPsec packet protected in tunnel mode. This section will cover some intrinsic incompatibilities between the two technologies and explore some solutions for deploying them in tandem.

Intrinsic IPsec/NAT Incompatibilities

Deployment of IPsec VPNs in NAT environments should be approached with care, as there are many known incompatibilities between NAT and IPsec. The nature of NAT is to modify, or translate, a portion of the IP packet, specifically the source and destination addresses or ports, when the packet is en route from a given source to a given destination. The nature of IPsec is to detect and prevent the malicious manipulation of packets between a given source and destination. Therein lies the origin of IPsec/NAT incompatibilitiesthe nature of NAT is to manipulate a packet, while the nature of IPsec is to preserve the packet's integrity.

Recall from our discussion in Chapter 2 that IPsec defines a suite of protocols, such as AH and ESP, that can operate in different modes, such as tunnel or transport, and include varying degrees of authentication, or strengths in optional HMACs within a given transform. Because each protocol protects different portions of the IP packet in different ways, the effect of NAT can vary on a per-protocol basis. Some of the protocol-specific examples of inherent IPsec/NAT incompatibility include:

  • IPsec AH Keyed Message Integrity Check (MIC) Failures in NAT Environments

  • Inbound IPsec SA Selector Inconsistencies in NAT Environments

  • IKE Rekeying Failures in PAT Environments

  • Overlapping IPsec Security Policy Database Entries

  • IPsec Security Parameter Index Conflicts on NAT Devices

  • Embedded IP Address Translation Limitations

  • Unidirectional NAT Support

  • TCP and User Datagram Protocol (UDP) Checksum Failures

IPsec AH Keyed MIC Failures in NAT Environments

Authentication Header protocol includes source and destination addresses in the keyed MIC in order to provide a greater scope of authentication and integrity than the ESP protocol. Manipulating the source/destination address of the packet between VPN endpoints using AH will cause a MIC failure at the receiving VPN endpoint. ESP does not have this specific incompatibility, as source and destination information is not included in the integrity check.

Inbound IPsec SA Selector Inconsistencies in NAT Environments

If IKE authenticates Phase 2 selectors, and the initiator's source address is translated en route to the responder, then RFC 2401 requires that the responder drop the decapsulated packet, as the translated IP address does not match the SA selector value.

IKE Rekeying Failures in PAT Environments

An IKE responder must respond to IKE requests on the correct port. In nonPAT environments, this is UDP 500 by default. However, in situations in which IKE initiators have their ports translated to something other than 500, the IKE responder must be able to respond to the IKE request on the translated port, and must be able to do so predictably and reliably for IKE rekey messages to reach their correct destinations (correct IKE initiators).

Overlapping IPsec Security Policy Database Entries

When two or more IPsec initiators use their source address as its Phase 2 identifiers, an IPsec responder could view the two sources as identical. The responder could, therefore, potentially install overlapping security policy database entries for multiple sources. As a result, the responder is at risk of forwarding traffic over the incorrect SAs to its sources. The creation of overlapping security policy database entries in an IPsec responder resulting from duplicate NAT inside local addresses used as Phase 2 SA identifiers is illustrated in Figure 4-8.

Figure 4-8. SPD Confusion in NAT Environments

[View full size image]

IPsec Security Parameter Index Conflicts on NAT Devices

When two initiators attempt to negotiate a Phase 2 SA with the same destination, and Security Parameter Index (SPI)-based NAT is occurring between source and destination, SPI conflicts can sometimes occur on that NAT device leading to forwarding confusion from responder to initiator. Consider the scenario in Figure 4-9. The responder will install two different SPI entries (i.e., 2001 and 2002). However, because inbound and outbound SPI creation occurs independently of one another, the two initiators could indeed install similar SPI entries (i.e., both would claim to have installed SPI 2000 for the same destination). Because traffic from both Router_A and Router_B use the same UDP source port information, the NAT devices use overlapping SPIs for forwarding decisions. As a result, the traffic from the responder could be forwarded to the incorrect initiator due to the SPI conflict in the NAT device (i.e., the NAT device does not know which initiator to forward SPI 2000 traffic to).

Figure 4-9. SPI Overlap in NAT Device

[View full size image]

Embedded IP Address Translation Limitations

Some applications have addressing information embedded in to the payload of the IP packet. In both ESP and AH protocols, the payload of the packet is integrity protected. Therefore, changes to that payload, such as those NAT would attempt to execute, are not possible within the ESP and AH encapsulated payloads.

Unidirectional NAT Support

In some cases, a NAT device will install an NAT/PAT entry only once a packet is received from a given interface (i.e., inside to outside). Once that entry is installed on the NAT device, traffic can be forwarded in both directions. However, until that entry is installed, traffic received in other directions (i.e., outside to inside) will not get forwarded, as a NAT/PAT entry will not be dynamically created for traffic received on that interface.

TCP and UDP Checksum Failures

TCP and UDP checksums include IP source and destination addresses as part of the calculation. Therefore, translating the source or destination address with NAT can cause these checksum calculations after NAT processing. This problem arises in IPsec and NAT environments where TCP and UDP checksums are calculated and verified. This specific incompatibility does not affect IPsec in tunnel mode or IPsec+GRE, as neither of these methods requires validation of UDP/TCP checksums that use a translated source and destination IP address in their calculations.

IPsec NAT Transparency (NAT-T)

IPsec NAT-T enables an IPsec VPN endpoint to dynamically detect the support for NAT-T on its remote endpoint and to detect the presence of NAT devices between the two endpoints. If NAT is detected through the use of NAT-T, then the two endpoints will dynamically agree on the appropriate handling of IPsec NAT-T packets (such as UDP encapsulation of ESP packets, and so on). NAT-T, therefore, enables the two VPN endpoints to seamlessly establish an IPsec VPN endpoint across one or more NAT points that may exist between the two endpoints.

Consider the example described in Figure 4-10 in which two routers, Router_A and Router_B, communicate with one another through a firewall, Ent_FW.

Figure 4-10. The Operation of IPsec NAT-T

[View full size image]

Routers A and B are both capable of NAT-T, and dynamically agree on the handling of IPsec packets across the NAT'd path through the following sequence of exchanges:

1.
Router_A sends its vendor ID to Router_B during IKE Phase 1 negotiation. This phase of NAT-T is commonly referred to as a "NAT Support" exchange.

2.
Router_B sends its vendor ID string payload to Router_A during IKE Main Mode (MM1 and MM2, Phase 1) negotiation, letting Router_A know that it does indeed support NAT-T. This is also known as a "NAT Support" exchange in NAT-T context.

3.
After Routers A and B have agreed on NAT-T Support, they must determine if NAT exists between the two of them. This phase is commonly referred to as "NAT Detect." In this phase of NAT-T, multiple NAT-D payloads are exchanged between source and destination. NAT-D payload consists of an address and a hash. Each peer typically sends two NAT-D payloads to the other in main mode (MM3 and MM4)one for the destination address followed by another for the source address. When NAT-D payloads are sent between each peer, the hashes are verified at the remote end. If the hash values match, then it can safely be determined that NAT does not exist. If the hash values do not match, then it can safely be determined that NAT does exist.

4.
After NAT-D payloads are exchanged to detect NAT information, IPsec Quick Mode messages are exchanged to decide which peer (none, either, or both) will use NAT-T. This negotiation is performed during IKE Phase 2 in Quick Mode (QM1 and QM2).

5.
In Figure 4-10, inside source address translation is being performed by the PIX. IPsec endpoints have determined this behavior using NAT-T steps 1-4 described above. In this case, Routers A and B will both encapsulate ESP packets in UDP, hereby remedying three incompatibilities with IPsec and NAT:

- Incompatibility between ESP and AH with PAT

- Incompatibility between IKE fixed ports and PAT

- Incompatibility between UDP checksums and NAT (intermediate NAT-T UDP header checksum set to 0)

Note

As noted above, Cisco IOS will attempt NAT-T during IKE Phase 1 negotiation. Cisco IOS configures NAT-T automatically, and there is no manual configuration required. To disable the encapsulation of ESP packets in UDP using NAT-T, execute the following command from the IOS CLI:

Router_A(config)#no crypto IPsec nat-transparency udp-encapsulation

SPI-Based NAT

IPsec SPIs provide another element that a NAT device can use to forward data between two endpoints. When IPsec traffic is passed through a NAT device, various crypto-protected elements are often translated by NAT, including source IP addresses, destination IP addresses, source ports, and destination ports. Another field that can be use to populate the translation table in a NAT device is the IPsec SPI. As we had discussed previously, though, IPsec and NAT incompatibilities arise when overlapping IPsec tunnels with overlapping SPIs are passed through the NAT device.

Cisco IOS releases 12.2T and later employ a predictive SPI selection algorithm on IPsec crypto endpoints that enable them to select unique SPIs during IKE. This effectively enables a NAT device in the crypto path to use IPsec SPIs to build its translation table without encountering the translation and forwarding issues caused by overlapping SPIs discussed earlier in this chapter.

Consider again the scenario in Figure 4-9, but with predictively selected SPIs and SPI matching enabled on the NAT device. The NAT device is now capable of differentiating between multiple initiators (sources) in its forwarding table without the use of PAT. Instead, SPI matching is used to differentiate between the two IPsec VPN tunnel initiators, Routers A and B.

Note

Additional configuration information on IPsec and SPI-based NAT can be obtained at the following link with a valid CCO account:

The Influence of IPsec on Traffic Flows Requiring QoS

As networking technologies begin to mature and become more widespread, time- and delay-sensitive applications are increasingly migrating toward a converged solution. Many of these applications are considered critical to the needs of businesses in different vertical markets. As such, a need for guaranteed timely delivery and ordering of these applications emerges. In today's networked environment, a variety of QoS mechanisms exist to guarantee the timely delivery of delay-sensitive business critical data communications in IP networks. QoS in and of itself is so broad and deep in scope that we cannot cover it in its entirety. We will, however, discuss several common inconsistencies between IPsec and QoS that present design challenges:

  • Traffic Flow Hash Ubiquification: Flow-based QoS techniques, such as Weighted-Fair queuing (WFQ) rely on the original source and destination IP addresses of the packet to hash traffic flows in to "conversations." Certain IPsec protocols and modes effectively ubiquify the information needed to perform this hashing decisionthe source and destination IP address. Consider the example of IPsec ESP in Tunnel mode. In this example, the inner IP header will be encapsulated within the ESP boundary and encrypted. Therefore, if the router wants to use WFQ to hash this traffic flow into a conversation, it will not be able to, as it will be unable to read the encrypted original source and destination IP address. Because most VPN endpoints supporting QoS rely on flow-based QoS techniques such as WFQ and Low-Latency Queueing/class-based weighted fair queueing (LLQ)/(CBWFQ), it is critical that the IPsec VPN endpoint have the capacity to classify traffic flows before IPsec or generic routing encapsulation (GRE) encapsulation or both. Cisco IOS offers this functionality with the IPsec Preclassify feature.

  • Packet Reordering and the IPsec Antireplay Window: If packets are received outside of the antireplay window in an IPsec VPN, they will be dropped. The nature of QoS is to reorder packets, which can sometimes result in delay of queued traffic. It is critical to ensure that delays are not so long as to result in the packet being received outside of the antireplay window on the receiving VPN endpoint. Cisco IOS offers the capacity to extend the antireplay window on VPN endpoints to alleviate antireplay window errors if they should arise.

  • Packet Marking Obfuscation and (LLQ/CBWFQ): LLQ/CBWFQ is a QoS technique for reordering traffic flows locally on a network device. LLQ/CBWFQ requires that packets within a traffic flow be identified in some way. This is typically achieved by marking the packet by setting the DiffServ bits in the IP header. Network devices are therefore able to differentiate that traffic from other traffic flows and treat it (queue it) with the appropriate level of urgency. The scope of effect of LLQ/CBWFQ decisions is contained to the local device only.

  • Resource Reservation Protocol (RSVP): RSVP uses an exchange of RSVP signaling messages between two endpoints to reserve resources for delay-sensitive traffic between the two endpoints. Unlike LLQ/CBWFQ, where LLQ/CBWFQ classification and queuing decisions are local in scope, the scope of RSVP queueing decisions is end-to-end. Although RSVP can be configured to work in tandem with DiffServ-based QoS, it can also be configured to place traffic in the RSVP-reserved queue regardless of what type of DiffServ policy is configured on that specific network node.

Tip

For more detailed information on LLQ/CBWFQ and DiffServ, visit CCO at the following URLs:

DiffServThe Scalable End-to-End QoS Model http://www.cisco.com/en/US/partner/tech/tk543/tk766/technologies_white_paper09186a00800a3e2f.shtml

Implementing DiffServ for End-to-End Quality of Service http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1834/products_feature_guide09186a0080080466.html

As mentioned previously, QoS requires the use of end-to-end messaging techniques and the interpretation of certain bit values within the IP header. In some cases, if care is not taken during an IPsec/QoS deployment, IPsec can obfuscate the necessary messaging and IP header bits needed to deliver QoS. We will discuss QoS within this context, and explore some available techniques for delivering QoS within an IPsec VPN deployment.

IPsec's Influence on DiffServ and LLQ/CBWFQ

In this section, we will explore a Voice over IP (VoIP) deployment in a branch networking scenario. VoIP is delay-sensitivethat is to say that packets must be received in order with consistent delay (low jitter). As shown in Figure 4-11, two routers want to communicate with each other over a series of wide-area links of varying bandwidths. On the lower-speed links, packets can sometimes be dropped due to oversubscription of the available bandwidth. Therefore QoS is required to ensure that the voice (RTP) packets are not dropped when this occurs (other packets are dropped instead). For these reasons, QoS must be used for IP traffic over the Frame-Relay links.

Figure 4-11. IPsec and DiffServ in a VoIP implementation

[View full size image]

DiffServ is implemented in conjunction with LLQ/CBWFQ to deliver QoS for voice traffic to and from the branches. Because the company's security policy mandates confidentiality for voice traffic, IPsec VPNs have been configured between the enterprise headend router and all branch routers, posing several design considerations with the IPsec/DiffServ requirements:

  • If AH is used, changes to the IP header are not permitted (the AH MIC invalidates them on the receiving VPN endpoint). This prevents remarking on network devices between the phones. Therefore, RTP traffic must be marked accordingly prior to IPsec encapsulation (either on the routers or phones) if AH is used.

  • In both AH and ESP, if packets are received outside the antireplay window, they are dropped. Therefore, if traffic is delayed in queue due to QoS decisions, it could get dropped if it is received outside of the antireplay window at the opposite end of the IPsec VPN tunnel.

  • With ESP, the original IP header and QoS information is encapsulated in ESP and encrypted with the appropriate transform. This effectively renders the DiffServ bits needed for QoS unreadable by intermediate network nodes between the two IPsec VPN endpoints. Unless these bits are successfully copied to the outer IP header ESP encapsulation, network nodes between the two IPsec VPN endpoints may not appropriately classify the IPsec-processed RTP packet.

IPsec's Effect on IntServ and RSVP

In addition to issues outlined with the DiffServ and LLQ/CBWFQ, RSVP implementations with IPsec VPNs provide further design issues to address. As we had mentioned previously, RSVP provides a signaling method to proactively provision resources between a given source and destination. RSVP does so by exchanging a series of RSVP PATH and RSVP RESV messages between the source and destination. If intermediate network nodes between the RSVP source and destination are unable to decipher the RSVP RESV messages, as would be the case if they were encrypted in an IPsec VPN, intermediate network nodes cannot use the RSVP-RESV messages to dynamically reserve resources between source and destination (illustrated in Figure 4-12).

Figure 4-12. IPsec and RSVP Signaling Incompatibility

[View full size image]

Therefore, to dynamically provision resources on intermediate nodes between a source and destination that require timely, ordered delivery of IP-based application traffic, RSVP signaling messages must be forwarded outside of the crypto path.

Solving Fragmentation Issues in IPsec VPNs

In IPsec VPN environments, it is critical to address MTU and fragmentation issues. Otherwise, the entire VPN is at risk of performance and operation issues. We will discuss the effect of fragmentation reassembly and MTU issues in this section, and provide solutions for proper IPsec design in environments in which MTU is likely to be exceeded, resulting in fragmentation.

The effect of fragment handling between encryption devices is largely focused on the encryption device that is performing the reassembly of the fragmented packet. Although most network devices and VPN endpoints available today can fragment encrypted packets in the crypto-switched fast path, the decrypting IPsec endpoint must decrypt all fragments in the chain before the packet can be reassembled. Figure 4-13 illustrates an IPsec VPN deployment in which packets are reassembled prior to decryption on the destination IPsec VPN gateway.

Figure 4-13. Fragmentation Handling Between Encryption Devices

[View full size image]

This reassembly behavior is done at the process level and greatly affects the performance of the VPN. In IPsec environments, every precaution should be taken to fragment packets before they are encrypted with IPsec so that administrators can be assured that both fragmentation and reassembly is being done on devices with the appropriate computational resources available.

Path MTU Discovery

IP PMTUD is a technology that is used to dynamically discover the maximum MTU size between two endpoints such that the originating device fragments packets to the lowest MTU of the path. As such, PMTUD prevents intermediate network devices from fragmenting packets and causing excessive CPU overhead on the receiving IPsec endpoint doing the reassembly. Consider the scenario described in Figure 4-14, in which Host_A wishes to open a TCP session to Server_B across a routed IP network using Routers A, B, and C.

Figure 4-14. PMTUD and IPsec

[View full size image]

Administrators have enabled IP PMTUD on their workstations and servers such that fragmentation reassembly issues can be avoided on Router_B. Host_A executes PMTUD using the following process:

1. | Host_A creates an IP packet sized to the appropriate MTU of its locally attached segment and sets the DF bit before transmitting it to Server_B.
2. | Router_A receives the packet, notes that the DF bit is set. Router_A's serial link has an MTU of 1414. Because the DF bit is set and the packet from Host_A to Server_B exceeds the MTU of the serial interface, it is dropped.
3. | Router_A sends an ICMP Unreachable message back to Host_A, carrying the MTU (1414) of the next hop (the serial interface between Router_A and C).
4. | Host_A sends another ICMP message of 1414 bytes in length to Server_B with the DF bit set.
5. | Router_A receives the packet and forwards to Router_C. Router_C receives the packet, and notes that the DF bit is set. Because the DF bit is set and the packet is greater than the MTU of Router_C's link to Router_B (512), the packet is dropped.
6. | Router_C sends an ICMP Unreachable message back to Host_A, carrying the MTU (512) of the next hop (serial interface between Router_C and A).
7. | Host_A sends another ICMP message of 512 bytes in length to Server_B with the DF bit set.
8. | The 512 byte ICMP message is lower than the MTU of any individual link in the path. It is therefore successfully forwarded to Server_B. Server_B sends an ICMP Echo Response back to Host_A, indicating to Host_A that 512 is the MTU of the path.

Note

The routers in the above scenario are used to illustrate the general operation of PMTUD. IPsec and IPsec+GRE tunnels use a slightly different configuration of PMTUD than the previous, known as "Tunnel Path MTU Discovery." The specific operation of fragment handling using PMTUD in IPsec and IPsec+GRE environments is discussed in greater detail later in this chapter.

IPsec in Cisco IOS can be configured to copy the DF bit value in to the outer IP header in ESP-processed packets. As such, the ICMP traffic that PMTUD relies on to operate correctly does not have to be explicitly excluded from the crypto switching path.

There are several issues that must be addressed if PMTUD is to be part of one's design strategy to mitigate fragmentation reassembly issues in IPsec VPNs. In this section, we will briefly highlight some of the most common ones:

  • Permitting ICMP Unreachable Messages

  • Rate-Limiting ICMP Messages

  • PMTUD Not Supported on End-Hosts

  • Adjusting TCP Maximum Segment Size

  • Clearing the DF-Bit

Permitting ICMP Unreachable Messages

As we've discussed previously in our overview of the PMTUD protocol, PMTUD relies heavily on ICMP unreachable messages to communicate the MTU of segments back to the fragmenting host. It is very common for security devices, such as firewalls, to deny ICMP unreachable messages, as they are commonly used in malicious scanning techniques by hackers. As such, care must be taken to ensure that all paths between PMTUD-enabled endpoint be checked to ensure that ICMP unreachables are indeed allowed to pass if PMTUD is to be the preferred message for fragmentation avoidance along the path.

Rate-Limiting ICMP Messages

Because PMTUD relies on the receipt of ICMP Unreachable replies within a given retransmission window on the originating host, care should be given to rate-limiting techniques applied to ICMP messages, as they could cause premature retransmission of ICMP messages in PMTUD environments. If received out of order, ICMP unreachable messages in a PMTUD environment could cause confusion on MTU settings for the originating PMTUD host. For example, ICMP Unreachable messages delayed in rate-limiting queues could signal an erroneous MTU setting on the originating PMTUD host if that Unreachable message is received after a valid ICMP Unreachable with the correct IP MTU.

PMTUD Not Supported on End-Hosts

If PMTUD is disabled on the hosts within a network, it is recommended that the network administrator take steps to ensure that packets are fragmented in the network at some other location before crypto processing occurs. This can be achieved through enabling IPsec Lookahead Fragmentation in Cisco IOS and setting the DF bit in IPsec-processed packets. With IPsec Lookahead Fragmentation, the IOS IPsec VPN endpoint will attempt to determine the encapsulated packet size before it is encrypted. If the encapsulated packet size is predetermined to be larger than the path MTU, it is fragmented before encryption. When the DF bit is set, the encrypting router will look for information in any ICMP unreachable message received for updates it needs to install to the Path MTU entry in its SADB. Alternately, if the VPN endpoint does not support functionality similar to IPsec Lookahead Fragmentation or explicit setting of the DF bit in outer IP headers, the MTU of the IPsec VPN tunnel can be manually defined to avoid fragmentation reassembly issues.

Adjusting TCP Maximum Segment Size

Hosts sending IP packets greater than the TCP Maximum Segment Size (MSS) are at risk of fragmentation. Strictly speaking, the TCP MSS is the maximum amount of data that a host is willing to accept in an IP datagram. Hosts compare TCP MSS buffers sizes with MTU to determine the MTU for their transmissions. The result will be the lower of the TCP MSS or the MTU less 40 bits (an allocation for IP header and TCP header, both 20 bits in length). Once determined, each host communicates the selected values to the opposite host via the following exchange described in Figure 4-15.

Figure 4-15. TCP MSS, IP MTU, and Fragmentation

[View full size image]

The following order of events describes the sequence illustrated in Figure 4-15 above:

1. | Host_A has an MSS buffer of 20k and an MTU of 1500. It compares the MSS buffer with the MTU of the link, less a 40-bit allocation for IP and TCP header addition (1500 40 = 1460) and selects the lower value of 1460 (1460 < 20000) to send to Host_B.
2. | Host_B has a 16k MSS buffer and a 2048 interface MTU size. It does a similar comparison to Host_A's in step 1 and selects 2008 (2048 40). It then compares the received value from Host_A and selects the lower value of 1460 as its MSS value (1460 < 2008).
3. | Host_B signals its MSS of 2008 to Host_A.
4. | Host_A compares the received value of 2008 with its TCP MSS value derived in Step 1 and selects the lower of the two values, 1460, as its TCP MSS.

TCP MSS values use MTU values to help avoid fragmentation. In the example above, MTU values are selected, as they are smaller than TCP MSS values. However, if the MSS value were to be smaller than the MTU, then Hosts A and B will select the MSS + 40 bytes as the maximum packet length for TCP traffic. Note that, in this case, the larger MTU value would still be used for UDP traffic.

Clearing the DF-Bit

If the DF bit is cleared somewhere along the PMTUD path between source and destination, the network nodes along the path will fragment the ICMP PMTUD message rather than dropping it and replying with an ICMP unreachable. This will obviously break the operation of PMTUD. Most IP-enabled devices available today are capable of clearing the DF bit in an IP header.

Fragmentation Behavior on Cisco IOS VPN Endpoints

The overhead associated with IPsec and IPsec+GRE encapsulated IP packets can often lead to fragmentation, which is why PMTUD is, by default, enabled on IPsec VPN routers. However, the specifics of fragment handling and PMTUD differ slightly from nonVPN environments. In this section, we will discuss the handling of fragments in IPsec and IPsec+GRE tunnels and some additional solutions available for avoiding fragmentation in IPsec VPN environments.

IPsec VPNs use Tunnel Path MTU Discovery to interpret MTU information of ICMP Unreachable messages and update the Path MTU of the corresponding IPsec SA. The typical PMTUD operation and fragment handling of an IPsec VPN is illustrated in Figure 4-16.

Figure 4-16. Fragment Handling and PMTUD Operation with IPsec Tunnels

[View full size image]

The following describes the operation illustrated in Figure 4-16:

1. | Host_A sends a 1500-byte (size of the local interface MTU) packet to Server_B.
2. | Router_A receives the packet sent in 1 above, and observes that the ESP encapsulated packet size exceeds the MTU of the serial link to B. Because Host_A set the DF bit of the packet, Router_A drops the packet and sends an ICMP unreachable message containing the MTU size of 1442 (1500bytes58bytes max ESP overhead) back to Host_A.
3. | Host_A receives the ICMP Unreachable message with the MTU information, and forwards another ICMP packet of 1442 bytes in length to Router_A. Router_A encapsulates the packet with ESP and forwards it across the VPN with the DF bit set in the outer header.
4. | Router_C receives the ICMP message from Router_A in Step 3 and notes that the packet exceeds the MTU of its serial interface to Router_B. Because the DF bit is set, Router_C drops the packet and forwards an ICMP Unreachable to Router_A with the MTU size of 1440 embedded.
5. | Router_A receives the ICMP Unreachable message from Router_C in Step 4. Router_A notes the MTU size of 1440 in the PMTU field of the SA that is established with Router_B. Router_A does not send a new ICMP message of 1440 in length, but instead this is handled by Host_A in step 6.
6. | Host_A retransmits an ICMP message of 1442 in length, as it never received an acknowledgement from the original ICMP message sent in Step 2.
7. | Router_A compares the ESP-encapsulated packet size (1442+58) of the packet received in step 6 above with its path MTU (1440) and drops the packet. Router_A responds with an ICMP unreachable with the MTU of 1342 (1400 PMTU less ESP overhead of 58 bytes) embedded.
8. | Host_A sets its MTU to 1342 and forwards a new 1342-byte message to Server_B. The message and associated ESP overhead is now lower than the end-to-end path MTU, resulting in a successful transmission from Host_A to Server_B.

As we've discussed in previous sections of this chapter, and in others, it is sometimes necessary to encapsulate certain traffic types in GRE prior to processing them with IPsec. Processing of multicast traffic, for example, is one instance in which one would seek to encapsulate the plain text traffic in GRE prior to encapsulating it in ESP. This is commonly referred to as IPsec+GRE. This process includes an additional 24 bytes of overhead, as the GRE header is applied in addition to the ESP or AH headers. More importantly, it adds additional steps to the Tunnel PMTUD operation while trying to avoid fragmentation. Figure 4-17 illustrates the fragment handling process using PMTUD in an IPsec+GRE scenario.

Figure 4-17. Fragment Handling and PMTUD Operation with IPsec+GRE Tunnels

[View full size image]

The operation of PMTUD over an IPsec+GRE tunnel illustrated in Figure 4-17 is described by the following order of events:

1. | Host_A sends a 1500byte packet with the DF bit set to Server_B.
2. | Router_A receives the packet and observes that the DF bit is set. GRE encapsulation occurs prior to ESP encapsulation in this scenario, so the GRE process on the router drops the packet as the 1500byte packet + 24bytes of GRE overhead exceeds the GRE tunnel MTU of 1500. Router_A sends an ICMP Unreachable back to Host_A with an embedded MTU value of 1476 (1500GRE header length of 24).
3. | Host_A sends a 1476 byte packet with the DF bit set to Server_B.
4. | Router_A receives the packet, noting that the DF bit has been set. The router encapsulates the packet in GRE and then attempts to encapsulate it in ESP. The added ESP encapsulation pushes the MTU over the serial interface MTU of 1414, so Router_A drops the packet. ESP sends an ICMP error message to GRE indicating an MTU of 1376 bytes (1414 less max ESP header length of 38 bytes). GRE records this value as the new tunnel IP MTU.
5. | Host_A retransmits the 1476-byte packet in step 3, as no acknowledgement was received. Router_A drops this packet as it exceeds the tunnel IP MTU derived in step 4. Router_A responds with an ICMP Unreachable message with the tunnel IP MTU of 1414.
6. | Host_A sends a new ICMP message of 1414-bytes in length to Server_B. Router_A encapsulates in GRE, and then encapsulates in ESP. The DF bit is copied to the outer IP header in the ESP packet before transmitting across the IPsec VPN.
7. | Router_C receives the packet, and notes that the DF bit is set. The size of the packet is now 1414, as GRE and ESP headers have been added to the original ICMP message sent in step 6. Router_C drops the packet, as it exceeds the MTU of the link to Router_B and has the DF bit set. Router_C sends an ICMP unreachable message to Router_A with the MTU of 1400.
8. | Router_A receives the ICMP unreachable message from Router_C in step 7 above and updates the PMTU field of its IPsec SA to Router_B with the 1400-byte value.
9. | Host_A retransmits the 1414-byte ICMP message in step 6 to Server_B, as no acknowledgement was received.
10. | Router_A receives the packet, and encapsulates it in GRE. Once ESP encapsulation is applied, the length of the packet exceeds the 1400-byte IPsec SA PMTU obtained from Router_C in step 8. ESP sends an ICMP message to GRE with an MTU of 1342 (140058 bytes max ESP header length). GRE updates its tunnel IP MTU with this value.
11. | Host_A retransmits the 1414-byte ICMP message in step 6 again, as no acknowledgement was received from the retransmission in step 10.
12. | Router_A receives the packet and drops it as it exceeds the new GRE tunnel IP MTU of 1342 and has the DF-bit set. Router_A forwards an ICMP Unreachable to Host_A with an MTU value of 1318 bytes (1342 GRE MTU less 24 bytes GRE overhead).
13. | Host_A receives the ICMP Unreachable message sent from Router_A in step 12, and sends a new 1318-byte ICMP message to Server_B with the DF bit set.
14. | Router_A receives the packet, encapsulates it in GRE, encapsulates it in ESP, sets the DF bit in the outer IP header, and forwards to Router_C. This time, Router_C forwards the ICMP message originated from Host_A to Router_B.
15. | Router_B decapsulates the ESP packet, then decapsulates the GRE packet, and finally forwards the original ICMP PMTUD message to Server_B.
16. | Server_B acknowledges the receipt of the message, confirming that Host_A is to use an MTU size of 1338 bytes for this path.

Note

Although the DF bit in PMTUD ICMP messages is always set so as to properly detect areas of fragmentation, ICMP Unreachable responses to these messages are sent with the DF bit set to 0. As such, it is important to note that ICMP PMTUD messages sent from source to destination will never be fragmented, but the responses to those messages could quite possibly be fragmented along the return path.

Solutions for Preventing Fragmentation

In previous sections, we've discussed the most common method for preventing fragmentationPath MTU Discovery. However, as we have explored, the use of PMTUD is somewhat laborious for network devices to execute. Additionally, PMTUD may not be an option in networks that require the filtering of ICMP messages at various points within the network. As such, it is important to understand other ways in which fragmentation can be avoided when designing an IPsec VPN. We will discuss several techniques for mitigating IP fragmentation other than PMTUD in this section.

IPsec Prefragmentation

IPsec Prefragmentation is a Cisco IOS feature that enables an encrypting IPsec VPN endpoint to attempt fragmentation before encryption if a size of the encrypted packet and additional header information exceeds the MTU of the path in between endpoints. PMTUD can be used to determine the path of the SA and the MTU of that path. Doing so in conjunction with IPsec Prefragmentation provides a very scalable and manageable method of increasing the overall performance of an IPsec VPN where fragmentation after encryption is a possibility. Example 4-34 illustrates how to configure IPsec crypto DF-bit overwrite with IPsec Lookahead Fragmentation such that the path MTU of the SADB will be dynamically determined using tunnel PMTUD, and large packets will be fragmented (those exceeding the Path MTU for that SA in the SADB) before encryption.

Example 4-34. Enabling IPsec Prefragmentation with PMTUD and Crypto DF-bit Rewrite

Router_A#config
Router_A#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router_A(config)#crypto IPsec df-bit set
Router_A(config)#crypto IPsec fragmentation before-encryption
Router_A(config)#

Tip

Although in the case of Example 4-34, Router_A will attempt to fragment large packets before encrypting them, there are many configuration instances in which IPsec Lookahead Fragmentation and DF-bit overwrite are configured incorrectly. It is critical to understand the interdependencies of the DF-bit setting and the Lookahead Fragmentation setting addressing IPsec fragmentation design considerations. For a full listing of DF-bit interoperability with IPsec Lookahead Fragmentation settings, please refer to the following URL on CCO:

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/products_feature_guide09186a0080115533.html

Figure 4-18 illustrates a client server exchange that does not support PMTUD. Note that, even though there is no exchange of ICMP messages, the Path MTU is still discovered and updated in Router_A's IPsec SADB.

Figure 4-18. IPsec Fragment Handling Without PMTUD-Enabled Endstations

[View full size image]

There are three key operations that enable this feature:

  • Lookahead Fragmentation: Before forwarding an IPsec packet, Router_A predetermines the encapsulated packet size, and compares it with the MTU in the SADB. If it is predetermined to exceed that MTU size, the packet is fragmented before it is encrypted.

  • Crypto DF-bit Rewrite: When PMTUD is not supported, it is important that Router_A be able to set the DF bit in the outer IP header of IPsec-encapsulated packets. This prevents fragmentation, and triggers ICMP unreachables needed to adjust the Path MTU in Router_A's SADB.

  • Processing of MTU Information in ICMP Unreachables: Router_A is capable of deciphering MTU information of ICMP unreachables (received when IPsec packets with DF=1 are dropped). It uses this information to dynamically update the path MTU in its SADB.

The exchange between Router_A and Router_B in Figure 4-18 illustrates how all of these three features work in concert to minimize the effect of postencryption fragmentation in IPsec VPN deployments where PMTUD is note-enabled on the endstations:

1. | Host_A sends a 1500-byte data packet, destined for Server_B.
2. | Router_A receives the packet, and estimates the ESP encapsulated packet size before encrypting or forwarding the packet. Router_A compares the estimated encapsulated packet size with the Path MTU, and determines that the size is greater than the Path MTU and fragments the packet.
3. | Router_A applies the appropriate encapsulation to the fragments in the fragment chain. While doing so, it sets the DF bit of each encapsulated packet equal to 1.
4. | Router_C receives the packets from Router_A, compares them with the MTU of the Router_C to Router_B link, notes that DF=1, and drops larger packets accordingly. Router_C sends ICMP Unreachables for dropped packets to Router_A.
5. | Router_A receives the ICMP Unreachables from Router_C, and updates the MTU of its SADB accordingly.
6. | Host_A does not receive a reply to its original packet within the appropriate timeout window and therefore retransmits.
7. | Router_A performs Lookahead Fragmentation on the retransmitted packet, sizing the fragments to the new MTU in its SADB. It then sets the DF bit in each encrypted packet.
8. | The encrypted packets are now sized lower than any individual link MTU in the path (<1400 bytes), and are therefore received on Router_B. Router_B is now able to decrypt each fragment in the chain before they are reassembled, a process that is done in the fast switching path.
Manual MTU Adjustment

We've discussed the many tools available within Cisco IOS to avoid fragmentation in IPsec VPNs without having to manually tune the MTU sizes within the network. However, the option still exists to increase MTU size between IPsec VPN endpoints such that the risk of receiving a packet smaller than that MTU size is small. If one must tune MTU sizes to accommodate IPsec traffic between endpoints in a network, one should take the following disadvantages to this approach into consideration:

  • Scalability and Management: Remember that MTU sizes vary on a segment-by-segment basis. As such, it can become laborious for network administrators to consistently ensure that every segment's MTU is properly tuned. Network designers can anticipate the difficulty of manual MTU tuning to increase as the number of IPsec VPN connections and hosts scales upwards.

  • Serialization Delay: The MTU attribute exists to decrease serialization delay on networks. On segments that have artificially high MTU sizes, network administrators can expect increased delay as larger packets are serialized in queue. This adversely affects time- and delay-sensitive applications such as Voice and Video over IP.

Note

For more information on serialization delay and other common troubleshooting and design issues with VoIP, please refer to the following link on CCO:

Troubleshooting QoS Choppy Voice Issues: http://www.cisco.com/en/US/partner/tech/tk652/tk698/technologies_tech_note09186a00800f6cf8.shtml

The Effect of Recursive Routing on IPsec VPNs

Recursive routing commonly occurs when a router attempts to install a route over the same route that it is using to learn that route through a given RP. Because multicast updates inherent to most RP operations are unable to be crypto-switched, the effect of recursive routing is most commonly seen in the IPsec+GRE solution in which GRE is used to encapsulate RP traffic prior to IPsec (ESP or AH) encapsulation. We will explore a recursive routing situation in an IPsec+GRE scenario outlined in Figure 4-19.

Figure 4-19. Recursive Routing and IPsec+GRE Deployments

[View full size image]

The following order of events describes the influence of the recursive routing scenario in the IPsec+GRE deployment illustrated in Figure 4-19:

1. | Router_A and Router_B look up the GRE tunnel destination interfaces in their routing tables in order to build the GRE tunnel. They both find routes installed in their routing table for the appropriate tunnel destination interfaces and build the GRE tunnel accordingly using the statically configured default route (Example 4-35, line 30).
2. | Router_A and Router_B are configured to encrypt all GRE traffic between each other using ESP. Therefore, all exchanges across the GRE tunnel will be kept confidential.
3. | Router_A and Router_B inject all directly connected routes in to their routing protocol, Enhanced Interior Gateway Routing Protocol (EIGRP) AS1 (Example 4-35, line 24). This includes the loopback192 interfaces and the GRE tunnel interfaces.
4. | Router_A and Router_B build an EIGRP adjacency across the GRE tunnel and begin to exchange routing updates with one another.
5. | Router_A and Router_B learn the static routes installed in step 1 recursively across the GRE tunnel via EIGRP 1, and attempt to install the routes in the routing table. EIGRP learns a more specific route to the GRE tunnel destination than the default used in step 1 above.
6. | Once Router_A and Router_B are instructed to learn each other's tunnel destinations of the GRE tunnel interface (rather than via the static default routes in step 1), they determine that the behavior is recursive, and clear the route from the routing table. This causes both the GRE tunnel and the EIGRP adjacency to go down.

When a recursive routing situation occurs in an IPsec+GRE scenario, IOS CLI will write messages to the console, indicating the failure. Other symptoms indicative of recursive routing failure include RP adjacency loss across the GRE tunnel, which are also written to the IOS CLI. Example 4-35 shows recursive routing configuration errors described in Figure 4-19 and steps 1-6 above. Symptoms of recursive routing in IPsec+GRE scenarios are shown in Example 4-36.

Example 4-35. Configuration Errors Leading to Recursive Routing (Topology in Figure 4-19)

1  interface Loopback192
2  ip address 192.168.1.1 255.255.255.255
3  !
4  interface Tunnel 192
5  ip address 192.168.0.1 255.255.255.252
6  tunnel source Loopback 192
7  tunnel destination 192.168.2.1
8  !
9  !
10 interface Serial 1/0
11  ip address 200.0.0.1 255.255.255.252
12  encapsulation frame-relay
13  serial restart-delay 0
14  frame-relay interface-dlci 102
15  frame-relay lmi-type ansi
16 !
17 !
18 router eigrp 1
19  redistribute connected
20  network 192.168.0.0
21  default-metric 1500 100 128 128 4700
22  no auto-summary
23 ip classless
24 ip route 0.0.0.0 0.0.0.0 200.0.0.2

Example 4-36 provides the diagnostic output on Router_A that confirms that the GRE tunnel and EIGRP adjacency failures are due to the recursive routing behavior described above. Lines 10 and 18 show the presence of the static route that was used to build the GRE tunnel prior to occurrence of recursive routing. However, line 18 of Example 4-36 shows that there is a recursively learned EIGRP route to the tunnel destination (192.168.2.1) over the tunnel interface itself (next hop of 192.168.0.2). Because this route is more specific than the default route, EIGRP installs it in the routing table, causing the tunnel to fail due to recursive routing (as confirmed in Example 4-36, lines 20 and 21). Once the tunnel fails, EIGRP tears down the adjacency, as illustrated in Example 4-36, line 22.

Example 4-36. Recursive Routing Symptoms and Diagnostic Output in Cisco IOS

1  Router_A#show ip route
2  Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
3         D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
4         N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
5         E1 - OSPF external type 1, E2 - OSPF external type 2
6         i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
7         ia - IS-IS inter area, * - candidate default, U - per-user static route
8         o - ODR, P - periodic downloaded static route
9
10 Gateway of last resort is 200.0.0.2 to network 0.0.0.0
11
12       200.0.0.0/30 is subnetted, 1 subnets
13 C        200.0.0.0 is directly connected, Ethernet0/0
14       192.168.0.0/30 is subnetted, 1 subnets
15 C        192.168.0.0 is directly connected, Tunnel192
16       192.168.1.0/32 is subnetted, 2 subnets
17 C        192.168.1.1 is directly connected, Loopback192
18 D        192.168.2.1 [90/297372416] via 192.168.0.2, 00:00:04, Tunnel192
18 S*    0.0.0.0/0 [1/0] via 200.0.0.2
19 Router_A#
20 *May 8 15:42:10.439: %TUN-5-RECURDOWN: Tunnel192 temporarily disabled due to recursive
     routing
21 *May 8 15:42:11.439: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel192,
     changed state to down
22 *May 8 15:42:11.447: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.0.2
(Tunnel192) is down: interface down

In order to prevent this behavior, the administrators of Router_A ensure that the route to the GRE tunnel destination is not learned over the GRE tunnel itself. This can be accomplished by excluding the routes used to establish the GRE tunnel from being redistributed in to EIGRP using either a route-map or distribute list. Example 4-37 provides an example of how to accomplish this using an EIGRP route-map.

Example 4-37. Controlling EIGRP Route Redistribution with Route-Maps and ACLs

access-list 1 deny 192.168.1.0
!
route-map no-recursive permit 10
 match ip address 1

Example 4-38 provides an alternative to excluding routes from the EIGRP redistribution using a distribute list. In the context of this particular example, the configuration in Example 4-38 will accomplish the same task as the route-map configuration in Example 4-37.

Example 4-38. Controlling EIGRP Route Redistribution with Distribute Lists

router eigrp 1
 redistribute connected
 network 192.168.0.0
 default-metric 1500 100 128 128 4700
 distribute-list 1 in
 no auto-summary
!
access-list 1 deny 192.168.1.0
access-list 1 permit any

Example 4-39 shows an example of EIGRP and GRE tunnel reestablishment once the appropriate route-map and ACL combination have been applied to the EIGRP routing protocol process using the redistribute connected route-map [route-map-name] command.

Example 4-39. GRE Tunnel and EIGRP Adjacency Reestablishment when Excluding Redistribution of Recursively-Learned Routes Using Route-Maps and ACLs

router eigrp 1
 redistribute connected
 network 192.168.0.0
 default-metric 1500 100 128 128 4700
 no auto-summary
!
crvpn-3600-a#conf t
Enter configuration commands, one per line. End with CNTL/Z.
crvpn-3600-a(config)#router eigrp 1
crvpn-3600-a(config-router)#redistribute connected route-map no-recursive
*May 8 16:27:44.191: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.0.2 (Tunnel192)
is up: new adjacency


Summary

In this chapter, we've covered several different broader areas of common issues with IPsec VPN deployments. The first area of common IPsec VPN issues we discussed pertains to configuration of ISAKMP and IPsec themselves, including

  • IKE SA Proposal Mismatches

  • IKE Authentication Errors

  • IPsec SA Proposal Mismatches

  • Crypto ACL Mismatches

When IKE is used, an IKE Phase 1 SA must be established before any additional IPsec SA negotiation can occur. The first task that crypto endpoints must accomplish to build an IKE SA is agreement on IKE SA proposals. We've discussed IKE SA proposal mismatches in the context of each of the following attributes that must be agreed on for a successful IKE SA proposal match:

  • IKE Authentication Method (PSKs, RSA Encryption, or RSA Signatures)

  • IKE Encryption Cipher (DES, 3DES, AES)

  • IKE Hash Algorithm (MD5, SHA1)

  • Diffie-Hellman Group Modulous (1, 2, or 5)

  • IKE SA Lifetime (60-86400 seconds)

Once IKE SA proposals have been agreed upon, the IKE SA must be authenticated. In this chapter, we've explored common techniques for IKE SA proposal troubleshooting and IKE SA authentication troubleshooting with each of the three IKE SA authentication methodsIKE PSKs, RSA Encryption, and RSA Signatures. The methods presented in this chapter can be used to diagnose problems with IKE SA establishment and authentication and verify the existence of an IKE SA before proceeding to investigate potential issues with IPsec SA establishment.

Unless IPsec SAs are manually defined, an IKE SA must exist on the crypto endpoints before an IPsec SA can be established. Once an IKE SA has been confirmed to exist, measures should be taken to confirm that the two crypto endpoints have agreed on IPsec SA proposals. In this chapter, we've discussed techniques IPsec SA failures attributable to mismatches in each of the following attributes:

  • The IP addresses used for IPsec tunnel termination

  • The symmetric IPsec transforms to use on crypto-protected traffic after an IPsec SA has been negotiated

  • The scope of protected traffic in the crypto switching path

When each of the previous attributes match, an IPsec SA can be formed. Techniques for verifying IPsec SA establishment were provided above to confirm the existence of an IPsec SA and the details of IPsec SA proposal agreed upon by the two crypto endpoints.

In addition to discussion of thorough discussion of configuration issues with IPsec VPN deployments, we have also introduced and discussed various architectural issues with IPsec VPN deployments. Unlike configuration issues, architectural issues pertain to incompatibilities and common design challenges when integrating IPsec with different technologies commonly found in the larger system architecture. Architectural issues discussed in this chapter include:

  • IPsec in Firewalled Environments

  • IPsec in NAT Environments

  • IPsec and QoS Inconsistencies

  • IPsec and Fragmentation

  • IPsec+GRE and Recursive Routing

When deploying IPsec through a firewall, several intrinsic design challenges surface. First, the appropriate protocols need to be allowed to pass for the IPsec and ISAKMP traffic to pass through the firewall. Recall that, for an IKE SA to establish successfully, UDP 500 must be allowed through. Once an IPsec tunnel has been built over IKE, the appropriate IP protocol number must be allowed (IP Protocol 50 for ESP and IP Protocol 51 for AH) for encrypted traffic to pass through the firewall. In our discussion of IPsec, we have also discussed the effect of fragmentation and the critical role that IP Unreachables play in PMTUD when preventing IPsec fragmentation after encryption. Firewalls typically do not send IP Unreachables. Therefore, when IPsec is deployed in conjunction with firewalls, it is important to ensure that MTUs are appropriately sized for the IPsec tunnel via some method other than PMTUD.

One primary strength of IPsec as a VPN technology is assurance that data is not manipulated while in transit between two crypto endpoints. When a NAT device is introduced between two crypto endpoints, often parts of the packets in transit are manipulatedspecifically the source IP address, destination IP address, source ports, and destination ports. This behavior causes many intrinsic incompatibilities between NAT and IPsec, including:

  • IPsec AH Keyed MIC Failures in NAT Environments

  • Inbound IPsec SA Selector Inconsistencies in NAT Environments

  • IKE Rekeying Failures in PAT Environments

  • Overlapping IPsec Security Policy Database Entries

  • IPsec Security Parameter Index Conflicts on NAT Devices

  • Embedded IP Address Translation Limitations

  • Unidirectional NAT Support

  • TCP and UDP Checksum Failures

IPsec introduces design challenges when deployed in conjunction with QoS. In this chapter, we've discussed how IPsec makes source and destination hash information opaque to intermediate notes that require that hash information to make Weighted-Fair Queueing decisions. We've also discussed how IPsec ubiquifies RSVP signaling information needed by intermediate notes to guarantee end-to-end QoS between to IP endpoints. IPsec incorporates protection against rollback attacks through incorporating an antireplay window. When QoS delays the transmission of encrypted packets outside of the antireplay window on the receiving host, the packet is dropped.

It is important to ensure that fragmentation in IPsec networks is facilitated before encryption takes place. This is because, when a decrypting IPsec endpoint receives a fragment chain, all of the fragments in the chain must be decrypted before the packet can be reassembled, an operation that is performed in the process-switched path. This behavior causes substantial performance and scalability considerations in IPsec VPN endpoints. Proper fragmentation is therefore a paramount design consideration to validate in an IPsec VPN deployment. In this chapter, we have provided several methods for ensuring that fragmentation in IPsec VPN deployments is executed properly, before encryption with IPsec.

The last architectural issue we have discussed in this chapter pertains to recursive routing in IPsec+GRE environments. Recall from our previous discussions that IPsec+GRE is a popular design choice, as it accommodates multicast traffic in the crypto switching path. Care must be taken when building GRE deployments that routes used to build the GRE tunnel are not then learned recursively over the GRE tunnel itself, resulting in the teardown of the GRE tunnel and the corresponding routing protocol adjacency formed over that tunnel.

In the following chapters, we will discuss resilient and highly available IPsec designs that build upon sound IPsec fundamentals introduced in this chapter and in previous chapters. When exploring each of the designs presented in subsequent chapters, it is important to consider each in the context of the common issues with IPsec VPN deployments presented in this chapter.


Part II: Designing VPN Architectures

Chapter 5 Designing for High Availability

Chapter 6 Solutions for Local Site-to-Site High Availability

Chapter 7 Solutions for Geographic Site-to-Site High Availability

Chapter 8 Handling Vendor Interoperability with High Availability

Chapter 9 Solutions for Remote Access VPN High Availability

Chapter 10 Further Architectural Options for IPsec


Chapter 5. Designing for High Availability

IPSec is a Layer 3 virtual private network (VPN) technology, offering a wide array of options to execute when designing for High Availability (HA). In this chapter, we will review some of the concepts that impact the availability of an IPSec VPN and introduce specific components of IPSec that present the opportunity to design HA in to the architecture. This chapter provides an introduction to five major areas for designing HA into an IPSec VPN system architecture:

  • Network and Path Redundancy IPSec VPNs require connectivity between two IP interfaces for tunnel termination. Redundancy can be built into the path between those two points so as to eliminate any single point of failure between the two IPSec tunnel termination endpoints.

  • IPSec Tunnel Termination Redundancy Terminating or originating an IPSec VPN tunnel from a single interface could decrease the overall availability of the design in a failover scenario. We will discuss several methods for designing HA into the tunnel termination endpoints of an IPSec VPN, including the use of highly available interfaces and the use of redundant interfaces with Hot Standby Router Protocol/Virtual Router Redundancy Protocol (HSRP/VRRP).

  • Managing Path Availability The setup and teardown of SAs can lead to increased reconvergence times in failover situations, eventually leading to a decreased level of availability in the overall system design. We will discuss several tools and practices for managing path availability in an IPSec VPN designed for HA.

  • Managing Path Symmetry In order to ensure that the control plane information required to establish, maintain, and tear down Phase 1 and 2 IPSec SAs can be communicated successfully between two IPSec VPN tunnel termination points, there must be a means by which to ensure that the IPSec control plane traffic follows the same return path as its original path. In this chapter, we will explore how path asymmetry can prevent successful negotiation and operation of an IPSec VPN tunnel when two stateless firewalls are injected in between the two tunnel termination endpoints.

  • Load Balancing Load balancing is traditionally more focused on increasing the overall performance and scalability of IPSec VPN deployment, but the effective use of clustering and load balancing in the design also indirectly improves availability. We will discuss several areas of the overall system architecture that can be balanced across multiple IPSec VPN components in the context of improving the overall availability of the IPSec VPN design.

The scope of this chapter is limited to presenting an overview of HA concepts and areas in which HA can be built in to an IPSec VPN; therefore, specific design solutions for local and geographic IPSec HA are not discussed in this chapter, but rather discussed in Chapter 6, "Site-to-Site Local HA Solutions," Chapter 7, "Site-to-Site Geographic HA Solutions," and Chapter 9, "Remote Access VPN High Availability."


Network and Path Redundancy

IPSec VPNs are a La:yer 3 VPN technology for securing IP traffic and therefore rely on a stable IP-enabled foundation for stability and HA. As such, one critical design consideration for IPSec VPNs is the incorporation of resiliency and HA between the two IP-enabled termination points of the IPSec VPN tunnel. Consider the three sample network topologies illustrated in Figures 5-1 through 5-3. We will use these topologies to illustrate how IPSec HA increases as single points of failure within the underlying IP foundation between the two IPSec tunnel termination points are eliminated.

Figure 5-1. Site-to-Site VPN without Path Redundancy

[View full size image]

The topology in Figure 5-1 illustrates a scenario in which no redundancy is designed into the underlying IP infrastructure. This type of design provides many different points at which the IPSec VPN tunnel could fail due to a failure in one of the many nodes in between the termination points of the IPSec tunnel:

  • Interface Failure The two serial interfaces connecting WAN_EdgeA and WAN_EdgeB present single points of failure for the VPN tunnel. If one of those interfaces on either router were to fail, then the Internet Key Exchange (IKE) and IPSec SAs comprising the IPSec VPN tunnel would have to be renegotiated upon recovery of that interface. IPSec can be configured to use multiple interfaces to eliminate these failure points, increasing the availability of the IPSec VPN. Figure 5-2 illustrates a topology in which path redundancy is designed between two VPN gateways at the interface level on WAN_EdgeA and WAN_EdgeB.

    Figure 5-2. Dual-Interface Path Redundancy

    [View full size image]

  • WAN Infrastructure/Carrier Failure In the design illustrated in Figure 5-1, the integrity of the IPSec VPN tunnel depends directly on the stability of the WAN link between WAN_EdgeA and B. A failure on the provider network would cause the IPSec VPN tunnel to be renegotiated once the failure is repaired. For traffic requiring higher availability in the crypto path, a backup WAN link can be deployed, as depicted in Figure 5-2.

  • Node Failure Even with redundancy built into the design at an interface and link level between the two IPSec VPN gateways, there still exists the possibility that the IPSec VPN tunnel could fail due to a system failure on the VPN gateway itself. Figure 5-3 depicts a topology that provides a greater degree HA at the WAN edge.

    Figure 5-3. WAN Gateway, Interface, and Carrier Redundancy

    [View full size image]

The topology in Figure 5-3 eliminates all single points of failure between sites A and B, including interface-level, link-level, and node-level failure points. Although it is the most costly of the three designs, the topology in Figure 5-3 provides the greatest degree of path availability for the IPSec VPN tunnel, and it is therefore the soundest IPSec HA design.

Figures 5-1 through 5-3 illustrate how designing resiliency into the infrastructure supporting an IPSec VPN tunnel increases the effectiveness of the IPSec HA design itself by stepping through the elimination of single points of failure. Every removal of a single point of failure along the IPSec VPN tunnel path, however, also increases the cost of the overall solution. As a result, administrators should consider the business requirements of application data to be included in the encrypted path when investing in this area of IPSec HA.


IPSec Tunnel Termination Redundancy

The IPSec HA design in Figure 5-3 eliminates all single points of failure between the two tunnel termination points of the IPSec VPN except onethe tunnel termination point itself. Indeed, all of the network topologies discussed up to this point present single points of failure at the actual tunnel termination point itself. In this section, we will discuss three methods for designing HA into the termination of the IPSec VPN tunnel:

  • Tunnel Termination on Highly Available Interfaces Terminating the IPSec tunnel on an interface that is resilient to the failure of any other physical interface on the gateway increases the availability of the IPSec Tunnel.

  • Tunnel Termination on HSRP/VRRP Virtual Interfaces With Cisco IOS, IPSec VPN tunnels can be terminated on HSRP Virtual Interfaces. This effectively allows box-level redundancy at the termination points of the IPSec tunnel itself.

  • Tunnel Termination with Multiple Peer Statements Redundant IPsec VPN peer statements can be used to provide redundancy to multiple redundant points of termination on the opposite end of the IPSec VPN tunnel.

In addition to these tunnel termination redundancy methods, redundancy can be built into the IPSec VPN tunnel infrastructure between the termination points of the IPSec VPN tunnel. The availability of the routing protocol that provides the underlying transport between IPSec VPN tunnel termination points therefore has a material impact on the system-level IPSec VPN HA.

Multiple Physical Interface HA with Highly Available Tunnel Termination Interfaces

Now that redundancy has effectively been built into the path between the two tunnel termination points of the IPSec VPN tunnel (Figure 5-3), what happens when a failure occurs on one of the actual IPSec tunnel termination points themselves? All of the extra funding invested in path HA would be negated by such a failure. Figure 5-4 extends the design depicted in Figure 5-3 to include termination-point redundancy using high-available loopback interfaces.

Figure 5-4. Tunnel Termination on Highly Available Interfaces

[View full size image]

The design illustrated in Figure 5-4 extends path HA to the tunnel termination point itself by utilizing a secondary Fast Ethernet port on the VPN gateways, IPSec_A and IPSec_B. Cisco IOS allows the administrator to source the IPSec VPN tunnel from a loopback interface on IPSec_A and IPSec_B, effectively allowing the two VPN gateways to maintain the IPSec VPN tunnel independently of a failure on one of the two Fast Ethernet interfaces on the box. Likewise, the target termination points are loopback interfaces, allowing for tunnel termination point HA on both the origination and termination sides of the IPSec tunnel.

Tunnel Termination HA Using HSRP/VRRP Virtual Interfaces

Using loopback interfaces to terminate the IPSec VPN tunnel, as displayed in Figure 5-4, allows the VPN gateways to leverage redundant interfaces (Fa0/0 and Fa0/1) on IPSec_A and IPSec_B for increased HA. However, this solution does not provide redundancy in a scenario in which the gateway itself fails. To design for box-level tunnel termination point redundancy, HSRP/VRRP virtual interfaces can be used to originate and terminate the IPSec VPN tunnel. Figure 5-5 presents an extension of Figure 5-3 that includes box-level tunnel termination HA using an HSRP Virtual Interface.

Figure 5-5. Tunnel Termination Point HA Using HSRP Virtual Interfaces

[View full size image]

The design illustrated in Figure 5-5 allows for a greater scope of tunnel termination redundancy. Not only does it eliminate the termination interface itself as a single point of failure, but it also eliminates the VPN gateway itself as a single point of failure. For example, if IPSec_A1 were to experience a total system failure due to, say, a power failure in the building, IPSec_A2 would take over as the IPSec VPN tunnel termination point, thereby preserving the consistency of the IPSec VPN. This type of design has two variations:

  • Stateless IPSec HA Stateless IPSec HA describes a situation in which a IPSec VPN tunnel is terminated on a virtual interface using HSRP and VRRP, but no state is communicated between the redundant IPSec VPN gateways in the HSRP group that are serving as the physical points of termination for the IPSec VPN tunnel. This method of box-level tunnel termination redundancy involves a teardown of the IPSec VPN tunnel itself using IKE keepalives when a failure occurs on the active HSRP router (IPSec_A1/B1 in Figure 5-5). Once this teardown occurs, a new tunnel is created using the same virtual interface. This process involves the renegotiation of Phase 1 and 2 SAs with the newly active HSRP/VRRP-enabled HSRP Router. As we'll discuss in Chapter 6, "Site-to-Site Local HA Solutions," the teardown and renegotiation of SAs in a stateless design can lead to a somewhat lengthy reconvergence of the IPSec VPN tunnel in a failover scenario. For environments where reconvergence is critical and HA needs are paramount, a stateful IPSec HA design should be considered.

  • Stateful IPSec HA Stateful IPSec HA can also be deployed using the same topology as a stateless IPSec HA design, such as the one in Figure 5-5. Unlike stateless IPSec HA designs, stateful IPSec HA designs are capable of communicating the state of the IPSec and ISAKMP SADB to the redundant IPSec VPN gateway in the HSRP/VRRP group prior to failover. This allows the IPSec VPN tunnels on the failed node to failover to the redundant node without the remote end of the IPSec VPN tunnel noticing that a failover has occurred. With IPSec VPN gateways running Cisco IOS, SADB information is communicated from the active IPSec VPN gateway to the standby IPSec VPN gateway using Stateful Switchover (SSO) and the Stream Control Transport Protocol (SCTP). The communication of SADB information between active and standby VPN gateways in the HSRP group allows the standby IPSec VPN gateway in the HSRP/VRRP group to take over as the IPSec VPN tunnel termination point in failover scenario without the teardown and renegotiation of Phase 1 and 2 SAs required in stateless IPSec HA operations (the standby router already has those SAs in its SADB prior to failover). The deprecation of the requirement of reaping stale SAs and renegotiating new ones in a failover scenario leads to dramatically reduced reconvergence times with stateful IPSec HA.

Note

The details of stateful and stateless IPSec HA design between routers in an HSRP group, including configuration, failover operations, and steps to minimize reconvergence delay impact, are discussed in greater detail in Chapter 6, "Site-to-Site Local HA Solutions."

HA with Multiple Peer Statements

In many cases, such as in situations in which geographic IPSec HA is required, it may not be feasible to terminate an IPSec tunnel on a virtual interface using HSRP and/or VRRP. Figure 5-6 depicts an example of one such situation.

Figure 5-6. Geographic IPSec HA Using Multiple Peering Statements in Each Crypto Map on IPSec_A1, A2, B1, and B2

[View full size image]

In Figure 5-6, IPSec_A1 and IPSec_A2 are now located in different wiring closets, and therefore do share the same Layer 3 boundary facing the WAN edge routers (WAN_EdgeA1 and WAN_EdgeA2). The same conditions exist at site B for routers IPSec_B1 and IPSec_B2. As such, HSRP or VRRP hellos cannot be sent between IPSec_A1 and A2 or between IPSec_B1 and B2 for IPSec tunnel termination on a virtual interface. In this situation, multiple peering statements can be included in the crypto maps for routers IPSec_A1, A2, B1, and B2, creating a backup IPSec VPN tunnel for encrypted traffic on egress from each IPSec VPN gateway. Figure 5-7 shows the loopback-to-loopback IPSec peering sessions between IPSec_A1, A2, B1, and B2 using redundant peering statements to protect traffic from Network_A to Network_B in the encrypted path.

Figure 5-7. Loopback-to-Loopback IPSec Peering Sessions with Redundant Peer Statements

[View full size image]

Note

Further explanation of design considerations and configuration of sourcing and terminating IPSec tunnels on loopback interfaces can be found in Chapter 6, "Site-to-Site Local HA Solutions." More detail on IPSec VPN design with redundant IPSec peering statements can be found in Chapter 7, "Site-to-Site Geographic HA Solutions."

RP-based IPSec HA

Because IPSec itself is a Layer 3 VPN technology, IPSec is dependent on the existence of a stable IP transport between tunnel termination points to operate effectively. This means that IPSec requires accurate and timely updating of routing information on intermediate nodes between the termination points of the IPSec tunnel.

The routing protocol of the IP infrastructure underneath the IPSec tunnel is responsible for communicating routing information to nodes in between the IPSec tunnel termination endpoints. If there is an RP failure between the two termination points of the IPSec tunnel, then IPSec traffic will not be able to flow between the two endpoints, eventually leading to expiration of the previously negotiated SA lifetimes or timeout of the IKE keepalives (if enabled). Fortunately, IPSec is not path-discriminateIPSec traffic will take any available Layer 3 path from the tunnel source to tunnel destination before tearing down the tunnel. Administrators can therefore leverage the use of routing protocols between tunnel endpoints to provide numerous routed paths between source and destination.

Figure 5-8 illustrates a design in which the dedicated WAN circuits incorporated into the designs in Figures 5-1 through 5-7 are replaced with uplinks to an ISP, presenting a much higher degree of HA beyond the interface of the WAN_Edge routers. The ISP has many different paths through which to route packets between the WAN_Edge routers as opposed to just one with the dedicated WAN circuits.

Figure 5-8. RP-Based HA between IPSec Tunnel Termination Points

[View full size image]

Therefore, by replacing the dedicated WAN circuits between the WAN_Edge routers with dual uplinks on each router to an ISP, the design in Figure 5-8 affords the IPSec VPN a much greater degree of RP-based HA, since the number of Layer 3 paths between endpoints has been greatly expanded. Furthermore, through the use of dual uplinks to the ISP, the design makes no concession in interface-level or box-level IPSec HA. In fact, the design in Figure 5-8 can use the same loopback-to-loopback peering model with redundant peering statements on each IPSec VPN gateway illustrated in Figure 5-7. The change in transport from dedicated WAN circuits to dual uplinks to the ISP on each gateway, while providing greater HA to the IPSec VPN itself, does not necessarily change the peering model of the IPSec VPN itself.

Warning

You may have noticed already that, as with most value-added services, increased HA usually comes with increased cost. In the context of the design illustrated in Figure 5-5, this cost is represented by the doubling of fee-based WAN links on the WAN_Edge routers (8 ISP uplinks versus 4 dedicated WAN circuits). Because of this, investing in increased HA is a business decision, and the needs of the business should be carefully evaluated when investing in the increased benefit of added IPSec HA. If overlooked, administrators face the risks associated with over-designed IPSec deployments, including increased maintenance, management, complexity, and costs.


Managing Peer and Path Availability

In any IPSec VPN design, it is important to ensure that both IPSec peers are available to one another, reachable through the IP-enabled infrastructure. An IPSec peering point can be thought of as a tunnel termination point. Each IPSec VPN tunnel endpoint must know how to source the IPSec VPN tunnel locally and how to reach the target termination point (its IPSec peer) from the tunnel source in order to successfully negotiate a Phase 2 SA. This requirement is referred to as peer availability. It is also important to ensure that when peers are unavailable to one another, the SADB is managed properly so that IPSec VPN tunnels are allowed to reconverge in HA environments.

Note

Improper management of peer availability can lead to the existence of stale SAs, prohibiting rapid reconvergence of IPSec VPNs in failover scenarios. The impact of stale SAs on IPSec HA designs is discussed in detail in Chapter 6, "Site-to-Site Local HA Solutions," and Chapter 7, "Site-to-Site Geographic HA Solutions."

Once peer availability has been addressed, it is important to make sure that the encrypted path (the IPSec VPN tunnel) is available to traffic to be included in the encrypted path. In other words, traffic to be encrypted must be able to be effectively routed through the IPSec VPN tunnel. This is referred to as crypto path availability. There are several common instances in which path availability may be impeded, the most common of which is when routing protocol traffic cannot be leaked between cleartext- and ciphertext-routed domains. This particular scenario effectively blocks the availability of the path for traffic to be included in the encrypted path, as either cleartext domain will not know how to route to the other because RP updates are not natively exchanged across the IPSec VPN tunnel or ciphertext routed domain. We will discuss this particular example in greater detail later in this section.

Peer Availability

In this section, we will explore features of IPSec and ISAKMP that can be used to manage peer availabilityDead Peer Detection (DPD) and IKE keepalives. Consider the scenario illustrated in Figure 5-9, in which the primary peering point of an IPSec VPN gateway becomes unavailable.

Figure 5-9. Peer Availability with DPD and IKE Keepalives

[View full size image]

When an IPSec peer goes offline, the SADB retains the security associations for that peer for the length of the lifetimes negotiated during Phase 1 and 2 SA negotiations. For example, if two IPSec VPN gateways establish IKE and IPSec SAs using the default lifetimes IPSec tunnel were to fail, stale IKE and IPSec SAs could remain present in the SADB for up to 86400 seconds (1 day) and 3600 seconds (1 hour), respectively. This behavior, if not managed properly, can lead to confusion when negotiating new SAs with new peers (see Chapter 6, "Site-to-Site Local HA Solutions," and Chapter 7, "Site-to-Site Geographic HA Solutions," for more detail on IPSec High Availability) and inefficient use of memory on the IPSec gateway itself.

Although these SAs would remain in the SADB of the remote IPSec SADB for an excessively long time, there are methods of reaping stale SAs from the SADB in a more expedient fashion. The default behavior of Cisco IOS is to use on-demand Dead-Peer Detection. On-demand DPD expedites the discovery and removal of stale SAs by sending out DPD status query messages when the status of the remote peer is questionable and there is traffic to be forwarded in the crypto path to that peer. Consider the scenario illustrated Figure 5-9, in which IPSec_B1 fails. IPSec_A uses on-demand DPD to expedite the discovery and removal of SAs with the dead peer, IPSec_B1, using the following steps:

1. | A failure occurs on IPSec_B1, preventing it from successfully terminating the IPSec VPN tunnel from IPSec_A.
2. | IPSec_A receives traffic from the workstations at Site_A and must forward the traffic across the encrypted path to Site_B through its IPSec VPN tunnel to IPSec_B1.
3. | IPSec_A forwards a DPD status query message to IPSec_B2 in order to determine the status of the peer.
4. | IPSec_B1 is unable to respond to the DPD status query message sent by IPSec_A. Steps 3 and 4 are retried a number of times, corresponding to the specified retry value.
5. | IPSec_A waits to receive a response to its DPD status query message sent in Step 3. When it receives no response from IPSec_B1, IPSec_A begins to purge its SADB of the security associations previously negotiated with IPSec_B1.

One important element of the DPD process described above is the fact that with on-demand DPD, traffic must be forwarded to the remote peer to initiate the discovery of the dead peer (Step 2). If traffic is not sent to that peer, then the DPD status query message will not be forwarded to the remote peer, and the tunnel SAs will remain installed in the local gateway's SADB for the duration of their previously negotiated lifetimes. This could potentially cause issues with reconvergence if, for example, a redundant IPSec tunnel were to be negotiated over the redundant path between Site A and Site B. One way of eliminating stale SAs in such a scenario is to enable the use of IKE keepalives, which provision for the removal of stale SAs from the SADB regardless of whether or not traffic is actively being forwarded to the dead peer. The process of SA removal with IKE keepalives, also depicted in Figure 5-9, operates in the following manner:

1. | The primary IPSec gateway for Site B goes offline.
2. | The IPSec gateway for Site A forwards its first IKE keepalive to the dead peer at Site B
3. | Site A's IPSec gateway does not receive a response to the first IKE keepalive within the configured keepalive interval (default of 10 seconds). Site A's IPSec gateway forwards a second IKE keepalive to the dead peer at Site B.
4. | Site A's IPSec gateway does not receive a response to the first IKE keepalive within the configured keepalive interval. Site A's IPSec gateway forwards a third IKE keepalive to the dead peer at Site B.
5. | After Site A has waited the duration of the keepalive interval without receiving a response to its third IKE keepalive, it declares that its peer at Site B is dead and removes the security associations with Site B's IPSec gateway from its own local SADB.

The two concepts described above are critically important when designing large-scale enterprise IPSec deployments. On-demand DPD and periodic DPD provide two different methods of proactively detecting stale SAs left over from dead IPSec peering sessions. On-demand DPD requires traffic along the encrypted path to initiate DPD status queries and consumes less overhead than periodic DPD (IKE keepalives), while periodic DPD can proactively detect dead peers without the presence of traffic in the encrypted path. Improper management of the IPSec SADB can lead to operational issues in HA environments and platform scalability issues specifically relating to excessive CPU utilization on platforms managing DPD for a large number of SAs. We will discuss the use of DPD to streamline the reconvergence process of an IPSec tunnel in our discussion of IPSec High Availability in Chapter 6, "Site-to-Site Local HA Solutions," and Chapter 7, "Site-to-Site Geographic HA Solutions."

Path Availability

As we have already mentioned in our discussion of the IPSec protocol in Chapter 3, "Basic VPN Topologies and Configuration," IPSec will not encrypt multicast traffic without the use of a prior instantiation of encapsulation using another tunneling protocol such as GRE. In many designs, it may be desirable to separate routing protocol domains while still joining routed domains between the two opposite ends of the IPSec tunnel, as shown in Figure 5-10.

Figure 5-10. IPSec and Multicast RP Updates

[View full size image]

In situations where RRI is not an option, this may require the exchange of RP updates across the VPN tunnel. Because most RPs use updates that are forwarded to multicast addresses, RP updates often cannot be exchanged across an IPSec tunnel without encapsulating them in GRE prior to encryption. As we have discussed before, this is commonly referred to as IPSec+GRE. IPSec+GRE tunnels are not only useful in designs where encrypted RP updates are required, but they are critically useful in networks where encrypted multicast application data is required.

One alternative to IPSec+GRE for encrypted RP update exchange using IPSec is to configure the RP to use unicast updates, rather than multicast updates. Configuring of unicast neighbors in RP processes come with added configuration, management, and scalability issues. However, in simpler site-to-site IPSec VPN environments, the configuration of unicast updates can be configured with a minimal increase in management and administration while eliminating the overhead added by GRE headers in an IPSec+GRE scenario.

Unlike most routing protocols, Border Gateway Protocol (BGP) natively uses unicast updates by establishing a TCP session on port 179. Therefore, RP updates using BGP can be sent through the crypto switching path without the use of GRE prior to encryption. Encrypted BGP updates are useful in designs requiring inter-AS connectivity between disparate IGP RP domains. Like unicast RP updates, BGP updates eliminate packet overhead and encapsulation inherent to IPSec+GRE designs. This method represents the fourth method of preserving RP information between two routed domains on opposite ends of an IPSec VPN tunnel that we've discussed in this chapter. The complete list of methods is as follows:

  • Reverse Route Injection (including static routes)

  • Multicast routing updates encapsulated in GRE

  • Unicast RP updates using unicast IGP neighbor definition

  • Unicast RP updates with BGP

Depending on the crypto platform selected, packets encapsulated in GRE may not be forwarded in hardware, regardless of whether or not some method of crypto hardware assist is present on the IPSec VPN gateway. It is therefore critically important to evaluate all options of preserving RP consistency across the VPN tunnel so as not to force traffic outside of the fast crypto switching path by unnecessarily using GRE on a platform that does not support the encapsulation of GRE packets in hardware.


Managing Path Symmetry

IPSec is a stateful protocol, meaning that it relies on the maintenance of a state table (SADB) and security associations (SAs) to process information in the crypto switching path. It is therefore important to make sure that traffic is sent to, and received from, the appropriate tunnel termination points present in Phase 2 SAs. Figure 5-11 illustrates a situation in which the IPSec VPN tunnel is broken due to path asymmetry.

Figure 5-11. IPSec VPN Failure Due to Path Asymmetry

[View full size image]

In Figure 5-11, a failure occurs on the IPSec tunnel between IPSec_A and IPSec_B due to asymmetric routing. In this case, all RP traffic is sent in the clear, resulting in one contiguous RP domain. When a failure occurs between INET_A and IEDGE_B1, the routing protocol reconverges in a manner that causes asymmetric routing between Site_A and Site_B. Specifically, after the failure, resources on Site_A chooses Path #1 to Site_B, while Site_B chooses Path #2. All interfaces on both IPSec_A and IPSec B are configured for IPSec, but there is a firewall prohibiting IPSec reconvergence along Path #2. This example illustrates just one scenario in which IPSec VPN tunnels can be broken when asymmetric paths exist between tunnel endpoints. We will discuss several methods for guaranteeing path symmetry in an IPSec VPN, including the tuning of routing protocol for path symmetry and the role of HSRP-based IPSec tunnel termination in path symmetry.

One way to resolve issues with IPSec reconvergence issues due to path asymmetry is to alter the routing protocol metrics to ensure that the IPSec VPN is originated and terminated on the appropriate source and destination tunnel endpoints, respectively. Figure 5-12 illustrates a situation in which the adjustment of routing protocol metrics on IEDGE_B2 and IEDGE_A2 help to avert IPSec issues due to a routing protocol reconvergence issues upon a serial link failure between INET_A1 and IEDGE_B1.

Figure 5-12. Adjusting RP Metrics to Avoid Issues with IPSec and Path Asymmetry

[View full size image]

In Figure 5-12, the IEDGE routers at both Site_A and Site_B are configured to forward traffic to the next hop of IPSec_A1 and IPSec_B1, respectively, unless the IPSec VPN gateways are down. This configuration helps to avoid the path symmetry problems experienced previously, as illustrated in Figure 5-11, regardless of any topological changes in between Site_A and Site_B that may cause a shift in the Layer 3 paths between IPSec VPN gateways.

Note

There are many ways to instantiate the RP metric changes to achieve the behavior discussed above and illustrated in Figure 5-12static routes would be one option, policy-based routing could be another, and hard-coded routing protocol metrics yet another. The specific methods of RP tuning, however, are outside of the scope of this discussion.


Load Balancing, Load Sharing, and High Availability

Load balancing between IPSec VPN tunnels provides some of the benefits of High Availability but, in general, meets a different set of design objectives than does HA. When discussing HA designs, we have typically included designs in which redundancy is built into the IPSec system. Specifically, these are designs that have IPSec VPN tunnels which are used strictly for backing up encrypted communications when the primary IPSec VPN tunnel is downonly one tunnel, main or standby, is used at a time.

When traffic is load balanced between multiple IPSec VPN tunnels, the traffic flows are divided and shared across the IPSec VPN tunnels. Unlike the redundancy options discussed up to this point, a load-balancing design uses multiple IPSec VPN tunnels simultaneously and therefore does not take a main/backup approach to IPSec VPN design. That said, load-balanced designs provide some degree of HA, since when any one of the IPSec VPN tunnels supporting the load-balanced design fails, the remaining operational IPSec VPN tunnels can assume the extra load that was originally forwarded through the failed IPSec VPN tunnel. In this section, we will explore several methods for building load-balanced IPSec VPN designs.

Load-Sharing with Peer Statements

IPSec VPNs can use the underlying routing protocol to load balance encrypted traffic across multiple paths. Although the effectiveness of load-balancing IPSec VPN tunnels using routing protocol depends somewhat on the capabilities of the routing protocol itself (such as equal-cost load-balancing capabilities within OSPF), a load-balanced solution also requires the appropriate configuration of crypto ACLs, crypto maps, and crypto peers.

Figure 5-13 illustrates a scenario in which the crypto ACLs are configured to load balance traffic between two IPSec VPN tunnels between IPSec_A and IPSec_B.

Figure 5-13. Multiple Peer Statements and Load Balancing

[View full size image]

Routing-protocol traffic between the two IPSec VPN endpoints, IPSec_A and IPSec_B, is exchanged in cleartext, allowing the IPSec tunnels to be built, as in Figure 5-13. RRI is used to preserve routing continuity between the two routed domains on opposite ends of the IPSec tunnel between IPSec_A and IPSec_B. The traffic flows in Figure 5-13 are forced over the two IPSec tunnels in a load-shared format by configuring the crypto ACLs to forward traffic over the corresponding tunnel to the appropriate peer IP addresstraffic from 10.1.1.0/24 to 10.1.2.0/24 takes Path #1, while traffic from 10.2.1.0/24 to 10.2.2.0/24 takes Path #2. Examples of proper and improper usage of load balancing with alternate peering statements are illustrated in Examples 5-1 and 5-2, respectively.

Example 5-1. Using Multiple Peering Statements for Load Balancing and Redundancy

crypto map chap5-loadbal 10 ipsec-isakmp
! #<--200.0.0.2 is the destination tunnel termination address for the encrypted
! traffic flow specified in crypto ACL 101-->
set peer 200.0.0.2
set transform-set chap6-dualint
! #<--Crypto ACL 101 defines the first encrypted traffic flow. Traffic
! matching the ACL 101 will be encrypted and routed to 200.0.0.2
! for decryption-->
match address 101
reverse-route
crypto map chap5-loadbal 10 ipsec-sakmp
! #<--200.0.0.4 is the destination tunnel termination address for the encrypted
! traffic flow specified in crypto ACL 102-->
set peer 200.0.0.4
set transform-set chap6-dualint
! #<--Crypto ACL 102 defines the first encrypted traffic flow. Traffic
! matching the ACL 104 will be encrypted and routed to 200.0.0.4
! for decryption-->
match address 102
reverse-route
!
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255
access-list 102 permit ip 10.2.1.0 0.0.0.255 10.2.2.0 0.0.0.255

Note that in Example 5-1, traffic is manually shared between two different tunnel termination endpoints, 200.0.0.2 and 200.0.0.4, by splitting the traffic flows out into separate crypto ACLs, 101 and 102. Let us now look at a configuration example where multiple peers are used, but only for pure redundancy and no load balancing.

Using the configuration listed in Example 5-2, IPSec_A uses 200.0.0.2 as the destination tunnel termination address for the encrypted traffic flow specified in crypto ACL 101. If 200.0.0.2 is unavailable, the crypto engine will use 200.0.0.4 for IPSec peering for traffic matching ACL 101. Unlike Example 5-1, ACL 101 is configured to match all traffic flows. This results only in IPSec tunnel termination point redundancyno load sharing is achieved..

Example 5-2. Using Multiple Peering Statements for Redundancy Only

crypto map chap5-redundant 10 ipsec-isakmp
set peer 200.0.0.2
set peer 200.0.0.4
set transform-set chap6-dualint
match address 101
reverse-route
!
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.1.2.0 0.0.0.255
access-list 101 permit ip 10.2.1.0 0.0.0.255 10.2.2.0 0.0.0.255

Routing

Remember that one key benefit of Layer 3 (L3) encryption technologies, like IPSec over Layer 2 (L2) encryption technologies, is that traffic flows can be kept confidential and secure over multiple L2 domains. It is therefore important that the underlying routing protocol between IPSec tunnel termination endpoints be configured to evenly distribute IPSec traffic across multiple available L3 paths en route to the appropriate target tunnel termination point. Figure 5-14 shows some examples of appropriate and inappropriate IPSec traffic distribution across multiple routed paths between the tunnel termination endpoints.

Figure 5-14. Intermediate RP Impact on IPSec Traffic Flow Distribution

[View full size image]

Domain Name System (DNS)

IPSec clients can be configured to use DNS to resolve the IP address of their IPSec peer. This allows designers to use DNS server load balancing to distribute the number of IPSec sessions across multiple IPSec VPN concentrators. In this type of design, the DNS server would resolve the same hostname to multiple addresses. When it receives a query from one of the IPSec clients to resolve the concentrator's hostname to a given IP address to be used for Phase 1 and 2 negotiations, the DNS server would return the first IP address associated with the concentrator's hostname. The DNS server would then continue to map subsequent resolutions to the other addresses mapped with the concentrator's hostname, yielding a round-robin distribution of inbound IPSec sessions from the IPSec VPN clients across the various IPSec VPN concentrators. Figure 5-15 illustrates the mechanics of a DNS-based, load-balanced IPSec RAVPN implementation.

Figure 5-15. DNS-Based Load Balancing

[View full size image]

Note

The Cisco IPSec VPN 3000 series of VPN concentrators support load balancing through concentrator clustering. We will discuss this method of load balancing later in this section. However, when using concentrators where clustering is not supported, DNS-based load-balancing solutions present an effective alternative to load-balanced RAVPN solutions.

The following sequence of operations corresponds to the order of operations illustrated in Figure 5-15, outlining the DNS-based load balancing of IPSec tunnels from VPN clients to the IPSec VPN cluster:

1. | IPSec_Client5a initiates Phase 1 negotiation with the concentrator using the hostname IPSec_Cluster5. The client attempts to resolve the hostname with its configured DNS server in order to identify the peer IP address.
2. | The DNS server returns the first IP address in the name record for IPSec_Cluster5, 200.1.1.1 (the first concentrator in the cluster).
3. | IPSec_Client5a initiates an IKE and IPSec SA negotiations with the first concentrator in the cluster using the peer IP address of 200.1.1.1.
4. | IPSec_Client5b attempts Phase 1 negotiation with the concentrator using the hostname IPSec_Cluster5. The client attempts to resolve the hostname with its configured DNS server in order to identify the peer IP address.
5. | The DNS server returns the second IP address in the name record for IPSec_Cluster5, 200.1.1.2 (the second concentrator in the cluster).
6. | IPSec_Client5b initiates an IKE and IPSec SA negotiations with the second concentrator in the cluster using the peer IP address of 200.1.1.2.
7. | IPSec_Client5c initiates Phase 1 negotiation with the concentrator using the hostname IPSec_Cluster5. The client attempts to resolve the hostname with its configured DNS server in order to identify the peer IP address.
8. | The DNS server returns the third IP address in the name record for IPSec_Cluster5, 200.1.1.3 (the third concentrator in the cluster).
9. | IPSec_Client5a initiates an IKE and IPSec SA negotiations with the third concentrator in the cluster using the peer IP address of 200.1.1.3.

Caution

The example above illustrates a basic round-robin distribution of DNS resolutions as clients request the IP address corresponding to the name of their VPN Concentrator. Take care when configuring your DNS server to ensure that the DNS name resolutions are being returned in the appropriate order with which you would like the sessions to be load balanced across your VPN concentrators.

Subsequent clients follow the same round-robin approach since the DNS server returns the three IP addresses in a round-robin fashion each time a name resolution request for IPSec_Cluster5 from the clients. This results in an even distribution of IPSec client sessions within the concentrator cluster.

Cisco VPN3000 Concentrator Clustering

VPN concentrator clustering enables network administrators to effectively distribute the load of IPSec VPN tunnels from remote IPSec VPN clients. Recall that DNS-based load balancing maps multiple VPN concentrator IP addresses to a common DNS name which all clients use to establish their IPSec VPN tunnels. DNS-based load balancing of IPSec sessions therefore provides a round-robin distribution of inbound IPSec VPN sessions on the concentrator IP addresses that share the same hostname.

Note

VPN3000 Clustering is a Cisco proprietary function. For environments that use IPSec VPN concentrators from other manufactures, another alternative such as DNS-based load balancing should be considered.

One major limitation of this type of deployment is that the DNS server that is doing the load balancing has no awareness of the current load on the concentrator to which it is effectively assigning the next inbound IPSec VPN session. This is not the case in a clustered deployment of IPSec VPN3000 concentrators. VPN3000 concentrators can be configured to intelligently direct inbound IPSec VPN connections from IPSec clients to the concentrator with the lowest load. This is accomplished through Virtual Cluster Agent (VCA) protocol communications between the VPN3000 concentrators in the cluster.

Each concentrator in the VPN3000 cluster running the Virtual Cluster Agent protocol is considered to be a Virtual Cluster Agent (VCA). Within the cluster, there is a master VCA and secondary VCAs. The master VCA monitors the load of the secondary VCAs using the VCA protocol to determine which concentrator has the lowest load and, subsequently, which concentrator to redirect the next IPSec VPN tunnel initiation request to. We will discuss the step-by-step process of inbound IPSec VPN tunnel termination from remote IPSec VPN clients on a VPN3000 concentrator cluster, but first let's discuss the VCA configuration tasks that must be accomplished on the VPN3000 to achieve IPSec VPN load balancing within the cluster:

  • VPN Virtual Cluster IP Address This is the IP address that the remote IPSec VPN clients use as their IPSec peer address in Phase 1 and 2 negotiations. As the VCA master will distribute (load-balance) these inbound IPSec VPN sessions to the concentrator with the lowest load in the cluster, all concentrators within the VPN3000 cluster must share this address.

  • VPN Virtual Cluster UDP Port Number This is the UDP port number that the VCA master will use to communicate with the secondary VCAs to gather load information from each VPN3000 concentrator in the cluster.

  • Encryption and Shared Secret VCA communications between concentrators in the cluster can be encrypted using IPSec. If encryption is enabled, then a shared secret key must be entered to cipher and decipher the communications between the VCA master and its secondary VCAs.

  • Enabling Load Balancing The load-balancing enable radio button must be checked for the VPN3000 concentrator to participate in the cluster.

  • Priority Concentrators within a cluster are assigned a priority to determine which cluster will assume the role of the master VCA. The first concentrator in the cluster assumes the role of master VCA; subsequent concentrators to come online within the cluster are secondary VCAs. When the master VCA fails, then the concentrator with the highest priority assumes the role of master VCA. If upon master-VCA failure two secondary VCAs share the same priority, the concentrator with the lowest IP address will break the tie and become master VCA. Table 5-1 shows the default priority for various VPN3000 models.

Table 5-1. VPN3000 Priority Default Settings

VPN Concentrator Model

Priority Default

3005

1

3015

3

3020

4

3030

5

3060

7

3080

9

Note

Remote Access High Availability is discussed more comprehensively in Chapter 9, "RAVPN High Availability," including the detailed configuration of VCA clustering on VPN3000 series IPSec VPN concentrators and ASA5500 series VPN appliances.

Figure 5-16 depicts a scenario in which inbound IPSec VPN sessions are load-balanced between a cluster of Cisco VPN3000 concentrators.

Figure 5-16. IPSec Session Load Balancing Using VPN3000 Concentrator Clustering

[View full size image]

Next, we will explore the steps taken when a new remote IPSec VPN client initiates an IPSec tunnel to the concentrator cluster. The following is an explanation of the numbered steps in Figure 5-16:

1. | IPSec Concentrators VPN3000_A, B, and C are all powered on serially, starting with VPN3000_A. VPN3000_A therefore assumes the role of Master VCA regardless of configured priorities within the cluster as it comes online first.
2. | The master VCA in the cluster, VPN3000_A, gathers information on the current session load on the secondary VCAs in the cluster, VPN3000_B and VPN3000_C.
3. | A remote VPN client initiates an IPSec VPN tunnel to the virtual cluster IP address.
4. | The master VCA in the cluster, VPN3000_A, directs the negotiation of the Phase 1 and 2 SAs to the concentrator with lowest load in the cluster (determined previously in Step 2), VPN3000_B.
5. | An IPSec VPN tunnel is established between the IPSec VPN client and VPN3000_B.
6. | A failure occurs on VPN3000_A, causing it to clear all IPSec SAs from its SADB and leave the concentrator cluster.
7. | The concentrator with the highest priority (VPN3000_B) takes over as the VCA master and collects information on session load from the secondary VCAs in the cluster (VPN3000_A and VPN3000_C).
8. | Once VPN3000_A recovers and rejoins the cluster, the new master VCA (VPN3000_B) redirects IPSec VPN tunnel negotiations to VPN3000_A, since it has the lowest load in the cluster.

It is important to observe the behavior of the cluster upon failure of one of the concentrators. Were this to occur, a DNS-based round-robin session load balancing alternative would continue to evenly load balance sessions across the concentrators in the cluster, unaware that VPN3000_A is vastly underutilized after it recovers in Step 8, described above. Using the VCA protocol, VPN3000 concentrators can make this distinction and therefore have enough load-balancing intelligence to assign IPSec client sessions to the underutilized concentrator until its load is roughly equal to that of the other concentrators in the cluster.

IPSec Session Load-Balancing Using External Load Balancers

Using an external load balancer to distribute IPSec VPN sessions to their corresponding concentrator could prove to be a useful design choice when VPN clustering is not an option. As VPN Concentrator clustering is only supported on VPN3000 Series Concentrators, this design scenario could present itself when another brand of concentrator is selected. Figure 5-17 shows a sample topology that uses a Content Switch Module (CSM)in the 6509 switch facing the VPN concentrators.

Figure 5-17. Load Balancing IPSec VPN Sessions with External Load Balancers

[View full size image]

The content switch module in Figure 5-17 is distributing IPSec VPN sessions to the concentrators behind it in a round-robin fashion. Unlike a cluster of VPN3000 concentrators running the VCA protocol, the CSM will not normally query the concentrators behind it for detailed session-load information unless a script is executed on the concentrator instructing it to do so. Instead, the CSM will only query the concentrator for its operational state using ICMP probes. The 6500 CSM does support scripting languages, such as TCL, which could be used to instruct the CSM to query (for example, with SNMP) the concentrators for information on their current session load, which in turn could be used to execute the load-balancing decision on the next inbound IPSec VPN session.

Warning

Although the CSM does allow administrators to write scripts that could be used for inbound IPSec session load balancing, support for this solution is severely limited. Additionally, the configuration, maintenance, and operation of this solution are all far more difficult than that of virtual clustering with VPN3000 series concentrators and ASA5500 VPN appliances.

Tip

The CSM supports scripting languages, such as TCL, that could be used to configure the CSM to query (for example, with SNMP) the concentrators for their tunnel load. The CSM could then use that information to load-balance the inbound IPSec VPN tunnels across the VPN concentrators behind the CSM. Although this presents a viable alternative to session load balancing, using VCA clustering on the VPN3000s is the best supported solution for dynamic session load balancing on VPN3000 IPSec VPN concentrators and ASA5500 VPN appliances.

The CSM can, however, direct inbound IPSec sessions to the concentrator with the lowest session load. The CSM accomplishes this by keeping a state table of the connections that pass through it. This allows the CSM to quickly identify which concentrators have been assigned the most sessions and which have been assigned the least, enabling the CSM to rapidly redirect inbound IPSec VPN tunnel initiation requests to the appropriate concentrators.


Summary

This chapter outlines a broad scope of concepts required for understanding IPSec VPN HA. In summary, there are five very broad components of IPSec VPN HA that should be explored when designing HA into an IPSec VPN deployment:

  • Network redundancy

  • Termination redundancy

  • Path availability mechanisms

  • Path symmetry mechanisms

  • Load balancing alternatives

This chapter ties in with various topologies discussed in previous HA discussions, and the book continues to do so in subsequent HA chapters. There are many different design options for each of the HA categories listed previously in this summary and introduced previously in this chapter. Table 5-2 shows some design concepts that you should be familiar with at this point in the text and the area of HA to which they pertain.

Table 5-2. HA Design Summary

HA Deployment Option

HA Deployment Category

Advantages and disadvantages of terminating IPSec on multiple interfaces versus terminating IPSec on a Virtual Interface (HSRP/VRRP).

Termination redundancy

IKE Keepalives and Dead Peer DetectionThe similarities and differences of each and when to use one or the other.

Path availability

When to use multiple peering statements for tunnel redundancy and when to rely on the underlying RP for tunnel redundancy.

Termination redundancy network redundancy

What load balancing is and where it fits into the IPSec HA paradigm.

Load balancing and HA

Encrypted RPs and GRE KeepalivesWhy they are useful and the associated packet and performance overhead.

Path availability

BGP and IGPs with Unicast NeighborsWhen they are a useful design alternative to encrypted RPs.

Path availability

How RRI, RP Metrics, and HSRP can all be used to abate IPSec control plane issues with path asymmetry.

Path symmetry

DNS-based IPSec load balancing, RP-based IPSec load balancing, IPSec load balancing alternate with peering statements, VPN3000 clustering with VCA, and IPSec load balancing with external load balancers: What each method requires, the advantages/disadvantages of each, and when to consider each design option.

Load balancing and HA

The ensuing chapters discuss these design concepts in greater detail, including configuration and troubleshooting steps. Each subject is presented in the context of local High Availability (Chapter 6, "Site-to-Site Local HA Solutions") and geographic High Availability (Chapter 7, "Site-to-Site Geographic HA Solutions"). Many of the IPSec HA design options introduced in this chapter, such as VPN3000 clustering, pertain to RAVPN environments. The HA discussions in Chapter 9, "Remote Access VPN High Availability," focus solely on RAVPN environments.


Chapter 6. Solutions for Local Site-to-Site High Availability

As we discussed in Chapter 5, "Designing for High Availability," there are many ways to design for High Availability (HA) in IPsec virtual private network (VPN) designs. One critical design goal in an IPsec VPN requiring HA is to ensure that elements local to the VPN endpoint are designed with the required amount of redundancy. In this chapter, we will discuss those design alternatives available locally on the router, otherwise known as "local IPsec HA." During our discussion, we will explore the advantages and disadvantages of each design, and we will wrap up with a summary comparison of those local HA design techniques previously discussed.


Using Multiple Crypto Interfaces for High Availability

It is very common for a networked IPsec VPN endpoint in a site-to-site deployment to have multiple interfaces available for IPsec configuration. One technique that can be used for local HA is to employ the use of multiple, redundant crypto interfaces in the IPsec VPN design. There are both advantages and disadvantages to leveraging this approach to IPsec local HA. Before we explore those advantages and disadvantages, let us first have a look at the failover process involved when activating multiple crypto interfaces for HA while exploring the simple site-to-site layout shown in Figure 6-1.

Figure 6-1. Multiple Crypto Interface Configurations for IPsec HA

[View full size image]

When a serial interface failure occurs between Router_A and Router_B in Figure 6-1, the system undergoes the following sequence of events during the reconvergence process:

1. | The primary link between Router_A (Se0/0) and Router_B (Se0/0) fails.
2. | The routing protocol used between Router_A and Router_B reconverges, and it now begins to re-route traffic over the redundant link between Router_A (Se0/1) and Router_B (Se0/1).
3. | The traffic from Step 2 matches the crypto ACL applied to the crypto map of the redundant interface on Router_A (Se0/1), thereby triggering ISAKMP, and subsequently IPsec, SA negotiation.
4. | If the primary link remains down longer than the negotiated SA lifetimes, and if IKE keepalives are disabled, the original, primary, ISAKMP, and IPsec SAs time out. Tip The use of IKE keepalives can enable the teardown of obsoleted SAs such as in Step 4 (and later in Step 7 of this example). If IKE keepalives were enabled on Router_A and Router_B, the routers would not have to wait the duration of the negotiated SA lifetime to tear down the SAs, even if they are not in use.
5. | When the primary link is restored, the routing protocol on Router_A and Router_B reconverges such that traffic is now once again routed over the link between Router_A (Se0/0) and Router_B (Se0/0).
6. | The re-routed traffic in Step 5 matches the crypto ACL of the crypto map applied to the primary interface of Router_A (Se0/0), thereby triggering another negotiation of ISAKMP and IPsec SAs.
7. | If the primary link stays up for longer than the negotiated SA lifetimes, and IKE keepalives are disabled, the ISAKMP and IPsec SAs established in Step 3 time out.

The use of crypto maps on redundant interfaces represents the most basic form of local HA available today. As one can tell from the preceding process, IPsec failover relies heavily on the reconvergence of the underlying routing protocol that the IPsec VPN tunnel is built on. Although this design is simple to deploy and to configure, there are quite a few ways to tune the process to fail over quicker. The failover scenario of Figure 6-1 and Example 6-1 describes the most simplistic, untuned way of providing local HA.

The ISAKMP configuration on Router_A and Router_B must be capable of using matching preshared keys with both peers. Router_A's configuration, which is displayed in Example 6-1, would not only need to use the key "cisco" with 200.0.0.2 as the primary, but also with the redundant peer200.0.0.4. Router_A's crypto map configuration, also displayed in Example 6-1, uses redundant peer definitions within the same crypto map. If the first peer is unavailable, Router_A will use 200.0.0.4. This configuration is well suited for this environment only because the same address space will be protected for both peers. However, if different peers were to be used for different sets of protected address spaces, then another process within the same crypto map would be required (for example, crypto map chap6-dualit 20 IPsec-isakmp).

Example 6-1. Local IPsec HA Using Separate Physical Interfaces

Router_A#  show running-config
!
!
crypto isakmp policy 10
 encr 3des
 authentication pre-share
crypto isakmp key cisco address 200.0.0.2
crypto isakmp key cisco address 200.0.0.4
crypto isakmp keepalive 10
!
crypto IPsec transform-set chap6-dualint esp-3des esp-sha-hmac
!
crypto map chap6-dualint 10 IPsec-isakmp
 set peer 200.0.0.2
 set peer 200.0.0.4
 set transform-set chap6-dualint
 match address 101
 reverse-route
!
!
interface Serial0/0
 no ip address
 no fair-queue
 crypto map chap6-dualint
!
interface Serial0/1
 no ip address
 no fair-queue
 crypto map chap6-dualintT
!
!
access-list 101 permit ip 201.1.1.0 0.0.0.255 202.1.1.0 0.0.0.255

Let us take a look at some of the areas of this process that present opportunities for improvement and introduce some available design solutions:

  • Routing protocol reconvergence

  • Stale security associations

  • IKE and IPsec SA renegotiation

Impact of Routing Protocol Reconvergence on IPsec Reconvergence

Note that Steps 3 and 6 of the failover process outlined in Figure 6-1 require that traffic be inspected by the crypto access list of the interfaces' crypto map before the new ISAKMP and IPsec SAs can be negotiated. Because of this, the availability of this design will directly depend on, among other things, the speed of RP reconvergence. With Cisco IOS, RP timers can be tuned to maximize the speed of reconvergence, resulting in faster failover to the redundant IPsec VPN tunnel.

Note

The discussion of RP timers is relevant to our discussion only in that speedy RP reconvergence times aid IPsec tunnel failover times. The subject is otherwise outside the scope of this publication. Tuning RP timers in an enterprise network produces an extremely large variety of effects beyond what we have discussed in relation to IPsec. For this reason, extreme caution should be exercised when altering RP timers in a network.

In some instances, it may make sense to use floating static routes to expedite IPsec local HA even further. The floating static route approach describes a situation in which a static route is installed in the configuration with a higher administrative distance than an identical dynamically learned route. If that dynamically learned route is somehow removed from the routing table, then the floating static route is immediately installed. Additionally, floating static routes are simple to deploy, and they require less overhead. For these reasons, it may make sense in a network design to employ them in lieu of a full RP-based failover solution.

One such popular instance in which floating static routes are commonplace is in highly available IPsec branch offices. Figure 6-2 illustrates the failover process of an IPsec HA branch failover scenario.

Figure 6-2. Floating Static Routes and IPsec Tunnel Failover

Example 6-2 illustrates the configuration of a floating static route on Branch_6A. Note in the configuration provided in Example 6-2, Ent_Main4a is using the loopback interface of Branch_4a to authenticate Phase 1 SAs and to negotiate Phase 2 SAs. Therefore, if Ent_Main4a is unable to effectively and rapidly route to that loopback interface, neither Phase 1 nor Phase 2 negotiations will complete successfully. Floating static routes can be used as follows to provide a means for rapid failover in this scenario: With floating static routes, the routing table does not need to wait on an update from Branch_4a to install the route to 10.1.1.4. Instead, the floating static route is immediately installed after the route with a lower admin distance is lost, thereby aiding the speed of reconvergence in the overall failover of the IPsec VPN tunnel. Like Ent_Main4a, Branch_4a uses a floating static route for failover of its IPsec tunnel. This allows Branch_4a to immediately renegotiate Phase 1 and Phase 2 SAs with Ent_Main4a without waiting for establishment of an RP adjacency and receipt of an RP update across the redundant link, thus trimming down the time it takes for the IPsec VPN to reconverge over the redundant path. Note in Example 6-2 the admin distance of 254 on this static route. Once the primary link is restored and an RP update with a lower admin distance is received over that path, that route will overwrite the static route in Branch_4a's routing table.

Example 6-2. Using Floating Static Routes for Fast IPsec HA Failover

hostname Ent_Main4A
!
!
crypto isakmp key cisco address 10.1.1.4
!
!
crypto map chap6-hainterface 10 ipsec-isakmp
crypto map chap6-hainterface local-address loopback10
 set peer 10.1.1.4
 set transform-set chap6-hainterface
!
!
ip route 10.1.1.4 255.255.255.255 200.1.1.6 254
ip route 10.1.4.0 255.255.255.0 200.1.1.6 254

hostname Branch_4a
!
!
crypto isakmp key cisco address 10.1.1.1
!
!
crypto map chap6-hainterface local-address loopback10

crypto map chap6-hainterface 10 ipsec-isakmp
 set peer 10.1.1.1
 set transform-set chap6-hainterface
!
!
ip route 0.0.0.0 0.0.0.0 200.1.1.5 254

Now that we have briefly discussed the motivators for using floating static routes in local IPsec HA scenarios, we will consider the disadvantages of such a design that arise as the scale and complexity of the network increases. There are many situations in which floating static routes may not be a viable option. For example, a large routed domain between the VPN endpoints rather than a single Layer-3 hop (as is the case in Figure 6-1 and Figure 6-2) could make the use of static routes difficult to scale and manage. While floating static routes have design advantages in simple local IPsec HA deployments, a full RP-based approach to IPsec HA is recommended as the scale of the network increases.

Impact of Stale SAs on IPsec Reconvergence

When new SAs are negotiated, the old (stale) SAs are not automatically reaped from the SADB. If IKE keepalives are not enabled, therefore, stale SAs can remain in for the duration of their original lifetime. As we have discussed in Chapter 4, "Common IPsec VPN Issues," stale IPsec and ISAKMP SAs can cause problems in IPsec VPNs. As we will see later in this section when discussing stateful and stateless IPsec HA solutions, stale SAs must be removed in order for an IPsec tunnel to fail over to its redundant peer. IPsec HA mechanisms therefore rely on IKE keepalives to reap stale SAs left in the SADB upon failover so that new SAs can be negotiated with the redundant peer. Improper handling of stale SAs can therefore lead to increased convergence times, or in some cases the inability to failover to a redundant peer in HA environments.

Impact of IPsec and ISAKMP SA Renegotiation on IPsec Reconvergence

Also note that in Steps 3 and 6 of Figure 6-2, new ISAKMP and IPsec SAs must be renegotiated. This process is initiated after the RP has reconverged, and traffic is forwarded matching a configured Crypto ACE on that interface's crypto map. This adds another layer of delay to the failover process, presenting us with another opportunity for optimizing local IPsec HA design. This hurdle for failover to a redundant IPsec VPN tunnel is inherent to a "stateless" failover. However, because we are currently speaking only of local HA solutions, this failover can be mitigated by sourcing updates from a highly available address (such as a loopback address) rather than the physical interface itself. In doing so, the original IPsec and ISAKMP SAs are preserved, and the failover time is limited to RP reconvergence across the redundant physical link.

Consider once again the HA IPsec branch scenario in Figure 6-2. The branch and hub now use loopback64 to initiate/terminate the IPsec tunnel. Recall that Branch_4A uses a floating static route for Layer-3 redundancy to minimize failover delay attributable to RP reconvergence. Additionally, Branch_4A and Ent_Main4A use their loopback interface for IPsec tunnel termination. This method removes the dependency of the physical interface state to maintain the local state of IPsec. Therefore, Branch_4A can now fail over without having to renegotiate IPsec and ISAKMP SAs.

Note

It is important to note that when the RP fails, the hub in this case will not know how to get to the branch loopback interface. The loopback interfaces must be able to communicate in order for the IPsec tunnel to come up, because they are the precise endpoints used to terminate the tunnel. Note that in Figure 6-2 and Example 6-2, there are two floating static routes on Hub_Main4Aone to establish connectivity between the loopback interfaces for IPsec failover and another to establish connectivity to the actual branch network ("Branch4A_Net" of Figure 6-2).

Example 6-3 illustrates a configuration in which IPsec and ISAKMP are sourced and terminated on highly available (loopback) interfaces. In this case, Branch_4a uses the highly available loopback interface of Ent_Main4a to identify the peer to use the key "cisco" with when authenticating Phase 1 SAs. Alternatively, Branch_4a could have been configured to share the key with a hostname, such as "Ent_Main4a", to accomplish the same thing. Branch_4a also uses the loopback interface as the termination point for the IPsec VPN tunnel. Because the IP address 200.1.1.5 is available to Branch_4a over either WAN link to Ent_Main4a, this separates the availability of the IPsec VPN tunnel from the availability of any one given physical interface, thereby providing a means of local HA between Branch_4a and Ent_Main4a.

Example 6-3. IPsec Tunnel Termination to Highly Available Interfaces

hostname Branch_4A
!
!
crypto isakmp key cisco address 200.1.1.5
crypto isakmp keepalive 10
!
crypto map chap6-hainterface local-address loopback10
crypto map chap6-hainterface 10 IPsec-isakmp
 set peer 200.1.1.5
 set transform-set chap6-hainterface
 match address 101

Now that we have introduced some of the basic challenges with IPsec tunnel failover in HA environments and discussed some of the basic concepts of designing resiliency into the local design of the IPsec VPN, we will look at some of the more robust alternatives to HA design. We will begin our exploration of these HA design concepts by discussing a prevalent improvement to the "stateless" HA designs previously discussed in this chapter. Following our discussion of stateless HA concepts and solutions, we will discuss the concept of "stateful" HA design requirements and some effective solutions for IPsec Stateful HA VPNs.


Stateless IPsec VPN High-Availability Alternatives

Stateless IPsec VPN HA refers to a scenario in which the state of a given Phase 1 or Phase 2 SA is not replicated to another separate, redundant IPsec device. In this section, we will discuss solutions for providing a highly available VPN design using stateless mechanisms, specifically HSRP/VRRP (Hot Standby Router Protocol/Virtual RRP) for termination of the IPsec VPN tunnel and Reverse-Route Injection for keeping routing protocol information consistent between the two private routing domains that use the IPsec VPN tunnel for confidential communications between them.

Solution Overview for Stateless IPsec High Availability

The stateless local IPsec HA design in this chapter uses the simple network topology depicted in Figure 6-3 to illustrate the required underlying concepts.

Figure 6-3. Stateless Local IPsec High Availability Topology

[View full size image]

In any stateless IPsec HA design, there are two key objectives that must be achieved.

Objective 1: Highly Available Termination The termination of the IPsec VPN tunnel must be highly available to the peering IPsec VPN gateway. This peering alternative must be adequate in reducing latency in IPsec VPN reconvergence attributable to RP reconvergence. The termination point should also eliminate any one physical device (this could be an interface or the gateway itself) as a single point of failure in the design. The primary solution is to use a virtual interface to terminate the IPsec tunnel. HSRP or VRRP can be deployed to provide a virtual interface common to one or more physical devices. Using an HSRP or VRRP virtual interface as the endpoint of an IPsec VPN tunnel preserves routing protocol information in the protected routed domain, eliminating latency attributable to the reconvergence of the routing protocol on the protected side of the VPN. This solution provides a design alternative when a single physical point of failure in the VPN network topology is unacceptable.

Note

While terminating an IPsec VPN tunnel on virtual interface precludes RP reconvergence from stalling IPsec VPN reconvergence, the HSRP or VRRP failover timers can stall IPsec VPN failover in such a scenario. We will discuss latency associated with these timers and how to minimize this latency later in this chapter.

Objective 2: Layer-3 Continuity across the IPsec VPN Tunnel As we have discussed in previous chapters, most RP updates are multicast-based. For this reason, they cannot be tunneled through an IPsec VPN without encapsulating them in GRE prior to their inclusion in the crypto switching path. Therefore, without GRE, the alternative is Reverse-Route Injection. When an IPsec VPN gateway is configured for RRI, it injects routing information backwards into the protected routed domain upon successfully negotiating an IPsec SA. In this scenario, C7206VXR-MAIN (or potentially C7206VXR-STANDBY) injects a static route for VPN-2651XM's protected IP address space backward into the enterprise network routing domain, as illustrated in Figure 6-3.

Hot Standby Routing Protocol

Hot Standby Routing Protocol (HSRP) provides a virtual interface that can be shared between two redundant routers. There are two main components of the HSRP protocol:

  • The creation of a virtual interface inclusive of a virtual MAC address residing on the same broadcast domain as the two physical redundant interfaces (at least one physical interface on each router in the HSRP group).

  • The communication of interface state and priority between each router with a physical interface in the HSRP group. This exchange is facilitated with the use of HSRP Hello messages sent to the all routers multicast destination address (224.0.0.2).

These two components work together to create a virtual interface that represents two or more physical interfaces on the same broadcast domain, addressed on the same subnet. In this section, we will describe a method of IPsec HA that uses this virtual interface to provide a stateless method of redundancy.

Note

This chapter discusses HSRP and VRRP in the context of IPsec HA only. For more detail on the operation of the Hot Standby Router Protocol (HSRP), refer to the following URL on CCO:

http://www.cisco.com/en/US/partner/tech/tk648/tk362/tk321/tsd_technology_support_subprotocol_home.html

Also note that we will only discuss HSRP IPsec HA alternatives, because many of the features required for stateless and stateful IPsec HA are Cisco proprietary features that work only on HSRP. For standards-track virtual interface capability, refer to the IETF's Virtual Router-Router Protocol charter:

http://www.ietf.org/html.charters/vrrp-charter.html

IPsec VPN tunnel termination on an HSRP interface eliminates a single point of failure in the IPsec VPN design. Consider the layout illustrated in Figure 6-3. In a nonredundant site-to-site VPN, 2651XM-VPNA would establish Phase 1 and Phase 2 SAs with only one endpoint. In this scenario, redundancy has been built into the design on cleartext routed domain A. Because of this, any device terminating an IPsec VPN tunnel at cleartext routed domain "a," such as 2651XMVPNA, would have the benefit of an HSRP-based redundant termination point.

Once the IPsec tunnel itself can be built between the HSRP virtual interface on cleartext routed domain A and the physical interface on 2651XM-VPNA, the two cleartext routing domains must be informed of how to route to one another. In the sense of a stateless IPsec HA deployment, this need is currently met by deploying RII.

Tip

Recall that without the use of IPsec+GRE, multicast traffic, inherent to the operation of many routing protocols, cannot be passed across the VPN. When a fully dynamic exchange of RP information is required, consider tunneling the routing protocol traffic through the VPN using GRE. This deployment is discussed in greater detail in Chapter 3, "Basic IPsec VPN Topologies and Configurations."

RRI

RRI can be deployed to maintain consistency between routed domains over an IPsec VPN tunnel when RP updates and hellos cannot be exchanged across the IPsec VPN tunnel. RRI does this by automatically injecting routes backward into the cleartext routing domain upon negotiation of a Phase 2 IPsec SA.

Consider again the topology described in Figure 6-3. When 2651XM-VPNA completes Phase 2 SA negotiation with the redundant HSRP pair of 7200VXRs on cleartext routed domain "D," the active HSRP router of the pair (in this case C7206VXR-MAIN) injects RRI-learned static routes to cleartext routed domain "A" into C7206VXR-MAIN's routing table. RRI accomplishes this by inspecting the IP address space to be included in the crypto switching path, as defined by the crypto ACLs configured on each peer. Remember that in order for an IPsec Phase 2 SA to be negotiated correctly, the protected address space defined in the ACLs on each peer must match. C7206VXR-MAIN is configured to redistribute these RRI-learned static routes into the IGP of cleartext routed domain "A."

Note

For more information on protected address space definition and the impact of crypto ACL mismatches on Phase 2 SA negotiation, refer to Chapter 3, "Basic IPsec VPN Topologies and Configurations."

After a Phase 2 SA is negotiated, RRI inspects the crypto-protected address space that the two VPN endpoints have agreed on and entered in the SADB. The VPN endpoints create static routes for the corresponding address space agreed upon in Phase 2 negotiation and entered in the SADB.

Tip

VPN routes created by RRI appear as static routes, but they can be injected into a dynamic routing protocol using the redistribute static command under the Routing Protocol subconfiguration menu.

Stateless High Availability Failover Process

Stateless local site-to-site HA leverages HSRP and RRI in tandem to provide redundancy in IPsec VPN designs. In this section, we will consider a scenario in which a smaller cleartext routed domain (A, B, or C) is establishing an IPsec VPN tunnel to a larger cleartext routed domain (D) at which there are shared, business-critical resources. The communications between the two cleartext routed domains must be confidential and are therefore passed in ciphertext across a ciphertext routed domain. Figure 6-4 illustrates this topology.

Figure 6-4. Step-by-Step Stateless Local IPsec HA Failover.

[View full size image]

The following sections describe the steps illustrated in Figure 6-4:

  • Step 1: Initial IPsec VPN Tunnel Establishment

  • Step 2: Pre-HSRP RRI Execution

  • Step 3: Active Router Failure

  • Step 4: HSRP Reconvergence

  • Step 5: IPsec Reconvergence

  • Step 6: Post-HSRP RRI Execution

Step 1: Initial IPsec VPN Tunnel Establishment

In this case, the VPN gateways at cleartext domain A, B, and C establish site-to-site IPsec VPN tunnels with cleartext domain D. Because there are critical resources that are shared among all domains (A, B, C, and D), the network architects of the firm decide to deploy stateless HA at cleartext routed domain D. The configuration of the gateways on domains A, B, and C are config-ured normally for site-to-site connectivity, with one exceptionthe remote peer is defined as the HSRP virtual IP address of the redundant pair of IPsec VPN gateways at cleartext routed domain D.

The key thing to remember in this step is that the single point of failure at cleartext routed domain D is eliminated by this solution. This provides IPsec HA at the terminating peer for confidential communications used by domains A, B, and C. Again, the only configuration change required on the VPN gateways in domains A, B, and C is to define the HSRP standby IP address of domain D as the remote IPsec peer and, if using preshared keys for Phase 1 negotiation, ensure that the appropriate ISAKMP preshared key is used with that IP address.

Example 6-4 provides the configuration of an IPsec branch router, 2651XM-VPNA, in the network topology illustrated in Figure 6-4. The branch router is configured to share its ISAKMP key with 200.1.2.1, the HSRP virtual interface of C7206VXR-MAIN and STANDBY so that either router can complete Phase 1 negotiations with 2651XM-VPNA. 2651XM-VPNA is also configured to use the HSRP virtual interface of C7206VXR-MAIN and STANDBY to terminate the IPsec tunnel. This allows 2651XM-VPNA to terminate the IPsec VPN tunnel on either C7206VXR-MAIN or STANDBY, thereby taking full advantage of the stateless IPsec HA configuration in cleartext routed domain D. RRI is used to dynamically inject an IP route for cleartext routed domain D into cleartext routed domain A. RRI accomplishes this by dynamically creating static routes to 10.0.0.0/8 on 2651XM-VPNA upon successful negotiation of an IPsec SA. The RRI-learned routes are manually redistributed into the RP on 2651XM-VPNA and are subsequently propagated throughout cleartext routed domain A. This provides network elements in cleartext routed domain A the ability to route IP packets to target destinations on cleartext routed domain D.

Example 6-4. Branch Configuration for Stateless IPsec HA

hostname 2651XM-VPNA
!
!
crypto isakmp key cisco address 200.1.2.1
!
!
crypto map chap6-stateless 10 IPsec-isakmp
 set peer 200.1.2.1
 set transform-set chap6-stateless
 match address 101
 reverse-route

To support the stateless HA configuration at domain D, HSRP must be configured on interfaces facing the remote branches A, B, and C in order to provide a virtual IP address that the VPN gateways on A, B, and C can terminate their IPsec VPN tunnels on. Example 6-5 shows the configuration additions required of C7206VXR-MAIN and C7206VXR-STANDBY needed to support HSRP-based termination of the IPsec VPN tunnels inbound from 2651XM-VPNA, 2651XM-VPNB, and 2651XM-VPNC.

Example 6-5. Aggregator (C7206VXR-MAIN and C7206VXR-STANDBY) Configuration on Cleartext Domain D for Stateless IPsec HA

hostname C7206VXR-MAIN
!
!
crypto isakmp keepalive 10
!
!
crypto map chap6-stateless 10 ipsec-isakmp
 set peer 200.1.1.1
 set transform-set chap6-stateless
 match address 101
 reverse-route
!
crypto map chap6-stateless 20 ipsec-isakmp
 set peer 200.1.1.5
 set transform-set chap6-stateless
 match address 102
 reverse-route
!
crypto map chap6-stateless 30 ipsec-isakmp
 set peer 200.1.1.9
 set transform-set chap6-stateless
 match address 103
 reverse-route
!
interface FastEthernet0/0
ip address 200.1.2.11 255.255.255.0
ip directed-broadcast
 speed auto
 half-duplex
 standby 1 ip 200.1.2.1
 standby 1 preempt
 standby 1 name chap6-vpnha
 standby 1 track FastEthernet0/1 75
!
access-list 101 permit ip 10.0.0.0 255.0.0.0 192.168.1.0 255.255.255.0
access-list 102 permit ip 10.0.0.0 255.0.0.0 192.168.2.0 255.255.255.0
access-list 103 permit ip 10.0.0.0 255.0.0.0 192.168.3.0 255.255.255.0
 crypto map chap6-stateless redundancy chap6-vpnha
hostname C7206VXR-STANDBY
!
!
crypto isakmp keepalive 10
!
!
crypto map chap6-stateless 10 ipsec-isakmp
 set peer 200.1.1.1
 set transform-set chap6-stateless
 match address 101
 reverse-route
!
crypto map chap6-stateless 20 ipsec-isakmp
 set peer 200.1.1.5
 set transform-set chap6-stateless
 match address 102
 reverse-route
!
crypto map chap6-stateless 30 ipsec-isakmp
 set peer 200.1.1.9
 set transform-set chap6-stateless
 match address 103
 reverse-route
!
!
interface FastEthernet0/0
 ip address 200.1.2.12 255.255.255.0
 ip directed-broadcast
 speed auto
 half-duplex
 standby 1 ip 200.1.2.1
 standby 1 preempt
 standby 1 name chap6-vpnha
 crypto map chap6-stateless redundancy chap6-vpnha
!
access-list 101 permit ip 10.0.0.0 255.0.0.0 192.168.1.0 255.255.255.0
access-list 102 permit ip 10.0.0.0 255.0.0.0 192.168.2.0 255.255.255.0
access-list 103 permit ip 10.0.0.0 255.0.0.0 192.168.3.0 255.255.255.0

Example 6-5 provides the configuration of the redundant headend routers performing IPsec VPN tunnel aggregation for the branches. IKE keepalives are the primary means by which to notify the crypto engine that the IPsec SAs previously established are no longer valid and must be torn down. After three keepalives are missed, the crypto engine will tear down Phase 1 and Phase2 SAs with its peers, allowing the remote peers to rebuild those SAs with the redundant gateway, C7206VXR-STANDBY. Line 4 of the configuration enables the use of IKE keepalives on C7206VXR-MAIN. IKE keepalives are also configured on C7206VXR-STANDBY, as shown in line 42 of the configuration, so as to allow C7206VXR-MAIN to preemptively assume active HSRP router responsibilities when a failure has been restored. C7206VXR-MAIN uses HSRP to present a highly available virtual interface for branch routers to terminate their IPsec VPN tunnels on. The HSRP standby interface is also the IP address that the IPsec VPN tunnel will be sourced from on C7206VXR-MAIN or C7206VXR-STANDBY, depending on which of the two is the active HSRP router. The IPsec and ISAKMP preshared key peering statements on 2651XMVPNA, 2651XM-VPNB, and 2651XM-VPNC must be configured to use this interface to take advantage of the stateless IPsec HA configuration between redundant peers C7206VXR-MAIN and STANDBY. Tracking other interfaces on the router allows HSRP to fail over based on downstream information. In this scenario, C7206VXR-MAIN tracks Fa0/1. If the tracked interface fails, HSRP decrements its priority by 50. C7206VXR-STANDBY then recognizes the priority change, further realizing that its priority is higher (75 > 50) and forcing C7206VXR-STANDBY to preemptively assume the role of the active HSRP router and the active IPsec VPN gateway in cleartext routed domain D. The standby name is referenced in the crypto map, chap6-stateless, for IPsec HA. This instructs the crypto engine to bind crypto information to the HSRP information for stateless IPsec HA. For example, the IPsec processes on C7206VXR-MAIN and STANDBY need to know to use the standby address (200.1.2.1) for tunnel termination and origination rather than the physical IP address of 200.1.2.11 and 12, respectively. Without referencing the HSRP standby name in the crypto map, the default behavior of peering directly from the physical interface IP would occur, effectively negating the benefits of HSRP-based stateless IPsec HA. The crypto map, "chap6-stateless", is applied to the physical interface configured for redundancy with HSRP. Note that this interface is configured to automatically inject routing information backwards in to cleartext routed domain D using RRI.

Example 6-5 also includes the configuration for the redundant router providing stateless IPsec HA, C7206VXR-STANDBY. C7206VXR-STANDBY's crypto map is identical to that of C7206VXR-MAIN. Note that it too uses RRI to update routing protocol information for cleartext routed domain D. This will happen only when HSRP and IPsec both fail over to C7206VXR-STANDBY. The physical interface configured for redundancy using HSRP is located on the same subnet as C7206VXR-MAIN. Many of the HSRP and IPsec parameters configured are identical between C7206VXR-MAIN and STANDBY, such as the crypto transform sets used, ISAKMP parameters, and HSRP standby interface IP addresses. Others are different, such as interface tracking configurationC7206VXR-STANDBY does not track interfaces, while C7206VXR-MAIN does. C7206VXR-STANDBY will, however, use HSRP preempt to assume the role of active HSRP router when it senses that the priority of C7206VXR-MAIN has decreased due to the failure of one of its tracked interfaces.

Step 2: Pre-HSRP RRI Execution

When the redundant pair of 7206VXRs is capable of building an IPsec VPN tunnel with the remote 2651XMs in Figure 6-4, there needs to be a means by which to ensure that Layer 3 devices in domains A, B, and C can route to domain D, and vice versa. Because this is a pure IPsec solution (and GRE is not in use), VPN gateways in domains A, B, C, and D are configured for RRI, which occurs in this step. RRI determines what routes to inject backwards into the appropriate routing domain by inspecting the protected address space negotiated in Phase 2 and entered in the IPsec SADB.

Example 6-6 shows the output of C7206VXR-MAIN, which is the active HSRP router terminating an IPsec connection for 2651XM-VPNA. Before taking any steps to verify the crypto operation, HSRP operation is confirmed to be operating correctly, as shown in lines 116 of Example 6-6. As C7206VXR-MAIN is the active HSRP router (confirmed in lines 3 and 4 of Example 6-6), it will also actively assume responsibilities for terminating Phase 1 and Phase 2 SAs with its remote peers. The output from C7206VXR-MAIN SADB shows the current ISAKMP and IPsec SAs associated with 2651XM-VPNA. The standby IP address that remote peers will use for IPsec tunnel termination is shown in line 5. According to the output listed in line 10, C7206VXR-MAIN will attempt to preempt other interfaces in the HSRP group to become the active router whenever a priority change is detected within the group. Therefore, C7206VXR-MAIN will take advantage of preemption to resume active router responsibilities once a failure has been repaired on C7206VXR-MAIN Fa0/0 or Fa0/1. C7206VXR-MAIN will track Fa0/1 and Lo10, and will decrement the default priority of 100 by 75 (yielding a priority of 25). When C7206VXR-STANDBY detects this (it is configured to preempt), it will take over as the active router for the HSRP group, as its priority of 50 is greater than C7206VXR-MAIN's new priority of 25. Also, C7206VXR-STANDBY will also take over as the IPsec tunnel termination point for 2651XMVPNA, 2651XM-VPNB, and 2651XM-VPNC once the appropriate amount of IKE keepalives are missed and new Phase 1 and Phase 2 SAs are negotiated. Note that the source IP address listed for the IPsec SAs in lines 21 and 22 is identical to the HSRP standby IP address listed in line 5. Lines 1922 therefore confirm that C7206VXR-MAIN is actively terminating IPsec VPN tunnels on the standby IP interface for the appropriate HSRP group.

Example 6-6. C7206VXR-MAIN IPsec SADB before HSRP Failover

C7206VXR-MAIN#show standby
FastEthernet0/0 - Group 1
 State is Active
   14 state changes, last state change 2d13h
 Virtual IP address is 200.1.2.1
 Active virtual MAC address is 0000.0c07.ac01
   Local virtual MAC address is 0000.0c07.ac01 (V1 default)
 Hello time 3 sec, hold time 10 sec
   Next hello sent in 0.276 secs
 Preemption enabled
 Active router is local
 Standby router is 200.1.2.12, priority 50 (expires in 7.840 sec)
 Priority 100 (default 100)
  Track interface FastEthernet0/1 state Up decrement 75
  Track interface Loopback10 state Up decrement 75
 IP redundancy name is "chap6-vpnha" (cfgd)
C7206VXR-MAIN#show crypto engine connections active

 ID Interface            IP-Address      State  Algorithm          Encrypt   Decrypt
 8 FastEthernet0/0       200.1.2.11      set    HMAC_SHA+3DES_56_C       0         0
 2001 FastEthernet0/0    200.1.2.1       set    3DES+SHA                 4         0
 2002 FastEthernet0/0    200.1.2.1       set    3DES+SHA                 0         4

C7206VXR-MAIN#

Note here that there will be reconvergence delay attributable to reconvergence of the routing tables on either side of the IPsec tunnel. The convergence delay of the IPsec design attributable to RP reconvergence can vary greatly based on a large number of variables, such as the routing protocol used, the size of the routing table, the configuration of RP timers, and the platforms selected to perform the routing functionality, among others. Because of this, within the context of this work, we will consider the total system failover time to include RRI but not system-wide RP reconvergence. In your network design, be advised that the reconvergence of routed domains should be analyzed regardless of whether a stateful or stateless IPsec HA design is selected.

Note also that in the SADB, C7206VXR-MAIN is instructed to encrypt traffic to 192.168.1.0/24, the address range used cleartext domain A. Because C7206VXR-MAIN does not receive RP updates, which are multicast, across the VPN tunnel, C7206VXR is configured to inject routes in to cleartext domain D using RRI.

In Example 6-7, 2651XM-VPNA inserts a VPN route using static RRI as soon as a complete static crypto map is applied to an interface, which, as we will see in Example 6-9, is slightly different from the behavior on C7206VXR-MAIN. Unlike dynamic crypto maps, static crypto maps must have manually defined peering information and completed crypto ACLs to successfully negotiate Phase 2 with a peer. RRI immediately inserts a VPN (static) route for the destination address space in the crypto ACL with a next hop of the peer IP of the IPsec VPN tunnel defined in the crypto map. This is confirmed by the insertion of the VPN (or RRI-learned) route being added (confirmed by line 5) without any IPsec SAs actively present in the SADB (confirmed by lines 1013).

Example 6-7. Verifying RRI for Domain A: RRI with Static Crypto Maps on 2651XM-VPNA

2651XM-VPNA#debug crypto ipsec
Crypto IPSEC debugging is on
!
!
*Mar  3 08:16:13.962: IPSEC(rte_mgr): VPN Route Added 10.0.0.0 255.0.0.0 via 200.1.2.1 in
  IP DEFAULT TABLE
!
!
2651XM-VPNA#sh ip route static
S    10.0.0.0/8 [1/0] via 200.1.2.1
2651XM-VPNA#show crypto engine connections active

 ID Interface            IP-Address      State  Algorithm          Encrypt Decrypt

2651XM-VPNA#

Example 6-8 shows the required configuration for RRI on C7206VXR-MAIN and the resulting output from the routing table that shows an RRI-injected route into cleartext domain D for cleartext domain A's routes upon successful negotiation of a Phase 2 SA between C7206VXR-MAIN and C2651XM-VPNA. Unlike static crypto maps, RRI with dynamic crypto maps will not inject routing information until a Phase 2 SA is negotiated. Initially, RRI is configured on C7206VXR-MAIN, but the crypto SADB and IP routing table are both empty, as confirmed by lines 14 and lines 5 and 6 of Example 6-8, respectively. When an IPsec SA is negotiated with 2651XM-VPNA (negotiation is also initiated by 2651XM-VPNA), C7206VXR-MAIN learns the tunnel termination endpoint to use on 2651XM-VPNA and which traffic to encrypt dynamically, as shown in lines 1419. Using this information, C7206VXR-MAIN uses RRI to inject a route into the routing table for cleartext routed domain D, as confirmed in lines 715 and in lines 20 and 21. Note that C7206VXR-MAIN has negotiated Phase 1 and Phase 2 SAs with 2651XM-VPNA, providing C7206VXR-MAIN with enough information to create a route for encrypted traffic using RRI. We can now verify that the VPN route appears in the routing table with the correct IP, subnet mask, and next hop, as shown in lines 20 and 21.

Caution

VPN routes injected by RRI appear as static routes and therefore will only exist in the routing table of the RRI-enabled IPsec VPN gateway without the aid of a selected routing protocol. To successfully propagate RRI-learned routes to the routing tables of all networked nodes participating in the routed domain, static routes must be redistributed into the chosen routing protocol.

Example 6-8. Verifying RRI for Domain A: DRI with Static Crypto Maps on C7206VXR-MAIN

C7206VXR-MAIN#sh crypto engine connections active

 ID Interface            IP-Address      State  Algorithm           Encrypt Decrypt
C7206VXR-MAIN#show ip route static
C7206VXR-MAIN#debug crypto ipsec
Crypto IPSEC debugging is on
!
!
*Jul  4 11:38:13.296: IPSEC(rte_mgr): VPN Route Added 192.168.1.0 255.255.255.0 via
  200.1.1.1 in IP DEFAULT TABLE with tag 0
!
!
C7206VXR-MAIN#sh crypto engine connections active

        ID Interface      IP-Address      State  Algorithm           Encrypt     Decrypt
   7 FastEthernet0/0      200.1.2.11      set    HMAC_SHA+3DES_56_C        0          0
2003 FastEthernet0/0       200.1.2.1      set    3DES+SHA                  0          4
2004 FastEthernet0/0       200.1.2.1      set    3DES+SHA                  4          0
C7206VXR-MAIN#show ip route static
S    192.168.1.0/24 [1/0] via 200.1.1.1

Notice in Example 6-8 that C7206VXR only injects a route for 192.168.1.0/24 into cleartext routed domain D. This is because C2651XM-VPNB and C2651XM-VPNC have yet to negotiate Phase 2 SAs with C7206VXR-MAIN. Once this occurs, C7206VXR-MAIN will inject routes for cleartext routed domains B (192.168.2.0/24) and C (192.168.3.0/24).

Step 3: Active Router Failure

Once the IPsec VPN SAs are all established between the active HSRP router C7206VXR-MAIN and 2651XM-VPNA, 2651XM-VPNB, and 2651XM-VPNC, assume that C7206VXR-MAIN were to fail for some reason. In a nonredundant environment, all connectivity from cleartext domains A, B, and C to critical resources at cleartext domain D would be lost. Remember, though, that in this scenario, HSRP is used between C7206VXR-MAIN and C7206VXR-STANDBY and that C2651XM-VPNA, C2651XM-VPNB, and C2651XM-VPNC are using that HSRP virtual IP address to terminate their IPsec VPN sessions to cleartext routed domain D. When C7206VXR-MAIN fails, therefore, C7206VXR-STANDBY takes over as the VPN aggregator for inbound IPsec VPN tunnels initiated by C2651XM-VPNA, C2651XM-VPNB, and C2651XM-VPNC. Because C2651-VPNA, C2651-VPNB, and C2651-VPNC are configured to use the HSRP virtual IP address shared between C7206VXR-MAIN and C7206VXR-STANDBY, and because this address does not change during failover, there is no required reconfiguration on C2651XM-VPNA, C2651XM-VPNB, and C2651XM-VPNC in a failover scenario when using this type of HA design.

Step 4: HSRP Reconvergence

In a failover scenario, the reconvergence of this design depends heavily on HSRP, because HSRP must adequately fail over the virtual IP address from the active HSRP router to the standby HSRP router before any IPsec reconvergence processes can take place. HSRP reconvergence directly depends on the exchange of HSRP hellos between the active and standby routers. The active and standby routers both actively monitor the receipt of these hello messages (multicast destination address of 224.0.0.2) and measure them against a set of predefined timers:

  • Hello Timer The amount of time between transmissions of HSRP hello messages.

  • Hold Timer The amount of time elapsed between receipt of HSRP hello messages for a neighboring HSRP router (active or standby) to be considered down.

These timers, of course, can be changed to optimize convergence in a stateless IPsec HA scenario. Example 6-9 shows configuration changes on C7206VXR-MAIN and C7206VXR-STANDBY to decrease the amount of time it takes HSRP, and hence the amount of time it takes the system, to reconverge.

Example 6-9. HSRP Tuning Example for Optimal Stateless IPsec HA Reconvergence.

C7206VXR-MAIN#
C7206VXR-MAIN(config)#interface fa0/0
C7206VXR-MAIN(config-if)#standby 1 timers msec 30 msec 100

Caution

Tuning HSRP timers for subsecond reconvergence upon failover greatly increases the amount of HSRP traffic on the subnet local to the routers in the HSRP group. Additionally, when timers are tuned for subsecond relay of HSRP hellos and holdtimes, delay between the peers on the same subnet could impact the timely processing of hellos, leading to inconsistent flux in HSRP states. Exercise caution when tuning HSRP timers this tightly in order to avoid inconsistencies in the behavior of the IPsec HA design, including potential unexpected failover due to successive missed HSRP hellos within a configure hold timer window.

Although HSRP timers can be tuned to trim seconds off of the overall delay in reconvergence of the IPsec tunnel itself, HSRP failover delay accounts for only part of the overall reconvergence. As we will discuss later, IPsec and ISAKMP both have elements contributing much more delay to the overall reconvergence than HSRP itself, such as transmission of IKE keepalives, among other things.

Step 5: IPsec Reconvergence

After HSRP successfully fails over from C7206VXR-MAIN to C7206VXR-STANDBY, an additional step of IPsec reconvergence must occur before data can successfully be passed between domain D and domains A, B, and C. This extra step in the reconvergence of the solution is a key characteristic of a stateless failover. Because C7206VXR-STANDBY does not have any awareness of the state of C7206VXR-MAIN's SADB, C7206VXR-STANDBY must therefore rebuild the ISAKMP and IPsec SAs in its own SADB after HSRP has reconverged.

Again, there is no manual intervention or configuration change required on any of the IPsec peers for this particular failover scenario to completeit is done dynamically once traffic is passed from C2651XM-VPNA, C2651XM-VPNB, and C2651XM-VPNC to C7206VXR-STANDBY. However, waiting for stale SAs to be torn down contributes more delay to the failover of a stateless HA solution than any other step in the process. The Cisco IOS default life of an ISAKMP SA is 24 hours, and the Cisco IOS default life of an IPsec SA is 1 hour. In an HA scenario, these SAs would need to be removed for new ones to be built with the redundant peer, leading to unacceptably long reconvergence times. At a minimum, IKE keepalives are required to identify stale SAs from a failover scenario and to remove them so that they can be replaced with new SAs with the redundant peer.

Tip

Even if IKE keepalives are used, the lowest configurable number in IOS is 10 seconds between keepalives, yielding a total failover delay attributable to stale SA teardown of approximately 30 seconds (3 keepalive intervals x 10s/keepalive interval).

Example 6-10 shows output from the SADB after a failure on C7206VXR-STANDBY and the reconvergence of HSRP and IPsec processes. Note that the peering and proxy fields in the SADB are identical to those listed in Example 6-6. With HSRP debugging enabled on C7206VXR-STANDBY, the administrator is able to diagnose the order of events when a failure occurs on C7206VXR-MAIN. The HSRP process begins with diagnostics confirming that C7206VXR-STANDBY has taken over active router responsibilities from 200.1.2.11 (C7206VXR-MAIN). The standby router is unknown, indicating that C7206VXR-STANDBY is taking over because of a physical interface failure on Fa0/0 of C7206VXR-MAIN, prohibiting it from sending or receiving HSRP hellos. The output in lines 59 confirms the transition of the redundancy group that the crypto process uses, "chap6-vpnha", from standby to active. This allows the local crypto process to bind IPsec and ISAKMP peering information to the virtual IP address rather than to the physical or loopback interface IP. The diagnostic output in line 11 confirms that C7206VXR-STANDBY's Fa0/0 interface is the current active HSRP interface for the group. Also confirmed in line 14 is the HSRP standby IP address that should be used by the redundancy group "chap6-vpnha" to populate local tunnel termination information in C7206VXR-STANDBY's SADB. Like C7206VXR-MAIN, C7206VXR-STANDBY is also configured to preemptively assume active router responsibilities when an HSRP priority change is sensed within the HSRP group, as shown in line 19. However, while C7206VXR-MAIN uses this information to reclaim the role of active router after a failure has been restored, C7206VXR-STANDBY will only preempt to take over when priority is decremented on C7206VXR-MAIN due to the failure of one of its tracked interfaces.

Example 6-10. C7206VXR-STANDBY IPsec SADB after HSRP Failover

C7206VXR-STANDBY#debug standby events
HSRP Events debugging is on
Jul 13 19:47:37.191: HSRP: Fa0/0 Grp 1 Active router is local, was 200.1.2.11
*Jul 13 19:47:37.191: HSRP: Fa0/0 Grp 1 Standby router is unknown, was local
*Jul 13 19:47:37.191: HSRP: Fa0/0 Grp 1 Standby -> Active
*Jul 13 19:47:37.191: %HSRP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
*Jul 13 19:47:37.191: HSRP:  Fa0/0 Grp 1 Redundancy "chap6-vpnha"  state Standby -> Active
*Jul 13 19:47:40.191: HSRP: Fa0/0 Grp 1 Redundancy group chap6-vpnha state Active -> Active
*Jul 13 19:47:43.191: HSRP: Fa0/0 Grp 1 Redundancy group chap6-vpnha state Active -> Active
C7206VXR-STANDBY#sh stand
FastEthernet0/0 - Group 1
 State is Active
  14 state changes, last state change 00:00:41
 Virtual IP address is 200.1.2.1
 Active virtual MAC address is 0000.0c07.ac01
  Local virtual MAC address is 0000.0c07.ac01 (V1 default)
 Hello time 3 sec, hold time 10 sec
  Next hello sent in 0.436 secs
 Preemption enabled
 Active router is local
 Standby router is unknown
 Priority 50 (configured 50)
IP redundancy name is "chap6-vpnha" (cfgd)

Step 6: Post-HSRP RRI Execution

The final step in the reconvergence of the system is to propagate routes into the respective VPN domains. As IPsec VPN connections are built from VPN gateways C2651XM-VPNA, C2651XM-VPNB, and C2651XM-VPNC to C7206VXR-STANDBY and the SADBs are populated with the appropriate protected address scopes to be included in the crypto switching path, RRI injects routes into the appropriate cleartext routing domains. In this step, RRI on C7206VXR-STANDBY is executed in the same way that C7206VXR-MAIN executed RRI in Step 2 earlier in this process.


Stateful IPsec VPN High-Availability Alternatives

Site-to-Site IPsec HA can be designed to reconverge quicker upon failover when a stateful design alternative is used. Recall that in stateless IPsec failover, there is a reconvergence delay directly attributable to rebuilding IPsec SAs with the redundant router upon failover. Stateful IPsec HA builds the appropriate entries in the redundant VPN gateway's SADB in advance and employs a mechanism to accurately maintain state parity between the active and standby VPN gateways, thereby effectively precluding the need for IPsec to renegotiate Phase 1 and Phase 2 SAs upon failover. We will now explore the additional components required for an IPsec VPN design with stateful local High Availability.

Solution Overview for Stateful IPsec High Availability

The solution for stateful HA requires all of the same physical components as a stateless solution, but it allows for additional redundancy at both ends of the IPsec VPN tunnel. In the previous stateless HA examples, our design discussion only involved the termination of the IPsec VPN tunnel at a redundant point (the HSRP virtual IP address), while the origination of the VPN tunnel was sourced from a nonredundant point (the physical interface on 2651XM-VPNA, 2651XMVPNB, and 2651XM-VPNC). In our discussion of stateful IPsec HA designs, we will discuss a design in which the IPsec VPN tunnels are both sourced from and terminated on statefully redundant HSRP virtual interfaces. The stateful design in Figure 6-5 illustrates this behavior. Notice that in Figure 6-3 and Figure 6-4, only the concentrating end of the VPN design (domain D) incorporated redundant termination of the IPsec tunnels from domains A, B, and C on an HSRP virtual interface, while in Figure 6-5, a stateless IPsec HA design has been incorporated at all domains to allow for redundant origination and termination of the IPsec VPN tunnel at domains A, B, and C.

Figure 6-5. Stateful IPsec High Availability Topology

[View full size image]

The following list briefly describes the stateful failover of the IPsec VPN tunnel illustrated in Figure 6-5:

1. | A branch router, such as 2651XM-VPNA, 2651XM-VPNB, or 2651XM-VPNC, establishes an IPsec VPN tunnel to the HSRP standby interface shared between C7206VXRVPN-MAIN and C7206VXRVPN-STANDBY.
2. | C7206VXR-MAIN communicates the contents of its IPsec SADB to C7206VXR-STANDBY via Stateful Switchover.
3. | C7206VXR-MAIN recognizes the presence of a new IPsec SA from Step 1 and injects an RRI-learned route in to Domain D.
4. | A reconvergence event occurs on C7206VXR-MAIN. This could be, for example, the failure of a tracked interface or a failure of the device itself, such as a power failure.
5. | HSRP state changes from Standby to Active on C7206VXR-STANDBY. C7206VXR-MAIN is now either unavailable or has transitioned from Active to Standby.
6. | The IPsec tunnel fails over to C7206VXR-STANDBY. There is no Phase 1 and Phase 2 renegotiation due to the prior synchronization of SADB state in step 2.
7. | C7206VXR-STANDBY injects an RRI-learned route for the SAs learned and activated in Steps 2 and 6, respectively.

In this section, we will discuss in greater detail the step-by-step failover of an IPsec VPN tunnel in a stateful HA design, but first, we will look at some of the key components of a stateful IPsec HA design that differ from a stateless IPsec redundancy designs.

HSRP and RRI

The stateful HA designs discussed in this chapter all use HSRP and RRI in the same way that the stateless designs do. Therefore, the reconvergence delay attributable to reconvergence of HSRP and re-injection of RRI routes is similar between stateful and stateless designs. Additionally, HSRP timers and RRI configurations should be similar between stateful and stateless designs. The key ingredient of a stateful design, which is also the key differentiator between stateful and stateless local IPsec HA alternatives, is the communication of state between the active and standby IPsec gateways configured for tunnel termination on the HSRP interface. This communication requires a function called Stateful Switchover (SSO), which we will now explore.

Stateful Switchover (SSO) and IPsec High Availability

SSO is the primary differentiator between stateful and stateless HA designs outlined in this chapter. Unlike stateless IPsec HA designs in which there is no sharing and synchronization of IPsec state between the redundantly configured IPsec gateways, there is a synchronization and mutual update of state information between redundant gateways in a stateful design. The mechanism used to communicate, synchronize, and maintain the state between two or more redundant IPsec gateways is SSO. As we will see, this dramatically streamlines the failover reconvergence process and reduces IPsec tunnel failover delay by eliminating the need for eradication of old SAs and regeneration of new ones. This is because the SAs in a stateful design are already configured by SSO and are therefore available on the redundant peer prior to failover.

Note

IKE keepalives are not supported with SSO in a stateful IPsec HA environment. Dead Peer Detection (DPD), however, is supported in stateful IPsec HA deployments.

By default, SSO uses the standards-based Stream Control Transmission Protocol (SCTP), defined in RFC 2970, to transport IPsec state information between redundant IPsec gateways. SCTP is similar to TCP in that it is connection-oriented and reliable, but it also has notable differences.

One such underlying difference is that SCTP provides message ordering and reliability, whereas TCP provides these services for the actual bytes of the message. Because of this, SCTP is well suited for the reliable, sequenced exchange of state messages used to provide IPsec HA between two redundant IPsec gateways.

As with HSRP and RRI, there are timers within SSO that can be tuned. Ideally, those timers should be set so that the state of each gateway is most accurately reflected in its redundant peers, rather than simply to aid in the speed of reconvergence among failover. Remember, SSO exists so that the state of the IPsec SADB is already built on the redundant peer before failover. As such, there should be no failover delay attributable to SSO if the state of each VPN gateway's SADB is correctly synchronized. Example 6-11 shows SSO output on C7206VXR-MAIN in Figure 6-5.

The key difference between stateful (Example 6-11) and stateless (Example 6-5) configurations is the configuration of SSO to communicate the SADB state between active and redundant IPsec VPN gateways prior to a convergence event taking place. Configuration lines 4 and 5 instruct SSO to use the standby group with the name "chap6-vpnha" for redundancy. This indirectly binds SSO to the redundant crypto process. (Note from previous examples that the crypto process is also bound to this HSRP group as well.) As discussed previously, SSO uses stream control transport protocol (SCTP) to relay SADB state information from active to standby IPsec VPN gateways. The configuration in lines 717 of Example 6-11 instructs the SCTP to use the physical interface on Fa0/0 of C7206VXR-MAIN as the local IP, the physical interface on Fa0/0 of C7206VXR-STANDBY as the remote IP, and port 6666 as the Layer 4 source and destination ports.

Example 6-11. SSO Configuration on C7206VXR-MAIN (Figure 6-5)

C7206VXR-MAIN#show running-config
!
!
redundancy inter-device
 scheme standby chap6-vpnha
!
ipc zone default
 association 6
no shutdown
 protocol sctp
 local-port 6666
 local-ip 200.1.2.11
 retransmit-timeout 200 5000
 path-retransmit 10
 assoc-retransmit 20
 remote-port 6666
 remote-ip 200.1.2.12

Stateful High Availability Failover Process

The following sections describe the stateful High Availability failover process:

  • Step 1: Initial IPsec VPN Tunnel Establishment

  • Step 2: SADB Synchronization with SSO

  • Step 3: Pre-HSRP Failover RRI Execution

  • Step 4: Active Router Failure

  • Step 5: HSRP Reconvergence

  • Step 6: IPsec Reconvergence

  • Step 7: Post-HSRP RRI Execution

Step 1: Initial IPsec VPN Tunnel Establishment

As with a stateless IPsec HA design, an IPsec VPN tunnel must first be built. Stateful IPsec HA offers a key design differentiator in this step: Whereas stateless IPsec HA allows the network designer to terminate the IPsec tunnel on an HSRP Virtual Interface, a stateful design allows the designer to both terminate and source the IPsec tunnel from HSRP virtual interfaces, thereby offering redundancy at both the origination and termination points of the IPsec VPN (a stateless design only offers redundancy at the termination points). This key point of differentiation is enabled with stateful IPsec HA using SSO.

Step 2: SADB Synchronization with SSO

As we have discussed several times, in order for a design to be stateful, the IPsec SADB must be synchronized between active and failover IPsec VPN gateways. When IPsec Phase 1 and Phase 2 SAs are populated in the active router's SADB, they are then shared with the redundant router pre-failover using SCTP (the transport protocol for SSO messages). As we will see in later steps and in the stateless HA design summary, sharing of the SADB state using SSO eliminates failover delay attributable to IPsec reconvergence.

Caution

Although SCTP eliminates certain vulnerabilities inherent to the nature of TCP, SADB information passed using SCTP in an SSO-enabled design is sent in cleartext, not ciphertext. Therefore, administrators should be advised not to allow SCTP messages to cross an untrusted domain, such as a Layer 2 domain spanned across multiple untrusted switched domains.

Step 3: Pre-HSRP Failover RRI Execution

RRI propagates routing information in a stateful IPsec HA deployment in the same way that it does in a stateless IPsec HA deployment. There should be no additional decrease in system reconvergence attributable to RRI injection when selecting a stateful IPsec HA design alternative over a stateless one. Be aware, however, that as with a stateless IPsec HA option, injecting routes via RRI in a failover scenario will require RP reconvergence behind the IPsec VPN, contributing to the overall system reconvergence delay.

Step 4: Active Router Failure

To trigger failover between redundant peers, an active router must first fail. Although this step is similar to what occurs in a stateless failover design, note that one key difference is that this failover can occur on either side of the VPN tunnel because there is redundancy built into the source of the IPsec VPN tunnel in this design.

Step 5: HSRP Reconvergence

As with a stateless design, HSRP must reconverge. The HSRP timers should be tuned for rapid failover in this stateful design in the same manner that they are tuned in a stateless design. It is important to note, however, that unlike a stateless design, HSRP reconvergence is the only process that contributes to the delay of the overall IPsec VPN tunnel.

Step 6: IPsec Reconvergence

The key difference between stateless and stateful IPsec HA solutions is that there is no reconvergence of IPsec in the overall reconvergence of the system. This is because the redundant router has already been informed of the IPsec SA state that it should use by its active counterpart prior to failover. For this reason, there is no failover delay attributable to Phase 1 and 2 IPsec negotiation in a stateful IPsec HA design.

Step 7: Post-HSRP RRI Execution

Once the standby IPsec VPN gateway assumes the crypto forwarding responsibilities for traffic through the IPsec VPN tunnel, it must update the local routing table with itself as the VPN gateway for routes on the opposite side of the IPsec VPN tunnel. This is done through RRI in the same manner outlined in our discussion of stateless IPsec HA.


Summary

In this chapter, we discussed several key components that comprise a highly available IPsec VPN design. These components provide local IPsec HA in either of two design strategiesstateful or stateless IPsec HA designs.

Stateless IPsec VPN High Availability Design Summary

We reviewed several key concepts in this chapter relating to IPsec HA, including the difference between stateful and stateless redundancy schemes in the context of IPsec itself. Stateless IPsec HA refers to a method of delivering redundant IPsec VPN tunnels without replicating SADB state information in the SADB of a redundant IPsec tunnel termination point. Recall from our discussions of stateless IPsec HA that although there are many ways to design redundancy into an IPsec network, there are two broad categories of stateless IPsec VPN design:

  • Use of redundant paths (interfaces) for IPsec VPN tunnels

  • HSRP-based IPsec VPN tunnel termination

Path redundancy can be designed into an IPsec VPN quite easily through the use of redundant interfaces on a router or IPsec VPN gateway. As in most IPsec VPN designs, the reconvergence of this design relies most heavily on the reconvergence of the underlying RP upon failure. In this chapter, we discussed this implication and others involved in a redundant path HA design, including the setup and teardown of IPsec and ISAKMP SAs and the use of IKE keepalives in failover situations. We further discussed several ways to expedite the reconvergence of redundant interface IPsec VPNs, including the use of floating static routes to eliminate reconvergence delay due to RP updates and the use of highly available interfaces to eliminate reconvergence delay attributable to teardown and setup of IPsec and ISAKMP SAs (see Table 6-1 for a summary comparison of path redundant VPN designs and HSRP-based IPsec tunnel termination designs).

Table 6-1. Summary Design Considerations for Stateless IPsec HA

Design Consideration

Use of Redundant Paths and Interfaces

Stateless HSRP-Based IPsec Tunnel Termination

Cost

Maintenance of redundant paths can be costly, especially in WAN environments.

Relates directly to the number of routers in the HSRP group. As the number of routers increases, so do costs.

Availability

Path availability offers end-to-end redundancy; more comprehensive in eliminating single point of failure along the path. Availability of redundant interfaces limited to the same box presents single point of failure.

HA is increased at the termination endpoint level. All HSRP routers typically on the same network segment, limiting HA relative to path redundancy. Path redundancy can be designed into HSRP-based HA designs beyond the HSRP group's local network.

Overhead

IKE keepalives; maintenance of redundant tunnel. SADB increases as number of redundant sessions increases.

HSRP hellos on the local HSRP group segment. Can be significant if using subsecond HSRP reconvergence within the HSRP group.

Reconvergence Delay: Phase 1 & 2 SA Maintenance

Stale SAs become a risk in redundant path schemesuse of IKE keepalives is recommended. Reconvergence delay attributable to setup and teardown of SAs can be immunized or eliminated by using highly available interfaces for IPsec tunnel origination and termination.

Stateless HSRP-based tunnel termination requires teardown of SAs using IKE keepalives and regeneration of new SAs when the standby router takes over as active during a failover scenario.

Reconvergence Delay: Redundancy Protocols

Nonedesign relies strictly on the availability of the redundant path and the stability of the underlying routing protocol.

HSRP must reconverge before IPsec can reconverge. Note that although HSRP can be tuned for subsecond failover, it is recommended that care be taken when tuning HSRP timers that tightly.

Reconvergence Delay: Routing Protocols

Design depends heavily on RP reconvergence. When RP scalability and management are not a concern, use of floating static routes can be configured to decrease failover delay attributable to RP reconvergence.

HSRP virtual interfaces must be routable and reachable by their remote peers, but this design minimizes impact due to RP failures.

We also discussed the benefits of stateless IPsec High Availability when terminating IPsec VPN tunnels on HSRP virtual interfaces without the synchronization of IKE and IPsec SADB states between active and redundant IPsec gateways prior to the experience of a reconvergence event. Stateless IPsec HA solutions provide High Availability at the platform level through leveraging the use of HSRP, rather than at the interface level. Stateless IPsec HA solutions therefore add an additional level of resiliency to the system over and beyond the level of resiliency provided by a single IPsec VPN gateway with redundant interfaces. Stateless HA designs such as these are somewhat hardened against RP failovers. There are, however, other elements of this design that contribute to increased failover delays, the most critical of which is the setup and teardown of Phase 1 and Phase 2 SAs using IKE keepalives. Recall from our discussions that IKE keepalives are a requirement for this type of stateless design and that, although they do decrease the timeout of a given Phase 1 SA from 24 hours to about 30 seconds and of a given Phase 2 SA from 1 hour to about 30 seconds, there are still methods that can be deployed to eliminate this contribution to failover delay altogether. Table 6-1 shows a summary comparison of IPsec HA using redundant interfaces and paths, and stateless HSRP-based IPsec tunnel termination using select design and deployment considerations.

Stateful IPsec VPN High Availability Design Summary

Stateful IPsec tunnel termination on virtual interface using SSO is the only local site-to-site HA method discussed in this chapter. Stateful IPsec HA aids the reconvergence of IPsec tunnels in a failover scenario, because the SADB state information on the primary peer is proactively relayed to the redundant peer prior to failover. The two peers use SSO to relay the information and use HSRP to provide a redundant point of origination and termination of the IPsec tunnel itself.

Instead of providing a variety of design benefits over stateless HA methods, stateful HA provides one major advantageminimal reconvergence delay. This is achieved by eliminating the teardown and setup of Phase 1 and Phase 2 SAs. Recall from our previous discussions of stateless IPsec HA that Phase 1 and Phase 2 SAs must be reaped and rebuilt when a failover situation occurs. This is not the case with stateful HA. Recall also that three IKE keepalives must be missed for the SAs to be reaped, and that, at a minimum, those keepalive intervals are set to occur every 10 seconds. This contributes at least 30 seconds of failover delay to the stateless solution, enough delay to cause many business-critical, time-sensitive applications to fail when the IPsec tunnel fails over.

Stateful designs eliminate the 30 seconds of failover delay. Instead, stateful IPsec failover delay is attributable only to RP reconvergence and HSRP reconvergence (which can be configured for subsecond failover). For this reason, stateful failover designs are ideally suited for IPsec deployments where HA is required at the tunnel termination point and business-critical, time-sensitive applications require rapid IPsec VPN reconvergence.


Chapter 7. Solutions for Geographic Site-to-Site High Availability

In Chapter 5, "Designing for High Availability," we had introduced elements of local IPsec Virtual Private Network (VPN) high availability and geographic IPsec VPN high availability. At this point, you should feel comfortable incorporating high availability in to the design of your IPsec VPN tunnel termination points using the design principals discussed in Chapter 6, "Solutions for Local Site-to-Site High Availability." In this chapter, we will extend our focus of IPsec VPN High Availability (HA) to incorporate design principals specific to geographic IPsec VPN HA. The design concepts pertaining to geographic HA are discussed in detail in this chapter, and reinforced with case studies illustrating applications of each design option:

  • Multiple Peer Statements with Routing Protocols and Reverse Route Injection

  • Encrypted Routing Protocols Using IPsec and Generic Routing Encapsulation (GRE)

  • Peer Management with Dynamic Multipoint VPN (DMVPN)

Use of the design topics discussed in this chapter in conjunction with the local IPsec VPN HA topics discussed in Chapter 6 should provide you with the design awareness needed to begin to address fundamental IPsec VPN HA design challenges.


Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers

This design option for IPsec VPN Geographic HA leverages two components to deliver continuity of cleartext routed domains across an untrusted network in a highly available fashion: Reverse Route Injection (RRI) and Multiple IPsec Peering statements. Each delivers complementary functions to deliver the overall solutionRRI is used to preserve routing information across the IPsec VPN tunnel, while multiple IPsec peering statements are used to deliver redundancy.

Solution Overview for RRI with Multiple IPsec Peers

In our discussion of IPsec VPN HA, you have learned that it is important to preserve Layer 3 continuity between cleartext networks on either side of an IPsec VPN tunnel. One method that we have introduced to preserve this continuity is RRI. When two networks want to communicate across an untrusted intermediate network using an IPsec VPN tunnel for data confidentiality, authenticity, integrity, and nonrepudiation, RRI can be configured on each IPsec VPN tunnel endpoint to inject routes to the remote (on the opposite side of the IPsec VPN tunnel) cleartext network back into its local cleartext routed domain. Figure 7-1 illustrates the injection of remote routes in to a local routed domain in an IPsec environment using RRI.

Figure 7-1. Simple Site-to-Site IPsec VPN Design with RRI

[View full size image]

The following is an explanation of the steps illustrated in Figure 7-1:

1. | Host-A on Network A sends traffic to Server-B on Network B, using a default route injected in to the network by C3845ISR-A. This traffic flow causes C3845ISR-A to initiate an IPsec VPN tunnel negotiation.
2. | C3845ISR-A and B negotiate Phase 1 and then Phase 2 IPsec SAs with one another, successfully creating an IPsec VPN tunnel between Network A and Network B.
3. | C3845ISR-A and B are configured for RRI. When Phase 2 SAs are successfully completed in step 2, C3845ISR-A creates static routes for Network B into its routing table. Likewise, C3845ISR-B injects static routes for Network A into its routing table.
4. | The administrators of Network A and Network B have configured their routing protocol processes on C3845ISR-A and C3845ISR-B to redistribute static routes into the routing protocols for Network A and Network B, respectively. The routing protocols distribute the route injected by RRI by sending RP updates back in to their RP domain. Note Routing Protocols (RPs) in this scenario are contained within Networks A and B. There is no exchange of routing protocol updates across the IPsec VPN tunnel established in Step 2 above. Multicast traffic such as the RP traffic used in this example cannot be encrypted in a site-to-site IPsec VPN. Instead, in this example, RRI is used to preserve routing information from Network A to B and vice versa across the IPsec VPN tunnel.
5. | After both RPs have converged to include the RRI-learned routes, C3845ISR-A uses the static route learned by RRI to forward traffic to Server-B to the next hop address of the IPsec VPN peer on C3845ISR-B. C3845ISR-B receives the traffic from C3845ISR-A and forwards it to Server-B, using a route learned by Network_B's IGP.
6. | Server-B forwards the return traffic to C3845ISR-B. C3845ISR-B uses the static route in its routing table learned via RRI in step 3 to forward the return traffic from Server-B to the next hop address of the IPsec VPN tunnel peer IP address on C3845ISR-A. C3845ISR-A receives the return traffic from C3745ISR-B and forwards it to Host_A using a route learned by Network_B's IGP.

This process illustrates dynamic RRI in a basic geographic site-to-site IPsec VPN example. As we'll later see when discussing RRI using multiple IPsec peering statements, the use of RRI in and of itself does not necessarily provide for IPsec HA. Instead, RRI is a component of HA when coupled with multiple peering statements or spread across multiple IPsec VPN tunnel termination points using the stateless or stateful local HA techniques discussed in Chapter 6. Examples 7-1 and 7-2 illustrate the basic configuration and verification of C3845ISR-A and B, respectively, for a simple site-to-site IPsec VPN deployment without geographic or local HA.

Example 7-1 provides several notable configuration tasks relevant to successful RRI implementation. C3845ISR-A is configured to use dynamic RRI (Line 9) to insert the static routes corresponding to the destination IP address in crypto ACL 101 (Lines 8 and 19) using a next-hop IP address of 200.1.1.2 (C3845ISR-A's IP). These routes will be injected only after an IPsec SA is present in the C3845ISR-B's security association database (SADB). C3845ISR-A uses the RP EIGRP AS 10 to populate this route in the routing table of other networked nodes in Network A. To do this, the RRI-learned routes must be redistributed in to the routing protocol by issuing the redistribute static command provided in Line 13 of Example 7-1. Enhanced Interior Gateway Routing Protocol (EIGRP) requires that the routes be given an EIGRP-specific metric, which is accomplished either by adding a metric for static routes only or by creating a default metric for redistributed routes, as shown in Example 7-1, line 15. RRI will use the destination IP network (192.168.2.0/24) in crypto ACL 101 to populate a static route in the routing table. The next hop for this route will be the IPsec peer defined in the crypto map, 200.1.1.2 (Example 7-1, line 6).

Example 7-1. Simple Site-to-Site RRI (Dynamic) Configuration on C3845ISR-A from Figure 7-1

1  C3845ISR-A#show running-config
2  Building configuration...
3  !
4  !
5  crypto map chap7-rri-1 10 IPsec-isakmp
6   set peer 200.1.1.2
7   set transform-set chap7-rri-1
8   match address 101
9   reverse-route
10 !
11 !
12 router eigrp 10
13  redistribute static
14  network 10.0.0.0
15  default-metric 1500 10 128 128 1500
16  no auto-summary
17 !
18 !
19 access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Like C3845ISR-A in Example 7-1, C3845ISR-B is configured to use dynamic RRI to insert the static routes corresponding to the destination IP address in crypto ACL 101 using a next-hop IP address of 200.1.1.1 (C3845ISR-A's IP). Because the router is configured for dynamic RRI (Example 7-2, line 9), these routes will be injected only after an IPsec SA is present in the C3845ISR-B's SADB. C3845ISR-B uses the RP EIGRP AS 10 to populate this route in the routing table of other networked nodes in Network A. To do this, the RRI-learned routes must be redistributed in to the routing protocol. EIGRP requires that the routes be given an EIGRP-specific metric, which is accomplished either by adding a metric for static routes only or by creating a default metric for redistributed routes as shown later. RRI will use the destination IP network (192.168.1.0/24) in crypto ACL 101 to populate a static route in the routing table. The next hop for this route will be the IPsec peer in the crypto map, 200.1.1.1.

Example 7-2. Simple Site-to-Site RRI (Dynamic) Configuration on C3845ISR-B from Figure 7-1

1  C3845ISR-B#sh run
2  Building configuration...
3  !
4  !
5  crypto map chap7-rri-1 10 IPsec-isakmp
6   set peer 200.1.1.1
7   set transform-set chap7-rri-1
8   match address 101
9   reverse-route
10 !
11 !
12 router eigrp 10
13  redistribute static
14  network 10.0.0.0
15  default-metric 1500 10 128 128 1500
16  no auto-summary
17 !
18 !
19 access-list 101 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

The process and examples discussed thus far illustrate the behavior of dynamic RRI, where static routes are dynamically created upon the creation of a Phase 2 IPsec SA. There is another form of RRI, called static RRI, where RRI will create static routes on the IPsec VPN gateway as soon as a crypto map referencing a valid crypto ACL, peer, and transform set is applied to a valid crypto interface.

Note that, in the process illustrated in step 1 above, the initial traffic flow triggering the IPsec VPN tunnel negotiation uses a predefined default route injected by C3845ISR-A. In the above process, a predefined route is required, as dynamic RRI will not inject a route for hosts on Network A to use until a Phase 2 SA is created (step 3). Static RRI, however, would have injected routes for Network B in to Network A as soon as the crypto ACL was referenced on a valid crypto map on a valid crypto interface. Therefore, with static RRI, the RRI learned routes could have been used instead of the predefined default route injected in step 1. Examples 7-3 and 7-4 illustrate the configuration and verification of static RRI respectively.

Caution

Static RRI injects a route before the establishment of a Phase 2 SA, which provides a way for interesting traffic to trigger the establishment of a Phase 2 SA. However, if the IPsec tunnel cannot be established (for example, if the path is severed between the two IPsec tunnel endpoints), traffic destined for the RRI-learned static route could potentially become black-holed, as that static route will always exist in the routing table regardless of the presence of an IPsec (Phase 2) SA in the SADB.

Example 7-1, lines 5-9, define the crypto map to be used. The crypto map "chap7-rri-1" applies, at a minimum, the transform set, IPsec peer, and crypto ACL to a crypto interface. In this example, crypto acl 101 defines the traffic to be included in the crypto switching path on this interface. The crypto map also applies the 3DES/MD5-HMAC transform referenced in the transform set "chap7-rri-1" and the peer 200.1.1.2. Static RRI is configured on this crypto map (Example 7-1, line 9), immediately injecting a static route in to the routing table. Once this crypto map has a valid crypto ACL, peer, and transform set, the application of the crypto map to the interface static RRI immediately injects the appropriate static route in to the routing table (see Example 7-4 for verification). EIGRP AS 10 is configured to redistribute static routes, which is required to inject the RRI learned static routes in to the dynamic routing protocol. This effectively injects RRI-learned static routes for Network B into the private network behind C3845ISR-A (Network A). In order for EIGRP to successfully redistribute the static routes, a metric must be defined specific to the redistribute static command, or with the default-metric command as listed below. ACL 101 defines the traffic to be included in the crypto switching path. RRI will use the destination IP address of the crypto ACL defined in the ACL to populate the RRI static route destination in the routing table. RRI will use the IPsec peer defined in the crypto map as the next-hop IP for this route.

Example 7-3. Static RRI Configuration

1  C3845ISR-A#sh run
2  Building configuration...
3  !
4  !
5  crypto map chap7-rri-1 10 IPsec-isakmp
6   set peer 200.1.1.2
7   set transform-set chap7-rri-1
8   match address 101
9   reverse-route static
10 !
11 interface Ethernet0/0
12  ip address 200.1.1.1 255.255.255.252
13  half-duplex
14  crypto map chap7-rri-1
15 !
16 !
17 router eigrp 10
18  redistribute static
19  network 10.0.0.0
20  default-metric 1500 10 128 128 1500
21  no auto-summary
22 !
23 !
24 access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Note from the console output in Example 7-4, lines 18-20, that a Phase 2 SA is not required to inject RRI-learned routes with static RRIthe static route will exist in the routing table regardless of whether IPsec has successfully established Phase 2 SAs or not. Also note from the console output in Example 7-4, line 3, that RRI inserted a static route immediately, prior to the negotiation of IPsec or IKE SAs

Example 7-4. Static RRI Verification

1  C3845ISR-A(config)#crypto map chap7-rri-1 10 IPsec-isakmp
2  C3845ISR-A(config-crypto-map)#reverse-route static
3  *Mar  1 00:42:25.431: IPSEC(rte_mgr): VPN Route Added 192.168.2.0 255.255.255.0 via
     200.1.1.2 in IP DEFAULT TABLE
4  C3845ISR-A#show crypto isakmp sa
5  dst             src              state         conn-id slot
6
7  C3845ISR-A#show crypto IPsec sa
8
9  interface: Ethernet0/0
10     Crypto map tag: chap7-rri-1, local addr. 200.1.1.1
11
12    protected vrf:
13    local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
14    remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
15    current_peer: 200.1.1.2:500
16      PERMIT, flags={origin_is_acl,}
17     #pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
18     #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
19     #pkts compressed: 0, #pkts decompressed: 0
20     #pkts not compressed: 0, #pkts compr. failed: 0
21     #pkts not decompressed: 0, #pkts decompress failed: 0
22     #send errors 0, #recv errors 0
23
24      local crypto endpt.: 200.1.1.1, remote crypto endpt.: 200.1.1.2
25      path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
26      current outbound spi: 0
27      inbound esp sas:
28
29      inbound ah sas:
30
31      inbound pcp sas:
32
33      outbound esp sas:
34
35      outbound ah sas:
36
37      outbound pcp sas:
38 C3845ISR-A#show crypto engine connections active
39
40   ID Interface            IP-Address      State  Algorithm       Encrypt  Decrypt
41 C3845ISR-A#show ip route static
42 S    192.168.2.0/24 [1/0] via 200.1.1.2

Note

The default behavior of RRI in Cisco IOS for static crypto maps was to inject static routes as soon as a valid crypto ACL was referenced on a valid crypto interface. For dynamic crypto maps, the default behavior of RRI in Cisco IOS was to inject static routes upon the successful creation of a Phase 2 SA. In IOS versions 12.3(14)T and later, the default behavior for both static and dynamic crypto maps and RRI is to inject static routes upon the successful establishment of a Phase 2 SA.

Until this point in the chapter, we have discussed only simple RRI scenarios used to preserve routing table continuity between two networks situated on opposite ends of the IPsec VPN tunnel. We've discussed how this can be done without the use of routing protocol exchanges across the IPsec VPN tunnel using RRI, and the differences between static and dynamic RRI methods. These discussions and examples have yet to include any means of HA. Indeed, all of the methods previously are single-peer definitions with one termination at each end of the tunnel. Chapter 6 discusses several methods of designing local HA in IPsec VPNs, and we will now expand those discussions to include geographic HA methods using the definition of multiple IPsec VPN peers. Figure 7-2 illustrates a variation on Figure 7-1 that adds geographic HA by adding multiple IPsec peering statements on Network_A's IPsec VPN gateway, C3845ISR-A. These peers point to two separate IPsec VPN gateways on Network B, C3845ISR-B and C. (The number steps in Figure 7-2 are discussed later in this section.)

Figure 7-2. Geographic HA with RRI and Multiple IPsec Peers

[View full size image]

The redundancy added by defining multiple peers on IPsec VPN gateway C3845ISR-A does not radically change the RRI processes we've discussed in the simpler design illustrated in Figure 7-1 and Example 7-1 through Example 7-4. However, it does heighten the need for dynamic RRI over static RRI. This is due to the fact that, when multiple peers are defined, static RRI creates two identical routes to different next-hop IP addresses (the opposite end of the IPsec VPN tunnel). Example 7-5 illustrates static RRI behavior when multiple IPsec peers are defined, in which C3845ISR-A attempts to do per-packet load balancing between multiple next-hops (peers) for the same RRI-learned route. Two peers defined here cause static RRI to inject a static route with two equal cost paths in to the routing table (one valid next-hop to each of the defined peers, 200.1.1.2 and 3, respectively). Because static RRI injects two entries in to the routing table, one corresponding to a valid peer and another corresponding to a dead peer, half of the packets are dropped. This occurs because the router attempts to load-balance between a valid peer and an invalid peer (all traffic forwarded to the invalid peer is subsequently dropped). The connection entries in the crypto engine reflect the packet loss described above. Only half of the fifty packets are encrypted/decrypted using the current active IPsec SA in the crypto engine SADB. The router attempts to forward the other half to an invalid peer, and they are subsequently dropped.

Example 7-5. Static RRI with Multiple IPsec Peering Statements

1  Host-A#ping
2  !
3  !
4  Target IP address: 192.168.2.1
5  !
6  !
7  Source address or interface: 192.168.1.1
8  !
9  !
10 Sending 50, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
11 Packet sent with a source address of 192.168.1.1
12 !.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.
13 Success rate is 50 percent (25/50), round-trip min/avg/max = 12/16/20 ms
14
15 C3845ISR-A#show running-config
16 Building configuration...
17 !
18 !
19 crypto map chap7-rri-1 10 IPsec-isakmp
20  set peer 200.1.1.2
21  set peer 200.1.1.3
22  set transform-set chap7-rri-1
23  match address 101
24  reverse-route
25
26 C3845ISR-A#show ip route stat
27 S    192.168.2.0/24 [1/0] via 200.1.1.2
28                     [1/0] via 200.1.1.3
29
30 C3845ISR-A#show crypto engine connections active
31
32   ID Interface            IP-Address      State  Algorithm           Encrypt  Decrypt
33    2 Ethernet0/0          200.1.1.1       set    HMAC_MD5+DES_56_CB        0        0
34 2000 Ethernet0/0          200.1.1.1       set    HMAC_MD5+3DES_56_C        0        25
35 2001 Ethernet0/0          200.1.1.1       set    HMAC_MD5+3DES_56_C        25        0

The behavior of Example 7-5 will lead to other unexpected behavior, potentially including the black holing of valid IP traffic to the inactive peer IP address. In order to avoid this behavior, dynamic RRI should be used for highly available IPsec VPN designs where RRI is required. Unlike static RRI, dynamic RRI will install only the static routes with the next hop address of the IPsec peer address resident in the current SADB Phase 2 SA entry. Consider a failover scenario in the network depicted in Figure 7-2. The following numbered list outlines the expected behavior of the IPsec VPN reconvergence process for the dynamic RRI implementation with multiple IPsec peer definitions in Figure 7-2:

1. | C3845ISR-A and C3845ISR-B successfully negotiate an IPsec VPN tunnel and inject RRI-learned static routes in to their routing protocol processes for Network A and Network B, respectively.
2. | A failure occurs on the serial link between C3845ISR-A and C3845ISR-B, causing IPsec VPN peers to miss three IKE keepalives and tear down the IPsec VPN tunnel.
3. | C3845ISR-A and B remove the RRI-learned route in step 1 from their routing table.
4. | Host_A continues to send traffic to Server-B, causing C3845ISR-A to initiate Phase 1 SA negotiation with C3845ISR-C.
5. | C3845ISR-A negotiates Phase 1 and 2 SAs with C3845ISR-C sequentially, using the backup IPsec peer definition (C3845ISR-C).
6. | C3845ISR-A and C are both configured for dynamic RRI. Therefore, once the IPsec VPN tunnel has reconverged from the failover in step 2, static routes for Networks A and B are populated in the routing tables of C3845ISR-C and A, respectively, once the crypto-protected address space defined in the crypto ACLs is reflected and populated in the IPsec SADB.
7. | C3845ISR-A and C are configured to redistribute static routes, effectively injecting the RRI-learned static routes in step 5 in to their routing protocols.
8. | Once both RPs have converged to include the RRI-learned routes, C3845ISR-A uses the static route learned by RRI to forward traffic to Server-B to the next hop address of the IPsec VPN peer on C3845ISR-C. C3845ISR-C receives the traffic from C3845ISR-A and forwards it to Server-B, using a route learned by Network_B's IGP.
9. | Server-B forwards the return traffic to C3845ISR-C. C3845ISR-C uses the static route in its routing table learned via RRI in step 3 to forward the return traffic from Server-B to the next hop address of the IPsec VPN tunnel peer IP address on C3845ISR-A. C3845ISR-A receives the return traffic from C3745-C and forwards it to Host_A using a route learned by Network_B's IGP.

While RRI provides continuity for IP routing across IPsec VPN tunnels, it is the use of multiple peering statements on C3845ISR-A that provides the redundancy that lends itself to a highly available design. This design option can be further tuned to yield a greater degree of availability using IKE keepalives or IKE dead peer detection (DPD). For more information on IKE keepalives and DPD, please refer back to previous discussions in Chapter 5. Example 7-6 provides sample configurations for the HA design illustrated in Figure 7-2 using RRI with Multiple IPsec Peer definitions on C3785-A. The successful reconvergence process described above is verified using the diagnostic commands included in Example 7-7.

The crypto map in Example 7-7 is configured with redundant peers. Dynamic RRI is configured under the crypto map, injecting static routes for the destination IP address configured in Crypto ACL 101 to the next-hop of the IPsec peer actively populated in the SADB. Unlike Static RRI, this route is populated only upon population of the SADB with the appropriate Phase 2 SA. RRI uses the destination IP defined in crypto ACL 101 (192.168.2.0/24) to populate the static routing table upon successful creation of a Phase 2 SA.

Example 7-6. C3845ISR-A Configuration Using Dynamic RRI with Multiple IPsec Peer Definitions

1  C3845ISR-A#show running-config
2  Building configuration...
3  !
4  !
5  crypto map chap7-rri-1 10 IPsec-isakmp
6   set peer 200.1.1.2
7   set peer 200.1.1.3
8   set transform-set chap7-rri-1
9   match address 101
10  reverse-route
11 !
12 !
13 access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

As confirmed by the diagnostic output of Example 7-7, lines 1-4, the crypto engine has no active SADB entries. As such, RRI will not populate the static routing table with the appropriate static routes (Example 7-7, lines 5-6). With static RRI, the configuration of Example 7-6 would populate the routing table with a static route regardless of the state of C3845ISR-A's SADB. Debugging the crypto IPsec process enables us to determine exactly when the RRI-learned static route is populated in the routing table by dynamic RRI (Example 7-7, line 18). A Phase 2 SA is created, also illustrated in Example 7-7 below (lines 21-28). The destination proxy address is the RRI-learned route, and the IPsec peer IP of this SA is the RRI-learned route's next hop. IPsec SAs are now confirmed to exist in C3845ISR's SADB, as shown by the diagnostic output pertaining to C3845ISR-A's crypto engine in Example 7-7, lines 29-34, following. As expected, dynamic RRI created a route for the destination proxy address (192.168.2.0/24) defined in crypto ACL 101 and the IPsec peer address used in the Phase 2 SA (200.1.1.2).

Example 7-7. Verifying C3845ISR VPN Failover with Dynamic RRI and Multiple IPsec Peer Definitions

1 C3845ISR-A#show crypto engine connections active
2
3   ID Interface            IP-Address      State  Algorithm        Encrypt     Decrypt
4

5  C3845ISR-A#show ip route static
6
7  C3845ISR-A#debug crypto IPsec
8  Crypto IPSEC debugging is on
9  !
10 !
11 *Aug 11 08:11:20.307: Crypto mapdb : proxy_match
12         src addr     : 192.168.1.0
13         dst addr     : 192.168.2.0
14         protocol     : 0
15         src port     : 0
16         dst port     : 0
17 *Aug 11 08:11:20.307: IPSEC(crypto_IPsec_sa_find_ident_head): reconnecting with the
     same proxies and 200.1.1.2
18 *Aug 11 08:11:20.307: IPSEC(rte_mgr): VPN Route Event create routes for peer or rekeying
19 *Aug 11 08:11:20.307:  IPSEC(rte_mgr): VPN Route Refcount 2
20 *Aug 11 08:11:20.307: IPsec: Flow_switching Allocated flow for sibling 80000006
21 *Aug 11 08:11:20.307: IPSEC(create_sa): sa created,
22   (sa) sa_dest= 200.1.1.1, sa_proto= 50,
23     sa_spi= 0x768C7B66(1988918118),
24     sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2003
25 *Aug 11 08:11:20.307: IPSEC(create_sa): sa created,
26   (sa) sa_dest= 200.1.1.2, sa_proto= 50,
27     sa_spi= 0x5A5D5B9B(1516067739),
28     sa_trans= esp-3des esp-md5-hmac , sa_conn_id= 2004
29 C3845ISR-A#show crypto engine connections active
30
31   ID Interface            IP-Address      State  Algorithm           Encrypt     Decrypt
32    6 FastEthernet0/0      200.1.1.1       set    HMAC_MD5+DES_56_CB        0           0
33 2001 FastEthernet0/0      200.1.1.1       set    3DES+MD5                  0           3
34 2002 FastEthernet0/0      200.1.1.1       set    3DES+MD5                  3           0
35 C3845ISR-A#show ip route static
36 S    192.168.2.0/24 [1/0] via 200.1.1.2


Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing Protocols

Tunneling traffic in GRE prior to encryption with IPsec enables the encryption of multicast traffic. This is due to the fact that the multicast traffic is represented as a payload of a unicast packet after it has been encapsulated with GRE. As such, once the packet has been encapsulated in GRE, it is presented to the crypto engine as a unicast packet. We have referred to this as IPsec+GRE in previous chapters. IPsec+GRE is a key design option for passing multicast traffic, including RPs that use multicast updates, through an encrypted tunnel. As such, sending routing protocol updates over an IPsec+GRE tunnel serves as an alternative to RRI for preserving IP routing continuity across an IPsec VPN tunnel.

Solution Overview for IPsec+GRE with Encrypted Routing Protocols

IPsec+GRE tunnels have increased in popularity primarily due to the increase in multicast application adoption. As these applications drive the amount of multicast traffic in the overall traffic profile upward, the need to secure this type of traffic increases proportionally. IGP multicast update traffic is one such critical multicast application that is often included in the crypto switching path.

Tip

Cisco IOS includes unicast RP update features for BGP and most IGPs. Encrypted unicast RP updates can be exchanged over the IPsec VPN tunnel to preserve IP routing continuity without the use of GRE. More information on Unicast RP updates is provided in Chapter 5.

Sending RP updates across the IPsec tunnel enables RP adjacencies to be built between two networks situated on opposite sides of an IPsec tunnel, as illustrated in Figure 7-3. This solution therefore serves as an alternative to RRI for preserving IP routing continuity between IP networks across an IPsec VPN tunnel.

Figure 7-3. IPsec+GRE with Encrypted Routing Protocol Updates

[View full size image]

The administrators of the network illustrated in Figure 7-3 face the same challenges as in the network topologies of Figures 7-1 and 7-2. Instead of using RRI to allow Network A and Network B to route between one another over the IPsec VPN tunnel, the administrators choose to create a GRE tunnel between C3845ISR-A and B through which RP updates are exchanged. All GRE traffic is then encrypted with a transform defined in the IPsec configuration on C3845ISR-A and B. This effectively allows the administrators of Network A and B to run the same routing protocol, preserving continuity of the routing tables of Network A and B by leveraging encrypted RP updates over the IPsec+GRE tunnel. The resulting forwarding numbered process along the path from Host-A to Server-B in Figure 7-3 is as follows:

1. | ISAKMP and IPsec are configured on C3845ISR-A and B. Once the GRE tunnel and RP configuration is complete on C3845ISR-A and B and traffic is received matching a active crypto ACL, the crypto engine initiates the negotiation of Phase 1 and 2 SAs on C3845ISR-A and B, completing the creation of the IPsec+GRE tunnel. Note Beware that control plane traffic such as GRE Keepalives, RP Hellos, and RP updates passing through the GRE tunnel will keep the IPsec+GRE tunnel up, as they are encapsulated in GRE causing a match on the IPsec+GRE crypto ACL.
2. | The GRE tunnel interfaces created in #1 are configured to forward EIGRP RP updates between C3845ISR-A and B. Routes for Network A are populated in the routing tables of networked nodes throughout Network B and vice versa.
3. | When Host-A sends traffic to Server-B, C3845ISR-A uses a route table entry for Server-B learned via EIGRP in #2 to make the Layer 3 forwarding decision. C3845ISR-A therefore forwards traffic from Host-A to Server-B out of the GRE tunnel interface.
4. | When the traffic is encapsulated in GRE, the crypto engine recognizes a crypto ACL match, causing the GRE packet resulting from #3 to be encrypted using ESP and forwarded to C3845ISR-B across the IPsec VPN tunnel.
5. | C3845ISR-B receives the encrypted traffic from #4 and decrypts it. After the ESP header is removed, the resulting GRE packet is then decapsulated.
6. | C3845ISR-B now forwards the resulting packet from #5 to Server-B using the destination IP of the original IP packet sent by Host-A in #3.
7. | When Server-B sends return traffic to Host-A, C3845ISR-B uses a routing table entry for Host-A learned via EIGRP in #2 to make the Layer 3 forwarding decision.
8. | C3845ISR-B encrypts the GRE packet resulting from the GRE encapsulation in #7 using ESP, and subsequently forwards the encrypted packet to C3845ISR.
9. | C3845ISR-A removes the Extended Services Processor (ESP) header attached by C3845ISRA in #8, and decapsulates the resulting GRE packet.
10. | C3845ISR-A forwards the return traffic from Server-B to Host-A using the destination of the original IP packet created in #7.

The important difference in this design is that encrypted routing protocols essentially replace RRI as a means of IP routing continuity between Network A and Network B. With IPsec+GRE, routing protocols updates can be exchanged only once the IPsec tunnel is successfully established, which is more akin to a dynamic RRI implementation as opposed to a static one. Unlike either mode of RRI, redistribution of static routes in to the dynamic Interior Gateway Protocol (IGP) is not required. Instead, RP updates are automatically propagated throughout Network A and Network B.

While the use of IPsec+GRE for encrypted routing protocols does deprecate the need for RRI, it does raise new requirements. Obviously, GRE tunnels must be created. Additionally, the crypto ACL is changed to include only GRE traffic between the tunnel endpoints. This is due to the fact that the crypto engine will now be presented with a GRE header resulting from the GRE encapsulation for inclusion in the crypto switching path based on a crypto ACL match, rather than the original headers now included as parts of the GRE payload. These necessary configuration elements are listed for C3845ISR-A and B of Figure 7-3 in Example 7-8, and the verification of the configuration is provided using the diagnostic commands in Example 7-9 later in our discussion of IPsec+GRE HA.

Thus far, we've covered two options for establishing IP routing continuity between two networks across an IPsec VPN tunnel: IPsec+GRE with encrypted RP updates and RRI. Generally speaking, each method is used to accomplish the same task of enabling each end of an IPsec VPN tunnel to route to the opposite end. However, each method has different benefits and requirements. Keep several design considerations, such as the ones provided in the following list, in mind when choosing one or another:

  • Encrypted IP Multicast Application Requirements: If there are other IP multicast applications that require data confidentiality, then IPsec+GRE may be a requirement regardless of the need for encrypted multicast updates. RRI does not provide a solution for IP multicast data flows. Instead it is a means to preserve unicast IP routing continuity across the IPsec VPN tunnel. Therefore, if IPsec+GRE is a requirement based on IP multicast application flow, then the same IPsec+GRE tunnel can be used for encrypted multicast RP updates.

  • GRE Support and Scalability: If GRE is unsupported; another means of preserving IP routing continuity is therefore required. The scalability and performance of GRE is a more common concern than support for GRE itself. In many of today's IPsec VPN platforms, GRE encap/decap processes are not supported in hardware. This becomes a disadvantage on higher-end VPN platforms that accelerate crypto in hardware, as the GRE process then becomes the bottleneck. If encrypted IP multicast flows are not a requirement, RRI becomes a more attractive design option for geographic HA when the crypto switching path must be executed in hardware.

  • Reverse Route Injection Support: RRI is not an Internet Engineering Task Force (IETF) standard, and is instead a feature proprietary to Cisco IPsec VPN platforms. In vendor-diverse environments, the IPsec VPN design options available to network architects do not include RRI.

At this point, the fundamental differences, requirements, and design drivers behind an RRI or IPsec+GRE decision should be clear. However, the IPsec+GRE solutions presented thus far have been limited to simple site-to-site designs without incorporating any elements of HA. We will now take a look at the design elements specific to geographic HA in IPsec+GRE, noting that these elements should indeed be coupled with the local HA design concepts covered in Chapter 6 for a full IPsec+GRE HA design. The numbered steps in Figure 7-4 are covered later in this section.

Figure 7-4. Geographic HA with IPsec+GRE and Encrypted Multicast RP Updates

[View full size image]

The degree of availability of a given IPsec+GRE design such as the one illustrated in Figure 7-4 depends primarily on the reconvergence of three components:

  • IPsec VPN Tunnel Reconvergence

  • GRE Tunnel Reconvergence

  • Routing Protocol Reconvergence

Before any reconvergence can occur across the IPsec VPN tunnel, stale Internet Key Exchange (IKE) and IPsec SAs must be reaped from the SADB, and new ones must be established between valid peers. In Chapter 5, we discussed the use of IKE keepalives and DPD to expedite reconvergence of an IPsec VPN tunnel in a failover situation. If IKE keepalives or DPD is not used, stale SAs could remain present in the SADB for unacceptably long periods of time, potentially stalling the reconvergence of the IPsec VPN tunnel.

Note

The default SA lifetimes for IKE and IPsec SAs in Cisco IOS are 38400s and 3600s, respectively.

IKE keepalives intervals can be configured as frequently as 10s apart. Therefore, using IKE keepalives potentially expedites stale SA cleanup from the SADB from as long as 3600s to as short as 30s (three missed IKE keepalives at 10s intervals). As such, IKE keepalives and DPD are a critical part of geographic HA concepts for both RRI and IPsec+GRE designs. IKE keepalives and DPD are also a critical part of IPsec peer availability, which is discussed in detail in Chapter 5.

After the IPsec VPN peers have been managed appropriately, and a new IPsec VPN tunnel has been established, the GRE tunnel must be established. This component of the overall reconvergence process is not expected to be materially relevant to the routing protocol reconvergence that must occur once the GRE tunnel is established. Once the IPsec+GRE tunnel is established, RP neighbor adjacency must be built between the two GRE tunnel interfaces. This process can vary based on the routing protocol selected. However, consider, as an example, that most EIGRP interfaces use a default hold timer of 15s (three times the 5s hello interval), which is the time it will take for that EIGRP neighbor to be declared dead so that a new one can be established to a viable peer.

For geographic IPsec HA deployments, the reconvergence component associated with RP reconvergence plays a critical role when deciding between IPsec+GRE vs. IPsec with RRI. Consider the failover scenario in Figure 7-4 in which the following steps are executed to facilitate reconvergence IPsec+GRE tunnel and associated EIGRP neighbor:

1. | A failure occurs between C3845ISR-A and C3845ISR-B, causing C3845ISR-A's primary IPsec peer to become unavailable (C3845ISR-B).
2. | C3845ISR-A fails to receive responses to 3 IKE keepalives timed at 10s intervals, causing C3845ISR-A to reap the IKE and IPsec SAs from its SADB.
3. | During the time it takes to miss the three IKE keepalives in #2, the EIGRP holddown timer expires for the EIGRP neighbor relationship between C3845ISR-A and B, at which point the EIGRP neighbor is removed from the neighbor table.
4. | C3845ISR-A and C's routing tables reconverge, causing all of the routes learned over the tunnel interface to B to point over the GRE tunnel interface to C3845ISR-C.
5. | Host-A forwards traffic to Server-B. C3845ISR-A uses a routing table entry learned via EIGRP RP updates sent in #5 to forward the traffic from Host-A through the IPsec+GRE tunnel.
6. | The traffic in #6 is encapsulated in GRE by C3845ISR-A. After the packet is GRE-encapsulated, it is encrypted with ESP and forwarded to the redundant IPsec peer at C3845ISR-C.
7. | C3845ISR-C decrypts the traffic received in #6, decapsulates the resulting GRE packet, and forwards the traffic to Server-B based on the destination address in the original IP header sent from Host-A.
8. | Server-B forwards the return traffic to C3845ISR-C. C3845ISR-C uses a routing table entry learned via EIGRP RP updates sent in #4 to forward the return traffic from Server-B back to Host-A through the IPsec+GRE tunnel.
9. | The traffic in #8 is encapsulated in GRE by C3845ISR-C. After it is GRE-encapsulated, the packet is encrypted with ESP and forwarded to the IPsec peer at C3845ISR-A.
10. | C3845ISR-A decrypts the traffic received in #9, decapsulates the resulting GRE packet, and forwards the traffic on to Host-A based on the destination address in the original IP header sent from Server-B in #8.

Similar to our discussion of RRI with multiple IPsec peers, IPsec+GRE in and of itself does not provide added degrees of availability to the design. Instead, IPsec+GRE is hardened using multiple, redundant, IPsec peers and redundant GRE tunnel interfaces that enable the IPsec+GRE tunnel to reconverge over a redundant path. This concept is referred to as path availability, and is discussed in greater detail in Chapter 5. Example 7-8 includes a sample configuration used on C3845ISR-A in Figure 7-4 providing HA using multiple IPsec peer definitions and redundant GRE tunnels. The failover process described previously for the IPsec+GRE deployment illustrated in Figure 7-4 is verified in Example 7-9.

Internet Security Association and Key Management Protocol (ISAKMP) is configured to use preshared key (PSK) authentication with an MD5 hash, DES encryption (default), and a group 2 Diffie-Hellman modulus. A PSK of Cisco is used to authenticate IKE SAs with C3845ISR-A (200.1.1.2) and B (200.1.1.3). The cipher used on the cleartext traffic sent through the IPsec VPN tunnel to the spokes is ESP 3DES with MD5 HMAC authentication on the ciphered blocks. Unlike our previous discussions of RRI with multiple crypto maps, this IPsec+GRE design leverages multiple crypto map process IDs (10 and 20) to define different IPsec peers and crypto ACLs. This effectively enables the use of two IPsec+GRE tunnels to become active simultaneously, offering the ability to load balance across each in an active/active fashion. There are two crypto ACLs that are defined in their own respective process IDs (10 and 20) under the same crypto map, "chap7-IPsec+gre":

  • Crypto ACL 101 defines GRE traffic from the Tunnel12's source IP to Tunnel12's destination IP to be protected in the crypto switching path. Crypto ACL 101 is configured to protect all traffic through GRE tunnel 12. It accomplishes this by including any GRE packets sourced from 1.1.1.1 (GRE tunnel source on C7304) to 2.2.2.2 (GRE tunnel destination on C3845ISR-A).

  • Crypto ACL 102 defines GRE traffic from the Tunnel13's source IP to Tunnel12's destination IP to be protected in the crypto switching path. Crypto ACL 102 is configured to protect all traffic through GRE tunnel 13. It accomplishes this by including any GRE packets sourced from 1.1.1.1 (GRE tunnel source on C7304) to 3.3.3.3 (GRE tunnel destination on C3845ISR-B).

It is also important to note that there are two different routing protocol implementations relevant to the design. Unless the GRE tunnels are built across a directly connected L3 segment, a routing protocol is needed between the two GRE tunnel endpoints to successfully establish the GRE tunnel. This routing protocol will also be used to establish Phase 1 and 2 SAs that protect the GRE tunnels. In this case, Open Shortest Path First (OSPF) (OSPF 10) is used to accomplish both of these tasks. This routing protocol's updates and hellos will not be protected by IPsec. A second routing protocol is used to provide continuity between two routed domains on opposite sides of the IPsec VPN tunnel. In this case, EIGRP (EIGRP 10) is used to accomplish this by sending EIGRP hellos and updates across the GRE tunnel. These routing protocol updates and hellos will be encrypted because they are encapsulated with GRE, which is defined in the crypto ACLs 101 and 102 accordingly.

Example 7-8. IPsec HA Configuration Using IPsec+GRE with Multiple Crypto-Process IDs and Redundant, Load-Sharing GRE Interfaces (C3845ISR-A)

1  C3845ISR-A#show running-config
2  Building configuration...
3  !
4  !
5  crypto isakmp policy 10
6   hash md5
7   authentication pre-share
8   group 2
9  crypto isakmp key cisco address 200.1.1.2
10 crypto isakmp key cisco address 200.1.1.3
11 crypto isakmp keepalive 10
12 !
13 crypto IPsec transform-set chap7-IPsec+gre esp-3des esp-md5-hmac
14 !
15 crypto map chap7-IPsec+gre 10 IPsec-isakmp
16  set peer 200.1.1.2
17  set transform-set chap7-IPsec+gre
18  match address 101
19 crypto map chap7-IPsec+gre 20 IPsec-isakmp
20  set peer 200.1.1.3
21  set transform-set chap7-IPsec+gre
22  match address 102
23 !
24 interface Tunnel12
25  ip address 12.1.1.1 255.255.255.252
26  tunnel source 1.1.1.1
27  tunnel destination 2.2.2.2
28 !
29 interface Tunnel13
30  ip address 13.1.1.1 255.255.255.252
31  tunnel source 1.1.1.1
32  tunnel destination 3.3.3.3
33 !
34 interface Loopback1
35 ip address 1.1.1.1 255.255.255.255
36 !
37 !
38 router eigrp 10
39  network 10.0.0.0
40  network 12.1.1.0 0.0.0.3
41  network 13.1.1.0 0.0.0.3
42  no auto-summary
43 !
44 router ospf 10
45  log-adjacency-changes
46  network 1.1.1.1 0.0.0.0 area 0
47  network 200.1.1.0 0.0.0.255 area 0
48 !
49 !
50 access-list 101 permit gre host 1.1.1.1 host 2.2.2.2
51 access-list 102 permit gre host 1.1.1.1 host 3.3.3.3

The crypto engine entries shown in Example 7-9, lines 1-9, verify two active IPsec VPN tunnels, each with their own ISAKMP SA and 2 IPsec SAs. This confirms that the IPsec+GRE implementation is currently redundant in an active/active load-balanced format across the two tunnels. The output in Example 7-9, lines 11-18, confirms that both the local interface providing connectivity to private networks and the two GRE tunnels to the branches (C3845ISR-A and B) are all injected into the appropriate routing protocol (EIGRP AS 10) on C7304. Diagnostic output provided in Example 7-9, lines 20-26, confirms that there are three EIGRP neighbors currently established on C7304: one for connectivity to the private networks behind C7304 and two additional ones for connectivity to the private networks behind C3845ISR-A and B across the IPsec+GRE tunnels. Routes are being learned via EIGRP 10 over the two IPsec+GRE tunnel interfaces from C7304 to C3845ISR-A and B, respectively, as confirmed by Example 7-9, lines 28-40. Each route has two equal cost paths that C7304 will use to load balance over the two IPsec+GRE tunnels currently operating in an active/active fashion.

Example 7-9. Verifying IPsec VPN Failover with IPsec+GRE with Multiple Crypto-Process IDs and Redundant, Load-Sharing GRE Interfaces (C3845ISR-A)

1  C3845ISR-A#show crypto engine connections active
2
3    ID Interface            IP-Address      State  Algorithm           Encrypt Decrypt
4     7 FastEthernet0/0      200.1.1.1       set    HMAC_MD5+DES_56_CB        0       0
5     8 FastEthernet0/0      200.1.1.1       set    HMAC_MD5+DES_56_CB        0       0
6  2001 FastEthernet0/0      200.1.1.1       set    3DES+MD5                  0     156
7  2002 FastEthernet0/0      200.1.1.1       set    3DES+MD5                123       0
8  2003 FastEthernet0/0      200.1.1.1       set    3DES+MD5                157       0
9  2004 FastEthernet0/0      200.1.1.1       set    3DES+MD5                  0     124
10
11 C3845ISR-A#show ip eigrp interfaces
12 IP-EIGRP interfaces for process 10
13
14                         Xmit Queue   Mean   Pacing Time   Multicast    Pending
15 Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
16 Fa0/1              1        0/0         1       0/10          50           0
17 Tu12               1        0/0        87      71/2702      3134           0
18 Tu13               1        0/0       192      71/2702      3294           0
19
20 C3845ISR-A#show ip eigrp neighbors
21 IP-EIGRP neighbors for process 10
22 H   Address                 Interface       Hold Uptime   SRTT   RTO  Q   Seq
23                                             (sec)         (ms)       Cnt  Num
24 2   13.1.1.2                Tu13            11 00:10:02   192   5000  0   49
25 1   12.1.1.2                Tu12            12 00:12:11    87   5000  0   73
26 0   10.1.1.100              Fa0/1           11 03:24:54     1    200  0   43
27
28 C3845ISR-A#show ip route eigrp 10 | include Tunnel
29 D       10.1.2.0 [90/297270016] via 13.1.1.2, 00:11:04, Tunnel13
30                  [90/297270016] via 12.1.1.2, 00:11:04, Tunnel12
31 D       192.168.2.2 [90/297398016] via 13.1.1.2, 00:11:04, Tunnel13
32                     [90/297398016] via 12.1.1.2, 00:11:04, Tunnel12
33 D       192.168.2.3 [90/297398016] via 13.1.1.2, 00:11:04, Tunnel13
34                     [90/297398016] via 12.1.1.2, 00:11:04, Tunnel12
35 D       192.168.2.1 [90/297398016] via 13.1.1.2, 00:11:04, Tunnel13
36                     [90/297398016] via 12.1.1.2, 00:11:04, Tunnel12
37 D       192.168.2.4 [90/297398016] via 13.1.1.2, 00:11:04, Tunnel13
38                     [90/297398016] via 12.1.1.2, 00:11:04, Tunnel12
39 D       192.168.2.5 [90/297398016] via 13.1.1.2, 00:11:04, Tunnel13
40                     [90/297398016] via 12.1.1.2, 00:11:04, Tunnel12


Dynamic Multipoint Virtual Private Networks

At this point, we've covered basic IP routing continuity options over IPsec VPN tunnels in the context of Geographic HA, each of which presents its own unique design challenges. In large-scale IPsec+GRE designs, two such unique design challenges include management and configuration on IPsec+GRE hub/aggregation routers and peer scalability in the hub/aggregation router SADB. DMVPN addresses these concerns, among others, by greatly decreasing the configuration and management effort on the IPsec+GRE hub/aggregation routers using mGRE with Next Hop Resolution Protocol (NHRP) and enabling spoke routers to dynamically build SAs directly to their desired spoke routers. In this section, we will review all of the required components of DMVPN and reinforce these components with an enterprise DMVPN deployment case study.

DMVPN Solution Design Drivers

DMVPN designs enable administrators to address several key design considerations with large-scale IPsec+GRE deployments. Our discussions in this section focus on two of these critical design considerations in large-scale IPsec+GRE designs found in many of today's enterprise-class networks:

  • Configuration Complexity and Size: Recall from our discussion of traditional IPsec+GRE designs earlier in this chapter that, each time a branch is added to the network, a GRE tunnel interface is added on the branch IPsec VPN gateway with its own unique point-to-point GRE tunnel interface on the central hub IPsec VPN gateway in order to complete the IPsec+GRE configuration. The creation of unique GRE tunnel interfaces on the hub IPsec VPN gateway for each branch causes configuration complexity and management as the number of branches increases. For example, a large enterprise-class network with 1000 IPsec+GRE enabled branches requires 1000 GRE tunnel interfaces to be configured on the hub IPsec VPN gateway. As we'll discuss later in this section, a DMVPN design can decrease the 1000 IPsec+GRE interfaces described above to a single mGRE interface. DMVPN does this not by altering the standards-based IPsec protocol itself, but instead by changing the configuration requirements of traditional point-to-point IPsec+GRE networks, yielding a more streamlined and manageable configuration and management requirements of the overall design.

  • GRE and IPsec Scalability and Management: In a standard, traditional IPsec+GRE design, each spoke creates a Phase 1 and 2 SA to the hub. Additionally, the required point-to-point GRE tunnel from the hub to the branch consumes an IDB entry on the hub and branch. For example, in an enterprise network with 1000 branches, 2000 SAs would exist in the hub IPsec VPN gateway's SADB, and 1000 IDB entries would exist to support the GRE tunnel termination. While DMVPN does not alter this SA requirement on the hub (a permanent hub-spoke SA is also created in DMVPN), DMVPN alters this behavior such that interface description block (IDB) entries are not statically created and consumed. Instead, they are created only when they are needed and only on the appropriate peers. Considering the 1000-branch example with DMVPN enabled, the GRE IDB requirement decreases from 1000 to potentially as little as 1 IDB required on the hub.

Note

Even in DMVPN networks, having 1 GRE IDB entries is rare to the point of being infeasible. This implies 100 percent spoke-to-spoke traffic. Any time a spoke requires IPsec-secured connectivity to the hub, regardless of whether or not DMVPN is configured, 2 IPsec SAs and 1 IDB entry will be created on the hub. The example described previously is used to reinforce that, with DMVPN, IPsec SAs and GRE IDBs are created only as needed.

In addition to improved SA and IDB management, DMVPN decreases unnecessary decrypt/reencrypt behavior on the hub IPsec VPN gateway for spoke-to-spoke communications. In traditional IPsec+GRE hub and spoke deployments, a branch must encrypt traffic to the hub, where it is decrypted and then reencrypted before sending to the destination branch in a spoke-to-spoke scenario. We will explore in our step-by-step discussions how DMVPN can be used to eliminate this by enabling the spokes in the previous example to directly negotiate Phase 1 and 2 SAs with each other, as opposed to both spokes negotiating Phase 1 and 2 SAs with the hub. In doing this, DMVPN changes the behavior of the spoke-to-spoke communication example described above to a direct spoke-to-spoke IPsec VPN tunneling model, including one encrypt action on the source IPsec spoke and one decrypt action on the destination IPsec spoke with no encryption or decryption occurring on the hub at all. DMVPN therefore presents an opportunity to dramatically decrease the processing load on the hub router in networks with heavy spoke-to-spoke IPsec VPN traffic.

DMVPN Component-Level Overview and System Operation

At this point, we've covered several key design drivers for DMVPN in IPsec+GRE environments, including DMVPN's ability to ease configuration and management burden on administrators, increase IPsec scalability through better management of the IPsec SADB and GRE IDB entries, and increase IPsec scalability by eliminating processing load on the hub IPsec VPN gateway attributable to spoke-to-spoke communications. In this section, we will discuss the step-by-step process involved in hub-to-spoke and spoke-to-spoke communication examples in a DMVPN network. However, before we dive in to the step-by-step operation of DMVPN in these scenarios, it is important to understand the required components of the overall DMVPN architecture:

  • Multipoint GRE (mGRE): DMVPN requires a multipoint GRE tunnel configured on the hub IPsec VPN gateway and on its spokes. The mGRE tunnel is used to exchange routing protocols between the private IP networks at the mGRE tunnel endpoints. NHRP messages are also exchanged over the mGRE tunnel between the hub and its spokes when spoke IPsec VPN gateways attempt to create direct dynamic spoke-to-spoke IPsec VPN tunnels.

  • Next Hop Resolution Protocol (NHRP): When two private IP networks behind two spoke IPsec VPN gateways want to communicate with one another, the initiating IPsec VPN gateway uses NHRP to determine which peer it should negotiate Phase 1 and 2 IPsec SAs with. The initiating IPsec VPN gateway accomplishes this by leveraging NHRP to query the Next Hop Server (NHS) configured at the hub for the destination spoke's physical IP address. This IP address is subsequently used when building the IPsec VPN tunnel that secures the traffic exchange between private networks across the mGRE tunnel.

  • IPsec and ISAKMP: As with standard IPsec+GRE deployments, DMVPN uses IPsec and ISAKMP for data authentication, integrity, confidentiality, and nonrepudiation. Although DMVPN does not change IPsec or ISAKMP protocols themselves, DMVPN does greatly simplify the configuration of IPsec and ISAKMP respective to traditional IPsec+GRE configuration requirements.

The components described above work in concert to deliver the overall DMVPN solution. Figure 7-5 illustrates an enterprise hub-and-spoke DMVPN design in which several spokes communicate in both a spoke-to-spoke and spoke-to-hub fashion.

Figure 7-5. Enterprise DMVPN Topology

[View full size image]

In the DMVPN topology, C3845ISR-A and B communicate to the hub securely using IPsec+GRE, without any dynamic next-hop discovery behavior with NHRP. In other words, in this topology, or any DMVPN topology, IPsec+GRE tunnels are created from hub-to-spoke once tunnel protection is enabled on the hub and spoke tunnel interfaces. The dynamic behavior of the DMVPN implementation of Figure 7-5 is introduced only when C3845ISR-A and B communicate with one another directly. In this case, NHRP is used to dynamically determine the peering information necessary to build a direct IPsec tunnel between the two spokes, effectively bypassing any crypto requirements on the hub for that specific spoke-to-spoke tunnel. The following list illustrates the sequence of events corresponding to dynamic spoke-to-spoke SA establishment between two endpoints illustrated in Figure 7-5:

1. | Host-A on Network A initiates a TCP session to Server-B on Network-B. C3845ISR-A looks up the route to Server-B and determines that the next hop is 192.168.2.1 and that the GRE interface (tunnel 0) is the egress interface, which is in the crypto switching path. Note In a DMVPN environment, all traffic learned over mGRE tunnel is expected to be included in the crypto switching path. As such, there is no concept of crypto ACLs in a DMVPN design.
2. | C3845ISR-A does not have an entry in its NHRP mapping table for the next hop of 192.168.2.1, so it queries the NHRP next-hop server (192.168.0.1). All of the spokes using the NHS 192.168.0.1 have a manually defined NHS definition mapped to the C7304's loopback interface, (200.1.0.1).
3. | The NHS on C7304 returns C3845ISR-B's physical interface IP (200.1.2.1) as the next-hop IP mapping to the next-hop IP of 192.168.2.1 in the forwarding decision by C3845ISR-A in #1.
4. | C3845ISR-A uses the C3845ISR-B's physical interface IP returned in #3 as the IPsec peer for Phase 2 SA negotiation. C3845ISR-A uses this information to build IPsec SAs with C3845ISR-B.
5. | Server-B forwards return traffic to Host-A. Similar to C3845ISR-A in #1, C3845ISR-B does not have the appropriate next-hop entry.
6. | C3845ISR-B queries the NHRP next-hop server (192.168.0.1) on C7304 for the next-hop IP.
7. | The NHRP entry is returned by the NHS on C7304 (192.168.1.1 -> 200.1.1.1). The NHRP mapping entry is used by C3845ISR-B to forward traffic C3845ISR-A over the IPsec+GRE tunnel established in #4.
8. | Networks A and B run a separate instantiation of EIGRP (192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24 = EIGRP 10) from the physical networks used to build the IPsec tunnel in #4 (200.1.0.0/24, 200.1.1.0/24, 200.1.2.0/24 = EIGRP 1). Multicast RP updates for EIGRP 10 can now be exchanged between C3845ISR-A and B across the IPsec+GRE tunnel built in #4. Traffic can now flow bidirectionally over the IPsec+GRE tunnel between Networks A and B behind C3845ISR-A and B, respectively.
9. | Host-A forwards traffic to Server-B over the IPsec+GRE tunnels established between C3845ISR-A and B using DMVPN. The VPN Gateway, C3845ISR-A, performs GRE encapsulation on the data before encrypting it. C3845ISR-B performs decryption on the traffic before GRE decapsulating it and eventually forwarding on to Server_B.
10. | Server-B forwards return traffic to Host-A over the IPsec+GRE tunnels established between C3845ISR-A and B using DMVPN. The VPN Gateway, C3845ISR-B, performs GRE encapsulation on the returned data before encrypting it. C3845ISR-A performs decryption on the return traffic before GRE decapsulating it and eventually forwarding on to Host-A.

Note

When the NHRP entry timeout intervals expire, the NHRP entries learned in #3 and #7 will be removed from the NHRP mapping tables on C3845ISR-A and B, respectively. This causes IPsec to tear down the VPN tunnel built between C3845ISR-A and B in #4.

The process described above illustrates several benefits of DMVPN from administrative, management, and scalability perspectives. The configurations for C7304, C3845ISR-A, C3845-ISR-B can be referenced in Examples 7-12 and 7-13 to further reinforce the illustration of these benefits. Before reviewing the required configurations for the DMVPN implementation topology of Figure 7-5, let's quickly review the DMVPN benefits against the step-by-step DMVPN operation on C3845ISR-A and B described above:

  • Zero-Touch Spoke Provisioning on the Hub (C7304): DMVPN configuration requires no maintenance on the hub (C7304) when adding spokes to the topology. In a traditional IPsec+GRE environment, a GRE tunnel interface must be added on the hub corresponding to that branch. DMVPN eliminates this requirement by using a single mGRE tunnel interface on the hub instead of a 1:1 branch-to-hub GRE interface configuration. The required hub configuration for C7304 in Figure 7-4 is provided in example 7-10.

  • Elimination of Decrypt/Reencrypt Behavior on Hub (C7304): DMVPN eliminates unnecessary decrypt/re-encrypt action on the hub. Note that, in step 4 previously, the IPsec VPN tunnel is terminated on C3845ISR-A and B. In a traditional IPsec+GRE environment, C3845ISR-A and B would terminate their IPsec+GRE tunnels on the hub, therefore requiring C7304 to decrypt/GRE decapsulate the inbound traffic from C3845ISR-A and GRE-re-encapsulate/encrypt it before forwarding it to C3845ISR-B.

  • Uniform IPsec Spoke (C3845ISR-A and B) Provisioning: DMVPN eliminates node-specific configuration elements on C3845ISR-A and B. DMVPN accomplishes this by enabling the peer to dynamically learn peering information via NHRP from the NHS configured on the hub (C7304), as illustrated in steps 2, 3, and 5 previously. This enables administrators to push a generic, uniform, IPsec configuration to each spoke (C3845ISR-A and B). The common IPsec configuration for spoke IPsec VPN gateways C3845ISR-A and B is illustrated in Example 7-11.

As with traditional IPsec+GRE, the ISAKMP must be configured to establish the Phase 1 SAs that DMVPN will use to build Phase 2 SAs. Unlike the configurations used earlier in this chapter, this design uses RSA-sigs (the IOS default) to authenticate the IKE SA. The crypto transform used in this example is 3DES with MD5 HMAC authentication on the ciphered blocks. A crypto profile is used to bind the transform set described above to the tunnel interface used for DMVPN (Example 7-9, lines 11-12). Unlike traditional IPsec and IPsec+GRE designs, there is no need for a crypto map or crypto ACL in a DMVPN design. The IPsec transform set is applied to the interface by referencing the IPsec profile configured earlier. This effectively turns on ISAKMP on physical interface protecting the tunnel and also includes all GRE traffic sent out of this interface to be included in the crypto switching path. As such, there is no concept of a crypto ACL for defining crypto-protected traffic flows in a DMVPN. Instead, all traffic forwarded out of the GRE interface with tunnel protection enabled will be encrypted using the appropriate crypto transform.

NHRP is used to dynamically learn next-hop addresses for spoke-to-spoke GRE tunnel terminations. NHRP Authentication is performed in cleartext, as shown in Example 7-10, line 18. Additional authentication is provided at the GRE layer using a tunnel key, as shown in Example 7-10, line 25. The NHRP network ID shown in Example 7-10, line 20, must be consistent between all of the spokes and the hub in the same DMVPN deployment that uses the same mGRE tunnel interface on the hub. All of the spokes with this network ID will use this hub router as the NHRP NHS.

Tip

The GRE tunnel maximum transmission unit (MTU) can be adjusted to avoid fragmentation issues that could lead to performance issues if reassembly is required prior to decryption at the opposite end of the tunnel. Example 7-10, line 14, illustrates how this can be done on a DMVPN hub router. For more information on proper handling of IP fragmentation in IPsec VPNs, please refer to Chapter 4.

The IP address of the tunnel interface is injected in to EIGRP 10. The routing protocol configuration in this design is configured in the same fashion as traditional IPsec+GRE: EIGRP 10 is used as the routing protocol for the tunnel interfaces and the private networks communicating over the IPsec+GRE DMVPN tunnels, while OSPF is used as the routing protocol for DMVPN IPsec and GRE tunnel establishment. Disabling split horizon for EIGRP AS 10 allows RP updates to be exchanged from spoke to spoke. Updates flow in to the mGRE tunnel interface on the hub and are then transmitted out of the hub to the destination spoke. EIGRP split horizon prevents this behavior, and is on by default, so it must be explicitly disabled when using EIGRP to route between private networks over the DMVPN IPsec+GRE infrastructure.

Example 7-10. DMVPN Hub Configuration for C7304 (Figure 7-5)

1  crypto ca trustpoint IOS_CA1
2   enrollment url http://200.1.2.100
3  !
4  crypto isakmp policy 10
5   hash md5
6   group 2
7  crypto isakmp keepalive 10
8  !
9  crypto IPsec transform-set dmvpn7 esp-3des esp-md5-hmac
10 !
11 crypto IPsec profile chap7-dmvpn-profile
12  set transform-set dmvpn7
13 !
14 interface Tunnel0
15  ip address 192.168.0.1 255.255.255.0
16  no ip redirects
17  ip mtu 1416
18  ip nhrp authentication dmvpn7
19  ip nhrp map multicast dynamic
20  ip nhrp network-id 7
21  ip nhrp holdtime 360
22  no ip split-horizon eigrp 10
23  tunnel source FastEthernet0/0
24  tunnel mode gre multipoint
25  tunnel key 0
26  tunnel protection IPsec profile chap7-dmvpn-profile

In terms of encryption and routing processes, the configuration of the DMVPN spoke in Example 7-11 is similar to that of the DMVPN hub provided in Example 7-10. Unlike the hub (which is actually the NHS and is aware of all spoke addresses), the spoke dynamically learns next hop addresses for spoke-to-spoke GRE tunnel terminations via NHRP by querying the NHS. Like the hub, the spoke performs NHRP Authentication in cleartext, and additional authentication is provided at the GRE layer using a tunnel key. The NHRP network ID shown must match the hub in order for the spoke to effectively use the hub as the NHS for resolving next-hop queries. A static NHRP map (Example 7-11, line 18) is required on the spoke to allow queries to the NHS (192.168.0.1) to be mapped to the physical interface of the NHS itself (200.1.1.1). The spoke is then configured to use this static map to query for the unknown next-hop IP addresses using NHRP. Although the NHS is defined as a tunnel interface, it is manually mapped to a physical interface, as shown previously in this example. The NHS responds to NHRP next-hop queries that are subsequently used by DMVPN for dynamic spoke-to-spoke IPsec VPN tunnel establishment.

Example 7-11. DMVPN Spoke Configuration for C3845ISR-A and B (Figure 7-5)

1  crypto ca trustpoint IOS_CA1
2   enrollment url http://200.1.2.100
3  !
4  crypto isakmp policy 10
5   hash md5
6   group 2
7  crypto isakmp keepalive 10
8  !
9  crypto IPsec transform-set dmvpn7 esp-3des esp-md5-hmac
10 !
11 crypto IPsec profile chap7-dmvpn-profile
12  set transform-set dmvpn7
13 !
14 interface Tunnel0
15  ip address 192.168.0.3 255.255.255.0
16  ip mtu 1416
17  ip nhrp authentication dmvpn7
18  ip nhrp map 192.168.0.1 200.1.1.1
19  ip nhrp network-id 7
20  ip nhrp holdtime 600
21  ip nhrp nhs 192.168.0.1
22  tunnel source Ethernet0/0
23  tunnel destination 200.1.1.1
24  tunnel key 0
25  tunnel protection IPsec profile chap7-dmvpn-profile


Summary

Geographic HA design considerations must be addressed to fully extend the Local HA concepts discussed in Chapter 6 to present a full IPsec HA solution. Regardless of how highly available an IPsec VPN's tunnel termination point is designed to be, the availability of the IPsec VPN can still be dramatically affected if the appropriate Geographic HA design considerations are not accounted for. In this chapter, we've reviewed several sound design alternatives for providing Geographic HA, including:

  • Reverse Route Injection with Multiple IPsec Peers

  • IPsec+GRE Tunnels with Multiple Crypto Map Process IDs

  • Dynamic Multipoint Virtual Private Networks

Although all of these Geographic HA options are sound in certain design scenarios, the most paramount design driver that a network architect should address in the context of Geographic HA is the need to include IP multicast traffic in the crypto switching path. If it is deemed necessary that IP multicast forwarding must be enabled in the crypto switching path, the design alternatives available for geographic HA are quickly focused on IPsec+GRE alternatives. While RRI is still usable with GRE, it becomes substantially less desirable as dynamic multicast RP updates (e.g., RIP, EIGRP, OSPF, and so on) can be exchanged across the GRE tunnel, effectively precluding the need for RRI.

Network architects should be wary that GRE encapsulation required in IPsec+GRE tunnels does affect the forwarding path on the IPsec VPN gateway. If the GRE encap/decap operation is not done in the fast path on the VPN platforms in your design, the GRE encap/decap could introduce a bottleneck in the IPsec+GRE switching path, potentially diminishing the value of hardware crypto accelerators that might be available on the IPsec VPN platform. If IP multicast forwarding is not required in the crypto switching path, RRI could be used as an alternative to IPsec+GRE in this scenario, eliminating the need for GRE encap/decap and enabling network architects to take full advantage of the crypto hardware accelerators on their IPsec VPN gateways. The key takeaway to consider when choosing IPsec+GRE (including DMVPN) or RRI is careful evaluation of the need for IP multicast forwarding, and careful consideration of RRI-based geographic HA when IP multicast is not required in the crypto switching path.

DMVPN is a form of IPsec+GRE that dramatically decreased the complexity of configuration and management in large-scale IPsec+GRE designs. Additionally, DMVPN can be configured such that spokes can be provisioned without any additional configuration on the hub. This is a very attractive feature of DMVPN, as it eliminates the possibility of misconfiguration on the hub IPsec router during the addition of new spokes that would damage communications of those IPsec spokes already included in the DMVPN. Additionally, as DMVPN does not require crypto map configuration (including crypto ACL and peer configuration), DMVPN spoke configuration can be deployed uniformly across different spokes, as shown in our DMVPN configuration examples relevant to the design topology of Figure 7-5.


Chapter 8. Handling Vendor Interoperability with High Availability

IPSec is a standards-based protocol, and as such, the Internet Engineering Task Force (IETF) and other standards bodies have provided substantial requirements to meet the standards defined in the IETF's IPSec-related RFCs. However, there are no requirements currently defined by the IETF that specifically address IPSec High Availability (HA) requirements. This chapter examines several key components of IPSec virtual private network (VPN) design that make up a highly available design in a multi-vendor deployment. Within the context of these topics, this chapter discusses several barriers to HA design that vendor HA interoperability presents. The chapter then covers several options within IPSec itself that can be used as design alternatives to deliver a certain degree of HA in a vendor-diverse environment.


Vendor Interoperability Impact on Peer Availability

In an IPSec HA environment, it is not only critical to determine the availability of both IPSec VPN tunnel endpoints, but also to quickly determine when a tunnel endpoint has become unavailable. Design issues discussed within this context all pertain to IPSec peer availabilitythe ability to determine the availability of a remote peer and to rapidly detect the change in a remote peer's availability. This chapter discusses several vendor interoperability path availability limitations that preclude HA and must therefore be addressed in an IPSec HA environment, including the inability to specify multiple peers and the lack of peer-availability mechanisms.

The Inability to Specify Multiple Peers

Figure 8-1 shows a network in which a remote branch office connects across an ISP to its campus internet edge, where there exist two VPN headend routers that are aggregating the termination of IPSec VPN tunnels from all remote branches. In this configuration, the enterprise has invested in out-of-chassis HA at their IPSec aggregation points. The solution does not use virtual interfaces (Hot Standby Router Protocol/Virtual Router Redundancy Protocol [HSRP/VRRP]) but instead relies on the ability of the branch to failover to the redundant aggregation point when the primary aggregation point becomes unavailable.

Figure 8-1. Vendor Interoperability and Peer Availability: Inability to specify multiple peers

[View full size image]

In this scenario, the remote VPN gateway does not have the ability to define multiple IPSec peers, Reverse Route Injection (RRI), or IPSec+GRE. Instead, the branch encryptor, IPSec-GW-A1, relies on manually defined static routes to preserve continuity between the two routed domains at Sites A and B across the IPSec VPN tunnel. Therefore, the expected behavior is as follows (as numbered in Figure 8-1):

1. | IPSec-GW-A1 is configured to negotiate an IPSec VPN tunnel with C7206VXR-A1 with the IP address of 200.1.1.1. IPSec-GW-A and C7206VXR-A1 successfully negotiate Phase 1 and 2 SAs with each other to establish the IPSec VPN tunnel.
2. | A failure on the serial link between C2800ISR-A1 and C7206VXR-A1 occurs, forcing traffic across the redundant serial link between C2800ISR-A1 and C7206VXR-B1.
3. | IPSec-GW-A1 does not support the definition of multiple IPSec peers and is therefore incapable of negotiating a Phase 2 Security Assotiation with C7206VXR-B1.
4. | Because the traffic flows to be included in the crypto switching path on IPSec-GW-A1 remain consistent before and after the failure of the serial link between C7206VXR-A1 and C2800ISR-A1, IPSec-GW-A1 will continually try and fail to encrypt traffic using the IPSec SA with C7206VXR-A1, which is now unavailable.
5. | IPSec-GW-A1's Phase 2 negotiations continually fail, causing all traffic flows in the crypto switching path to be discarded.

It is important to consider that in number 5, above, the results depend heavily on the capabilities of IPSec-GW-A1. For example, if IPSec-GW-A1 has the ability to distinguish between ciphertext and cleartext traffic flows (as is the case with crypto ACLs), then IPSec+GRE could be used to differentiate the traffic flows (flows would be based on source and destination GRE tunnel endpoints) by encapsulating them in GRE before the traffic were to reach IPSec-GW-A1 for crypto processing. Because IPSec-GW-A1 is still incapable of negotiating an IPSec SA with a redundant peer, the redundant path cannot be leveraged for ciphertext communications. However, the redundant path could still be used for cleartext data transfer, since IPSec-GW-A1's crypto ACL equivalent would be configured to bypass crypto operations for the redundant GRE tunnel traffic. Although this method may be unacceptably insecure in failover scenarios, it does provide a cleartext alternative in emergency situations.

Another solution to this problem is to somehow combine the two peering endpoints on C7206VXR-A1 and C7206VXR-B1 into a single yet redundant point of termination for remote IPSec endpoints. This would provide an HA solution for the vendor-diverse environment discussed above that is independent of the operation of IPSec-GW-A1 in Step 5. Recall that in Chapter 6, "Solutions for Local Site-to-Site High Availability,"we discussed the option of using HSRP or VRRP to create a virtual interface for tunnel termination point redundancy. In this scenario, HSRP or VRRP could be deployed between C7206VXR-A1 and C7206VXR-B1 to provide the same out-of-chassis HA benefits while presenting a single tunnel termination point for the branches.

Note

For the purposes of this chapter, the problem is presented only in the context of multiple tunnel termination points to illustrate issues with IPSec HA interoperability. For more information on stateful and stateless IPSec HA designs using HSRP and VRRP, please refer to Chapter 6, "Solutions for Local Site-to-Site High Availability."

Although there are multiple widely deployed solutions, such as stateful and stateless HA using virtual interfaces, there are other alternatives for handling vendor interoperability within HA, such as QM Delete Notify, relying on IPSec and IKE SA lifetimes, and Invalid SPI recovery.

Although these solutions may not provide the same degree of HA as the HA solutions discussed in Chapters 5, 6, 7, and 8 (for example, stateful HA with Stateful Switchover [SSO], as discussed in Chapter 6), we will discuss these designs later in this chapter as alternative design options where best practices may not be possible.

Lack of Peer Availability Mechanisms

An IPSec HA deployment relies on the rapid detection of a failure along the primary path and the ability to quickly re-establish communications across the redundant path, a concept referred to as IPSec reconvergence. Without a mechanism to detect whether or not a failure has occurred somewhere along the path of the primary IPSec VPN tunnel that has eliminated the availability of one of the IPSec peers actively used as an IPSec tunnel termination point, the ability of the IPSec VPN tunnel to reconverge along the redundant path is greatly impacted.

Note

Cisco VPN concentrators, clients, and couters supporting IPSec provide for several mechanisms for managing peer availability, including IKE keepalives and Dead Peer Detection (DPD). For a more detailed discussion of IKE keepalives and DPD, please refer to Chapter 5, "Designing for High Availability."

Figure 8-2 illustrates a network in which there is a remote IPSec VPN gateway that is dually homed to a pair of IPSec VPN headend devices at the enterprise's headquarters.

Figure 8-2. Lack of Peer Availability Mechanisms and the Impact on IPSec VPN Reconvergence

[View full size image]

The remote VPN gateway, IPSec-GW-A2, supports the use of multiple peers but does not support any peer availability mechanisms outside of those required by the RFC. For example, IPSec-GWA2 does not support IKE keepalives or DPD, but as per RFC 2401, IPSec-GW-A2 does associate lifetimes with Phase 1 and 2 SAs. The following revisits the failover scenario in Figure 8-2 and describes the expected step-by-step outcome:

IPSec-GW-A2 successfully negotiates an IPSec VPN Tunnel (Phase 1 and 2 SAs) with C7206VXR-A2 (200.1.1.1).

1. | The serial interface between C2800ISR-A2 and C7206VXR-A2 fails, forcing traffic that was in the crypto path to use the redundant tunnel termination point on C7206VXR-B2 (200.1.1.5).
2. | IPSec-GW-A2 does not have a mechanism for determining that the availability of the peer used to populate the Phase 2 SA in its Security Assotiation Database (SADB) (200.1.1.1) is now unavailable. IPSec-GW-A2 therefore waits for the lifetime of the Phase 2 SA in its SADB to expire.
3. | Upon expiration of the existing Phase 2 SA lifetime in IPSec-GW-A2's SADB, IPSec-GWA2 then tries to renegotiate Phase 1 and 2 SAs with 200.1.1.1, which is still unavailable. IPSec-GW-A2 initiates Phase 1 and 2 SA negotiations with the redundant peer, C7206VXRB2 (200.1.1.5), after failing to negotiate SAs with C7206VXR-A2.

The impact on HA in this situation is realized in step 3. Although the system eventually reconverges after the lifetime of the Phase 2 SA (3600 seconds by default) expires, application data is being dropped while the stale SA remains in the SADB. The presence of the stale SA in IPSec-GW-A2 effectively inserts an unacceptably large delay in the overall reconvergence of the IPSec VPN onto the redundant path.

If there were peer availability mechanisms present to speed the detection of the stale SA left over from the failure situation described in Figure 8-2, then the overall reconvergence process of the IPSec VPN would be greatly expedited. For more information on the operation IPSec with IKE Keepalives and Dead Peer Detection, please refer to Chapter 5, "Designing for High Availability."

We've discussed two popular options for expediting the detection of stale SAs in HA environments, IKE keepalives and DPD, and presented the design alternatives accordingly in Chapters 5 and 6. It is therefore important to integrate these options into the design of the IPSec VPN where possible. However, there may be situations where this is not possible, such as the scenario presented in Figure 8-2. Later in this chapter, we will discuss several design alternatives for handling this design consideration when peer availability mechanisms are not supported on the selected IPSec VPN gateways in the system design.


Vendor Interoperability Impact on Path Availability

It is critical in an IPSec HA design that the IPSec VPN gateways and intermediate routers between the two gateways are capable of supporting and managing the availability of the path which the IPSec VPN tunnel traverses. Recall from our discussion of IPSec HA design in Chapter 5 that this is a critical component of path availability: the ability to ensure the availability of the path between two encrypted domains. In Chapter 7, "Solutions for Geographic Site-to-Site High Availability," we explored several mechanisms for addressing path availability design considerations within the context of IPSec HA. This section introduces several barriers that IPSec vendor interoperability presents to these design solutions and discusses some additional design alternatives that may be better suited to the vendor-diverse environment in which these limitations exist:

1. | Limited support for selected routing protocols
2. | Lack of support for reverse route injection
3. | Lack of support for GRE tunnels

IPSec HA Design Considerations for Platforms with Limited Routing Protocol Support

As a Layer 3 VPN technology, IPSec relies on underlying Layer 3 information to establish and maintain the IPSec VPN tunnel. Although IPSec tunnels can be established on point-to-point links, such as a serial link between a branch router and a headend router used for IPSec VPN tunnel aggregation, one key benefit of IPSec is that it can be used to provide data confidentiality between two endpoints which are multiple hops away.

One such common IPSec VPN topology that is used to encrypt communications between networks multiple hops apart from one another is that of an RAVPN deployment, in which IPSec VPN clients encrypt communication from remote network across an ISP to a VPN concentrator at the enterprise campus or internet edge De-Militarized Zone (DMZ). IPSec is also used to provide data confidentiality across routed environments in extranet deployments. In this section, we will explore the impact of limited RP support on site-to-site IPSec VPN extranet deployment, as depicted in Figure 8-3.

Figure 8-3. Lack of RP Support and the Impact on Site-to-Site IPSec VPN High-Availability

[View full size image]

Note

Common IPSec VPN deployments such as remote-acess VPN (RAVPN) and extranet deployments are presented in greater detail in Chapter 4, "Common IPsec VPN Issues." Additionally, RAVPN High Availability is discussed in detail, including configuration and design options, in Chapter 12, "Solutions for Handling Dynamically Addressed Peers."

Figure 8-3 shows a common deployment of IPSec VPNs in an extranet environment. In this scenario, the enterprise offers connectivity to its extranet partners over the internet. As such, all extranet communications between the enterprise and its extranet partners are spanned across multiple Layer 3 hops. This design requires that the extranet partner's IPSec gateways support adequate RP capabilities in order to establish and maintain the IPSec VPN tunnel.

Consider the scenario in which an extranet partner's IPSec VPN gateway does not support the appropriate RP capabilities required of this deployment. Because the IPSec VPN gateway is only capable of sending IP traffic, including all IPSec control plane traffic, to networks on the same directly connected segment, that IPSec VPN gateway is incapable of forwarding control plane traffic to the appropriate Layer 3 IPSec tunnel termination point.

Routing Protocol support on the extranet edge routers concentrating inbound IPSec tunnels from the extranet partners is also critically important. Without the additional Layer 3 awareness that routing protocols provide, the aggregation routers will not be able to forward IPSec and Internet Security Association and Key Management Protocol (ISAKMP) traffic to the appropriate destination extranet-partner IPSec gateways. Static routes, if supported on the gateway, provide some relief from this limitation. However, they do not address scalability and management issues that arise on the aggregation routers, since administrators must manually configure routes each time a partner residing on a different IP network is added to the extranet. Additionally, the manual configuration required when using static routes for this type of deployment reduces the usefulness of dynamic crypto maps, since the manual addition the static routing entries themselves add additional administration to the IPSec aggregation points (static routes and static IPSec peers can be added during the same configuration window).

In many situations, lack of RP support can be addressed by the addition of a static default route (if supported) pointing to an external router that can handle the additional required RP responsibilities. One such example in which this is common is when a PIX firewall is used to terminate IPSec VPN connections. Regardless of the workaround used to add the required Layer 3 capabilities, it is important that the Layer 3 infrastructure supporting the IPSec VPN tunnel is scalable, functional, and can quickly adapt to changes forcing reconvergence within the IPSec VPN tunnel itself.

IPSec HA Design Considerations for Lack of RRI Support

Reverse Route Injection (RRI) enables IPSec VPN gateways to dynamically inject VPN routes into their local protected routed domain upon the establishment of a Phase 2 SA. RRI therefore serves as an effective method for preserving dynamic routing information for unicast traffic across an IPSec VPN tunnel.

In Figure 8-4, there must be a means to exchange RP information between the two routed domains on the opposite ends of the IPSec VPN tunnel (routed domains A and C).

Figure 8-4. IPSec Vendor Interoperability and Lack of RRI Support.

[View full size image]

Recall from our previous discussions that there are several options for doing so, including:

1. | Injection of static routes or a single default route
2. | Cleartext exchange of routing protocols between A, B, and C
3. | Encrypted routing protocols using IPSec+GRE
4. | Reverse Route Injection

Figure 8-4 focuses on the last of these design options. Vendor interoperability and the impact of the lack of RRI support is illustrated when Host_A4 on segment A attempts to reach Server_B4 on segment C on the opposite end of the IPSec VPN tunnel. Because segment A's VPN gateways (IPSec-GW-A4 and IPSec-GW-B4) do not support RRI (and are not equipped nor configured for any other means of routing information propagation), all the routing tables on all other nodes within segment A will not contain any of the routes for segment B. Therefore, Host_A's communications to Server_B will fail at the first Layer 2/3 boundary it encounters within segment A.

RRI would solve this problem by dynamically creating a static route based on the protected address space populated in IPSec-GW-A4's SADB upon successful negotiation of a Phase 2 SA. These static routes can then be redistributed into segment A's RP to populate the routing tables of the remaining Layer 3 nodes within the segment.

Note

RRI is introduced in greater detail in Chapter 5, "Designing for High Availability." For more information on Local and Geographic HA design considerations, please refer to Chapters 6, "Solutions for Local Site-to-Site High Availability," and 7, "Solutions for Geographic Site-to-Site High Availability," respectively.

IPSec HA Design Considerations for Lack of Generic Routing Encapsulation (GRE) Support

IPSec+GRE provides a means to exchange encrypted multicast RP updates across an IPSec VPN tunnel, thereby serving as an effective path availability design alternative to RRI. Additionally, IPSec+GRE designs provide effective support for native multicast traffic flows themselves, while native RRI does not, thereby making IPSec+GRE the compelling design alternative where multicast traffic must be transmitted with data confidentiality in the crypto switching path.

For the purposes of our discussion here, we will consider an extreme case in which GRE encapsulation is not supported at all on a VPN gateway terminating an IPSec tunnel (shown in Figure 8-5).

Figure 8-5. IPSec Vendor Interoperability and Lack of GRE Support.

[View full size image]

Figure 8-5 illustrates a scenario in which multicast traffic, including RP updates, are exchanged between two extranet partners. Therefore, double-encapsulation (IPSec+GRE) is used to support the encrypted exchange of routing protocol updates and multicast application traffic between the two partners. The failure occurs on Extranet Partner B's IPSec VPN gateway, which is capable of handling ESP encapsulation and decapsulation but is unable to handle the GRE encapsulation and decapsulation.

There are varying degrees of support for GRE on IPSec VPN gateways affecting the performance of the solution. Therefore, it is important to understand the impact of all of the data permutations to be included in the switching path when selecting an IPSec gateway.

Tip

GRE offload scenarios are a relatively common design alternative for IPSec+GRE deployments in which there is inadequate GRE performance or support capabilities on the IPSec VPN gateway itself. For more information on IPSec+GRE with GRE offload deployments, please refer to Chapter 10, "Further Architectural Options for IPsec."


Vendor Interoperability Design Considerations and Options

At this point, we have covered some of the most prevalent and effective means to address site-to-site and remote-access VPN High Availability. However, the design options presented in previous chapters may not be available in multi-vendor deployments, depending on the capabilities of the IPSec VPN gateways themselves. This section discusses some additional alternatives that can be used to increase the degree of availability of an IPSec VPN in vendor-diverse deployments.

Phase 1 and 2 SA Lifetime Expiry

The most rudimentary form of IPSec failover is driven by expiry of Phase 1 and 2 SA lifetimes from a stale SA left over after a failure in the primary IPSec VPN tunnel. This method entails the simple process of allowing the lifetimes of the previously negotiated SA lifetimes to expire after an IPSec VPN tunnel fails. After these SAs timeout, new SAs can be then negotiated to redundant peers.

SA lifetimes are required (per RFC 2401) for security reasons. Coincidentally, they are the only HA-related means addressed as a requirement in the RFC. Therefore, expiry of Phase 1 and 2 SA lifetimes are the only means of HA that administrators can count on, regardless of the capabilities implemented by a vendor's IPSec VPN gateway, so long as that vendor's implementation of IPSec is compliant with the RFC.

Unfortunately, relying on SA lifetimes to expire before establishing a new set of SAs to a redundant IPSec gateway is the slowest of all available HA processes. As such, many alternatives to this method have been developed to speed reconvergence of IPSec VPN tunnels in HA environments. We've explored many of these design options in detail in previous discussions of HA, including the following:

  • IKE keepalives and dead peer detection (Chapter 5)

  • VPN concentrator clustering and the VCA protocol (Chapters 5 and 9)

  • DNS-based VPN Concentrator HA (Chapters 5 and 9)

  • Stateless HA with IKE keepalives and DPD (Chapter 6)

  • Stateful HA with SSO (Chapter 6)

  • Redundant peers with IKE keepalives and DPD (Chapter 6 and 7)

  • Redundant physical interfaces with IKE keepalives and DPD (Chapter 6 and 7)

  • Highly available (loopback) interfaces (Chapter 6)

Unfortunately, because HA is largely unaddressed by standards bodies, not all of these design options are globally available across all vendor implementations of IPSec. Now we will explore some additional alternatives to expiration of SA lifetimes that address potential limitations introduced by vendor interoperability in platform and vendor-diverse IPSec HA designs.

SADB Management with Quick Mode Delete Notify Messages

Recall from our discussions in Chapter 3, "Basic IPsec VPN Topologies and Configurations," that the management of SAs in an IPSec VPN gateway's SADB are managed over a secure channel, called an IKE security association (or Phase 1 SA). This SA can be negotiated in one of two modesmain mode or aggressive mode. Once the Phase 1 SA has been negotiated, two Phase 2 SAs, called IPSec SAs, are negotiated (one in each direction) securely over the IKE SA.

Unlike Phase 1 SA negotiation, Phase 2 SAs can only be negotiated in one modequick mode. Because IKE manages the setup and teardown of IPSec SAs, there must be some means for IKE to communicate to IPSec that it must tear down its Phase 2 SAs. The IKE module in an IPSec VPN gateway accomplishes this by sending a quick mode DELETE_NOTIFY message to the IPSec module within the gateway.

Consider the case in which two gateways have negotiated an IPSec VPN tunnel successfully. The Phase 2 SA lifetime is the Cisco IOS default of 3600 seconds (1 day). Due to a failure somewhere within the IPSec VPN deployment, the VPN gateways have determined that the Phase 1 SA should be reaped from the SADB (via DPD or IKE keepalives). Phase 2 SAs, however, still remain in the IPSec SADB, and packets in the crypto path are dropped until these stale SAs are removed. If the gateways support quick mode DELETE_NOTIFY messages, the IKE module in each IPSec VPN gateway will send a DELETE_NOTIFY message to the IPSec module, instructing it to remove the Phase 2 (IPSec) SAs from its SADB. The result of this behavior is quicker teardown of stale IPSec SAs so that new, valid, Phase 1 and 2 SAs can be negotiated between the peers within the IPSec VPN tunnel.

Invalid Security Parameter Index Recovery

Invalid Security Parameter Index (SPI) Recovery allows for reduced IPSec recovery times when an IPSec peer resets or goes offline and then returns. Figure 8-6 shows a standard site-to-site IPSec VPN in which vendor-diverse IPSec VPN gateways are used to terminate the IPSec VPN tunnel.

Figure 8-6. Expediting IPSec VPN Tunnel Recovery with Invalid SPI Recovery

[View full size image]

Consider the scenario in which C2800ISR-A6 was to go offline and then return due to an interface failure, a system reset, or a power failure. When the C2800ISR-A6 goes offline, it loses its Phase 1 and 2 SA entries in its SADB. Because IPSec-GW-A6 does not support the use of IKE Keepalives and DPD, it has no ability to reap the SAs in its SADB before their lifetimes expire. In order to expedite the initiation of Phase 1 and 2 SA renegotiations between the two peers, C2800ISR-A6 must therefore have some means by which to detect that the SAs must be reaped at the opposite end so that new ones can be negotiated. Invalid SPI Recovery is used on C2800ISR-A6 to accomplish this task. The following sequence of events summarizes the events occurring after a system reset occurs on C2800ISR-A6 in the network illustrated in Figure 8-6:

1. | C2800ISR-A6 reloads due to a power failure, losing all current entries in its SADB in the process. Upon recovery and a crypto ACL match, C2800ISR-A6 attempts to build new IKE and IPSec SAs (with new SPIs) with IPSec-GW-B6.
2. | Phase 1 and 2 SA lifetimes have not expired on IPSec-GW-A6, so IPSec-GW-A6 continues to forward packets to C2800ISR-A6 using the previously negotiated (now stale) SAs with C2800ISR-A6 in its SADB.
3. | C2800ISR-A6 receives the encrypted traffic from IPSec-GW-A6 and finds no SPI in its SADB for the received traffic. C2800ISR-A6 thereby detects an invalid SPI from IPSec-GW-A6.
4. | C2800ISR-A6 forwards an INVALID_SPI_NOTIFY message to IPSec-GW-A6 over the Phase 1 SA established in Step 4.
5. | IPSec-GW-A6 receives the INVALID_SPI_NOTIFY message forwarded in Step 5 and reaps the corresponding SAs from its SADB.
6. | IPSec-GW-A6 receives traffic to be forwarded in the crypto path to C2800ISR-A6, triggering a new negotiation of Phase 1 and 2 SAs with C2800ISR-A6.

Vendor Interoperability with Stateful IPSec HA

As mentioned before, vendor-interoperability issues within HA can present themselves when an IPSec VPN gateway does not support the ability to use multiple, redundant, IPSec peers. One way to solve this is to use stateful IPSec HA on the opposite end of the IPSec VPN tunnel in order to make the two peering IP addresses look as if they were one single interface. As discussed previously in Chapter 6, "Solutions for Local Site-to-Site High Availability," this is achieved using a virtual interface with HSRP or VRRP and communicating IPSec state information between the redundant IPSec gateways participating in the HSRP or VRRP group using SSO and SCTP.

Figure 8-7 illustrates an extranet deployment in which extranet partners are given their choice of IPSec VPN gateways while still being offered a certain level of IPSec HA at the enterprise campus. This is done using stateful IPSec HA with HSRP and SSO.

Figure 8-7. Addressing Vendor Interoperability HA Issues with Stateful IPSec HA with HSRP and SSO.

[View full size image]

In this scenario, the two IPSec VPN gateways at the enterprise's internet edge DMZ present only one HSRP virtual interface instead of multiple physical or loopback interfaces for the extranet partners' IPSec VPN gateways to peer to. This eliminates the need for several key capabilities that would be required for HA peering to redundant interfaces:

  • Multiple Peering Statements Only one interface (the HSRP or VRRP virtual interface) is presented to the remote IPSec VPN gateway. Therefore, only one peering statement is required on the remote VPN gateway instead of two peering statements in the case of peering to multiple redundant physical or loopback interfaces.

  • IKE Keepalives or DPD The use of a virtual interface keeps peering information consistent during a failover scenario from the perspective of the remote IPSec VPN gateway. SSO communicates the SADB state in advance of the failure to the redundant IPSec VPN gateway, precluding the need for Phase 1 and 2 renegotiations with the redundant IPSec VPN gateway after failover.

Note

Detailed information on stateless and stateful IPSec HA can be found in Chapter 6. Likewise, detailed operational information on IKE keepalives and DPD can be found in Chapter 5, "Designing for High Availability."

The design benefits of stateful IPSec HA extend far beyond the added flexibility of IPSec VPN gateway selection at the opposite end of the VPN tunnel, including, among others, subsecond IPSec VPN failover convergence with HSRP. Alternatively, when cost is an issue, achieving HA with DPD and or IKE keepalives to multiple peers could be a more appropriate design option. As such, flexibility in IPSec VPN gateway selection should not drive HA strategy by itself. Instead, it is important to fully understand and consider all of the design benefits of each option presented in Chapters 5 through 7 when selecting a strategy for IPSec HA.


Summary

This chapter discusses several key components that compose a highly available IPSec VPN design in a multi-vendor deployment. It introduces the barriers to HA design that vendor HA interoperability presents. The chapter covers several options that exist within IPSec itself that can be used as design alternatives in delivering a certain degree of HA in a vendor-diverse environment.


Chapter 9. Solutions for Remote-Access VPN High Availability

As workforces become more virtualized and mobile, the growth in Remote-Access Virtual Private Network (RAVPN) deployments increases, which also drives the need for IPsec High Availability (HA) in RAVPN deployments. RAVPN deployments enable employees to securely access centralized corporate resources from any location with access to the Internet. Greater productivity and efficiency is therefore enabled for sales, marketing, consulting, and any other field employee in the enterprise's mobile workforce. In this chapter, we will expand on the Remote Access VPN design introduction provided in Chapter 3, "Basic IPsec VPN Topologies and Configurations," while examining several different approaches to building high-availability and load balancing in Remote Access VPN designs.

RAVPNs typically refer to topologies in which remote users establish a secure tunnel from a remote location using either a piece of client software on their laptop or a small hardware-based client at a home office or other small remote location. Although the secure tunneling requirement of an RAVPN can come in many different flavors such as L2TP and PPTP, our discussions in this chapter will be based on IPsec-based RAVPNs.

IPsec-based RAVPNs are composed of two key components: a VPN client and a VPN concentrator. To complete the RAVPN, the VPN client (whether software or hardware based) must negotiate an IPsec VPN tunnel over an IP transport (in the case of RAVPN, this IP transport is the Internet) to the VPN concentrator. In an IPsec RAVPN, the client-side network of the tunnel is typically very small, and in many cases is limited only to a single user's laptop. As such, there is little need for high-availability specific to the client in an RAVPN implementation.

Note

When there are significant resources on the client-side private network of the RAVPN, network architects should consider migrating the design of the remote network to a small branch site-to-site IPsec VPN deployment. For more on site-to-site IPsec VPN HA, refer to Chapter 6, "Solutions for Local Site-to-Site High Availability," and Chapter 7, "Solutions for Geographic Site-to-Site High Availability."

Unlike the client side of an RAVPN tunnel, the need for high-availability on the concentrator side becomes critical depending on the number of IPsec RAVPN clients the network must support. For organizations with large mobile workforces, often IPsec VPN clients are enabled on all corporate IT supported laptops, resulting in potentially thousands of tunnels to the corporate network at any given time. The VPN concentrator provides the tunnel termination point for these thousands of users, and, as such, must be deployed in a highly scalable and highly available fashion.

In this chapter, we will apply the Local and Geographic HA concepts discussed in Chapters 6 and 7 to RAVPN implementations as we explore highly resilient, scalable, and available IPsec VPN concentrator deployments targeted at supporting large numbers of IPsec VPN tunnels from clients:

  • VPN Termination with Virtual Router Redundancy Protocol (IOS or VPN3000 Concentrators)

  • VPN Termination with Hot Standby Routing Protocol (ASA5500 or IOS Concentrators only)

  • Clustering using VPN3000 Virtual Clustering Agents (ASA5500 Appliances and VPN3000 Concentrators only)

After exploring the design concepts to be evaluated for optimizing local HA in concentrator deployments, we will evaluate Geographic HA design options for optimizing availability of client access to the concentrator cluster:

  • DNS-based Session Load Balancing on Clustered Concentrators

  • Multiple Peer Definitions on the VPN Client Profile


IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination

IPsec RAVPN Concentrator HA can be achieved using a virtual interface protocol such as Hot Standby Router Protocol (HSRP) or Virtual Router Redundancy Protocol (VRRP). Using HSRP or VRRP, many VPN concentrators can be made to appear as a single IPsec peer to the IPsec clients. Should a VPN concentrator in the HSRP or VRRP peer group fail, the use of a virtual interface provides resiliency to the client, enabling the client to fail its IPsec session over to another concentrator participating in the HSRP or VRRP group. In this section, we will explore several tasks to consider when selecting virtual interfaces as the RAVPN design option for RAVPN HA.

IPsec RAVPN Concentrator High Availability Using VRRP

VRRP is a standards-based protocol enabling multiple interfaces on different IP routers (or in this case, RAVPN concentrators) to appear as a single virtual router interface. RFC 3768 defines VRRP as an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN.

Tip

For more information on VRRP and its many uses, please refer to the following sources of information:

http://www.ietf.org/rfc/rfc3768.txt

http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2284/products_tech_note09186a0080094490.shtml

In RAVPN environments, this VRRP LAN is typically a network segment attached to a firewall DMZ interface on the enterprise Internet edge. Multiple VPN concentrators will be attached to the DMZ LAN, each with their own unique physical interface IP in the VRRP group. These physical interfaces will all appear to the IPsec VPN clients as a VRRP virtual router interface. As such, the clients will need only one peer definition (the VRRP router interface) to take full advantage of the redundancy provided by having multiple concentrators in the enterprise Internet edge demilitarized zone (DMZ). Figure 9-1 illustrates an enterprise RAVPN deployment in which a cluster of three VPN concentrators is deployed in a dual-DMZ firewall design at the Internet edge.

Figure 9-1. Dual-DMZ VPN Concentrator Design with VRRP-Based HA

[View full size image]

The VPN3000 concentrator configuration for IPsec, Internet Security Association and Key Management Protocol (ISAKMP), and Group/User Management is illustrated in Figures 9-2 through 9-10.

Remote access VPN tunnels are typically authenticated with IKE X-Auth for per-user SA authentication granularity. Authentication using IKE X-Auth requires that a Phase 1 SA be temporarily authenticated pending successful authentication with Internet Key Exchange (IKE) X-Auth in "Phase 1.5." The IPsec group password is used to provide the temporary authentication of the Phase 1 SA. Configuration of the RAVPN group and password on the VPN3000 is illustrated in Figure 9-2.

Figure 9-2. VPN3000 IPsec Group and Password Configuration

[View full size image]

Figure 9-3 illustrates the following parameters that can be assigned to a given IPsec VPN client during IKE Mode config. In Figure 9-3, a VPN3000 concentrator is instructed to assign clients a DNS server of 200.1.1.17 and an IP address from the range of 192.168.0.0 to its clients. Also note that, in this configuration, SEP cards 1-4 are actively participating in the acceleration of IPsec on the concentrator for this group.

Figure 9-3. VPN3000 General Configuration (Client SEP Card, DHCP/Address Scope, and DNS Server Assignment)

[View full size image]

Figure 9-4 illustrates the IPsec configuration for this group, including the transform (Encapsulating Security Payload (ESP) 3DES with MD5 Hash-based Message Authentication Code (HMAC) Authentication) and the tunnel type (Remote Access).

Figure 9-4. VPN3000 Group IPsec and ISAKMP Configuration

[View full size image]

IKE mode config can be used to assign additional parameters, such as the IP subnet mask, client banner, split tunnel policy, and NAT-T policy. Figure 9-5 illustrates the configuration of these parameters for assignment to the client via IKE mode config.

Figure 9-5. VPN3000 Client Configuration (Banner, NAT-T Policy, Subnet Mask Assignment, IPsec Split Tunnel Policy)

[View full size image]

There are many different methods to assign a client an IP address, as illustrated in Figure 9-6. In this chapter, we will assign IPsec VPN clients an IP address from an address pool defined locally on the IPsec VPN concentrator using IKE mode config. Figure 9-6 illustrates the corresponding configuration on the VPN3000 concentrator.

Figure 9-6. Defining Address Assignment Methods on the VPN3000

[View full size image]

Figure 9-7 illustrates the configuration of the appropriate address pool corresponding to the defined address assignment method displayed in Figure 9-6.

Figure 9-7. Assigning Client Addresses from Defined IP Address Pool on the VPN3000 Concentrator

[View full size image]

As we had discussed previously in Figure 9-4, Phase 1 SA authentication can be done with peruser granularity when IKE x-Auth is used. Figure 9-4 provides us with the appropriate group and password configuration for IKE Phase 1 authentication, and Figure 9-8 provides us with an example of user and password credentials that will be validated with x-Auth in "Phase 1.5" negotiation. In this case, we are using the VPN3000 itself as the user database for x-Auth. However, the VPN3000 can also be configured to authenticate user credentials supplied via x-Auth using an external RADIUS database.

Figure 9-8. Creating VPN3000 Internal User Database Accounts for Authentication and Authorization with IKE X-Auth

[View full size image]

Figure 9-9 illustrates the configuration of general RAVPN user authentication and authorization parameters for a given user account on the VPN3000. In this case, any four of the available SEP modules are available for processing the termination of this user's IPsec VPN tunnel. IPsec is the only tunneling protocol configured for this client to use on this particular VPN concentrator.

Figure 9-9. VPN3000 Configuration for General RAVPN User Authentication and Authorization Policies with IKE X-Auth

[View full size image]

IPsec transform sets can be configured on a per-user basis. Figure 9-10 illustrates the appropriate IPsec transform configuration at the user level.

Figure 9-10. Defining Per-User Allowed IPsec Transform Polices with IKE X-Auth on VPN3000 Concentrators

[View full size image]

The VPN3000 concentrator must be configured with the appropriate routing protocol information in order for transparent IP connectivity to be maintained from IPsec RAVPN clients to enterprise resources located within the IPsec VPN concentrator's private network. The VPN3000 can support multiple means by which to achieve this:

  • Static Routing: Typically, a static default route is used to route IP traffic from the concentrator's private network through the public interface and across the IPsec VPN tunnels. More specific static routes are required to route traffic in the opposite direction, inbound from IPsec RAVPN clients to IP-enabled resources on the enterprise's private network.

  • OSPF: Instead of manually inserting more specific static routes pointing out of the concentrator's private interface, these routes can be learned dynamically via Open Shortest Path First (OSPF). A popular design option is use of a static default route pointing out of the concentrator's public interface with more specific IP subnets learned dynamically through OSPF on the concentrator's private interface.

  • RIP: Cisco VPN3000 concentrators support Routing Information Protocol (RIP) as well as OSPF. Instead of learning more specific routes via OSPF (or manually defining static ones), RIP can be used as an alternative routing protocol on the concentrator's public or private interfaces.

In this example, we will explore the design option of using a combination of static default routing to the public network, with more specific IP subnets learned via OSPF from the enterprise network on the VPN3000 concentrator's private interface. Samples of the required configuration can be found in Figures 9-11 through 9-14.

Figure 9-11. VPN3000 Static Default Routing

[View full size image]

The VPN3000 in this example uses OSPF to route traffic out of its private interface to the enterprise's corporate network. Figure 9-12 provides the appropriate routing configuration on the VPN3000, including OSPF area configuration and other area-level configuration parameters.

Figure 9-12. VPN3000 OSPF Routing Configuration

[View full size image]

Figure 9-13 provides the interface-level configuration of the VPN3000's private interface, including IP address, administrative state (up/down), speed, duplex, and maximum transmission unit (MTU).

Figure 9-13. VPN3000 Private Interface Configuration

[View full size image]

Figure 9-14 provides the interface-level configuration of the VPN3000's public interface, including IP address, administrative state (up/down), speed, duplex, and MTU.

Figure 9-14. VPN3000 Public Interface Configuration

[View full size image]

Note

Cisco VPN3000 concentrators and ASA5500 Series VPN appliances do not support HSRP. VRRP is the only virtual router protocol for first-hop redundancy supported by the VPN3000 series VPN concentrators. Routing platforms running Cisco IOS support HSRP-based RAVPN HA, as discussed later in this chapter.

In the RAVPN HA design of Figure 9-1, network architects have elected to use VRRP-based tunnel termination for high availability. Concentrators VPN3060-A, B, and C all have public interfaces on the outside DMZ that are configured in the same VRRP group. Initially, VPN3060-A is configured as the VRRP "Master" (it has the highest configured VRRP priority in the group). As the master, VPN3060-A is responsible for sending multicast keepalive polls to the other concentrators in the VRRP group using the link local multicast IP address of 224.0.0.18. If one or both of the other concentrators does not see a configurable amount of keepalives in their corresponding timed intervals, the remaining concentrators in the VRRP group will undergo an election to assume the role as the VRRP master router. This process allows for resiliency in the concentrator cluster design, as illustrated in the following failures scenario for VPN3060-A in Figure 9-1:

1. | VPN3060-A, B, and C are all configured for VRRP on the DMZ-Outside network segment. VPN3060-A is currently the VRRP master, assuming forwarding responsibility for RAVPN clients. A link failure on VPN3060-A's public interface causes the concentrator to become unavailable to inbound IPsec VPN sessions from the VPN clients.
2. | VPN3060-B and C are configured to wait three successive timed intervals to receive a VRRP router advertisement from the master router before attempting an election for VRRP master router. After missing a VRRP advertisement from VPN3060-A in the third timed interval, VPN3060-B and C attempt to elect a new VRRP master through the exchange of their own VRRP router advertisement messages. As VPN3060-B has the second highest priority next to VPN3060-A, it becomes the new VRRP master router.
3. | When VPN clients attempt to negotiate IPsec VPN tunnels with the Concentrator Cluster using the VRRP Virtual Router IP address, the VPN3060-B will now be responsible for terminating the inbound IPsec VPN tunnels. Note The VPN clients in this example are configured with only one IPsec peer corresponding to the VRRP Virtual Router IP address for the IPsec VPN concentrators in that VRRP group. As such, the clients are unaware of any changes that occur in the concentrator cluster due to the failure described abovethey will always use the same IP address for their IPsec peer regardless of which VPN concentrator is the master for the VRRP group.
4. | VPN3060-A is configured to preempt the other concentrators when it recovers from a failure. This means that it will proactively attempt to reassume the role of VRRP master for the VRRP group after it recovers from a failure. VPN3060-A recovers from the failure in step 1, sending out a VRRP router advertisement message causing a new reelection to occur. VPN3060 has the highest priority in the group, thereby reassuming the role of VRRP master for the VRRP group.
5. | When VPN clients attempt to negotiate IPsec VPN tunnels with the Concentrator Cluster using the VRRP Virtual Router IP address, the VPN3060-A will now be responsible for terminating the inbound IPsec VPN tunnels.

Figure 9-15 illustrates the VRRP required on all VPN concentrators in the network topology illustrated in Figure 9-1.

Figure 9-15. VPN3000 VRRP-Based IPsec RAVPN HA Configuration

[View full size image]

It is critically important to consider that, in the above RAVPN design, there is no dynamic communication of IPsec configuration or state between the Master VRRP concentrator and its backup VRRP concentrators. As such, on Cisco ASA5500 and VPN3000 series IPsec VPN concentrators, VRRP-based HA options are considered to be stateless. In a VRRP-based RAVPN HA design, the master and backup concentrators must have identical IPsec and ISAKMP settings, so that clients are able to use any concentrator that happens to be the VRRP master at any given point in time. Inconsistencies in these configuration settings can lead to inconsistent success in IPsec VPN tunnel negotiation across the cluster, as some concentrators will be appropriately configured to successfully terminate inbound IPsec VPN tunnels from VPN clients, while others will not.

Tip

IOS IPsec features can be configured to support HSRP-based termination of IPsec VPN tunnels in a stateful manner between two IOS-based IPsec VPN concentrators (routers configured for RAVPN). Chapter 6 covers the comparison of stateless vs. stateful IPsec VPN tunnel termination in greater detail.

Additionally the network design illustrated in Figure 9-1 requires that all of the VPN clients use the same VRRP Virtual Router IP address for IPsec peering to the concentrator cluster. While this does provision for high availability in the concentrator cluster, it does not provision for session load balancing. We will discuss how IPsec session load balancing can be achieved in highly available RAVPN implementations using Virtual Clustering later in this chapter.

In this section, we've discussed how VRRP can be used for VPN Concentrator High Availability. The concepts of RAVPN HA discussed above are all stateless in nature, meaning that, when VPN clients successfully negotiate IPsec VPN tunnels with the concentrator, this state is not communicated to the backup concentrators in the cluster. As such, when a failover occurs on a VPN concentrator terminating IPsec VPN sessions for multiple IPsec VPN clients, these clients must renegotiate Phase 1 and 2 SAs with the backup IPsec VPN concentrator. In the following section, we will explore a stateful RAVPN HA design using Cisco IOS-based RAVPN concentrators that enables us to avoid the renegotiation of Phase 1 and 2 SAs with the backup VPN concentrators when a failure occurs on master VPN concentrator.

IPsec RAVPN Concentrator HA Using HSRP

HSRP operates in a similar fashion to VRRP. HSRP can therefore be used in a similar fashion to VRRP to provide IPsec Local HA. Thus far, we've discussed design options for providing stateless IPsec RAVPN HA in a VPN concentrator cluster design using VRRP. With Cisco IOS, the same design principals of a stateless RAVPN HA concentrator cluster design can be extended to incorporate stateful failover across different concentrators in a given cluster. This section discusses an IOS-based concentrator design that uses HSRP for stateful RAVPN high availability.

In RAVPN concentrator cluster designs, HSRP provides high availability in a fashion similar to VRRP by electing an "active" (equivalent to the VRRP "master" concentrator) concentrator that is responsible for the forwarding of all traffic and session termination from all clients in the HSRP group. The other concentrators in the HSRP group are "standby" (equivalent to VRRP "backup" concentrators) until they assume active responsibilities due to a change in the network. Like VRRP, the HSRP active router sends periodic status messages to other concentrators in the HSRP group using a link local multicast address (HSRP=224.0.0.2, VRRP=224.0.0.18). If one or more concentrators in the HSRP group does not receive an HSRP status message within a configurable amount of timed windows, the standby concentrators then undergo an election to determine the new active HSRP concentrator/router. Like VRRP, the HSRP concentrator with the highest priority will assume the role of "active" and responsibilities for forwarding all traffic and terminating all inbound IPsec sessions for the HSRP group.

Tip

For more information on HSRP and its many uses, please refer to the following sources of information:

http://www.ietf.org/rfc/rfc2281.txt

http://www.cisco.com/en/US/partner/tech/tk648/tk362/tk321/tsd_technology_support_sub-protocol_home.html

The solution for RAVPN HA discussed in this section is not primarily differentiated by the use of HSRP over VRRP. Instead, the key difference in this design is that it is stateful instead of stateless. Figure 9-16 presents a design with IOS-based VPN concentrators to deliver stateful failover across the different concentrators in the cluster.

Figure 9-16. Dual-DMZ IOS-Based Concentrator Design with HSRP-Based Stateful HA.

[View full size image]

The following illustrates the HSRP-based stateful failover process for the topology depicted in Figure 9-16:

1.
VPN7301-A, B, and C are all configured for HSRP on the DMZ-Outside network segment. VPN7301-A is currently with the highest HSRP priority making it become the active concentrator and assume forwarding responsibility for RAVPN clients.

2.
As clients successfully use the HSRP Standby IP interface currently active on VPN7301-A to terminate IPsec VPN tunnels, the state for each of these tunnels is periodically communicated using SSO and SCTP to the backup routers in the HSRP group (VPN7301-B and C).

Tip

The stateful IPsec high availability design described here is a local IPsec HA design applied to Cisco routers running IOS and acting as a concentrator cluster in an RAVPN for IPsec VPN clients. The design leverages stateful failover concepts for site-to-site IPsec Local HA using HSRP and SSO. For more information on HSRP and SSO specifics in the context of IPsec Local HA, please refer to Chapter 6.

3.
A link failure on VPN7301-A's public interface (GigE0/0) causes the concentrator to become unavailable to inbound IPsec VPN sessions from the VPN clients.

4.
VPN7301-B and C are configured to wait three successive timed intervals to receive a HSRP router advertisement from the master router before attempting to elect a new active HSRP router. After missing a HSRP advertisement from VPN7301-A in the third timed interval, VPN7301-B and C attempt to elect a new active HSRP router through the exchange of their own HSRP router advertisement messages. As VPN7301-B has the second highest priority next to VPN7301-A, it becomes new active HSRP router.

5.
The VPN clients that had established IPsec VPN tunnels with VPN7301-A when it was the active HSRP router in the cluster seamlessly fail their session over to VPN7301-B, the newly elected active HSRP router. This seamless transition of IPsec sessions is enabled by the proactive communication of IPsec state using SSO in step 1. Unlike the stateless HA scenario described previously using VRRP on VPN3000 and ASA5500 concentrators, the VPN clients transitioning their IPsec VPN sessions from VPN7301-A to VPN7301-B in this stateful HA failover process step do not have to renegotiate Phase 1 and 2 SAs with VPN7301-B.

6.
When VPN clients attempt to negotiate IPsec VPN tunnels with the Concentrator Cluster using the HSRP Standby IP address, VPN7301-B will be responsible for terminating the inbound IPsec VPN tunnels.

Note

The VPN clients in this example are configured with only one IPsec peer corresponding to the HSRP Standby IP address for the IPsec VPN routers in that HSRP group. As such, the clients are unaware of any changes that occur in the concentrator cluster due to the failure described abovethey will always use the same IP address for their IPsec peer regardless of which VPN router is the actively forwarding for that HSRP group.

7.
In this stateful IPsec RAVPN HA design, VPN7301-A is not configured to preempt the other routers in the HSRP group when it recovers from a failure. This means that it will rejoin the HSRP group as a standby router until another failure occurs and another HSRP election process is executed.

Tip

When an IPsec device recovers and attempts to preempt other IPsec routers in the HSRP group, it will likely not have the appropriate state information to seamlessly transition the existing IPsec sessions from the existing active IPsec router. This will cause the sessions to be dropped and renegotiated with the preempting IPsec VPN router. This behavior essentially negates the use of stateful HA, reverting back to a stateless failover. In stateful HA configurations, disabling preemption enables a router to relearn IPsec session state using SSO as a standby HSRP router. As such, when another failure occurs, this router is now prepared to assume the role of the active IPsec VPN router and to seamlessly transition IPsec VPN sessions in a stateful manner.

8.
IPsec VPN clients will continue to use VPN7301-B as their IPsec RAVPN peer until a change in the network forces another HSRP election. In the meantime, VPN7301-A has recovered as a standby HSRP router in the cluster, and is receiving periodic HSRP advertisements and IPsec SSO state messages from VPN7301-B. Therefore, when a change in the network forces another HSRP election, VPN7301-A will have the appropriate IPsec SADB entries for Phase 1 and 2 SAs to the VPN clients required to seamlessly assume forwarding responsibilities for those clients as the active HSRP router without forcing the VPN clients to renegotiate Phase 1 and 2 SAs.

The design process described above effectively increases HA baselined in the VRRP-based dual-DMZ concentrator design of Figure 9-1, but provides little in the way of session load balancing across the concentrators in the cluster in active/active/active scenarios. When deploying this design, administrators face the same load-balancing challenges faced in our discussion of VRRP-based RAVPN HA concentrator cluster deployment. The stateful design described in this section can leverage the use of multiple HSRP groups to load balance across the VPN routers VPN7301-A, B, and C when all three routers in the cluster are active.

Example 9-1 illustrates the configuration of the VPN routers VPN7301-A, B, and C for RAVPN IPsec session concentration using HSRP for stateful IPsec HA. In order to support IPsec stateful HA, VPN7301-A is configured to preemptively communicate the state of the SADB using SSO to VPN7301-B and C using the redundancy scheme "chap9-stateful" as shown in lines 8 and 9 of Example 9-1. Proactive communication of the IPsec SADB state to redundant IPsec gateways is accomplished with the SSO configurations in lines 11-22. The crypto engine is then instructed to use this SSO stateful failover configuration during the application of the crypto map in line 56. In addition to these SSO-specific configuration elements required for stateful failover, VPN7301-A's configuration has several elements required for RAVPN Termination, described in the following bulleted list:

  • IKE X-Auth (Lines 4-5, 41, 43, 62, and 63): IKE x-Auth required to authenticated IKE SAs based on specific user accounts with either Terminal Access Controller Access Control System+ (TACACS+) or RADIUS (RADIUS is used in this example).

  • IKE Mode ConfigGroup Key Definition (Lines 32-33): Required to complete the IKE Phase 1 SA before IKE x-Auth can occur (Phase 1.5).

  • IKE Mode ConfigClient Address Assignment (Line 29): During IKE, Mode Config can be used to assign a variety of parameters to a VPN client, including IP addresses, domain names, and default gateways. Line 29 instructs the IOS VPN concentrator to assign clients IP addresses with Mode Config from the defined pool "chap9-stateful-pool."

  • Dynamic Crypto Map Configuration (Lines 37-39): A dynamic crypto map is required, as the IPsec VPN peers' (VPN clients) IP addresses are unknown (they will vary based on their location and assigned DHCP address).

  • Static Crypto Map Configuration (Lines 41-44): The static crypto map references the dynamic crypto map. To facilitate RAVPN Concentration, the static crypto map also references the authentication, authorization, and accounting (AAA) list to be used for authenticating and authorizing VPN clients with x-Auth. The crypto map also specifies whether or not to initiate IP address assignment or respond to an address assignment request with IKE Mode config. In this case, VPN7301-A is instructed to initiate IP address assignment with IKE Mode Config.

  • Interface-Level Crypto Configuration (Line 56): This configuration line binds all of the crypto information defined in the static crypto map "chap9-stateful-static" to the crypto interface, FastEthernet0/0, on VPN7301-A. Additionally, because the dynamic crypto map "chap9-stateful-dynamic" was previously referenced in the static crypto map, the elements referenced in the dynamic crypto map configuration are also bound to this crypto interface. Note that the inter-device redundancy configuration "chap9-stateful" is appended to the end of the interface crypto map configuration. This effectively binds the stateful HA SSO redundancy configuration "chap9-stateful" to the crypto process configured for FastEthernet0/0.

  • Address Pool Definition (Line 59): IKE Mode Config has been previously configured to assign VPN clients from IP addresses from this pool, "chap9-stateful-pool."

  • RADIUS Server Configuration (Line 62-63): These commands configure the VPN7301-A to use the RADIUS Server IP "10.0.0.101" and key "cisco123" for authenticating VPN client credentials using IKE x-Auth.

Example 9-1. VPN7301A Stateful IPsec RAVPN HA Configuration

1  VPN7301-A#show running-config
2  !
3  !
4  aaa authentication login ravpn-auth group radius
5  aaa authorization network ravpn-auth group radius
6  !
7  !
8  redundancy inter-device
9   scheme standby chap9-stateful
10 !
11 ipc zone default
12  association 6
13   no shutdown
14   protocol sctp
15    local-port 6666
16     local-ip 10.1.1.1
17     retransmit-timeout 200 5000
18     path-retransmit 10
19     assoc-retransmit 20
20    remote-port 6666
21     remote-ip 10.1.1.2
22     remote-ip 10.1.1.3
23 !
24 !
25 crypto isakmp policy 10
26  authentication pre-share
27  hash md5
28  group 2
29 crypto isakmp client configuration address-pool local chap9-stateful-pool
30
31 !
32 crypto isakmp client configuration group chap9-stateful
33  key cisco123
34 !
35 crypto IPsec transform chap9-stateful-trans esp-3des esp-md5-hmac
36 !
37 crypto dynamic-map chap9-stateful-dyn 10
38  set transform-set chap9-stateful-trans
39  reverse-route
40 !
41 crypto map chap9-stateful-static client authentication list ravpn-auth
42 crypto map chap9-stateful client configuration address initiate
43 crypto map chap9-stateful-static isakmp authorization list ravpn-auth
44 crypto map chap9-stateful-static 10 IPsec-isakmp dynamic chap9-stateful-dyn
45 !
46 !
47 interface FastEthernet0/0
48  ip address 10.1.1.1 255.255.255.0
49  ip directed-broadcast
50  speed auto
51  half-duplex
52  standby 1 ip 10.1.1.100
53  standby 1 priority 30
54  standby 1 preempt
55  standby 1 name chap9-stateful-static
56  crypto map chap9-stateful-static redundancy chap9-stateful
57 !
58 !
59 ip local pool chap9-stateful-pool 192.168.1.1 192.168.1.100
60 !
61 !
62 radius-server host 10.1.1.101 auth-port 1645 acct-port 1646
63 radius-server key cisco123

Note

VPN7301-B and C are configured in a similar manner to VPN7301-A. They use the same radius server and key and the same HSRP standby address among other similarities. Additionally, the IPsec and ISAKMP configurations are identical between VPN7301-A, B, and C. The main differences on VPN7301-B and C are:

SSO Peering Definitions: VPN7301-B must peer with A and C, and VPN7301-C must peer with A and B.

HSRP Priority Definition: VPN7301-A and B are configured with lower HSRP priorities.

Physical IP Addressing: VPN7301-B's and C's physical IP addresses are different from VPN7301-A, following the addressing information provided in Figure 9-16.

At this point, we've explored both stateful and stateless RAVPN HA designs, illustrating how system reconvergence can be expedited through the proactive communication of SADB state from the active concentrator (active router in the HSRP group) to the backup concentrators (standby routers in the HSRP group) resulting in a seamless failover from the VPN client's perspective (no renegotiation of IKE Phase 1 or 2 SAs). However, stateful and stateless IPsec VPN designs share one common design limitationneither provide for IPsec session load balancing, as all IPsec VPN client connections are terminated on the active HSRP (or master VRRP) router or concentrator in the concentrator cluster. Cisco VPN concentrators support dynamic per-session load balancing across the different concentrators in the cluster using Virtual Cluster Agent (VCA), which we will discuss in the following section.


IPsec RAVPN Concentrator HA Using the VCA Protocol

VCA has become a very popular means by which to provide Local HA in VPN concentrator cluster designs. In a design that uses VCA, the VPN concentrators participating in the cluster are known as VCAs. The VCAs each communicate their status to one another using the VCA protocol. VCA architecture is proprietary to Cisco Systems IPsec VPN concentrators. Additionally, VCA is not supported in Cisco IOS, and is supported only in VPN3000 series concentrators and the ASA5500 series Adaptive Security Appliances. The example in this section uses ASA5500s to illustrate the load-balancing and HA concepts provided by VCA. Example 9-2 provides the IPsec RAVPN user, group, IPsec, and ISAKMP configurations that will support the VCA configurations illustrated in Figure 9-17, Figure 9-18, and Figure 9-19 later in this section.

Figure 9-17. VCA Cluster Master Concentrator Election

[View full size image]

Figure 9-18. VCA Cluster IPsec Session Load Balancing

[View full size image]

Figure 9-19. RAVPN DNS-Based IPsec Session Load Balancing

[View full size image]

The ASA5540 VPN Appliance configuration in Example 9-2 requires security level interface configurations in the same manner that one would configure a PIX firewall. From the ASA5540 VPN concentrators perspective, configuring security level 0 on Ethernet0/0 makes Ethernet0/0 the VPN concentrator public interface. Defining security level 100 on Ethernet0/1 makes it the VPN concentrator's private interface.

In a manner similar to the IOS configuration previously discussed in Example 9-1, a dynamic crypto map, "chap9-3-dyn," is configured on all ASA5500s to accommodate change in VPN client IP addresses as they move from one location to another (line 27). RRI will inject a route for the host in to the corporate network after the SADB is populated with a Phase 2 SA for that IPsec VPN client (line 28). The dynamic crypto map is referenced in the static crypto map "chap9-3-stat" so that it can be bound to one or more physical interfaces on ASA5540-A.

ISAKMP configuration ASA5540 is configured in two parts. First, a standard ISAKMP policy is configured, including authentication method, encryption cipher, hash, SA lifetime, and Diffie-Hellman Group Modulus. This part of ASA5540's ISAKMP configuration is provided in Example 9-2, lines 31-36. Second, a tunnel group is configured to configure various extensions to IKE, including IKE x-Auth and IKE Mode Config. The tunnel-group configuration for ASA5540 is included in Example 9-2, lines 39-45. The tunnel group configuration for ASA5540-A in Example 9-2 enables the following capabilities:

  • Tunnel-Group Type Definition (Line 39): The Tunnel Group is defined as a Remote Access Tunnel group, enabling parameters for RAVPN within the tunnel group configuration options.

  • IKE Mode ConfigAddress Assignment (Line 41): Allocates IP addresses from the range specified in the pool "chap9-3-pool" when assigning VPN clients their IP addresses.

  • IKE X-AuthAuthentication (Line 42): Specifies the AAA Server Group "chap9-3-xauth" (which in turn uses a RADIUS server, "10.1.1.101," and a key of "cisco123") for use when authenticating VPN clients with RADIUS.

  • IKE X-AuthAuthorization (Line 43): Specifies the AAA Server Group "chap9-3-xauth" (which in turn uses a RADIUS server, "10.1.1.101," and a key of "cisco123") for use when authorizing VPN clients with RADIUS.

  • IKE Pre-Shared Group Key (Line 45): A group key is required to complete IKE Phase 1 Authentication before IKE x-Auth can occur during Phase 1.5 negotiation.

Warning

Normally, wildcard or preshared group keys are not recommended as a best practice unless they are supplemented with a more granular form of authentication such as IKE x-Auth. This is because of the group member eviction difficulties they present. When group keys are used with IKE x-Auth, this risk is mitigated because of the required authentication of individual user credentials in conjunction with the validation of the group key. Caution should be taken when wildcard or group preshared keys are used without a more granular supplemental form of IKE authentication such as IKE X-Auth.

Example 9-2. ASA5540A Basic IPsec RAVPN Configuration (Figure 9-17, Figure 9-18, and Figure 9-19)

1  ASA5550-A# show run
2  : Saved
3  :
4  ASA Version 7.0(2)
5  names
6  !
7  interface Ethernet0/0
8   nameif outside
9   security-level 0
10  ip address 10.1.1.1 255.255.255.0
11 !
12 interface Ethernet0/1
13  nameif inside
14  security-level 100
15  ip address 10.0.0.1 255.255.255.0
16 !
17 !
18 aaa-server chap9-3-xauth protocol radius
19 aaa-server chap9-3-xauth host 10.0.0.101
20  key cisco123
21 !
22 !
23 ip local pool chap9-3-pool 192.168.1.1-192.168.1.100
24 !
25 !
26 crypto IPsec transform-set chap9-3 esp-3des esp-md5-hmac
27 crypto dynamic-map chap9-3-dyn 10 set transform-set chap9-3
28 crypto dynamic-map chap9-3-dyn 10 set reverse-route
29 crypto map chap9-3-stat 10 IPsec-isakmp dynamic chap9-3-dyn
30 crypto map chap9-3-stat interface outside
31 isakmp enable outside
32 isakmp policy 10 authentication pre-share
33 isakmp policy 10 encryption 3des
34 isakmp policy 10 hash sha
35 isakmp policy 10 group 2
36 isakmp policy 10 lifetime 86400
37 !
38 !
39 tunnel-group chap9-3-group type IPsec-ra
40 tunnel-group chap9-3-group general-attributes
41  address-pool chap9-3-pool
42  authentication-server-group (outside) chap9-3-xauth
43  authorization-server-group chap9-3-xauth
44 tunnel-group chap9-3-group IPsec-attributes
45  pre-shared-key *
46 Cryptochecksum:4b678d738ff3aa2976e916cca5687442
47 : end

Note

The configurations for ASA5540-B and ASA5540-C use the same base RAVPN IPsec configuration. The only difference is the change in IP addresses on the Inside and Outside interfaces:

ASA5540-B, Outside = 10.1.1.2/24

ASA5540-B, Inside = 10.0.0.2/24

ASA5540-C, Outside = 10.1.1.3/24

ASA5540-C, Inside = 10.0.0.4/24

Unlike single-group VRRP or HSRP-based IPsec RAVPN HA designs, all VPN concentrators in a VCA-enabled cluster forward traffic in a load-balanced fashion. VCA achieves this by directing incoming sessions to the least-loaded concentrator in the VCA cluster. Like HSRP and VRRP-based RAVPN HA designs, VCA employs the use of configurable priority levels to elect a "master" VCA in the cluster (the other concentrators in the cluster are referred to as "secondary" concentrators). The master VCA is responsible for polling the secondary concentrators for their current load attributable to inbound IPsec VPN client session processing. Unlike HSRP and VRRP, there is no concept of preemption, meaning that, when a VCA rejoins concentrator cluster, it will join as a secondary concentrator. With VCA, election of the master concentrator occurs only when the current master concentrator fails. Figure 9-17 illustrates a VCA-enabled concentrator cluster design that we will use to illustrate the designation of a master concentrator in the VCA cluster.

The following ordered sequence of events corresponding to the network topology in Figure 9-17 describes the VCA master election process when all three VPN concentrators are brought online together, and the election process that occurs when the VCA master (ASA5540-A) goes offline and then returns:

1. | The concentrators are powered up in following order ASA5540-A (Priority 1) first, followed by ASA5540-B (Priority 5), then ASA5540-C (Priority 10). This is shown in steps 1a, 1b, and 1c, respectively. Even though ASA5540-A has the lowest priority in the VCA cluster, it becomes the master concentrator, as it was the first concentrator to join the cluster.
2. | When ASA5540-B and C are brought online after ASA5540-A, they send User Datagram Protocol (UDP) messages on 9023 (default) to ASA5540-A with their session load information, defined as the percentage of consumed IPsec sessions on the concentrator (active sessions/max sessions). ASA5540-A uses this information to load balance IPsec sessions from VPN clients across the three active concentrators in the cluster (ASA5540-B and C). ASA5540-B and C join as secondary controllers regardless of their priority.
3. | A link failure occurs, causing ASA5540-A's public interface to become unavailable.
4. | ASA5540-B and C to elect a new VCA master. ASA5540-C becomes the master controller, as it has the highest configured priority.
5. | ASA5540-B sends keepalives to ASA5540-C with its session load information. ASA5540-C uses this information to appropriately load balance inbound IPsec sessions from the VPN clients between itself and ASA5540-B (ASA5540-A is currently offline).
6. | ASA5540-A recovers from link failure in step 3, and joins as a secondary controller in the VCA cluster. ASA5540-A sends a keepalive message to ASA5540-C, the current master, with its current session load information. ASA5540-C uses this information to load balance inbound IPsec sessions from the VPN clients across all three active concentrator clusters (ASA5540-A, B, and C).

Note

VCA priorities are defined as part of the VCA IPsec session load-balancing configuration on the ASA5500. Example 9-3 provides a sample of this configuration later in this chapter.

Although the VCA protocol does not always elect the concentrator with the highest priority value as the master concentrator (as is the case with HSRP/VRRP with preemption enabled), it is still good practice in platform diverse VCA concentrator clusters to assign higher priority values to platforms with higher session capacity. In situations where VCA priorities are identical, the VCA secondary with the lowest IP address will assume the role of master VCA concentrator during an election. Table 9-1 provides a list of VPN3000 default VCA priority values.

Table 9-1. VPN3000 Default VCA Priority Values

VCA Concentrator Platform

Default VCA Priority Values

VPN3005

1

VPN3015

3

VPN3030

5

VPN3060

7

VPN3080

9

Tip

In scenarios in which all IPsec VPN concentrator platforms in the VCA-enabled RAVPN design are identical, setting all of the VCA priority values to the highest setting (10), can potentially speed reconvergence by decreasing the time it takes to complete the VCA election process.

Once a master concentrator exists in the cluster, secondary concentrators can join the VCA cluster and immediately participate in the VCA IPsec session load-balancing operation. The secondary concentrators use the VCA protocol, sending messages over a configurable UDP port number to the VCA master concentrator declaring their session load to the master concentrator. When a VPN client initiates a new IPsec VPN tunnel to the concentrator cluster, the VCA master concentrator redirects the IPsec session to the concentrator with the lowest IPsec session load. The session load is defined as the currently number of active IPsec sessions managed by the concentrator divided by the maximum number of sessions supported by the concentrator.

Tip

Although each VCA-enabled concentrator has a default value for the number of supported sessions, this value is a configurable VCA option.

VPN clients use the VCA Virtual IP address for the concentrator cluster (shared by all concentrators in the cluster). When a client attempts to build an IPsec VPN tunnel to the concentrator cluster using the VCA Virtual IP address, the VCA master concentrator returns the physical public IP address of the concentrator in the cluster with the lowest session load. The IPsec VPN client subsequently initiates an IPsec VPN tunnel with that concentrator determined to have the lowest session load in the VCA cluster. The result is that each IPsec VPN client is assured that it is building an IPsec VPN tunnel with the IPsec VPN concentrator with the greatest amount of available processing resources relative to any of the other VPN concentrators in the VCA cluster at any given point in time. Figure 9-18 illustrates the load-balancing operation of VCA clustering in a dual-DMZ firewall design with three clustered ASA5540s used for IPsec VPN tunnel termination from RAVPN clients.

Once a VCA master concentrator has been elected and secondary VCA concentrators have been identified in the cluster, the VCA master concentrator can begin to distribute the load of IPsec VPN sessions inbound from various VPN clients to the secondary VCA concentrators in the cluster. The following ordered sequence of events corresponding to those events illustrated in Figure 9-18 describes the process of distributing IPsec VPN sessions inbound from VPN clients across the different IPsec VPN concentrators participating in a cluster using the VCA protocol:

1. | The concentrators are all configured in the same cluster. ASA5540-A is currently the VCA master concentrator for the cluster. ASA5540-B and ASA5540-C send keepalive messages to ASA5540-A with their session load information, indicating that they currently are managing 51 and 50 IPsec sessions, respectively. ASA5540-A stores this information to execute future load-balancing decisions.
2. | Client-A initiates an IPsec VPN tunnel to the Concentrator Cluster using the VCA Virtual IP of 200.1.1.100. Initially, this session is destined for ASA5540-A, the master concentrator in the cluster.
3. | ASA5540 redirects the session to ASA5540-C (200.1.1.103), as it has the lowest session load level (50 sessions) relative to its IPsec session capacity.
4. | Client-B initiates an IPsec VPN tunnel to the Concentrator Cluster using the VCA Virtual IP of 200.1.1.100. Initially, this session is destined for ASA5540-A, the master concentrator in the cluster.
5. | ASA5540 redirects the session to ASA5540-B (200.1.1.102) even though ASA5540-A and B's loads are identical. This is because the VCA master will redirect client sessions to its secondary concentrators until it has the lowest load in the cluster. The rationale behind this is that the VCA master is burdened by the overhead of session redirection and should therefore redirect sessions to secondary concentrators with equal session loads (equaling an overall lesser load due to the absence of VCA session administration overhead on the secondary controller).
6. | Client-C initiates an IPsec VPN tunnel to the Concentrator Cluster using the VCA Virtual IP of 200.1.1.100. Initially, this session is destined for ASA5540-A, the master concentrator in the cluster.
7. | ASA5540 does not redirect the session, but instead returns its own physical IP address (200.1.1.101) to the VPN client for IPsec peer, as ASA5540-A has the lowest number of managed sessions (ASA5540-A has 50 sessions, and ASA5540-B and C both now have 51 sessions after accepting sessions from Client A and B in steps 3 and 4, respectively).

Example 9-3 provides the necessary configuration required for an ASA5500 to participate in a VCA cluster. The following configuration specifies a priority of 9, making ASA5540 the most likely concentrator in the cluster to become the VCA master concentrator. In addition to the VCA priority, all of the participating concentrators in the VCA cluster must be configured with an identical VCA cluster IP address. In this case, ASA5540-A is configured to participate in the VCA cluster with the VCA cluster IP address of 200.1.1.100. It is instructed to encrypt exchanges between concentrators in the cluster with a key of "cisco123."

Example 9-3. ASA5540A VCA Load-Balancing Configuration

ASA5540-A(config)# Vpn load-balancing
ASA5540-A(config-load-balancing)# priority 9?
ASA5540-A(config-load-balancing)# cluster key cisco123
ASA5540-A(config-load-balancing)# cluster ip address 200.1.1.100
ASA5540-A(config-load-balancing)# cluster encryption?
ASA5540-A(config-load-balancing)# participate

Note

The load-balancing configurations on ASA5540-B and C are identical to ASA5540-A in every way except for the priority definition (ASA5540-B = 5, ASA5540-C = 3). The cluster key and IP address must be identical across all VPN concentrators in the VCA-enabled cluster. The concentrator with the highest priority has the best chance of becoming the master concentrator.

It is important to note that, in Figure 9-17, Figure 9-18, Example 9-2, and Example 9-3, identical VPN concentrator platforms were selected to more clearly illustrate the load-balancing process in a concentrator cluster using VCA. One major benefit of the VCA protocol is that it factors each platform's capacity in to its load-balancing scheme. As such, if a smaller concentrator (such as a VPN3005) capable of supporting a smaller amount of sessions were to be introduced to the VCA cluster, the master concentrator would factor the smaller capacity of the VPN3005 when redirecting IPsec VPN client sessions. This is achieved by each concentrator's definition of session load: the number of current sessions divided by the number of maximum sessions. In the case of the VPN3005 joining a cluster of ASA5540s, the VPN3005 would express its load as a percentage of the active sessions relative to its platform session capacity to the master, thereby providing the master VCA controller with a metric incorporating the platforms session capacity. As such, a VCA master controller will often continue to assign IPsec sessions to higher-capacity concentrators, such as the ASA5530 concentrators previously, even if they have a greater raw session count than lower-capacity concentrators such as the VPN3005.

Through proper implementation of VCA-enabled concentrators in an RAVPN design, IPsec VPN clients can be assured that they are terminating their IPsec tunnel on the concentrator with the highest degree of available computational resources of any concentrator in the VCA cluster. VCA therefore offers a method of load balancing that yields the most efficient use of IPsec processing resources in Cisco-based IPsec RAVPN concentrator designs of any of the designs discussed.


IPsec RAVPN Geographic HA Design Options

Once the RAVPN has the appropriate amount of resiliency designed into the VPN concentrator cluster, there are several design options that can be selected for VPN clients to take full advantage of the resilient concentrator cluster design. In this section, we will explore the use of geographic HA in an RAVPN. First, we will discuss how Domain Name System (DNS) can be configured to load balance inbound IPsec sessions from the VPN clients across multiple concentrators in a given cluster. After exploring this design alternative, we will then add the use of multiple peer definitions in the IPsec VPN client profile to provide resilient peering to multiple IPsec VPN concentrators. We will explore how these geographic HA options can be deployed in a standalone fashion, or in tandem for increased geographic IPsec HA.

VPN Concentrator Session Load Balancing Using DNS

Geographic HA can be designed in to an RAVPN deployment using DNS-based load balancing. In this section, we will explore how resolving a single IPsec VPN concentrator hostname to multiple IP address assigned to the public interfaces of different VPN concentrators in a cluster can result in a round-robin distribution of IPsec VPN client sessions across the VPN concentrators in a given cluster. Figure 9-19 illustrates a RAVPN deployment in which IPsec VPN clients resolve the hostname cluster-main.cisco.com to the various IP addresses of the public interfaces on the VPN concentrators in the cluster in a round-robin fashion.

The following order of operations describes the numbered process of DNS-based round-robin IPsec VPN session load balancing across redundantly configured VPN concentrators:

1. | Client-A initiates an IPsec VPN tunnel to the concentrator cluster using the hostname "cluster-main.cisco.com." Client-A attempts to resolve the IP address of "cluster-main.cisco.com" sing the DNS server at 200.1.1.17.
2. | The DNS server at 200.1.1.17 responds with the first IP address assigned to cluster-main.cisco.com (200.1.1.101), which is also the IP address of the public interface configured on ASA5540-A.
3. | Client-A establishes an IPsec VPN tunnel to ASA5540-A using the IP address of 200.1.1.1 for IPsec peering.
4. | Client-B initiates an IPsec VPN tunnel to the concentrator cluster using the hostname "cluster-main.cisco.com." Client-B attempts to resolve the IP address of "cluster-main.cisco.com" using the DNS server at 200.1.1.17.
5. | The DNS server at 200.1.1.17 responds with the second IP address assigned to cluster-main.cisco.com (200.1.1.102), which is also the IP address of the public interface configured on ASA5540-B.
6. | Client-B establishes an IPsec VPN tunnel to ASA5540-B using the IP address of 200.1.1.102 for IPsec peering.
7. | Client-C initiates an IPsec VPN tunnel to the concentrator cluster using the hostname "cluster-main.cisco.com." Client-C attempts to resolve the IP address of "cluster-main.cisco.com" using the DNS server at 200.1.1.17.
8. | The DNS server at 200.1.1.17 responds with the third IP address assigned to cluster-main.cisco.com (200.1.1.103), which is also the IP address of the public interface configured on ASA5540-C.
9. | Client-C establishes an IPsec VPN tunnel to ASA5540-C using the IP address of 200.1.1.103 for IPsec peering.

The process described above continues in a round-robin fashion as new IPsec VPN clients attempt to build IPsec VPN tunnels with the IPsec VPN concentrator cluster. Although this method of RAVPN IPsec session load balancing is not as efficient or effective as VCA, it does ensure that inbound IPsec VPN tunnels are evenly distributed across the concentrators in the cluster.

With DNS-based load balancing, an even distribution of IPsec VPN tunnels is achieved. Even distribution provides an effective means of load balancing, but perhaps not the most effective and efficient. VCA, however, does not provide an even distribution of inbound IPsec VPN sessions across the clusters. Instead, IPsec VPN session distribution decisions are made based on actual session load information taken from the concentrators in the cluster, accounting for platform-specific capacity considerations and fluctuation in IPsec session load statistics on the concentrators in the cluster. RAVPN HA designs using VCA are supported only by Cisco VPN concentrators, and as such, using VRRP-based RAVPN HA or DNS-based load balancing both present viable design alternatives for RAVPN HA in vendor-diverse environments. However, in Cisco-based RAVPN HA concentrator cluster designs, VCA adds an extra layer of intelligence to load balancing and redundancy operations that enable optimized distribution of IPsec VPN sessions across the different concentrators in the VCA cluster.

VPN Concentrator Redundancy Using Multiple Peers

Another layer of Geographic HA can be built in to the RAVPN design by defining multiple IPsec peers in the IPsec VPN client profile. In this section, we will explore two designs that use multiple IPsec peers for Geographic HA:

  • Multiple IPsec Peers with HSRP-Based VPN Concentrator HA and DNS-Based Load Balancing

  • Multiple IPsec Peers with Multiple VCA Concentrator Clusters for HA and Load Balancing

Figures 9-20 through 9-22 illustrate the VPN client configuration required to leverage geographic HA using multiple IPsec peer definitions. The configuration is the same regardless of whether that peer represents an HSRP Standby interface or a VCA Virtual IP address.

Figure 9-20. IPsec VPN Client Authentication Configuration

Figure 9-21. IPsec VPN Client Transport Configuration

Figure 9-22. Configuring Backup Peers on Cisco VPN Clients

The first design we will discuss deploys a stateless IPsec VPN concentrator design using HSRP-based tunnel termination with multiple HSRP groups for HA and DNS-based. In Figure 9-19, the three IPsec VPN concentrators are configured for stateful HA using three HSRP groups with different HSRP Virtual Router IP addresses. Instead of statically assigning VPN clients to a VRRP group, the concentrators in this cluster use DNS-based load balancing to dynamically return a different HSRP Virtual Router IP address when a round-robin VPN client establishes an IPsec VPN session to the concentrator. The load-balancing configuration for Figure 9-23 is summarized in Table 9-2.

Figure 9-23. Geographic IPsec HA Using Multiple IPsec Peer Hostnames in the VPN Client Profile, DNS-Based Load Balancing, and VRRP-Based IPsec VPN concentrator Local HA

[View full size image]

Table 9-2. VRRP-Based Stateless IPsec RAVPN HA Load Balancing with Multiple VRRP Groups, DNS-Based Load Balancing, and Multiple Peer Definitions in the IPsec VPN Client Profile

Cluster Hostname: charlotte-vpn.cisco.com
DNS IP Resolutions: 200.1.1.100
200.1.2.100
200.1.3.100

HSRP Group#: 1
IP: 200.1.1.100

HSRP Group#: 2
IP: 200.1.2.100

HSRP Group#: 3
IP: 200.1.3.100

Concentrator:

Priority: 30

Priority: 20

Priority: 10

VPN7301-CHA-A

Status: Master

Status: 1st Backup

Status: 2nd Backup

VPN Clients:

1st + Every Other 3rd

Concentrator:

Priority: 10

Priority: 30

Priority: 20

VPN7301-CHA-B

Status: 2nd Backup

Status: Master

Status: 1st Backup

VPN Clients:

2nd + Every Other 3rd

Concentrator:

Priority: 20

Priority: 10

Priority: 30

VPN7301-CHA-C

Status: 1st Backup

Status: 2nd Backup

Status: Master

VPN Clients:

3rd + Every Other 3rd

Cluster Hostname: boulder-vpn.cisco.com
DNS IP Resolutions: 200.2.1.100
200.2.2.100
200.2.3.100

VRRP Group#: 1
IP: 200.2.1.100

VRRP Group#: 2
IP: 200.2.2.100

VRRP Group#: 3
IP: 200.2.3.100

Concentrator:

Priority: 30

Priority: 20

Priority: 10

VPN7301-BOU-A

Status: Master

Status: 1st Backup

Status: 2nd Backup

VPN Clients:

1st + Every Other 3rd

Concentrator:

Priority: 10

Priority: 30

Priority: 20

VPN7301-BOU-B

Status: 2nd Backup

Status: Master

Status: 1st Backup

VPN Clients:

2nd + Every Other 3rd

Concentrator:

Priority: 20

Priority: 10

Priority: 30

VPN7301-BOU-C

Status: 1st Backup

Status: 2nd Backup

Status: Master

VPN Clients:

3rd + Every Other 3rd

The design leverages the use of two concentrator clusters, boulder-vpn.cisco.com and charlotte-vpn.cisco.com. Each cluster acts as a "primary" cluster for its half of the VPN client population in the RAVPN design: boulder-vpn.cisco.com serves as the primary cluster for users in the western half of the country, while charlotte-vpn.cisco.com serves as the primary cluster for the eastern half of the country. The VPN clients are configured to use multiple IPsec peers for geographic HA. The IPsec VPN clients will therefore attempt to connect to their primary cluster first. If they are unable to connect to their primary cluster within a configurable timeout window, they will try the other cluster as a backup. Within each cluster, inbound IPsec sessions are distributed across three VRRP groups with skewed priorities consistent with the format in Table 9-2 using DNS-based load balancing.

The following sequence of steps illustrates the order of operations executed when clients attempt to build IPsec VPN tunnels to the redundant pair of concentrator clusters illustrated in Figure 9-23.

1. | Client-Cha1 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.
2. | The DNS server returns the first HSRP Virtual Router IP address (Group 1 = 200.1.1.101) for charlotte-vpn.cisco.com.
3. | Client-Cha1 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-CHA-A (the Active HSRP Router for HSRP Group 1).
4. | Client-Cha2 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.
5. | The DNS server returns the second HSRP Virtual Router IP address (Group 1 = 200.1.1.102) for charlotte-vpn.cisco.com.
6. | Client-Cha2 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-CHA-B (the Active HSRP Router for HSRP Group 2).
7. | As long as the all of the concentrators in the VPN cluster charlotte-vpn.cisco.com are active, the DNS-server at 200.1.1.17 distributes the IPsec VPN sessions from the Charlotte clients evenly across the VPN concentrators in the Charlotte cluster (VPN7301-CHA-A, B, and C). This is achieved by using DNS-based load balancing to return the HSRP Virtual Router IP addresses corresponding to VPN7301-CHA-A, B, and C in a round-robin format following the same process as illustrated in steps 1-6 above.
8. | Client-Bou1 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.
9. | The DNS server returns the first HSRP Virtual Router IP address (Group 1 = 200.1.2.101) for boulder-vpn.cisco.com.
10. | Client-Bou1 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-BOU-A (the Active HSRP Router for HSRP Group 1).
11. | Client-Bou2 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.
12. | The DNS server returns the second HSRP Virtual Router IP address (Group 1 = 200.1.2.102) for boulder-vpn.cisco.com.
13. | Client-Bou2 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-BOU-B (the active HSRP Router for HSRP Group 2).
14. | As long as all of the concentrators in the VPN cluster boulder-vpn.cisco.com are active, the DNS server at 200.1.2.17 distributes the IPsec VPN sessions from the Boulder clients evenly across the VPN concentrators in the Boulder cluster (VPN7301-BOU-A, B, and C). This is achieved by using DNS-based load balancing to return the HSRP Virtual Router IP addresses corresponding to VPN7301-BOU-A, B, and C in a round-robin format following the same process as illustrated in steps 8-13 above.
15. | A power outage occurs in the Boulder Facility hosting the IPsec VPN concentrator cluster boulder-vpn.cisco.com, making all concentrators in the cluster unavailable.
16. | Client-Bou3 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname boulder-vpn.cisco.com to an IP address using the DNS server at 200.1.2.17. Due to the power outage in step 15 above, Client-Bou3 receives no reply from the DNS server at 200.1.2.17. Client-Bou3 queries 200.1.1.17 instead.
17. | The DNS server 200.1.1.17 returns the third HSRP Virtual Router IP address (Group 1 = 200.1.1.103) for charlotte-vpn.cisco.com to Client-Bou3.
18. | Client-Bou3 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-CHA-C (the Active HSRP Router for Group 3).
19. | As long as the all of the concentrators in the VPN cluster charlotte-vpn.cisco.com are active, the DNS-server at 200.1.1.17 distributes the IPsec VPN sessions from the Boulder clients evenly across the VPN concentrators in the Charlotte cluster (VPN7301-CHA-A, B, and C). This is achieved by using DNS-based load balancing to return the VRRP Virtual Router IP addresses corresponding to ASA5540-CHA-A, B, and C in a round-robin format. When the VPN concentrator cluster in Boulder recovers from the power outage in step 15, Boulder clients will revert back to boulder-vpn.cisco.com concentrator cluster.

Tip

Upon recovery of a client's primary IPsec VPN concentrator cluster, the active remote VPN tunnels on a given VPN concentrator cluster will not revert back to their primary VPN concentrator until they are torn down and renegotiated (for example, torn down by the client, or timed out by the VPN concentrator). For this reason, and for others, it is useful to configure an effective timeout period on the VPN concentrators for client RAVPN sessions.

VCA can easily replace HSRP intra-cluster HA method for boulder-vpn.cisco.com and charlotte-vpn.cisco.com in the load-balancing scenario described above. If VCA were elected as the design option for charlotte-vpn.cisco.com and boulder-vpn.cisco.com in the clusters above, the DNS server would simply be altered to return VCA Virtual IP addresses for the hostnames boulder-vpn.cisco.com and charlotte-vpn.cisco.com to the IPsec VPN clients instead of the HSRP Virtual Router IP addresses in the scenario listed Figure 9-23 and Table 9-2. The IPsec VPN client profile configuration need not be changed when replacing HSRP with VCAthe VPN clients still use the hostnames charlotte-vpn.cisco.com and boulder-vpn.cisco.com to initiate IPsec VPN tunnels to the appropriate concentrator cluster. Within the VPN concentrator cluster, there are several key changes to the design that occur when changing from VRRP to VCA. Table 9-3 provides the information required to achieve Geographic HA using multiple hostnames for IPsec peering to IPsec VPN clusters enabled for load balancing and HA using VCA:

  • There is no need for DNS-based load balancing The VCA master controller handles IPsec session load balancing within the cluster.

  • There is no need for multiple HSRP groups or multiple HSRP Virtual Router IP addresses VCA dynamically redirects inbound IPsec sessions to the appropriate concentrator based on its current load relative to the platform maximum load.

  • Although the VPN clients still use DNS to resolve the hostnames charlotte-vpn.cisco.com and boulder-vpn.cisco.com to an IP address, the DNS resolution for these hostnames is changed to yield a single VCA Virtual IP address to all DNS queries, rather than yielding multiple HSRP Virtual Router IP addresses in a round-robin fashion. VCA obsoletes the need for multiple DNS IP address under a single hostname.

Table 9-3. VCA IPsec RAVPN HA Load Balancing with DNS-Based Load Balancing and Multiple Peer Definitions in the IPsec VPN Client Profile

Cluster Hostname: charlotte-vpn.cisco.com
DNS IP Resolutions: 200.1.1.100

VCA Virtual IP: 200.1.1.100

Concentrator: ASA5540-CHA-A

Priority: 30

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.1.101

Status: Master

Concentrator: ASA5540-CHA-B

Priority: 20

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.1.102

Status: 1st Secondary

Concentrator: ASA5540-CHA-C

Priority: 10

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.1.103

Status: 2nd Secondary

Cluster Hostname: boulder-vpn.cisco.com
DNS IP Resolutions: 200.1.2.100

VCA Virtual IP: 200.1.2.100

Concentrator: ASA5540-BOU-A

Priority: 30

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.2.101

Status: Master

Concentrator: ASA5540-BOU-B

Priority: 10

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.2.102

Status: 2nd Backup

Concentrator: ASA5540-BOU-C

Priority: 20

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.2.103

Status: 1st Backup

Figure 9-24 illustrates the operation of an RAVPN design in which multiple IPsec VPN peer definitions are configured in the VPN client profile to provide Geographic HA between two VCA-enabled RAVPN concentrator clusters in Boulder (boulder-vpn.cisco.com) and Charlotte (charlotte-vpn.cisco.com). We will used the stepped order of operation corresponding to Figure 9-24 to illustrate the order of operation that occurs when VPN clients attempt to access the VCA-enabled concentrator clusters in Boulder and Charlotte.

Figure 9-24. Geographic IPsec HA Using Multiple IPsec Peer Hostnames and VCA Clustering for Local HA and Intracluster Session Load Balancing

[View full size image]

The following numbered list corresponding to the topology illustrated in Figure 9-24 describes the process of distributing inbound sessions from IPsec VPN clients when connecting to two geographically-disperse VPN concentrator clusters running the VCA session load-balancing protocol.

1. | Client-Cha1 looks up the first IPsec peer entry in its VPN Profile (charlotte-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.
2. | The DNS server returns the VCA Virtual IP address for charlotte-vpn.cisco.com (200.1.1.100).
3. | Client-Cha1 uses the IP address returned in step 2 to build an IPsec VPN tunnel with the cluster charlotte-vpn.cisco.com. The VCA master for charlotte-vpn.cisco.com (ASA5540-CHA-A) returns the physical public IP address of the least-loaded concentrator, which is currently ASA5540-CHA-B, (200.1.1.102).
4. | Client-Cha1 uses the public IP address of ASA5540-CHA-B as its IPsec peer when building the IPsec VPN tunnel.
5. | Client-Cha2 looks up the first IPsec peer entry in its VPN Profile (charlotte-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.
6. | The DNS server returns the same VCA Virtual IP address for charlotte-vpn.cisco.com (200.1.1.100) as it returned in step 2note that multiple DNS resolutions are not required here.
7. | Client-Cha2 uses the IP address returned in step 6 to build an IPsec VPN tunnel with the cluster charlotte-vpn.cisco.com. The VCA master for charlotte-vpn.cisco.com (ASA5540-CHA-A) returns the physical public IP address of the least-loaded concentrator, which is now ASA5540-CHA-C, to Client-Cha2 to use when building the IPsec VPN tunnel.
8. | Client-Cha2 establishes an IPsec VPN tunnel to the public interface on ASA5540-CHA-C (200.1.1.103).
9. | Client-Bou1 looks up the first IPsec peer entry in its VPN Profile (boulder-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.
10. | The DNS server returns the VCA Virtual IP address for boulder-vpn.cisco.com (200.1.2.100).
11. | Client-Bou1 uses the IP address returned in step 11 to build an IPsec VPN tunnel with the cluster boulder-vpn.cisco.com. The VCA master for boulder-vpn.cisco.com (ASA5540-BOU-A) returns the physical public IP address of the least-loaded concentrator, which is currently ASA5540-BOU-B.
12. | Client-Bou1 establishes an IPsec VPN tunnel to the public interface on ASA5540-BOU-B (200.1.2.102).
13. | Client-Bou2 looks up the first IPsec peer entry in its VPN Profile (boulder-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.
14. | The DNS server returns the same VCA Virtual IP address for boulder-vpn.cisco.com (200.1.2.100) as it returned in step 11 abovenote that there is no need for multiple DNS resolutions required here.
15. | Client-Bou2 uses the IP address returned in step 2 to build an IPsec VPN tunnel with the cluster boulder-vpn.cisco.com. The VCA master for boulder-vpn.cisco.com (ASA5540-BOU-A) returns the physical public IP address of the least-loaded concentrator, which is now ASA5540-BOU-C.
16. | Client-Bou2 establishes an IPsec VPN tunnel to the public interface on ASA5540-BOU-C (200.1.2.103).
17. | A power outage occurs in the Boulder Facility hosting the IPsec VPN concentrator cluster boulder-vpn.cisco.com, making all concentrators in the cluster unavailable.
18. | Client-Bou3 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname boulder-vpn.cisco.com to an IP address using the DNS server at 200.1.2.17. Due to the power outage in step 15, Client-Bou3 receives no reply from the DNS server at 200.1.2.17. Client-Bou3 queries 200.1.1.17 instead.
19. | Client-Bou3 attempts to resolve the backup IPsec peer hostname configured in its IPsec VPN profile (charlotte-vpn.cisco.com) with the DNS server at 200.1.1.17.
20. | The DNS server returns the VCA Virtual IP address for charlotte-vpn.cisco.com (200.1.1.100) to Client-Bou3.
21. | Client-Bou3 uses the IP address returned in step 2 to build an IPsec VPN tunnel charlotte-vpn.cisco.com. The VCA master for charlotte-vpn.cisco.com (ASA5540-CHA-A) returns the physical public IP address of the least-loaded concentrator, which is currently itself.
22. | Client-Bou2 establishes an IPsec VPN tunnel to the public interface on ASA5540-BOU-A (200.1.1.101).
23. | IPsec VPN sessions from both Charlotte and Boulder clients will continue to be load balanced across the concentrators participating the Charlotte VCA cluster. When the VPN concentrator cluster in Boulder recovers from the power outage in step 15, Boulder clients will revert to using boulder-vpn.cisco.com concentrator cluster for IPsec RAVPN session establishment.


Summary

The availability of a remote access VPN infrastructure is largely centered around the concentration point of RAVPN tunnels. This chapter has focused on presenting designs scenarios that can be used to increase the availability of RAVPN concentration points. The designs presented in this chapter include:

  • Resilient RAVPN Concentrator Cluster Designs with VRRP

  • Resilient RAVPN Concentrator Cluster Designs with HSRP

  • Resilient RAVPN Concentrator Cluster Designs with VCA

  • Geographically Resilient Concentrator Designs with DNS-Based Load Balancing to HSRP Virtual Interfaces

  • Geographically Resilient Concentrator Designs with DNS-Based Load Balancing to VCA Virtual IP Addresses

All of the RAVPN design concepts discussed in this chapter can be deployed in tandem to maximize RAVPN accessibility for IPsec VPN clients. However, tying all of these components together can be daunting. Keeping that in mind, it is helpful to approach designing HA and load balancing in to the RAVPN in a layered format presented in this chapter:

Step 1.
Design Local HA for IPsec VPN Concentrators: First, ensure that the VPN concentrator located at the Internet Edge is available to the IPsec VPN clients. This can be accomplished using the following methods discussed in this chapter:

  • VRRP-Based Stateless IPsec VPN Tunnel Termination

  • HSRP-Based Stateful IPsec VPN Tunnel Termination

  • VCA Concentrator Clustering

  • DNS-Based Redundancy to Standalone Concentrators

Step 2.
Incorporate Intracluster Load-Balancing Techniques: Second, once the concentrator cluster has been designed using one of the above Local HA methods, investigate the available options for load balancing within the redundancy method selected:

  • DNS-Based Load Balancing to Multiple Standalone Concentrators

  • VCA Session and Platform-Aware IPsec Session Load Balancing

Step 3.
Incorporate Geographic HA Techniques: Lastly, once the concentrator cluster is highly available and properly load balancing IPsec sessions across the various concentrators in the cluster, administrators should evaluate the benefits of incorporating multiple, geographically redundant concentrator clusters into the RAVPN design. The two methods for providing Geographic HA between IPsec VPN clients and multiple IPsec VPN concentrators discussed in this chapter are:

  • Resolving a single concentrator hostname to multiple IPsec VPN concentrator public IP addresses, or, if VRRP/HSRP is used, multiple VRRP/HSRP Virtual Router IP addresses corresponding to different VRRP/HSRP groups.

  • Defining multiple IPsec VPN peers in the VPN clients IPsec profile.

In this chapter, we have covered the basic construction of a remote access VPN deployment, and applied the Local and Geographic HA concepts discussed in Chapters 6 and 7 to that construct to yield several highly available RAVPN design alternatives. In addition to RAVPN HA, we have embedded several effective means by which to load balance inbound client IPsec VPN sessions on a concentrator cluster. Lastly, the concept of multiple peers was introduced to provide the clients with Geographic HA by leveraging the use of geographically disperse and redundant IPsec VPN concentrator clusters.


Chapter 10. Further Architectural Options for IPsec

Up until this point, we've discussed major deployments and best practice design fundamentals for IPsec VPN deployments. Situations may arise in which IPsec network architectures are forced to vary somewhat. In this chapter, we will explore the forces that cause this variation in the fundamentals of IPsec VPN designs and some of the strategies that can be used to address these variations:

  • IPsec VPN Tunnel Termination "On-a-Stick"

  • In-Path vs. Out-of-Path Encryption

  • Separate Termination of IPsec and GRE (GRE-offload)

We will discuss each of these above design options in detail, including the drivers for selecting that specific variant of IPsec design. Case studies for each of the above will be inserted after introducing each design variant to illustrate that particular design alternative in practice.


IPsec VPN Termination On-a-Stick

When referring to technologies "on-a-stick," we are typically describing a scenario in which the device performing that technical function is attached to the network using a single interface. Common examples that can reside "on-a-stick" include router-on-a-stick, NAT-on-a-stick, and IPsec VPN termination-on-a-stick. In this section, we will discuss the latest of the three, focusing on IPsec Virtual Private Network (VPN) deployment scenarios in which one or both IPsec VPN tunnel termination points are attached out-of-path using a single physical interface for network connectivity.

IPsec with Router-on-a-Stick Design Overview

Although they do exist in many network deployments, cases in which administrators would opt for IPsec VPN tunnel termination "on-a-stick" are rare. Furthermore, of those existing cases, this design option is most commonly used as an alternative to accommodate other areas of the network architecture, rather than as an option that an administrator would choose over in-path IPsec VPN design options discussed previously.

IPsec termination on-a-stick refers to a deployment scenario in which the IPsec tunnel termination point is attached to the network using a single network interface. As such, this design option places crypto and IPsec functionality outside of the data path, as illustrated in Figure 10-1.

Figure 10-1. IPsec VPN Tunnel Termination "On-a-Stick"

[View full size image]

Figure 10-1 depicts a rare scenario in which IPsec using router-on-a-stick is required. Let's now discuss some of the circumstances that force this scenario to exist.

Single, Flatly Addressed L3 Domain

The key design driver here is that the cable modem and integrated bridge provides only one flat Layer 2 domain for devices to attach to. Although it is rare to see a VPN concentrator with one interface (most devices will ship with multiple interfaces to reside in-path), the bridged layout of this network design on the LAN side presents only one interface from a L3 perspective. In other words, a second interface on the VPN concentrator or router would yield no benefit, as one would be unable to assign it an IP address (it would conflict with the other interface connected to the bridged domain).

Lack of In-Path Design Options

The flat L3 network forces the IPsec VPN tunnel outside of the data path. Due to the fact that only one L3 interface can be attached to this bridged LAN, the encryptor is unable to reside inside the unencrypted data path.

Note

In-Path and Out-of-Path refer to the path of the unencrypted data flows. The encrypted data must flow through the IPsec VPN tunnel endpoint, even in "on-a-stick" implementations. In-Path versus Out-of-Path comparisons are discussed later in this chapter.

In this situation, IPsec VPN tunnel termination "on-a-stick" can be used to provide encryption for resources on the bridged LAN in Figure 10-1. This design option involves several components, some of which are unique to this design.

Single Interface to the Bridged LAN

This interface resides outside of the unencrypted data path. This requires that network resources traversing the VPN tunnel use the IP address of the IPsec VPN tunnel termination point that connects to the bridged LAN as their default gateways.

Crypto-Enabled Loopback Interface

This interface essentially serves as the crypto interface used to terminate the IPsec VPN tunnel. In Chapter 6, "Solutions for Local Site-to-Site High Availability," we discussed the use of a loopback interface to terminate the IPsec VPN tunnel for local High Availability (HA). In this situation, we will actually apply the crypto map to the loopback interface itself and loop encrypted traffic back onto the bridged LAN. Figure 10-2 displays this operation.

Figure 10-2. IPsec VPN Tunnel Termination On-a-Stick Using Loopback Interfaces for Crypto

[View full size image]

The process in Figure 10-2 is as follows:

1. | The IPsec VPN gateway (router-on-a-stick) in Figure 10-2 receives traffic from the bridged LAN. This traffic is in cleartext format.
2. | The router forwards the traffic to its loopback interface. The router inspects the traffic, matching it to a crypto ACL referenced in the crypto map that is applied to the crypto interface. The crypto engine applies the appropriate transform to the data matching the crypto ACL.
3. | The router forwards the traffic from step 2 on to the bridged LAN. The traffic is now in ciphered format, destined for the other end of the IPsec VPN tunnel.

Note

These steps described vary slightly from the ones outlined in the ensuing case study, as the case study includes IPsec VPN tunnel termination on-a-stick and Network Address Translation (NAT) on-a-stick, while the example we have just discussed includes only IPsec VPN tunnel termination on-a-stick without NAT.

Let's now take a look at a case study that will illustrate the operation of IPsec VPN tunnel termination "on-a-stick," including a real-world scenario in which this rare choice of IPsec design is used and working configurations.

Case Study: Small Branch IPsec VPN Tunnel Termination with NAT On-a-Stick

In this section, we will discuss a scenario in which a large company in retail wants to deploy secure, low-cost IP communications at each of its stores globally. At each branch location, there are server applications that collect and store customer information and financial data. That data must be reliably relayed to centralized data storage facilities in the company's data center, which is centrally located at the corporation's headquarters. For this reason, the customer is interested in a simple, low-cost solution for relaying this information from their many retail locations over the WAN to the data center at the corporate HQ. The corporate IT staff is interested in using an Internet managed service to provide the WAN connectivity to HQ to meet several critical business objectives, including:

  • Support for many branches makes a low-cost managed solution a business requirement, as scaling the solution to the many branches will drive costs up regardless of the per-unit cost.

  • Data confidentiality is a business requirement, as confidential customer information (account numbers, marketing data) is required to be transmitted across a public domain (the Internet).

  • Multiple point-of-sale machines and small-scale servers at the remote retail location require a low-cost LAN solution (multiple Ethernet ports at the retail branch).

The corporation's IT staff has been in contact with several service providers who will offer managed services that may meet the retailer's business requirement. The managed service offers basic IP connectivity using a cable modem at the remote retail location. The service also includes a workgroup switch for connecting devices together on the retailer's LAN, but the functionality of the switch is very basic and therefore does not include support VLANs or 802.1q trunking. Given the retailer's business objectives, these circumstances present design challenges at the retailer's remote locations, including the following:

  • Limited publicly routable IP addressing space at the remote retail locations

  • No NAT functionality integrated in to the managed service offering

  • Lack of capabilities for providing data confidentiality (such as using IPsec or crypto) between the remote retail location and the corporate HQ

  • Lack of VLAN awareness on the managed service switch at the remote retail location supports only one L3 broadcast domain at the remote retail LAN

The retailer agrees to a small pilot of the Internet service provider's (ISP's) managed service. As depicted in remote retail store LAN pilot topology in Figure 10-1, the corporate IT staff elects to use a small IPsec-enabled router, such as the Cisco 1845 ISR, to enable two key services at the remote retail locationData Confidentiality (IPsec) and NAT. Let us take a quick step-by-step look at the life of a packet on egress from the remote retail LAN en route to centralized corporate resources before diving in to some configuration examples for enabling data confidentiality and NAT in "on-a-stick" environments:

1. | Hosts and servers on the remote retail branch LAN initiate communications with centralized corporate resources using a default gateway of 192.168.1.2 on the 1845ISR.
2. | The 1845 receives the traffic from step 1 and matches it to an ACL referenced in a route-map that is used for policy routing. The policy route sets the output interface for traffic matching the ACL to router's loopback201 address.
3. | Before making the forwarding decision described in step 2, the 1845ISR applies the NAT rules defined on the router, as the traffic matches the ACL referenced in the NAT configuration on the router and was received on the inside NAT interface (FastEthernet0/0).
4. | The traffic is forwarded to the loopback201 interface based on the rules defined in the policy routing configuration on the 1845ISR. The privately addressed source IP is translated in to the loopback201 IP (the outside NAT interface), which is publicly routable.
5. | The traffic translated using NAT in step 4 matches a crypto ACL referenced by a crypto map applied to the loopback201 interface. Before forwarding the traffic, the 1845ISR processes the traffic with the appropriate transform.
6. | The 1845ISR forwards the crypto-processed transform to the opposite end of the IPsec VPN tunnel. The packet is now encapsulated with Encapsulating Security Payload (ESP), and the outer IP header is populated with publicly routable IP addresses (the IP addresses of the IPsec peers agreed upon in Phase 2 SA negotiation).

Data confidentiality is required across the WAN using IPsec VPN tunnel termination. The IPsec VPN gateway at the remote branch resides out-of-path, and is therefore considered to be deployed "on-a-stick." This out-of-path design option was selected for the retailer's pilot program due to the fact that the branch LAN switch is incapable of providing multiple L3 domains. As such, only one L3 domain is presented to the IPsec VPN-enabled router on-a-stick, supporting only a single L2 connection between the router and the switch.

Example 10-1 provides a configuration for the retail branch LAN's IPsec VPN gateway. The IPsec VPN gateway is configured to use the ESP-3DES with MD5 HMAC authentication on data sent to and received from the remote IPsec VPN gateway at 24.10.100.1, as illustrated in configuration lines 10 and 20, respectively. Note that, in line 20, the crypto map is applied to the loopback interface rather than a physical interface. It is important to note that the crypto map matches ACL 102 specifying the inside global IP address space as the source. This is because encryption occurs after NAT when the two are configured concurrently. As illustrated in Example 10-2, all traffic to be translated on-a-stick is policy routed to loopback 201. This enables traffic from the 10.0.0.0/8 address space on the retailer's LAN to be NAT'd between inside (e0/0) and outside (lo201) before being encrypted using the crypto map on loopback 201. Provided in line 26 is the crypto ACL used by the retail branch LAN VPN gateway. Note that the source IP address space is the inside global address space. This configuration is required for IPsec to properly agree upon consistent protected address space when negotiating a Phase 2 SA, as encryption occurs after NAT. If not properly configured with the correct addresses, a crypto ACL scope inconsistency can cause Phase 2 negotiation to fail.

Example 10-1. IPsec VPN Tunnel Termination "On-a-Stick" Using Logical (Loopback) Interfaces

C1845-VPN10-A#show running-config
Building configuration...
!
#<--Output Suppressedà
!
crypto isakmp policy 10
authentication pre-share
crypto isakmp key cisco address 24.10.100.1
!
crypto IPsec transform-set c10-on-a-stick esp-3des esp-md5-hmac
!
crypto map on-a-stick 10 IPsec-isakmp
 set peer 24.10.100.1
 set transform-set c10-on-a-stick
 match address 102
 !
 #<--Output Suppressedà
 !
 interface Loopback201
  ip address 201.1.1.1 255.255.255.0
  ip nat outside
  crypto map on-a-stick
 !
 #<--Output Suppressedà
 !
 access-list 102 permit ip 200.1.1.0 0.0.0.3 11.0.0.0 0.255.255.255
 !
 #<--Output Suppressedà

NAT on-a-stick supports IP communications with privately addressed devices across a publicly addressed infrastructure. In this case, the retailer has not been given enough publicly routable address space for all of the IP-enabled resources to communicate across the Internet. Therefore NAT must be used to translate the privately addressed IP addresses in to public ones so that they can be routed across the Internet to the retailer's data center at its HQ. Because there is only one connection between the IPsec VPN-enabled router and the remote retail site's LAN switch, like IPsec VPN tunnel termination, this service must also exist "on-a-stick." Example 10-2 provides a sample NAT on-a-stick configuration that the retail branch LAN IPsec VPN gateway uses in conjunction with its IPsec VPN tunnel termination configuration on-a-stick in Example 10-1.

Example 10-2. Network Address Translation "On-a-Stick" Using Logical (Loopback) Interfaces

C1845-VPN10-A#sh run
Building configuration...
!
#<--Output Suppressedà
!
interface Loopback10
 ip address 10.1.2.1 255.255.255.252
 ip nat outside
!
interface Ethernet0/0
 ip address 192.168.1.2 255.255.255.248 secondary
 ip address 10.1.1.1 255.255.255.0
 ip nat inside
 ip policy route-map on-a-stick
 half-duplex
!
#<--Output Suppressedà
!
ip nat pool public 200.1.1.1 200.1.1.4 prefix-length 29
ip nat inside source list 1 pool public overload
!
#<--Output Suppressedà
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
!
access-list 1 permit 10.0.0.0 0.255.255.255
access-list 101 permit ip any 200.1.1.0 0.0.0.7
access-list 101 permit ip 10.0.0.0 0.255.255.255 any
!
route-map on-a-stick permit 10
 match ip address 101
 set interface Loopback10
!
#<--Output Suppressedà

Once the appropriate configurations have been put in place, the retailer takes several measures to ensure that the operation of the IPsec VPN router on-a-stick is working correctly with NAT:

  • Verify that private addresses are being translated in to routable address space as in Example 10-3.

    Example 10-3. Verifying NAT "On-a-Stick" Operations

    C1845-VPN10-A#debug ip nat
IP NAT debugging is on
crvpn-3600-b#
*Mar  2 23:23:21.732: NAT: s=10.1.1.100->200.1.1.1, d=11.1.1.1 [400]
*Mar  2 23:23:21.748: NAT: s=11.1.1.1, d=200.1.1.1->10.1.1.100 [400]
*Mar  2 23:23:21.756: NAT: s=10.1.1.100->200.1.1.1, d=11.1.1.1 [401]
*Mar  2 23:23:21.768: NAT: s=11.1.1.1, d=200.1.1.1->10.1.1.100 [401]
*Mar  2 23:23:21.776: NAT: s=10.1.1.100->200.1.1.1, d=11.1.1.1 [402]
*Mar  2 23:23:21.792: NAT: s=11.1.1.1, d=200.1.1.1->10.1.1.100 [402]
*Mar  2 23:23:21.796: NAT: s=10.1.1.100->200.1.1.1, d=11.1.1.1 [403]
*Mar  2 23:23:21.812: NAT: s=11.1.1.1, d=200.1.1.1->10.1.1.100 [403]
*Mar  2 23:23:21.816: NAT: s=10.1.1.100->200.1.1.1, d=11.1.1.1 [404]
*Mar  2 23:23:21.832: NAT: s=11.1.1.1, d=200.1.1.1->10.1.1.100 [404]

  • Verify that Internet Key Exchange (IKE) and IPsec security associations (SAs) can be established between the device on-a-stick and the opposite endpoint of the IPsec VPN tunnel as in Example 10-4.

    Example 10-4. Verifying Phase 1 and 2 IPsec SA Establishment

    C1845-VPN10-A#show crypto isakmp sa
dst             src             state          conn-id slot
24.10.100.1     201.1.1.1       QM_IDLE              4    0

C3800-VPN10-A#sh crypto IPsec sa

interface: Loopback201
    Crypto map tag: on-a-stick, local addr. 201.1.1.1
    protected vrf:
    local ident (addr/mask/prot/port): (200.1.1.0/255.255.255.252/0/0)
    remote ident (addr/mask/prot/port): (11.0.0.0/255.0.0.0/0/0)
    current_peer: 24.10.100.1:500
      PERMIT, flags={origin_is_acl,}
     #pkts encaps: 14, #pkts encrypt: 14, #pkts digest 14
     #pkts decaps: 14, #pkts decrypt: 14, #pkts verify 14
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts compr. failed: 0
     #pkts not decompressed: 0, #pkts decompress failed: 0
     #send errors 1, #recv errors 0

      local crypto endpt.: 201.1.1.1, remote crypto endpt.: 24.10.100.1
      path mtu 1514, ip mtu 1514, ip mtu idb Loopback201
      current outbound spi: CD72F170

      inbound esp sas:
       spi: 0xF8F64DEB(4176891371)
         transform: esp-3des esp-md5-hmac ,
         in use settings ={Tunnel, }
         slot: 0, conn id: 2000, flow_id: 1, crypto map: on-a-stick
         sa timing: remaining key lifetime (k/sec): (4535979/1289)
         IV size: 8 bytes
         replay detection support: Y

      inbound ah sas:

      inbound pcp sas:

      outbound esp sas:
       spi: 0xCD72F170(3446862192)
         transform: esp-3des esp-md5-hmac ,
         in use settings ={Tunnel, }
         slot: 0, conn id: 2001, flow_id: 2, crypto map: on-a-stick
         sa timing: remaining key lifetime (k/sec): (4535979/1287)
         IV size: 8 bytes
         replay detection support: Y

     outbound ah sas:

     outbound pcp sas:
C1845-VPN10-A#show crypto engine connections active

  ID Interface            IP-Address      State  Algorithm           Encrypt  Decrypt
   4 Loopback201          201.1.1.1       set    HMAC_SHA+DES_56_CB        0        0
2000 Loopback201          201.1.1.1       set    HMAC_MD5+3DES_56_C        0       14
2001 Loopback201          201.1.1.1       set    HMAC_MD5+3DES_56_C       14        0

  • Verify that the negotiation of the IPsec VPN tunnel can be initiated from either endpoint, and that no conflicts reside with NAT at the remote retail branch running IPsec and NAT on-a-stick.


In-Path Versus Out-of-Path Encryption with IPsec

Design options that place the IPsec VPN tunnel termination endpoints directly in the data path refer to in-path IPsec VPN tunnel terminations. Figure 10-3 illustrates in-path versus out-of-path IPsec VPN design scenarios in which there is only one available interface for Demilitarized Zone (DMZ) access on the firewall. The administrator wants to encrypt certain traffic flows inbound through the firewall. However, for security reasons, all VPN traffic from and to the enterprise network must be encrypted and decrypted within the DMZ, hereby requiring an out-of-path design. If the firewall were able to terminate the IPsec VPN tunnels natively, without the use of an external IPsec VPN concentrator located in the DMZ, then an in-path design option (also illustrated in Figure 10-3) would be possible in this scenario.

Figure 10-3. In-Path and Out-of-Path Design Options with Single DMZ IPsec VPN Tunnel Termination

[View full size image]

The considerable majority of design options in today's IPsec VPN environments are in-path. For this reason, among others, it is very common to see network nodes such as routers and switches embed integrated IPsec crypto engines and hardware-based crypto accelerators. The key design benefit of an in-path design is the ability to process crypto traffic in the fast switching path. This design benefit greatly boosts the overall performance of the IPsec VPN. Additionally, it enables network designers to incorporate hardware accelerators to increase performance in the crypto switching path even further. There are limitations with the next design option, out-of-path, that force crypto switching in the process switching path, thereby precluding hardware acceleration design options.

In some scenarios, it may be necessary to place one or both IPsec VPN tunnel termination points outside of the data path. This is commonly referred to as "out-of-path" encryption. One such scenario that we've explored already is the use of IPsec tunnel termination on-a-stick. This scenario is also found when IPsec tunnels are terminated in firewalled environments, such as the one presented in Figure 10-4. In these scenarios, IPsec VPN termination points are typically located in a DMZ, which may require an out-of-path design.

Figure 10-4. In-Path and Out-of-Path Design Options with Dual DMZ IPsec VPN Tunnel Termination

[View full size image]

Out-of-Path Encryption Design Overview

Although out-of-path encryption options include IPsec VPN tunnel termination "on-a-stick," this subset of IPsec VPN design alternatives is not limited to that one option. Out-of-path design options can include a single interface, or they can include multiple interfaces. Figures 10-3 and 10-4 illustrate DMZ designs in which inbound IPsec VPN tunnels are terminated on concentrators in the DMZ. Note the comparison of the equivalent in-path design option also illustrated in both options.

Figure 10-3 places the IPsec VPN router on-a-stick. Although this option can be effective when required (e.g., due to limited available interfaces on the firewall, and so on), many on-a-stick scenarios require a loopback interface to operate correctly, forcing crypto traffic in to the process switched path.

Figure 10-4 illustrates an out-of-path design alternative that does not place the IPsec VPN tunnel termination point on-a-stick. Instead, this dual-DMZ design provisions dual uplinks from the concentrator to the firewall, enabling the IPsec VPN concentrator or gateway to switch all crypto traffic in the fast switching path, and to leverage any available onboard crypto hardware assist resources for increased performance.

Although there are ways of optimizing out-of-path design options for increased performance, in-path designs generally yield higher overall performance, as they eliminate the overall switching load of the system. Although the dual-DMZ design of Figure 10-4 yields some performance benefits over the single-DMZ design of Figure 10-3, both scenarios require the firewall to switch the packets at least twice (once in cleartext en route to the IPsec VPN gateway, and once in ciphertext inbound from the IPsec VPN gateway). The in-path design alternative would be to terminate the IPsec VPN tunnels on the firewall itself, or to use an integrated chassis-based solution with installed modules for firewalling and concentrating IPsec VPN tunnels.

Note

Examples of integrated solutions from Cisco Systems include the Catalyst 6500 line of switching platforms that support the Firewall Services Module (FWSM) and IPsec VPN Service Port Adapters (VPN SPA), and the Cisco Integrated Services Router that supports onboard IPsec hardware accelerators and IOS Stateful Firewalling.

Although in-path design options generally provide increased performance, and are generally more common, there may be design scenarios in which the needs of the network infrastructure require an out-of-path solution. This is commonly found in DMZ designs, such as the one illustrated in the case study described in the following section.

Case Study: Firewalled Site-to-Site IPsec VPN Tunnel Termination

A large marketing firm has increasingly relied on incoming data flows from partner organizations and feeds. As such, the organization is now revisiting its traditional strategy of accepting data feeds from those partners at the Internet-edge DMZ. The corporate IT department has proposed a pilot program to migrate connectivity between key partner organizations to a new extranet design currently in the planning process. The topology of the planned extranet project is illustrated in Figure 10-4.

Although the firm's business is increasingly reliant on communications from key partners using the extranet described in Figure 10-4, the corporation's IT security staff is still concerned that the extranet presents an attack vector if one of the partner networks were to be breached. It is therefore determined that the extranet will deploy statefully redundant firewalls to protect the network against attacks across inbound VPN tunnel traffic from partners. The firewall uses a dual-DMZ approach to address two technical design challenges in firewalled site-to-site IPsec VPN deployments:

  • First, IPsec (IP protocol 50) and Internet Security Association and Key Management Protocol (ISAKMP) (UDP Port 500) control plane traffic must be passed through (using a conduit or ACL) to the local point of IPsec VPN tunnel termination. Allowing such traffic through the firewall presents an attack vector for malicious network users if not managed properly.

  • Second, VPN traffic presented to the outside firewall interface is encapsulated in ESP or Authentication Header (AH). This renders the firewall incapable of making inspection and filtering decisions on the original packet, as it is presented as an encrypted payload. The firewall is therefore unable to determine whether or not the encrypted payload of the VPN traffic is carrying any malicious data.

Example 10-5 provides the firewall diagnostics illustrating the settings for out-of-path IPsec VPN tunnel termination on the extranet deployment illustrated in Example 10-4. The firewall's security levels and interface IP addresses are configured in lines 1 through 16, allowing data to freely flow from inside networks to outside networks but not vice versa unless the firewall has the required state information to allow return traffic. The inside interface of the firewall is configured to passively listen for Routing Information Protocol (RIP) updates from other RIP routers on the local segment. The only exception to this passive behavior is that the firewall is configured to advertise a single default route to the other RIP routers on the segment. The firewall's routing table is displayed in lines 2026. Note there is a static default route pointing to the VPN concentrator on the inside DMZ interface. This effectively forwards all outbound L3 traffic to the concentrator cluster for encryption over the IPsec VPN tunnel. Of critical importance is the NAT and ACL entries on the firewall. Lines 2734 show an active NAT ACL that is used for translating inside IP addresses in to the inner DMZ interface facing the inside interface of the VPN concentrator. Only traffic matching the ACL will be NAT'd on egress to the PIX. Subsequently, any traffic exiting the firewall that does not match this ACL will not be translated and forwarded to the inside network. This effectively hides all inside IP addresses from the traffic exiting the concentrator. Instead, presenting only one interface with multiple translations for original traffic matching the NAT ACL on the PIX (NAT Overload or PAT), effectively allowing for added security. The named ACL "vpn-group" is the ACL referenced by NAT instance 1, making it a NAT ACL. Traffic matching this ACL on received on the inside interface will be translated in to the IP information referenced in by the corresponding global instance. The global instance below (1) maps to traffic matching the NAT ACL above. The traffic matching the NAT ACL will therefore be translated to the IP address of the inner-inner interface on the firewall. The static shown in line 36 allows the outside extranet partner's IPsec VPN gateways to reach the privately addressed VPN tunnel termination point (192.168.1.1) directly attached to the firewall's outer-outer interface using a public IP address (200.1.1.3) within the IP address range assigned to the outside interface (200.1.1.0/24). The named ACL, "vpn-control," allows crypto control plane traffic through the firewall to the outer-outer interface. ISAKMP traffic (UDP port 500) (IP protocol 50) must be allowed to the concentrator to establish the appropriate SAs, and ESP must be allowed to transport encrypted traffic between the IPsec VPN tunnel endpoints. Note that, although this effectively pokes holes through the firewall, they do not go all the way through to the inside interface. This ACL works with the static translation above to limit access from traffic matching this ACL only to the concentrator on the outer DMZ. There is no exception or ACL on the inner DMZ interface allowing crypto control plane traffic through.

Example 10-5. Dual-DMZ Firewall Design for Extranet Edge IPsec VPN Tunnel Termination

crvpn-pix525-a# show nameif
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz-outer security51
nameif ethernet3 dmz-inner security52
crvpn-pix525-a# sh ip
System IP Addresses:
       ip address outside 200.1.1.1 255.255.255.0
       ip address inside 10.1.1.1 255.255.0.0
       ip address dmz-outer 192.168.1.2 255.255.255.0
       ip address dmz-inner 192.168.2.2 255.255.255.0
Current IP Addresses:
        ip address outside 200.1.1.1 255.255.255.0
        ip address inside 10.1.1.1 255.255.0.0
        ip address dmz-outer 192.168.1.2 255.255.255.0
        ip address dmz-inner 192.168.2.2 255.255.255.0
crvpn-pix525-a(config)# show rip
rip inside passive version 2
rip inside default version 2
crvpn-pix525-a(config)# sh route
        dmz-inner 0.0.0.0 0.0.0.0 192.168.2.1 1 OTHER static
        inside 10.1.0.0 255.255.0.0 10.1.1.1 1 CONNECT static
        inside 100.0.0.0 255.0.0.0 10.1.1.2 1 RIP
        dmz-outer 192.168.1.0 255.255.255.0 192.168.1.2 1 CONNECT static
        dmz-inner 192.168.2.0 255.255.255.0 192.168.2.2 1 CONNECT static
        outside 200.1.1.0 255.255.255.0 200.1.1.1 1 CONNECT static
crvpn-pix525-a# show nat
nat (inside) 1 access-list vpn-group1 0 0
crvpn-pix525-a# show access-list vpn-group1
access-list vpn-group1; 1 elements
access-list vpn-group1 line 1 permit ip 100.1.1.0 255.255.255.0 30.1.1.0
  255.255.255.0 (hitcnt=10)
crvpn-pix525-a# show global
global (dmz-inner) 1 interface
crvpn-pix525-a# show static
static (dmz-outer,outside) 200.1.1.3 192.168.1.1 netmask 255.255.255.255 0 0
crvpn-pix525-a# show access-list vpn-control
access-list vpn-control; 2 elements
access-list vpn-control line 1 permit esp host 200.1.1.2 host 200.1.1.3 (hitcnt=50)
access-list vpn-control line 2 permit udp host 200.1.1.2 host 200.1.1.3 eq isakmp
  (hitcnt=0)

In this dual-DMZ scheme, all IPsec VPN tunnel traffic is terminated in the outer DMZ. After the concentrator decrypts the traffic inbound across the IPsec VPN tunnel on the outer DMZ, it forwards the traffic back to the firewall on the inner DMZ interface in cleartext. Now that the packet is presented to the firewall in cleartext, the firewall is now capable of making another filtering decision based on the full contents of the packet. Figures 10-5 through 10-10 illustrate the required configuration of the VPN concentrators deployed in the design topology depicted in Figure 10-4.

The VPN concentrators can be configured for network connectivity via a console port and command-line interface (CLI). Once the concentrator is configured for network access, the VPN3000 concentrator GUI can be used to configure and manage the concentrator over either HTTP or HTTPS sessions. Figure 10-5 displays the VPN3060 IP address configuration for the concentrator cluster illustrated in Figure 10-4.

Figure 10-5. Dual-DMZ, Out-of-Path, VPN 3060 Concentrator IP Addressing

[View full size image]

VPN3000 concentrators support routing protocols, including Open Shortest Path First (OSPF), RIP, and static routing. Figure 10-6 illustrates the definition of a default static route on the VPN3060 concentrators depicted in Figure 10-4.

Figure 10-6. Dual-DMZ, Out-of-Path, VPN 3060 Concentrator Routing Table

[View full size image]

Figure 10-7 illustrates the configuration of the VPN3060's active IKE policies to use for authenticating Phase 1 SAs inbound from remote branch offices.

Figure 10-7. IKE Proposal Selection on the VPN 3060 Concentrator

[View full size image]

Although there are numerous preconfigured IKE proposals that can be activated on the VPN3060, they can be customized. Figure 10-8 provides an example of how to modify a preexisting IKE proposal on the VPN3060.

Figure 10-8. IKE Proposal Configuration/Modification on the VPN 3060 Concentrator

[View full size image]

Figure 10-9 displays the required IPsec peering configuration for a site-to-site IPsec VPN tunnel negotiation with the remote branch, which is, in this case, a small home office hardware VPN client with the IP address 200.1.1.2. Here, the IKE proposal "IKE-3DES-SHA1-DH2" is used for Phase 1 negotiation, and 3DES ESP transform ("ESP-3DES") with 160-bit SHA1 MAC authentication ("ESP/SHA/HMAC-160") is used for Phase 2 SA negotiation with 200.1.1.2.

Figure 10-9. Dual-DMZ, Out-of-Path, VPN 3060 IPsec VPN Tunnel Configuration (1 of 2)Peering, IKE, and Transforms

[View full size image]

Figure 10-10 provides a continuance of the screen capture provided in Figure 10-9, and also depicts the crypto-protected address space specification to use in the IPsec Phase 2 SA negotiated with 200.1.1.2. In this case, traffic originated from 192.168.2.2 to 30.1.1.0/24 is included in the crypto switching path.

Figure 10-10. (Figure 10-9 continued)Dual-DMZ, Out-of-Path, VPN 3060 IPsec VPN Tunnel Configuration (2 of 2)Protected Address Space Definition

[View full size image]

In the design topology illustrated in Figure 10-4 and the corresponding configuration examples presented in Figures 10-5 through 10-10, data is taken slightly out-of-path to the outer DMZ then injected back in-path on the inner DMZ. Although this type of design requires more processing overhead on the firewall, it is very popular and is in many cases the optimal design choice when increased security surrounding the VPN tunnel termination point is required. Alternatives such as the one described previously are the methods of choice for many Internet edge, WAN edge, and extranet edge designs.

Now that the firewalled dual-DMZ infrastructure has been deployed and the VPN concentrator is configured for site-to-site VPN tunnel termination from the extranet partners, the firm's IT staff takes several measures to verify the operation of the extranet infrastructure:

Step 1.
Verify that inside addresses are being translated to the inner-inner address+port. The debug trace provided in Example 10-6 is initiated by a ping from 100.1.1.1 to 30.1.1.1 (matching the NAT ACL in Example 10-5). We can verify from these debug traces that the source address is being translated to the inside DMZ interface (192.168.2.2) and also that return traffic is being untranslated accordingly.

Example 10-6. Verifying NAT Between Inside Addresses and the Inner-Inner Interface Address

crvpn-pix525-a# debug icmp trace
2241: ICMP echo-request from inside:100.1.1.1 to 30.1.1.1 ID=36 seq=0 length=80
2242: ICMP echo-request: translating inside:100.1.1.1/36 to dmz-inner:192.168.2.2/25
2243: ICMP echo-reply from dmz-inner:30.1.1.1 to 192.168.2.2 ID=25 seq=0 length=80
2244: ICMP echo-reply: untranslating dmz-inner:192.168.2.2/25 to inside:100.1.1.1/36

Step 2.
Verify that the private address allocated to the public concentrator address is being translated in to a publicly routable IP address on the outside interface. A ping from the extranet partner VPN gateway (200.1.1.2) to the outside address NAT'd to the VPN concentrator outside address (192.168.1.1) creates the following trace displayed in Example 10-7. We can determine that outside hosts are able to successfully use the outside address of 200.1.1.3 to reach the nonroutable concentrator outside address of 192.168.1.1

Example 10-7. Verifying Static NAT Between Outside IP Address 200.1.1.3 and the VPN Concentrator Address (192.168.1.1)

crvpn-pix525-a#debug icmp trace
2266: ICMP echo-request from outside:200.1.1.2 to 200.1.1.3 ID=58 seq=0 length=80
2267: ICMP echo-request: untranslating outside:200.1.1.3 to dmz-outer:192.168.1.1
2268: ICMP echo-reply from dmz-outer:192.168.1.1 to 200.1.1.2 ID=58 seq=0 length=80
2269: ICMP echo-reply: translating dmz-outer:192.168.1.1 to outside:200.1.1.3

Note

The debug trace previously requires that Internet Control Message Protocol (ICMP) traffic be allowed through the firewall from 200.1.1.2 to 200.1.1.3 using either an ACL or conduit. The IT staff inserts an entry in to the ACL permitting ICMP for troubleshooting purposes during initial install, then removes the ACE corresponding to ICMP before the extranet connection is committed in to production.

Step 3.
Verify negotiation of IPsec and ISAKMP SAs on the remote extranet peer. In the design scenario listed in Figure 10-4, a router running Cisco IOS is used to terminate the IPsec VPN tunnel on the extranet partner side. The diagnostic output supplied in Example 10-8 verifies encryption and decryption occurring in the crypto engine for SA's established with the extranet concentrator cluster.

Note

The tunnel definition is actually built to the PIX outside interface IP (200.1.1.3) that is translated to the concentrator's physical public IP (192.168.1.1). The static NAT entry configured on the PIX is listed in line 36 of Example 10-5.

Example 10-8. Verifying SA Establishment on the Remote Extranet Partner's VPN Gateway

crvpn-3600-e#show crypto engine connections active

  ID Interface            IP-Address      State  Algorithm           Encrypt  Decrypt
   2 Ethernet0/0          200.1.1.2       set    HMAC_SHA+DES_56_CB        0        0
2012 Ethernet0/0          200.1.1.2       set    HMAC_SHA+3DES_56_C        0        5
2013 Ethernet0/0          200.1.1.2       set    HMAC_SHA+3DES_56_C        5        0

Step 4.
Verify the successful negotiation of IPsec LAN-to-LAN Sessions (Phase 2 SA) on the IPsec VPN concentrator. Figure 10-11 verifies that there is an active IPsec VPN session on a VPN3060 concentrator in the cluster in the design presented in Figure 10-5.

Figure 10-11. Verifying SA Establishment on the Extranet DMZ Concentrator Cluster

[View full size image]


Separate Termination of IPsec and GRE (GRE-Offload)

In Chapter 3, "Basic IPsec VPN Topologies and Configurations," we introduced the need to encapsulate traffic to be included in the crypto switching path in generic routing encapsulation (GRE) prior to crypto processing, a technique we've referred to as IPsec+GRE. Until now, we've explored integrated design options in which IPsec and GRE processing both occurred on the same VPN platform. In this section, we will discuss situations in which it is more appropriate to separate the processing of IPsec and GRE on to different platforms, a technique referred to as IPsec+GRE with GRE-offload.

GRE-Offload Design Overview

The need to forward IP Multicast traffic in the crypto switching path is the most prominent driver for IPsec+GRE designs. This is because IPsec alone will not support the encrypted multicast traffic. However, if one were to encapsulate a multicast packet in GRE prior to encryption, this would present a unicast traffic flow (the GRE traffic flow, with a multicast payload) to the IPsec crypto engine. This enables IPsec to forward the unicast GRE packet to the opposite end of the tunnel, where the IPsec headers (ESP, AH, or both) are decapsulated before the GRE headers are decapsulated. This operation results in an IP multicast packet presented in cleartext to be forwarded in normal IP multicast forwarding path at the opposite end of the tunnel.

In previous chapters, we've discussed several design issues that GRE encapsulation prior to encryption presents, including the effect of tunnel fragmentation (Chapter 5, "Designing for High Availability") and the impact on geographic HA (Chapters 5 and 7, "Solutions for Geographic Site-to-Site High Availability"). These design considerations, however, apply to both consolidated and separated termination of IPsec and GRE in IPsec+GRE solutions. But, there are two key design considerations that mandate separate termination of IPsec+GRE tunnel terminationlack of support for GRE on the VPN gateways and insufficient performance for GRE on the IPsec VPN gateways.

Lack of Support for GRE Processing

In many circumstances, IPsec VPN-enabled devices will not support the termination of GRE. One such example in which IPsec VPNs are commonly terminated on IPsec VPN devices that do not support GRE is when PIX firewalls are used as the IPsec gateways. This is a perfectly valid solution for IPsec VPN tunnel termination, but in situations in which IPsec+GRE is required, a separate device is required to perform the GRE encapsulate/decapsulate operations on the firewall inside interface or DMZ. Figure 10-12 illustrates a GRE-offload scenario with PIX used as the IPsec VPN tunnel termination point.

Figure 10-12. PIX IPsec VPN Tunnel Termination with GRE-Offload

[View full size image]

Low GRE Performance

IPsec+GRE is driving increased GRE performance in many integrated routing and switching platforms that support IPsec VPN tunnel termination. Many of today's midrange routers and IPsec appliances still do not support hardware-based GRE forwarding. However, GRE performance is a critical design requirement in large-scale site-to-site IPsec VPN tunnel concentration platforms. It is therefore very common to see IPsec VPN processing and GRE tunnel processing separated in this type of environment, as illustrated in Figure 10-13.

Figure 10-13. Large-Scale Site-to-Site IPsec+GRE VPN Tunnel Concentration with GRE-Offload

[View full size image]

In Figure 10-13, IPsec is processed in hardware with high-speed IPsec VPN SPA included in the Catalyst 6500 switches at the enterprise campus WAN edge. The GRE processing is offloaded to the 7304 VXR routers behind 6500s so as to present all multicast traffic on egress to the branch in a unicast format to the 6500 VPN SPAs responsible for crypto processing. This design scenario is a very popular option, yielding high-speed hardware-assisted crypto forwarding for both unicast and multicast GRE payloads. The following case study aims to reinforce this design, in a real-world enterprise deployment.

Note

The Internet Engineering Task Force (IETF) is current working on a draft for encrypted multicast forwarding technique called Group Domain of Interpretation (GDOI) that enables native IPsec (without GRE) to support encryption of multicast IP flows. It further enables the multicast fanout to occur after encryption, which greatly decreases the load on the crypto engine relative to an IPsec+GRE scenario. GDOI is outside of the scope of book, but more information on IPsec, GDOI, and IP Multicast forwarding can be found within the following Internet draft for RFC 3547 located here:

http://tools.ietf.org/wg/msec/draft-ietf-msec-gdoi/rfc3547.txt

Case Study: Large-Scale IPsec VPN Tunnel Termination with GRE Offload

A large retail bank currently employs multiple large-scale WAN aggregation hubs for its thousands of retail branch offices scattered across the nation. Although the WAN edge deployments all follow the same design layout illustrated in Figure 10-13, the bank's IT staff has decided on multiple Internet-edge deployments located in Charlotte, Seattle, and Chicago to concentrate inbound WAN connectivity for the branches located in the eastern, western, and central United States, respectively. This offers the firm a measure of increased scalability and resiliency to disaster recovery over a consolidated single-site design.

The bank had decided to expand its service offering some time ago by purchasing an investment-banking arm and a private equity arm. In order to increase workforce flexibility, and expand the geographic presence of these services, the bank employs these staff members at remote locations from time to time. One key service that these professionals rely on is the timely and accurate feed of stock quotes using an IP multicast stock quote server application residing in one of the organization's data centers in Dallas, Texas. The multicast traffic must therefore be confidentially transmitted from the data center across the WAN links to the remote branch locations. As such, multicast data is required to be encapsulated in GRE prior to being encrypted in IPsec, a technique we've previously referred to as IPsec+GRE.

The typical bank branch is capable of terminating the IPsec+GRE traffic sequentially on the same IPsec VPN gateway. Therefore, a consolidated point of termination for IPsec and GRE tunnels is employed at the bank branch. However, due to sheer number of branches terminating their WAN connections at the three Internet-edge locations, scalability problems have presented themselves with a consolidated termination approach:

  • The encryptor at the headend relies on IPsec hardware acceleration to process all of the traffic inbound from the WAN in the crypto switching path. Lack of support for GRE hardware acceleration causes a bottleneck in the switching path when encapsulating/decapsulating the packets in GRE (IP traffic is being encrypted/decrypted faster than it can be encapsulated/decapsulated in GRE).

  • The number IPsec and GRE tunnels terminated on the same platform are overrunning the WAN link aggregation platforms.

For these reasons, the firm decides to make some key alterations to its Internet-edge design using GRE-Offload. First, the IT staff has decided to increase the crypto switching capacity at the headend by introducing newer crypto hardware assist modules to its current platforms. The existing platforms, however, will not process the GRE traffic in the fast switching path. As such, the IT staff has decided to make a complementary investment to their new crypto processing hardware by investing in newer switching engines with onboard crypto hardware assist processors. Lastly, the firm has decided upon a staged update of its branch platforms to include increased crypto processing power. These branch platforms do not require GRE processing in hardware, as GRE scalability limitations were only being reached at the aggregation point of the IPsec+GRE VPN tunnels, not on the branches themselves. These changes all culminate in an Internet-edge design that follows the topology illustrated in Figure 10-13. Additionally, the firm decides to implement the following features in to the platform-specific design elements of its larger IPsec VPN architecture:

  • Dynamic Crypto Maps

  • IKE Extended Authentication

  • Separate Encrypted and Cleartext Firewall Paths

  • High Speed GRE Tunnel Termination for GRE Offload

Dynamic Crypto Maps and GRE-Offload

Dynamic crypto maps are used on the headend platforms aggregating the IPsec VPN tunnels. This allows for better management of the SADB on the headend platforms. It also allows for decreased management of peering sessions to the branches as they are moved, added, or changed. Note that this option does not use Tunnel Endpoint Discovery (TED), and therefore only the branch routers can initiate the establishment of an IPsec VPN tunnel.

It is important to consider the administration and configuration management differences between a traditional IPsec+GRE headend configuration and an IPsec+GRE configuration with GREOffload. With a traditional IPsec+GRE scenario in which both IPsec and GRE configuration occurs on the same box, the addition of a new IPsec+GRE tunnel on the IPsec+GRE headend forces the configuration to be changed regardless of whether dynamic crypto maps are used or not. The separation of IPsec and GRE configurations on IPsec+GRE changes the administration requirements in a GRE-Offload deployment. Although the configuration of the GRE headend router must be changed whenever an IPsec+GRE tunnel is added in an IPsec+GRE Offload scenario, dynamic crypto maps can be used on the router terminating the IPsec portion of the IPsec+GRE headend to eliminate the need to change the configuration of the crypto headend when a new IPsec+GRE tunnel is added. This design element of the IPsec with GRE-Offload configuration therefore eliminates the opportunity for configuration or administration errors during maintenance windows.

Tip

Dynamic Multipoint VPN can eliminate configuration changes on the headend router further. Like IPsec+GRE Offload, DMVPN employs the use of dynamic crypto maps to negate the need to alter the crypto configuration on the headend. In addition, DMVPN employs NHRP to provision the GRE portion of the IPsec+GRE tunnel dynamically. DMVPN headend configuration is therefore considered to be "touchless" when deploying new IPsec+GRE tunnels. We will discuss DMVPN in greater detail in Chapter 7, "Solutions for Geographic Site-to-Site High Availability."

Example 10-9 provides several key configuration elements required for IPsec+GRE with IKE x-Auth. First, the two ends of the IPsec VPN tunnel must agree on parameters used to authenticate the IKE channel during Phase 1 negotiation. The IKE policy (10) used to accomplish this task is displayed in lines 1-5 of Example 10-9 following. In this case, an added layer of authentication is used to authenticate the IKE channel against a TACACS+ database. This is known as IKE x-Auth and is commonly referred to as IKE Phase 1.5 negotiation (Example 10-10). The dynamic map provided in lines 10 and 11, "c10-iedge-dyn," references the transform set provided in line 8, "c10-iedge-trans," that defines the cryptographic transforms to be used in the Phase 2 SA. This dynamic crypto map is then bound to a static crypto map defined in configuration lines 13-14, which is then applied to the crypto interface with configuration line 21.

Example 10-9. Dynamic Crypto Map Configuration on IPsec+GRE Crypto Headend Platform

crypto isakmp policy 10
 encr 3des
 authentication pre-share
 group 2
!
crypto isakmp key c10-iedge address 192.168.0.0 255.255.0.0
!
crypto IPsec transform-set c10-iedge-trans esp-3des esp-md5-sha
!
crypto dynamic-map c10-iedge-dyn 10
 set transform-set c10-iedge-trans
!
crypto map c10-iedge-stat local-address Loopback1
crypto map c10-iedge-stat 10 IPsec-isakmp dynamic c10-iedge-dyn
!
interface Serial0/0
  ip address 200.1.1.1 255.255.255.252
  encapsulation frame-relay
  frame-relay interface-dlci 102
  frame-relay lmi-type ansi
  crypto map c10-iedge-stat

IKE Extended Authentication (X-Auth)

IKE x-Auth provisions another layer of authentication of the IKE SA using a unique username/password on a centrally managed authentication, authorization, and accounting (AAA) server using either TACACS+ or RADIUS. This design option enables the enterprise to manage preshared keys (PSKs) used during x-Auth more granularly, eliminating issues with peer eviction from the group. IKE x-Auth is discussed in greater detail in Chapter 12, "Solutions for Handling Dynamically Addressed Peers." The crypto headend platforms use the IKE X-Auth configuration supplied in Example 10-10.

Example 10-10. IKE X-Auth Configuration on IPsec+GRE Crypto Headend Platform

aaa authentication login vpn-auth group radius
aaa authorization network vpn-auth group radius
!
crypto map extranet client authentication list vpn-auth
crypto map extranet isakmp authorization list vpn-auth
!
radius-server host 10.1.20.100
radius-server key cisco

Firewalled Cleartext Traffic

There are two paths through the firewall, allowing cleartext traffic to flow directly from inside to outside interface, and allowing crypto-switched traffic to flow bidirectionally between the outside and DMZ interfaces on the firewall. This design option allows for increased security for cleartext traffic, while allowing branches to establish IPsec tunnels through the firewall (hereby leveraging the dynamic crypto map on the headend IPsec VPN router). Example 10-11 provides the sample configuration for the IPsec+GRE deployment in Figure 10-13.

Example 10-11. Firewall Configuration Example for IPsec+GRE Concentration in DMZ

crvpn-pix525-a(config)#nameif eth0 outside 0
crvpn-pix525-a(config)# ip address outside 200.1.1.10 255.255.255.0
crvpn-pix525-a(config)# nameif eth2 dmz-vpn 50
crvpn-pix525-a(config)# ip address dmz-vpn 192.168.1.100 255.255.255.0
crvpn-pix525-a(config)# nameif eth1 inside 100
crvpn-pix525-a(config)# ip address inside 10.1.1.1 255.255.255.0
!
crvpn-pix525-a(config)# access-list VPN permit udp any host 200.1.1.1 eq isakmp
crvpn-pix525-a(config)# access-list VPN permit esp any host 200.1.1.100
!
crvpn-pix525-a(config)# access-group VPN in interface outside
!
crvpn-pix525-a(config)# static (dmz-vpn,outside) 200.1.1.100 192.168.1.100

High-Speed GRE Tunnel Termination for GRE-Offload

GRE tunnel termination is offloaded from the crypto headends to platforms that can encapsulate and decapsulate the GRE tunnel traffic in the fast switching path. In this case, as illustrated in Figure 10-13, the enterprise has elected Catalyst Supervisor 720 switching engine on their Internet-edge distribution switch pair to aggregate termination of the GRE tunnels from the Branch routers.


Summary

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

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

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

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


Part III: Advanced Topics

Chapter 11 Public Key Infrastructure and IPsec VPNs

Chapter 12 Solutions for Handling Dynamically Addressed Peers


Chapter 11. Public Key Infrastructure and IPsec VPNs

A Public Key Infrastructure (PKI) entails a system of cryptographic endpoints that use an infrastructure of trusted resources, such as Certificate Authorities (CAs) and Registration Authorities (RAs), to facilitate a cryptographic transaction in a trusted manner. In large enterprise-class IPSec VPN designs, the burden of key management can be overwhelming. When the number of cryptographic endpoints scales upwards, so does the need to for a centralized, scalable method of key management between the cryptographic endpoints, or in this case, between the IPSec VPN gateways. A PKI can be used in varying types of cryptographic solutions. However, in the context of IPSec VPN deployments, the PKI entails the following elements:

  • The cryptographic endpoints participating in the PKI are IPSec VPN gateways.

  • The resource trusted by the cryptographic endpoints of the PKI is the PKI Certificate Authority (and optionally, a system of Registration Authorities).

  • The secure transaction that needs to be facilitated in a trusted manner is the exchange of public keys between the cryptographic endpoints for authenticating and encrypting the IKE SA.

Using the elements listed in the bulleted list above, PKIs present a comprehensive and scalable design option for secure key management in large-scale IPSec VPN deployments. Cisco IPSec VPN technologies support PKIs using the RSA Signatures method of IKE authentication, which describes an asymmetric authentication and encryption scheme used in the negotiation and operation of Phase 1 SAs. In this chapter, we will discuss a brief history and overview of PKI, then proceed to discuss the advantages to deploying IPSec VPNs using the RSA Signature method of IKE authentication in a PKI architecture.


PKI Background

Thus far, we've explored the concepts of symmetric key and asymmetric key encryption as they pertain to IPSec and various IPSec designs. Asymmetric key encryption leverages PKI to reinforce the community of trust within a network of cryptographic endpoints and other cryptographic elements, such as certificate authorities and registration authorities. Now, we will take a deeper look at asymmetric key encryption technology as it pertains to public key infrastructures (PKI).

Lenin once said that "trust is good, but control is better"he would have appreciated the need for asymmetric key encryption. Public key cryptography was born from the concept of controlling issues surrounding trust between two cryptographic endpoints that symmetric key encryption itself did not address. Remember that in symmetric key encryption, two cryptographic endpoints must share the same encryption key, since that key is also used for decryption. The integrity of this cryptographic operation relies on the security of the exchange of symmetric keys between the cryptographic endpoints. Therefore, the control of trust in a symmetric key encryption scheme lies on the secure channel over which the keys are exchanged, in addition to the strength of the keys themselves. Public key cryptography shifts the control of trust away from the secure channel of key exchange onto the generation of the asymmetric keypaironly a public key is exchanged freely, while the corresponding private key is not.

In 1976, Whitfield Diffie and Martin Hellmann introduced the concept of public key cryptography in their publication entitled "New Concepts in Cryptography." Their concept described an asymmetric cryptographic operation, outlining the use of two keysa public key used only for encryption and a private key used only for decryption. The two keys are mathematically related, but related in a way such that it is computationally infeasible to derive one key from the other. Additionally, information encrypted with a public key can only be decrypted using the corresponding private key. This cryptographic concept moves control over the security of cryptographic keys away from the manner in which they are exchanged and into the derivation of the keys itself. Central to this concept is the fact that the public key of an asymmetric keypair can be freely distributed without compromising the confidentiality or integrity of encrypted communications.

Note

Although asymmetric cryptography provides a more secure framework for key management and exchange than that of a traditional symmetric key cryptographic operation, there are still trust and authentication issues inherent to pure asymmetric cryptography. We will discuss these issues as they pertain to RSA Encryption and IKE. We will then discuss the RSA Signature method of IKE authentication and how PKIs can be used effectively to address issues of trust and control in asymmetric cryptographic systems.

Consider the example in Figure 11-1, where Caroline intercepts the public key that James tries to send to Charlie so that Charlie can encrypt messages to James. Because the public key only encrypts information, Caroline cannot use the key to decipher encrypted communication between James and Charlie. Additionally, because James uses strong cryptographic keys, which are refreshed periodically, Caroline is not able to derive James' private key from the public key that she has intercepted.

Figure 11-1. What Can Be Done with a Compromised Public Key?

[View full size image]

Although PKI does eliminate the need for authenticated, confidential distribution of symmetric keys, there must be additional mechanisms to enforce trust amongst cryptographic endpoints. As we have discussed, an attacker cannot do as much damage with a compromised public key as they could do with a compromised symmetric key. They could, however, have an impact in the authenticity of messages within the network. Because of this, there need to be additional measures to ensure that public keys are only exchanged among trusted cryptographic elements. Two measures that we have explored thus far, RSA encryption and Diffie-Hellman key exchange, have these elements of trust built into the cryptographic algorithm itself. Others rely on PKIs that use Certificate Authoritiescentral, trusted, repositories for maintaining keys with authentication and integrity.

Consider again the example in which Caroline intercepts a public key en route from James to Charlie. Although Caroline is unable to decrypt information from James and Charlie, she is still capable of using the public key maliciouslyshe could, for example, now use James' public key to encrypt information and send it to James as if she were Charlie.

Note

An attack scenario in which a malicious party inserts themselves in between two or more communicating partners to manipulate and eavesdrop on data in transit is commonly referred to as a man-in-the-middle attack. Recall that this attack was discussed in the scenario described in Figure 2-9 in Chapter 2, "IPsec Fundamentals."

How can James be certain that the information that he decrypts with is private key is authentic with preserved integrity knowing that his public key was distributed freely and openly? There exists a need for additional methods of data authentication and data integrity that deliver this level of trust, which is what PKI is all about.


PKI Components

PKIs employ a suite of cryptographic devices that ensure that public keys are managed securely. These devices work in tandem with to perform a wide array of functions relevant to managing public key distribution, including the following:

1. | Authenticating and registering cryptographic endpoints
2. | Verifying the integrity of public keys
3. | Authenticating requests for stored public keys
4. | Securely issuing public key certificates
5. | Revoking public keys that are no longer valid
6. | Maintaining public key revocation information (CRL) and distributing the information (via CRL issuance or responding to Online Certificate Status Protocol [OCSP] messages)
7. | Securely storing valid public keys

We will now explore the function of each of these PKI elements, and then we will walk through the life of a PKI certificate and explore some working scenarios involving cryptographic endpoints and PKI.

Public Key Certificates

The goal of an asymmetric key exchange is to securely distribute the public key to a party who wants to transmit (encrypt) data to the receiving (decrypting) party. A PKI helps to facilitate this key exchange securely while ensuring authenticity of both exchanging parties. The first step in this exchange is the creation of a public key certificate. A public key certificate can correspond to any node that can be referenced in the subject field of the public key certificate.

Note

PKI certificates in today's cryptographic network follow the ITU-T standard formatting for X.509v3 certificates. X.509v3 certificates will be used when discussing PKI examples throughout the remainder of this chapter.

The public key certificate is generated by the certificate authority (CA). In order for the CA to generate the public key certificate for the corresponding cryptographic endpoint, the endpoint must first enroll with the CA. The process of enrollment includes registration, initialization, and certification of the cryptographic endpoint with nodes in the PKI, such as registration authorities (RAs) and CAs. We will use the following list to explore the process of enrollment within a PKI:

1. | The cryptographic endpoint registers with the CA or RA. During this process, the cryptographic endpoint makes its identity known to the certificate cuthority. The certificate cuthority will authenticate the cryptographic endpoint, issuing its public key to the cryptographic endpoint pending the success of that authentication.
2. | The cryptographic endpoint begins the initialization phase by generating a public/private keypair (if it has not already done so). The public key of that keypair is forwarded to the certificate authority.
3. | The CA signs the public key certificate with its private key to create a public key certificate for the cryptographic endpoint. Note In public key cryptography, the private key is normally used for decryption, and the public key is normally used for encryption. When applying a digital signature, the opposite is trueprivate keys are used for encryption and public keys are used for decryption.
4. | Cryptographic endpoints can now request the public key certificate from the cryptographic endpoint described above. They can use the CAs public key (obtained in Step 1) to decrypt the public key certificate to obtain the appropriate public key.

Registration Authorities

In many instances, the CA in a PKI will provide all of the PKI services needed to manage the public keys within the network. However, there are instances in which a CA may delegate tasks to one or more registration ruthorities (RA). The primary task that a CA may delegate to an RA is the verification and validation of the identity of the cryptographic endpoint that is attempting to use the PKI. There are, however, other functions that a CA may also delegate to an RA, including the following:

  • Verification that a cryptographic endpoint attempting to enroll a public key with the CA also has the appropriate private key that is to be used in conjunction with the public key (proof of possession)

  • Generation of the public/private keypairs to be used in the initialization phase of the enrollment process

    Note

    Cisco cryptographic endpoints support the RSA signature method for PKI. In this process, the RSA keypair is generated locally on the cryptographic endpoint, after which the endpoint attempts to enroll the public key with the CA.

  • Validation of public key parameters

  • Indirect issuance of Certificate Revocation Lists (CRL)

Although the RA is capable of offloading many critical PKI functions from the CA, an RA can only compliment a CAit can never replace it. The CA is the central focus of a PKI, and it is the only device in the PKI that is capable of signing public key certificates from cryptographic endpoints.

Certificate Revocation Lists and CRL Issuers

CRLs exist to tell cryptographic endpoints which public key certificates are no longer valid within a PKI. This function is critical to maintaining the integrity of the PKI, especially as it pertains to the freshness of the public keys used by cryptographic endpoints. Public keys that are renewed or expire periodically provide an additional measure of security to the PKI, since they give attackers less time to compromise a public key and deploy it maliciously.

Public key certificates can be rendered invalid for a variety of different reasons. For example, an administrator can manually instruct a CA to revoke a public key certificate, or a certificate could be rendered invalid before the expiry of the timeout field within the certificate itself.

Tip

ITU-T X.509v3-compliant certificates must include a field called "validity period." This field specifies the time range in which the certificate is considered valid. It is critical that the network time settings on the routers, CAs, and RAs are synchronized such that the validity period is accurately populated within the PKI's public key certificates. Otherwise, problems relating to PKI usage could arise. The format of an X.509v3-formatted certificate is illustrated in Figure 11-2 later in this chapter.

Figure 11-2. An ITU-T X.509 Certificate

[View full size image]

CAs normally maintain the CRL in a PKI. The maintenance and issuance of the CRL, however, can be delegated to another entity within the PKI, such as an RA. Once issued to a cryptographic endpoint, the CRL is stored locally on that endpoint. The endpoint can then make the appropriate decisions regarding public key certificate usage by cross-referencing the locally stored CRL.

Tip

CRLs can grow to be quite large, which presents a problem on cryptographic endpoints that are memory constrained. OCSP was developed to help mitigate this issue on memory-constrained devices. OCSP is covered in further detail later in this chapter.

Certificate Authorities

A CA represents the central resource of trust in a PKI. This is because the CA is the only element within the PKI that can issue public key certificates to cryptographic endpoints. A PKI does not have to have only one CA. PKIs can set up CAs redundantly or in a hierarchy of trust, in which multiple CAs are branched off of a trusted root CA. These two PKI topologies are illustrated in case studies at the end of this chapter.

CAs are also usually responsible for maintaining the CRL and typically serve as the CRL Issuer. Although a CA may delegate CRL issuance or one of many more responsibilities to one or more RAs, the CA can assume responsibility for all of these functions such that an RA is not needed; the CA is capable of performing all of the tasks that we have discussed previously.

PKI Cryptographic Endpoints

PKI was designed to scale asymmetric key encryption networks to include a variety of different cryptographic endpoints. As such, not only will network nodes oftentimes serve as cryptographic endpoints in a PKI, but workstations, applications, and other devices that live on the periphery of an IP network will also subscribe to the PKI. Therefore, a PKI cryptographic endpoint can be any host, server, network element, or peripheral device that wants to talk to another IP-enabled PKI cryptographic endpoint. Of course, these cryptographic endpoints must all be enrolled with the CA of the PKI, and they must also be able to obtain public key certificates for the PKI cryptographic endpoints that they want to encrypt data towards. We will now explore the process that cryptographic endpoints follow when setting up encrypted communications between one another in a PKI, by stepping through the life of a certificate.


Life of a Public Key Certificate

The life of a public key certificate in a PKI depends largely on the implementation and design of the PKI itself. For example, the life of a certificate would change if one were to offload PKI functionality from a CA to a series of RAs. Likewise, the life of a certificate would change if one were to deploy a hierarchy of CAs, as opposed to using a single CA. However, the high-level process of creating and obtaining public key certificates is fairly consistent. Implementation-specific considerations are covered later in the chapter, but to fully appreciate them, we must first understand the general process of creating and obtaining public key certificates.

RSA Signatures and X.509v3 Certificates

RSA signatures are a form of Digital Signature, the operation of which is described previously in this chapter and in Chapter 2, "IPsec Fundamentals." RSA signatures combine the strength of a standard digital signature with the strength of the RSA encryption algorithm, also described above, to yield an RSA signature. Crypto-enabled network devices oftentimes will use RSA signatures when exchanging X.509-based certificates with a X.509 compliant certificate authority. Note that, unlike Internet Security Association and Key Management Protocol (ISAKMP) authentication designs that use preshared keys, the RSA signatures authentication method uses an RSA keypair.

ITU-T X.509 certificates and certificate authorities were developed to aid administrative burden in asymmetric cryptographic deployments through leveraging a central point of administration, or a trustpoint, for cryptographic endpoints to register their public keys and to obtain the public keys of their peers. Such a trustpoint is commonly referred to as a certificate authority. In order to effectively exchange this information, the certificate authority must communicate certificates in a standard format that is agreed upon with by its peers. ITU-T X.509-formatted certificates are commonly accepted as the standard for this type of public key cryptosystem. Figure 11-2 illustrates the format of an X.509-formatted certificate.

Certificate authorities allow network administrators to effectively manage large-scale crypto deployments by concentrating the administration of public key distribution into a single source. In doing so, administrators can be assured that keys are exchanged with authentic sources and destinations.

Note

The use of CA-based PKI does not enhance the level of confidentiality exchanged in an asymmetric key crypto deployment. It does, however, enforce data authentication in a fashion that allows for enhanced scalability in the number of encrypting/decrypting peers.

The following sequence illustrates the process of two endpoints, James and Charlie, communicating with one another using the RSA-signatures method of IKE authentication, as illustrated in Figure 11-3:

1.
James and Charlie request the CA's certificate. They optionally confirm the authenticity of the CA by verifying its fingerprint (manually) and install the CA's certificate, including its public (decryption) key.

2.
James and Charlie enroll with the CA upon completion of Step 2. During this process, they forward their public RSA key to the CA.

3.
When James and Charlie enroll with the CA, their public keys are received by the CA, then digitally signed with the CA's private key, as shown in Figure 11-4, resulting in a public key certificate for both James and Charlie.

Figure 11-3. Certificate Enrollment Procedure Using RSA Signatures and X.509 Certificates

[View full size image]

Figure 11-4. CA Signs the X.509 Certificate

[View full size image]

4.
The CA forwards the James and Charlie their CA-signed public key certificates, which are stored locally on both James and Charlie for future ISAKMP Phase I exchanges with other endpoints in the PKI that use the RSA-signatures method of authentication.

5.
When James and Charlie want to initiate ISAKMP Phase I negotiation with one another, they forward their CA-signed RSA public key certificates to one another.

6.
James and Charlie then use the CA Public Key (obtained in Step 1), to verify the CA's digital signature (computed in Step 2) on the public key certificates they receive from one another in Step 5. This is displayed in Figure 11-5. If the CA's certificate is verified successfully, then James and Charlie can be assured that the public keys were obtained from authentic sources and that their integrity has been preserved.

Figure 11-5. Verification of the CA-Signed Certificate

[View full size image]

7.
James and Charlie can now use each other's public keys to encrypt communications between each other. Note that James and Charlie's private keys have been kept private throughout this exchange, ensuring confidentiality between the parties.

Note

Encryption with RSA signatures is only used for IKE. A Diffie-Hellman shared secret key is negotiated over the IKE channel encrypted with the RSA signatures. The IPSec SA then uses the Diffie-Hellman shared secret key to encrypt data between the two endpoints.

Because only authentic endpoints have the CA public key, all of the authentic endpoints receiving a CA-signed public key certificate can be assured that the enclosed public key is authentic if the CA's signature is successfully validated. Additionally, only authentic cryptographic endpoints, such as James and Charlie in this case, can use their private keys to decrypt communications between one another.

In the preceding exchange, James and Charlie will enroll using Simple Certificate Enrollment Protocol (SCEP) as defined by the X.509 standard. The transport used to distribute certificates in the exchange described above using a client/server application such as HTTP, FTP, or LDAP. Cisco Systems manufactures a full set of network devices and appliances that utilize X.509-based PKI cryptosystems that leverage protocols such as HTTP for certificate transport, including firewalls, intrusion detection systems, routers, switches, and VPN concentrators.

Generating Asymmetric Keypairs on Cryptographic Endpoints

The main component of a public key certificate is the public key itself. Because of this, cryptographic endpoints must generate asymmetric keys, which would include the public key, before a public key certificate can be created. As we have discussed before, the effectiveness of a public key cryptosystem depends on the difficulty of deriving a private key from a compromised public key. Therefore, the effectiveness of a public key cryptosystem is directly related to the strength, or modulus, of the asymmetric keypair itself. Most Cisco devices will support RSA keys modulus sizes between 512 and 2048.

The stronger the keys, the harder it is to compromise the keypair. The tradeoff in selecting a large key modulus is that they consume more computational resources when ciphering messages. Additionally, a larger key modulus consumes more computational resources during the generation of the keys themselves.

Registration and Endpoint Authentication

The life of a public key certificate begins when a cryptographic endpoint registers with the PKI. On Cisco devices, this process is initiated when the device is configured with the CA IP and certificate path. When a device attempts to enroll with the CA, an optional step can be executed to verify the authenticity of the cryptographic endpoint before it is registered with the PKI.

Authenticating cryptographic endpoints during the registration phase can be bypassed on certain CA implementations. For example, a Microsoft Windows 2000 server running Certificate Services can be configured to automatically issue the CA certificate to the cryptographic endpoint without authentication. Alternatively, Windows 2000 Server can also be configured to wait until the CA administrator manually examines the request from the endpoint and instructs the CA to issue its certificate to the cryptographic endpoint.

Receipt and Authentication of the CA's Certificate

Once an endpoint has registered with the CA, the CA forwards its certificate, containing its public key, to the cryptographic endpoint. This step is critical to the endpoint's ability to verify the CA's signature when receiving public key certificates from other cryptographic endpoints, since the CA's certificate contains the public key that corresponds to the private signing key.

When the CA forwards its certificate to the endpoint, a step of authenticating the CA is typically executed. The CA's certificate has a unique fingerprint that can be checked for authenticity. Alternatively, this authentication step can be skipped if such authentication is not needed.

Forwarding and Signing of Public Keys

Once the CA and cryptographic endpoints have established a relationship of trust with one another, the cryptographic endpoint forwards its public key to the CA to be stored for other cryptographic endpoints to use. Before the CA forwards this public key to anybody, it signs it. To do this, the CA hashes the public key with a one-way hash algorithm, such as SHA-1 or MD-5. The message digest of that hash is then encrypted with the CA's private key. Only those endpoints that have authenticated the CA (and, as a result, also have the CA public key) can decrypt the message digest and verify it.

Note

Cisco cryptographic endpoints support the RSA-signatures method of authentication in ISAKMP. The DSS-1 standard for signature formatting and creation is followed in this process.

As you may recognize, this is the same process of creating a digital signature, which we explored in Chapter 2, "IPsec Fundamentals." The digital signature that the CA places on stored public keys is the very cornerstone of trust in a PKI.

Obtaining and Using Public Key Certificates

Once a cryptographic endpoint has enrolled with the CA, it can now verify the public key certificates of cryptographic endpoints that are enrolled with the CA. Because the cryptographic endpoint has already obtained the CA's certificate and public key, it can verify the CA's signature on the public key certificates of other cryptographic endpoints that it wants to encrypt data towards.

Note

During the whole process of creating and obtaining public key certificates, the cryptographic endpoints' private keys are never shared with anybody else, including the CA. This process ensures that only the cryptographic endpoint that originated the public/private keypair can decrypt data that was encrypted with its public key.


PKI and the IPSec Protocol SuiteWhere PKI Fits into the IPSec model

You may remember from our discussions of cryptographic components that asymmetric key encryption, while stronger than symmetric key encryption, is more computationally intensive than symmetric key encryption. Exactly how much more resources does asymmetric key encryption consume than symmetric key encryption? If the algorithms are executed in software, asymmetric key encryption is believed to be 1000 times slower than symmetric key encryption. If the algorithm is executed in hardware, this number decreases to a multiple of 100. Regardless, these numbers highlight the need for a cryptographic scheme that is more suited to bulk data transfer, a critical component of IPSec implementations.

For these reasons, IPSec specifies the RSA-signature method for PKI compatibility for ISAKMP authentication onlysymmetric key encryption is much better suited for bulk transfer of encrypted data. As such, IPSec specifies a symmetric key method for encrypted data transfer over the IPSec SA (i.e., DES, 3DES, AES). Diffie-Hellman session keys are derived for symmetric encryption of the IKE channel and for use with symmetric key ciphers in the IPSec SA itself. Using RSA signatures provides a strong and highly scalable method for authentication during the establishment of ISAKMP SAs. This limits the impact on CPU burden to ISAKMP SA negotiation only, which allows data encryption at the IPSec layer to be encrypted effectively and efficiently.


OCSP and CRL Scalability

One design consideration that has received a lot of attention over the years in the PKI world is scalability surrounding CRLs. As we have discussed, CRLs were born of the need to tell cryptographic endpoints which public key certificates that they are using have expired or have been revoked by the CA or CA administrator. We have further discussed that CRLs are periodically issued to cryptographic endpoints by CRL issuers, and stored locally on the cryptographic endpoint itself. This presents problems on memory-constrained endpoints like workstations and network nodes. This problem begins to penetrate all areas of the PKI design as the size of the CRL grows and higher-end cryptographic devices are now struggling to accommodate the storage of the large CRL. The IETF's PKIX working group has drafted proposals and RFCs for several alternative methods that would eliminate the need to store the CRL locally on the cryptographic endpoint itself. One of most widely used protocols is the Online Certificate Status Protocol.

Tip

PKIX has defined many protocols to address PKI scalability issues surrounding CRL storage and other design topics. For more information on the PKIX and its initiatives you can view their charter at http://www.ietf.org/html.charters/pkix-charter.html.

OCSP

OCSP was developed to provide routers with the ability to check for revoked certificates quicker and more frequently than they could when following the standard CRL-checking format. In an OCSP arrangement, cryptographic endpoints act as OCSP clients, and the CRL issuer typically acts as the OCSP responder. The client gets CRL information from the OCSP responder through the following exchange:

1.
The OCSP client receives a certificate from another peer.

2.
The OCSP client sends an OCSP request to the OCSP server for the validity of the certificate that it just received.

3.
The OCSP server checks the signature within the OSCP request to see if the OCSP request is well formed and that it contains the information it needs to formulate a response.

4.
The OCSP server crafts an OCSP response message containing one of three messages:

  • Good

  • Revoked

  • Unknown

5.
The OCSP responder digitally signs the response and forwards it to the OCSP client.

6.
The OCSP client receives the OCSP response message, and verifies the digital signature.

7.
The OCSP client uses the OCSP response message to determine the validity of the certificate received in Step 1.

Note

Cisco IOS allocates 64k of memory for CRL processing. This is adequate for the majority of CRL sizes. However, for abnormally large CRLs, alternatives to standard CRL checking, such as OCSP, must be explored.

The preceding exchange provides a scalable alternative to periodically downloading the full CRL from a CRL issuer. OCSP messages are ensured to be authentic and with integrity, since the CRL issuer digitally signs all OCSP responses.


Case Studies and Sample Configurations

The following case studies represent a scaled-down version of an enterprise network. In real topologies, much more redundancy would be built into the network topology. However, for clarity and conciseness, the topology has been reduced to the critical network elements themselves. The network core consists of Catalyst 6500s, which branch off distribution switches at the company's east and west campuses. The distribution layer switches in this case are represented by the Catalyst 4507Rs at each campus. A 7200VXR router serves as the headend for the company's branch locations. Frame relay circuits extend the network to each branch, represented with a 3745 router. The topology described above is illustrated in Figure 11-6.

Figure 11-6. Case Study PKI Topology

[View full size image]

Critical resources are located at the company's east campus. Transmissions from these resources across the WAN to the branch offices must be kept confidential. Security administrators have selected asymmetric encryption as the method used to authenticate the IKE channels. As such, a PKI-based implementation has been chosen to encrypt data from the company's east campus to resources at the branch locations. This series of case studies will demonstrate various PKI deployments in the company's west campus that are used to deliver these services.

Case Study 1: PKI Integration of Cryptographic Endpoints

In the first case study, we will illustrate the basic enrollment and authentication processes of the cryptographic endpoints within the PKI. In this case, the cryptographic endpoints are represented by the frame-relay head-end (7206VXR) and its spokes (3745s). The CA for this case study is running on Cisco IOS 12.3.8T4 and is configured as displayed in Example 11-1.

Example 11-1. Cisco IOS CA base configuration

crypto pki server IOS_CA1
grant auto
!
crypto pki trustpoint IOS_CA1
revocation-check crl
rsakeypair IOS_CA1
!
crypto pki certificate chain IOS_CA1
certificate ca 01
308201FD 30820166 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
12311030 0E060355 04031407 494F535F 43413130 1E170D30 34313230 36313234
3532305A 170D3037 31323036 31323435 32305A30 12311030 0E060355 04031407
494F535F 43413130 819F300D 06092A86 4886F70D 01010105 0003818D 00308189
02818100 C3AB99C2 CE7E000D CB59AA96 CD5815EF 60ADAB83 DE6B67B5 356BC735
7F518745 EF92AC71 BBCA8CB5 DFCD8B63 DB05BDC9 194D1665 181283E5 631C9875
F7821CCA 2717900D EF73BD7A 0D86C2B7 73170DB4 41C66C66 BBD25C19 2801D22E
2AC7E22E 710B6BC9 184803BE 9D5D3238 FC704842 E4728A05 943B7AEB AF76F4B1
7E638CBD 02030100 01A36330 61300F06 03551D13 0101FF04 05300301 01FF300E
0603551D 0F0101FF 04040302 0186301D 0603551D 0E041604 14177FC9 2F8DE64D
F61B730D 873B67BF 13A7E05B 70301F06 03551D23 04183016 8014177F C92F8DE6
4DF61B73 0D873B67 BF13A7E0 5B70300D 06092A86 4886F70D 01010405 00038181
004940A8 5E4ED5BB 3DF84643 AB77E505 A8A96E9B 1D621471 56ADC25B 7FBA3CEB
EB755322 BB3A50A1 8B3B567D 4F4B667D B84D9860 F7519B70 EF2529E7 8B3F1EC7
90880D87 84394162 B31DD74F 0F2E4532 8E4EF645 15766A62 546CD102 BD670F6B
034FDCC6 040F90EF C68DDF1B 8A86354B 48289102 01700B77 CDB416A7 58605FDE CF

Once the CA has been configured, the crypto endpoints must generate RSA keys for creating digital signatures, as shown when the Frame Relay headend 7206VXR enrolls with the PKI. These public RSA keys will be used to encrypt communications through the IKE channel, and the private keys will be used for decrypting communications through the IKE channel. Note that stronger keys are selected for stronger security than the default key modulus (512). Example 11-2 illustrates the process of generating an RSA keypair with Cisco IOS.

Example 11-2. Generating RSA Keys for Use with RSA Signatures

7206VXR-MAIN(config)#crypto key generate rsa
The name for the keys will be: 7206VXR-MAIN.cisco.com
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [512]: 1024
% Generating 1024 bit RSA keys ...[OK]

7206VXR-MAIN(config)#exit
7206VXR-MAIN#sh crypto key mypubkey rsa
% Key pair was generated at: 11:08:26 PST Dec 6 2004
Key name: 7206VXR-MAIN.cisco.com
Usage: General Purpose Key
Key is not exportable.
Key Data:
30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00F4F069
29F731C7 3A6A78AC FC28201F 4B278BEB 348C6450 C9B88510 1AC5948B 36C2DB4A
6C85C1E8 C689B5CD 841F60FA 53264AB2 AFBD8E3E 62235BD0 F48208E9 042B43E6
60F01AD0 B7F870C2 224FF2E5 7288E6CA 47BFDF36 E0D882B1 6B8FAA28 775CBE4B
13B83E11 090F731D D5640280 4EBEF7EE C5EF1ED7 B56A5E09 603377E2 DD020301 0001
% Key pair was generated at: 11:08:26 PST Dec 6 2004
Key name: 7206VXR-MAIN.cisco.com.server
Usage: Encryption Key
Key is exportable.
Key Data:
307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00D6CD85 1A603369
F8598785 E0F3003C 81874E3A F10BC0FB 5401D977 CA445C6B C9EA191D C08AEFED
9A511972 7BD4B303 C748A7EC 3A6DB4BD 8B6193A9 6FA80D2F CC32E35D E7E4CE1C
74F4493F 6C9DF20F B26B1FFB A52BAD30 5D88B725 6EFF4CE1 71020301 0001

Once RSA keys have been created, the CA must be specified and authenticated. Example 11-3 shows the specification of a CA trustpoint on the 7206VXR. When authenticating a CA, the CA will provide the administrator with a unique fingerprint. The administrator must manually accept this fingerprint for the CA to be authenticated on the router.

Example 11-3. Authenticating the CA with Cisco IOS

7206VXR-MAIN#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
7206VXR-MAIN(config)#crypto ca trustpoint IOS_CA1
7206VXR-MAIN(ca-trustpoint)#enrollment url http://200.2.1.2
7206VXR-MAIN(ca-trustpoint)#exit
7206VXR-MAIN(config)#crypto ca authenticate IOS_CA1
Certificate has the following attributes:
Fingerprint: 99282341 BE16A9D0 DE8614E4 A3557E48
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
7206VXR-MAIN(config)#

The 7206VXR has now authenticated the CA. Next, the 7206VXR must be enrolled with the CA for other endpoints to verify its validity in the PKI. Example 11-4 shows this enrollment process. The router prompts the administrator for a password that is used for revoking certificates if needed.

Example 11-4. Enrolling a Cryptographic Endpoint in a PKI

7206VXR-MAIN(config)#crypto ca enroll IOS_CA1
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.

Password:
Re-enter password:

% The fully-qualified domain name in the certificate will be:
7206VXR-MAIN.cisco.com
% The subject name in the certificate will be: 7206VXR-MAIN.cisco.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]:
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto ca certificate' command will also show the fingerprint.
CRYPTO_PKI:    Fingerprint: 56FB7367 20C98A75 82B96CE9 46C4D1F6
Dec  6 16:22:56.486:
Dec  6 16:23:07.717: %CRYPTO-6-CERTRET: Certificate received from
Certificate Authority

As a result of the enrollment process, the 7206VXR receives its own certificate signed by the CA. When 3745-A, B, and C enroll with the PKI through this same process, they will also receive their own CA-signed certificates. The spokes will then be able to exchange their certificates successfully with the 7206VXR to authenticate the IKE channel. Over this channel, an IPSec SA will be built and encrypted communications will be enabled between the spokes and the West Campus LAN.

Case Study 2: PKI with CA and RA

In this scenario, another Cisco IOS-based CA has been addedIOS_CA2. However, IOS_CA2 is acting strictly as a registration authority; it is not actually signing certificates for the crypto endpoints. Instead, IOS_CA2 offloads registration responsibility for IOS_CA1, which retains sole responsibility for enrolling and signing router certificates. In order to ensure that the CA is only granting certificates to those cryptographic endpoints which have already been processed by the registration authority, the configuration of IOS_CA1 is changed, as shown in Example 11-5, to automatically grant requests only if a trusted registration authority has previously processed them.

Example 11-5. CA Configuration for RA Interoperability

IOS_CA1#configure terminal
IOS_CA1(config)#
IOS_CA1(cs-server)#crypto pki server IOS_CA1
IOS_CA1(cs-server)#grant ra-auto
IOS_CA1(cs-server)#end

The RA configuration looks similar to the configuration of a CA in Cisco IOS. The main difference is that RA mode must be selected under the CA server configuration. Additionally, the RA must be configured with a CA as its trustpoint, which is IOS_CA1 in this case. As such, IOS_CA2 will authenticate IOS_CA1 and enroll with IOS_CA1 in the same manner that a normal cryptographic endpoint would. IOS_CA2 must also be configured with its certificate name, along with other parameters for enrolling with the CA. Configuration of IOS_CA2 is displayed in Example 11-6.

Example 11-6. RA Configuration for CA Interoperability

IOS-CA2#configure terminal
IOS-CA2(config)#crypto pki server IOS_RA1
IOS-CA2(cs-server)#grant auto
IOS-CA2(cs-server)#mode ra
IOS-CA2(cs-server)#no shut
% Once you start the server, you can no longer change some of
% the configuration.
Are you sure you want to do this? [yes/no]: yes
Error: There is an enrollment transaction in progress.
Please wait or abort the current enrollment before
starting a new enrollment transaction.
% Enrollment in progress...
% You have to re-enable the certificate server after the enrollment succeeds.
!
IOS-CA2(cs-server)#exit
IOS-CA2(config)#crypto pki trustpoint IOS_RA1
IOS-CA2(ca-trustpoint)#enrollment url http://200.2.1.2:80
IOS-RA2(ca-trustpoint)#serial-number
IOS-CA2(ca-trustpoint)#ip-address FastEthernet0/1
IOS-CA2(ca-trustpoint)#subject-name cn=IOS_RA1, ou=ioscs RA, o=cisco, c=us
IOS-CA2(ca-trustpoint)#revocation-check crl
IOS-CA2(ca-trustpoint)#rsakeypair IOS_RA1
IOS-CA2(ca-trustpoint)#end

Note

In Example 11-6, the enrollment URL points to an HTTP server enabled on the IOS-based CA Server, IOS-CA1.

The IOS CA will store information requests from the RA, which must be manually granted. Example 11-7 shows the process of displaying requests from RA's on IOS_CA1 and manually accepting them.

Example 11-7. Managing RA Information Requests on IOS CAs

IOS-CA1#crypto pki server IOS_CA1 info requests
Enrollment Request Database:

RA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------
14     pending    230B8A39AC85E0512A5D01EC1796D2C8
serialNumber=7F6AD0E2+ipaddress=200.2.2.2+hostname=IOS-RA1.cisco.com,
cn=IOS_RA1,ou=ioscs RA,o=cisco,c=us

Router certificates requests:
ReqID  State      Fingerprint                      SubjectName
IOS-CA1#crypto pki server IOS_CA1 ?
grant     Grant enrollment requests
info      Display info
password  One Time Password for SCEP enrollment
reject    Reject enrollment requests
request   Retrieve an enrollment request
revoke    Revoke certificate
IOS-CA1#crypto pki server IOS_CA1 grant 14

Note that in Example 11-6, once the RA, IOS_CA2, has authenticated and enrolled with CA, IOS_CA1, the RA server on IOS_CA2 shuts down. It will remain disabled until it is manually enrolled by the administrator on IOS_CA1, as shown in Example 11-8.

Example 11-8. Re-Enabling the IOS Server on an RA

IOS-CA2#configure terminal
IOS-CA2(config)#crypto pki server IOS_RA1
IOS-CA2(cs-server)#no shut
% Once you start the server, you can no longer change some of
% the configuration.
Are you sure you want to do this? [yes/no]: yes
% Certificate Server enabled.
IOS-CA2(cs-server)#end

Now that the RA has been fully enrolled with the CA, cryptographic endpoints must be configured to subscribe to the PKI with the RA (IOS_CA2). The cryptographic endpoints will subscribe to the PKI using the same procedure outlined in Case Study 1, with the exception of using IOS_CA2 as their trustpoint instead of IOS_CA1. Additionally, the endpoints must be told that they are using an RA instead of a CA for subscribing to the PKI. Otherwise, the interaction between the RA and CA will be transparent to the cryptographic endpoints. Example 11-9 shows the configuration of the IOS CA server (IOS-CA2 in Figure 11-6) to act as an RA.

Example 11-9. Cryptographic Endpoint Enrollment with an RA

IOS-CA2#
IOS-CA2(config)#crypto pki trustpoint IOS_RA1
IOS-CA2(ca-trustpoint)#enrollment url http://200.2.1.2:80
!#<--The following command informs the IOS PKI endpoint that it is
enrolling with an RA as opposed to a CA-->
IOS-CA2(ca-trustpoint)#enrollment mode ra

Case Study 3: PKI with Redundant CAs (CA Hierarchy)

A third CA running on Cisco IOS has now been added to the topology. This CA will serve as the root CA in the PKI CA hierarchy. IOS_CA2 is now configured as a full CA server that subscribes to the root CA. As such, there are now two CA servers running on Cisco IOS that are subscribed to the root CA.

Note

Traditionally, PKIs have only accommodated two tiers in their hierarchiesthe root CA comprises the first tier, and all other CAs in the second tier must subscribe to that tier-1 root CA. Cisco IOS supports multiple tier hierarchies for additional PKI scalability in later versions of 12.2T.

The two IOS-based CAs are configured to subscribe to the root CA as shown in Example 11-10 and Example 11-11.

Example 11-10. IOS_CA1 Configuration

IOS-CA1#configure terminal
IOS-CA1(config)#crypto pki server IOS_CA1
IOS-CA1(cs-server)#grant auto
IOS-CA1(cs-server)#exit
IOS-CA1(config)#crypto pki trustpoint IOS_CA1
IOS-CA1(ca-trustpoint)#enrollment url http://10.1.12.100:80
IOS-CA1(ca-trustpoint)#revocation-check crl
IOS-CA1(ca-trustpoint)#rsakeypair IOS_CA1
IOS-CA1(ca-trustpoint)#end

Example 11-11. IOS_CA2 Configuration

IOS-CA2#configure terminal
IOS-CA2(config)#crypto pki server IOS_CA2
IOS-CA2(cs-server)#grant auto
IOS-CA2(cs-server)#exit
IOS-CA2(config)#
IOS-CA2(ca-trustpoint)#crypto pki trustpoint IOS_CA2
IOS-CA2(ca-trustpoint)#enrollment url http://10.1.12.100:80
IOS-CA2(ca-trustpoint)#revocation-check crl
IOS-CA2(ca-trustpoint)#rsakeypair IOS_CA2
IOS-CA2(ca-trustpoint)#end

Note

The CAs in Example 11-10 and Example 11-11 are subordinate to the root CA, IOS_CAROOT. Each subordinate CA must download the root CA certificate and authenticate the root CA. Likewise, each subordinate CA is configured to enroll with the root CA (shaded text in Example 11-10 and Example 11-11).

The root CA is configured to grant its certificate to the root CA, as shown in Example 11-12. The root CA can therefore use what is commonly referred to as a "self-signed certificate" when IOSCA1 and IOS-CA2 are unavailable, providing another layer of redundancy within the PKI hierarchy.

Example 11-12. Root CA Configuration

IOS-CAROOT#configure terminal
IOS-CAROOT(config)#crypto pki server IOS_CAROOT
IOS-CAROOT(cs-server)#grant auto
IOS-CAROOT(cs-server)#exit
IOS-CAROOT(config)#crypto pki trustpoint IOS_CAROOT
IOS-CAROOT(ca-trustpoint)#revocation-check crl
IOS-CAROOT(ca-trustpoint)#rsakeypair IOS_CAROOT
IOS-CAROOT(ca-trustpoint)#end

Each cryptographic endpoint will authenticate the root CA and at least one of its subordinate CAs for redundancy. Likewise, each cryptographic endpoint will enroll with the root CA and one of its subordinates. Example 11-13 shows the configuration of redundant trustpoints on one of the Frame Relay spoke routers, 3745-A. Example 11-14 displays the configuration of the Frame Relay head-end 7206VXR. The Frame Relay hub router must authenticate and enroll with all of the CAs in the PKI, since not all of the Frame Relay spokes will have their certificates signed by the same CA. The process of enrollment for the cryptographic endpoints for each CA trustpoint configured is consistent with the procedures discussed in the previous case studies in this chapter.

Example 11-13. Frame Relay Spoke (3745) Configuration for PKI Redundancy.

3745-A#configure terminal
3745-A(config)#crypto pki trustpoint IOS_CAROOT
3745-A(ca-trustpoint)#enrollment url http://10.1.12.100:80
3745-A(ca-trustpoint)#serial-number
3745-A(ca-trustpoint)#ip-address Serial0/0
3745-A(ca-trustpoint)#revocation-check crl
3745-A(ca-trustpoint)#exit
3745-A(config)#crypto pki trustpoint IOS_CA1
3745-A(ca-trustpoint)#enrollment url http://200.2.1.2:80
3745-A(ca-trustpoint)#serial-number
3745-A(ca-trustpoint)#ip-address Serial0/0
3745-A(ca-trustpoint)#revocation-check crl
3745-A(ca-trustpoint)#end

Example 11-14. Frame Relay Hub (7206VXR) Configuration for PKI Redundancy

7206VXR#configure terminal
7206VXR(config)#crypto ca trustpoint IOS_CAROOT
7206VXR(ca-trustpoint)#enrollment url http://10.1.12.100:80
7206VXR(ca-trustpoint)#serial-number
7206VXR(ca-trustpoint)#ip-address FastEthernet0/1
7206VXR(ca-trustpoint)#exit
7206VXR(config)#crypto ca trustpoint IOS_CA1
7206VXR(ca-trustpoint)#enrollment url http://200.2.1.2:80
7206VXR(ca-trustpoint)#serial-number
7206VXR(ca-trustpoint)#ip-address FastEthernet0/1
7206VXR(ca-trustpoint)#exit
7206VXR(config)#crypto ca trustpoint IOS_CA2
7206VXR(ca-trustpoint)#enrollment url http://200.2.2.2:80
7206VXR(ca-trustpoint)#serial-number
7206VXR(ca-trustpoint)#ip-address FastEthernet0/1
7206VXR(ca-trustpoint)#end


Summary

As the scale of enterprise-class IPSec VPN designs increases, so do the design challenges associated with the scalability and management of the overall architecture. In this chapter, we've introduced the use of a PKI as a centralized, scalable resource for key management in large-scale IPSec VPN deployments. The PKI lends an additional degree of security to the overall IPSec VPN architecture using a centralized, trusted resource (the PKI CA) to distribute public key certificates to each IPSec VPN gateway participating in the PKI. At this point, we have discussed how Cisco IPSec VPN gateways using RSA signatures for IKE Authentication authenticate and enroll with the CA of the PKI, obtain their public key certificates, and verify each other's public key certificates using several different design alternatives including:

  • Standalone CA deployments

  • CA deployments using one or more RAs

  • CA hierarchies using multiple CAs for redundancy

We have also covered the basics for using PKI technology with Cisco IPSec VPN endpoints, and several design alternatives to deploying PKI resources. PKIs should be evaluated as the design option of choice using concepts and design scenarios discussed in this chapter when additional levels of secure, scalable key management are required within their IPSec VPN deployments.


Chapter 12. Solutions for Handling Dynamically Addressed Peers

There often exist areas of IPSec design that could benefit from more flexible peering options. From this demand arose the creation of solutions to handle dynamically addressed IPSec peers. Although these solutions are used less frequently than the static peering design alternatives that we have discussed in previous chapters, they are commonly deployed when network designers anticipate that they will not know the addresses of certain remote IPSec peers within their greater VPN implementation. Dynamic peering solutions can add value to situations in which the peer of an IPSec VPN is not known in advance or is anticipated to change over time.

For Cisco IOS and ASA-based IPSec VPN implementations, dynamic crypto maps were created as the foundation for addressing the need for dynamic peering alternatives. Tunnel Endpoint Discovery (TED) extends the functionality of dynamic crypto maps, enabling the local peer to proactively discover remote IPSec VPN peers, the addresses of which are unknown. This chapter explores the design issues surrounding the two core components of dynamic peering solutionsdynamic crypto maps and TED.


Dynamic Crypto Maps

Dynamic crypto maps enable IPSec to negotiate ISAKMP and IPSec Security Associations (SA) that are initiated from remote endpoints, the addresses of which are unknown. Dynamic crypto maps by themselves do not enable a virtual private network (VPN) endpoint to proactively discover remote and unknown IPSec peers and does not enable a VPN endpoint to initiate ISAKMP and IPSec SA negotiation to undiscovered peers. Indeed, traffic that is in the crypto-protected path of a dynamic crypto map without TED will be dropped unless the remote peer has already initiated and negotiated an IPSec tunnel with the IPSec endpoint using that dynamic crypto map. In order to initiate ISAKMP and IPSec SA negotiation with unknown remote peers, dynamic crypto maps must be used in conjunction with TED, which is discussed later in this chapter.

With static crypto maps, an IPSec peer is specified statically. This is not the case with dynamic crypto maps. Instead, because the peer is unknown, dynamic crypto maps will respond to ISAKMP and IPSec SA negotiation attempts from an array of previously unknown peers. Because of this, dynamic crypto maps have distinct differences from static crypto maps that change various concepts surrounding IPSec and ISAKMP design, deployment, and administration. Here are some key components of static IPSec peering designs that can be dynamically discovered and configured by altering the design to use dynamic crypto maps:

  • Dynamic acceptance and configuration of the remote (initiating) peer's IP address in the negotiated IPSec SA

  • Dynamic acceptance and configuration of the crypto-protected address space in the IPSec SA

Note

In remote access VPN deployments, dynamic crypto maps are commonly used to facilitate additional dynamic functionality, such as the dynamic assignment of VPN client IP addresses, DNS/WINS servers, and IP domain names using IKE Mode Config. These scenarios are discussed in greater detail in Chapter 9, "Solutions for Remote Access VPN High Availability."

With static crypto maps, all of the above items must be manually configured at both the local and remote peers. In a dynamic crypto map solution, only the remote endpoint must be statically configuredthe local endpoint can use its dynamic crypto map to retroactively discover the remote peer's IP address. Indeed, it is this dynamic nature that distinguishes dynamic crypto maps from static ones. We will explore configurations that enable dynamic functionality later in the chapter, but first we will explore the impact that dynamic crypto maps have on the operation of ISAKMP and IPSec.

Dynamic Crypto Map Impact on VPN Behavior

Incorporating dynamic crypto maps into an IPSec VPN design can dramatically change the behavior of the VPN. It is therefore important that network administrators understand the way that dynamic crypto maps alter the behavior of the VPN. In the following sections, we will discuss the impact of dynamic crypto map design on ISAKMP SA negotiation and what routing considerations must be addressed in an IPSec VPN deployment using dynamic crypto maps. Then we will discuss security considerations of dynamic crypto maps when compared against static ones, as well as some measures to consider when securing VPN implementations using dynamic crypto maps.

Dynamic Crypto Map Impact on ISAKMP/IKE

Dynamic crypto maps will dynamically allocate a remote peer to the local IPSec configuration based on information provided by the remote peer itself. Indeed, ISAKMP negotiation cannot begin until a remote peer is defined. Therefore, once a router that uses dynamic crypto maps receives a request to initiate ISAKMP SA negotiation using a matching, locally configured ISAKMP policy, it creates and installs a temporary crypto map entry populated with the initiating endpoint's peer so that it can then carry on with Phase 1 negotiation. This order of operations is illustrated later in Figure 12-1.

Figure 12-1. Reverse Route Injection and Dynamic Crypto Maps

[View full size image]

A VPN endpoint that uses dynamic crypto maps must be configured with an ISAKMP policy that matches one proposed by the remote VPN endpoint. This behavior is consistent with static crypto maps with one exceptiondynamic crypto maps typically use wildcard preshared keys. The use of wildcard preshared keys allows network administrators to define a key for use with a range of IP addresses, as opposed to just one. This is particularly useful in a dynamic crypto map scenario where there are a varying number of peers whose addresses are unknown. Wildcard preshared keys eliminate the need to know the peer's exact address during IKE authentication, requirng only that it fall within a specific range. Example 12-1 illustrates a sample IKE configuration using a wildcard preshared key.

Note

The use of wildcard preshared keys leads to difficulties when attempting to evict an endpoint from the IPSec VPN. When the administrative overhead of static preshared keys is a concern, it is recommended that RSA signatures be used instead of wildcard preshared keys.

Example 12-1. Wildcard Preshared Keys in ISAKMP Authentication.

!#<--This example of a wildcard preshared key will allow any peer with an IP
!address within the range of 192.168.0.0/16 to negotiate an ISAKMP SA-->
crypto isakmp key extranet address 192.168.0.0 255.255.0.0

Note

For increased security using dynamic crypto maps, IKE Extended Authentication (x-auth) can be used instead of pre-shared keys. IKE x-auth leverages a robust set of authentication and authorization commands in conjunction with centrally maintained TACACS+/RADIUS databases for increased security and scalability.

Routing Considerations with Dynamic Crypto Maps

Designs leveraging the functionality of dynamic crypto maps introduce some additional design considerations that network designers must address within their routed infrastructures. The following list provides a brief introduction and explanation of considerations for IPSec VPNs with dynamic crypto maps:

  • IGP Multicast Routing Updates Dynamic crypto maps allow broader definition of protected traffic sets, since multiple unknown peers can now dynamically negotiate different protected traffic sets with the same dynamic crypto map. However, caution should be exercised against using the any keyword in the dynamic crypto map's ACL when defining broad scopes of protection, so that multicast routing protocol updates are not encrypted or dropped unnecessarily. As we've mentioned previously, traffic in the crypto path using a dynamic crypto map will not initiate IPSec tunnel negotiation; it will instead be dropped. Therefore, defining multicast and broadcast traffic in the crypto path using dynamic crypto maps can oftentimes lead to the discarding of routing updates and loss of RP adjacencies. When using any keyword on the dynamic crypto map ACL, traffic such as multicast RP updates should be explicitly denied first.

  • Reverse Route Injection (RRI) RRI is a feature that will dynamically inject routes into the IPSec VPN gateway's routing table. Effective implementation of RRI allows network administrators to keep the routing table size manageable. With RRI, routes are injected dynamically into the routing table, which can subsequently be redistributed into the enterprise's IGP for propagation throughout the network. This allows the VPN concentrator or router to inject routes for only those remote networks that have active IPSec VPN connections. This method can be used to efficiently scale the Interior Gateway Protocol (IGP) of an IPSec VPN implementation when used in conjunction with dynamic crypto maps.

Figure 12-1 illustrates an IPSec VPN deployment in which dynamic crypto maps are used in conjunction with RRI.

The following is the operation of the IPSec-enabled infrastructure numbered in Figure 12-1:

1. | The remote network attempts to contact a resource on the enterprise network.
2. | The remote VPN endpoint sees the traffic in Step 1, successfully matches it against a crypto ACL, and initiates ISAKMP SA negotiation.
3. | The VPN aggregation point receives the request and finds a locally configured ISAKMP policy to match the ISAKMP proposal that it received in Step 2. The VPN aggregator creates a temporary crypto map entry populated with the remote peer address so that ISAKMP negotiation can continue.
4. | The VPN aggregator on the enterprise network uses a temporary crypto map installed in Step 3 to negotiate Phase 1 and 2 with the remote VPN endpoint.
5. | The VPN aggregator uses RRI to dynamically inject the 199.1.1.0/24 network into the enterprise network. This allows enterprise resources to route traffic over the VPN to the appropriate destination on the remote end of the IPSec VPN tunnel. When the ISAKMP and IPSec SAs for the remote network time out, the routes injected using RRI are allowed to time out.
Security Considerations for Dynamic Crypto Maps

As the number of remote peers associated with a dynamic crypto map scales upward, so too escalates the security concerns surrounding the use of wildcard preshared keys. Next, we will discuss two of these concerns, both directly related to key management for dynamically addressed peers, and how to use x-auth during ISAKMP authentication to harden security for dynamically addressed VPN peers.

Key Administration and Scalability

Multiple wildcard preshared keys can be defined, but the manual configuration involved makes it very difficult for each peer to use its own unique key for IKE authentication, since the number of remote and unknown peers scale upward. Therefore, using wildcard preshared keys for a large number of unknown peers presents a security risk, because many of those unknown peers typically use a common key. Using IKE x-auth in conjunction with a TACACS+ or RADIUS database such as Cisco Secure Access Control Server (ACS) provides a highly scalable, highly available solution for IPSec peers to authenticate with their own unique credentials.

The addition of a peer to the group using a common wildcard preshared key for IKE authentication is a simple processa single configuration of that key on the remote peer. However, removing a peer from that group is more involved and presents security risks. Once a peer is evicted from a group using a common preshared key, that key has become compromised, and must therefore be changed and updated on every remaining peer in the group. For this reason, it is apparent that wildcard preshared keys do not offer the administrative flexibility needed for secure IKE negotiation with dynamically addressed peers. Instead, IKE x-auth should be used so that a peer in the group can be removed without compromising the credentials that the remaining, dynamically addressed peers use for IKE authentication.

IKE x-auth offloads Phase 1 authentication and authorization of remote peers to either a locally configured database on the aggregating router or to a centrally maintained database using TACACS+ or RADIUS. Figure 12-2 describes the authentication process used during IKE x-auth.

Figure 12-2. ISAKMP Phase 1 Negotiation Using Extended Authentication (x-auth)

[View full size image]

The following is a description of the numbered process in Figure 12-2:

1. | The remote peer sends an ISAKMP proposal.
2. | The local peer checks the ISAKMP proposal against its locally configured policies and finds a match; an IKE SA is established with that proposal using preshared keys.
3. | The local peer sends a TACACS+ access-request message to the AAA server.
4. | The AAA server responds with either an access-accept or access-reject message, depending on whether the peer is successfully authenticated or not. In this case, the peer is authenticated by the AAA server and a TACACS+ access-accept message is forwarded back to the local peer.
5. | The local peer installs a temporary crypto map using the IP address peer that sent the ISAKMP proposal in Step 1.
6. | The two peers continue to negotiate IPSec SAs.

In the configuration in Example 12-2, the remote 3745 acts as an EZVPN client, connecting dynamically to the 7304, which in this case acts as the VPN concentrator. The concentrator receives the VPN group credentials and password, and uses the group password as the IKE preshared key. IKE x-auth is configured for additional security and flexibility in group and peer administration. Using x-auth, the concentrator prompts the client for an additional authentication check against its locally configured database. The client authenticates using its locally configured username and password under the appropriate group settings.

Note

IKE x-auth occurs after an IKE SA has been created but before an IPSec SA can be created. IKE x-auth therefore does not replace IKE itself, but rather occurs in addition to it. As such, IKE x-auth negotiation is commonly referred to as Phase 1.5 negotiation.

Example 12-2. Configuring IKE X-Auth Using TACACS+ and AAA

AS1-7304A#
!
!#<--This username and password configured in the local database are referenced
!by the AAA model when authenticating IPSec clients-->
!
username as111 privilege 15 password 0 cisco111
!
!#<--These AAA statements are used when IPSec clients require x-auth.
!The AAA statements below reference the local database, in which there
!is an appropriate username and password for the client.-->
!
aaa authentication login vpn-auth local
aaa authorization network vpn-auth local
!
!#<--The VPN group "extranet" is used for group authentication with the
!IKE pre-shared key "cisco". This group template protects traffic using
!the crypto ACL 111 and the dynamic crypto map "extranet-dyn".
!The "save-password" command allows clients to hard code their usernames and
!passwords into their client configurations. As such, they can be automatically
!offered for authentication, rather than having to enter them manually
!when prompted by the concentrator.-->
crypto isakmp client configuration group extranet
 key cisco
 acl 111
 save-password
!
crypto dynamic-map extranet-dyn 10
 set transform-set extranet-trans
 reverse-route
!
!#<--The crypto map "extranet" is instructed to use the AAA model "vpn-auth"
!for extended authentication and authorization of IPsec VPN clients.-->
crypto map extranet client authentication list vpn-auth
crypto map extranet isakmp authorization list vpn
!#<--The dynamic crypto map "extranet-dyn" is referenced here so that it can
!be applied indirectly via the application of the static crypto map "extranet"
!to the physical interface-->
crypto map extranet 10 ipsec-isakmp dynamic extranet-dyn
!
Interfaces Serial0/0
 crypto map extranet

AS111-3745A#
!
!#<--Instead of static or dynamic crypto maps, the remote router is configured
!as an ezvpn client, so that x-auth can be used for greater flexibility in
!group management and additional security-->
crypto ipsec client ezvpn as111-client
 connect auto
!#<--The VPN concentrators will use these credentials to identify which group
!and pre-shared key this client will use for ISAKMP Phase 1 negotiation-->
 group extranet key cisco
 mode client
 peer 200.1.1.1
!#<--The VPN concentrator will authenticate these credentials against its
!AAA model (must match username and password configuration on AS1-7304A)-->
 username as111 password cisco111
!
!#<--This ezvpn client does not use crypto acls to determine the crypto protected
!traffic. Instead, all traffic from the ezvpn "inside" interface being sent out
!of the concentrator-facing physical interface is crypto protected-->
interface Loopback192
 crypto ipsec client ezvpn as111-client inside
!
interface Serial0/0
 crypto ipsec client ezvpn as111-client

Unrestricted Peering and Traffic Flows

By default, dynamic crypto maps allow peering sessions from any peer that IKE can authenticate. Likewise, by default, all traffic is allowed to and from all peers associating with that dynamic crypto map. Both of these areas can be secured by restricting peering sessions and using dynamic crypto map ACLs to restrict traffic.

Example 12-3 describes a scenario in which a dynamic crypto map allows HTTP traffic only from peers 192.168.1.15, but allows both http and SMTP traffic from peers 192.168.1.610.

Example 12-3. Restricting IPSec Peering and Traffic Flows in Dynamic Crypto Maps

AS1-7304A#
!
crypto dynamic-map extranet-dyn 10
 set peer 192.168.1.1
 set peer 192.168.1.2
 set peer 192.168.1.3
 set peer 192.168.1.4
 set peer 192.168.1.5
 set ip access-group 113 in
 set transform-set extranet-trans
 match address 111
 reverse-route
crypto dynamic-map extranet-dyn 20
 set peer 192.168.1.6
 set peer 192.168.1.7
 set peer 192.168.1.8
 set peer 192.168.1.9
 set peer 192.168.1.10
 set ip access-group 114 in
 set transform-set extranet-trans
 match address 111
 reverse-route
!
access-list 113 permit tcp 192.168.111.0 0.0.0.255 192.168.1.0 0.0.0.255 eq www
access-list 113 permit tcp 192.168.111.0 0.0.0.255 192.168.1.0 0.0.0.255 eq smtp
access-list 114 permit tcp 192.168.111.0 0.0.0.255 192.168.1.0 0.0.0.255 eq www
access-list 114 permit tcp 192.168.111.0 0.0.0.255 192.168.1.0 0.0.0.255 eq smtp

Dynamic Crypto Map Configuration and Verification

The design topology illustrated in Figure 12-3 outlines a site-to-site extranet deployment in which an organization maintains secure connectivity to its extranet partners, which are numerous. The organization relies on data feeds from extranet partners for services critical to the operation of the business but does not maintain control over the configuration of remote routers on the extranet partner's premises. Instead, those configurations are maintained by the partner, and they are subject to change over time. As such, the organization has chosen to deploy dynamic crypto maps at its local aggregation point for extranet IPSec VPNs, allowing the extranet partners to change their configuration on the fly and dynamically update the IPSec SA peer configuration information on the aggregation router with minimal administrative overhead.

Figure 12-3. Extranet Deployment and Dynamic Crypto Maps

[View full size image]

Note the size of the extranet in Figure 12-3. The simple hub-and-spoke extranet design listed in this figure presents a fair amount of administrative overhead at the hub, especially when the partner sites control the policy on their VPN endpoint and are liable to make changes to their session on the fly. Deploying dynamic crypto maps (and TED, if necessary) can dramatically ease the hub administrator's burden of accommodating the many anticipated changes made at the numerous extranet partner sites.

To highlight the configuration of a dynamic crypto map, we will select a fixed (extranet partner) end of the tunnel and the dynamic end of the tunnel, and explore the connectivity between those two peers, as the greater extranet design is merely an extension of that dynamically established point-to-point IPSec VPN.

Note

For extranet designs such as this one, there typically will exist a certain amount of High Availability (HA) designed into the aggregation points. Our conversation in this chapter will focus solely on dynamically addressed peering, and, because of this, HA concepts are not incorporated into these configurations.

Example 12-4 provides a sample configuration for a hub router (AS1-7304A) supporting the extranet design discussed in Figure 12-3.

Example 12-4. Configuration of AS1-7304A

!#<--In this case, the ISAKMP policy is configured as if the crypto map
!were static. However, it is applied to all peers negotiating IPSec and
!ISAKMP SAs with this router using its local dynamic crypto map.-->
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
!#<--Because the specific peer address is unknown, wildcard preshared keys are
!used to authenticate extranet peers initiating ISAKMP SA negotiation with
!addresses in the range of 192.168.0.0/16-->
crypto isakmp key extranet address 192.168.0.0 255.255.0.0
!
crypto ipsec transform-set extranet-trans esp-3des esp-md5-hmac
!
!#<--The dynamic crypto map requires that a transform set be specified and
!a protected address set to populate the dynamically configured VRF in the
!IPSec SADB. However, the peer does not need to be defined, which is useful
!as in this case, the specific peer addresses of the various extranet partners
!are unknown and change frequently.-->
crypto dynamic-map extranet-dyn 10
 set transform-set extranet-trans
 match address 111
!#<--Each time a remote IPSec peer negotiates a VPN tunnel with this router
!using the dynamic crypto map defined above, a specific route for that
!endpoint will be dynamically injected backwards into the organizations'
!IGP routing table.-->
 reverse-route
!
!
!#<--The static crypto map is necessary to configure, as it is eventually
!referenced by the physical interface configuration. There is no additional
!mandatory configuration within the static crypto map when a dynamic crypto map
!is referenced. This particular crypto map sources updates from a loopback
!address for increased stability-->
crypto map extranet local-address Loopback1
crypto map extranet 10 ipsec-isakmp dynamic extranet-dyn
!
!
!
!
interface Loopback1
 ip address 201.1.1.1 255.255.255.255
!
interface Loopback192
 ip address 192.168.1.1 255.255.255.0
!
interface Serial0/0
 ip address 200.1.1.1 255.255.255.252
 encapsulation frame-relay
 frame-relay interface-dlci 102
 frame-relay lmi-type ansi
!#<--The static crypto map is referenced in the physical interface configuration.
!The dynamic crypto map is indirectly referenced here, as it is bound directly
!to the specified static crypto map below.-->
 crypto map extranet
!
!#<--The crypto protected address space used to populate the VRF each negotiated
!IPSec SA must be configured and referenced in the dynamic crypto map-->
access-list 111 permit ip 192.168.1.0 0.0.0.255 any

Example 12-5 provides a sample branch router (AS113-3745A) configuration used to establish an IPSec VPN tunnel to the corresponding hub router (AS1-7304A). The extranet topology for this configuration is illustrated in Figure 12-3, and hub configuration is provided in Example 12-5.

Example 12-5. Configuration of AS113-3745A

!#<--The extranet partner side of the tunnel is configured with static
!crypto maps and no wildcards in the preshared key-->
crypto isakmp policy 10
 encr 3des
 hash md5
 authentication pre-share
 group 2
crypto isakmp key extranet address 201.1.1.1
!
!
crypto ipsec transform-set extranet-trans esp-3des esp-md5-hmac
!
!<#--Static crypto maps, sourced from a loopback address for stability-->
crypto map extranet local-address Loopback192
crypto map extranet 10 ipsec-isakmp
 set peer 201.1.1.1
 set transform-set extranet-trans
 match address 111
!
!
!
!
interface Loopback111
 ip address 111.1.1.1 255.255.255.0
!
interface Loopback192
 ip address 192.168.111.1 255.255.255.0
!
interface Serial0/0
 ip address 200.1.1.2 255.255.255.252
 encapsulation frame-relay
 no fair-queue
 clockrate 128000
 frame-relay interface-dlci 201
 crypto map extranet
!
access-list 111 permit ip any 192.168.1.0 0.0.0.255

Example 12-6 illustrates some basic techniques that administrators can use to verify the operation of a dynamic crypto map configuration such as the one on AS1-7304A.

Example 12-6 illustrates the dynamic IPSec SA using the dynamic crypto map referenced in Example 12-4. The protected VRF (proxy) noted in the IPSec SA is consistent with the access list referenced in the dynamic crypto map of Example 12-4. The remote peer, 192.168.111.1, was learned dynamically. The IPSec SA is built from the IPSec headend loopback interface to the dynamically learned remote peer, 192.168.111.1. It is important to note that sourcing Phase 1 and 2 SAs from the router's loopback behavior represents a departure from the default behavior, which is to source the IPSec tunnel from the physical interface to which the crypto map is bound. The encryption/decryption statistics for this SA show that five Internet Control Message Protocol (ICMP) messages were sent across the IPSec tunnelfour were encrypted and their responses were decrypted while the first was dropped during the negotiation of Phase 1 and 2 SAs.

Example 12-6. Verifying the Dynamic Crypto Maps

AS1-7304A#show crypto ipsec sa
 interface: Serial0/0
     Crypto map tag: extranet, local addr. 201.1.1.1
    protected vrf:
    local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
    remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
    current_peer: 192.168.111.1:500
      PERMIT, flags={}
     #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
     #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
     #pkts compressed: 0, #pkts decompressed: 0
     #pkts not compressed: 0, #pkts compr. failed: 0
     #pkts not decompressed: 0, #pkts decompress failed: 0
     #send errors 0, #recv errors 0
      local crypto endpt.: 201.1.1.1, remote crypto endpt.: 192.168.111.1
      path mtu 1500, media mtu 1500
      current outbound spi: ACD63558

      inbound esp sas:
       spi: 0x1EDD5D8D(517823885)
         transform: esp-3des esp-md5-hmac ,
         in use settings ={Tunnel, }
         slot: 0, conn id: 2000, flow_id: 5, crypto map: extranet
         crypto engine type: Software, engine_id: 1
         sa timing: remaining key lifetime (k/sec): (4474400/1132)
         ike_cookies: 0636F569 27CE6A48 BC7118C8 F037E068
         IV size: 8 bytes
         replay detection support: Y

      inbound ah sas:

      inbound pcp sas:

      outbound esp sas:
       spi: 0xACD63558(2899719512)
         transform: esp-3des esp-md5-hmac ,
         in use settings ={Tunnel, }
         slot: 0, conn id: 2001, flow_id: 6, crypto map: extranet
         crypto engine type: Software, engine_id: 1
         sa timing: remaining key lifetime (k/sec): (4474401/1130)
         ike_cookies: 0636F569 27CE6A48 BC7118C8 F037E068
         IV size: 8 bytes
         replay detection support: Y

      outbound ah sas:

      outbound pcp sas:

The output in Example 12-7 verifies the operation of the crypto engine as traffic is passed along the VPN path. Note that four packets were decrypted/received from the remote host to initiate tunnel negotiation and that four responses to the packets were encrypted on the return path. This is consistent with the traffic statistics in the IPSec SA diagnostic output in Example 12-6.

Example 12-7. Verifying Security Association Cryptographic Operations

AS1-7304A#show crypto engine connections active

  ID Interface            IP-Address      State  Algorithm           Encrypt  Decrypt
   3 Serial0/0            200.1.1.1       set    HMAC_MD5+3DES_56_C        0        0
2000 Serial0/0            200.1.1.1       set    HMAC_MD5+3DES_56_C        0        4
2001 Serial0/0            200.1.1.1       set    HMAC_MD5+3DES_56_C        4        0


Tunnel Endpoint Discovery

Tunnel Endpoint Discovery (TED) is a logical extension to the dynamic crypto maps that allows an endpoint to dynamically, proactively discover a previously unknown peer. TED therefore allows peers to proactively initiate the negotiation of IPSec tunnels with unknown peers when the local peer is brought online.

TED accomplishes these tasks by sending TED probes out of the local VPN endpoint's crypto-enabled interfaces. The remote peer does not need to have TED configured in order to be discovered by inbound TED probes. As we will see when configuring TED, VPN devices that receive TED probes on interfaces that do not have TED configured can successfully negotiate a dynamically initiated tunnel using TED. We will use Figure 12-4 to demonstrate how a TED-enabled router can dynamically determine the remote endpoint.

Figure 12-4. Using TED to Initiate IPSec VPN Tunnel Negotiation

[View full size image]

In the extranet topology configured in Figure 12-4, a host on the extranet partner site wants to communicate with a server on the central campus. The extranet partner's local VPN endpoint, however, does not know the peer address with which to build a tunnel. Instead, TED has been enabled on the extranet partner router so that the peer address can be dynamically discovered through the following steps (also referenced in Figure 12-4):

1. | A host wants to communicate securely with a resource on the opposite end of a VPN connection (to be created) and begins sending packets to the destination.
2. | The host's local VPN gateway receives the packet, then checks its source and destination IP (s=111.1.1.100, d=201.1.1.100) against the crypto-protected address space defined in its configured crypto ACLs.
3. | If the VPN gateway finds a match against its configured crypto ACLs, it sends a TED probe with the original source (111.1.1.100/24) and destination (201.1.1.100/24) IP addresses in the payload out of its crypto-enabled interfaces.
4. | The router or VPN appliance on the remote side receives the TED probe, decapsulates it, and checks the source and destination address in the payload of the TED probe against its own crypto-protected address space in its own locally configured crypto ACLs.
5. | If the remote endpoint finds a match in Step 4, it sends a TED reply containing layer 3 addressing information of the destination to the original source (s=201.1.1.100/24, d=111.1.1.100/24).
6. | The local endpoint at the extranet site checks the TED reply against its crypto-protected address space in its crypto ACLs for a potential match.
7. | If the address space in the TED reply matches those in the local endpoint's crypto ACLs, the local crypto endpoint initiates IKE negotiation with the peer that sent the TED reply.

In the next section, we will explore TED configuration and verification steps required. The configurations will follow the steps and dynamic crypto map procedures outlined previously in this chapter.

TED Configuration and Verification

In this configuration, we will discuss enabling TED as well as the appropriate steps to take when verifying IPSec VPN operation using TED. As illustrated in Example 12-8, TED is only allowed on dynamic crypto maps. As a result, the only two prerequisites for the use of TED are the use of ISAKMP (TED is not supported with manual IPSec keying) and the use of dynamic crypto maps.

Example 12-8. Enabling Tunnel Endpoint Discovery

AS1-7304A#
!
!#<--When referencing a dynamic crypto map in a static crypto map entry,
!specifying the "discover" keyword enables the transmission of TED probes
!on physical interfaces where the static crypto map is applied.-->
crypto map extranet 10 ipsec-isakmp dynamic extranet-dyn discover

Enabling TED in this fashion allows AS1-7304A to initiate IPSec tunnel negotiation with AS113-3745A. Without TED, traffic tagged as IPSec on AS1-7304A would be dropped if a remote peer had not initiated a VPN connection previously. With TED, however, this IPSec-tagged traffic would initiate ISAKMP Phase 1 negotiation to the remote peer, and traffic would therefore not be dropped.


Case StudyUsing Dynamic Addressing with Low-Maintenance Small Home Office Deployments

In this case study, we will discuss a large enterprise IPSec VPN deployment. The enterprise, in this case, is a large insurance provider that services customers nationally. In order to increase their scope of coverage and to keep operational expenses down, the provider is primarily comprised of small branch offices throughout the country. Additionally, the insurance provider has a pilot program that allows agents the opportunity to contract independently with the firm. As a result, the enterprise network must accommodate secure connectivity from a large number of small home offices. When data is transferred from the small branch offices and small office/home office (SOHO) environments to administration databases at the corporate campus headquarters, it is required by law to be done so with confidentiality. Therefore, the insurance provider has decided to invest in a highly flexible and scalable architecture for delivering confidential data transfer between small branches and SOHO environments and the corporate campus network.

Of paramount importance to this discussion is the fact that the deployment of VPN endpoints to the thousands of SOHO and branch offices relies on dynamic crypto map usage at the headend. Dynamic crypto maps are required for the following reasons:

  • Agents do not manage the configuration of the VPN endpoints furnished by the firm. Instead, the configuration must be centrally managed by the insurance provider, limiting the involvement of the agent in the deployment process to strict "plug-and-play" behavior.

  • The firm realizes that numerous SOHO VPN deployments can lead to a high degree of change as agents move houses or locations within their region of coverage. The VPN deployment must therefore be able to dynamically reconfigure itself whenever there is such a change.

  • The NMS capabilities at the central site have no means by which to "push" the entire IPSec configuration to the VPN endpoints. Instead, the devices are minimally bootstrapped, and the user is simply instructed to enter a username/password for x-auth during IKE Phase 1 (see next requirement). This process is referred to as Easy Secure Device Deployment (EzSDD).

  • Because the deployment uses a combination of dynamic crypto maps and wildcard PSKs for IKE Phase 1 negotiation, Each VPN endpoint will perform x-auth at IKE "Phase 1.5." This enables the network administrators to "evict" agents from the deployment securely without compromising the authentication materials used when authenticating the IKE SA.

To meet these needs, the firm has decided to deploy a dynamic crypto map at the headend router. The VPN endpoints at agent offices are dynamically bootstrapped when they are installed at the remote location. To accomplish this, each device is minimally configured using EzSDD to initiate the bootstrap process with minimal assistance from the agent at the remote office. The agent's routers are therefore drop-shipped directly from Cisco Systems or their chosen reseller with EzSDD enabled by default. This allows the agent to simply plug in and power up the router, then follow several simple instructions on their web browser while connected to the router's LAN port.

Once the agent receives the drop-shipped router at their remote branch location, they power up the router, attach it to the cable or DSL modem supplied by their service provider, attach their workstation to an Ethernet port on the LAN side of the router and open a web browser to the HTTP server running on the supplied router. The agent follows several minimal instructions over the presented web interface on their workstation to complete the configuration of their crypto endpoint. This process is commonly referred to as Trusted Transitive Introduction (TTI), consisting of three components:

  • Introducer A device that is trusted by both the petitioner and the registrar. In this case, the introducer would be the insurance agent.

  • Petitioner A new crypto endpoint that wishes to enroll in the PKI. In this case, the petitioner is the EzSDD endpoint that was drop-shipped directly from Cisco Systems or the selected reseller.

  • Registrar A cryptographic device that is used to authorize access of new petitioners to the network. In this case, the registrar is the firm's CA.

Figure 12-5 illustrates the TTI process between a remote site acting as a petitioner and registrar on the firm's enterprise network.

Figure 12-5. EzSDD Trusted Transitive Introduction Process

[View full size image]

Phase 1 is referred to as the Welcome Phase. The agent connects their VPN gateway to their service provider. The device gets an IP address via DHCP and is now capable of contacting the registrar at the firm's corporate HQ to request an enrollment. In this phase, the agent initiates either an HTTP or HTTPS session to the web server enabled on their new router.

Note

Of critical importance to this design is the use of DHCP in the initial bootstrap configuration. Because this configuration relies on DHCP to determine its IP address, it is difficult for the firm to deploy static crypto maps at the headend (the peer would have to have been defined).

When the petitioner's HTTP server sees the session initiation come in from the introducer, it automatically generates the cryptographic keys required to enroll in the PKI. Likewise, a partial trustpoint (labeled TTI) is generated to facilitate this enrollment. Figure 12-6 illustrates the Welcome Phase web browser interface to the TTI process.

Figure 12-6. TTI Welcome Phase Generation of Cryptographic Keys

[View full size image]

The corresponding cryptographic keys are created on the petitioner, as illustrated in Example 12-9. When the introducer authenticates to the petitioner, the agent's VPN gateway in this case, the petitioner installs a 1024-bit (default modulus) RSA keypair for future use when authenticating IKE Phase 1 using the RSA Signatures method of authentication. Output from the running configuration reflects the creation of a trustpoint for enrollment to the PKI using TTI and is also shown in Example 12-9.

Example 12-9. Automatic Petitioner Configuration Elements During the TTI Welcome Phase.

Router#
Jul  1 12:49:02.131: %SSH-5-ENABLED: SSH 1.99 has been enabled
Jul  1 12:49:02.131: %CRYPTO-6-AUTOGEN: Generated new 1024 bit key pair
Router#
Router#show crypto key mypubkey rsa
% Key pair was generated at: 12:49:02 UTC Jul 1 2005
Key name: tti
 Usage: General Purpose Key
 Key is not exportable.
 Key Data:
  30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00CDA621
  6A21BAA1 D65FFB0C 4C4839D2 19377EAD D10A180D 5ECDD28D 8081FF70 8618E341
  6629D0BF FF2F2655 B38B8957 65D7002F F04C08BE DDE0846F C39B5943 193A2BDA
  49075218 B1837622 37E40173 513841B5 EEB57CCF 55D216D8 9B56FB7C 23B61125
  D57A8327 2E8C399B 6479B982 9AB684F2 9CBAD06A 0E7126E4 3E32EB8D 8B020301 0001
% Key pair was generated at: 12:49:02 UTC Jul 1 2005
Key name: tti.server
 Usage: Encryption Key
 Key is not exportable.
 Key Data:
  307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00E1E40D 0CC98F6B
  CFC7D37F 6DEA0068 1AD55330 475CA9DE C2136964 DFFB8A79 259F634D 8187F927
  7BB42F39 66ACEF42 80EA530B 0B3B46E0 C6F9B7F3 B01CFFDE 0172D1C7 7EDB94C1
  F514F15A EC8E94F9 0893FCBF 387382E2 E726E95D 1F37D6A0 41020301 0001
Router#
Router#sh run
Building configuration...

Current configuration : 1453 bytes
!
!<--Configuration Truncated-->
!
!<--The EzSDD petitioner installs a trustpoint to use when enrolling in the PKI
!in later phases of the TTI process-->
crypto pki trustpoint tti
 revocation-check crl
 rsakeypair tti
!
!<--Configuration Truncated-->
!
end

In the final stages of the EzSDD TTI Welcome Phase, the agent is prompted to enter the website used on the registrar to enroll their cryptographic endpoint into the secure domain. Figure 12-7 displays the instance in which the agent provides the TTI process with the URL necessary to transition from the Welcome Phase to the Introduction Phase.

Figure 12-7. EzSDD Transition from Welcome Phase to Introduction Phase

[View full size image]

Phase 2, called the Introduction Phase, is executed when the introducer (in this case, the insurance agent) is ready to authenticate their crypto endpoint on the registrar. Once the registrar's website is entered, as in Figure 12-7, the petitioner will be prompted for a username and password, if required. In this case, the registrar is configured to use an external AAA database via RADIUS, such as Cisco Secure ACS, which in turn uses the firm's MS Active Directory backend infrastructure to validate the authentication credentials. Figure 12-8 illustrates the next step in the TTI Introduction Phase, providing confirmation that the agent's credentials have been accepted by the registrar.

Figure 12-8. EzSDD Introduction Phase Registrar Credential Confirmation

[View full size image]

At this point, the registrar and petitioner have been successfully introduced, and the petitioner can therefore receive its configuration from the petitioner and enroll with the PKI. This is done in the third and final phase of the EzSDD TTI process, the Completion Phase. Figure 12-9 illustrates the completion of the TTI process for a remote branch, Branch-Florida15. At this point Branch-Florida15 has a full working configuration, and has successfully enrolled in the PKI.

Figure 12-9. EzSDD Completion Phase

[View full size image]

It is important to note that the registrar must be configured to support the authentication requests, configuration requests and pushes, and the certificate enrollment requests inbound from the petitioner. Upon successful authentication, the remote VPN gateway or TTI petitioner at the agent's site requests a configuration from the database. The configuration database pushes the configuration to the remote VPN gateway, including routing protocol configuration, IPSec configuration, device AAA information, and x-auth configuration.

Note

At this point, the agent's VPN gateway (petitioner) should be capable of temporarily negotiating a Phase 1 SA with the IPSec aggregation headend in the campus network at corporate headquarters. It is important to note that the VPN aggregation headend will use dynamic crypto maps, since the remote petitioner IP address are not known in advance. This enables the aggregation headend to accommodate the introduction of petitioners into the PKI dynamically, without manual configuration or maintenance from the firm's IT staff.

Phase 3, the Completion Phase of the TTI process, consists mainly of the user enrolling with the PKI. Phase 3 is facilitated with the automatically generated keying material and trustpoint configuration obtained in Phases 1 and 2, accordingly. The introducer will be notified that the TTI process has been completed successfully on the web interface presented on their workstation. Figure 12-10 provides output from the Completion Phase of the TTI process, including the running configuration downloaded to the petitioner.

Figure 12-10. Branch-Florida15 Configuration Verification Using TTI

[View full size image]

Upon completion of these steps, IPSec and ISAKMP SAs can be established between the remote IPSec VPN gateway and the IPSec headend gateway. The configurations in Examples 12-10 and 12-11 illustrate the required configuration on the branch (TTI petitioner) and headend IPSec VPN gateways, respectively. Observe that while both VPN endpoints in this case study use static crypto maps, the headend router at the corporate headquarters must use a dynamic crypto map to accommodate the various agent SOHO devices. This element of the overall architecture exists primarily because the headend will never initiate Phase 1 negotiation to the branch. Instead, the branch will always initiate Phase 1 negotiation to the headend. This allows the dynamic crypto map at the headend to learn about remote peers with no additional configuration as the agents bring their IPSec gateways online.

Example 12-10. Low-Touch SOHO and Small Branch IPSec VPN Endpoint DeploymentsRemote IPSec VPN Endpoint/Petitioner Final Configuration

hostname Branch-Florida15
!
!<--This DHCP pool serves allows the Agent's workstations to dynamically learn
!their IP addresses and default gateways, DNS servers, and domain names when
!they attach to the network. This pool consists of non-routable IP address
!space and is therefore translated before leaving the agents LAN-->
!
ip dhcp pool rem-net
   network 192.168.1.0 255.255.255.0
    default-router 192.168.1.1
!
!<--This is the trustpoint used for enrolling this agent's VPN gateway into
!the PKI. The certificates obtained from the CA will be used to authenticate
!the agent's VPN gateway during Phase 1 negotiation with the headend router-->
!
crypto pki trustpoint tti
 enrollment url http:// IS-VPNConc-A:80
 serial-number
 revocation-check crl
 rsakeypair tti
!
!<--The following ISAKMP policy uses the IOS default authentication
!method  RSA Signatures. This method is required when using EzSDD-->
crypto isakmp policy 10
!
!
crypto ipsec transform-set field-transform esp-3des esp-sha-hmac
!
!<--The agent's VPN gateway is served a configuration from the Registrar via
!secure HTTP during the EzSDD Trusted Transitive Introduction process.
!The configuration attained can be based on authentication with a
!backend database. In this case, the agent authenticated as an agent based
!in Florida and was served a configuration for 'Branch-Florida15'.
!Note that while this gateway can use a static crypto map, as the remote peer
!is known, the headend router cannot as the configuration of this branch
!router is unknown until it attains its configuration via TTI.-->
crypto map Branch-Florida15 10 ipsec-isakmp
 set peer 200.1.1.1
 set transform-set field-transform
 match address 101
!
interface FastEthernet0/0
 ip address 200.1.1.23 255.255.255.0
 ip virtual-reassembly
!<--Defines the outside NAT interface-->
 ip nat outside
 speed auto
 full-duplex
 crypto map Branch-Florida15
!
interface FastEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 ip virtual-reassembly
!<--Defines the inside NAT interface-->
 ip nat inside
 speed auto
 full-duplex
!
ip classless
!
!
!<--The server configuration is required for EzSDD. This configuration uses
!local authentication to authenticate the petitioners. HTTPS is used to secure
!the communication between the introducer and the petitioner and registrar.
!When HTTPS is used, the secure-trustpoint command must also be entered to
!ensure interoperability with the defined trustpoint PKI.-->
ip http server
ip http authentication local
ip http secure-server
ip http secure-trustpoint
!
!<--NAT is being used to maintain Layer 3 connectivity between the agent's
!devices using non-routable IP address space and the enterprise resources on
!the opposite end of the IPSec VPN. Note that the Service Provider will not
!route non-routable address space, and that their publicly routed domain is
!used for all communications between the agent's remote site and the Firm's
!Enterprise Network. In this case, NAT is set up to translate any address in
!the 192.168.0.0/16 address space on Fa0/1 into the IP address assigned to
!Fa0/0 (200.1.1.1). This configuration uses ports to distinguish between
!multiple hosts translating to the same address, 200.1.1.1-->
ip nat inside source list 1 interface FastEthernet0/0 overload
!
!<--ACL 1 defines the inside local address space to be translated into
!200.1.1.1 (the IP address assigned to Fa0/0-->
access-list 1 permit 192.168.0.0 0.0.255.255
!<--ACL 101 defines the address space to be included in the crypto switching
!path (encrypted with IPSec). It is important to note that traffic from the
!source of 200.1.1.1 is encrypted, not 192.168.0.0/16. This is due to the fact
!that encryption decisions occur after NAT decisions. As such, if the ACL were
!to include 192.168.0.0/16 as the source, the traffic from the agent's remote
!site would not be processed in the crypto switching path and ISAKMP would
!never initiate Phase 1 negotiation-->
access-list 101 permit ip host 200.1.1.1 any
!
End

The configuration shown in Example 12-11 illustrates a sample configuration of the headend router in this case study. Remember that this case study was written to illustrate the need for dynamic crypto maps. Note that without the dynamic crypto map on IS-VPNConc-A in Example 12-11, each remote user would require their own static crypto map entry on IS-VPNConc-A. The use of dynamic crypto maps on the headend, however, allows IS-VPNConc-A to learn about its peers dynamically as they are brought online by the insurance agents at the remote sites. This greatly reduces the configuration and administration costs required to support the overall remote access VPN (RAVPN) system, ultimately resulting in drastically reduced operating expenses for the firm.

Example 12-11. Low-Touch SOHO and Small Branch IPSec VPN Endpoint DeploymentsHeadend IPSec Concentrator/Registrar

hostname IS-VPNConc-A
!
ip domain name cisco.com
!
!
!<--This is the PKI server used to enroll new VPN gateways at agent remote sites
!into the PKI during the EzSDD TTI. It is set up to automatically grant
!certificates to its requestors. This parameter can be manually changed to
!require an administrator to grant each certificate request as it comes
!in from the requestor.-->
crypto pki server cs1
 grant auto
!
!<--IOS will automatically install a trustpoint for the corresponding
!certificate server once the certificate server is administratively
!enabled (no shut)-->
crypto pki trustpoint cs1
 revocation-check crl
 rsakeypair cs1
!
!<--Because this headend is also serving as a Registrar and Certificate
!Authority, this trustpoint was configured to obtain a certificate to use to
!negotiate IKE Phase 1 SAs with the remote peers. In reality, the certificate
!authority and registrar would be bundled together on a separate device.
!This trustpoint configuration would still be required to enroll the
!Headend router in the PKI.-->
crypto pki trustpoint IS-VPNConc-A
 enrollment url http://IS-VPNConc-A:80
 serial-number
 ip-address FastEthernet0/1
 revocation-check none
 rsakeypair 1024
!
!
!<--The following registrar configuration is required for EzSDD Petitioners
!(Agent Remote VPN Gateways) to obtain their final configuration.
!This registrar uses the PKI server cs1 (via the trustpoint configuration
!on this router), and instructs the petitioner and introducer to obtain the
!petitioner configuration on the http server "confserv-main" which resides
!on the enterprise network DMZ-->
crypto provisioning registrar
 pki-server cs1
 template config http://confserv-main/Branch-Florida15-confg
username remuser1 privilege 15 password 0 cisco
!
!<--The following ISAKMP policy uses the IOS default authentication
!method  RSA Signatures. This method is required when using EzSDD-->
crypto isakmp policy 10
!
!
crypto ipsec transform-set RAVPN-trans esp-3des esp-sha-hmac
!
!<--Dynamic crypto maps are used when the addresses of remote peers are
!unknown in advance. In this case, because the remote peers are obtaining
!their IP addresses dynamically from the service provider, the administrators
!of the VPN concentrator do not know the remote peers in advance. Therefore a
!dynamic crypto map is used to "learn" the peer's IP addresses after they are
!brought online by the agent via the TTI process-->
crypto dynamic-map RAVPN-dyn 10
 set transform-set RAVPN-trans
!
!
!<--To apply a dynamic crypto map, it must first be referenced
!in a static crypto map-->
crypto map RAVPN-stat 10 ipsec-isakmp dynamic RAVPN-dyn
!
!
interface FastEthernet0/1
 ip address 200.1.1.1 255.255.255.0
 duplex auto
 speed auto
!<--The static crypto map referencing the dynamic crypto map is applied to
!the appropriate crypto interface-->
 crypto map RAVPN-stat
!
!<--The server configuration is required for EzSDD. HTTPS is used to secure the
!communication between the introducer and the petitioner and registrar.
!When HTTPS is used, the secure-trustpoint command must also be entered
!to ensure interoperability with the defined trustpoint PKI.-->
ip http server
ip http secure-server
ip http secure-trustpoint
!
End

In this example, the headend router (IS-VPNConc-A) acts as the registrar for the EzSDD trusted transitive introduction process. In reality, the registrar will reside on another, separate IOS-based RA or CA within the enterprise network. Because the focus of this chapter is on dynamic crypto maps, the EzSDD registrar functionality is configured on the headend router for simplicity.

Note

For more information on EzSDD, log on to the following CCO resource with a valid user account:

http://www.cisco.com/en/US/partner/tech/tk583/tk372/technologies_white_paper0900aecd80128d1f.shtml

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_feature_guide09186a008028afbd.html

Once the EzSDD process has completed, the user can then verify the establishment of the IPSec tunnel between the newly introduced router of the secure domain at the agent site and the headend router. Example 12-12 shows that the two crypto endpoints have established Phase 1 and Phase 2 SAs successfully. Note that the source of the SAs (the agent's IPSec VPN gateway) is randomly attained via service provider's DHCP server, rendering it impossible to manually configure the remote peer statically on the firm's headend VPN routera dynamic crypto map must be used to learn the remote peer's address when the agent's VPN gateway comes online.

Note

Although the VPN gateway at the remote site technically uses a static crypto map to manually define the peer IP of the VPN concentrator on the enterprise network, it is not initially configured as such. Instead, this address is provided to the VPN gateway (the petitioner) during the EzSDD TTI process, along with the full configuration of the router. The router is also enrolled in the enterprise's PKI during this process.

Example 12-12 shows the establishment of Phase 1 and 2 SAs on the IPSec headend router, 3745-Registrar. The source of the Phase 1 SA below is dynamically learned via the TTI process. Also note the consistency of the source IP addresses in the Phase 1 and 2 SAsthe source IP address of the remote peer (TTI petitioner) is the same as the dynamically learned source IP address in the Phase 1 SA.

Example 12-12. Verifying SA Establishment on the IPSec Headend

3745-Registrar#show crypto isakmp sa
dst             src             state          conn-id slot status
200.1.1.1       200.1.1.23      QM_IDLE             24    0 ACTIVE

3745-Registrar#show crypto ipsec sa

interface: FastEthernet0/1
    Crypto map tag: campus-stat, local addr 200.1.1.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
   remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   current_peer 200.1.1.23 port 500
     PERMIT, flags={}
    #pkts encaps: 307, #pkts encrypt: 307, #pkts digest: 307
    #pkts decaps: 307, #pkts decrypt: 307, #pkts verify: 307
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0
     local crypto endpt.: 200.1.1.1, remote crypto endpt.: 200.1.1.23
     path mtu 1500, ip mtu 1500
     current outbound spi: 0x1C5F47BE(476006334)

     inbound esp sas:
      spi: 0x46C2BDC4(1187167684)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2003, flow_id: AIM-VPN/HPII:3, crypto map: campus-stat
        sa timing: remaining key lifetime (k/sec): (4459514/2316)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x1C5F47BE(476006334)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2004, flow_id: AIM-VPN/HPII:4, crypto map: campus-stat
        sa timing: remaining key lifetime (k/sec): (4459514/2314)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:
3745-Registrar#


Summary

As workforces become increasingly mobile in nature, so does the need to gain secure network access from a varying physical locations. Dynamic peers allow network administrators to ensure network connectivity when remote network peers are either not known in advance or change to an unknown value over time. Dynamic peers also require less administrative effort than do static peers. Dynamically IPSec peer addressing has therefore become an increasingly popular design alternative in many large-scale enterprise IPSec VPN designs and in RAVPN designs. In this chapter, we have discussed the design issues that arise when supporting dynamically addressed peers in an IPSec VPN design, including:

  • Added support within ISAKMP for dynamically addressed peers

  • Impact of dynamically addressed peers on the routed infrastructure

  • Security considerations for dynamically addressed peers

We have also discussed the added features for addressing these fundamental design considerations, including the use of dynamic crypto maps, tunnel endpoint discovery, IKE Extended Authentication (x-auth), and IKE Mode Config. Effective IPSec VPN designs that employ the use of dynamically addressed peers commonly use many of these solution components.

Dynamic crypto maps are central to the support of dynamically addressed peers, since no manual specification of a peer within the dynamic crypto map configuration is required. The chapter covers the use of dynamic crypto maps in IPSec headend configurations in extranet deployments and in large-scale branch and SOHO deployments. When a dynamic crypto map is used in conjunction with a static crypto map on the remote IPSec endpoint, only the remote IPSec VPN endpoint can initiate the negotiation of the IPSec VPN tunnel unless TED is used. TED allows an IPSec VPN endpoint such as the one described above to dynamically discover its remote IPSec VPN tunnel endpoint through the exchange of TED probes.

The changes brought forward by IKE Extended Authentication (x-auth) can be used to provide more granularity when authenticating a dynamically addressed peer. IKE x-auth occurs in addition to the negotiation of IKE itself and is very effective at eliminating group eviction difficulties that commonly arise from authenticating IKE with wildcard preshared keys. Refer to the previous discussion of IKE wildcard preshared keys for more discussion on this very important design consideration. IKE Mode Config can be used to assign a remote IPSec VPN endpoint various configuration elements, including the remote IPSec VPN endpoint's IP address, as part of IKE Phase 1 negotiation.


Appendix A. Resources

    Books

    RFCs

    Web and Other Resources


Books

Applied Cryptography, 2nd Edition, Bruce Schneier, John Wiley and Sons, Inc. 1996

Designing Network Security, M. Kaeo, Cisco Press, 1999


RFCs

RFC 2105: Internet X.509 Public Key Infrastructure, C. Adams, S. Farrell, http://www.ietf.org/rfc/rfc2510.txt, March 1999

RFC 2246: The TLS Protocol Version 1.0, T. Dierks, C. Allen, IETF, http://www.ietf.org/rfc/rfc2246.txt, January 1999

RFC 2395: IP Payload Compression Using LZS, R. Friend, R. Monsour, IETF, http://www.ietf.org/rfc/rfc2395.txt, December 1998

RFC 2401: Security Architecture for the Internet, S. Kent, R. Atkinson, IETF, http://www.ietf.org/rfc/rfc2401.txt, November 1998

RFC 2402: IP Authentication Header (AH), S. Kent, R. Atkinson, IETF, http://www.ietf.org/rfc/rfc2402.txt, November 1998

RFC 2406: IP Encapsulating Security Payload (ESP), S. Kent, R. Atkinson, IETF, http://www.ietf.org/rfc/rfc2406.txt, November 1998

RFC 2408: Internet Security Association and Key Management Protocol, D. Maughan, M. Schertler, M. Schneider, J. Turner, IETF, http://www.ietf.org/rfc/rfc2408.txt, November 1998

RFC 2409: The Internet Key Exchange, D. Harkins, C. Carrel, IETF, http://www.ietf.org/rfc/rfc2409.txt, November 1998

RFC 2412: The Oakley Key Determination Protocol, H. Orman, IETF, http://www.ietf.org/rfc/rfc2412.txt, November 1998

RFC 2560: Online Certificate Status Protocol, M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, http://www.ietf.org/rfc/rfc2560.txt, June 1999

RFC 2631: Diffie-Hellman Key Agreement Method, E. Rescorla, IETF, http://www.ietf.org/rfc/rfc2631.txt, June 1999

RFC 2748: Generic Routing Encapsulation (GRE), D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, IETF, http://www.ietf.org/rfc/rfc2784.txt, March 2000

RFC 3526: More Modular Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE), T. Kivenen, M. Kojo, http://www.ietf.org/rfc/rfc3526.txt, May 2003

RFC 3546: TLS Security Extensions, S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright, IETF, http://www.ietf.org/rfc/rfc3546.txt, June 2003


Web and Other Resources

Cisco Secure Consulting Services (Security Wheel), http://www.cisco.com/warp/public/cc/serv/mkt/sup/advsv/pavsup/sposass/cscsb_br.pdf

Configuring IKE Extended Authentication, http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1834/products_feature_guide09186a008007feb8.html

Designing and Implementing a Secure Network Infrastructure, M. Kaeo, NANOG, http://www.nanog.org/mtg-0310/pdf/kaeo.ppt, October 2003

How TLS/SSL Works, http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/c22a4d3d-6335-4b9b-b344-bbae041203b4.mspx

Internet Draft: Simple Certificate Validation Protocol, T. Freeman, R. Housley, A. Malpani., http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-16.txt, October 2004

Internet Key Exchange Mode Config, http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5014/products_feature_guide09186a0080088172.html

Office for Civil RightsHIPAA, http://www.hhs.gov/ocr/hipaa/

PKI BasicsA Technical Perspective, Shashi Kiran, Patricia Lareau, Steve Lloyd, PKI Forum, http://www.pkiforum.org/pdfs/PKI_Basics-A_technical_perspective.pdf, 2002

Security of the MPLS Architecture, http://www.cisco.com/en/US/partner/tech/tk436/tk428/technologies_white_paper09186a00800a85c5.shtml

Software IPPCP (LZS) with Hardware Encryption, http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110c00.html

SSL/TLS Case Study, http://www.stanford.edu/class/cs259/lectures/02-SSL.pdf


Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]


SYMBOL

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

3DES (triple data encryption standard),


A

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

aggressive mode negotiation,
AH (Authentication Headers), 2nd
alternatives to IPsec VPN HA,
stateful
stateless
HSRP,
RRI,
applying crypto maps in SOHO environments,
asymmetric cryptography,
asymmetric key encryption, 2nd
impact on CPU processing
asymmetric routing as cause of broken VPN tunnels,
authentication errors (IKE), troubleshooting,
authentication services (IKE)
preshared keys
RSA encryption
RSA signatures
X.509 certificates
authentication,
of public key certificates


B

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

BGP (Border Gateway Protocol), crypto path availability,
business drivers for VPNs,
remote access VPNs
site-to-site VPNs


C

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

CA hierarchy configuration, case study,
CAs (Certificate Authorities), 2nd
enrollment process
RA interoperability, configuring
case studies, PKI
CA hierarchy
configuring CA/RA interoperability
cryptographic endpoint integration
CBC (cipher block chaining),
CBWFQ (class-based weighted fair queuing), impact of IPsec on,
CE (customer edge) routers,
characteristics of effective VPNs,
cipher text,
ciphers,
Cisco IPSec VPN 3000 series concentrators,
Cisco Security Wheel,
Cisco VPN 3000 series concentrators, clustering,
clustered spoke VPN design,
clustered VPN concentrator designs,
commands, redistribute static, 2nd
comparing In-Path and Out-of-Path encryption, 2nd
compulsory tunnels,
concentrator clustering,
configuring
CA hierarchy, case study
CA/RA interoperability, case study
crypto maps
dynamic crypto maps
geographic HA
DMVPNs,
IPsec+GRE, 2nd
RRI with multiple IPsec peers,
ISAKMP
RAVPN HA
DNS-based load balancing,
using multiple IPsec peers, 2nd
with HSRP,
with VCA,
with VRRP,
site-to-site VPNs
TED
control messages,
creating
message digests
transforms
CRLs,
scalability
crypto ACLs,
mismatches, troubleshooting
crypto engines,
crypto maps,
configuring
multiple peering statements, tunnel termination HA
crypto path availability,
cryptographic endpoints,
cryptographic key derivation (SSL VPNs),
CSM (Content Switch Module), external load balancing,


D

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

data authentication,
data confidentiality,
in VPDN deployments
data integrity, 2nd
decryption,
deployment models
hub-and-spoke VPNs
clustered spoke design,
redundant clustered spoke design,
IPsec+GRE
sample configurations,
tunnel establishment, verifying,
RAVPNs
clients,
clustered VPN concentrator designs,
standalone VPN concentrator designs,
site-to-site VPNs
configuring,
over routed domain,
verifying configuration,
DES (data encryption standard),
Diffie, Whitfield,
Diffie-Hellman
key exchange
secret key generation 2nd
DiffServ, impact of IPsec on,
digital signatures, generating,
distribute lists,
DMVPNs (Dynamic Multipoint VPNs), 2nd
geographic HA, configuring
DNS server load balancing,
in RAVPNs with geographic HA
DPD (Dead Peer Detection),
peer availability
dual-DMZ tunnel termination, 2nd
dynamic crypto maps,
and RRI
applying in SOHO environments
configuring
impact on ISAKMP/IKE
impact on VPN behavior
routing considerations
security considerations
key administration and scalability,
unrestricted peering and traffic flows,
TED
verifying


E

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

eliminating single points of failure for site-to-site VPNs,
enabling TED,
encryption,
asymmetric
In-Path versus Out-of-Path 2nd
Out-of-Path
symmetric 2nd
enrollment process,
for RSA signatures 2nd
for X.509 certficates 2nd
ESP (Encapsulating Standard Protocol),
confidentiality services
data integrity and authentication services
extensions for IKE
mode config
xauth
external load balancers,


F

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

failover
stateful HA failover process
stateless HA failover process
firewalled VPN environments
ICMP unreachables, troubleshooting
troubleshooting
tunnel termination
floating static routes,
flow-based QoS, impact of IPsec on,
format of L2F packets,
forwarding public key certificates,
fragmentation
on Cisco IOS VPN endpoints
PMTUD
preventing
with IPsec Prefragmentation,
with manual MTU adjustment,
Virtual Fragmentation Reassembly


G

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

generating
Diffie-Hellman secret keys
digital signatures
geographic HA,
DMVPNs
IPsec+GRE 2nd
RRI with multiple IPsec peers
goals of VPN implementation,
GRE-offload, 2nd [See also IPsec+GRE model.]
with cleartext firewall paths
with dynamic crypto maps
with high-speed tunnel termination
with IKE x-Auth


H

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

HA (High Availability)
geographic HA
DMVPNs,
IPsec+GRe,
RRI with multiple IPsec peers,
in RAVPNs
concentrator redundancy with multiple peers, 2nd
DNS-based load balancing,
HSRP,
VCA,
VRRP, 2nd 3rd
load-balanced designs
concentrator clustering,
DNS server load balancing,
external load balancers,
load sharing with peer statements,
routing,
peer availability
on-demand DPD,
SSO
stateful HA
alternatives to,
failover process,
stateless HA
alternatives to,
failover process,
tunnel termination redundancy
on HSRP/VRRP virtual interfaces,
using RP-based IPsec HA,
with multiple peer statements,
handshake process (SSL VPNs),
hardware-based VPN clients,
hashes,
Hellman, Martin,
HMAC (hashed message authentication codes), 2nd
home gateways,
HSRP (Hot Standby Routing Protocol),
RAVPN concentrator HA
timers, tuning
HSRP/VRRP virtual interfaces, tunnel termination point HA,
hub-and-spoke IPsec model,
clustered spoke design
site-to-site VPNs


I

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

ICMP messages
rate-limiting
unreachables, troubleshooting in firewalled VPN environments
identifying IPsec transform set mismatches,
IKE,
authentication errors, troubleshooting
authentication services
pre-shared keys,
RSA encryption,
RSA signatures,
X.509 certificates,
Diffie-Hellman secret key generation
keepalives, removing stale SAs from SADB
key mismatches, troubleshooting
mode config extension
Phase I negotiation
aggressive mode negotiation,
main mode negotiation,
Phase II negotiation
DPD,
IKE keepalives,
PFS,
quick mode negotiation,
SA negotiation and maintenance
SA proposal mismatches, troubleshooting
x-auth
xauth extension
impact of vendor interoperability on path availability,
In-Path encryption,
integrity,
IntServ, impact of IPsec on,
invalid SPI recovery,
IPComp,
IPPCP (IP Payload Compression Protocol),
IPsec Prefragmentation,
IPsec+GRE model, 2nd
geographic HA, configuring 2nd
sample configurations
tunnel establishment, verifying
ISAKMP,
configuring
ITU-T X.509v3compliant certificates,
IV (Initialization Vector),


K

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

keepalives (IKE),
key management
need for
PKI
CAs,
CRLs,
cryptographic endpoints,
public key certificates,
registration authorities,


L

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

L2F (Layer 2 Forwarding), home gateways,
L2TP (Layer 2 Tunneling Protocol)
control messages
payload packets
tunnel negotiation process
LAC (L2TP Access Concentrator),
lack of RP support, effect on IPS HA design,
Layer 2 Forwarding Protocol,
packet format
tunnel establishment process
life cycle of public key certificates,
RSA signatures 2nd
X.509 certificates 2nd
limitations of vendor HA interoperability
inability to specify multiple peers
lack of peer availability mechanisms
LLQ (low-latency queuing), impact of IPsec on,
LNS (L2TP Network Server),
load balanced designs
concentrator clustering
DNS server load balancing
configuring in RAVPNs with geographic HA,
external load balancers,
load sharing with peer statements,
routing,
load sharing with peer statements,
local IPsec HA,
Lookahead Fragmentation,
LZS (Lempel Ziv Stac),


M

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

main mode negotiation,
manual keying,
manual MTU adjustment, preventing fragmentation,
MD5 (Message Digest 5),
message digests, creating and verifying,
messages (ICMP), rate-limiting,
mismatched crypto ACLs, troubleshooting,
mismatched IKE SA proposals, troubleshooting, 2nd
mismatched transform sets, identifying,
mode config extension (IKE),
MODP (prime modulus),
MP-BGP (Multiprotocol Border Gateway Protocol),
MPLS VPNs,
VRFs
MPPE (Microsoft Point-to-Point Encryption),
MTUs (maximum transmission units), manual adjustment,


N

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

NAS (Network Access Server),
NAT (Network Address Translation)
SPI-based, troubleshooting
troubleshooting
NAT Detect,
NAT-on-a-stick, IPsec VPN tunnel termination,
NAT-T, troubleshooting,
NHRP (next hop routing protocol),
nonces,


O

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

obtaining public key certificates,
OCSP (Online Certificate Status Protocol),
"on-a-stick" designs,
NAT-on-a-stick
router-on-a-stick
on-demand DPD,
OSI reference model,
Out-of-Path encryption,


P

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

P (provider) routers,
packets, L2F,
path availability, 2nd
and vendor HA availability
path symmetry, managing,
payload packets,
PE (provider edge) routers,
peer availability, 2nd
on-demand DPD
peer mismatches (IKE), troubleshooting,
periodic DPD,
PFS (perfect forward secrecy), 2nd
PKI (Public Key Infrastructure),
CAs
case studies
CA hierarchy,
configuring CA/RA interoperability,
cryptographic endpoint integration,
CRLs
cryptographic endpoints
enrollment process
public key certificates
registration authorities
PMTUD (Path MTU Discovery),
PPTP (Point-to-Point Tunneling Protocol),
compulsory tunnels
data structure
tunnel negotiation process
voluntary tunnels
preshared keys,
preventing fragmentation
with IPsec Prefragmentation
with manual MTU adjustment
proxies,
PSKs (preshared keys), troubleshooting mismatched peer addresses,
public key certificates,
authentication
forwarding
life cycle of
obtaining
registration process
RSA signatures, life cycle of 2nd
signing
X.509 certificates, life cycle of 2nd
public key cryptography,
public key encryption,
Diffie-Hellman key exchange
RSA
RSA signatures


Q

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

QoS (quality of service), impact of IPsec on
DiffServ
flow-based
IntServ
quick mode negotiation,


R

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

RAs (registration authorities),
CA interoperability, configuring
rate-limiting ICMP messages,
RAVPNs (remote-access VPNs)
deployment model
clients,
clustered VPN concentrator designs,
standalone VPN concentrator designs,
HA
DNS-based load balancing,
geographic HA, DNS-based load balancing, 2nd
HSRP,
VCA,
VRRP, 2nd 3rd
reconvergence of routing protocols, impact on IPsec reconvergence,
recursive routing
effect on IPsec VPNs
symptoms of
redistribute static command, 2nd
redistribution
distribute lists
of VPN routes
redundant clustered spoke VPN design,
registration authorities,
CA interoperability, configuring
registration process for public key certificates,
remote-access VPNs
business drivers
SSL
removing stale SAs from SADB,
round-robin approach to DNS resolution,
route descriptors,
router-on-a-stick, IPsec VPN tunnel termination,
routing,
RP-based IPsec HA,
RRI (Reverse Route Injection),
and dynamic crypto maps
impact on vendor interoperability
RSA encryption, 2nd
IKE authentication errors, troubleshooting
signatures 2nd 3rd 4th
enrollment process, 2nd
IKE authentication errors, troubleshooting,
life cycle of, 2nd
RSVP (Resource Reservation Protocol), impact of IPsec on,


S

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

sample IPsec+GRE model configurations,
SAs (security associations)
IPsec tunnel security parameters 2nd
need for
proposal mismatches, troubleshooting
security parameters, manual keying
transport mode
tunnel mode
scalability of CRLs,
SCEP (Simple Certificate Enrollment Protocol),
SCTP (Stream Control Transmission Protocol),
security wheel,
sender non-repudiation,
serialization delay,
session authentication (SSL VPNs),
SHA (Secure Hash Algorithm),
shared secret keys,
signing public key certificates,
single points of failure for site-to-site VPNs,
site-to-site IPsec VPNs, 2nd
business drivers
configuration, verifying
configuring
hub-and-spoke networks
over routed domains 2nd
single points of failure, eliminating
site-to-site IPsec+GRE model [See IPsec+GRE model.]
software-based VPN clients,
SOHO deployments, applying dynamic crypto maps case study,
SPI (security parameter index),
SPI-based NAT, troubleshooting,
SSL VPNs,
cryptographic key derivation
handshake process
HMAC
RAVPN architectures
session authentication
transport layer security
tunnel establishment process
SSO (stateful switchover),
stale SAs
impact on IPsec reconvergence
removing from SADB
standalone VPN concentrator designs,
stateful IPSec HA,
alternatives to
failover process
stateless IPsec HA,
alternatives to
HSRP,
RRI,
failover process
goals of
static crypto maps,
symmetric encryption, 2nd
shared secret keys, Diffie-Hellman secret key generation
symptoms of recursive routing,


T

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

TED (Tunnel Endpoint Discovery),
timers (HSRP), tuning,
topologies [See VPN topologies.]
transform sets, identifying mismatches,
transforms
AH
creating
ESP
confidentiality services,
data integrity and authentication services,
IPComp
LZS
transport layer VPNs, SSL VPNs,
cryptographic key derivation
handshake process
HMAC
session authentication
transport layer security
tunnel establishment process
transport mode, 2nd
troubleshooting
IKE
authentication errors,
peer mismatches,
SA proposal mismatches, 2nd
mismatched crypto ACLs
NAT issues in IPsec VPN designs
SPI-based NAT,
NAT-T issues in IPsec VPN designs
VPNs in firewalled environments
TTI (Trusted Transitive Introduction),
tunnel mode,
tunnel termination. [See also tunnels.]
dual-DMZ firewall design 2nd
firewalled
GRE-offload
with cleartext firewall paths,
with dynamic crypto maps,
with high-speed tunnel termination,
with IKE x-Auth,
"on a stick" termination
NAT-on-a-stick,
router-on-a-stick,
termination redundancy
on HSRP/VRRP virtual interfaces,
using RP-based IPsec HA,
with multiple peer statements,
tunnels
L2F establishment process
load-balanced designs
concentrator clustering,
DNS,
external load balancers,
load sharing with peer statements,
routing,
negotiation process
PPTP
compulsory,
tunnel negotiation process,
voluntary,
SA security parameters 2nd


V

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

"validity period" field (ITU-T X.509v3-compliant certificates),
VCA (Virtual Cluster Agent) protocol,
RAVPN concentrator HA
vendor HA interoperability
design considerations
interoperability with stateful IPsec HA,
invalid security parameter index recovery,
Phase1/2 SA lifetime expiry,
SADB management,
impact on path availability
limitations of
inability to specify multiple peers,
lack of peer availability mechanisms,
verifying
dynamic crypto maps
IPsec+GRE model, tunnel establishment
message digests
site-to-site VPN configuration
TED
Virtual Fragmentation Reassembly,
voluntary tunnels,
VPDNs (virtual private dialup networks),
L2TP
control messages,
payload packets,
tunnel negotiation process,
Layer 2 Forwarding Protocol
packet format,
tunnel establishment process,
PPTP
compulsory tunnels,
data structure,
tunnel negotiation process,
voluntary tunnels,
VPN clients,
VPN concentrators,
VPN routes, redistribution,
VPN topologies
hub-and-spoke
clustered spoke design,
redundant clustered spoke design,
IPsec+GRE model
sample configurations,
tunnel establishment, verifying,
RAVPNs
clients,
clustered VPN concentrator designs,
standalone VPN concentrator designs,
site-to-site
configuring,
over routed domain, 2nd
verifying configuration,
VPN tunnel termination
dual-DMZ firewall design 2nd
firewalled
GRE-offload
with cleartext firewall paths,
with dynamic crypto maps,
with high-speed tunnel termination,
with IKE x-Auth,
"on a stick" termination
NAT-on-a-stick,
router-on-a-stick,
termination redundancy
on HSRP/VRRP virtual interfaces,
using RP-based IPsec HA,
with multiple peer statements,
VPN3000 Clustering,
VRFs (VPN Routing and Forwarding Instances),
VRRP, RAVPN concentrator HA, 2nd 3rd


W

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

wildcard preshared keys,


X

Previous Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [V] [W] [X]

x-auth,
X.509 certificates,
enrollment process 2nd
life cycle of 2nd
xauth extension (IKE),