Anda di halaman 1dari 481

ptg12115235

From the Library of Ahmed Aden


ptg12115235
800 East 96th Street
Indianapolis, Indiana 46240 USA
Cisco Press
IPsec Virtual Private Network
Fundamentals
James Henry Carmouche, CCIE No. 6085
From the Library of Ahmed Aden
ptg12115235
ii
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 pub-
lisher, 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
ISBN: 1-58705-207-5
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 tness 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 pre-
cision, 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.
From the Library of Ahmed Aden
ptg12115235
iii
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
From the Library of Ahmed Aden
ptg12115235
iv
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
GSUs 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 UNCs 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. Jasons
primary focus is on rewalls, 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 nancial and medical industries.
Mark is a frequent contributor and reviewer for Cisco Press books.
From the Library of Ahmed Aden
ptg12115235
v
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.
From the Library of Ahmed Aden
ptg12115235
vi
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.
Id like to thank Mike OShea for his support and friendship over the course of developing this
book. Mikes sound professional and personal advice have helped me endure the ebbs and ows
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 dene 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.
From the Library of Ahmed Aden
ptg12115235
vii
This Book Is Safari Enabled
The Safari

Enabled icon on the cover of your favorite technology book


means the book is available through Safari Bookshelf. When you buy this
book, you get free access to the online edition for 45 days.
Safari Bookshelf is an electronic reference library that lets you easily search
thousands of technical books, nd code samples, download chapters, and
access technical information whenever and wherever you need it.
To gain 45-day Safari Enabled access to this book:
Go to http://www.ciscopress.com/safarienabled
Complete the brief registration form
Enter the coupon code 6LL4-NBLJ-5EK4-HDJP-PKVQ
If you have difculty registering on Safari Bookshelf or accessing the online
edition, please e-mail customer-service@safaribooksonline.com.
From the Library of Ahmed Aden
ptg12115235
viii
Contents at a Glance
Introduction xvii
Part I Introductory Concepts and Conguration/Troubleshooting 3
Chapter 1 Introduction to VPN Technologies 5
Chapter 2 IPsec Fundamentals 35
Chapter 3 Basic IPsec VPN Topologies and Congurations 105
Chapter 4 Common IPsec VPN Issues 141
Part II Designing VPN Architectures 205
Chapter 5 Designing for High Availability 207
Chapter 6 Solutions for Local Site-to-Site High Availability 235
Chapter 7 Solutions for Geographic Site-to-Site High Availability 267
Chapter 8 Handling Vendor Interoperability with High Availability 297
Chapter 9 Solutions for Remote-Access VPN High Availability 313
Chapter 10 Further Architectural Options for IPsec 359
Part III Advanced Topics 389
Chapter 11 Public Key Infrastructure and IPsec VPNs 391
Chapter 12 Solutions for Handling Dynamically Addressed Peers 417
Appendix A Resources 449
Index 452
From the Library of Ahmed Aden
ptg12115235
ix
Contents
Introduction xvii
Part I Introductory Concepts and Configuration/Troubleshooting 3
Chapter 1 Introduction to VPN Technologies 5
VPN Overview of Common Terms 5
Characteristics of an Effective VPN 6
VPN Technologies 9
Virtual Private Dialup Networks 10
Layer 2 Forwarding Protocol 10
Point-to-Point Tunneling Protocol 12
Layer 2 Tunneling Protocol 16
Multiprotocol Label Switching VPNs 18
IPsec VPNs 20
Transport Layer VPNs 21
Secure Socket Layer VPNs 21
Transport Layer Security and SSL VPNs 25
Common VPN Deployments 25
Site-to-Site VPNs 25
Remote Access VPNs 28
SSL in RAVPN Architectures 28
Business Drivers for VPNs 29
Remote Access VPN Business DriversA Practical Example 30
Site-to-Site VPN Business DriversA Practical Example 30
IPsec VPNs and the Cisco Security Framework 31
Summary 32
Chapter 2 IPsec Fundamentals 35
Overview of Cryptographic Components 35
Asymmetric Encryption 36
Symmetric Encryption 39
Message Authentication, Message Integrity, and Sender Nonrepudiation Mechanisms 42
Hashing and Message Digests 42
Digital Signatures 44
Public Key Encryption Methods 46
RSA Public-Key Technologies 48
RSA Encryption 48
RSA Signatures 50
Diffie-Hellman Key Exchange 51
The IP Security Protocol (IPsec) 51
IPsec Modes 52
Transport Mode 52
Tunnel Mode 54
From the Library of Ahmed Aden
ptg12115235
x
IPsec Transforms 55
ESP 55
AH 57
IP Payload Compression Protocol (IPPCP) and LZS 58
IPsec SA 59
IPsec Configuration Elements 63
Creating an IPsec Transform 63
Crypto Map Configuration 66
Manual Keying 68
The Need for Security Association and Key Management 77
IKE and ISAKMP 78
IKE and ISAKMP Terminology and Background 78
IKE SA Negotiation and Maintenance 79
IPsec Diffie-Hellman Shared Secret Key Generation Using IKE 79
IKE Authentication Services 83
Pre-Shared Keys 83
RSA Encryption (Encrypted Nonces) 85
RSA Signatures and X.509 Certificates 86
IKE Phase I Negotiation 87
Main Mode 88
Aggressive Mode 89
IKE Phase II Negotiation 90
Quick Mode 90
PFS 91
Dead Peer Detection and IKE Keepalives 92
Configuring ISAKMP 94
IKE with RAVPN Extensions 96
Mode Configuration 96
X-Auth 98
Summary 100
Chapter 3 Basic IPsec VPN Topologies and Configurations 105
Site-to-Site IPsec VPN Deployments 107
Site-to-Site VPN Architectural Overview for a Dedicated Circuit 107
Cisco IOS Site-to-Site IPsec VPN Configuration 108
Verifying Cisco IOS Site-to-Site IPsec VPN Operation 111
Site-to-Site Architectural Overview over a Routed Domain 117
Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE) 121
Site-to-Site IPsec+GRE Architectural Overview 121
Increased Packet Size and Path MTU Considerations 122
GRE and Weighted Fair Queuing 122
QoS and the IPsec Anti-Replay Window 122
From the Library of Ahmed Aden
ptg12115235
xi
Site-to-Site IPsec+GRE Sample Configurations 123
Cisco IOS Site-to-Site IPsec+GRE Configuration 123
Verification of IPsec+GRE Tunnel Establishment 126
Hub-and-Spoke IPsec VPN Deployments 128
Hub-and-Spoke Architectural Overview 129
Standard Hub-and-Spoke Design without High Availability 129
Clustered Spoke Design to Redundant Hubs 130
Redundant Clustered Spoke Design to Redundant Hubs 131
Remote Access VPN Deployments 132
RAVPN Architectural Overview 132
RAVPN Clients 132
Standalone VPN Concentrator Designs 133
VPN Concentrator on Outside Network with Single DMZ 133
VPN Concentrator and Firewall in Parallel 134
VPN Concentrator with Dual DMZs to Firewall 135
What to Avoid in DMZ/VPN Concentrator Topologies 136
Clustered VPN Concentrator Designs 137
Summary 138
Chapter 4 Common IPsec VPN Issues 141
IPsec Diagnostic Tools within Cisco IOS 141
Common Configuration Issues with IPsec VPNs 142
IKE SA Proposal Mismatches 142
IKE Authentication Failures and Errors 146
IKE Authentication Errors and PSKs 146
IKE Authentication Errors with RSA Encryption 151
IKE Authentication Errors with RSA Signatures 158
IPsec SA Proposal Mismatches 165
Crypto-Protected Address Space Issues (Crypto ACL Errors) 169
Architectural and Design Issues with IPsec VPNs 171
Troubleshooting IPsec VPNs in Firewalled Environments 171
Allowing the Required IPsec Protocols to Pass 171
Firewalls Handling of Fragmented IPsec Packets 173
Filtering of ICMP Unreachables 174
NAT Issues in IPsec VPN Designs 174
Intrinsic IPsec/NAT Incompatibilities 175
IPsec NAT Transparency (NAT-T) 178
SPI-Based NAT 179
The Influence of IPsec on Traffic Flows Requiring QoS 180
IPsecs Influence on DiffServ and LLQ/CBWFQ 181
IPsecs Effect on IntServ and RSVP 183
From the Library of Ahmed Aden
ptg12115235
xii
Solving Fragmentation Issues in IPsec VPNs 183
Path MTU Discovery 184
Fragmentation Behavior on Cisco IOS VPN Endpoints 189
Solutions for Preventing Fragmentation 193
The Effect of Recursive Routing on IPsec VPNs 197
Summary 200
Part II Designing VPN Architectures 205
Chapter 5 Designing for High Availability 207
Network and Path Redundancy 208
IPSec Tunnel Termination Redundancy 210
Multiple Physical Interface HA with Highly Available Tunnel Termination Interfaces 210
Tunnel Termination HA Using HSRP/VRRP Virtual Interfaces 211
HA with Multiple Peer Statements 212
RP-based IPSec HA 214
Managing Peer and Path Availability 215
Peer Availability 216
Path Availability 218
Managing Path Symmetry 219
Load Balancing, Load Sharing, and High Availability 222
Load-Sharing with Peer Statements 222
Routing 224
Domain Name System (DNS) 225
Cisco VPN3000 Concentrator Clustering 227
IPSec Session Load-Balancing Using External Load Balancers 230
Summary 232
Chapter 6 Solutions for Local Site-to-Site High Availability 235
Using Multiple Crypto Interfaces for High Availability 235
Impact of Routing Protocol Reconvergence on IPsec Reconvergence 238
Impact of Stale SAs on IPsec Reconvergence 240
Impact of IPsec and ISAKMP SA Renegotiation on IPsec Reconvergence 241
Stateless IPsec VPN High-Availability Alternatives 242
Solution Overview for Stateless IPsec High Availability 242
Hot Standby Routing Protocol 244
RRI 245
Stateless High Availability Failover Process 246
Step 1: Initial IPsec VPN Tunnel Establishment 247
Step 2: Pre-HSRP RRI Execution 251
Step 3: Active Router Failure 254
Step 4: HSRP Reconvergence 254
Step 5: IPsec Reconvergence 255
Step 6: Post-HSRP RRI Execution 257
From the Library of Ahmed Aden
ptg12115235
xiii
Stateful IPsec VPN High-Availability Alternatives 257
Solution Overview for Stateful IPsec High Availability 258
HSRP and RRI 259
Stateful Switchover (SSO) and IPsec High Availability 259
Stateful High Availability Failover Process 261
Step 1: Initial IPsec VPN Tunnel Establishment 261
Step 2: SADB Synchronization with SSO 261
Step 3: Pre-HSRP Failover RRI Execution 262
Step 4: Active Router Failure 262
Step 5: HSRP Reconvergence 262
Step 6: IPsec Reconvergence 262
Step 7: Post-HSRP RRI Execution 263
Summary 263
Stateless IPsec VPN High Availability Design Summary 263
Stateful IPsec VPN High Availability Design Summary 265
Chapter 7 Solutions for Geographic Site-to-Site High Availability 267
Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers 267
Solution Overview for RRI with Multiple IPsec Peers 267
Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing
Protocols 278
Solution Overview for IPsec+GRE with Encrypted Routing Protocols 279
Dynamic Multipoint Virtual Private Networks 287
DMVPN Solution Design Drivers 288
DMVPN Component-Level Overview and System Operation 289
Summary 295
Chapter 8 Handling Vendor Interoperability with High Availability 297
Vendor Interoperability Impact on Peer Availability 297
The Inability to Specify Multiple Peers 297
Lack of Peer Availability Mechanisms 300
Vendor Interoperability Impact on Path Availability 301
IPSec HA Design Considerations for Platforms with Limited Routing
Protocol Support 302
IPSec HA Design Considerations for Lack of RRI Support 304
IPSec HA Design Considerations for Lack of Generic Routing Encapsulation (GRE)
Support 305
Vendor Interoperability Design Considerations and Options 306
Phase 1 and 2 SA Lifetime Expiry 307
SADB Management with Quick Mode Delete Notify Messages 307
Invalid Security Parameter Index Recovery 308
Vendor Interoperability with Stateful IPSec HA 309
Summary 311
From the Library of Ahmed Aden
ptg12115235
xiv
Chapter 9 Solutions for Remote-Access VPN High Availability 313
IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel
Termination 314
IPsec RAVPN Concentrator High Availability Using VRRP 315
IPsec RAVPN Concentrator HA Using HSRP 327
IPsec RAVPN Concentrator HA Using the VCA Protocol 333
IPsec RAVPN Geographic HA Design Options 342
VPN Concentrator Session Load Balancing Using DNS 343
VPN Concentrator Redundancy Using Multiple Peers 345
Summary 355
Chapter 10 Further Architectural Options for IPsec 359
IPsec VPN Termination On-a-Stick 359
IPsec with Router-on-a-Stick Design Overview 359
Single, Flatly Addressed L3 Domain 360
Lack of In-Path Design Options 361
Single Interface to the Bridged LAN 361
Crypto-Enabled Loopback Interface 361
Case Study: Small Branch IPsec VPN Tunnel Termination with NAT On-a-Stick 362
In-Path Versus Out-of-Path Encryption with IPsec 368
Out-of-Path Encryption Design Overview 370
Case Study: Firewalled Site-to-Site IPsec VPN Tunnel Termination 370
Separate Termination of IPsec and GRE (GRE-Offload) 379
GRE-Offload Design Overview 379
Lack of Support for GRE Processing 380
Low GRE Performance 380
Case Study: Large-Scale IPsec VPN Tunnel Termination with GRE Offload 382
Dynamic Crypto Maps and GRE-Offload 383
IKE Extended Authentication (X-Auth) 384
Firewalled Cleartext Traffic 385
High-Speed GRE Tunnel Termination for GRE-Offload 385
Summary 386
Part III Advanced Topics 389
Chapter 11 Public Key Infrastructure and IPsec VPNs 391
PKI Background 391
PKI Components 394
Public Key Certificates 394
Registration Authorities 395
Certificate Revocation Lists and CRL Issuers 396
Certificate Authorities 397
PKI Cryptographic Endpoints 397
From the Library of Ahmed Aden
ptg12115235
xv
Life of a Public Key Certificate 397
RSA Signatures and X.509v3 Certificates 397
Generating Asymmetric Keypairs on Cryptographic Endpoints 402
Registration and Endpoint Authentication 402
Receipt and Authentication of the CAs Certificate 403
Forwarding and Signing of Public Keys 403
Obtaining and Using Public Key Certificates 403
PKI and the IPSec Protocol SuiteWhere PKI Fits into the IPSec model 404
OCSP and CRL Scalability 404
OCSP 405
Case Studies and Sample Configurations 405
Case Study 1: PKI Integration of Cryptographic Endpoints 407
Case Study 2: PKI with CA and RA 410
Case Study 3: PKI with Redundant CAs (CA Hierarchy) 412
Summary 414
Chapter 12 Solutions for Handling Dynamically Addressed Peers 417
Dynamic Crypto Maps 417
Dynamic Crypto Map Impact on VPN Behavior 418
Dynamic Crypto Map Impact on ISAKMP/IKE 418
Routing Considerations with Dynamic Crypto Maps 419
Security Considerations for Dynamic Crypto Maps 421
Dynamic Crypto Map Configuration and Verification 425
Tunnel Endpoint Discovery 430
TED Configuration and Verification 432
Case StudyUsing Dynamic Addressing with Low-Maintenance Small Home Office
Deployments 432
Summary 446
Appendix A Resources 449
Books 449
RFCs 449
Web and Other Resources 450
Index 452
From the Library of Ahmed Aden
ptg12115235
xvi
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
conguration 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.
From the Library of Ahmed Aden
ptg12115235
xvii
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 nancial, government), explaining the need for increased information
authentication, condentiality, and non repudiation for secure transmission of condential data
(government records, nancial 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) congurations 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 todays enterprise networks are presented and
discussed. Within each chapter, the design concepts are presented and then reinforced with
congurations, 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 specic 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 specic
IPsec congurations and practical IPsec deployment examples on Cisco products may also nd
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.
From the Library of Ahmed Aden
ptg12115235
xviii
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 IPsecs 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 conguration 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 conguration 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 TechnologiesThis chapter includes an introduction
to various VPN technologies, discusses how VPNs are utilized in todays networks, and
identies 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 FundamentalsThis chapter focuses on the underlying components
and mechanics of IPsec, including cryptographic components, Internet Key Exchange (IKE),
and IPsec. This chapter includes basic conguration examples (not step-by-step) to
demonstrate the concepts.
From the Library of Ahmed Aden
ptg12115235
xix
Chapter 3, Basic IPsec VPN Topologies and CongurationsThis 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 IssuesIPsec 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 verication 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 AvailabilityThis 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 AvailabilityThis 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 AvailabilityThis 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 AvailabilityUnfortunately,
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 AvailabilityThis 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 IPsecThis chapter discusses other
architectural variations in designing VPN solutions. It describes each option with usage
considerations and nishes with case studies of each.
From the Library of Ahmed Aden
ptg12115235
xx
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 rmly 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 todays enterprise-class IP networks:
Chapter 11, Public Key Infrastructure and IPsec VPNsThis chapter discusses the
usage of public key infrastructure (PKI) to authenticate IPsec peers via Rivest, Shamir, and
Adelman (RSA) signatures. This method uses a certicate 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 PeersDynamic 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 prolic in
various architectures.
From the Library of Ahmed Aden
ptg12115235
This page intentionally left blank
From the Library of Ahmed Aden
ptg12115235
From the Library of Ahmed Aden
ptg12115235
Part I: Introductory Concepts and
Conguration/Troubleshooting
Chapter 1 Introduction to VPN Technologies
Chapter 2 IPsec Fundamentals
Chapter 3 Basic IPsec VPN Topologies and Congurations
Chapter 4 Common IPsec VPN Issues
From the Library of Ahmed Aden
ptg12115235
From the Library of Ahmed Aden
ptg12115235
C H A P T E R
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 efciencies
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 efciencies in tandem with greatly reduced IT
operational expenditures. In this chapter, we will discuss how todays 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 todays 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
AVPN 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 dened 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 well
explore in later chapters when discussing dynamic multipoint VPN (DMVPN) deployments,
they currently provide no means to provide condentiality, 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.
From the Library of Ahmed Aden
ptg12115235
6 Chapter 1: Introduction to VPN Technologies
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 youll 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 condential VPN
implementation must meet:
Data condentiality: 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 condentiality 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 condential from would be interceptors of the
NOTE Although IPSec-processed data is encrypted, it is also encapsulated with either
Encapsulating Standard Protocol (ESP) or Authentication Headers (AH).
From the Library of Ahmed Aden
ptg12115235
Characteristics of an Effective VPN 7
message. Figure 1-1 illustrates a high-level exchange of encrypted message between to endpoints,
James and Charlie.
Figure 1-1 Condentiality and Authenticity in Encrypted Communications
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 Dife-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
condentiality, and vice versa.
Hashes and digital signatures protect the integrity of a specic 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.
By providing a unique ngerprint specic 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 specic 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.
Hey Charlie, what did you
learn at school today?
4$h5*&FsW@4^%TY&^i*f
Plain Text
Cipher Text:
James
Charlies Encryption Key
Hey Charlie, what did you
learn at school today?
4$h5*&FsW@4^%TY&^i*f
Plain Text
Cipher Text:
Charlies Decryption Key
Cipher:
RSA
Charlie
Cipher:
RSA
Charlie shares his encryption
key only with James
From the Library of Ahmed Aden
ptg12115235
8 Chapter 1: Introduction to VPN Technologies
Figure 1-2 Data Integrity, Secure Hashes
Figure 1-3 Message Authenticity and Data Non-Repudiation with Digital Signatures
Hey Charlie, what did you
learn at school today?
Charlie separates James message
digest from original message
Charlie verifies the James
message digest with his own
Fsd$#^@43#@Ad5J$
Hey Charlie, what did you
learn at school today?
Fsd$#^@43#@Ad5J$
Plain Text
Hash Value:
James
Hey Charlie, what did you
learn at school today?
Fsd$#^@43#@Ad5J$
Plain Text
Hash Value:
Fsd$#^@43#@Ad5J$
Hash Value:
J
a
m
e
s

a
p
p
e
n
d
s

m
e
s
s
a
g
e

d
i
g
e
s
t
t
o

o
r
i
g
i
n
a
l

m
e
s
s
a
g
e
Charlie
Hash:
MD5
Hash:
MD5
Hey Charlie, what did you
learn at school today?
Charlie separates James message
digest from original message
Charlie verifies the James
message digest with his own
Plain Text
James
Encryption Key
James
Decryption Key
Hash Value:
James Charlie
Hash Value:
James encrypts the
message digest
Charlie
decrypts
the digital
signature
Fsd$#^@43#@Ad5J$
Digital
Signature
Digital
Signature
Hey Charlie, what did you
learn at school today?
James appends message
digest to original message
Digital
Signature
Fsd$#^@43#@Ad5J$
Hash Value:
Fsd$#^@43#@Ad5J$
Hash:
MD5
Cipher:
RSA
Hash:
MD5
Cipher:
RSA
Hey Charlie, what did you
learn at school today?
From the Library of Ahmed Aden
ptg12115235
VPN Technologies 9
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 well 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
Secure HTTP (HTTPS)
S/MIME, PGP
N/A
N/A
SSL and TLS
SOCKS, SSH
IPSec Deployments,
MPLS VPNs
VPDN-PPTP, L2TP, L2F
ATM Cell Encryptors
Frame-Relay Frame Encryptors
Optical Bulk Encryptors
Radio Frequency (RF)
Encryptors
Layer 7, Application
Open-Standard Interconnect (OSI)
Model Layer VPN Technology
Layer 6, Presentation
Layer 5, Session
Layer 4, Transport
Layer 3, Network
Layer 2, Data Link
Layer 1, Physical
From the Library of Ahmed Aden
ptg12115235
10 Chapter 1: Introduction to VPN Technologies
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 condentiality. 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 clients 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 todays 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.
NOTE In an L2F environment, a home gateway refers to a gateway located at the corporate
headquarters.
PPP Encapsulation PPP Payload L2F Encapsulation UDP
From the Library of Ahmed Aden
ptg12115235
VPN Technologies 11
Figure 1-6 L2F Topology and Tunnel Establishment
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).
Once the PPP session has been authenticated, a series of exchanges are performed to ofoad
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.
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 conrms acceptance of the tunnel negotiation initiation request from NAS.
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).
PSTN/ISDN
Connections
Cisco Secure
ACS, ISP
NAS
Step 4
Step 2
Step 3
Step 5
Step 6 Step 1
Home
Gateway
PPP Client,
Mobile Worker
PPP Client,
Branch Office
PPP Client,
Telecommuter
PPP Client, Small
Home Office PPP Client,
Mobile Worker
Cisco Secure
ACS, Corporate
From the Library of Ahmed Aden
ptg12115235
12 Chapter 1: Introduction to VPN Technologies
Figure 1-7 PPP Authentication with CHAP
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.
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 ofce 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.
The PPP client in this scenario needs to connect to their enterprise network. The corporations
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.
NOTE For more information on L2F, refer to RFC 2341 at http://www.ietf.org/rfc/rfc2406.txt.
Step 1: PPP CHAP Authentication Operation
1) Establish link (LCP);
initiate PPP negotiation
2) Select CHAP as PPP
authentication scheme
3) Acknowledge PPP
authentication scheme
4) Challenge
5) Create one-way hash
and use as response
6) Create one-way hash;
verify clients response;
accept or reject connection
PPP Client, Small
Home Office
NAS
From the Library of Ahmed Aden
ptg12115235
VPN Technologies 13
Figure 1-8 PPTP Topology and Tunnel Negotiation
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 rst 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 condentiality 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.
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
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.
NAS/PAC
PIX/PNS Gateway
Router
Step 1
Service Provider
Network
Enterprise
Network
Step 4
Step 3
Step 2
PSTN/ISDN
Connections
PPP Client,
Mobile Worker
PPP Client,
Branch Office
PPP Client,
Telecommuter
PPP Client,
Small Home Office
PPP Client,
Mobile Worker
From the Library of Ahmed Aden
ptg12115235
14 Chapter 1: Introduction to VPN Technologies
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.
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 dened in RFC 2673 between the PNS
and the PPP client.
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 modied 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
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
CAUTION In many cases, including the example in Figure 1-8, TCP port 1723 must be
allowed through any corporate rewalls or other ltering security devices for PPTP to operate
correctly. In this scenario, the PIX would be congured with the appropriate static translation
and access list entry on its outside interface to allow TCP sessions from remote clients on port
1723.
TIP As with PPP authentication on the NAS/PAC, PPTP connections on PIX rewalls 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.
NOTE The header used in the PPTP encapsulation process is similar to a GRE header, with
some slight modications to the specication outlined in RFC 1701. The PPTP version of the
GRE header includes an acknowledgment eld to determine the rate at which packets are
traversing the PPTP tunnel.
Data Link Header Data Link Trailer IP Header PPTP Header PPP Header PPP Payload
From the Library of Ahmed Aden
ptg12115235
VPN Technologies 15
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
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 ve times the tunnel maintenance of a compulsory tunnel negotiation
option (ve 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 condentiality 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 condential 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 condentiality.
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.
NAS/PAC
PIX/PNS Gateway
Router
PSTN/ISDN
Connections
Service Provider
Network
Enterprise
Network
PPP Client
PPP Client
PPP Client
PPP Client
PPP Client
Step 2
Step 3
Step 1
Step 4
From the Library of Ahmed Aden
ptg12115235
16 Chapter 1: Introduction to VPN Technologies
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
NOTE L2F control and payload packets are also sent on UDP port 1701. Network devices
inspect the version eld to differentiate between L2F and L2TP packet formats.
Data Link Header Data Link Trailer IP Header UDP Header PPP Header PPP Payload L2TP Header
From the Library of Ahmed Aden
ptg12115235
VPN Technologies 17
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 customers 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
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 users 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.
Cisco Secure ACS, ISP
Service
Provider
Network
NAS/LAC
Step 4
Step 3
Step 5
Step 6
Step 1
LNS
Step 2
PSTN/ISDN
Connections
PPP Client,
Mobile Worker
PPP Client,
Branch Office
PPP Client,
Telecommuter
PPP Client, Small
Home Office PPP Client,
Mobile Worker
Cisco Secure
ACS, Corporate
From the Library of Ahmed Aden
ptg12115235
18 Chapter 1: Introduction to VPN Technologies
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 trafc 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 prex and
8-byte route descriptor, between one another using the Multiprotocol Border Gateway
Protocol (MP-BGP), enabling convergence at the PE.
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.
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
From the Library of Ahmed Aden
ptg12115235
VPN Technologies 19
A VRF describes a separate routing and forwarding table, enabled by the use of Route Descriptors,
which are 8-byte unique identiers derived from VPN-specic 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 trafc
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 networks routing table or IP addressing information. Instead, trafc is
switched within the MPLS cloud using labels and an entry in the P routers label forwarding
information base (LFIB). Figure 1-13 illustrates IP-routed and VRF-routed domains with MPLS.
Figure 1-13 Trafc is IP-Routed to the Provider Edge (PE)
When the trafc 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
CAUTION An MPLS VPN does not provide condentiality unless it is deployed in
conjunction with IPsec.
Customer
Network
B
PE Routers use MP-BGP
to distribute VPNv4
routes to one another
over the network of P
routers.
Customer Networks A, B, C,
and D use the a single,
shared, virtualized core
enabling all networks to
participate in the VPN #1
while only allowing
Customer Networks C and D
participate in the VPN #2.
Customer
Network
C
C
C
CE
CE
IP
Switched
Customer
Network
D
C
CE
IP
Switched
IP Switched IP Switched
C CE
Customer
Network
A
P
P
PE
PE
PE
PE
Label
Switched
= VPN #1 = VPN #2
From the Library of Ahmed Aden
ptg12115235
20 Chapter 1: Introduction to VPN Technologies
MPLS labels and an associated LFIB entry to forward the trafc across the MPLS core rather than
IP addressing information.
When MPLS-switched trafc arrives at the destination PE router, trafc 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 conict 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 condentiality, and
data integrity protection. As such, IPsec is one of the most widespread VPN technologies in
todays 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.
As we will discuss, IPsec is supported within Cisco IOS on a wide array of different routers,
rewalls, 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 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.
From the Library of Ahmed Aden
ptg12115235
VPN Technologies 21
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
condentially 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 todays 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 condentiality 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
NOTE The precise operation of ESP and AH are outlined more comprehensively in Chapter 2.
Secure Socket Layer (SSL)
Services
Layer 4, Transport, TCP
Layer 3, Network, IP
Layer 2, Data Link
Layer 1, Physical
From the Library of Ahmed Aden
ptg12115235
22 Chapter 1: Introduction to VPN Technologies
SSL follows ve 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
The following order of operations describes the SSL handshake illustrated in Figure 1-15:
Client Exchange of Cryptographic Parameters
CLIENT-HELLO Message:
Cipher suite (supported symmetric transforms)
Version (SSL v2, v3, or v3.1)
ClientRandom (for master secret calculation)
Optional session ID
Compression algorithm
CLIENT-HELLO-DONE Message
Server Exchange of Cryptographic Parameters
SERVER-HELLO Message:
Cipher suite (supported symmetric transforms)
Version (SSL v2, v3, or v3.1)
ServerRandom (for master secret calculation)
Optional session ID
Compression algorithm
SERVER-HELLO-DONE Message
Cryptographic Key Derivation
CLIENT-KEY-EXCHANGE Message:
Client protocol version
Pre-master secret: a 48-byte value
FINISHED Message
Hash of all exchanged messages executed in the
handshake
Session Authentication
FINISHED Message
Hash of all exchanged messages executed in the
handshake including the Client FINISHED message
Session Authentication
FINISHED Message
Hash of all exchanged messages executed in the
handshake including the Client FINISHED message
1
2
3
4
5 5
SSL Concentrator
SSL Concentrator
SSL Concentrator
SSL Concentrator
SSL Concentrator
SSL Client
SSL Client
SSL Client
SSL Client
SSL Client
From the Library of Ahmed Aden
ptg12115235
VPN Technologies 23
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-CERTIFICATEContains the serverss public key for
server authentication and pre-master secret encryption.
SERVER-KEY-EXCHANGEOptionally used to encrypt the
CLIENT-KEY-EXCHANGE message in Step 3 below.
CLIENT-CERTIFICATE-REQUESTThe SSL concentrator or
server can optionally request a client certicate for authentication. If this
message is sent to the client, the clients 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 specied 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 servers 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-CERTIFICATEThe client must possess a certicate and
forward it to the server using this message if the client receives a
CLIENT-CERTIFICATE-REQUEST in Step 2 above.
NOTE RSA signatures are commonly used to facilitate the authentication and condential
exchange of messages during the SSL handshake. RSA Signatures, including x.509-based
certicates and certicate authorities, are discussed in full detail in Chapter 2 and Chapter 12,
Public Key Infrastructures and IPsec.
From the Library of Ahmed Aden
ptg12115235
24 Chapter 1: Introduction to VPN Technologies
CERTIFICATE-VERIFYThis 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 SecretClient uses this key to create a hash
appended to the original message; server uses this key to verify the hash.
Server Write MAC SecretServer uses this key to create a hash
appended to the original message; client uses this key to verify the hash.
Client Write KeyClient uses this key to encrypt messages; server
uses it to decrypt messages.
Server Write KeyServer 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 veries 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. Condential 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.
From the Library of Ahmed Aden
ptg12115235
Common VPN Deployments 25
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
signicant modications, specically 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 ratied 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 briey
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, ofoading the initiation and termination of the VPN tunnel to a rewall or VPN
concentrator on each organizations 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
Although the two IPsec tunnel implementations in Figure 1-16 use the same physical topology to
accomplish a similar task, there is a signicant 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
IPSec tunnel over point-to-point link
IPSec tunnel over routed links
Network A Network B
From the Library of Ahmed Aden
ptg12115235
26 Chapter 1: Introduction to VPN Technologies
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 exibility 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 trafc 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.
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 ofce.
IP
S
ec T
unnel
IP
S
e
c
T
u
n
n
e
l
7200VXR
Head-End
2800 Series ISR
2651XM Branch Router
IPSec over multiple L3 (routed) hops
3800 Series ISR
3745 Branch Router
IP
S
e
c
T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
From the Library of Ahmed Aden
ptg12115235
Common VPN Deployments 27
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
TIP In a hub-and-spoke topology, a dynamic multipoint VPN (DMVPN) conguration 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.
Branch_H
Branch_A Branch_B
Corporate
Extranet
Branch_C
Branch_D
Branch_G Branch_F
Branch_E
Branch_D
I
P
S
e
c

T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
IP
S
e
c
T
u
n
n
e
l
IP
S
e
c
T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
IP
S
e
c T
u
n
n
e
l
IP
S
e
c
T
u
n
n
e
l I
P
S
e
c

T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
Extranet Partner
Network #1
Extranet Partner
Network #3
Extranet Partner
Network #4
Extranet Partner
Network #2
From the Library of Ahmed Aden
ptg12115235
28 Chapter 1: Introduction to VPN Technologies
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 users 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.
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 specic 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 specic application on a
given web server, as opposed to allowing all of the remote users IP trafc through the network.
To achieve this, the remote user would use SSL client software installed with their web browser.
The security administrator can then congure their VPN concentrator or web server to terminate
the SSL VPN connection accordingly.
From the Library of Ahmed Aden
ptg12115235
Business Drivers for VPNs 29
Figure 1-19 RAVPN Implementation
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 nancial 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.
IPSec Tunnels
VPDN Infrastructure RAVPN Infrastructure
IPSec Client,
Telecommuter
IPSec Client,
Mobile Worker
PPP/VPDN Client,
Mobile Worker
PPP over PSTN/
ISDN
PPP/VPDN Client,
Small Home Office
PPP/VPDN Client,
Telecommuter
IPSec Client, Branch Office
I
P
S
e
c

T
u
n
n
e
l
IP
S
ec Tunnel
IPSec Client,
Small Home Office
Enterprise Branch
Infrastructure and DMZ
ISP (IP Network)
Corporate
Extranet
IP
S
e
c
T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
IP
S
e
c T
u
n
n
e
l
IP
S
ec T
unnel
I
P
S
e
c

T
u
n
n
e
l
I
P
S
e
c
T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
I
P
S
e
c

T
u
n
n
e
l
Extranet Partner
Network #1
Extranet Partner
Network #3
Extranet Partner
Network #4
Extranet Partner
Network #2
I
P
S
e
c

T
u
n
n
e
l
IPSec Tunnel
From the Library of Ahmed Aden
ptg12115235
30 Chapter 1: Introduction to VPN Technologies
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, condential
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 patients 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
exibility. Organizations are now becoming more global in reach, and the need for a exible,
productive workforce is as critical as ever.
Workforce exibility 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 exibility 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 organizations chief
security ofcer 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 nal result is that the organizations 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 efciencies 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
From the Library of Ahmed Aden
ptg12115235
IPsec VPNs and the Cisco Security Framework 31
decreasing the overall operation expenditures associated with the enterprises 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 enterprises headquarters over dedicated T-1
circuits. The enterprises 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 condentially
transmitted between the branch ofces and headquarters. The enterprise addresses this need for
condentiality 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 enterprises 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 xed costs associated with
migrating to an ISP-based site-to-site IPsec VPN solution, such as the initial xed 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
Ciscos 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 todays business environment.
Figure 1-20 VPN Implementations and the Cisco Security Wheel
Corporate
Security Policy
Test
Secure
I
m
p
r
o
v
e
M
o
n
i
t
o
r
From the Library of Ahmed Aden
ptg12115235
32 Chapter 1: Introduction to VPN Technologies
This book explores many secure designs relying on IPsec for condentiality, authentication,
non-repudiation, and data authenticity. Those designs will incorporate many of the products that
t within various segments of the security wheel comprising Ciscos end-to-end security product
line, including rewalls, intrusion detection systems, authentication, authorization and accounting
(AAA) technologies, policy management, and, most importantly, encryption technologies. With
respect to Ciscos 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.
Summary
A virtual private network delivers upon business needs for data condentiality, 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 exibility 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 benets 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 WANsA companys 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.
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 Ciscos SAFE architecture. For
more information on SAFE, please refer to the following URL:
http://www.cisco.com/go/safe
From the Library of Ahmed Aden
ptg12115235
Summary 33
Corporate extranetsNow 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 nancial decisions, or a large regional hospital processing thousands of claims
with a global health-insurance provider, the need for condential, secure communications
becomes critically important. As such, corporate extranets are another demand driver for site-
to-site VPN implementations.
Remote access VPN implementationsThis chapter discussed examples of how providing
a workforce with more exibility throughout the day drives productivity, ultimately positively
impacting an organizations bottom line. A Remote Access VPN can be used to enable such
exibility. 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 exible Layer 3
IPsec and Layer 4 SSL and TLS solutions in order to deliver condential, authentic exchange
of data in these scenarios.
You have seen that VPN technologies are a critical component to Ciscos end-to-end security
strategythe Cisco Security Wheel. Throughout the course of this book, you will explore the
VPN platforms available to effectively implement specic types of VPN architectures. The book
further explores specic design scenarios and case studies to effectively illustrate common design
issues and how a network architect can remediate those issues.
From the Library of Ahmed Aden
ptg12115235
From the Library of Ahmed Aden
ptg12115235
C H A P T E R
2
IPsec Fundamentals
Internet Protocol Security (IPsec), as dened in RFC 2401, provides a means by which to ensure
the authenticity, integrity, and condentiality of data at the network layer of the Open System
Interconnection (OSI) stack. IPsec is a suite of protocols that dene standards for four key
elements needed in dening a comprehensively robust Virtual Private Network (VPN) enabler:
Security Protocols
Key Exchange Mechanisms
Algorithms Required for Encryption and Secure Key Exchange
SA Denitions 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
rst 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 IPsecs 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).
Overview of Cryptographic Components
As we had discussed briey while introducing the criteria for dening an effective VPN, data
condentiality, 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.
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.
From the Library of Ahmed Aden
ptg12115235
36 Chapter 2: IPsec Fundamentals
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 condentiality in VPN deployments.
Figure 2-1 EncryptionA One-Thousand-Foot View
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 trafc to one another. James will then use Charlies 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 JamesCharlies reply will
be encrypted with his James public key, and James will have to use his private key to decrypt
Charlies 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.
Test ABCD1234 Test ABCD1234
4$h5*&FsW@4^%TY&^i*f
Plain Text
Cipher Text:
James
Encryption Key
4$h5*&FsW@4^%TY&^i*f
Plain Text
Cipher Text:
Decryption Key
Cipher:
RSA
Charlie
Cipher:
RSA
From the Library of Ahmed Aden
ptg12115235
Overview of Cryptographic Components 37
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 condentially, using that key to encrypt the message. Note that private keys are never
exchanged across the shared media, which lessens the inuence 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 Charlies
condential conversation using asymmetric cryptography.
Figure 2-3 Exchanging Messages with Asymmetric Cryptography
Test Send ABCD1234
Message:
James
Private Key, James
Charlie
Private Key, Charlie
Public Key, Charlie Public Key, James
@#4w{3%d2q@!#4a
Message:
Encrypted Message
@#4w{3%d2q@!#4a
Encrypted Message
James
Public Key, Charlie
Charlie
Cipher:
RSA
Test Send ABCD1234
1
3A&s(}>s,%43Sf*5
Message:
Encrypted Message
3A&s(}>s,%43Sf*5
Encrypted Message
Charlie
Public Key, James
James
Cipher:
RSA
Test Reply ZYXW9876
3
Test Send ABCD1234
Decrypted Message
@#4w{3%d2q@!#4a
Encrypted Message
James
Private Key, Charlie
Charlie
Cipher:
RSA
2
Test Reply ZYXW9876
Message:
3A&s(}>s,%43Sf*5
Encrypted Message
Private Key, James
Cipher:
RSA
Charlie James
4
From the Library of Ahmed Aden
ptg12115235
38 Chapter 2: IPsec Fundamentals
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 Charlies 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. Condentiality 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 decryption
only 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 Charlies
reply. Lets 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
Private Key, James
Public Key, James
Public Key, Charlie
Private Key, Charlie
James sends Public
Key to Charlie.
1
Olivia intercepts James
Public Key.
2
Charlie sends Public Key
to James.
3
Olivia cannot decrypt encrypted data sent from
James to Charlie. Only Charlies Private Key can
decrypt data encrypted with Charlies Public Key.
4
Olivia cannot decrypt encrypted data sent from
Charlie to James. Only James Private Key can
decrypt data encrypted with James Public Key.
4
Encrypted Data
Encrypted Data
From the Library of Ahmed Aden
ptg12115235
Overview of Cryptographic Components 39
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 Charlies 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 condential
messages.
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
precongured 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.
From the Library of Ahmed Aden
ptg12115235
40 Chapter 2: IPsec Fundamentals
Figure 2-5 Symmetric Key Encryption
When Charlie decides to answer James query, the operation would follow the same procedure.
Specically, 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.
@#4w{3%d2q@!#4a
Message:
Encrypted Message
@#4w{3%d2q@!#4a
Encrypted Message
James
Shared Secret Key
Charlie
Cipher:
AES
Test Send ABCD1234
2
Test Message ABCD1234
Decrypted Message
@#4w{3%d2q@!#4a
Encrypted Message
James
Shared Secret Key
Charlie
Cipher:
AES
3
Message:
James
Shared Secret Key
Charlie
Shared Secret Key
Test Message ABCD1234
1
From the Library of Ahmed Aden
ptg12115235
Overview of Cryptographic Components 41
Lets return to Olivias attempt to compromise the condential 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 sufcient 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 Olivias man-in-the-middle attack on James and Charlies
symmetrically encrypted conversation relative to their asymmetrically encrypted conversation can
be observed.
Figure 2-6 An Attempt to Compromise a Symmetric Key Cryptosystem
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.
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.
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 condential exchange of data.
NOTE As we will discuss later in this text, IPsec uses the Dife-Hellman algorithm to derive
shared secret keys for bulk data encryption with a symmetric key transform. Dife-Hellman is
facilitated over a trusted channel secured with IKE.
Symmetric Key Symmetric Key
1 2
Encrypted Data
Encrypted Data
3
From the Library of Ahmed Aden
ptg12115235
42 Chapter 2: IPsec Fundamentals
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 xed-length code. The xed 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.
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 messages integrity has not been compromised. That is to say
that James message to Charlie has not been modied 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
dened 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 xed 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.
From the Library of Ahmed Aden
ptg12115235
Overview of Cryptographic Components 43
Figure 2-7 Creating and Verifying a Message Digest
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.
Fsd$#^@43#@Ad5J$
Message:
Message:
Hash Value:
Fsd$#^@43#@Ad5J$
Hash Value:
James
Shared Secret Key
Charlie
Hash:
MD5
Shared Secret Key Shared Secret Key
Test Message:
Charlie, are you there?
Message:
Test Message:
Charlie, are you there?
Test Message:
ABCD1234
1
Fsd$#^@43#@Ad5J$
Hash Value:
James
Shared Secret Key
Charlie
Hash:
MD5
2
Fsd$#^@43#@Ad5J$
Hash Value:
Hash Function/Algorithm
Hash Function/Algorithm
Hashes match:
Message authentic
w/integrity
From the Library of Ahmed Aden
ptg12115235
44 Chapter 2: IPsec Fundamentals
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 certicate 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 veried
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 veried, 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 rst 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.
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.
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.
From the Library of Ahmed Aden
ptg12115235
Overview of Cryptographic Components 45
Figure 2-8 Generating and Verifying a Digital Signature
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.
Message:
Fsd$#^@43#@Ad5J$
Hash Value:
James
Private Key
Charlie
Cipher:
RSA
Public Key
Private Key
Message:
Test Message:
Lets go get some lunch
Test Message:
Lets go get some lunch
Encrypted Hash, or Digital Signature is appended
to the message and forwarded to Charlie
James Public Key is forwarded to
Charlie to decrypt the Digital Signature
James forwards original
message to Charlie
DIGITAL
SIGNATURE
DIGITAL
SIGNATURE
2
Fsd$#^@43#@Ad5J$
Hash Value:
James
Public Key
Charlie
Hash:
MD5
4
Fsd$#^@43#@Ad5J$
Hash Value:
Hash Function/Algorithm
Message:
Fsd$#^@43#@Ad5J$
Hash Value:
James
Public Key
Charlie
Hash:
MD5
Private Key
Public Key
Test Message:
Lets go get some lunch
Message:
Test Message:
Lets go get some lunch
Message:
Test Message:
Lets go get some lunch
DIGITAL
SIGNATURE
1
Hash Function/Algorithm
Hashes match:
message authentic
w/integrity
Fsd$#^@43#@Ad5J$
Hash Value:
James
Public Key
Charlie
Decipher
RSA
3
Fsd$#^@43#@Ad5J$
Hash Value:
From the Library of Ahmed Aden
ptg12115235
46 Chapter 2: IPsec Fundamentals
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 ngerprint 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 verication.
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. Charlies rst 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 others public
key to encrypt communications that are decipherable by the other party. Lets 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.
Charlies 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 Charlies 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 Olivias public key, thinking that he is using
Charlies public key, and transmits it to Olivia unknowingly.
From the Library of Ahmed Aden
ptg12115235
Public Key Encryption Methods 47
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 Charlies 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.
Figure 2-9 Compromised Keys in an Asymmetric Exchange
Apply this type of attack to an exchange of nancial account information between large global
nancial 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
well discuss at several points throughout this text, many of these methods are secured by the
computational difculty of factoring two large prime numbers. Let us begin our exploration of
these techniques by discussing the RSA encryption algorithm.
Public Key, James Public Key, Charles
Private Key, James Private Key, Charles
James
Public Key, Olivia
Private Key, Olivia
Olivia
Charlie
3 5 2
1
4
Go Blue Devils! Go Tar Heels! Go Blue Devils! Go Tar Heels!
Hi, Im Charlie, give me your
public key so that we can talk.
Message Altered
1
Hi, Im James, give me your
public key so that we can talk.
Message: New Message:
From the Library of Ahmed Aden
ptg12115235
48 Chapter 2: IPsec Fundamentals
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 dened 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.
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) (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 [(P 1) (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.
From the Library of Ahmed Aden
ptg12115235
Public Key Encryption Methods 49
Figure 2-10 Encrypting Data with the RSA Encryption Algorithm
3. James uses Charlies 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.
2
3
1
James
RSA Pub James
(E = 11, M = 15)
Charlie
RSA Private James
(D = 3)
Random Prime #1, (P) = 5
Random Prime #2, (Q) = 3
Modulus (M) = (P) (Q) = 15
Encryption Exponent (E) = 11
Decryption Exponent (D) = 3
RSA Pub James
(E = 11; M = 15)
James Charlie
RSA Private James
(D = 3)
RSA Private James
(D = 3, M = 15)
RSA Public James
(E = 11, M = 15)
Charlie did you catch the
Saints game last night?
Charlie did you catch the
Saints game last night?
f8desa0RQ(eQW*()SD
Clear Text:
Cipher Text:
James
f8desa0RQ(eQW*()SD
Clear Text:
Cipher Text:
Cipher:
RSA
Charlie
Cipher:
RSA
Decryption Cipher = [(CT) ^ D] mod M
Encryption Cipher =
[(PT) ^ E] mod M
From the Library of Ahmed Aden
ptg12115235
50 Chapter 2: IPsec Fundamentals
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 difculty 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.
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 sacricing 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 Certicates and Certicate authorities. This method of authentication, though more
complicated to congure, offers a more scalable conguration alternative to RSA encryption and
preshared keys.
Crypto endpoints using RSA signatures use X.509 certicates to authenticate and enroll with the
CA. Using a central resource for authentication services, the Certicate Authority, simplies
maintenance on both crypto endpoints. This is particularly useful in large networks, as
NOTE Cisco manufactures crypto engines that can support key length (modulus) sizes of up
to 2048 bits in length. As weve 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.
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 51
administrators now congure each crypto endpoint to use the CA for authentication, instead of
manually conguring preshared keys for each peer. Cisco IOS supports RSA signatures when
negotiating ISAKMP SAs. The operation and conguration of crypto endpoints using RSA
signatures is covered in greater detail in Chapter 11, Public Key Infrastructure and IPsec VPNs.
Dife-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 Dife-Hellman algorithm to securely derive shared keys across an untrusted network
infrastructure.
Dife-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 Dife-Hellman exchange. IKE uses Dife-Hellman keys to encrypt the ISAKMP SA over
which IPsec SAs are established. Likewise, Dife-Hellman is used to generate keys to be used in
the ciphers specied in IPsec transforms. These transforms, when used in conjunction with Dife-
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 specically, 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
dened 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. Weve
discussed in detail the operation of many different cryptographic components designed to deliver
services such as data authentication, data condentiality, 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 condentiality, and
sender nonrepudiation include IKE for authenticity and the Encapsulating Security Payload for
condentiality. We will explore these protocols and others as we present a comprehensive
overview of the mechanics of IPsec.
NOTE Dife-Hellman is a core component of the IKE protocol. Aspects of the Dife-
Hellman algorithm will be covered in additional detail in the IKE and perfect forward secrecy
(PFS) section of this chapter.
From the Library of Ahmed Aden
ptg12115235
52 Chapter 2: IPsec Fundamentals
IPsec VPNs encrypt data at the Layer-3 IP packet layer, offering a comprehensively secure VPN
solution through providing data authentication, antireplay protection, data condentiality, and data
integrity protection. As such, IPsec is one of the most widespread VPN technologies in todays
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 well 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
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.
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 condentiality. The key choice in selection of an IPsec operational mode is determination of
what parts of IP headers and payloads are to be kept condential.
Transport Mode
RFC 2401 denes 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
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.
Cryptographic Components
Security Association and
Key Management
IPSec Components
Clarify SA and Key Management concerns
within IPSec framework (ISAKMP, Diffie-
Hellman, xauth and mode config)
Apply cryptographic components
to IPSec fundamentals (cipher,
SA construct)
1 2 3
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 53
condential. 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
Tunnel mode places the ESP header before the IP header, offering condentiality 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
IP Header
ESP
Header
ESP
Trailer
ESP
Auth.
TCP
Header
Data
Encrypted
Unprotected Unprotected
Authenticated
VC4
VC2 VC3
VC1
James
Kristen
Charlie
VC5
Outer IP
Header
ESP
Header
ESP
Trailer
ESP
Auth.
TCP
Header
Data
Original IP
Header
Sent on VC4 to James
I cant see the
original source and dest
IP addresses, so I cant
use WFQ to hash them
in to the correct
conversation!
ATM OC3
(VCs 1, 2, 3, 4, and 5)
All of my original souirce and
destination addresses are
now the tunnel source and
destination address located
in the Outer IP Header.
From the Library of Ahmed Aden
ptg12115235
54 Chapter 2: IPsec Fundamentals
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 condential 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 condentiality 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
Tunnel mode denes a broader protective boundary at the packet layer, and hence provides a
greater scope of condentiality. 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 condentiality 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
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.
Outer IP
Header
Original IP
Header
ESP
Header
ESP
Trailer
ESP
Auth.
TCP
Header
Data
Encrypted
Unprotected Unprotected
Authenticated
Original IP Header kept confidential,
encapsulated in ESP. Outer IP header
prepended maintain IP connectivity.
Note:
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 55
concepts pertaining to the appropriateness of IPsec tunnel mode and transport mode in subsequent
chapters.
IPsec Transforms
As discussed above, IPsec delivers data condentiality 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 specications for IPsecs 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 condentiality, data origin authentication, data integrity
assurance mechanisms, and data ow condentiality. 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 Trafc-Flow Condentiality
ESP provides condentiality 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 condentiality protection for Layer 47
protocol informationit is effective at providing condentiality 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 dening 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 trafc ows themselves, in addition to Layer 47
protocol information protected in transport mode.
From the Library of Ahmed Aden
ptg12115235
56 Chapter 2: IPsec Fundamentals
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 packets appropriate
SA is critical, as each SA may be processed under a variety of different parameters, such as
selected encryption transforms and Dife-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 trafc in both tunnel (Figure 2-14) and
transport mode (Figure 2-12).
Data Authentication and Integrity
ESP denes 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 trafc. In the context of IPsec, an HMAC would be specied 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 Dife-Hellman exchange), a hash function (IPsec
RFC accepts MD 5 and SHA-1), and xed message input.
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-ord with specied array to create K1.
3. (First Message Block + K1) is hashed with a specied hash function (such as MD 5 or SHA-1)
to create Hash1.
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 condentiality with the cost of their VPN infrastructure.
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.
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 57
4. Shared secret key is x-ord again with another specied array to create K2.
5. (Hash1 + K2) is hashed with a specied hash function to create Hash2.
6. Shared secret key is x-ord again with another specied array to create Kn.
7. (Hashn + Kn) is hashed with a specied hash function to create Hash(n+1).
As weve 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 rst 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 condentiality 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 eld, called the authentication header,
protecting the data payload and parts of the original IP header. Unlike ESP, however, IPsec AH
does not provide data condentiality. 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 encapsu-
lated with Authentication Headers in tunnel mode.
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.
IP
Header
Authentication
Header
TCP
Header
Data
Authenticated
From the Library of Ahmed Aden
ptg12115235
58 Chapter 2: IPsec Fundamentals
Figure 2-16 IPsec Authentication Headers in Tunnel Mode
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 condentiality 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 condentiality 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 efcient 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 condentiality, compression of the data payload must occur before the packet is
compressed.
Outer IP
Header
Inner IP
Header
Authentication
Header
TCP
Header
Data
Authenticated
Original IP
Header
IPComp
Header
Data
Note:
Compressed
Original IP Header is not compressed, but
certain elements are updated to accommodate
the IPComp header, including length, protocol
number (109 for IPComp), and header checksum.
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 59
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 efcient 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:
ModeThe IPsec mode used for ESP and AH packet transformation. This will be either
transport or tunnel, as described in preceding text.
TransformThe IPsec encapsulation protocol and cipher used to transform the cleartext
packets. This will include specication 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.
PeerSpecies the peer with which to negotiate IPsec SAs. The IPsec peer is dened as the
destination on which the IPsec tunnel is to be terminated.
Matched TrafcIPsec peers must be congured 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
species encrypted data that is outside of Charlies data set to be decrypted from James, then
the IPsec will reject the SA establishment. If James species encrypted data that matches
Charlies 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 trafc
set mismatch dened in the cryptographic endpoints crypto ACLs.
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.
From the Library of Ahmed Aden
ptg12115235
60 Chapter 2: IPsec Fundamentals
Figure 2-18 IPsec Trafc Set Mismatch and SA Negotiation
Path MTUIPsec 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 trafc 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 well 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.
James
Workstation A
20.0.1.1/24
1
Serial2/0
10.0.0.0/8
.1
Serial2/0
10.0.0.0/8
.2
Charlie
I want to encrypt traffic from
20.0.1.0/24 to 30.0.0.0/8
I want to encrypt traffic from
30.0.1.0/24 to 20.0.1.0/24
IPSec SA Negotiation
Traffic going from
Workstation A to
Workstation B
matches the James
crypto map ACL
Encrypted Traffic
from James does
not match Charlies
decryption scope
20.0.0.0/8
Workstation B
30.0.100.1/24
30.0.0.0/8
James Scope of
Decryption
Charlies Scope
of Encryption
James
2
Serial2/0
10.0.0.0/8
.1
Serial2/0
10.0.0.0/8
.2
Charlie
I want to encrypt traffic from
20.0.1.0/24 to 30.0.0.0/8
I want to encrypt traffic from
30.0.0.0/8 to 20.0.1.0/24
IPSec SA Negotiation
20.0.0.0/8 30.0.0.0/8
James Scope of Decryption matches
Charlies Scope of Encryption and vice-versa.
As such, IPSec accepts the proposed ranges
of addresses from James and Charlie.
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 61
SPIthe IPsec SPI is a unique 32-bit value in the IPsec-transformed packet that identies
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 trafc from
all of its spokes on many different SAs. The IPsec hub uses the SPI to determine which IPsec
SA the trafc 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
10.0.0.0/8
James Ziggy
Kristen
Charles
IPSec Transform:
AH, DES Cipher
SHA-1 HMAC
Authentication.
I must support
IPSec SAs for all valid
peers. I therefore use
SPIs to uniquely
identify these SAs.
IPSec Transform:
ESP, AES Cipher
40.0.0.0/8
IPSec Transform:
ESP, AES Cipher
MD5-HMAC
Authentication.
40.0.0.0/8 20.0.0.0/8
ATM3/0
Includes Subinterfaces A3/0.1, .2, and .3
Includes ATM VCs 1, 2, and 3.
ATM3/0.1
VC1
ATM3/0.3
VC3
ATM3/0.2
VC2
1
7
0
.
1
.
1
.
0
/
3
0
1
7
0
.
1
.
1
.
8
/
3
0
1
7
0
.
1
.
1
.
4
/
3
0
IPSec VPN Tunnels
From the Library of Ahmed Aden
ptg12115235
62 Chapter 2: IPsec Fundamentals
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.
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
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
Dened Preshared keys, RSA Encrypted Nonces (public only), or CA-signed RSA
Certicates. An IKE SA is formed between the routers.
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).
James
Workstation A
20.0.1.1/24
Serial2/0
10.0.0.0/8
.1
Serial2/0
10.0.0.0/8
.2
Charlie
20.0.0.0/8
Workstation B
30.0.100.1/24
30.0.0.0/8
2
3
4
1
5
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 63
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 Dife-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 trafc from Workstation A accordingly
and forwards to Charlie.
5. Charlie, on receiving the packet, looks up the SPI to nd 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 nal destination.
For subsequent packets, the process starts at Step 4, because the SAs have been established. After
a dened interval (or data volume), the SAs will time out, and the next packet after this will trigger
the SA establishment process again.
IPsec Conguration 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 conguration
of an IPsec crypto map.
Creating an IPsec Transform
In order to implement an IPsec VPN, the administrator must rst make a series of
decisions that will eventually result in the creation of the IPsec transform. The IPsec transform
denes 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.
From the Library of Ahmed Aden
ptg12115235
64 Chapter 2: IPsec Fundamentals
Figure 2-21 IPsec Transform Creation Decision Tree
Select an IPSec
Transform
Select ESP as IPSec
Protocol
Select AH as IPSec
Protocol
Select ESP and AH to be
included in the transform
set
Is confidentiality
a requirement?
Do encrypted
packets also require
broad authentication
services?
YES NO
YES
NO
Select Transport Mode Select Tunnel Mode
Do lower-
layer protocols
require confidentiality
or full authentication
protection?
Do lower-layer
protocols require
full authentication
protection?
Do I need
additional
Authentication
and Integrity?
Do I need
additional
Authentication
and Integrity?
SHA-1 MD 5
DES AES 3DES
How Strong of
an Encryption
Cipher do I need?
NO
NO YES
YES
YES YES
Strong Stronger
Strongest
Stronger
Strong
How Strong do I
need the HMACs
to be?
No HMAC Authentication
NO NO
Select Transport Mode Select Tunnel Mode
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 65
The following list and examples use Figure 2-21 to illustrate the creation of a transform set
within IOS:
1. An IPsec transform set denes 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.
2. Also specied 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 waysspecically, as it pertains to header location and the scope of the ESP or AH
protection boundary. Example 2-2 illustrates the conguration of the mode that IPsec is to
operate in.
Example 2-1 IPsec Protocol Denition and Availability
James#
James#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
*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)#ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -111 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)#ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -111 1 eee esss sppp p--- -ddd deee esss s aaa ahhh h--- -sss shhh haaa a--- -hhh hmmm maaa accc c
James(config)#eee ennn nddd d
James(config)#
Example 2-2 IPsec Protocol Mode Denition
James#
James#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
*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)#ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -111 1 eee esss sppp p--- -ddd deee esss s aaa ahhh h--- -sss shhh haaa a--- -hhh hmmm maaa accc c
James(cfg-crypto-trans)#mmm mooo oddd deee e ??? ?
transport transport (payload encapsulation) mode
tunnel tunnel (datagram encapsulation) mode
James(cfg-crypto-trans)#mmm mooo oddd deee e ttt tuuu unnn nnnn neee elll l
James(cfg-crypto-trans)#eee ennn nddd d
James#
From the Library of Ahmed Aden
ptg12115235
66 Chapter 2: IPsec Fundamentals
3. The symmetric key encryption cipher to be used for the IPsec SA is dened 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 specied 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 dening transforms. As such, it helps to
think of transform creation as a series of sequential decisions as depicted by the owchart in
Figure 2-21.
As well see in later sections of this book, Charlie must be congured with a transform set that
matches James for the IPsec tunnel to negotiate properly. The transform set denes a variety of
security parameters that will be negotiated over IKE when IPsec SAs are formed.
Crypto Map Conguration
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 conguration 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 congured
with three items before it is activated by IOS:
An existing crypto ACL to dene trafc to be transformed.
An existing IPsec transform set to use when transforming packets that are inbound to the
IPsec engine.
A peer that denes the IPsec tunnel endpoint. The dened peer is necessary for the IPsec SA
to be established with the correct endpoint.
Consider Charlies conguration of a crypto map when setting up an IPsec tunnel to James in
Figure 2-20. It is assumed that Charlie has congured a transform set named IPSECVPN-1 that
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.
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 67
matches the one that James had congured in Examples 2-1 and 2-2. Charlie matches any SMTP
trafc destined James 20.0.0.0/8 network by referencing ACL 101 in his crypto map. Last, Charlie
denes James serial interface IP address as the IPsec tunnel endpoint so that IPsec understands
which destination the Charlies IPsec SA to James (rememberIPsec builds two unidirectional
SAs) should reference. Example 2-3 illustrates Charlies conguration of the three minimal
objectives to establish his crypto map and the binding of the crypto map to his serial interface.
Charlie congures a crypto map to communicate with James via IPsec. To achieve this, Charlie
congures 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 congured for the crypto map to be activated. Charlie
references access-list 101 as trafc 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 trafc matching ACL 101, as illustrated in Example 2-3, lines 8
and 11, respectively. When Charlie wants to encrypt e-mail trafc (SMTP) destined to James
(hosts on 20.0.0.0/8), he sets up ACL 101 to reference SMTP trafc destined to that subnet and
tells IPsec to use ACL 101 when deciding which trafc 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 rst congures 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 congured for the crypto map
to be activated. James references access-list 101 as trafc to be processed by IPsec in this crypto
map, after which he selects the IP address of Charlies 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 trafc
matching ACL 101 (Example 2-3, lines 25 and 27, respectively). When James wants to encrypt
e-mail trafc (SMTP) destined to Charlie (hosts on 30.0.0.0/8), he sets up ACL 101 to reference
SMTP trafc destined to that subnet and tells IPsec to use ACL 101 when deciding which trafc
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 Conguration Objectives for a Crypto Map
Charlie#
Charlie#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
*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.
continues
From the Library of Ahmed Aden
ptg12115235
68 Chapter 2: IPsec Fundamentals
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.
Charlie(config)# ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -111 1 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
Charlie(config-crypto-map)#mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
Charlie(config-crypto-map)#sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .111 1
Charlie(config-crypto-map)#sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -111 1
Charlie(config-crypto-map)#eee exxx xiii ittt t
Charlie(config)#aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1 ppp peee errr rmmm miii ittt t ttt tccc cppp p 333 3000 0... .000 0... .000 0... .000 0 000 0... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5 222 2000 0... .000 0... .000 0... .000 0 000 0... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5
eee eqqq q sss smmm mttt tppp p
Charlie(config)#
Charlie(config)#iii innn nttt teee errr rfff faaa accc ceee e sss seee errr riii iaaa alll l222 2/// /000 0
Charlie(config-if)#ccc crrr ryyy yppp pttt t mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -111 1
Charlie(config-if)#eee ennn nddd d
Charlie#
James#
James#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
*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)# ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -111 1 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
Charlie(config-crypto-map)#mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
James(config-crypto-map)#sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .222 2
James(config-crypto-map)#sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -111 1
James(config-crypto-map)#eee exxx xiii ittt t
James(config)#aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1 ppp peee errr rmmm miii ittt t ttt tccc cppp p 222 2000 0... .000 0... .000 0... .000 0 000 0... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5 333 3000 0... .000 0... .000 0... .000 0 000 0... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5 eee eqqq q
sss smmm mttt tppp p
James(config)#iii innn nttt teee errr rfff faaa accc ceee e sss seee errr riii iaaa alll l222 2/// /000 0
James(config-if)#ccc crrr ryyy yppp pttt t mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -111 1
James(config-if)#eee ennn nddd d
James#
NOTE All Cisco IOS and Cisco VPN appliances support IKE and ISAKMP protocols.
Example 2-3 Minimum IOS Conguration Objectives for a Crypto Map (Continued)
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 69
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 Dife-Hellman keys using PFS.
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 congurations to support
IKE. Examples 2-4 and 2-5 illustrate conguration objectives required to create manual keys
between James and Charlie.
Once James applies the crypto map to his interface, the SA is established. In this conguration, 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.
NOTE PFS is a means by which to improve the freshness of IPsec shared secret keys
generated using Dife-Hellman. PFS is discussed in greater detail later in this chapter.
Example 2-4 IPsec Manual Keying CongurationJames
James#
James#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
*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)#ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -222 2 eee esss sppp p--- -ddd deee esss s
James(cfg-crypto-trans)#mmm mooo oddd deee e ttt tuuu unnn nnnn neee elll l
James(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -222 2 111 1000 0 III IPPP Psss seee eccc c--- -mmm maaa annn nuuu uaaa alll l
James(config-crypto-map)#sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .222 2
James(config-crypto-map)#sss seee ettt t sss seee esss ssss siii iooo onnn n--- -kkk keee eyyy y iii innn nbbb booo ouuu unnn nddd d eee esss sppp p 111 1000 0000 0111 1 ccc ciii ippp phhh heee errr r 111 1222 2333 3444 4aaa abbb bccc cddd d111 1222 2333 3444 4aaa abbb bccc cddd d
aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tooo orrr r 000 0111 1
James(config-crypto-map)#sss seee ettt t sss seee esss ssss siii iooo onnn n--- -kkk keee eyyy y ooo ouuu uttt tbbb booo ouuu unnn nddd d eee esss sppp p 111 1000 0000 0000 0 ccc ciii ippp phhh heee errr r aaa abbb bccc cddd d111 1222 2333 3444 4aaa abbb bccc cddd d111 1222 2333 3444 4
aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tooo orrr r 000 0111 1
James(config-crypto-map)#sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -222 2
James(config-crypto-map)#mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
James(config-crypto-map)#eee exxx xiii ittt t
James(config)#aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1 ppp peee errr rmmm miii ittt t ttt tccc cppp p 222 2000 0... .000 0... .000 0... .000 0 000 0... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5 333 3000 0... .000 0... .000 0... .000 0 000 0... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5 eee eqqq q
sss smmm mttt tppp p
James(config)#iii innn nttt teee errr rfff faaa accc ceee e sss seee errr riii iaaa alll l222 2/// /000 0
James(config-if)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -222 2
James(config-if)#eee ennn nddd d
James#
From the Library of Ahmed Aden
ptg12115235
70 Chapter 2: IPsec Fundamentals
Example 2-5 James IPsec SA Establishment Process
James#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c
*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#
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 71
Charlie must now apply a crypto map with matching session keys and matching security
parameters (trafc sets and transform sets) to be able to decrypt trafc from James and encrypt
trafc to James. Example 2-6 illustrates Charlies conguration 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 Charlies inbound session key).
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-6 IPsec Manual Keying ExampleCharlie
Charlie#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
*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)#ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -222 2 eee esss sppp p--- -ddd deee esss s
Charlie(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -222 2 111 1000 0 III IPPP Psss seee eccc c--- -mmm maaa annn nuuu uaaa alll l
Charlie(config-crypto-map)#sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .111 1
Charlie(config-crypto-map)#sss seee ettt t sss seee esss ssss siii iooo onnn n--- -kkk keee eyyy y iii innn nbbb booo ouuu unnn nddd d eee esss sppp p 111 1000 0000 0000 0 ccc ciii ippp phhh heee errr r aaa abbb bccc cddd d111 1222 2333 3444 4aaa abbb bccc cddd d111 1222 2333 3444 4
aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tooo orrr r 000 0111 1
Charlie(config-crypto-map)#sss seee ettt t sss seee esss ssss siii iooo onnn n--- -kkk keee eyyy y ooo ouuu uttt tbbb booo ouuu unnn nddd d eee esss sppp p 111 1000 0000 0111 1 ccc ciii ippp phhh heee errr r 111 1222 2333 3444 4aaa abbb bccc cddd d111 1222 2333 3444 4aaa abbb bccc cddd d
aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tooo orrr r 000 0111 1
Charlie(config-crypto-map)#sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -222 2
Charlie(config-crypto-map)#mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
Charlie(config-crypto-map)#eee exxx xiii ittt t
Charlie(config)#aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1 ppp peee errr rmmm miii ittt t ttt tccc cppp p 333 3000 0... .000 0... .000 0... .000 0 000 0... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5 222 2000 0... .000 0... .000 0... .000 0 000 0... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5
eee eqqq q sss smmm mttt tppp p
Charlie(config)#iii innn nttt teee errr rfff faaa accc ceee e sss seee errr riii iaaa alll l222 2/// /000 0
Charlie(config-if)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -222 2
Charlie(config-if)#eee ennn nddd d
Charlie#
Example 2-7 Charlies IPsec SA Establishment Process
Charlie#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c
*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),
continues
From the Library of Ahmed Aden
ptg12115235
72 Chapter 2: IPsec Fundamentals
Once James and Charlie have established an IPsec SA, they should be able to encrypt and decrypt
trafc 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 Charlies SADB and in the crypto
engine connection database.
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#
Example 2-8 Charlie Veries SA Establishment with James and Veries Encryption/Decryption Activity in
His IPsec Crypto Engine
Charlie#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c sss saaa a
interface: FastEthernet0/0
Crypto map tag: IPSECMAP-2, local addr. 10.1.1.2
Example 2-7 Charlies IPsec SA Establishment Process (Continued)
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 73
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn n aaa accc cttt tiii ivvv veee e
continues
Example 2-8 Charlie Veries SA Establishment with James and Veries Encryption/Decryption Activity in
His IPsec Crypto Engine (Continued)
From the Library of Ahmed Aden
ptg12115235
74 Chapter 2: IPsec Fundamentals
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c sss saaa a
Example 2-8 Charlie Veries SA Establishment with James and Veries Encryption/Decryption Activity in
His IPsec Crypto Engine (Continued)
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 75
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:
continues
Example 2-8 Charlie Veries SA Establishment with James and Veries Encryption/Decryption Activity in
His IPsec Crypto Engine (Continued)
From the Library of Ahmed Aden
ptg12115235
76 Chapter 2: IPsec Fundamentals
Now that Charlie has sent 1499 encrypted packets to James, James can take steps to see what
trafc he has decrypted from Charlie, and if hes encrypted any trafc 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.
Charlie#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn n aaa accc cttt tiii ivvv veee e
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#
Example 2-9 James Checks Decryption of Charlies Trafc (ICMP Echo Request) and Then Veries That
He Is Encrypting Responses to Charlie (ICMP Echo Replies)
James#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c sss saaa a
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
Example 2-8 Charlie Veries SA Establishment with James and Veries Encryption/Decryption Activity in
His IPsec Crypto Engine (Continued)
From the Library of Ahmed Aden
ptg12115235
The IP Security Protocol (IPsec) 77
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 xed, 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
inefciencies 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 specied 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.
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn n aaa accc cttt tiii ivvv veee e
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#
Example 2-9 James Checks Decryption of Charlies Trafc (ICMP Echo Request) and Then Veries That
He Is Encrypting Responses to Charlie (ICMP Echo Replies) (Continued)
From the Library of Ahmed Aden
ptg12115235
78 Chapter 2: IPsec Fundamentals
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 weve discussed that use manual SAs, IKE SAs can be
established on the y and torn down at a time period negotiated. As we had discussed before, IPsec
species 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 dened 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 denes
procedures for:
Crypto endpoint authentication procedures
IPsec SA negotiation, maintenance, and timeout
Cryptographic key generation and exchange techniques (Dife-Hellman)
Threat mitigation (antireplay, DoS mitigation techniques)
However, ISAKMP is a framework for delivering these servicesit does not dene 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 t 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.
From the Library of Ahmed Aden
ptg12115235
IKE and ISAKMP 79
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 dened. This is not the case with IKE/
ISAKMP. IKE dynamically creates IPsec SAs upon the transmittal of trafc 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 efciently 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 conguration of the IPsec SA lifetime that Charlie would like to negotiate with
James during IKE.
IPsec Dife-Hellman Shared Secret Key Generation Using IKE
As weve 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.
Weve 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 trafc. As a result, manual session key
conguration requires that the crypto endpoints maintain all of the SAs congured 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.
Example 2-10 Charlie Species a Lifetime for His IPsec SAs, Negotiated with James During IKE
Charlie#
Charlie#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
Enter configuration commands, one per line. End with CNTL/Z.
Charlie(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 111 1000 0
Charlie(config)#lll liii ifff feee ettt tiii immm meee e ??? ?
<60-86400> lifetime in seconds
From the Library of Ahmed Aden
ptg12115235
80 Chapter 2: IPsec Fundamentals
Manual keying negates antireplay techniques between crypto peers.
There is no CA support for manual session keys.
As weve 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 congured in IKE, they
must be dynamically created. IKE uses the Dife-Hellman algorithm to dynamically create
session keys exchanged over IKE. Dife-Hellman is congured 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 Dife-Hellman secret key generation, as illustrated in
Example 2-11.
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 conguring 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 Dife-Hellman
algorithm.
Example 2-11 ISAKMP Policy Dife-Hellman Conguration (Charlie Selects DH MODP 2)
Charlie#
Charlie#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
Enter configuration commands, one per line. End with CNTL/Z.
Charlie(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 111 1000 0
Charlie(config-isakmp)#ggg grrr rooo ouuu uppp p ??? ?
1 Diffie-Hellman group 1
2 Diffie-Hellman group 2
5 Diffie-Hellman group 5
Charlie(config-isakmp)#ggg grrr rooo ouuu uppp p 222 2
Charlie(config-isakmp)#eee ennn nddd d
Charlie#
NOTE Dife-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 Dife-Hellman MODPs
ensure a stronger Dife-Hellman secret key. However, as Dife-Hellman MODP values get
larger, they become more computationally expensive.
From the Library of Ahmed Aden
ptg12115235
IKE and ISAKMP 81
Figure 2-22 James and Charlie Derive Shared Secret Keys Using Dife-Hellman
The following order of operations outlines the exchange that James and Charlie will execute when
deriving shared secret keys using Dife-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 dened by the equation A* = (Q ^ A) mod (P). Once he
has nished 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 dened by the equation B* = (Q ^ B) mod (P). Charlie
then shares this value with James.
f8desa0RQ(eQW*()SD f8desa0RQ(eQW*()SD
Test Message:
Lets go play some basketball
Message:
These can be any symmetric
key transforms, such as DES,
3DES, or AES
Note:
Test Message:
Lets go play some basketball
Message:
Select Number (Kept Private), A = 3
A* = (Q ^ A) mod (P) = 6
Select Number (Kept Private), B = 7
B* = (Q ^ B) mod (P) = 2
Derive Shared Secret Number
DHS = (A* ^ B) mod (P) = 8
Derive Shared Secret Number:
DHS = (B* ^ A) mod (P) = 8
Random Prime #1, (P) = 11
Random Prime #2, (Q) = 19
Cipher Text:
James
Cipher Text:
Cipher:
DES
Charlie
Cipher:
DES
Shared Secret Key, DH Shared Secret Key, DH
3
2
1
5
4 4
From the Library of Ahmed Aden
ptg12115235
82 Chapter 2: IPsec Fundamentals
4. James and Charlie derive their shared, secret (Dife-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 Dife-
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 Dife-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 Dife-Hellman derived keypair presents two mathematical tasks to would-be attackers who
wish to compromise the shared secret keys condentiality. 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 RSAs key strengthsthe attacker must be able to factor two large
prime numbers. Hence, Dife-Hellman values for P and Q share the same requirement as an RSA
key modulusit must be large and random. Dife-Hellman does not typically specify a modulus
size directly. Instead, the modulus of a Dife-Hellman key is referred to as the Dife-Hellman
group. There are four different Dife-Hellman Groups that yield a DHS that is approximately
equal to a 7080-bit symmetric key in strength.
Unless attackers can leap the mathematical hurdles described above, the DH secret key can be
shared between the peers condentially without an attacker being able to determine its value. IKE
provides for additional condentiality 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 congured in Example 2-12, using the Dife-Hellman shared secret as the symmetric
encryption key on each peer.
NOTE Existing Dife-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 fth Dife-Hellman group. RFC 3526 describes the development
of DH group 5 in more detail.
From the Library of Ahmed Aden
ptg12115235
IKE and ISAKMP 83
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 IKEs supported authentication
protocols, which include:
Pre-Shared Keys
RSA Encryption (Encrypted Nonces)
RSA Signatures (X.509 certicate basedrequires X.509 CA)
Pre-Shared Keys
For smaller networks on which keys can be manually dened, IKE preshared keys (PSKs) can be
used. PSKs are manually dened 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.
To guarantee authenticity of this message exchange, IKE appends a message digest to the key
through a user-dened hash algorithm (MD5 or SHA-1). Example 2-13 shows the required IKE
congurations on James and Charlie.
Example 2-12 James Congures IPsec and IKE Encryption Ciphers.
James#
James#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
Enter configuration commands, one per line. End with CNTL/Z.
James(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 111 1000 0
James(config-isakmp)#eee ennn nccc crrr ryyy yppp pttt tiii iooo onnn n 333 3DDD DEEE ESSS S
James(config-isakmp)eee ennn nddd d
James#
TIP The Dife-Hellman keys used for encrypting IKE can also be used as the shared session
key for the cipher specied in the IPsec transform. For stronger security, another new Dife-
Hellman key can be created over IKE for use with IPsec transform ciphers.
NOTE A dened, static PSK may specify a single peer to share a key with. Alternately, a range
of peers can be specied for a single key using wildcard subnet masks in the ISAKMP key
denition. A single IKE PSK dened for use with multiple peers using wildcard subnet masks
is typically referred to as a wildcard preshared key.
From the Library of Ahmed Aden
ptg12115235
84 Chapter 2: IPsec Fundamentals
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 (administrators 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 aws 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
Example 2-13 IKE Congurations for James and Charlie Using PSKs
Charlie#
Charlie#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
*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)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y uuu unnn nccc cttt taaa arrr rhhh heee eeee elll lsss s aaa addd dddd drrr reee esss ssss s 111 1000 0... .111 1... .111 1... .111 1
Charlie(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 111 1000 0
Charlie(config-isakmp)# eee ennn nccc crrr ryyy yppp pttt tiii iooo onnn n 333 3ddd deee esss s
Charlie(config-isakmp)# aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tiii iooo onnn n ppp prrr reee e--- -sss shhh haaa arrr reee e
Charlie(config-isakmp)# ggg grrr rooo ouuu uppp p 222 2
Charlie(config-isakmp)# lll liii ifff feee ettt tiii immm meee e 555 5000 0000 0000 0000 0
Charlie(config-isakmp)#eee ennn nddd d
Charlie#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
Enter configuration commands, one per line. End with CNTL/Z.
Charlie(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -333 3 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
Charlie(config-crypto-map)# sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .111 1
Charlie(config-crypto-map)# sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -222 2
Charlie(config-crypto-map)# mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
Charlie(config-crypto-map)#eee ennn nddd d
Charlie#
James(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 111 1000 0
James(config-isakmp)# eee ennn nccc crrr ryyy yppp pttt tiii iooo onnn n 333 3ddd deee esss s
James(config-isakmp)# aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tiii iooo onnn n ppp prrr reee e--- -sss shhh haaa arrr reee e
James(config-isakmp)# ggg grrr rooo ouuu uppp p 222 2
James(config-isakmp)# lll liii ifff feee ettt tiii immm meee e 555 5000 0000 0000 0000 0
James(config-isakmp)#eee exxx xiii ittt t
James(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y uuu unnn nccc cttt taaa arrr rhhh heee eeee elll lsss s aaa addd dddd drrr reee esss ssss s 111 1000 0... .111 1... .111 1... .222 2
James(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -333 3 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
James(config-crypto-map)#mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
James(config-crypto-map)#sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m
James(config-crypto-map)#sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -222 2
James(config-crypto-map)#sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .222 2
James(config-crypto-map)#eee ennn nddd d
From the Library of Ahmed Aden
ptg12115235
IKE and ISAKMP 85
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 certicates), 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 congured 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.
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 Initiators 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 Initiators 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, Dife-Hellman secrets, and other items specic 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.
From the Library of Ahmed Aden
ptg12115235
86 Chapter 2: IPsec Fundamentals
Figure 2-23 RSA-Encrypted Nonce Authentication
RSA Signatures and X.509 Certicates
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
James Charlie
Cipher:
RSA
Public Key, James
Public Key, James
Private Key, James
Public Key, Charlie
Private Key, Charlie
1 1 2
3
5
4
6
7
8
Nonce, I
Hash_I
Cipher:
RSA
Nonce, I
Nonce, R
Cipher:
RSA
Cipher:
RSA
Hash_R
Nonce, R
Private Key, James
From the Library of Ahmed Aden
ptg12115235
IKE and ISAKMP 87
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
certicates with an X.509 compliant Certicate Authority (CA).
ITU-T X.509 Certicates 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 certicates in a
standard format that is agreed upon with its peers. ITU-T X.509 formatted certicates are
commonly accepted as the standard for this type of public key cryptosystem.
Certicate 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 condentiality 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 Certicate
Enrollment Protocol (SCEP), as dened by the X.509 standard. The transport used to distribute
certicates 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 certicate transport, including rewalls, intrusion detection systems, routers,
switches, and VPN concentrators.
IKE Phase I Negotiation
As weve 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
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 certicate.
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 conguring 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.
From the Library of Ahmed Aden
ptg12115235
88 Chapter 2: IPsec Fundamentals
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
Dife-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 condential 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
James Charlie
Charlie responds with a selected group of security parameters
based on James proposed options and preferences.
James sends his Diffie-Hellman public key and nonce.
Charlie sends James his Diffie-Hellman public key and nonce.
James sends authentication message to Charlie (encrypted with
Diffie-Hellman key and selected cipher, authenticated with hash).
Charlie sends authentication message to James (encrypted with
Diffie-Hellman key and selected cipher, authenticated with hash).
James sends security proposal to Charlie, containing options and
preferences for encryption cipher, authentication hash,
authentication method, and Diffie-Hellman group number.
1
2
3
From the Library of Ahmed Aden
ptg12115235
IKE and ISAKMP 89
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 Dife-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 Dife-Hellman public keys and nonces. The two parties are able
to derive shared Dife-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 Dife-Hellman exchange, and an agreed-upon cipher, the authentication
messages can be encrypted. This allows for a purely condential exchange when establishing
ISAKMP SA, as identity messages are never sent in the clear and are sent with appended
hashes for message authentication.
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 Dife-Hellman group number. Unlike main mode, in aggressive mode the senders and
receivers identities are not encrypted because they are sent concurrently with cryptographic
elements needed for encryption in the rst IKE aggressive mode exchange. In an aggressive mode
exchange, the Dife-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 senders and receivers
identities are exchanged in cleartext. Figure 2-25 illustrates the negotiation of an IKE SA using
aggressive mode.
TIP IOS always attempts to negotiate IKE Phase I in main mode before attempting
aggressive mode. However, IOS can be congured not to attempt aggressive mode upon
failure to negotiate main mode. IOS will respond to crypto endpoints initiating aggressive
mode exchanges.
From the Library of Ahmed Aden
ptg12115235
90 Chapter 2: IPsec Fundamentals
Figure 2-25 IKE Exchange in Aggressive Mode
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 congured to disallow the use of aggressive mode as an option for Phase 1 negotiation, as
illustrated in Example 2-14.
IKE Phase II Negotiation
The goal of IKE Phase II negotiation is establishment of IPsec SAs between two endpoints. IKE
uses Dife-Hellman key exchange to negotiate the shared secret key to be used in the encryption
cipher specied in the IPsec transform set. The IPsec SA can include the shared Dife-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
negotiations 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
Example 2-14 Disallowing Aggressive Mode as an Option for Phase 1 Negotiation
James(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p aaa aggg gggg grrr reee esss ssss siii ivvv veee e--- -mmm mooo oddd deee e ddd diii isss saaa abbb blll leee e
James Charlie
Charlie responds with a selected group of security parameters
based on James proposed options and preferences. Charlie
sends his Diffie-Hellman public key and nonce.
James sends authentication message to Charlie (unencrypted, but
authenticated with message-digest verification).
Charlie sends authentication message to James (unencrypted,
but authenticated with message-digest verification).
James sends security proposal to Charlie, containing options and
preferences for encryption cipher, authentication hash,
authentication method, Diffie-Hellman public key, Diffie-Hellman
nonce, and Diffie-Hellman group number.
1
2
From the Library of Ahmed Aden
ptg12115235
IKE and ISAKMP 91
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
After IKE Phase II negotiation has successfully completed quick mode exchange, both crypto
endpoints should have three established security associations in their SADB:
ISAKMP SAThis is a bidirectional SA that is used to dynamically establish a secure
channel for the negotiation of IPsec SAs.
Outbound IPsec SAThis unidirectional SA is used to provide protection services offered
by IPsec to trafc that is to be transmitted to the remote tunnel endpoint, identied by the SPI
within the IPsec header.
Inbound IPsec SAThis unidirectional SA is used to process inbound IPsec trafc from
from a remote crypto endpoint. Again, this trafc is identied 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 condentiality of current and future session keys. PFS does this
by forcing renegotiation of shared Dife-Hellman keys whenever a new negotiation of ISAKMP
and IPsec SAs occurs. In doing so, PFS offers greater condentiality, 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 Dife-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 conguring
the IPsec crypto map, as illustrated in Example 2-15.
James Charlie
Charlie selects a security proposal (by setting the commit
bit in the ISAKMP header) from the list to use for IPSec SA
establishment.
James sends an authentication payload with message digest for
antireplay and authentication protection.
Charlie verifies the authentication hashs message digest.
James forwards a list of security proposals (AH vs. ESP, DES vs.
3DES, and MD5 vs. SHA, and description of traffic to be protected)
needed to establish the IPSec SA to Charlie.
1
2
From the Library of Ahmed Aden
ptg12115235
92 Chapter 2: IPsec Fundamentals
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.
Example 2-16 illustrates Kristens conguration for failover using IKE DPD to a redundantly
dened IPsec peer. To do this, Kristen species the use of IKE keepalives. If Kristens primary
peer, 10.1.1.2, goes ofine, 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 dened 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 dened with both peers (Example 2-16, lines 10 and 11).
Example 2-15 Conguring PFS
Charlie#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
Enter configuration commands, one per line. End with CNTL/Z.
Charlie(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -333 3 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
Charlie(config-crypto-map)#sss seee ettt t ppp pfff fsss s ??? ?
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)#sss seee ettt t ppp pfff fsss s ggg grrr rooo ouuu uppp p555 5
Charlie(config-crypto-map)#eee ennn nddd d
Charlie#
NOTE PFS requires IKE. As such, PFS can be congured only on crypto maps that
are congured for IKE/ISAKMP. Crypto maps using manually set session keys do not
support PFS.
From the Library of Ahmed Aden
ptg12115235
IKE and ISAKMP 93
Figure 2-27 Detecting Stale SAs with IKE Keepalives
Example 2-16 Kristen Uses DPD and IKE Keepalives for VPN High Availability
Kristen
Kristen#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
Enter configuration commands, one per line. End with CNTL/Z.
Kristen(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 111 1000 0
Kristen(config-isakmp)#hhh haaa asss shhh h sss shhh haaa a
Kristen(config-isakmp)#aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tiii iooo onnn n ppp prrr reee e--- -sss shhh haaa arrr reee e
Kristen(config-isakmp)#eee ennn nccc crrr ryyy yppp pttt tiii iooo onnn n 333 3ddd deee esss s
Kristen(config-isakmp)#eee exxx xiii ittt t
Kristen(config)#crypto isakmp keepalive 10
Kristen(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y nnn nccc csss sttt taaa attt teee ewww wooo olll lfff fppp paaa accc ckkk k aaa addd dddd drrr reee esss ssss s 111 1000 0... .111 1... .111 1... .222 2
Kristen(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y nnn nccc csss sttt taaa attt teee ewww wooo olll lfff fppp paaa accc ckkk k aaa addd dddd drrr reee esss ssss s 111 1000 0... .111 1... .111 1... .333 3
Kristen(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -111 1 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
Kristen(config-crypto-map)#mmm maaa attt tccc chhh h aaa addd dddd d 111 1000 0111 1
Kristen(config-crypto-map)#sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .222 2
Kristen(config-crypto-map)#sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .333 3
Kristen(config-crypto-map)#sss seee ettt t ttt trrr raaa annn nsss s III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -111 1
Kristen(config-crypto-map)#eee ennn nddd d
Kristen#
RP
ISP
Default Gateway to .1.
Charlie also injects default
gateway back to Kristen
via the chosen RP.
Default Gateway to .1.
James also injects default
gateway back to Kristen
via the chosen RP.
Charlie
(10.1.1.3)
James
(10.1.1.2)
Internet
Gateway
Kristen
(10.1.1.100)
Kristens crypto map is
configured with a redundant
peer and pre-shared key (see
Example 3-13). After her 3
rd
missed keepalive from James,
she automatically begins IKE
Phase I negotiation with Charlie.
James link to Kristen fails, and
as such, his IKE keepalives no
longer reach Kristen.
192.168.1.0/24
.3 .2
.1
From the Library of Ahmed Aden
ptg12115235
94 Chapter 2: IPsec Fundamentals
Dead Peer Detection (DPD) refers to a crypto endpoints ability to detect when one of its peers
goes ofine. DPD can be useful on highly available peers that are receiving trafc from its remote
crypto endpoints. With DPD, crypto endpoints will not send keepalives if they are sending trafc
to their peers. This keeps the processing of keepalives relatively low on crypto endpoints and
decreases use on links between crypto endpoints.
Conguring ISAKMP
In order to successfully congure 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 Dene the ISAKMP policy. Within the ISAKMP policy, dene security parameters
to be used with ISAKMP provided in the following list:
Authentication Method
Authentication Hash Algorithm
Encryption Cipher
Dife-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 identies 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 conguration corresponding to the exchange illustrated in
Figure 2-28.
From the Library of Ahmed Aden
ptg12115235
IKE and ISAKMP 95
Example 2-17 James and Charlie Use ISAKMP Policies for IKE Negotiation
James#
James#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
James(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 111 1000 0
James(config-isakmp)#eee ennn nccc crrr ryyy yppp pttt tiii iooo onnn n 333 3ddd deee esss s
James(config-isakmp)#aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tiii iooo onnn n ppp prrr reee e--- -sss shhh haaa arrr reee e
James(config-isakmp)#ggg grrr rooo ouuu uppp p 222 2
James(config-isakmp)#lll liii ifff feee ettt tiii immm meee e 555 5000 0000 0000 0000 0
James(config-isakmp)#eee exxx xiii ittt t
James(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 222 2000 0
James(config-isakmp)#hhh haaa asss shhh h mmm mddd d555 5
James(config-isakmp)#aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tiii iooo onnn n rrr rsss saaa a--- -eee ennn nccc crrr r
James(config-isakmp)#ggg grrr rooo ouuu uppp p 555 5
James(config-isakmp)#eee exxx xiii ittt t
James(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y uuu unnn nccc cttt taaa arrr rhhh heee eeee elll lsss s aaa addd dddd drrr reee esss ssss s 111 1000 0... .111 1... .111 1... .222 2
James(config)#ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -111 1 eee esss sppp p--- -ddd deee esss s
James(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -111 1 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
James(config-crypto-map)#sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .222 2
James(config-crypto-map)#sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -111 1
James(config-crypto-map)#mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
James(config-crypto-map)#eee exxx xiii ittt t
James(config)#iii innn nttt teee errr rfff faaa accc ceee e sss seee errr riii iaaa alll l222 2/// /000 0
James(config-if)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -111 1
James(config-if)#eee ennn nddd d
James#
Charlie#
Charlie#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
Charlie(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 111 1000 0
Charlie(config-isakmp)#eee ennn nccc crrr ryyy yppp pttt tiii iooo onnn n 333 3ddd deee esss s
Charlie(config-isakmp)#aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tiii iooo onnn n ppp prrr reee e--- -sss shhh haaa arrr reee e
Charlie(config-isakmp)#ggg grrr rooo ouuu uppp p 222 2
Charlie(config-isakmp)#lll liii ifff feee ettt tiii immm meee e 555 5000 0000 0000 0000 0
Charlie(config-isakmp)#eee exxx xiii ittt t
Charlie(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y uuu unnn nccc cttt taaa arrr rhhh heee eeee elll lsss s aaa addd dddd drrr reee esss ssss s 111 1000 0... .111 1... .111 1... .111 1
Charlie(config)#ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -222 2 eee esss sppp p--- -ddd deee esss s
Charlie(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -111 1 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
Charlie(config-crypto-map)#sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .111 1
Charlie(config-crypto-map)#sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t III IPPP PSSS SEEE ECCC CVVV VPPP PNNN N--- -222 2
Charlie(config-crypto-map)#mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
Charlie(config-crypto-map)#eee exxx xiii ittt t
Charlie(config)#iii innn nttt teee errr rfff faaa accc ceee e sss seee errr riii iaaa alll l222 2/// /000 0
Charlie(config-if)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p III IPPP PSSS SEEE ECCC CMMM MAAA APPP P--- -111 1
Charlie(config-if)#eee ennn nddd d
Charlie#
From the Library of Ahmed Aden
ptg12115235
96 Chapter 2: IPsec Fundamentals
Figure 2-28
IKE with RAVPN Extensions
There are extensions specied 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 Conguration
IKE Extended Authentication (x-Auth)
We will use an RAVPN topology in which remote clients with software-based IPsec VPN clients
installed use mode conguration for client IP address assignment and IKE x-Auth to enable
administrators to provision increased granularity when authenticating client sessions.
Mode Conguration
Using mode cong, administrators can dynamically manage RAVPN client addressing, domain
names, WINS servers, and DNS servers on the RAVPN concentrator itself. This greatly simplies
administrative overhead of the RAVPN for both network administrators and users. Mode cong
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 clients publicly available address, usually assigned by the clients ISP,
will populate the outer ESP or AH header.
James Charlie
James ISAKMP Security Proposal:
I prefer to use ISAKMP policy
20 (RSA-encryption, MD 5
hash, Diffie-Hellman Group 5,
with all other values default).
I will accept ISAKMP policy 10
(pre-shared keys, 3DES cipher,
Diffie-Hellman Group 2, SA
lifetime of 50000).
James and Charlie use ISAKMP policy 10
(pre-shared keys, 3DES cipher, Diffie-
Hellman group 2, and SA lifetime of 50000
to establish ISAKMP and IPSec SAs.
Charlies ISAKMP Proposal Selection:
I have no policy matching your
ISAKMP 20 proposal.
I have a matching proposal for
James ISAKMP 10 proposal.
I will set the selector bit in the
IPSec header, choosing ISAKMP 10.
From the Library of Ahmed Aden
ptg12115235
IKE and ISAKMP 97
IKE mode cong offers a scalable alternative to manually assigning tunneled IP address space to
each RAVPN client. With mode cong, IP addresses and other parameters are congured on the
concentrator and pushed to the clients after they have been authenticated in Phase I negotiation.
Mode cong does this by dynamically assigning IP addresses from a pool congured 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 conguration on Kristen,
the IOS VPN concentrator in this topology. In this specic example, Kristen is congured to assign
IP addresses from a locally dened pool, RAVPN-pool. Kristen is congured to assign addresses
in one of two ways:
Address assignment in response to a request (Charlies request in Figure 2-29).
Address assignment when initiating an IPsec VPN tunnel (James IP address assignment in
Figure 2-29).
Example 2-18 VPN Concentrator Settings for Extended Authentication
Kristen#
Kristen#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
Enter configuration commands, one per line. End with CNTL/Z.
Kristen(config)#aaa aaaa aaaa a nnn neee ewww w--- -mmm mooo oddd deee elll l
Kristen(config)#aaa aaaa aaaa a aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tiii iooo onnn n lll looo oggg giii innn n RRR RAAA AVVV VPPP PNNN N--- -aaa aaaa aaaa a ggg grrr rooo ouuu uppp p ttt taaa accc caaa accc csss s+++ +
Kristen(config)#aaa aaaa aaaa a aaa auuu uttt thhh hooo orrr riii izzz zaaa attt tiii iooo onnn n nnn neee ettt twww wooo orrr rkkk k RRR RAAA AVVV VPPP PNNN N--- -aaa aaaa aaaa a ggg grrr rooo ouuu uppp p ttt taaa accc caaa accc csss s+++ +
Kristen(config)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 111 1000 0
Kristen(config-isakmp)#hhh haaa asss shhh h mmm mddd d555 5
Kristen(config-isakmp)#aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tiii iooo onnn n ppp prrr reee e--- -sss shhh haaa arrr reee e
Kristen(config-isakmp)#ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ccc clll liii ieee ennn nttt t ccc cooo onnn nfff fiii iggg guuu urrr raaa attt tiii iooo onnn n ggg grrr rooo ouuu uppp p RRR RAAA AVVV VPPP PNNN N--- -ggg grrr rooo ouuu uppp p
Kristen(config-isakmp-group)#kkk keee eyyy y nnn nccc csss sttt taaa attt teee ewww wooo olll lfff fppp paaa accc ckkk k
Kristen(config-isakmp-group)#ddd dooo ommm maaa aiii innn n ccc ciii isss sccc cooo o... .ccc cooo ommm m
Kristen(config-isakmp-group)#ppp pooo oooo olll l RRR RAAA AVVV VPPP PNNN N--- -ppp pooo oooo olll l
Kristen(config-isakmp-group)#eee exxx xiii ittt t
Kristen(config)#ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t RRR RAAA AVVV VPPP PNNN N--- -ttt trrr raaa annn nsss sfff fooo orrr rmmm m eee esss sppp p--- -aaa aeee esss s eee esss sppp p--- -sss shhh haaa a--- -hhh hmmm maaa accc c
Kristen(cfg-crypto-trans)#mmm mooo oddd deee e ttt tuuu unnn nnnn neee elll l
Kristen(cfg-crypto-trans)#eee exxx xiii ittt t
Kristen(config)#ccc crrr ryyy yppp pttt tooo o ddd dyyy ynnn naaa ammm miii iccc c--- -mmm maaa appp p RRR RAAA AVVV VPPP PNNN N--- -ddd dyyy ynnn n 111 1000 0
Kristen(config-crypto-map)#sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t RRR RAAA AVVV VPPP PNNN N--- -111 1
Kristen(config-crypto-map)#eee exxx xiii ittt t
Kristen(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p RRR RAAA AVVV VPPP PNNN N--- -mmm maaa appp p ccc clll liii ieee ennn nttt t aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tiii iooo onnn n lll liii isss sttt t RRR RAAA AVVV VPPP PNNN N--- -aaa aaaa aaaa a
Kristen(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p RRR RAAA AVVV VPPP PNNN N--- -mmm maaa appp p iii isss saaa akkk kmmm mppp p aaa auuu uttt thhh hooo orrr riii izzz zaaa attt tiii iooo onnn n lll liii isss sttt t RRR RAAA AVVV VPPP PNNN N--- -aaa aaaa aaaa a
Kristen(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p RRR RAAA AVVV VPPP PNNN N--- -mmm maaa appp p ccc clll liii ieee ennn nttt t ccc cooo onnn nfff fiii iggg guuu urrr raaa attt tiii iooo onnn n aaa addd dddd drrr reee esss ssss s rrr reee esss sppp pooo onnn nddd d
Kristen(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p RRR RAAA AVVV VPPP PNNN N--- -mmm maaa appp p ccc clll liii ieee ennn nttt t ccc cooo onnn nfff fiii iggg guuu urrr raaa attt tiii iooo onnn n aaa addd dddd drrr reee esss ssss s iii innn niii ittt tiii iaaa attt teee e
Kristen(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p RRR RAAA AVVV VPPP PNNN N--- -mmm maaa appp p 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p ddd dyyy ynnn naaa ammm miii iccc c RRR RAAA AVVV VPPP PNNN N--- -ddd dyyy ynnn n
Kristen(config)#iii innn nttt teee errr rfff faaa accc ceee e FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /000 0
Kristen(config-if)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p RRR RAAA AVVV VPPP PNNN N--- -mmm maaa appp p
continues
From the Library of Ahmed Aden
ptg12115235
98 Chapter 2: IPsec Fundamentals
Figure 2-29 Address Assignment with IKE Extended Authentication
X-Auth
As condentiality continues to become increasingly important in VPNs, network administrators
are increasingly turning to IPsec as a solution in Remote Access VPN deployments. Weve
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 exibility when authenticating IPsec Remote Access VPN connections. For
example, administrators conguring x-Auth in RAVPN deployments can ofoad user
authentication to AAA servers such as CSACS.
Kristen(config-if)#eee exxx xiii ittt t
Kristen(config)#iii ippp p lll looo occc caaa alll l ppp pooo oooo olll l RRR RAAA AVVV VPPP PNNN N--- -ppp pooo oooo olll l 111 1000 0... .111 1... .111 1... .111 1 111 1000 0... .111 1... .111 1... .222 2555 5444 4
Access-list 101 permit
Kristen(config)#ttt taaa accc caaa accc csss s--- -sss seee errr rvvv veee errr r hhh hooo osss sttt t 111 1000 0000 0... .111 1... .111 1... .222 2555 5444 4
Kristen(config)#ttt taaa accc caaa accc csss s--- -sss seee errr rvvv veee errr r ddd diii irrr reee eccc cttt teee eddd d--- -rrr reee eqqq quuu ueee esss sttt t
Kristen(config)#ttt taaa accc caaa accc csss s--- -sss seee errr rvvv veee errr r kkk keee eyyy y CCC Ciii isss sccc cooo o
Example 2-18 VPN Concentrator Settings for Extended Authentication (Continued)
James
Kristen
CiscoSecure
AAA Server
Charlie
Kristen assigns (initiates) a
private address to use for his
IPSec tunnel endpoint.
Kristen and James complete
IKE Phase I authentication.
Kristen responds to Charlies
request for a IP address to use
for his IPSec tunnel endpoint.
Charlie and Kristen complete
Phase I IKE authentication.
ISP
Kristens is configured with a dynamic crypto map to
negotiate Phase IKE with James and Charlie. Kristens
crypto map is also configured both to initiate IP address
assignment to remote peers (James) and to respond to
requests for IP address assignment (Charlie).
I want to request an address,
and have Kristen respond with
an IP address for me to use for
my tunnel endpoint.
I want to allow Kristen to assign
me an IP address to use for my
IPSec tunnel endpoint.
Kristen uses x-Auth to authenticate
Charlies user information against
AAA/TACACS
+
server.
Kristen uses x-Auth to authenticate
Jamess user information against
AAA/TACACS
+
server.
From the Library of Ahmed Aden
ptg12115235
IKE and ISAKMP 99
X-Auth is not a replacement for IKE Phase Is existing authentication capabilities. Instead,
x-Auth occurs in addition to IKE Phase I negotiation and occurs after IKE authenticates
the crypto endpoint.
As such, to use x-Auth, administrators must congure native Phase I authentication schemes and
x-Auth parameters. Example 2-18 shows IPsec RAVPN congurations on an IOS-based VPN
concentrator congured for x-Auth and authentication, authoring, and accounting (AAA) (as
displayed in Figure 2-29).
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
congured 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 congured
to serve her remote clients with an address from the pool RAVPN-pool, and assign them a
domain name of cisco.com.
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.
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.
TIP In the conguration in Example 2-18, Kristen will attempt to authenticate any remote
client that attempts to connect to her. An ACL can be congured 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 dene a trafc set to protect trafc
(protects all trafc from concentrator to client). An access list can be added to the dynamic
crypto map to provide further granularity in the protected trafc set denition.
From the Library of Ahmed Aden
ptg12115235
100 Chapter 2: IPsec Fundamentals
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 weve 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 weve discussed earlier in this chapter, IPsec relies on many fundamental cryptographic
operations to provide authenticity, integrity, condentiality, 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 receivers message digest
compares to the senders message digest, then the messages integrity has not been compromised.
In this operation, data authenticity, sender nonrepudiation, or condentiality 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
From the Library of Ahmed Aden
ptg12115235
Summary 101
that Digital Signatures therefore do not provide data condentiality 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 exibility 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 condentiality.
At this point, weve discussed the mechanics of IPsec with and without IKE. Because IPsec
ciphers require a symmetric key for bulk data encryption, keys must be dened 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: Denes the opposite end of the IPsec tunnel.
Trafc 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: Denes the MTU for the path along the IPsec SA.
From the Library of Ahmed Aden
ptg12115235
102 Chapter 2: IPsec Fundamentals
Security Parameter Index (SPI): The SPI is a unique identier 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 species two protocols for data transformation: ESP, IP Protocol 50 or AH IP Protocol 51.
ESP provides data condentiality, 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 weve discussed thus far, IPsec must use symmetric key transforms for bulk data ciphering.
This requires that the symmetric key must be manually dened 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 rst establishing an
authenticated, secure channel across the untrusted medium using either one of three authentication
methods:
PSKs: Keys used to negotiate are manually dened 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 Certicate 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 Dife-Hellman over the
Phase I SA to derive joint symmetric keys to use when ciphering data with their agreed-upon
symmetric key transforms.
From the Library of Ahmed Aden
ptg12115235
Summary 103
In this chapter, we use cryptographic building blocks to lay the foundation for building an
understanding of IPsec and IKE mechanics. Weve 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.
From the Library of Ahmed Aden
ptg12115235
From the Library of Ahmed Aden
ptg12115235
C H A P T E R
3
Basic IPsec VPN Topologies and
Congurations
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 conguring a
crypto endpoint for basic IPsec operations. Though effective IPsec VPN design drives the
complexity of conguration 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.
Each of the following deployments requires the conguration of IPsec in a point-to-point
fashion in one way or another. As such, all of the topologies discussed share common
conguration tasks to establish the IPsec tunnel:
Step 1 Decide how strong the IPsec transform must be and what mode the tunnel must
use (dene 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 conguration:
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.
Dife-Hellman Key Modulus (Group #)
Hash used for IKE authentication
Encryption method used for IKE channel
From the Library of Ahmed Aden
ptg12115235
106 Chapter 3: Basic IPsec VPN Topologies and Configurations
Figure 3-1 High-Level Conguration Process for IPsec VPN
Do I need
DH keys to be
freshly derived
for IKE and
IPSec?
Select DH
modulus to use
when PFS
renegotiates
DH
Does VPN
require dynamic
session keys
using DH?
What type of
authentication
method is
required?
How strong
must the hash
be during IKE?
How strong
must encryption
of the IKE
channel be?
How long must
the DH session
keys be?
Define traffic to be included
in crypto path in ACL and
reference ACL in Crypto Map
Define IPSec peer, or
multiple peers if HA is
required
Reference IPSec Transform
Set in Crypto Map
Reference Crypto Map on
Appropriate VPN Interfaces
Configure Crypto Map
Properties
Configure Crypto Map to
use ISAKMP for dynamic
session keys.
Configure Static IPSec
Session Keys as part of
Crypto Map (IPSec-Manual)
Configure IPSec Transform
Set via process described
in Figure 2-20
RSA-Encryption
RSA-Signatures
Pre-Shared Keys
3DES (168-bit)
DES (56-bit)
AES (256-bit)
SHA-1 (160-bit)
MD-5 (128-bit)
Strongest
Stronger
Strongest
Stronger
Strong
Group2 (1024-bit)
Group1 (512-bit)
Group5 (1536-bit)
Group1
(512-bit)
Group2
(1024-bit)
Group5
(1536-bit)
Strongest
Stronger
Strong
Strong Stronger Strongest
Yes
Yes
No
No
From the Library of Ahmed Aden
ptg12115235
Site-to-Site IPsec VPN Deployments 107
Step 4 Identify and assign IPsec peer and any High-Availability requirements. (Create
crypto map.)
Step 5 Dene trafc sets to be encrypted (Crypto ACL Denition 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 benets 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, exibility, 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
conguration and verication 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 condential 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.
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 specic case, there is no benet to
conguring 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 conguration 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.
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 59.
From the Library of Ahmed Aden
ptg12115235
108 Chapter 3: Basic IPsec VPN Topologies and Configurations
Figure 3-2 Site-to-Site IPsec VPN Topology Using Dedicated T-1 Circuits for Communications
Cisco IOS Site-to-Site IPsec VPN Conguration
The congurations 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 condential.
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 certication authority (CA), and the administrators want to use hardware
acceleration, which rules out the RSA-encrypted nonces method of authentication. So pre-
shared 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.
E
S
P
ESP
E
S
P
Loopback 1
201.1.1.1/32
AS1-7304A
AS #2
Loopback 1
202.1.1.1/32
AS2-3745A
AS #3
Loopback 1
203.1.1.1/32
AS3-3745A
AS #1
DS-3
200.1.1.0/30
DS-3
200.1.1.8/30
DS-3
200.1.1.4/30
GRE Encapsulated Tunnels
From the Library of Ahmed Aden
ptg12115235
Site-to-Site IPsec VPN Deployments 109
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).
Example 3-1 provides a conguration for the AS1-7301A in Figure 3-2. This routers
conguration 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
trafc from AS1 to AS2, as dened in Crypto ACL 101. AS1VPN, process 20, protects trafc from
AS1 to AS3 (Example 3-1, line 14), as dened in Crypto ACL 102 (Example 3-1, line 15).
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
organizations performance and security requirements before building IPsec VPN
congurations.
Example 3-1 Site-to-Site VPN Conguration on AS1-7301A
AS1-7304A#sss shhh hooo owww w rrr ruuu unnn nnnn niii innn nggg g--- -ccc cooo onnn nfff fiii iggg g
!
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
From the Library of Ahmed Aden
ptg12115235
110 Chapter 3: Basic IPsec VPN Topologies and Configurations
Example 3-2 provides the conguration 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 trafc ows to
AS1 and AS3. AS2VPN 10 protects trafc to AS1 (endpoint 200.1.1.1), and references ACL101
for crypto-protected trafc and IPsec transform ivdf3-1. AS2VPN 20 protects trafc to AS3
(endpoint 200.1.1.6), and references ACL102 for crypto-protected trafc and IPsec transform
ivdf3-1. AS2-3745 uses a relatively strong transform, AES cipher with SHA1 HMAC
authentication. PFS is also congured to refresh the symmetric transform key each time an IPsec
SA is negotiated.
Example 3-3 provides the conguration 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 trafc ows to AS1 and AS3. AS3VPN 10 protects trafc to AS1 (endpoint 200.1.1.9), and
references ACL101 for crypto-protected trafc and IPsec transform ivdf3-1. AS3VPN 20
protects trafc to AS3 (endpoint 200.1.1.5), and references ACL102 for crypto-protected trafc
and IPsec transform ivdf3-1. AS2-3745 uses a relatively strong transform, AES cipher with
SHA1 HMAC authentication. PFS is also congured to refresh the symmetric transform key each
time an IPsec SA is negotiated.
Example 3-2 Site-to-Site VPN Conguration on AS2-3745A
AS2-3745A#sss shhh hooo owww w rrr ruuu unnn nnnn niii innn nggg g--- -ccc cooo onnn nfff fiii iggg g
!
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
From the Library of Ahmed Aden
ptg12115235
Site-to-Site IPsec VPN Deployments 111
Verifying Cisco IOS Site-to-Site IPsec VPN Operation
Now that we have congured 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
trafc is being encrypted and decrypted.
Step 5 Check physical interface statistics for errors.
Examples 3-4 through 3-7 provide examples of these verication tasks on AS1-7304A in Figure 3-2.
First, we verify that an ISAKMP SA has been successfully established. Example 3-4 conrms 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.
Example 3-3 Site-to-Site VPN Conguration on AS3-3745A
AS3-3745A#sss shhh hooo owww w rrr ruuu unnn n
!
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
From the Library of Ahmed Aden
ptg12115235
112 Chapter 3: Basic IPsec VPN Topologies and Configurations
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-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 Dife-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.
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 rst exchange in
Aggressive Mode, but the SA is not
authenticated.
AG_AUTH The peers have done the rst exchange in
Aggressive Mode, but the SA is not
authenticated.
Example 3-4 Verication of ISAKMP SAs for AS1-7304A
AS1-7304A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p sss saaa a
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
From the Library of Ahmed Aden
ptg12115235
Site-to-Site IPsec VPN Deployments 113
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 specied 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 elds for ESP, PCP, and Authentication
Header (AH)only the ESP elds are populated because there is no AH specied 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 elds for ESP, PCP, and AHonly the ESP elds are
populated as there is no AH specied 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 trafc is sent across the tunnel in Example 3-6.
Example 3-5 Verication of IPsec SAs for AS1-7304A
AS1-7304A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c sss saaa a
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
continues
From the Library of Ahmed Aden
ptg12115235
114 Chapter 3: Basic IPsec VPN Topologies and Configurations
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
Example 3-5 Verication of IPsec SAs for AS1-7304A (Continued)
From the Library of Ahmed Aden
ptg12115235
Site-to-Site IPsec VPN Deployments 115
In Example 3-6, we will attempt to send trafc 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 rst ICMP packet during IKE and IPsec
SA negotiation.
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:
Example 3-6 Verication of Connectivity along the Crypto Path
AS1-7304A#sss shhh hooo owww w aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0222 2
Extended IP access list 102
10 permit ip host 201.1.1.1 host 202.1.1.1
AS1-7304A#sss shhh hooo owww w aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0333 3
Extended IP access list 103
10 permit ip host 201.1.1.1 host 203.1.1.1
AS1-7304A#ppp piii innn nggg g
Protocol [ip]:
Target IP address: 222 2000 0222 2... .111 1... .111 1... .111 1
continues
Example 3-5 Verication of IPsec SAs for AS1-7304A (Continued)
From the Library of Ahmed Aden
ptg12115235
116 Chapter 3: Basic IPsec VPN Topologies and Configurations
After we have successfully sent trafc 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
Repeat count [5]: 111 1000 0000 0
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yyy y
Source address or interface: 222 2000 0111 1... .111 1... .111 1... .111 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#ppp piii innn nggg g
Protocol [ip]:
Target IP address: 222 2000 0333 3... .111 1... .111 1... .111 1
Repeat count [5]: 111 1000 0000 0
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: yyy y
Source address or interface: 222 2000 0111 1... .111 1... .111 1... .111 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
Example 3-6 Verication of Connectivity along the Crypto Path (Continued)
From the Library of Ahmed Aden
ptg12115235
Site-to-Site IPsec VPN Deployments 117
ones previously displayed in Example 3-4). Because IPsec SAs are unidirectional, we conrm that
there are 4 SAs present in AS1-7304As 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 conrm 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 conrmed for the two
SAs built between AS1-7304A and AS3-3745A (Example 3-7, SA ID #2002 and #2003).
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 trafc in the crypto switching path.
Multicast trafc, 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 trafc associated with the routing protocol updates
Example 3-7 Crypto Engine Verication
AS1-7304A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn nsss s aaa accc cttt tiii ivvv veee e
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
From the Library of Ahmed Aden
ptg12115235
118 Chapter 3: Basic IPsec VPN Topologies and Configurations
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 ofces
over an independently maintained routed domain, such as the Internet. The smaller branch
ofces consist of a number of routed nodes and, as such, would benet 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 ofces from exchanging RP updates with the campus network at the
corporate HQ.
Due to IPsecs inability to natively encrypt multicast trafc, 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 implemen-
tation. RP trafc 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 nancial 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 nancial organization. This must be done securely and with condentiality. The insertion
of an independently maintained routed domain between the corporate extranet partner and the
global nancial organization breaks the multicast tree between the two parties, as illustrated in
Figure 3-4.
From the Library of Ahmed Aden
ptg12115235
Site-to-Site IPsec VPN Deployments 119
Figure 3-3 IPsec RAVPN Extension to Small Home Ofce over the Internet
B1-3745A
Loopback 1
202.1.1.1/32
B2-3745A
Loopback 1
203.1.1.1/32
T-1 Recovery from ISDN Failover
IPSec VPNs
Routing Protocol Update
DS-3
200.1.1.0/30
ISDN-PRI
199.1.1.0/24
ISDN-BRI
199.1.1.4/30
ISDN-BRI
199.1.1.8/30
Si
Corporate HQ
201.3.1.0/30
Si
HQ Campus Net
201.4.0.0/16
Branch1 Net
201.4.129.0/28
Branch2 Net
201.4.129.128/28
Branch-1 Branch-2
T-1
200.1.1.4/30
T-1
200.1.1.8/30
1
1
2 2
201.3.1.4/30
ISP
Loopback 1
201.2.2.2/32
HQ-3745AS
Loopback 1
201.1.1.1/32
HQ-7304A
3
From the Library of Ahmed Aden
ptg12115235
120 Chapter 3: Basic IPsec VPN Topologies and Configurations
Figure 3-4 Corporate Extranet Connection Using Internet Uplinks and IPsec VPNs
The extranet model breaks multicast in two areas. First, underlying media is not congured 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 ow in ciphered format.
Again, the addition of GRE to the corporate extranet would allow extension of PIM trafc 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
Multicast
Reciever A
201.4.1.1/24
Campus Net:
201.40.0.0/16
Multicast
Reciever B
201.4.2.1/24
IPTV Server
(224.0.0.2)
199.1.1.200
Tibco Server
(224.0.0.1)
199.1.1.100
ISP
Extranet Partner
199.1.1.0/24
Extranet crypto
engine does not
process PIM updates
or multicast traffic
sent in cleartext
Extranet partners
crypto engine does
not encrypt multicast
feeds to campus net.
Multicast Traffic from Quote Server and IPTV Server
PIM Messages (Join, Prune, etc.)
Campus Extranet Extranet Partner
From the Library of Ahmed Aden
ptg12115235
Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE) 121
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 todays IP
communications. Indeed, many of todays voice and video applications require point-to-
multipoint connectivity. As such, they leverage IP multicast techniques to selectively ood data to
interested parties. Traditionally, IP multicast trafc 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
trafc in cipher-text is IPsec+GRE.
Site-to-Site IPsec+GRE Architectural Overview
The IPsec+GRE model is used most commonly when there are trafc types that require
condentiality which are not traditionally suited for IPsec point-to-point trafc. 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 trafc 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)
Although IPsec+GRE does provide a wider scope of condentiality when applying the
ESP encapsulation, and enables condentiality for additional IP applications, increased
maximum transmission unit (MTU) sizes of encapsulated packets become an increased design
concern.
Outer
IP Header
ESP
Header
ESP
Trailer
ESP
Auth.
TCP
Header
GRE
Header
Original Multicast
IP Header
Data
Encrypted
Unprotected Unprotected
Authenticated
From the Library of Ahmed Aden
ptg12115235
122 Chapter 3: Basic IPsec VPN Topologies and Configurations
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 elds, 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.
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 ubiquied 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 classied prior to encapsulation. Cisco IOS supports IPsec QoS pre-classify
functionality on IOS VPN endpoints to assure that ow 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)
conicts 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 conict
with anti-replay functions native to IPsec.
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.
From the Library of Ahmed Aden
ptg12115235
Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE) 123
Site-to-Site IPsec+GRE Sample Congurations
Thus far, we have introduced the requirement of unicast presentation of data ows to the IPsec
crypto engine. In this section, we will discuss working IPsec+GRE conguration procedures,
examples, and verication techniques to use when encapsulating multicast trafc with a unicast
header so that it can be processed with encrypted with IPsec.
Cisco IOS Site-to-Site IPsec+GRE Conguration
We will now alter the congurations 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 congura-
tion elements, such as the PFS and peering congurations. However, other crypto map
conguration elements, such as the crypto ACLs, will change to accommodate GRE trafc. We
will also demonstrate IOS QoS for IPsec VPNs by conguring the routers to classify packets prior
to GRE encapsulation and crypto processing. The topology used for these congurations 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 conguration changes made to AS1-7304A to accommodate
IPsec+GRE. One of the most important differences in this conguration compared to Example 3-1
is the change in the crypto ACLs. Note that in Example 3-8, the crypto ACLs protect GRE trafc
from the GRE tunnel source and destination address from AS1-7304A to AS2-3745A and AS3-
3745A, respectively. This will effectively encrypt all trafc 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-7304As 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 congured 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 Conguration on AS1-7301A
AS1-7304A#sss shhh hooo owww w rrr ruuu unnn n
!
crypto df-bit set
!
crypto ipsec fragmentation before-encryption
!
continues
From the Library of Ahmed Aden
ptg12115235
124 Chapter 3: Basic IPsec VPN Topologies and Configurations
Example 3-9 provides the IPsec+GRE conguration for the IPsec VPN gateway for AS2. Like
AS1-7304A, AS2-3745A is congured 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 congured to prevent fragmentation after encryption and to classify packets with
QoS prior to 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 Site-to-Site VPN Conguration on AS2-3745A
AS2-3745A#sss shhh hooo owww w rrr ruuu unnn n
!
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
Example 3-8 Site-to-Site VPN Conguration on AS1-7301A (Continued)
From the Library of Ahmed Aden
ptg12115235
Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE) 125
Example 3-10 provides the IPsec+GRE conguration for the IPsec VPN gateway for AS3. Like
AS1-7304A, AS3-3745A is congured 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 congured to prevent fragmentation after encryption and to classify packets with
QoS prior to encryption.
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 Site-to-Site VPN Conguration on AS3-3745A
AS3-3745A#sss shhh hooo owww w rrr ruuu unnn n
!
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
!
Example 3-9 Site-to-Site VPN Conguration on AS2-3745A (Continued)
From the Library of Ahmed Aden
ptg12115235
126 Chapter 3: Basic IPsec VPN Topologies and Configurations
Verication of IPsec+GRE Tunnel Establishment
Verifying an IPsec+GRE tunnel begins with the same steps that are taken in the verication
of a standard IPsec tunnel. Verication 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:
Verication of tunnel establishment
Verication of RP (including PIM) adjacencies through the tunnel
Once these basic tunneling operations have been veried, they must be re-veried after the addition
of IPsec. In addition to that re-verication, the administrator should also verify the establishment
of ISAKMP SA, IPsec SA, and that trafc 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 verication steps on AS1-7304A (prior to the addition of the crypto map to the physical
interface) and the verication of the full IPsec+GRE tunnel (after the crypto map has been applied
to the physical interface). Again, note that all EIGRP trafc is kept condential from the OSPF
core via IPsec processing of all GRE trafc (which in this case includes all EIGRP trafc
192.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 Verication of GRE Tunnels and Tunneled Routing Protocols on AS1-7304A
AS1-7304A#sss shhh hooo owww w iii ippp p iii innn nttt t bbb brrr riii ieee efff f
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#ppp piii innn nggg g 111 1999 9222 2... .111 1666 6888 8... .111 1222 2... .222 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
From the Library of Ahmed Aden
ptg12115235
Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE) 127
After we have veried 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 trafc will traverse. The diagnostic output in Exam-
ple 3-12 veries that protected trafc (in this case all GRE trafc) is being processed by the
crypto engine. This output reects 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 trafc including
RP updates and adjacency maintenance.
AS1-7304A#ppp piii innn nggg g 111 1999 9222 2... .111 1666 6888 8... .111 1333 3... .222 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#sss shhh hooo owww w iii ippp p eee eiii iggg grrr rppp p iii innn nttt teee errr rfff faaa accc ceee esss s
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#sss shhh h iii ippp p eee eiii iggg grrr rppp p nnn neee eiii iggg ghhh hbbb booo orrr rsss s
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
Example 3-12 Verication of Crypto-Processed Trafc after Crypto Maps Have Been Applied to Physical
Interfaces That Will Protect All GRE Trafc Between the Two GRE Tunnel Endpoints
AS1-7304A#sss shhh h ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn n aaa accc cttt tiii ivvv veee e
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
Example 3-11 Verication of GRE Tunnels and Tunneled Routing Protocols on AS1-7304A (Continued)
From the Library of Ahmed Aden
ptg12115235
128 Chapter 3: Basic IPsec VPN Topologies and Configurations
Hub-and-Spoke IPsec VPN Deployments
Most of todays 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 ScalabilityThe 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 CapacityIn addition to the number of SAs that the endpoints 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 CapacityThe throughput, in packets per second (pps), of the
trafc that is processed in the routers 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 CapacityAlthough 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 hubs CPU.
Fragmentation CapabilitiesBecause 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 specied
appropriately so as to handle potentially large amounts of fragmented packets sent from
adjacent spoke IPsec peer endpoints.
TIP It is recommended that the administrator re-verify the steps taken in Example 3-11
to conrm 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.
From the Library of Ahmed Aden
ptg12115235
Hub-and-Spoke IPsec VPN Deployments 129
Additionally, the urgency for HA at the hub router increases dramatically as additional spokes are
reliant on the hub for connectivity to the enterprises centrally located resources.
Hub-and-Spoke Architectural Overview
In this section, we will explore three common layouts for hub-and-spoke IPsec VPNs. The hub-
and-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 todays hub-and-spoke IPsec VPN designs.
Figure 3-6 Hub-and-Spoke IPsec VPN Variations
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 rst 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
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.
Cluster C
Cluster B
Hub A Hub B Hub C
Cluster A
Cluster C
Cluster B
Hub A Hub B Hub C
Cluster A
Hub and Spoke Design #3:
Redunant Spokes Clustered to Redundant
Hubs
Hub and Spoke Design #2:
Clustered Design to Redundant Hubs
Hub and Spoke Design #1:
Standard Hub and Spoke Design, No
High-Availability
From the Library of Ahmed Aden
ptg12115235
130 Chapter 3: Basic IPsec VPN Topologies and Configurations
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 ScalabilityThe 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 AggregationThe 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 TrafcFor spoke-spoke
connectivity, the hub router will be decrypting trafc 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 trafc, the hub router that has enough processing power to support
substantial amounts of decrypt/re-encrypt behavior must be selected.
Multicast FanoutIn this design, the hub router is performing the multicast fanout for trafc
to all of the spoke routers that are subscribed to the multicast group. For trafc proles that
have substantial amounts of multicast trafc, 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 rst 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 CapacityUsing 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
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.
From the Library of Ahmed Aden
ptg12115235
Hub-and-Spoke IPsec VPN Deployments 131
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 CapacityDistributed 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 RedundancyIn 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 spokes 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 610. 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 trafc from the spoke is load-balanced across the two redundant spoke routers. These
benets, 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 610 for design concepts surrounding IPsec HA
in IOS).
Because of this, the primary benet 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-benet 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.
From the Library of Ahmed Aden
ptg12115235
132 Chapter 3: Basic IPsec VPN Topologies and Configurations
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. Weve 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.
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 predened 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 avors, hardware-based clients and software-based
clients. Software-based VPN clients run locally on the users 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 users laptop, a software-based VPN client can securely extend
condential 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.
Specically, software-based VPN clients terminate VPN connectivity locally on teleworkers
NOTE Cisco Systems Business Ready Teleworker Solutions fully outlines the business
justication 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
From the Library of Ahmed Aden
ptg12115235
Remote Access VPN Deployments 133
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 ows. 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
ofces 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 ofce or branch. Therefore, hardware-
based VPN components add a networked element to the SOHO (small ofce, home ofce) 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 xed 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 chapters RAVPN discussion on.
Standalone VPN Concentrator Designs
Due to the nature of IPsec and rewalls, 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.
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
trafc from the VPN concentrator is rewalled from the rewalls DMZ interface to its inside
interface.
From the Library of Ahmed Aden
ptg12115235
134 Chapter 3: Basic IPsec VPN Topologies and Configurations
Figure 3-7 VPN Concentrator Placement in Single-DMZ Design
Also, the rewall 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 trafc types all the way up to Layer 7.
The processing of trafc 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-specic modications that
need to be added to the rewall ACL conguration. Likewise, there are no additional Network
Address Translation (NAT) considerations to account for on the rewall. This design does,
however, require marginally increased ltering capability on the rewall, as cleartext trafc from
the IPsec VPN concentrator is now being processed on the DMZ interface on its way to the inside
network.
VPN Concentrator and Firewall in Parallel
Placing the VPN concentrator in parallel with the rewall eliminates the possibility of human error
when opening up holes in the rewall ACL to allow IPsec trafc 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 rewall.
Service
Provider
Enterprise
Inside
DMZ 1
Outside
From the Library of Ahmed Aden
ptg12115235
Remote Access VPN Deployments 135
Figure 3-8 Parallel VPN Concentrator and Firewall DMZ Design
Additionally, this topology presents no computational overhead on the rewall for processing
IPsec trafc in to the VPN concentrator. Instead, that trafc is focused solely on the VPN
concentrator. Likewise, the concentrator is not burdened by non-VPN trafc, as would be the case
if the concentrator were placed in series with the rewall on the outside network.
The parallel conguration described in the design of Figure 3-8 also simplies the NAT
conguration on both the rewall and the DMZ. Although IPsec itself can accommodate environ-
ments where addresses are being translated, this topology eliminates the NAT processing of VPN
trafc rewall and concentrator. Therefore, for RAVPN IPsec tunnels, the need for vendor-specic
IPsec extensions such as NAT-T (IPsec NAT Transparency) is avoided.
VPN Concentrator with Dual DMZs to Firewall
Using two DMZ interfaces for inside and outside VPN trafc, 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
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.
Service
Provider
Enterprise
Inside
Outside
From the Library of Ahmed Aden
ptg12115235
136 Chapter 3: Basic IPsec VPN Topologies and Configurations
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 rewall, as opposed to the Internet gateway, to switch
packets to the appropriate directly connected interface. As a result, it would be the rewalls
responsibility to forward VPN trafc directly connected to DMZ1 interface and allowed NATd (if
necessary) enterprise trafc directly to the inside interface.
Figure 3-9 VPN Concentrator with Dual DMZs to Firewall
Locating the VPN concentrators outside interface behind the DMZ inserts a layer of ltering and
authentication of IPsec trafc 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 rewall must
be altered to allow ISAKMP, ESP, and AH trafc through to the concentrator. In addition to
punching holes through the ACL to accommodate VPN trafc, this design also increases the
computation overhead associated with VPN trafc on the rewall, because trafc is processed
twice (once on the outside interface, and again as trafc 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
DMZ 1
Service
Provider
Enterprise
Inside
DMZ 2
Outside
From the Library of Ahmed Aden
ptg12115235
Remote Access VPN Deployments 137
VPN trafc to be processed serially between the rewall 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, trafc 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 rewall conguration and increased processing overhead.
Figure 3-10 What to Avoid in DMZ/VPN Concentrator Topologies
Locating the VPN concentrator serially outside of the rewall (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 trafc be processed by the concentrator, as opposed to just the VPN
trafc, leading to increased overhead. While this alteration eliminates the need to NAT inbound
VPN trafc, it does place the concentrator in a relatively unsecured location, presenting the
opportunity for denial of service (DoS) attacks for all network trafc 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
Service
Provider
Enterprise
Inside
Location A
Location B
Outside
Moving concentrator inside
firewall decreases
effectiveness of firewall design
From the Library of Ahmed Aden
ptg12115235
138 Chapter 3: Basic IPsec VPN Topologies and Configurations
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
trafc 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
Service
Provider
Enterprise
Inside
DMZ 1
Outside
3x cluster triples
local concentrator
redundancy and
IPSec VPN tunnel
processing
capacity
From the Library of Ahmed Aden
ptg12115235
Summary 139
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 hub-
and-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 rewall DMZ design
Dual DMZ VPN concentrator design
Serial VPN concentrator placement on inside rewall interface
At this point, you should have a basic familiarity with VPN concentrator placement in a rewalled
DMZ design, as well as a basic understanding of the dangers of placing IPsec VPN concentrators
serially inside a rewalled 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.
From the Library of Ahmed Aden
ptg12115235
From the Library of Ahmed Aden
ptg12115235
C H A P T E R
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: conguration and
architecture. The IPsec VPN conguration issues we will explore in this chapter include:
IKE SA Proposal Mismatches
IKE Authentication Failures
IPsec SA Proposal Mismatches
Crypto ACL Mismatches
Unlike conguration issues, architectural issues do not require a misconguration 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 weve discussed, there
are detailed steps that occur during the formation of Internet Security Association and Key
From the Library of Ahmed Aden
ptg12115235
142 Chapter 4: Common IPsec VPN Issues
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 ow
show crypto engine qos
Common Conguration Issues with IPsec VPNs
There are many parameters and features to understand when deploying IPsec VPNs. In this
section, we will discuss conguration issues presented when one or more IPsec VPN gateways are
congured incorrectly. After discussing the nature of each of the above commonly experienced
IPsec VPN conguration issues, we will discuss the methods used to effectively diagnose and
remedy these issues.
IKE SA Proposal Mismatches
Unless IPsec session keys are manually dened, 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 trafc will continue to ow
unencrypted.
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 143
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 conguration 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 congured ISAKMP policies for a
match. If there are none, the initiator will propose the next highest ISAKMP policy and dene its
local conguration. 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
congurations 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
Example 4-1 provides the ISAKMP policies congured for Router_A in Figure 4-1. Note that, in
this conguration, there are no ISAKMP proposals congured that match those congured on
Router_B in Example 4-2.
Example 4-1 Crypto ISAKMP Policy Denition for Router_A in Figure 4-1 (Mismatch with Router_B,
Example 4-2)
Router_A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y
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
continues
Network_B
202.1.1.0/24
Network_A
201.1.1.0/24
Router_B Router_A
200.0.0.0/30 .1
.2
From the Library of Ahmed Aden
ptg12115235
144 Chapter 4: Common IPsec VPN Issues
Example 4-2 provides the ISAKMP policy conguration 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_Bs ISAKMP conguration contains no matching
proposals with Router_As conguration provided in Example 4-1, ISAKMP negotiation will fail.
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 Crypto ISAKMP Policy Denition for Router_B in Figure 4-1 (Mismatch with Router_B,
Example 4-1)
Router_B#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y
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
Example 4-1 Crypto ISAKMP Policy Denition for Router_A in Figure 4-1 (Mismatch with Router_B,
Example 4-2) (Continued)
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 145
The following numbered sequence of events describes the ISAKMP proposal mismatch between
the congurations 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 congured ISAKMP policies 10, 20, and 30 to Router B.
2. Router B checks policy 10 obtained in step 1 against its own congured policies, beginning
with the lowest numbered policy and ending with the highest.
3. If Router B does not nd a match in step 2, it checks policy 20 obtained in step 1 against its
own congured policies, starting with the lowest numbered and ending with the highest.
4. If Router B does not nd a match in step 3, it checks policy 30 obtained in step 1 against its
own congured policies, starting with the lowest numbered and ending with the highest.
5. If Router B does not nd a match in step 4, then a proposal mismatch has occurred, and the
Phase 1 negotiation times out.
In order to conrm 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
congured 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 congured 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 congured 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 specic 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 congured ISAKMP policies. Example 4-3, line 12, conrms that a
proposal mismatch has occurred. Router_B nds that no ISAKMP proposals sent from Router_A
match its own congured ISAKMP policies and therefore deletes the Phase1 SA and Phase1
negotiation times out on Router_A, as conrmed in Example 4-3, line 18.
Example 4-3 Isolating IKE Proposal Mismatches on the Initiating VPN Endpoint (Router A)
1 Router_B#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p
2 Crypto ISAKMP debugging is on
3 !
continues
From the Library of Ahmed Aden
ptg12115235
146 Chapter 4: Common IPsec VPN Issues
Until the two endpoints can agree on an ISAKMP policy to use when securing the IKE channel
and negotiating a Dife-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 congured on the two endpoints. Second, the
endpoints must be congured to share these keys with the correct peer. Router_A and Router_B
are now congured 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.
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)
Example 4-3 Isolating IKE Proposal Mismatches on the Initiating VPN Endpoint (Router A) (Continued)
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 147
Figure 4-2 Troubleshooting IKE PSK Authentication
Example 4-4 provides the conguration of Router_A in Figure 4-2. Note that, unlike Router_As
conguration in Figure 4-1, Router_A is now congured 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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y
2
3 Global IKE policy
4 #<--ISAKMP Policy 10 Matches Router_Bs 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)
continues
Network_A
202.1.1.0/24
Network_B
202.2.2.0/24
Router_A Router_B
200.0.0.0/30 .1
.2
Loopback 1 = 201.0.0.1/32
IKE PSK = Tarheels
Loopback 1 = 201.0.0.2/32
IKE PSK = Bluedevils
Router_A, ISAKMP Policy 30 =
Router_B, ISAKMP Policy 10
IKE Preshared Keys are mismatched and shared with
incorrect peers (Router_ A sources session from 201.1.1.1)
From the Library of Ahmed Aden
ptg12115235
148 Chapter 4: Common IPsec VPN Issues
Example 4-5 provides the conguration of Router_B in Figure 4-2. Note that Router_Bs
ISAKMP proposal listed with priority 10 (Example 4-4, lines 5-10) will match Router_As
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).
28 lifetime: 86400 seconds, no volume limit
29 Router_A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y
30 Keyring Hostname/Address PSK
31
32 default 200.0.0.2 tarheels
Example 4-5 Mismatched IKE PSK on Router_B (Corresponds with Mismatched Key for Router_A in
Example 4-4)
1 Router_B#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y
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_As 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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y
30 Keyring Hostname/Address PSK
31
32 default 200.0.0.1 bluedevils
Example 4-4 Mismatched IKE PSK on Router_A (Corresponds with Mismatched Key for Router_B in
Example 4-5) (Continued)
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 149
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, conrms that the two
crypto peers have agreed on an IKE proposal. However, Example 4-6, line 18, conrms that the
SA fails negotiation due to a PSK mismatch.
Mismatched Peer Addresses in IKE PSK Denition
As we have discussed, there are two elements to troubleshoot in a PSK authentication scheme.
Thus far, weve covered IKE failure due to PSK mismatches. Now, lets turn our attention to IKE
issues surrounding peering specication 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 routers default settings by instructing the router to use a loopback
interface for sourcing the IPsec VPN tunnel.
Example 4-6 PSK Authentication Failure Between Two IKE Endpoints
1 Router_A#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p
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
Example 4-7 Router_A Sources IPsec VPNs from Its Loopback1 Interface (201.0.0.1)
!
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p RRR Rooo ouuu uttt teee errr r___ _AAA A___ _MMM Maaa appp p lll looo occc caaa alll l--- -aaa addd dddd drrr reee esss ssss s LLL Looo oooo oppp pbbb baaa accc ckkk k111 1
!
iii innn nttt teee errr rfff faaa accc ceee e LLL Looo oooo oppp pbbb baaa accc ckkk k111 1
iii ippp p aaa addd dddd drrr reee esss ssss s 222 2000 0111 1... .000 0... .000 0... .111 1 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5
From the Library of Ahmed Aden
ptg12115235
150 Chapter 4: Common IPsec VPN Issues
The administrators of Router_B must make two basic changes to accommodate this change on
Router_A. They must rst change their IPsec peering denition in their crypto map to point to
Router_As new source (its loopback address, 201.0.0.1). This change is illustrated in the
conguration fragment provided in Example 4-8.
Assume, though, that the administrators of Router_B did not correctly modify the peer address on
their PSK statement to accurately reect 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 conrm 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 conrms this error, as
IKE cannot nd a matching key to use with the new IPsec peer statement in the crypto map
(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 x the problem. Additionally, all of the ISAKMP address
information on PSK denitions 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,
Example 4-8 Necessary Peering Changes Required on Router_B
!
ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y ttt taaa arrr rhhh heee eeee elll lsss s aaa addd dddd drrr reee esss ssss s 222 2000 0111 1... .000 0... .000 0... .111 1
!
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p RRR Rooo ouuu uttt teee errr r___ _BBB B___ _MMM Maaa appp p 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
sss seee ettt t ppp peee eeee errr r 222 2000 0111 1... .000 0... .000 0... .111 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!
!
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 151
conrms that the two crypto peers have agreed on an ISAKMP proposal, and Example 4-10 line
22 conrms that the SA has been authenticated. Once Phase 1 negotiation is complete, the
ISAKMP SA can be veried without debugging, using show commands, as illustrated in Example
4-10, lines 2325.
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.
Example 4-10 Successful IKE Authentication Using PSKs (Router_B)
1 Router_B#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p
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
From the Library of Ahmed Aden
ptg12115235
152 Chapter 4: Common IPsec VPN Issues
Figure 4-3 IKE Authentication FailureMismatched RSA Public Keys
Example 4-11 provides the RSA key conguration 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_As private key is manually generated, and
is listed in Example 4-11, lines 3-9. The administrator of Router_A has manually entered
Router_Bs encryption key, as listed in Example 4-11, lines 20-29.
Example 4-11 Router_As (Figure 4-3) RSA Key Conguration for IKE SA Establishment with Router_B
1 Router_A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y mmm myyy yppp puuu ubbb bkkk keee eyyy y rrr rsss saaa a
2 % Key pair was generated at: 8:56:03 UTC Feb 17 2005
3 <-- Router_As 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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y ppp puuu ubbb bkkk keee eyyy y--- -ccc chhh haaa aiii innn n rrr rsss saaa a aaa addd dddd d 222 2000 0000 0... .000 0... .000 0... .222 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
Network_A
202.1.1.0/24
Network_B
202.2.2.0/24
Router_A Router_B
200.0.0.0/30 .1
.2
Loopback 1 = 201.0.0.1/32 Loopback 1 = 201.0.0.2/32
Router_B has been mistakenly configured with Router_As
private/encryption key, leading to an IKE authentication failure.
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 153
Example 4-12 provides the RSA key conguration of Router_B in Figure 4-3. Note that Router B
has mistakenly been congured with Router_As private key, rather than its public key.
Example 4-13, line 5, conrms 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_As decryption key for encrypting
IKE messages to Router_A, rather than using Router_As proper encryption key to do so.
Example 4-13, lines 19-40, illustrate that the same key misconguration 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-12 Router_Bs (Figure 4-3) RSA Key Conguration for IKE SA Establishment with Router_A
1 Router_B#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y mmm myyy yppp puuu ubbb bkkk keee eyyy y rrr rsss saaa a
2 % Key pair was generated at: 08:59:17 UTC Feb 17 2005
3 <-- Router_Bs 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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y ppp puuu ubbb bkkk keee eyyy y--- -ccc chhh haaa aiii innn n rrr rsss saaa a aaa addd dddd drrr reee esss ssss s 222 2000 0000 0... .000 0... .000 0... .111 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
From the Library of Ahmed Aden
ptg12115235
154 Chapter 4: Common IPsec VPN Issues
Example 4-13 Troubleshooting IKE Authentication Failures with RSA Encryption
1 Router_A#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p
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#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p
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
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 155
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 xed the mismatching key problem in
Example 4-11 through Example 4-13, and have updated their IPsec conguration to peer with
Router_As loopback address. However, they have not updated the address that ISAKMP should
use when authenticating the IKE channel with Router_Bs public/encryption key (see
congurations 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
Example 4-14 provides the RSA key conguration 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
Conguration Provided in Example 4-15)
1 Router_A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y mmm myyy yppp puuu ubbb bkkk keee eyyy y rrr rsss saaa a
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y ppp puuu ubbb bkkk keee eyyy y--- -ccc chhh haaa aiii innn n rrr rsss saaa a aaa addd dddd drrr reee esss ssss s 222 2000 0000 0... .000 0... .000 0... .222 2
21 Key address: 200.0.0.2
continues
Network_A
202.1.1.0/24
Network_B
202.2.2.0/24
Router_A Router_B
200.0.0.0/30 .1
.2
Loopback 1 = 201.0.0.1 Loopback 1 = 201.0.0. 2
Router_B has not been configured to use Router_As
decryption key with the correct address, which is now
its loopback 1 interface (201.0.0.1)
From the Library of Ahmed Aden
ptg12115235
156 Chapter 4: Common IPsec VPN Issues
Example 4-15 provides the RSA key conguration for Router_B in Figure 4-4. Note that, although
the public and private keys have been correctly congured on Router_A and Router_B, Router_B
is not congured 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.
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 Router_B RSA Encryption Key Peer Mismatch with Router_A in Figure 4-4 (Router_A
Conguration Provided in Example 4-14)
1 Router_B#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y mmm myyy yppp puuu ubbb bkkk keee eyyy y rrr rsss saaa a
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y ppp puuu ubbb bkkk keee eyyy y--- -ccc chhh haaa aiii innn n rrr rsss saaa a aaa addd dddd drrr reee esss ssss s 222 2000 0000 0... .000 0... .000 0... .111 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
Example 4-14 Router_A RSA Encryption Key Peer Mismatch with Router_B in Figure 4-4 (Router_B
Conguration Provided in Example 4-15) (Continued)
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 157
Once the conguration on Router_B (Example 4-15, lines 22-23) has been updated to use
Router_As public key with Router_As new peering information (lo1=201.0.0.1), then the ISAKMP
SA can be negotiated successfully using RSA Encryption as conrmed in Example 4-16.
Last, it is important to note that the congurations 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 conguration. Additionally, each peer using
a hostname for ISAKMP identication must be instructed to do so using the crypto isakmp
Example 4-16 Updated Peer Conguration on Router_B, and ISAKMP SA Conrmation
1 Router_B#sss shhh h rrr ruuu unnn n
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#ppp piii innn nggg g
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p sss saaa a
21 dst src state conn-id slot
22 201.0.0.1 200.1.1.2 QM_IDLE 1 0
23 Router_B#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y ppp puuu ubbb bkkk keee eyyy y--- -ccc chhh haaa aiii innn n rrr rsss saaa a
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.
From the Library of Ahmed Aden
ptg12115235
158 Chapter 4: Common IPsec VPN Issues
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 well discuss later in Chapter 11, the dynamics of authentication change dramatically when
RSA signatures are used. Until now, weve 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 Certicate 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 Certicate
Enrolling with the CA and Obtaining Public Key Certicates
We will examine debugs and diagnostics for each of these processes using the topology in
Figure 4-5, as Routers A and B obtain certicates from IOS_CAROOT needed for IKE
authentication using RSA Signatures. It has been conrmed that Router_A and Router_B can
reach the CA.
Figure 4-5 Troubleshooting IKE Authentication Errors with RSA Signatures
Example 4-17 provides the conguration for Router_A in Figure 4-5. We will use this
conguration while troubleshooting and validating IKE SA authentication with RSA Signatures
later in this chapter.
.1 .2
Loopback 1 = 202.0.0.1
Loopback 192 = 192.168.1.1/24
Loopback 1 = 202.0.0.2
Loopback 192 = 192.168.2.1/24
Loopback 1 = 202.0.0.3
DWDM Ring = 200.0.0.0/24
.3
IOS_CAROOT
202.1.3.2/24
Network_A
202.1.1.0/24
Network_B
202.2.2.0/24
Network_C
202.1.3.0/24
Router_C
Router_A Router_B
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 159
Example 4-17 RSA Signatures Conguration on Router_A (Figure 4-5)
Router_A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o ccc caaa a ccc ceee errr rttt tiii ifff fiii iccc caaa attt teee esss s
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y mmm myyy yppp puuu ubbb bkkk keee eyyy y rrr rsss saaa a
% 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:
continues
From the Library of Ahmed Aden
ptg12115235
160 Chapter 4: Common IPsec VPN Issues
Example 4-18 provides the conguration for Router_B in Figure 4-5. We will use this
conguration while troubleshooting and validating IKE SA authentication with RSA Signatures
later in this chapter.
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y ppp puuu ubbb bkkk keee eyyy y--- -ccc chhh haaa aiii innn n rrr rsss saaa a
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 RSA Signatures Conguration on Router_B (Figure 4-5)
Router_B#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o ccc caaa a ccc ceee errr rttt tiii ifff fiii iccc caaa attt teee esss s
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
Example 4-17 RSA Signatures Conguration on Router_A (Figure 4-5) (Continued)
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 161
Authenticating the CA and Obtaining the CA Certicate
During the process of CA authentication on a Cisco IOS VPN endpoint, the administrator of the
VPN endpoint visually inspects the CA certicate ngerprint and manually accepts the
corresponding CA certicate. Aside from human error in the inspection and acceptance of the CA
ngerprint and certicate 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
CAs certicate has a lifetime associated with it. When a public-key infrastructure (PKI) endpoint
receives the CA certicate during the authentication process and has an incorrect clock setting, the
CA certicate could appear to be invalid. Consider Example 4-19 in which Router_B attempts to
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y mmm myyy yppp puuu ubbb bkkk keee eyyy y rrr rsss saaa a
% 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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o kkk keee eyyy y ppp puuu ubbb bkkk keee eyyy y--- -ccc chhh haaa aiii innn n rrr rsss saaa a
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
Example 4-18 RSA Signatures Conguration on Router_B (Figure 4-5) (Continued)
From the Library of Ahmed Aden
ptg12115235
162 Chapter 4: Common IPsec VPN Issues
enroll with the CA, RSA_CAROOT. Router_Bs clock is set incorrectly, which leads the router to
believe that the CA certicate is outside of the appropriate period of validity.
Once Router_Bs clock has been synchronized with the PKI (and subsequently the CAs),
Router_B can then authenticate the CA in the PKI by verifying the CA certicates thumbprint, as
illustrated in Example 4-20, lines 3-5. The debugging output from Example 4-20, lines 10 and 11,
veries that a CA certicate has been received by Router_B. We can further conrm that a CA
certicate 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-19 CA Authentication Failure Due to Inconsistent Clock Settings
Router_B#sss shhh h ccc clll looo occc ckkk k
09:55:30.262 UTC Wed Apr 26 2002
Router_B(config)#ccc crrr ryyy yppp pttt tooo o ppp pkkk kiii i aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt teee e III IOOO OSSS S___ _CCC CAAA ARRR ROOO OOOO OTTT T
% 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
Example 4-20 Authenticating and Obtaining the CA Certicate
1 Router_B(config)#ccc crrr ryyy yppp pttt tooo o ppp pkkk kiii i aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt teee e III IOOO OSSS S___ _CCC CAAA ARRR ROOO OOOO OTTT T
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#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o ppp pkkk kiii i sss seee errr rvvv veee errr r
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o ppp pkkk kiii i ccc ceee errr rttt tiii ifff fiii iccc caaa attt teee esss s
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
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 163
Now that we have veried that we have the CAs certicate, 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 CAs signing certicate 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 congured
on the CA. Consider the case below in which Router_A wants to enroll with IOS_CAROOT in
Figure 4-5. We can conrm 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.
The second task that must be accomplished in PKI enrollment is verication that the router has
indeed received the CAs certicate. Remember that, when enrolling in the PKI, the CA
administrator must grant the VPN endpoint its certicate 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 conrms that the CA has granted and sent its certicate to a requestor (Router_A). The
output provided in line 7 of Example 4-22 conrms that Router_A has indeed received its signed
certicate from the CA.
Example 4-21 Verifying That Enrollment Requests Are Received by the CA
IOS_CAROOT#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o ppp pkkk kiii i sss seee errr rvvv veee errr r
!
!
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
Example 4-22 Router_As Certicate Is Signed by the CA, Sent by the CA, and Received by Router_A
1 IOS_CAROOT#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o ppp pkkk kiii i sss seee errr rvvv veee errr r
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
From the Library of Ahmed Aden
ptg12115235
164 Chapter 4: Common IPsec VPN Issues
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 verication 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 certicates for validity after PKI authentication and enrollment, in
order to avoid IKE authentication errors with RSA signatures. Once certicates 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 conrm the
existence of signed certicates on both Router_A and Router_B, as illustrated in Example 4-23.
Example 4-23 Verifying the Existence of Certicates on IOS PKI VPN Endpoints
Router_A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o ccc caaa a ccc ceee errr rttt tiii ifff fiii iccc caaa attt teee esss s
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o ccc caaa a ccc ceee errr rttt tiii ifff fiii iccc caaa attt teee esss s
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
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 165
Finally, the certicates displayed above are used to authenticate the IKE channel during Phase1
negotiation. Diagnostic and debugging output from Example 4-24 conrms 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.
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, weve 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
specic to Phase 2 negotiation:
The IP addresses used for IPsec tunnel termination
Example 4-24 Verifying the Establishment of an ISAKMP SA Using RSA Signatures on Router_A
Router_A#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p
!
!
*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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p sss saaa a
dst src state conn-id slot
200.0.0.2 200.0.0.1 QM_IDLE 1 0
Router_A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn nsss s aaa accc cttt tiii ivvv veee e
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
From the Library of Ahmed Aden
ptg12115235
166 Chapter 4: Common IPsec VPN Issues
The symmetric IPsec transforms to use on crypto-protected trafc after an IPsec SA has been
negotiated
The scope of protected trafc in the crypto switching path
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.
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 conrm
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.
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.
Example 4-25 Inserting a Peering Error on Router_B
Router_B#ccc cooo onnn nfff f ttt t
Enter configuration commands, one per line. End with CNTL/Z.
Router_B(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ppp pkkk kiii i444 4 111 1000 0
Router_B(config-crypto-map)#sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .000 0... .000 0... .111 1000 0
Router_B(config-crypto-map)#eee ennn nddd d
Router_B#
Example 4-26 Identifying IPsec Proposal Mismatch Issues
Router_A#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c
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#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c
Router_B#
Feb 24 11:52:30.627: IPSEC(key_engine): got a queue event with 1 kei messages
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 167
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 recongure 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).
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
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#ccc cooo onnn nfff f ttt t
Enter configuration commands, one per line. End with CNTL/Z.
Router_B(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ppp pkkk kiii i444 4 111 1000 0
Router_B(config-crypto-map)#nnn nooo o sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .000 0... .000 0... .333 3
Router_B(config-crypto-map)#sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .000 0... .000 0... .111 1
Router_B(config-crypto-map)#eee exxx xiii ittt t
Router_B(config)#ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ppp pkkk kiii i444 4 eee esss sppp p--- -aaa aeee esss s eee esss sppp p--- -mmm mddd d555 5--- -hhh hmmm maaa accc c
Router_B(cfg-crypto-trans)#eee ennn nddd d
Router_B#
Example 4-26 Identifying IPsec Proposal Mismatch Issues (Continued)
From the Library of Ahmed Aden
ptg12115235
168 Chapter 4: Common IPsec VPN Issues
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 congured 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 conrm this by debugging the IPsec crypto engine
(debug crypto IPsec). The diagnostic output in Example 4-28 highlighted below conrms 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
From the Library of Ahmed Aden
ptg12115235
Common Conguration Issues with IPsec VPNs 169
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 dened 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
denition, and then explore some methods for diagnosing crypto ACL denition problems using
Cisco IOS IPsec debugging capabilities.
The rst case we will discuss demonstrates a crypto ACL denition 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. Congurations
illustrating a valid crypto ACL match for Router_A and Router_B are provided in Example 4-29.
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, trafc matching ACE 10 will
facilitate successful Phase1 and 2 SA negotiations. Trafc matching ACE 20 on Router-B will
NOTE The protected address and port ranges specied in crypto ACLs are commonly shown
as proxies in the crypto debugging output in Cisco IOS and ASA IPsec VPN endpoints.
NOTE The crypto ACLs described in Cases 2 through 4 below will not preclude Phase 2 SA
negotiation when TEDv3 is used. Although the ACLs 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#sss shhh hooo owww w aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1
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#sss shhh hooo owww w aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1
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#
From the Library of Ahmed Aden
ptg12115235
170 Chapter 4: Common IPsec VPN Issues
initiate a Phase 2 SA proposal that will be rejected by Router_A, which has no corresponding ACE
in its Crypto ACL for Router_Bs ACE 20 in crypto ACL 101. The trafc matching ACE 20 will
subsequently be dropped. Example 4-30 provides the congurations on Router_A and Router_B
illustrating the missing crypto ACE on Router_A.
Example 4-31 provides a conguration in which the crypto ACLs on both Router_A and Router_B
dene scopes of protected address spaces that are inconsistent with the opposite peers scope of
protected source addresses. For example, Router_A protects trafc destined for any IP address that
is sourced from 192.168.1.0/24. What would occur if trafc was sent from 192.168.1.1 to
Router_As physical IP address, 200.0.0.2? Router_A would encrypt the trafc as it matches ACE
10 in ACL 101. Router_B, however, would not encrypt the return trafc, as trafc sourced from
200.0.0.2 is not dened anywhere in its crypto ACL. For this reason, Phase 2 SA negotiation will
fail when such an inconsistency is dened in the crypto ACLs of two IPsec peers.
In the case provided in Example 4-32, the ACL denes a tighter scope of address space on
Router_Bs crypto ACL. As such, if Router_B initiates the Phase 2 exchange, then an IPsec SA
will be established successfully in the SADB, and trafc 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-30 Crypto ACL Mismatch Due to Missing ACE on Router_A
Router_A#sss shhh h aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1
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#sss shhh h aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1
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 Crypto ACL Mismatch Due to Inconsistent Destination Address Ranges
Router_A#sss shhh hooo owww w aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1
Extended IP access list 101
10 permit ip 192.168.1.0 0.0.0.255 any
Router_A#
Router_B#sss shhh hooo owww w aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1
Extended IP access list 101
10 permit ip 192.168.2.0 0.0.0.255 any
Router_B#
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 171
Architectural and Design Issues with IPsec VPNs
Aside from issues related to conguring 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 weve 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 rewalls, by
default, employ a closed model of security (by default, nothing is allowed) in which the rewall
must be explicitly instructed to allow the required protocols through by an administrator. When
deploying IPsec in rewalled 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 rewalled VPN environmentsrewall fragmentation handling, ltering of
required IPsec protocols, and ltering 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 rewalls. One such example that weve
discussed in Chapter 2 is in a DMZ design. Another popular application for such a design is in
secure extranet designs. Most rewalls available in todays marketplace employ a closed policy by
default, allowing no trafc 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, rewalls between IPsec peers must allow ISAKMP
trafc (UDP port 500) to pass between the IPsec VPN endpoints. Additionally, IPsec trafc must
be allowed through the rewall, or encrypted trafc will get blocked at the rewall outside
Example 4-32 Crypto ACL Mismatch Due to Inconsistent Destination Address Scope on Router_B
Router_A#sss shhh h aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1
Extended IP access list 101
10 permit ip 192.168.1.0 0.0.0.255 any (24 matches)
Router_A#
Router_B#sss shhh h aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1
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#
From the Library of Ahmed Aden
ptg12115235
172 Chapter 4: Common IPsec VPN Issues
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.
Figure 4-6 illustrates a rewalled IPsec VPN tunnel deployment in which tunnels are built from a
central, rewalled aggregation site out to smaller remote locations.
Figure 4-6 IPsec VPN Trafc Through Firewalls
Example 4-33 provides the rewall ACL conguration 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.
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 rewall congurations 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 rewall.
Example 4-33 Firewall Conguration for Crypto Trafc in Figure 4-6
DMZ-PIX-MAIN(config)# sss shhh hooo owww w aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1
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
Enterprise
10.0.0.0/8
Remote_Net_A
192.168.1.0/24
Remote_Net_B
192.168.2.0/24
Remote_Net_C
192.168.2.0/24
Allowing ISAKMP messages through the
firewall allows SAs to be built successfully and
allows encrypted traffic flows through the
corresponding IPsec tunnels.
1
6
0
.
1
.
0
.
0
/
3
0
160.1.4.0/30
1
6
0
.1
.8
.0
/3
0
.2
.6
.10
201.1.1.0/28
.1
Firewall blocks ISAKMP
(UDP 500), ESP (IP 50),
and AH (IP 51) by default.
IPsec Tunnels
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 173
Firewalls Handling of Fragmented IPsec Packets
In addition to ensuring that the appropriate protocols are allowed to communicate through the
rewall, it is critical that network designers should also account for the design considerations
presented by the way that rewalls handle fragmented packets. When an IPsec packet is
fragmented, the information relevant to the rewalls ltering decision, such as data found in the
Layer 3 and 4 headers, is obscured in noninitial fragments.
As such, the rewall will potentially allow fragments to pass without inspection, as shown in
Figure 4-7.
Figure 4-7 Firewall Fragment Handling in IPsec Networks
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)# sss shhh hooo owww w aaa accc cccc ceee esss ssss s--- -ggg grrr rooo ouuu uppp p
access-group 101 in interface outside
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.
Example 4-33 Firewall Conguration for Crypto Trafc in Figure 4-6 (Continued)
ISP_Net
MTU = 512
Encrypted
Payload
ESP
Auth
ESP
Header
Outer IP
Header
Outer IP
Header
Encrypted Fragment
Payload #1
Outer IP
Header
Encrypted Fragment
Payload #2
Outer IP
Header
Encrypted Fragment
Payload #3
Outer IP
Header
Last Encrypted
Fragment Payload
MTU = 1500
ENT_GW ISP_GW_B
ENT_FW ENT_DMZ_IN ISP_GW_A

IPsec Tunnel
Firewall cannot decrypt fragments to
perform reassembly. Virtual
Fragmentation Reassembly allows
fragment inspection without reassembly.
Intermediate Router, ISP_GW_B, fragments encrypted
traffic between ISP_GW_A and ENT_DMZ_IN
MTU = 4470 MTU = 1500
From the Library of Ahmed Aden
ptg12115235
174 Chapter 4: Common IPsec VPN Issues
Cisco PIX rewalls by default are congured to detect when a fragmented packet has been
received and to make ltering 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 rewall with the ability to make ltering decisions on
fragments without having to decrypt each packet in the fragmented chain. Virtual Fragmentation
Reassembly does indeed consume computational resources on the rewall, but does provide an
ideal solution when ltering 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 rewall,
ENT_FW, receives the fragments, and is congured for virtual fragmentation reassembly. The
rewall therefore does not do any reassembly. Instead, it will initially allow only the rst fragment
in the fragment chain through without being inspected. Virtual Fragment Reassembly enables the
rewall 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 rewall
would have to decrypt each fragment in the chain in order to reassemble the packet, which it is not
congured to do.
Filtering of ICMP Unreachables
ICMP unreachables are commonly used by hackers to nd and exploit network vulnerabilities, and
are a fundamental component of scanning techniques used to nd openings in rewalled
environments. As such, it is very common that rewalls not reply to ltered 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 rewall 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
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 175
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, specically 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 packets integrity.
Recall from our discussion in Chapter 2 that IPsec denes 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-specic 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 Conicts 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 specic
incompatibility, as source and destination information is not included in the integrity check.
From the Library of Ahmed Aden
ptg12115235
176 Chapter 4: Common IPsec VPN Issues
Inbound IPsec SA Selector Inconsistencies in NAT Environments
If IKE authenticates Phase 2 selectors, and the initiators 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 identiers, 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 trafc 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 identiers is illustrated in Figure 4-8.
Figure 4-8 SPD Confusion in NAT Environments
10.1.1.1
WAN
10.1.1.1
10.1.1.1 170.1.1.100
NAT
170.1.2.100 10.1.1.1
NAT
200.1.0.0/216
170.1.1.0/24
170.1.2.0/24
Inside Local Addresses intentionally overlap,
and are translated to unique global
addresses. If used as Phase 2 Identifiers, the
IPsec responder for the sources will install
overlapping security policy database entries.
Security policy database
(SPD) conflict for IPsec
initiators with the identity
of 10.1.1.1
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 177
IPsec Security Parameter Index Conicts 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 conicts 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 trafc 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 trafc from the responder could be forwarded to the incorrect initiator
due to the SPI conict in the NAT device (i.e., the NAT device does not know which initiator to
forward SPI 2000 trafc to).
Figure 4-9 SPI Overlap in NAT Device
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, trafc can
be forwarded in both directions. However, until that entry is installed, trafc received in other
directions (i.e., outside to inside) will not get forwarded, as a NAT/PAT entry will not be
dynamically created for trafc received on that interface.
WAN
200.1.0.0/216
Translation Table:
10.1.1.1, SPI 2000 -> 170.1.1.1
10.1.1.2, SPI 2000 -> 170.1.1.2
NAT device uses SPI-based NAT. Identical SPI
information for Router_A and Router_B can potentially
cause data to be forwarded to the incorrect peer (i.e., an
SPI match on 2000 could cause traffic destined for
10.1.1.2 to get forwarded to10.1.1.1 and vice versa).
Router_A
10.1.1.1
10.1.1.2
170.1.1.0/24
200.0.0.0/24
200.0.0.100
200.0.0.1
NAT
Router_B
Routers A and B
simultaneously initiate IPsec
VPN tunnels the concentrator,
choosing identical SPIs (2000).
From the Library of Ahmed Aden
ptg12115235
178 Chapter 4: Common IPsec VPN Issues
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 veried. This specic 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 rewall, Ent_FW.
Figure 4-10 The Operation of IPsec NAT-T
Routers A and B are both capable of NAT-T, and dynamically agree on the handling of IPsec
packets across the NATd 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.
10.0.0.1
10.0.0.0/24
201.1.0.200
201.1.0.0/24
Router_A Initiates Phase 1 Negotiation with Router_B.
Vendor ID string sent. (MM1)
1
NAT-Detect message exchanged and verified (hashes of
saddr, daddr, sport, and dport) in MM3 and MM4.
Router_B responds with its Vendor ID string, confirming
that it supports NAT - T (MM2).
3 3
2
Routers Negotiate NAT - T information in SA establishment
if step 3 detects NAT. (QM1 and QM2)
4 4
Router_A and Router_B insert an extra UDP header
(checksum = 0) outside of the ESP header when
forwarding IPsec packets to one another.
5 5
NAT
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 179
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 veried 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 xed ports and PAT
Incompatibility between UDP checksums and NAT (intermediate NAT-T UDP
header checksum set to 0)
SPI-Based NAT
IPsec SPIs provide another element that a NAT device can use to forward data between two
endpoints. When IPsec trafc 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 eld 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.
NOTE As noted above, Cisco IOS will attempt NAT-T during IKE Phase 1 negotiation. Cisco
IOS congures NAT-T automatically, and there is no manual conguration 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
From the Library of Ahmed Aden
ptg12115235
180 Chapter 4: Common IPsec VPN Issues
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.
The Inuence of IPsec on Trafc 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 todays
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:
Trafc Flow Hash Ubiquication: Flow-based QoS techniques, such as Weighted-Fair
queuing (WFQ) rely on the original source and destination IP addresses of the packet to hash
trafc ows 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 trafc ow 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 ow-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 trafc ows 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 trafc. It is critical to ensure that
NOTE Additional conguration information on IPsec and SPI-based NAT can be obtained at
the following link with a valid CCO account:
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 181
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 trafc ows locally on a network device. LLQ/CBWFQ requires that packets
within a trafc ow be identied 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 trafc from other trafc ows 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 trafc between the
two endpoints. Unlike LLQ/CBWFQ, where LLQ/CBWFQ classication and queuing
decisions are local in scope, the scope of RSVP queueing decisions is end-to-end. Although
RSVP can be congured to work in tandem with DiffServ-based QoS, it can also be
congured to place trafc in the RSVP-reserved queue regardless of what type of DiffServ
policy is congured on that specic network node.
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.
IPsecs Inuence 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
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
From the Library of Ahmed Aden
ptg12115235
182 Chapter 4: Common IPsec VPN Issues
occurs (other packets are dropped instead). For these reasons, QoS must be used for IP trafc
over the Frame-Relay links.
Figure 4-11 IPsec and DiffServ in a VoIP implementation
DiffServ is implemented in conjunction with LLQ/CBWFQ to deliver QoS for voice trafc to and
from the branches. Because the companys security policy mandates condentiality for voice
trafc, IPsec VPNs have been congured 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 trafc 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 trafc 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.
Phone_A
Phone_B
Router_A Router_B
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
Altering the order of transmission with
QoS can cause packets held in queue
to be received outside of the anti-replay
window on IPsec endpoints. The
anti-replay window must therefore
be sized accordingly.
DiffServ bits in the IP header are used to
make the appropriate QoS classifications
when executing on queuing decisions.
If AH is used, IP header information cannot
be re-marked after IPsec applies the AH
encapsulation otherwise the integrity
checks fail (specifically the AH MIC).
IPsec VPN Tunnel
VoIP RTP Stream
If DiffServ bits are not copied in to the outer IP header
(outside the crypto boundary), intermediate routers will not
be able to interpret them to make QoS decisions, hereby
breaking QoS between Phone_A and Phone_B.
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 183
IPsecs 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
Therefore, to dynamically provision resources on intermediate nodes between a source and
destination that require timely, ordered delivery of IP-based application trafc, 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
Phone_A
Phone_B
Router_A Router_B
IP
IP
IP
IP
IP
IP
IP
IP
IP
IP
IPsec VPN Tunnel
VoIP RTP Stream
If RSVP Path and Resv messages are not copied outside of the
crypto boundary, then intermediate nodes cannot use the
RSVP signalling messages to dynamically reserve resources
for the RTP stream between Phone_A and Phone_B.
From the Library of Ahmed Aden
ptg12115235
184 Chapter 4: Common IPsec VPN Issues
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
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.
Router_A Router_C Router_B
IP
IP
IP
IP
IP
IP
IP
ESP Encap
Original IP Packet
1500 + 52
Fragment
Fragment
1500-bytes
MTU = 1500 MTU = 1500 MTU = 1500 MTU = 1400
1500-bytes
1500-bytes
Original IP Packet
1400-bytes
Fragment 1 + IP
Header
72-bytes
Fragment 1 + IP
Header
72-bytes
Fragment 2 + IP
Header
120-bytes
Reassemble
Decrypt
Packet reassembly prior to decryption
is executed at the process level on the
decrypting endpoint, resulting in material
degradation in crypto switching
performance.
IPsec Tunnel
(ESP in Tunnel Mode)
Host_A
Server_B
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 185
Figure 4-14 PMTUD and IPsec
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_As 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).
Router_A Router_C Router_B
IP
IP
IP
IP
IP
IP
IP
DF Set?
Drop
DF Set?
Length <
1414 MTU?
ICMP (1500-bytes)
ICMP Unreachable
(Use MTU = 1414)
MTU = 1500 MTU = 1500 MTU = 1414 MTU = 512
1
ICMP (1414-bytes)
4
ICMP Echo Reply
8
3
ICMP
Unreachable
(Use MTU =
512)
6
2
DF Set?
Drop
Length <
512 MTU?
5
Length <
1414 MTU?
ICMP
(1414-bytes)
DF Set? ICMP (512-bytes)
ICMP (512-bytes)
7
Length <
1414 MTU?
ICMP
(512-bytes)
DF Set?
Length <
1500 MTU?
DF Set?
Length <
512 MTU?
ICMP
(512-bytes)
Host_A
Server_B
From the Library of Ahmed Aden
ptg12115235
186 Chapter 4: Common IPsec VPN Issues
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_Cs 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.
IPsec in Cisco IOS can be congured to copy the DF bit value in to the outer IP header in ESP-
processed packets. As such, the ICMP trafc 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 ones design strategy to
mitigate fragmentation reassembly issues in IPsec VPNs. In this section, we will briey 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 weve 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 rewalls, to deny ICMP unreachable
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 conguration of PMTUD than
the previous, known as Tunnel Path MTU Discovery. The specic operation of fragment
handling using PMTUD in IPsec and IPsec+GRE environments is discussed in greater detail
later in this chapter.
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 187
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 dened 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.
From the Library of Ahmed Aden
ptg12115235
188 Chapter 4: Common IPsec VPN Issues
Figure 4-15 TCP MSS, IP MTU, and Fragmentation
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_As 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 trafc. Note that, in this case, the larger MTU value would still be used for UDP
trafc.
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.
Router_A Router_C Router_B
IP
IP
IP
IP
IP
IP
IP
MSS Buffer = 20k MSS Buffer = 16k
MTU = 1500 MTU = 2048
1
2
4
3
Host_A
Server_B
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 189
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
specics 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
Router_A Router_C Router_B
IP
IP
IP
IP
IP
IP
IP
DF Set?
1500 + 58
ESP Encap
Timeout and Retransmit
1442 + 58
ESP Encap
Drop
Length <
1500 MTU?
Update SA
PMTU
ICMP (1500-bytes)
ICMP Unreachable
(Use MTU = 1442)
DF Set?
Drop
Length <
1400 MTU?
MTU = 1500 MTU = 1500 MTU = 1500 MTU = 1400
ICMP (1442-bytes)
ICMP Echo Reply
ICMP
(1500-bytes)
DF Set?
1442 + 58
ESP Encap
1342 + 58
ESP Encap
1400 58
ESP Decap
Drop
Length <
1400 MTU?
ICMP (1442-bytes)
ICMP (1342-bytes)
ICMP Unreachable
(Use MTU = 1342)
ICMP (1342-bytes)
ICMP
(1400-bytes)
ICMP
(1400-bytes)
ICMP
Unreachable
(Use MTU =
1400)
Host_A
Server_B
ESP
From the Library of Ahmed Aden
ptg12115235
190 Chapter 4: Common IPsec VPN Issues
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 eld 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 weve discussed in previous sections of this chapter, and in others, it is sometimes necessary
to encapsulate certain trafc types in GRE prior to processing them with IPsec. Processing of
multicast trafc, for example, is one instance in which one would seek to encapsulate the plain text
trafc 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.
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 191
Figure 4-17 Fragment Handling and PMTUD Operation with IPsec+GRE Tunnels
Router_A Router_C Router_B
IP
IP
IP
IP
IP
IP
IP
DF Set?
1500 + 24
GRE Encap
Drop
Length <
1496 MTU?
DF Set?
1472 + 58
ESP Encap
Drop
Length <
1500 MTU?
Set GRE
MTU = 1414
ICMP (1500-bytes)
ICMP Unreachable
(Use MTU = 1472)
DF Set?
1472 + 24
GRE Encap
Length <
1414 MTU?
ICMP (1472-bytes)
Timeout and Retransmit
Timeout and Retransmit
ICMP Unreachable
(Use MTU = 1414)
MTU = 1500 MTU = 1500 MTU = 1500 MTU = 1400
ICMP Echo Reply
DF Set?
1472 + 24
GRE Encap
Length <
1496 MTU?
ICMP (1472-bytes)
DF Set?
1438 + 58
ESP Encap
Length <
1500 MTU?
DF Set?
1414 + 24
GRE Encap
Length <
1496 MTU?
ICMP (1414-bytes)
DF Set?
Drop
Length <
1400 MTU?
DF Set?
1438 + 58
ESP Encap
Drop
Drop
Length <
1400 MTU?
Set GRE
MTU = 1342
DF Set?
1414 + 24
GRE Encap
Length <
1342 MTU?
ICMP (1414-bytes)
Timeout and Retransmit
ICMP Unreachable
(Use MTU = 1318)
DF Set?
1342 + 58
ESP Encap
Length <
1400 MTU?
DF Set?
1318 + 24
GRE Encap
Length <
1342 MTU?
ICMP (1414-bytes)
ICMP
(1442-bytes)
ICMP
Unreachable
(Use MTU =
1400)
Update SA
PMTU
DF Set?
1414 + 24
GRE Encap
Length <
1496 MTU?
ICMP (1414-bytes)
ESP GRE
Host_A
Server_B
From the Library of Ahmed Aden
ptg12115235
192 Chapter 4: Common IPsec VPN Issues
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 eld 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.
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 193
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 nally
forwards the original ICMP PMTUD message to Server_B.
16. Server_B acknowledges the receipt of the message, conrming that Host_A is to use an MTU
size of 1338 bytes for this path.
Solutions for Preventing Fragmentation
In previous sections, weve discussed the most common method for preventing fragmentation
Path 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 ltering 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
congure 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.
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.
From the Library of Ahmed Aden
ptg12115235
194 Chapter 4: Common IPsec VPN Issues
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_As IPsec SADB.
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_As
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:
Example 4-34 Enabling IPsec Prefragmentation with PMTUD and Crypto DF-bit Rewrite
Router_A#ccc cooo onnn nfff fiii iggg g
Router_A#ccc cooo onnn nfff fiii iggg guuu urrr reee e ttt teee errr rmmm miii innn naaa alll l
Enter configuration commands, one per line. End with CNTL/Z.
Router_A(config)#ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ddd dfff f--- -bbb biii ittt t sss seee ettt t
Router_A(config)#ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c fff frrr raaa aggg gmmm meee ennn nttt taaa attt tiii iooo onnn n bbb beee efff fooo orrr reee e--- -eee ennn nccc crrr ryyy yppp pttt tiii iooo onnn n
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 conguration instances in which IPsec Lookahead
Fragmentation and DF-bit overwrite are congured 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
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 195
Figure 4-18 IPsec Fragment Handling Without PMTUD-Enabled 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.
Router_A Router_C Router_B
IP
IP
IP
IP
IP
IP
IP
Lookahead
Fragment
1442 + 58
Set DF = 1
ESP Encap
1500 + 58
< MTU?
Set Path
MTU = 1400
Pre-Frag
Packet =
1442 bytes
Fragment =
78 bytes
Set PMTU
in SADB to
MTU = 1400
Reassemble
Length <
1500 MTU?
IP (1500-bytes)
MTU = 1500 MTU = 1500 MTU = 1500 MTU = 1400
DF Set?
Drop
Length <
1400 MTU?
ESP + IP
(1500-bytes)
IP + ESP
(136-bytes)
78 + 58
Set DF = 1
ESP Encap
136 58
ESP Decap
DF Set?
Length <
1400 MTU?
ESP + IP
(136-bytes)
ICMP
Unreachable
(Use MTU =
1400)
Lookahead
Fragment
1342 + 58
Set DF = 1
ESP Encap
1500 + 58
< MTU?
Pre-Frag
Packet =
1342 bytes
Fragment =
78 bytes
ICMP (1500-bytes)
IP (1342 bytes + 158 bytes)
IP + ESP
(1400-bytes)
IP + ESP
(1400-bytes)
1400 58
ESP Decap
DF Set?
Length <
1400 MTU?
158 + 58
Set DF = 1
ESP Encap
IP + ESP
(216-bytes)
IP + ESP
(216-bytes)
216 58
ESP Decap
DF Set?
Length <
1400 MTU?
Timeout and Retransmit
Router configured to manually
clear the DF bit so that IPsec
prefragmentation can occur
(See Example 4-11)
Router configured to set DF bit in
every outside IP header applied
during ESP encapsulation.
Because fragmentation occurred
before encryption, decryption occurs
before fragment reassembly. This
behavior allows fragmented packets to
be decrypted in the CEF switching
path, as opposed to the process
switching path.
ESP
Host_A
Server_B
From the Library of Ahmed Aden
ptg12115235
196 Chapter 4: Common IPsec VPN Issues
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
Weve 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 trafc
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 segments MTU is properly tuned. Network designers can anticipate the difculty 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 articially 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
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 197
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 trafc 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
The following order of events describes the inuence 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 nd routes installed in their routing table for the
appropriate tunnel destination interfaces and build the GRE tunnel accordingly using the
statically congured default route (Example 4-35, line 30).
2. Router_A and Router_B are congured to encrypt all GRE trafc between each other using
ESP. Therefore, all exchanges across the GRE tunnel will be kept condential.
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
specic route to the GRE tunnel destination than the default used in step 1 above.
interface s0/0 = 200.0.0.1/30
interface lo192 = 192.168.1.1/32
Router_A
interface s0/0 =200.0.0.2/30
Interface lo192 = 192.168.1.2/32
Serial Link = 200.0.0.0/30
Router_B
3
ESP Tunnel GRE = 192.168.0.0/30
3
5
33
5
6
R
e
c
u
r
s
i
v
e

R
o
u
t
e

C
l
e
a
r
e
d
R
e
c
u
r
s
i
v
e

R
o
u
t
e

C
l
e
a
r
e
d
Tunnel Route Learned Recursively Tunnel Route Learned Recursively
GRE Tunnel Established 1
IPsec Tunnel Established 2
EIGRP RP Adjacency Formed 4
EIGRP RP Adjacency Cleared 6
From the Library of Ahmed Aden
ptg12115235
198 Chapter 4: Common IPsec VPN Issues
6. Once Router_A and Router_B are instructed to learn each others 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 conguration 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-36 provides the diagnostic output on Router_A that conrms 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 specic than the default route, EIGRP installs it in the
routing table, causing the tunnel to fail due to recursive routing (as conrmed in Example 4-36,
Example 4-35 Conguration Errors Leading to Recursive Routing (Topology in Figure 4-19)
111 1 iii innn nttt teee errr rfff faaa accc ceee e LLL Looo oooo oppp pbbb baaa accc ckkk k111 1999 9222 2
222 2 iii ippp p aaa addd dddd drrr reee esss ssss s 111 1999 9222 2... .111 1666 6888 8... .111 1... .111 1 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5
333 3 !!! !
444 4 iii innn nttt teee errr rfff faaa accc ceee e TTT Tuuu unnn nnnn neee elll l111 1999 9222 2
555 5 iii ippp p aaa addd dddd drrr reee esss ssss s 111 1999 9222 2... .111 1666 6888 8... .000 0... .111 1 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5222 2
666 6 ttt tuuu unnn nnnn neee elll l sss sooo ouuu urrr rccc ceee e LLL Looo oooo oppp pbbb baaa accc ckkk k111 1999 9222 2
777 7 ttt tuuu unnn nnnn neee elll l ddd deee esss sttt tiii innn naaa attt tiii iooo onnn n 111 1999 9222 2... .111 1666 6888 8... .222 2... .111 1
888 8 !!! !
999 9 !!! !
111 1000 0 iii innn nttt teee errr rfff faaa accc ceee e SSS Seee errr riii iaaa alll l111 1/// /000 0
111 1111 1 iii ippp p aaa addd dddd drrr reee esss ssss s 222 2000 0000 0... .000 0... .000 0... .111 1 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5222 2
111 1222 2 eee ennn nccc caaa appp psss suuu ulll laaa attt tiii iooo onnn n fff frrr raaa ammm meee e--- -rrr reee elll laaa ayyy y
111 1333 3 sss seee errr riii iaaa alll l rrr reee esss sttt taaa arrr rttt t--- -ddd deee elll laaa ayyy y 000 0
111 1444 4 fff frrr raaa ammm meee e--- -rrr reee elll laaa ayyy y iii innn nttt teee errr rfff faaa accc ceee e--- -ddd dlll lccc ciii i 111 1000 0222 2
111 1555 5 fff frrr raaa ammm meee e--- -rrr reee elll laaa ayyy y lll lmmm miii i--- -ttt tyyy yppp peee e aaa annn nsss siii i
111 1666 6 !!! !
111 1777 7 !!! !
111 1888 8 rrr rooo ouuu uttt teee errr r eee eiii iggg grrr rppp p 111 1
111 1999 9 rrr reee eddd diii isss sttt trrr riii ibbb buuu uttt teee e ccc cooo onnn nnnn neee eccc cttt teee eddd d
222 2000 0 nnn neee ettt twww wooo orrr rkkk k 111 1999 9222 2... .111 1666 6888 8... .000 0... .000 0
222 2111 1 ddd deee efff faaa auuu ulll lttt t--- -mmm meee ettt trrr riii iccc c 111 1555 5000 0000 0 111 1000 0000 0 111 1222 2888 8 111 1222 2888 8 444 4777 7000 0000 0
222 2222 2 nnn nooo o aaa auuu uttt tooo o--- -sss suuu ummm mmmm maaa arrr ryyy y
222 2333 3 iii ippp p ccc clll laaa asss ssss slll leee esss ssss s
222 2444 4 iii ippp p rrr rooo ouuu uttt teee e 000 0... .000 0... .000 0... .000 0 000 0... .000 0... .000 0... .000 0 222 2000 0000 0... .000 0... .000 0... .222 2
From the Library of Ahmed Aden
ptg12115235
Architectural and Design Issues with IPsec VPNs 199
lines 20 and 21). Once the tunnel fails, EIGRP tears down the adjacency, as illustrated in
Example 4-36, line 22.
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-38 provides an alternative to excluding routes from the EIGRP redistribution using a
distribute list. In the context of this particular example, the conguration in Example 4-38 will
accomplish the same task as the route-map conguration in Example 4-37.
Example 4-36 Recursive Routing Symptoms and Diagnostic Output in Cisco IOS
1 Router_A#sss shhh hooo owww w iii ippp p rrr rooo ouuu uttt teee e
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
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
From the Library of Ahmed Aden
ptg12115235
200 Chapter 4: Common IPsec VPN Issues
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.
Summary
In this chapter, weve covered several different broader areas of common issues with IPsec VPN
deployments. The rst area of common IPsec VPN issues we discussed pertains to conguration
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 rst task that crypto endpoints must accomplish to build an IKE SA is
Example 4-38 Controlling EIGRP Route Redistribution with Distribute Lists
rrr rooo ouuu uttt teee errr r eee eiii iggg grrr rppp p 111 1
rrr reee eddd diii isss sttt trrr riii ibbb buuu uttt teee e ccc cooo onnn nnnn neee eccc cttt teee eddd d
nnn neee ettt twww wooo orrr rkkk k 111 1999 9222 2... .111 1666 6888 8... .000 0... .000 0
ddd deee efff faaa auuu ulll lttt t--- -mmm meee ettt trrr riii iccc c 111 1555 5000 0000 0 111 1000 0000 0 111 1222 2888 8 111 1222 2888 8 444 4777 7000 0000 0
ddd diii isss sttt trrr riii ibbb buuu uttt teee e--- -lll liii isss sttt t 111 1 iii innn n
nnn nooo o aaa auuu uttt tooo o--- -sss suuu ummm mmmm maaa arrr ryyy y
!!! !
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1 ddd deee ennn nyyy y 111 1999 9222 2... .111 1666 6888 8... .111 1... .000 0
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1 ppp peee errr rmmm miii ittt t aaa annn nyyy y
Example 4-39 GRE Tunnel and EIGRP Adjacency Reestablishment when Excluding Redistribution of
Recursively-Learned Routes Using Route-Maps and ACLs
rrr rooo ouuu uttt teee errr r eee eiii iggg grrr rppp p 111 1
rrr reee eddd diii isss sttt trrr riii ibbb buuu uttt teee e ccc cooo onnn nnnn neee eccc cttt teee eddd d
nnn neee ettt twww wooo orrr rkkk k 111 1999 9222 2... .111 1666 6888 8... .000 0... .000 0
ddd deee efff faaa auuu ulll lttt t--- -mmm meee ettt trrr riii iccc c 111 1555 5000 0000 0 111 1000 0000 0 111 1222 2888 8 111 1222 2888 8 444 4777 7000 0000 0
nnn nooo o aaa auuu uttt tooo o--- -sss suuu ummm mmmm maaa arrr ryyy y
!!! !
crvpn-3600-a#ccc cooo onnn nfff f ttt 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
From the Library of Ahmed Aden
ptg12115235
Summary 201
agreement on IKE SA proposals. Weve 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)
Dife-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,
weve 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 dened, an IKE SA must exist on the crypto endpoints before an
IPsec SA can be established. Once an IKE SA has been conrmed to exist, measures should be
taken to conrm that the two crypto endpoints have agreed on IPsec SA proposals. In this chapter,
weve 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 trafc after an IPsec SA has been
negotiated
The scope of protected trafc 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 conrm 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 conguration issues with IPsec VPN
deployments, we have also introduced and discussed various architectural issues with IPsec VPN
deployments. Unlike conguration 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
From the Library of Ahmed Aden
ptg12115235
202 Chapter 4: Common IPsec VPN Issues
IPsec and QoS Inconsistencies
IPsec and Fragmentation
IPsec+GRE and Recursive Routing
When deploying IPsec through a rewall, several intrinsic design challenges surface. First, the
appropriate protocols need to be allowed to pass for the IPsec and ISAKMP trafc to pass through
the rewall. 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 trafc to pass through
the rewall. 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 rewalls, 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 manipulatedspecically 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 Conicts 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, weve
discussed how IPsec makes source and destination hash information opaque to intermediate notes
that require that hash information to make Weighted-Fair Queueing decisions. Weve also
discussed how IPsec ubiquies 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.
From the Library of Ahmed Aden
ptg12115235
Summary 203
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 trafc 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.
From the Library of Ahmed Aden
ptg12115235
From the Library of Ahmed Aden
ptg12115235
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
From the Library of Ahmed Aden
ptg12115235
From the Library of Ahmed Aden
ptg12115235
C H A P T E R
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 specic components
of IPSec that present the opportunity to design HA in to the architecture. This chapter
provides an introduction to ve major areas for designing HA into an IPSec VPN system
architecture:
Network and Path RedundancyIPSec 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 RedundancyTerminating 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 AvailabilityThe 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 SymmetryIn 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 trafc 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 rewalls are injected
in between the two tunnel termination endpoints.
From the Library of Ahmed Aden
ptg12115235
208 Chapter 5: Designing for High Availability
Load BalancingLoad 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, specic 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 trafc 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
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 FailureThe 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 congured
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.
Network_A
IPSec_B
Site B
Single points of failure could
tear down the IPSec VPN
tunnel between Network_A
and Network_B.
Network_A
IPSec_A
Site A
Fa0/0
WAN_EdgeA WAN_EdgeB
Serial0/0
Serial0/0
Fa0/0
IPSec VPN Tunnel
From the Library of Ahmed Aden
ptg12115235
Network and Path Redundancy 209
Figure 5-2 Dual-Interface Path Redundancy
WAN Infrastructure/Carrier FailureIn 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 trafc requiring higher availability in the
crypto path, a backup WAN link can be deployed, as depicted in Figure 5-2.
Node FailureEven 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
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,
Network_B
IPSec_B
Network_A
IPSec_A
Int Fa0/0 Int Fa0/0
Site A
WAN_EdgeA
Int Se0/0
Int Se0/1
WAN_EdgeB
Int Se0/0
Int Se0/1
Service
Provider
Site B
Link and interfaces single points
of failures are eliminated with
redundant WAN interface.
The VPN gateway itself
still presents a single point
of failure.
IPSec VPN Tunnel
IPSec_B
Network_B
Network_A
IPSec_A
Serial0/0
Serial0/0
Site A
Fa0/0
Fa0/0
S
e
ria
l0
/1
S
e
r
ia
l0
/
1
S
e
r
ia
l0
/1 S
e
r
ia
l0
/
1
Site B
Fa0/0
Fa0/0
WAN_EdgeA1 WAN_EdgeB1
WAN_EdgeB2
Serial0/0
Serial0/0
WAN_EdgeA2
IPSec VPN Tunnel
From the Library of Ahmed Aden
ptg12115235
210 Chapter 5: Designing for High Availability
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 InterfacesTerminating 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 InterfacesWith 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 StatementsRedundant 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.
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.
From the Library of Ahmed Aden
ptg12115235
IPSec Tunnel Termination Redundancy 211
Figure 5-4 Tunnel Termination on Highly Available Interfaces
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
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
Fa0/0
Fa0/0
Fa0/0
Site B
IPSec_B
Network_B
WAN_EdgeA2
Serial0/0
Serial0/0
Site A
Fa0/0
S
e
r
ia
l0
/
1
S
e
r
ia
l0
/
1
S
e
r
ia
l0
/
1
S
e
r
ia
l0
/
1
WAN_EdgeA1
WAN_EdgeB1
WAN_EdgeB2
Serial0/0
Serial0/0
IPSec_A
Network_A
IPSec VPN Tunnel
Network_B
Fa0/0
Fa0/0
IPSec_B1
IPSec_B2
Site B
Fa0/0
Fa0/0
WAN_EdgeA2
Serial0/0
Serial0/0
IPSec_A1
Site A
Fa0/0 Fa0/0
Fa0/0 Fa0/0
S
e
r
ia
l0
/1 S
e
r
ia
l0
/
1
S
e
r
ia
l0
/
1
S
e
r
ia
l0
/
1
IPSec_A2
WAN_EdgeA1 WAN_EdgeB1
WAN_EdgeB2
Serial0/0
Serial0/0
HSRP virtual address shared
between IPSec_A1 (HSRP active)
and IPSec_A2 (HSRP standby).
Network_A
HSRP virtual address shared
between IPSec_B1 (HSRP active)
and IPSec_B2 (HSRP standby).
IPSec VPN Tunnel
From the Library of Ahmed Aden
ptg12115235
212 Chapter 5: Designing for High Availability
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 HAStateless 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 well 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 HAStateful 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.
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.
NOTE The details of stateful and stateless IPSec HA design between routers in an HSRP
group, including conguration, failover operations, and steps to minimize reconvergence delay
impact, are discussed in greater detail in Chapter 6, Site-to-Site Local HA Solutions.
From the Library of Ahmed Aden
ptg12115235
IPSec Tunnel Termination Redundancy 213
Figure 5-6 Geographic IPSec HA Using Multiple Peering Statements in Each Crypto Map on
IPSec_A1, A2, B1, and B2
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 trafc 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 trafc from Network_A to Network_B in the encrypted path.
Figure 5-7 Loopback-to-Loopback IPSec Peering Sessions with Redundant Peer Statements
All WAN edge routers use multiple
peering statements, providing a
redundant IPSec VPN tunnel for
traffic in the encrypted path (IP traffic
exchanged between from Network_A
to Network_B).
All four tunnel terminating IPSec VPN gateways
are on different segments. IPSec_A1 & A2 are
not on the same segment, IPSec_B1 & B2 are
not on the same segment, thereby precluding
tunnel termination on a virtual interface using
HSRP or VRRP.
Site A
WAN_EdgeA1 WAN_EdgeB1
WAN_EdgeA2 WAN_EdgeB2
Serial0/0
S
e
r
ia
l0
/1
Serial0/0
Serial0/0 Serial0/0
S
e
r
ia
l0
/1
S
e
r
ia
l0
/1
S
e
r
ia
l0
/1
Network_A
IPSec_A2
IPSec_A1
Fa0/0
Fa0/0
Fa0/0
Fa0/0
Site B
Network_B
IPSec_B2
IPSec_B1
Fa0/0
Fa0/0
Fa0/0
Primary IPSec VPN Tunnel
Primary IPSec VPN Tunnel
S
e
c
o
n
d
a
r
y
IP
S
e
c
V
P
N
T
u
n
n
e
l
S
e
c
o
n
d
a
r
y
IP
S
e
c
V
P
N
T
u
n
n
e
l
Fa0/0
All four crypto routers peer loopback-to-loopback with one
another using redundant peering statements in their crypto
maps. This effectively creates a full mesh of encrypted paths
and a fully redundant geographic IPSec HA design.
Site A
WAN_EdgeA1
WAN_EdgeA2
WAN_EdgeB1
WAN_EdgeB2
Serial0/0
S
e
ria
l0
/1
Serial0/0
S
e
ria
l0
/1
S
e
ria
l0
/1
Serial0/0
Serial0/0
Network_A
IPSec_A2
IPSec_A1
Fa0/0
Fa0/0
Fa0/0
Fa0/0
Site B
Network_B
IPSec_B2
IPSec_B1
Fa0/0
Fa0/0
Fa0/0
Fa0/0
S
e
ria
l0
/1
Secondary IPSec VPN Tunnel (IPSec_A1 -> IPSec_B2)
Primary IPSec VPN Tunnel (IPSec_A1 -> IPSecB1)
Secondary IPSec VPN Tunnel (IPSec_A2 -> IPSec_B1)
Primary IPSec VPN Tunnel (IPSec_A2 -> IPSecB2)
From the Library of Ahmed Aden
ptg12115235
214 Chapter 5: Designing for High Availability
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 trafc
will not be able to ow 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 trafc 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
NOTE Further explanation of design considerations and conguration 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.
Site B
Network_B
IPSec_B2
IPSec_B1
Fa0/0
Fa0/0
Fa0/0
Fa0/0
S
e
r
i
a
l
0
/
1
Site A
S
erial0/0
Serial0/0
Serial0/0
WAN_EdgeA2
S
e
ria
l0
/0
S
e
r
i
a
l
0
/
1
S
e
r
i
a
l
0
/
1
Network_A
Routed
Infrastructure
ISP
Layer 3
IPSec_A2
IPSec_A1
Fa0/0
Fa0/0
Fa0/0
Fa0/0
S
e
c
o
n
d
a
r
y
IP
S
e
c
V
P
N
T
u
n
n
e
l
S
e
c
o
n
d
a
r
y
IP
S
e
c
V
P
N
T
u
n
n
e
l
Primary IPSec VPN Tunnel
Primary IPSec VPN Tunnel
S
e
r
i
a
l
0
/
1
WAN_EdgeB2
WAN_EdgeA1 WAN_EdgeB1
From the Library of Ahmed Aden
ptg12115235
Managing Peer and Path Availability 215
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.
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.
Once peer availability has been addressed, it is important to make sure that the encrypted path
(the IPSec VPN tunnel) is available to trafc to be included in the encrypted path. In other words,
trafc 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 trafc cannot
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 benet of added IPSec HA. If overlooked, administrators face the risks
associated with over-designed IPSec deployments, including increased maintenance,
management, complexity, and costs.
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.
From the Library of Ahmed Aden
ptg12115235
216 Chapter 5: Designing for High Availability
be leaked between cleartext- and ciphertext-routed domains. This particular scenario effectively
blocks the availability of the path for trafc 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
When an IPSec peer goes ofine, 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
On-Demand Dead Peer Detection (DPD)
IPSec_A
Site A
Prim
ary IPSec VPN
Tunnel
3
IKE Keepalives (DPD with Periodic Queries)
IPSec_B1
IPSec_B2
Site B
4
5
Site B Site A
2
IPSec_A
Prim
ary IPSec VPN
Tunnel
IPSec_B1
IPSec_B2
5
3
Si
Si
Si
Si
1
1
4
2
From the Library of Ahmed Aden
ptg12115235
Managing Peer and Path Availability 217
Chapter 7, Site-to-Site Geographic HA Solutions, for more detail on IPSec High Availability)
and inefcient 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 trafc 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 trafc from the workstations at Site_A and must forward the trafc 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 specied 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,
trafc must be forwarded to the remote peer to initiate the discovery of the dead peer (Step 2). If
trafc 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 gateways 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 trafc 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 ofine.
2. The IPSec gateway for Site A forwards its rst IKE keepalive to the dead peer at Site B
3. Site As IPSec gateway does not receive a response to the rst IKE keepalive within the
congured keepalive interval (default of 10 seconds). Site As IPSec gateway forwards a
second IKE keepalive to the dead peer at Site B.
From the Library of Ahmed Aden
ptg12115235
218 Chapter 5: Designing for High Availability
4. Site As IPSec gateway does not receive a response to the rst IKE keepalive within the
congured keepalive interval. Site As 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 Bs 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 trafc 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 trafc in the encrypted path. Improper management of the IPSec SADB
can lead to operational issues in HA environments and platform scalability issues specically
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 Conguration, IPSec will not encrypt multicast trafc 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
To unify RP domains A and B
using the IPSec VPN tunnel, the
IPSec VPN gateways must use
either RRI or IPSec+GRE.
Routed
Domain A
Routed
Domain B
IPSec-A IPSec-B
Routed Domain C
Multicast RP updates from
domain A to B cannot pass
across the IPSec VPN tunnel.
IPSec VPN Tunnel
From the Library of Ahmed Aden
ptg12115235
Managing Path Symmetry 219
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 congure
the RP to use unicast updates, rather than multicast updates. Conguring of unicast neighbors in
RP processes come with added conguration, management, and scalability issues. However,
in simpler site-to-site IPSec VPN environments, the conguration of unicast updates can be
congured 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 weve 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 denition
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 trafc 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 trafc 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.
From the Library of Ahmed Aden
ptg12115235
220 Chapter 5: Designing for High Availability
Figure 5-11 IPSec VPN Failure Due to Path Asymmetry
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 trafc 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. Specically,
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 congured for IPSec, but there is a rewall
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.
Stateful firewall allows return
IPSec traffic for sessions
initiated from the inside
(Site_A to Site_B) to return
along Path #1.
IPSec_A
Site_A
IPSec_B
Site_B
INET_A
IEDGE_A2
IEDGE_A1
IEDGE_B1
IEDGE_B2
INET_B
The stateful firewall has not
observed an IPSec traffic flow
originating from the inside to
the outside (Site_A to site_B),
and is therefore dropped by
the stateful firewall.
The serial link between
INET_A and IEDGE_B1 fails,
causing the asymmetric
routing between Site_A and
Site_B.
1
3
2
PATH #1
PATH #2
From the Library of Ahmed Aden
ptg12115235
Managing Path Symmetry 221
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
Stateful firewall allows return
IPSec traffic for sessions
initiated from the inside
(Site_A to Site_B) to return
along Path #1.
The serial link between INET_A
and IEDGE_B1 fails, causing
the asymmetric routing between
Site_A and Site_B.
IEDGE routers have RPs
configured to always forward
traffic via the primary path to
its local IPSec VPN gateway
unless it is unavailable.
IPSec_A
IPSec_B
Site_A
INET_A
Site_B
IEDGE_A1
IEDGE_A2
IEDGE_B1
IEDGE_B2
INET_B
PATH #1
PATH #2
From the Library of Ahmed Aden
ptg12115235
222 Chapter 5: Designing for High Availability
In Figure 5-12, the IEDGE routers at both Site_A and Site_B are congured to forward trafc to
the next hop of IPSec_A1 and IPSec_B1, respectively, unless the IPSec VPN gateways are down.
This conguration 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.
Load Balancing, Load Sharing, and High Availability
Load balancing between IPSec VPN tunnels provides some of the benets 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.
Specically, 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 trafc is load balanced between multiple IPSec VPN tunnels, the trafc ows 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 trafc 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
conguration of crypto ACLs, crypto maps, and crypto peers.
Figure 5-13 illustrates a scenario in which the crypto ACLs are congured to load balance trafc
between two IPSec VPN tunnels between IPSec_A and IPSec_B.
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 specic
methods of RP tuning, however, are outside of the scope of this discussion.
From the Library of Ahmed Aden
ptg12115235
Load Balancing, Load Sharing, and High Availability 223
Figure 5-13 Multiple Peer Statements and Load Balancing
Routing-protocol trafc 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 trafc ows in Figure 5-13 are forced over the two IPSec
tunnels in a load-shared format by conguring the crypto ACLs to forward trafc over the
corresponding tunnel to the appropriate peer IP addresstrafc from 10.1.1.0/24 to 10.1.2.0/24
takes Path #1, while trafc 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
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p555 5--- -lll looo oaaa addd dbbb baaa alll l 111 1000 0 iii ippp psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
!!! ! ### #<<< <--- ---- -222 2000 0000 0... .000 0... .000 0... .222 2 iii isss s ttt thhh heee e ddd deee esss sttt tiii innn naaa attt tiii iooo onnn n ttt tuuu unnn nnnn neee elll l ttt teee errr rmmm miii innn naaa attt tiii iooo onnn n aaa addd dddd drrr reee esss ssss s fff fooo orrr r ttt thhh heee e eee ennn nccc crrr ryyy yppp pttt teee eddd d
!!! ! ttt trrr raaa afff ffff fiii iccc c fff flll looo owww w sss sppp peee eccc ciii ifff fiii ieee eddd d iii innn n ccc crrr ryyy yppp pttt tooo o AAA ACCC CLLL L 111 1000 0111 1--- ---- ->>> >
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .000 0... .000 0... .222 2
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -ddd duuu uaaa alll liii innn nttt t
!!! ! ### #<<< <--- ---- -CCC Crrr ryyy yppp pttt tooo o AAA ACCC CLLL L 111 1000 0111 1 ddd deee efff fiii innn neee esss s ttt thhh heee e fff fiii irrr rsss sttt t eee ennn nccc crrr ryyy yppp pttt teee eddd d ttt trrr raaa afff ffff fiii iccc c fff flll looo owww w... . TTT Trrr raaa afff ffff fiii iccc c
!!! ! mmm maaa attt tccc chhh hiii innn nggg g ttt thhh heee e AAA ACCC CLLL L 111 1000 0111 1 www wiii illl llll l bbb beee e eee ennn nccc crrr ryyy yppp pttt teee eddd d aaa annn nddd d rrr rooo ouuu uttt teee eddd d ttt tooo o 222 2000 0000 0... .000 0... .000 0... .222 2
!!! ! fff fooo orrr r ddd deee eccc crrr ryyy yppp pttt tiii iooo onnn n--- ---- ->>> >
mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
rrr reee evvv veee errr rsss seee e--- -rrr rooo ouuu uttt teee e
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p555 5--- -lll looo oaaa addd dbbb baaa alll l 111 1000 0 iii ippp psss seee eccc c--- -sss saaa akkk kmmm mppp p
!!! ! ### #<<< <--- ---- -222 2000 0000 0... .000 0... .000 0... .444 4 iii isss s ttt thhh heee e ddd deee esss sttt tiii innn naaa attt tiii iooo onnn n ttt tuuu unnn nnnn neee elll l ttt teee errr rmmm miii innn naaa attt tiii iooo onnn n aaa addd dddd drrr reee esss ssss s fff fooo orrr r ttt thhh heee e eee ennn nccc crrr ryyy yppp pttt teee eddd d
!!! ! ttt trrr raaa afff ffff fiii iccc c fff flll looo owww w sss sppp peee eccc ciii ifff fiii ieee eddd d iii innn n ccc crrr ryyy yppp pttt tooo o AAA ACCC CLLL L 111 1000 0222 2--- ---- ->>> >
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .000 0... .000 0... .444 4
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -ddd duuu uaaa alll liii innn nttt t
continues
IPSec_A
IPSec_B
Encrypted Flow #1:
10.1.1.0/24 <-> 10.1.2.0/24
Encrypted Flow #2:
10.2.1.0/24 <-> 10.2.2.0/24
200.0.0.2/24
200.0.0.4/24
200.1.1.4/30
200.1.1.0/30
.1
.2
.3
.4
Si
IPSec VPN Tunnel #1
IPSec VPN Tunnel #2
10.1.1.0/24 10.2.1.0/24 10.2.2.0/24 10.1.2.0/24
Si
From the Library of Ahmed Aden
ptg12115235
224 Chapter 5: Designing for High Availability
Note that in Example 5-1, trafc is manually shared between two different tunnel termination
endpoints, 200.0.0.2 and 200.0.0.4, by splitting the trafc ows out into separate crypto ACLs, 101
and 102. Let us now look at a conguration example where multiple peers are used, but only for
pure redundancy and no load balancing.
Using the conguration listed in Example 5-2, IPSec_A uses 200.0.0.2 as the destination tunnel
termination address for the encrypted trafc ow specied in crypto ACL 101. If 200.0.0.2 is
unavailable, the crypto engine will use 200.0.0.4 for IPSec peering for trafc matching ACL 101.
Unlike Example 5-1, ACL 101 is congured to match all trafc ows. This results only in IPSec
tunnel termination point redundancyno load sharing is achieved..
Routing
Remember that one key benet of Layer 3 (L3) encryption technologies, like IPSec over Layer 2
(L2) encryption technologies, is that trafc ows can be kept condential and secure over multiple
L2 domains. It is therefore important that the underlying routing protocol between IPSec tunnel
termination endpoints be congured to evenly distribute IPSec trafc 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 trafc distribution across multiple routed paths
between the tunnel termination endpoints.
!!! ! ### #<<< <--- ---- -CCC Crrr ryyy yppp pttt tooo o AAA ACCC CLLL L 111 1000 0222 2 ddd deee efff fiii innn neee esss s ttt thhh heee e fff fiii irrr rsss sttt t eee ennn nccc crrr ryyy yppp pttt teee eddd d ttt trrr raaa afff ffff fiii iccc c fff flll looo owww w... . TTT Trrr raaa afff ffff fiii iccc c
!!! ! mmm maaa attt tccc chhh hiii innn nggg g ttt thhh heee e AAA ACCC CLLL L 111 1000 0444 4 www wiii illl llll l bbb beee e eee ennn nccc crrr ryyy yppp pttt teee eddd d aaa annn nddd d rrr rooo ouuu uttt teee eddd d ttt tooo o 222 2000 0000 0... .000 0... .000 0... .444 4
!!! ! fff fooo orrr r ddd deee eccc crrr ryyy yppp pttt tiii iooo onnn n--- ---- ->>> >
mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0222 2
rrr reee evvv veee errr rsss seee e--- -rrr rooo ouuu uttt teee e
!!! !
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1 ppp peee errr rmmm miii ittt t iii ippp p 111 1000 0... .111 1... .111 1... .000 0 000 0... .000 0... .000 0... .222 2555 5555 5 111 1000 0... .111 1... .222 2... .000 0 000 0... .000 0... .000 0... .222 2555 5555 5
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0222 2 ppp peee errr rmmm miii ittt t iii ippp p 111 1000 0... .222 2... .111 1... .000 0 000 0... .000 0... .000 0... .222 2555 5555 5 111 1000 0... .222 2... .222 2... .000 0 000 0... .000 0... .000 0... .222 2555 5555 5
Example 5-2 Using Multiple Peering Statements for Redundancy Only
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p555 5--- -rrr reee eddd duuu unnn nddd daaa annn nttt t 111 1000 0 iii ippp psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .000 0... .000 0... .222 2
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .000 0... .000 0... .444 4
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -ddd duuu uaaa alll liii innn nttt t
mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
rrr reee evvv veee errr rsss seee e--- -rrr rooo ouuu uttt teee e
!!! !
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1 ppp peee errr rmmm miii ittt t iii ippp p 111 1000 0... .111 1... .111 1... .000 0 000 0... .000 0... .000 0... .222 2555 5555 5 111 1000 0... .111 1... .222 2... .000 0 000 0... .000 0... .000 0... .222 2555 5555 5
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1 ppp peee errr rmmm miii ittt t iii ippp p 111 1000 0... .222 2... .111 1... .000 0 000 0... .000 0... .000 0... .222 2555 5555 5 111 1000 0... .222 2... .222 2... .000 0 000 0... .000 0... .000 0... .222 2555 5555 5
Example 5-1 Using Multiple Peering Statements for Load Balancing and Redundancy (Continued)
From the Library of Ahmed Aden
ptg12115235
Load Balancing, Load Sharing, and High Availability 225
Figure 5-14 Intermediate RP Impact on IPSec Trafc Flow Distribution
Domain Name System (DNS)
IPSec clients can be congured 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 concentrators hostname to a given IP address to be used for Phase 1 and 2 negotiations,
the DNS server would return the rst IP address associated with the concentrators hostname. The
DNS server would then continue to map subsequent resolutions to the other addresses mapped
with the concentrators 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.
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.
Scenario 1 Unbalanced Routed Paths
Scenario 2 Balanced Routed Paths
VPNGW_A VPNGW_C
VPNGW_D VPNGW_B
VPNGW_A
VPNGW_C
VPNGW_D VPNGW_B
Router_A
Router_B
Router_C
Router_D
Router_E
Router_F
Router_E
Router_F
Both paths forced over C and E yield excessive load
over the same physical link. Bandwidth is underutilized
on another available link between D and F.
Ensuring RP metrics forces IPSec traffic over both
available L3 paths andyields more effective utilization
of bandwidth between tunnel termination endpoints.
Router_B Router_D
Router_A Router_C
From the Library of Ahmed Aden
ptg12115235
226 Chapter 5: Designing for High Availability
Figure 5-15 DNS-Based Load Balancing
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 congured DNS server
in order to identify the peer IP address.
2. The DNS server returns the rst IP address in the name record for IPSec_Cluster5, 200.1.1.1
(the rst concentrator in the cluster).
3. IPSec_Client5a initiates an IKE and IPSec SA negotiations with the rst 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 congured DNS server
in order to identify the peer IP address.
1
3
4
5
6
8
7
9
DNS Servers
IPSec_Client5a
IPSec_Client5b
IPSec_Client5c
Outside
DMZ Outside
DMZ Inside
Inside
ISP
IPSec_Cluster5
200.1.1.2 200.1.1.1 200.1.1.3
2
Si Si
Si
Si
Si Si Si
Si
Si
Si
Si
Si
From the Library of Ahmed Aden
ptg12115235
Load Balancing, Load Sharing, and High Availability 227
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 congured 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.
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.
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 congured to intelligently direct
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 conguring 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.
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.
From the Library of Ahmed Aden
ptg12115235
228 Chapter 5: Designing for High Availability
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 rst lets discuss the VCA conguration tasks that must be
accomplished on the VPN3000 to achieve IPSec VPN load balancing within the cluster:
VPN Virtual Cluster IP AddressThis 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 NumberThis 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 SecretVCA 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 BalancingThe load-balancing enable radio button must be checked for the
VPN3000 concentrator to participate in the cluster.
PriorityConcentrators within a cluster are assigned a priority to determine which cluster
will assume the role of the master VCA. The rst 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
From the Library of Ahmed Aden
ptg12115235
Load Balancing, Load Sharing, and High Availability 229
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
VPN Concentrator Model Priority Default
3030 5
3060 7
3080 9
NOTE Remote Access High Availability is discussed more comprehensively in Chapter 9,
RAVPN High Availability, including the detailed conguration of VCA clustering on
VPN3000 series IPSec VPN concentrators and ASA5500 series VPN appliances.
Table 5-1 VPN3000 Priority Default Settings (Continued)
VPN3000_A
VPN3000_B
ISP
VPN3000_C
Si Si
1 1 1
2
2
7 7 7
6
8
4
3
5
From the Library of Ahmed Aden
ptg12115235
230 Chapter 5: Designing for High Availability
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
congured priorities within the cluster as it comes online rst.
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.
From the Library of Ahmed Aden
ptg12115235
Load Balancing, Load Sharing, and High Availability 231
Figure 5-17 Load Balancing IPSec VPN Sessions with External Load Balancers
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 conguration, maintenance, and operation of this solution are all far more
difcult 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 congure
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.
Session #1
Session #2
Session #3
Concentrator_A
Concentrator_B
Concentrator_C
Content
Switch Module
C6509-Edge
7206VXR-VPNA
IPSec_ClientA
IPSec_ClientC
ISP
IPSec_ClientB
7206VXR-VPNB
Si
From the Library of Ahmed Aden
ptg12115235
232 Chapter 5: Designing for High Availability
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 ve 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 ts into the
IPSec HA paradigm.
Load balancing and HA
From the Library of Ahmed Aden
ptg12115235
Summary 233
The ensuing chapters discuss these design concepts in greater detail, including conguration 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.
HA Deployment Option HA Deployment Category
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
Table 5-2 HA Design Summary (Continued)
From the Library of Ahmed Aden
ptg12115235
From the Library of Ahmed Aden
ptg12115235
C H A P T E R
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 conguration. 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 rst 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 Congurations for IPsec HA
Serial0/0 = 200.0.0.2
Serial0/1 = 200.0.0.4
4
6
3
7
4
6
3
7
Network_A
201.1.1.0/24
Router_A Router_B
Network_B
202.1.1.0/24
Redundant ESP Tunnel
ESP
3
6
Primary Link between Se0/0 Fails
Primary Link between Se0/0 Restored
Serial0/1 = 200.0.0.3
Serial0/0 = 200.0.0.1
2
5
1
From the Library of Ahmed Aden
ptg12115235
236 Chapter 6: Solutions for Local Site-to-Site High Availability
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 trafc over the redundant link between Router_A (Se0/1) and Router_B (Se0/1).
3. The trafc 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.
5. When the primary link is restored, the routing protocol on Router_A and Router_B
reconverges such that trafc is now once again routed over the link between Router_A
(Se0/0) and Router_B (Se0/0).
6. The re-routed trafc 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 congure, 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 conguration on Router_A and Router_B must be capable of using matching
preshared keys with both peers. Router_As conguration, 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_As crypto map conguration, also displayed in
Example 6-1, uses redundant peer denitions within the same crypto map. If the rst peer is
unavailable, Router_A will use 200.0.0.4. This conguration is well suited for this environment
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.
From the Library of Ahmed Aden
ptg12115235
Using Multiple Crypto Interfaces for High Availability 237
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).
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
Example 6-1 Local IPsec HA Using Separate Physical Interfaces
Router_A# sss shhh hooo owww w rrr ruuu unnn nnnn niii innn nggg g--- -ccc cooo onnn nfff fiii iggg g
!
!
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
From the Library of Ahmed Aden
ptg12115235
238 Chapter 6: Solutions for Local Site-to-Site High Availability
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 trafc 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.
In some instances, it may make sense to use oating static routes to expedite IPsec local HA even
further. The oating static route approach describes a situation in which a static route is installed
in the conguration 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
oating static route is immediately installed. Additionally, oating 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 oating static routes are commonplace is in highly available
IPsec branch ofces. Figure 6-2 illustrates the failover process of an IPsec HA branch failover
scenario.
Example 6-2 illustrates the conguration of a oating static route on Branch_6A. Note in the
conguration 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 oating 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 oating 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 oating 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_4as routing table.
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.
From the Library of Ahmed Aden
ptg12115235
Using Multiple Crypto Interfaces for High Availability 239
Figure 6-2 Floating Static Routes and IPsec Tunnel Failover
Example 6-2 Using Floating Static Routes for Fast IPsec HA Failover
hhh hooo osss sttt tnnn naaa ammm meee e EEE Ennn nttt t___ _MMM Maaa aiii innn n444 4AAA A
!!! !
!!! !
ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y ccc ciii isss sccc cooo o aaa addd dddd drrr reee esss ssss s 111 1000 0... .111 1... .111 1... .444 4
!!! !
!!! !
continues
Branch4A_Net
10.1.4.0/24
IP IP IP IP IP
Campus_Net
10.0.0.0/16
Ent_Main4A
Branch_4A
M
a
i
n

I
P
S
e
c

T
u
n
n
e
l
S
e
c
o
n
d
a
r
y

I
P
S
e
c

V
P
N

T
u
n
n
e
l
Call
Manager SMTP WWW FTP
Floating Static Route to
Ent_Main4A
Floating Static Route to
Branch_4A
Lo192 = 10.1.1.1/32
Lo192 = 10.1.1.4/32
From the Library of Ahmed Aden
ptg12115235
240 Chapter 6: Solutions for Local Site-to-Site High Availability
Now that we have briey discussed the motivators for using oating 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 oating 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 difcult to scale and manage. While oating 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.
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -hhh haaa aiii innn nttt teee errr rfff faaa accc ceee e 111 1000 0 iii ippp psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -hhh haaa aiii innn nttt teee errr rfff faaa accc ceee e lll looo occc caaa alll l--- -aaa addd dddd drrr reee esss ssss s lll looo oooo oppp pbbb baaa accc ckkk k111 1000 0
sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .444 4
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -hhh haaa aiii innn nttt teee errr rfff faaa accc ceee e
!!! !
!!! !
iii ippp p rrr rooo ouuu uttt teee e 111 1000 0... .111 1... .111 1... .444 4 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5 222 2000 0000 0... .111 1... .111 1... .666 6 222 2555 5444 4
iii ippp p rrr rooo ouuu uttt teee e 111 1000 0... .111 1... .444 4... .000 0 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0 222 2000 0000 0... .111 1... .111 1... .666 6 222 2555 5444 4
hhh hooo osss sttt tnnn naaa ammm meee e BBB Brrr raaa annn nccc chhh h___ _444 4aaa a
!!! !
!!! !
ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y ccc ciii isss sccc cooo o aaa addd dddd drrr reee esss ssss s 111 1000 0... .111 1... .111 1... .111 1
!!! !
!!! !
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -hhh haaa aiii innn nttt teee errr rfff faaa accc ceee e lll looo occc caaa alll l--- -aaa addd dddd drrr reee esss ssss s lll looo oooo oppp pbbb baaa accc ckkk k111 1000 0
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -hhh haaa aiii innn nttt teee errr rfff faaa accc ceee e 111 1000 0 iii ippp psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
sss seee ettt t ppp peee eeee errr r 111 1000 0... .111 1... .111 1... .111 1
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -hhh haaa aiii innn nttt teee errr rfff faaa accc ceee e
!!! !
!!! !
iii ippp p rrr rooo ouuu uttt teee e 000 0... .000 0... .000 0... .000 0 000 0... .000 0... .000 0... .000 0 222 2000 0000 0... .111 1... .111 1... .555 5 222 2555 5444 4
Example 6-2 Using Floating Static Routes for Fast IPsec HA Failover (Continued)
From the Library of Ahmed Aden
ptg12115235
Using Multiple Crypto Interfaces for High Availability 241
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 trafc is forwarded matching a
congured Crypto ACE on that interfaces 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 oating 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.
Example 6-3 illustrates a conguration 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 congured 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.
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 oating 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).
From the Library of Ahmed Aden
ptg12115235
242 Chapter 6: Solutions for Local Site-to-Site High Availability
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, specically
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 condential 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.
Example 6-3 IPsec Tunnel Termination to Highly Available Interfaces
hhh hooo osss sttt tnnn naaa ammm meee e BBB Brrr raaa annn nccc chhh h___ _444 4AAA A
!!! !
!!! !
ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y ccc ciii isss sccc cooo o aaa addd dddd drrr reee esss ssss s 222 2000 0000 0... .111 1... .111 1... .555 5
ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eeee eppp paaa alll liii ivvv veee e 111 1000 0
!!! !
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -hhh haaa aiii innn nttt teee errr rfff faaa accc ceee e lll looo occc caaa alll l--- -aaa addd dddd drrr reee esss ssss s lll looo oooo oppp pbbb baaa accc ckkk k111 1000 0
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -hhh haaa aiii innn nttt teee errr rfff faaa accc ceee e 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .111 1... .111 1... .555 5
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -hhh haaa aiii innn nttt teee errr rfff faaa accc ceee e
mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
From the Library of Ahmed Aden
ptg12115235
Stateless IPsec VPN High-Availability Alternatives 243
Figure 6-3 Stateless Local IPsec High Availability Topology
In any stateless IPsec HA design, there are two key objectives that must be achieved.
Objective 1: Highly Available TerminationThe 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.
Objective 2: Layer-3 Continuity across the IPsec VPN TunnelAs 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
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.
Cleartext Routed Domain B
10.0.0.0/8
192.168.2.0/24
2651XM-VPNB
VPN Gateway
Cleartext Routed Domain A
10.0.0.0/8
2651XM-VPNA
VPN Gateway
192.168.1.0/24
Cleartext Routed Domain D
10.0.0.0//8
C7206VXR-STANDBY
(Standby HSRP Router)
Ciphertext Routed Domain
200.1.0.0/16
C7206VXR-MAIN
(Primary HSRP Router)
HSRP Virtual Interface
Cleartext Routed Domain C
10.0.0.0/8
2651XM-VPNC
VPN Gateway
192.168.3.0/24
IP
S
e
c
V
P
N
T
u
n
n
e
l
IPSec VPN Tunnel
IP
S
e
c
V
P
N
T
u
n
n
e
l
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
Public Routed
Domain
From the Library of Ahmed Aden
ptg12115235
244 Chapter 6: Solutions for Local Site-to-Site High Availability
switching path. Therefore, without GRE, the alternative is Reverse-Route Injection. When an
IPsec VPN gateway is congured 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-2651XMs
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.
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 2651XM-
VPNA, would have the benet of an HSRP-based redundant termination point.
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_sub-
protocol_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 IETFs Virtual Router-Router
Protocol charter:
http://www.ietf.org/html.charters/vrrp-charter.html
From the Library of Ahmed Aden
ptg12115235
Stateless IPsec VPN High-Availability Alternatives 245
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.
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-MAINs routing table. RRI accomplishes this by
inspecting the IP address space to be included in the crypto switching path, as dened by the
crypto ACLs congured on each peer. Remember that in order for an IPsec Phase 2 SA to be
negotiated correctly, the protected address space dened in the ACLs on each peer must match.
C7206VXR-MAIN is congured to redistribute these RRI-learned static routes into the IGP of
cleartext routed domain A.
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 Recall that without the use of IPsec+GRE, multicast trafc, 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 trafc through the VPN
using GRE. This deployment is discussed in greater detail in Chapter 3, Basic IPsec VPN
Topologies and Congurations.
NOTE For more information on protected address space denition and the impact of crypto
ACL mismatches on Phase 2 SA negotiation, refer to Chapter 3, Basic IPsec VPN Topologies
and Congurations.
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
subconguration menu.
From the Library of Ahmed Aden
ptg12115235
246 Chapter 6: Solutions for Local Site-to-Site High Availability
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 condential 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.
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
Cleartext Routed Domain B
10.0.0.0/8
192.168.2.0/24
2651XM-VPNB
VPN Gateway
Cleartext Routed Domain A
10.0.0.0/8
2651XM-VPNA
VPN Gateway
192.168.1.0/24
Cleartext Routed Domain C
10.0.0.0/8
2651XM-VPNC
VPN Gateway
192.168.3.0/24
Cleartext Routed Domain D
10.0.0.0/8
C7206VXR-STANDBY
(Standby HSRP Router)
Ciphertext Routed Domain
200.1.0.0/16
C7206VXR-MAIN
(Primary HSRP Router)
Public Routed
Domain
6
3
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
2
4
5
HSRP Virtual Interfaces
IP
S
e
c
V
P
N
T
u
n
n
e
l
IPSec VPN Tunnel
IP
S
e
c
V
P
N
T
u
n
n
e
l
1
1
1
From the Library of Ahmed Aden
ptg12115235
Stateless IPsec VPN High-Availability Alternatives 247
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 rm decide to deploy stateless HA
at cleartext routed domain D. The conguration of the gateways on domains A, B, and C are
cong-ured normally for site-to-site connectivity, with one exceptionthe remote peer is
dened 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 condential
communications used by domains A, B, and C. Again, the only conguration change required on
the VPN gateways in domains A, B, and C is to dene 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 conguration of an IPsec branch router, 2651XM-VPNA, in the
network topology illustrated in Figure 6-4. The branch router is congured 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
congured 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
conguration 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 Conguration for Stateless IPsec HA
hhh hooo osss sttt tnnn naaa ammm meee e 222 2666 6555 5111 1XXX XMMM M--- -VVV VPPP PNNN NAAA A
!!! !
!!! !
ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eyyy y ccc ciii isss sccc cooo o aaa addd dddd drrr reee esss ssss s 222 2000 0000 0... .111 1... .222 2... .111 1
!!! !
!!! !
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .111 1... .222 2... .111 1
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s
mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
reverse-route
From the Library of Ahmed Aden
ptg12115235
248 Chapter 6: Solutions for Local Site-to-Site High Availability
To support the stateless HA conguration at domain D, HSRP must be congured 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
conguration 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) Conguration on Cleartext
Domain D for Stateless IPsec HA
hhh hooo osss sttt tnnn naaa ammm meee e CCC C777 7222 2000 0666 6VVV VXXX XRRR R--- -MMM MAAA AIII INNN N
!!! !
!!! !
ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eeee eppp paaa alll liii ivvv veee e 111 1000 0
!!! !
!!! !
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s 111 1000 0 iii ippp psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .111 1... .111 1... .111 1
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s
mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
rrr reee evvv veee errr rsss seee e--- -rrr rooo ouuu uttt teee e
!!! !
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s 222 2000 0 iii ippp psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .111 1... .111 1... .555 5
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s
mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0222 2
rrr reee evvv veee errr rsss seee e--- -rrr rooo ouuu uttt teee e
!!! !
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s 333 3000 0 iii ippp psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .111 1... .111 1... .999 9
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s
mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0333 3
rrr reee evvv veee errr rsss seee e--- -rrr rooo ouuu uttt teee e
!!! !
iii innn nttt teee errr rfff faaa accc ceee e FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /000 0
iii ippp p aaa addd dddd drrr reee esss ssss s 222 2000 0000 0... .111 1... .222 2... .111 1111 1 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
iii ippp p ddd diii irrr reee eccc cttt teee eddd d--- -bbb brrr rooo oaaa addd dccc caaa asss sttt t
sss sppp peee eeee eddd d aaa auuu uttt tooo o
hhh haaa alll lfff f--- -ddd duuu uppp plll leee exxx x
sss sttt taaa annn nddd dbbb byyy y 111 1 iii ippp p 222 2000 0000 0... .111 1... .222 2... .111 1
sss sttt taaa annn nddd dbbb byyy y 111 1 ppp prrr reee eeee emmm mppp pttt t
sss sttt taaa annn nddd dbbb byyy y 111 1 nnn naaa ammm meee e ccc chhh haaa appp p666 6--- -vvv vppp pnnn nhhh haaa a
sss sttt taaa annn nddd dbbb byyy y 111 1 ttt trrr raaa accc ckkk k FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /111 1 777 7555 5
!!! !
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1 ppp peee errr rmmm miii ittt t iii ippp p 111 1000 0... .000 0... .000 0... .000 0 222 2555 5555 5... .000 0... .000 0... .000 0 111 1999 9222 2... .111 1666 6888 8... .111 1... .000 0 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0222 2 ppp peee errr rmmm miii ittt t iii ippp p 111 1000 0... .000 0... .000 0... .000 0 222 2555 5555 5... .000 0... .000 0... .000 0 111 1999 9222 2... .111 1666 6888 8... .222 2... .000 0 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0333 3 ppp peee errr rmmm miii ittt t iii ippp p 111 1000 0... .000 0... .000 0... .000 0 222 2555 5555 5... .000 0... .000 0... .000 0 111 1999 9222 2... .111 1666 6888 8... .333 3... .000 0 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s rrr reee eddd duuu unnn nddd daaa annn nccc cyyy y ccc chhh haaa appp p666 6--- -vvv vppp pnnn nhhh haaa a
From the Library of Ahmed Aden
ptg12115235
Stateless IPsec VPN High-Availability Alternatives 249
Example 6-5 provides the conguration 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,
hhh hooo osss sttt tnnn naaa ammm meee e CCC C777 7222 2000 0666 6VVV VXXX XRRR R--- -SSS STTT TAAA ANNN NDDD DBBB BYYY Y
!!! !
!!! !
ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eeee eppp paaa alll liii ivvv veee e 111 1000 0
!!! !
!!! !
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s 111 1000 0 iii ippp psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .111 1... .111 1... .111 1
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s
mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0111 1
rrr reee evvv veee errr rsss seee e--- -rrr rooo ouuu uttt teee e
!!! !
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s 222 2000 0 iii ippp psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .111 1... .111 1... .555 5
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s
mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0222 2
rrr reee evvv veee errr rsss seee e--- -rrr rooo ouuu uttt teee e
!!! !
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s 333 3000 0 iii ippp psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
sss seee ettt t ppp peee eeee errr r 222 2000 0000 0... .111 1... .111 1... .999 9
sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s
mmm maaa attt tccc chhh h aaa addd dddd drrr reee esss ssss s 111 1000 0333 3
rrr reee evvv veee errr rsss seee e--- -rrr rooo ouuu uttt teee e
!!! !
!!! !
iii innn nttt teee errr rfff faaa accc ceee e FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /000 0
iii ippp p aaa addd dddd drrr reee esss ssss s 222 2000 0000 0... .111 1... .222 2... .111 1222 2 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
iii ippp p ddd diii irrr reee eccc cttt teee eddd d--- -bbb brrr rooo oaaa addd dccc caaa asss sttt t
sss sppp peee eeee eddd d aaa auuu uttt tooo o
hhh haaa alll lfff f--- -ddd duuu uppp plll leee exxx x
sss sttt taaa annn nddd dbbb byyy y 111 1 iii ippp p 222 2000 0000 0... .111 1... .222 2... .111 1
sss sttt taaa annn nddd dbbb byyy y 111 1 ppp prrr reee eeee emmm mppp pttt t
sss sttt taaa annn nddd dbbb byyy y 111 1 nnn naaa ammm meee e ccc chhh haaa appp p666 6--- -vvv vppp pnnn nhhh haaa a
ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p666 6--- -sss sttt taaa attt teee elll leee esss ssss s rrr reee eddd duuu unnn nddd daaa annn nccc cyyy y ccc chhh haaa appp p666 6--- -vvv vppp pnnn nhhh haaa a
!!! !
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0111 1 ppp peee errr rmmm miii ittt t iii ippp p 111 1000 0... .000 0... .000 0... .000 0 222 2555 5555 5... .000 0... .000 0... .000 0 111 1999 9222 2... .111 1666 6888 8... .111 1... .000 0 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0222 2 ppp peee errr rmmm miii ittt t iii ippp p 111 1000 0... .000 0... .000 0... .000 0 222 2555 5555 5... .000 0... .000 0... .000 0 111 1999 9222 2... .111 1666 6888 8... .222 2... .000 0 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
aaa accc cccc ceee esss ssss s--- -lll liii isss sttt t 111 1000 0333 3 ppp peee errr rmmm miii ittt t iii ippp p 111 1000 0... .000 0... .000 0... .000 0 222 2555 5555 5... .000 0... .000 0... .000 0 111 1999 9222 2... .111 1666 6888 8... .333 3... .000 0 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
Example 6-5 Aggregator (C7206VXR-MAIN and C7206VXR-STANDBY) Conguration on Cleartext
Domain D for Stateless IPsec HA (Continued)
From the Library of Ahmed Aden
ptg12115235
250 Chapter 6: Solutions for Local Site-to-Site High Availability
C7206VXR-STANDBY. Line 4 of the conguration enables the use of IKE keepalives on
C7206VXR-MAIN. IKE keepalives are also congured on C7206VXR-STANDBY, as shown in
line 42 of the conguration, 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 2651XM-
VPNA, 2651XM-VPNB, and 2651XM-VPNC must be congured to use this interface to take
advantage of the stateless IPsec HA conguration 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 benets of HSRP-based
stateless IPsec HA. The crypto map, chap6-stateless, is applied to the physical interface
congured for redundancy with HSRP. Note that this interface is congured to automatically
inject routing information backwards in to cleartext routed domain D using RRI.
Example 6-5 also includes the conguration for the redundant router providing stateless IPsec HA,
C7206VXR-STANDBY. C7206VXR-STANDBYs 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 congured for redundancy using HSRP is located on the same subnet as
C7206VXR-MAIN. Many of the HSRP and IPsec parameters congured 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
congurationC7206VXR-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.
From the Library of Ahmed Aden
ptg12115235
Stateless IPsec VPN High-Availability Alternatives 251
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 congured 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 conrmed to be operating correctly, as shown in lines 116 of Example 6-6. As
C7206VXR-MAIN is the active HSRP router (conrmed 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 congured to preempt), it will take over as the active router for the
HSRP group, as its priority of 50 is greater than C7206VXR-MAINs new priority of 25. Also,
C7206VXR-STANDBY will also take over as the IPsec tunnel termination point for 2651XM-
VPNA, 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 conrm 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
CCC C777 7222 2000 0666 6VVV VXXX XRRR R--- -MMM MAAA AIII INNN N### #sss shhh hooo owww w sss sttt taaa annn nddd dbbb byyy y
FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /000 0 --- - GGG Grrr rooo ouuu uppp p 111 1
SSS Sttt taaa attt teee e iii isss s AAA Accc cttt tiii ivvv veee e
111 1444 4 sss sttt taaa attt teee e ccc chhh haaa annn nggg geee esss s,,, , lll laaa asss sttt t sss sttt taaa attt teee e ccc chhh haaa annn nggg geee e 222 2ddd d111 1333 3hhh h
VVV Viii irrr rttt tuuu uaaa alll l III IPPP P aaa addd dddd drrr reee esss ssss s iii isss s 222 2000 0000 0... .111 1... .222 2... .111 1
AAA Accc cttt tiii ivvv veee e vvv viii irrr rttt tuuu uaaa alll l MMM MAAA ACCC C aaa addd dddd drrr reee esss ssss s iii isss s 000 0000 0000 0000 0... .000 0ccc c000 0777 7... .aaa accc c000 0111 1
LLL Looo occc caaa alll l vvv viii irrr rttt tuuu uaaa alll l MMM MAAA ACCC C aaa addd dddd drrr reee esss ssss s iii isss s 000 0000 0000 0000 0... .000 0ccc c000 0777 7... .aaa accc c000 0111 1 ((( (vvv v111 1 ddd deee efff faaa auuu ulll lttt t))) )
HHH Heee elll llll looo o ttt tiii immm meee e 333 3 sss seee eccc c,,, , hhh hooo olll lddd d ttt tiii immm meee e 111 1000 0 sss seee eccc c
NNN Neee exxx xttt t hhh heee elll llll looo o sss seee ennn nttt t iii innn n 000 0... .222 2777 7666 6 sss seee eccc csss s
PPP Prrr reee eeee emmm mppp pttt tiii iooo onnn n eee ennn naaa abbb blll leee eddd d
continues
From the Library of Ahmed Aden
ptg12115235
252 Chapter 6: Solutions for Local Site-to-Site High Availability
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 conguration 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 trafc 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 congured 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 dened 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 dened in the crypto
map. This is conrmed by the insertion of the VPN (or RRI-learned) route being added (conrmed
by line 5) without any IPsec SAs actively present in the SADB (confirmed by lines 1013).
AAA Accc cttt tiii ivvv veee e rrr rooo ouuu uttt teee errr r iii isss s lll looo occc caaa alll l
SSS Sttt taaa annn nddd dbbb byyy y rrr rooo ouuu uttt teee errr r iii isss s 222 2000 0000 0... .111 1... .222 2... .111 1222 2,,, , ppp prrr riii iooo orrr riii ittt tyyy y 555 5000 0 ((( (eee exxx xppp piii irrr reee esss s iii innn n 777 7... .888 8444 4000 0 sss seee eccc c))) )
PPP Prrr riii iooo orrr riii ittt tyyy y 111 1000 0000 0 ((( (ddd deee efff faaa auuu ulll lttt t 111 1000 0000 0))) )
TTT Trrr raaa accc ckkk k iii innn nttt teee errr rfff faaa accc ceee e FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /111 1 sss sttt taaa attt teee e UUU Uppp p ddd deee eccc crrr reee emmm meee ennn nttt t 777 7555 5
TTT Trrr raaa accc ckkk k iii innn nttt teee errr rfff faaa accc ceee e LLL Looo oooo oppp pbbb baaa accc ckkk k111 1000 0 sss sttt taaa attt teee e UUU Uppp p ddd deee eccc crrr reee emmm meee ennn nttt t 777 7555 5
III IPPP P rrr reee eddd duuu unnn nddd daaa annn nccc cyyy y nnn naaa ammm meee e iii isss s ccc chhh haaa appp p666 6--- -vvv vppp pnnn nhhh haaa a ((( (ccc cfff fggg gddd d))) )
CCC C777 7222 2000 0666 6VVV VXXX XRRR R--- -MMM MAAA AIII INNN N### #sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn nsss s aaa accc cttt tiii ivvv veee e
III IDDD D III Innn nttt teee errr rfff faaa accc ceee e III IPPP P--- -AAA Addd dddd drrr reee esss ssss s SSS Sttt taaa attt teee e AAA Alll lggg gooo orrr riii ittt thhh hmmm m EEE Ennn nccc crrr ryyy yppp pttt t DDD Deee eccc crrr ryyy yppp pttt t
888 8 FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /000 0 222 2000 0000 0... .111 1... .222 2... .111 1111 1 sss seee ettt t HHH HMMM MAAA ACCC C___ _SSS SHHH HAAA A+++ +333 3DDD DEEE ESSS S___ _555 5666 6___ _CCC C 000 0 000 0
222 2000 0000 0111 1 FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /000 0 222 2000 0000 0... .111 1... .222 2... .111 1 sss seee ettt t 333 3DDD DEEE ESSS S+++ +SSS SHHH HAAA A 444 4 000 0
222 2000 0000 0222 2 FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /000 0 222 2000 0000 0... .111 1... .222 2... .111 1 sss seee ettt t 333 3DDD DEEE ESSS S+++ +SSS SHHH HAAA A 000 0 444 4
CCC C777 7222 2000 0666 6VVV VXXX XRRR R--- -MMM MAAA AIII INNN N### #
Example 6-7 Verifying RRI for Domain A: RRI with Static Crypto Maps on 2651XM-VPNA
222 2666 6555 5111 1XXX XMMM M--- -VVV VPPP PNNN NAAA A### #ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o iii ippp psss seee eccc c
CCC Crrr ryyy yppp pttt tooo o III IPPP PSSS SEEE ECCC C ddd deee ebbb buuu uggg gggg giii innn nggg g iii isss s ooo onnn n
!!! !
!!! !
Example 6-6 C7206VXR-MAIN IPsec SADB before HSRP Failover (Continued)
From the Library of Ahmed Aden
ptg12115235
Stateless IPsec VPN High-Availability Alternatives 253
Example 6-8 shows the required conguration 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 As 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 congured on
C7206VXR-MAIN, but the crypto SADB and IP routing table are both empty, as conrmed 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 trafc 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 conrmed 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 trafc 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.
*** *MMM Maaa arrr r 333 3 000 0888 8::: :111 1666 6::: :111 1333 3... .999 9666 6222 2::: : III IPPP PSSS SEEE ECCC C((( (rrr rttt teee e___ _mmm mggg grrr r))) )::: : VVV VPPP PNNN N RRR Rooo ouuu uttt teee e AAA Addd dddd deee eddd d 111 1000 0... .000 0... .000 0... .000 0 222 2555 5555 5... .000 0... .000 0... .000 0 vvv viii iaaa a 222 2000 0000 0... .111 1... .222 2... .111 1 iii innn n
III IPPP P DDD DEEE EFFF FAAA AUUU ULLL LTTT T TTT TAAA ABBB BLLL LEEE E
!!! !
!!! !
222 2666 6555 5111 1XXX XMMM M--- -VVV VPPP PNNN NAAA A### #sss shhh h iii ippp p rrr rooo ouuu uttt teee e sss sttt taaa attt tiii iccc c
SSS S 111 1000 0... .000 0... .000 0... .000 0/// /888 8 [[[ [111 1/// /000 0]]] ] vvv viii iaaa a 222 2000 0000 0... .111 1... .222 2... .111 1
222 2666 6555 5111 1XXX XMMM M--- -VVV VPPP PNNN NAAA A### #sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn nsss s aaa accc cttt tiii ivvv veee e
III IDDD D III Innn nttt teee errr rfff faaa accc ceee e III IPPP P--- -AAA Addd dddd drrr reee esss ssss s SSS Sttt taaa attt teee e AAA Alll lggg gooo orrr riii ittt thhh hmmm m EEE Ennn nccc crrr ryyy yppp pttt t DDD Deee eccc crrr ryyy yppp pttt t
222 2666 6555 5111 1XXX XMMM M--- -VVV VPPP PNNN NAAA A### #
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
CCC C777 7222 2000 0666 6VVV VXXX XRRR R--- -MMM MAAA AIII INNN N### #sss shhh h ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn nsss s aaa accc cttt tiii ivvv veee e
III IDDD D III Innn nttt teee errr rfff faaa accc ceee e III IPPP P--- -AAA Addd dddd drrr reee esss ssss s SSS Sttt taaa attt teee e AAA Alll lggg gooo orrr riii ittt thhh hmmm m EEE Ennn nccc crrr ryyy yppp pttt t DDD Deee eccc crrr ryyy yppp pttt t
CCC C777 7222 2000 0666 6VVV VXXX XRRR R--- -MMM MAAA AIII INNN N### #sss shhh hooo owww w iii ippp p rrr rooo ouuu uttt teee e sss sttt taaa attt tiii iccc c
continues
Example 6-7 Verifying RRI for Domain A: RRI with Static Crypto Maps on 2651XM-VPNA (Continued)
From the Library of Ahmed Aden
ptg12115235
254 Chapter 6: Solutions for Local Site-to-Site High Availability
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 congured 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 reconguration 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
C7206VXR-MAIN#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o iii ippp psss seee eccc c
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#sss shhh h ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn nsss s aaa accc cttt tiii ivvv veee e
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#sss shhh hooo owww w iii ippp p rrr rooo ouuu uttt teee e sss sttt taaa attt tiii iccc c
S 192.168.1.0/24 [1/0] via 200.1.1.1
Example 6-8 Verifying RRI for Domain A: DRI with Static Crypto Maps on C7206VXR-MAIN (Continued)
From the Library of Ahmed Aden
ptg12115235
Stateless IPsec VPN High-Availability Alternatives 255
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 predened timers:
Hello TimerThe amount of time between transmissions of HSRP hello messages.
Hold TimerThe 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 conguration 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.
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-MAINs SADB, C7206VXR-STANDBY must therefore
rebuild the ISAKMP and IPsec SAs in its own SADB after HSRP has reconverged.
Example 6-9 HSRP Tuning Example for Optimal Stateless IPsec HA Reconvergence.
C7206VXR-MAIN#
C7206VXR-MAIN(config)#iii innn nttt teee errr rfff faaa accc ceee e fff faaa a000 0/// /000 0
C7206VXR-MAIN(config-if)#sss sttt taaa annn nddd dbbb byyy y 111 1 ttt tiii immm meee errr rsss s mmm msss seee eccc c 333 3000 0 mmm msss seee eccc c 111 1000 0000 0
CAUTION Tuning HSRP timers for subsecond reconvergence upon failover greatly increases
the amount of HSRP trafc 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
ux 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 congure hold timer window.
From the Library of Ahmed Aden
ptg12115235
256 Chapter 6: Solutions for Local Site-to-Site High Availability
Again, there is no manual intervention or conguration change required on any of the IPsec peers
for this particular failover scenario to completeit is done dynamically once trafc 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 unaccept-
ably 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.
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 elds 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 conrming 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 conrms 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 conrms that C7206VXR-
STANDBYs Fa0/0 interface is the current active HSRP interface for the group. Also conrmed
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-STANDBYs SADB. Like
C7206VXR-MAIN, C7206VXR-STANDBY is also congured 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.
TIP Even if IKE keepalives are used, the lowest congurable 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 10s/keepalive interval).
Example 6-10 C7206VXR-STANDBY IPsec SADB after HSRP Failover
C7206VXR-STANDBY#ddd deee ebbb buuu uggg g sss sttt taaa annn nddd dbbb byyy y eee evvv veee ennn nttt tsss s
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
From the Library of Ahmed Aden
ptg12115235
Stateful IPsec VPN High-Availability Alternatives 257
Step 6: Post-HSRP RRI Execution
The nal 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 gateways 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.
*** *JJJ Juuu ulll l 111 1333 3 111 1999 9::: :444 4777 7::: :333 3777 7... .111 1999 9111 1::: : HHH HSSS SRRR RPPP P::: : FFF Faaa a000 0/// /000 0 GGG Grrr rppp p 111 1 SSS Sttt taaa annn nddd dbbb byyy y --- ->>> > AAA Accc cttt tiii ivvv veee e
*** *JJJ Juuu ulll l 111 1333 3 111 1999 9::: :444 4777 7::: :333 3777 7... .111 1999 9111 1::: : %%% %HHH HSSS SRRR RPPP P--- -666 6--- -SSS STTT TAAA ATTT TEEE ECCC CHHH HAAA ANNN NGGG GEEE E::: : FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /000 0 GGG Grrr rppp p 111 1 sss sttt taaa attt teee e SSS Sttt taaa annn nddd dbbb byyy y --- ->>> > AAA Accc cttt tiii ivvv veee e
*** *JJJ Juuu ulll l 111 1333 3 111 1999 9::: :444 4777 7::: :333 3777 7... .111 1999 9111 1::: : HHH HSSS SRRR RPPP P::: : FFF Faaa a000 0/// /000 0 GGG Grrr rppp p 111 1 RRR Reee eddd duuu unnn nddd daaa annn nccc cyyy y ccc chhh haaa appp p666 6--- -vvv vppp pnnn nhhh haaa a sss sttt taaa attt teee e SSS Sttt taaa annn nddd dbbb byyy y --- ->>> > AAA Accc cttt tiii ivvv veee e
*** *JJJ Juuu ulll l 111 1333 3 111 1999 9::: :444 4777 7::: :444 4000 0... .111 1999 9111 1::: : HHH HSSS SRRR RPPP P::: : FFF Faaa a000 0/// /000 0 GGG Grrr rppp p 111 1 RRR Reee eddd duuu unnn nddd daaa annn nccc cyyy y ggg grrr rooo ouuu uppp p ccc chhh haaa appp p666 6--- -vvv vppp pnnn nhhh haaa a sss sttt taaa attt teee e AAA Accc cttt tiii ivvv veee e --- ->>> > AAA Accc cttt tiii ivvv veee e
*** *JJJ Juuu ulll l 111 1333 3 111 1999 9::: :444 4777 7::: :444 4333 3... .111 1999 9111 1::: : HHH HSSS SRRR RPPP P::: : FFF Faaa a000 0/// /000 0 GGG Grrr rppp p 111 1 RRR Reee eddd duuu unnn nddd daaa annn nccc cyyy y ggg grrr rooo ouuu uppp p ccc chhh haaa appp p666 6--- -vvv vppp pnnn nhhh haaa a sss sttt taaa attt teee e AAA Accc cttt tiii ivvv veee e --- ->>> > AAA Accc cttt tiii ivvv veee e
CCC C777 7222 2000 0666 6VVV VXXX XRRR R--- -SSS STTT TAAA ANNN NDDD DBBB BYYY Y### #sss shhh h sss sttt taaa annn nddd d
FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /000 0 --- - GGG Grrr rooo ouuu uppp p 111 1
SSS Sttt taaa attt teee e iii isss s AAA Accc cttt tiii ivvv veee e
111 1444 4 sss sttt taaa attt teee e ccc chhh haaa annn nggg geee esss s,,, , lll laaa asss sttt t sss sttt taaa attt teee e ccc chhh haaa annn nggg geee e 000 0000 0::: :000 0000 0::: :444 4111 1
VVV Viii irrr rttt tuuu uaaa alll l III IPPP P aaa addd dddd drrr reee esss ssss s iii isss s 222 2000 0000 0... .111 1... .222 2... .111 1
AAA Accc cttt tiii ivvv veee e vvv viii irrr rttt tuuu uaaa alll l MMM MAAA ACCC C aaa addd dddd drrr reee esss ssss s iii isss s 000 0000 0000 0000 0... .000 0ccc c000 0777 7... .aaa accc c000 0111 1
LLL Looo occc caaa alll l vvv viii irrr rttt tuuu uaaa alll l MMM MAAA ACCC C aaa addd dddd drrr reee esss ssss s iii isss s 000 0000 0000 0000 0... .000 0ccc c000 0777 7... .aaa accc c000 0111 1 ((( (vvv v111 1 ddd deee efff faaa auuu ulll lttt t))) )
HHH Heee elll llll looo o ttt tiii immm meee e 333 3 sss seee eccc c,,, , hhh hooo olll lddd d ttt tiii immm meee e 111 1000 0 sss seee eccc c
NNN Neee exxx xttt t hhh heee elll llll looo o sss seee ennn nttt t iii innn n 000 0... .444 4333 3666 6 sss seee eccc csss s
PPP Prrr reee eeee emmm mppp pttt tiii iooo onnn n eee ennn naaa abbb blll leee eddd d
AAA Accc cttt tiii ivvv veee e rrr rooo ouuu uttt teee errr r iii isss s lll looo occc caaa alll l
SSS Sttt taaa annn nddd dbbb byyy y rrr rooo ouuu uttt teee errr r iii isss s uuu unnn nkkk knnn nooo owww wnnn n
PPP Prrr riii iooo orrr riii ittt tyyy y 555 5000 0 ((( (ccc cooo onnn nfff fiii iggg guuu urrr reee eddd d 555 5000 0))) )
III IPPP P rrr reee eddd duuu unnn nddd daaa annn nccc cyyy y nnn naaa ammm meee e iii isss s ccc chhh haaa appp p666 6--- -vvv vppp pnnn nhhh haaa a ((( (ccc cfff fggg gddd d))) )
Example 6-10 C7206VXR-STANDBY IPsec SADB after HSRP Failover (Continued)
From the Library of Ahmed Aden
ptg12115235
258 Chapter 6: Solutions for Local Site-to-Site 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, 2651XM-
VPNB, 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
Stateful Switchover communicates SADB state of the active router SADB
to the failover router prior to failover, precluding the need to re-negotiate
SAs when the system reconverges from VPN gateway failure.
Cleartext Routed Domain D
10.0.0.0/8
C7206VXR-STANDBY
(Standby HSRP Router)
C7206VXR-MAIN
(Primary HSRP Router)
Cleartext Routed Domain A
10.0.0.0/8
2651XM-VPNA1
Active Gateway
2651XM-VPNA2
Standby Gateway
192.168.1.0/24
Public Routed Domain
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
3
4 2
3
2 4
10.0.0.0/8
2651XM-VPNC1
Active Gateway
2651XM-VPNC2
Standby Gateway
192.168.3.0/24
Cleartext Routed Domain C
Cleartext Routed Domain B
10.0.0.0/8
2651XM-VPNB1
Active Gateway
2651XM-VPNB2
Standby Gateway
192.168.2.0/24
2
IP
S
e
c
V
P
N
T
u
n
n
e
l
HSRP Virtual Interfaces
IPSec VPN Tunnel 1
IP
S
e
c
V
P
N
T
u
n
n
e
l
1
1
Ciphertext Routed Domain
200.1.0.0/16
From the Library of Ahmed Aden
ptg12115235
Stateful IPsec VPN High-Availability Alternatives 259
The following list briey 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 rst, 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 congurations 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 congured 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 congured 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
From the Library of Ahmed Aden
ptg12115235
260 Chapter 6: Solutions for Local Site-to-Site High Availability
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 congured by SSO and are therefore available on the redundant peer prior to failover.
By default, SSO uses the standards-based Stream Control Transmission Protocol (SCTP), dened
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 reected 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 gateways 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) congurations
is the conguration of SSO to communicate the SADB state between active and redundant IPsec
VPN gateways prior to a convergence event taking place. Conguration 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 conguration 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.
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.
Example 6-11 SSO Conguration on C7206VXR-MAIN (Figure 6-5)
CCC C777 7222 2000 0666 6VVV VXXX XRRR R--- -MMM MAAA AIII INNN N### #sss shhh hooo owww w rrr ruuu unnn nnnn niii innn nggg g--- -ccc cooo onnn nfff fiii iggg g
!!! !
!!! !
rrr reee eddd duuu unnn nddd daaa annn nccc cyyy y iii innn nttt teee errr r--- -ddd deee evvv viii iccc ceee e
sss sccc chhh heee emmm meee e sss sttt taaa annn nddd dbbb byyy y ccc chhh haaa appp p666 6--- -vvv vppp pnnn nhhh haaa a
!!! !
iii ippp pccc c zzz zooo onnn neee e ddd deee efff faaa auuu ulll lttt t
From the Library of Ahmed Aden
ptg12115235
Stateful IPsec VPN High-Availability Alternatives 261
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 rst 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 routers 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
aaa asss ssss sooo occc ciii iaaa attt tiii iooo onnn n 666 6
nnn nooo o sss shhh huuu uttt tddd dooo owww wnnn n
ppp prrr rooo ottt tooo occc cooo olll l sss sccc cttt tppp p
lll looo occc caaa alll l--- -ppp pooo orrr rttt t 666 6666 6666 6666 6
lll looo occc caaa alll l--- -iii ippp p 222 2000 0000 0... .111 1... .222 2... .111 1111 1
rrr reee ettt trrr raaa annn nsss smmm miii ittt t--- -ttt tiii immm meee eooo ouuu uttt t 222 2000 0000 0 555 5000 0000 0000 0
ppp paaa attt thhh h--- -rrr reee ettt trrr raaa annn nsss smmm miii ittt t 111 1000 0
aaa asss ssss sooo occc c--- -rrr reee ettt trrr raaa annn nsss smmm miii ittt t 222 2000 0
rrr reee emmm mooo ottt teee e--- -ppp pooo orrr rttt t 666 6666 6666 6666 6
rrr reee emmm mooo ottt teee e--- -iii ippp p 222 2000 0000 0... .111 1... .222 2... .111 1222 2
Example 6-11 SSO Conguration on C7206VXR-MAIN (Figure 6-5) (Continued)
From the Library of Ahmed Aden
ptg12115235
262 Chapter 6: Solutions for Local Site-to-Site High Availability
in the stateless HA design summary, sharing of the SADB state using SSO eliminates failover
delay attributable to IPsec reconvergence.
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 reconver-
gence 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 rst 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 reconver-
gence 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.
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.
From the Library of Ahmed Aden
ptg12115235
Summary 263
Step 7: Post-HSRP RRI Execution
Once the standby IPsec VPN gateway assumes the crypto forwarding responsibilities for trafc
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 strategies
stateful 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 oating 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).
We also discussed the benets 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
From the Library of Ahmed Aden
ptg12115235
264 Chapter 6: Solutions for Local Site-to-Site High Availability
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.
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 groups 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
signicant 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.
From the Library of Ahmed Aden
ptg12115235
Summary 265
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 benets 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 congured 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.
Design
Consideration
Use of Redundant Paths and
Interfaces
Stateless HSRP-Based IPsec
Tunnel Termination
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 oating
static routes can be congured 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.
Table 6-1 Summary Design Considerations for Stateless IPsec HA (Continued)
From the Library of Ahmed Aden
ptg12115235
From the Library of Ahmed Aden
ptg12115235
C H A P T E R
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 specic 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
From the Library of Ahmed Aden
ptg12115235
268 Chapter 7: Solutions for Geographic Site-to-Site High Availability
across an untrusted intermediate network using an IPsec VPN tunnel for data condentiality,
authenticity, integrity, and nonrepudiation, RRI can be congured 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
The following is an explanation of the steps illustrated in Figure 7-1:
1. Host-A on Network A sends trafc to Server-B on Network B, using a default route injected
in to the network by C3845ISR-A. This trafc ow 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 congured 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 congured 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 trafc such as the RP trafc 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.
4
3
2
3
4
5
6
EIGRP AS 10
WAN
200.1.1.0/24
OSPF 10
Network_A
192.168.1.0/24
EIGRP AS 10
Network_B
192.168.2.0/24
C3845ISR-A
200.1.1.1 200.1.1.2
C3845ISR-B
Host-A
Server-B
RRI-Learned Route: 192.168.2.0/24
Next Hop: 200.1.1.2
RRI-Learned Route: 192.168.1.0/24
Next Hop: 200.1.1.1
1
From the Library of Ahmed Aden
ptg12115235
Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers 269
5. After both RPs have converged to include the RRI-learned routes, C3845ISR-A uses the static
route learned by RRI to forward trafc to Server-B to the next hop address of the IPsec VPN
peer on C3845ISR-B. C3845ISR-B receives the trafc from C3845ISR-A and forwards it to
Server-B, using a route learned by Network_Bs IGP.
6. Server-B forwards the return trafc to C3845ISR-B. C3845ISR-B uses the static route in its
routing table learned via RRI in step 3 to forward the return trafc from Server-B to the next
hop address of the IPsec VPN tunnel peer IP address on C3845ISR-A. C3845ISR-A receives
the return trafc from C3745ISR-B and forwards it to Host_A using a route learned by
Network_Bs IGP.
This process illustrates dynamic RRI in a basic geographic site-to-site IPsec VPN example. As
well 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 conguration and verication 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 conguration tasks relevant to successful RRI
implementation. C3845ISR-A is congured 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-As IP). These routes will be injected only after an IPsec SA
is present in the C3845ISR-Bs 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-specic 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 dened in the crypto map, 200.1.1.2 (Example 7-1, line 6).
Example 7-1 Simple Site-to-Site RRI (Dynamic) Conguration on C3845ISR-A from Figure 7-1
1 C3845ISR-A#sss shhh hooo owww w rrr ruuu unnn nnnn niii innn nggg g--- -ccc cooo onnn nfff fiii iggg g
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
continues
From the Library of Ahmed Aden
ptg12115235
270 Chapter 7: Solutions for Geographic Site-to-Site High Availability
Like C3845ISR-A in Example 7-1, C3845ISR-B is congured 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-As IP). Because the router is congured for dynamic RRI
(Example 7-2, line 9), these routes will be injected only after an IPsec SA is present in the
C3845ISR-Bs 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-specic
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.
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
Example 7-2 Simple Site-to-Site RRI (Dynamic) Conguration on C3845ISR-B from Figure 7-1
1 C3845ISR-B#sss shhh h rrr ruuu unnn n
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
Example 7-1 Simple Site-to-Site RRI (Dynamic) Conguration on C3845ISR-A from Figure 7-1 (Continued)
From the Library of Ahmed Aden
ptg12115235
Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers 271
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 trafc ow triggering the IPsec VPN
tunnel negotiation uses a predened default route injected by C3845ISR-A. In the above process,
a predened 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 predened default route injected in step 1. Examples 7-3 and 7-4 illustrate the
conguration and verication of static RRI respectively.
Example 7-1, lines 5-9, dene 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 denes the trafc 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 congured 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
verication). EIGRP AS 10 is congured 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 dened specic to
the redistribute static command, or with the default-metric command as listed below. ACL 101
denes the trafc to be included in the crypto switching path. RRI will use the destination IP
address of the crypto ACL dened in the ACL to populate the RRI static route destination in
the routing table. RRI will use the IPsec peer dened in the crypto map as the next-hop IP for
this route.
CAUTION Static RRI injects a route before the establishment of a Phase 2 SA, which
provides a way for interesting trafc 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), trafc 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.
From the Library of Ahmed Aden
ptg12115235
272 Chapter 7: Solutions for Geographic Site-to-Site High Availability
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-3 Static RRI Conguration
1 C3845ISR-A#sss shhh h rrr ruuu unnn n
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
Example 7-4 Static RRI Verication
1 C3845ISR-A(config)#ccc crrr ryyy yppp pttt tooo o mmm maaa appp p ccc chhh haaa appp p777 7--- -rrr rrrr riii i--- -111 1 111 1000 0 III IPPP Psss seee eccc c--- -iii isss saaa akkk kmmm mppp p
2 C3845ISR-A(config-crypto-map)#rrr reee evvv veee errr rsss seee e--- -rrr rooo ouuu uttt teee e sss sttt taaa attt tiii iccc c
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p sss saaa a
5 dst src state conn-id slot
6
7 C3845ISR-A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c sss saaa a
8
9 interface: Ethernet0/0
10 Crypto map tag: chap7-rri-1, local addr. 200.1.1.1
11
12 protected vrf:
From the Library of Ahmed Aden
ptg12115235
Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers 273
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.
Weve discussed how this can be done without the use of routing protocol exchanges across the
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn nsss s aaa accc cttt tiii ivvv veee e
39
40 ID Interface IP-Address State Algorithm Encrypt Decrypt
41 C3845ISR-A#sss shhh hooo owww w iii ippp p rrr rooo ouuu uttt teee e sss sttt taaa attt tiii iccc c
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.
Example 7-4 Static RRI Verication (Continued)
From the Library of Ahmed Aden
ptg12115235
274 Chapter 7: Solutions for Geographic Site-to-Site High Availability
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 denitions 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 denition 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_As 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
The redundancy added by dening multiple peers on IPsec VPN gateway C3845ISR-A does not
radically change the RRI processes weve 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 dened, 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 dened, in which
C3845ISR-A attempts to do per-packet load balancing between multiple next-hops (peers) for the
same RRI-learned route. Two peers dened 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 dened peers, 200.1.1.2
EIGRP AS 10
Network_A
192.168.1.0/24
C3845ISR-C
C3845ISR-B
C3845ISR-A
Host-A
EIGRP AS 10
Network_B
192.168.2.0/24
Server-B
6/7
OSPF 10
WAN
200.1.1.0/24
2
2
5
8
9
1
3
4
1
1
3
6/7
4
200.1.1.1
200.1.1.2
200.1.1.3
RRI-Learned Route: 192.168.2.0/24
Next Hop: 200.1.1.2
RRI-Learned Route: 192.168.1.0/24
Next Hop: 200.1.1.1
RRI-Learned Route: 192.168.1.0/24
Next Hop: 200.1.1.1
RRI-Learned Route: 192.168.2.0/24
Next Hop: 200.1.1.2
200.1.1.3
From the Library of Ahmed Aden
ptg12115235
Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers 275
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 trafc forwarded to the invalid peer is subsequently dropped). The connection
entries in the crypto engine reect the packet loss described above. Only half of the fty 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.
The behavior of Example 7-5 will lead to other unexpected behavior, potentially including the
black holing of valid IP trafc to the inactive peer IP address. In order to avoid this behavior,
Example 7-5 Static RRI with Multiple IPsec Peering Statements
1 Host-A#ppp piii innn nggg g
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#sss shhh hooo owww w rrr ruuu unnn nnnn niii innn nggg g--- -ccc cooo onnn nfff fiii iggg g
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#sss shhh hooo owww w iii ippp p rrr rooo ouuu uttt teee e sss sttt taaa attt t
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn nsss s aaa accc cttt tiii ivvv veee e
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
From the Library of Ahmed Aden
ptg12115235
276 Chapter 7: Solutions for Geographic Site-to-Site High Availability
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 denitions 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 trafc 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 denition (C3845ISR-C).
6. C3845ISR-A and C are both congured 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 dened in the crypto ACLs is reected and populated in the IPsec SADB.
7. C3845ISR-A and C are congured 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 trafc to Server-B to the next hop address of the IPsec VPN
peer on C3845ISR-C. C3845ISR-C receives the trafc from C3845ISR-A and forwards it to
Server-B, using a route learned by Network_Bs IGP.
9. Server-B forwards the return trafc to C3845ISR-C. C3845ISR-C uses the static route in its
routing table learned via RRI in step 3 to forward the return trafc from Server-B to the next
hop address of the IPsec VPN tunnel peer IP address on C3845ISR-A. C3845ISR-A receives
the return trafc from C3745-C and forwards it to Host_A using a route learned by
Network_Bs 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
congurations for the HA design illustrated in Figure 7-2 using RRI with Multiple IPsec Peer
From the Library of Ahmed Aden
ptg12115235
Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers 277
denitions on C3785-A. The successful reconvergence process described above is veried using
the diagnostic commands included in Example 7-7.
The crypto map in Example 7-7 is congured with redundant peers. Dynamic RRI is congured
under the crypto map, injecting static routes for the destination IP address congured 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 dened in crypto ACL 101 (192.168.2.0/24) to populate the static routing table
upon successful creation of a Phase 2 SA.
As conrmed 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 conguration of Example 7-6 would populate
the routing table with a static route regardless of the state of C3845ISR-As 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 routes next hop. IPsec SAs are
now conrmed to exist in C3845ISRs SADB, as shown by the diagnostic output pertaining to
C3845ISR-As 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) dened in crypto ACL 101 and
the IPsec peer address used in the Phase 2 SA (200.1.1.2).
Example 7-6 C3845ISR-A Conguration Using Dynamic RRI with Multiple IPsec Peer Denitions
1 C3845ISR-A#sss shhh hooo owww w rrr ruuu unnn nnnn niii innn nggg g--- -ccc cooo onnn nfff fiii iggg g
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
Example 7-7 Verifying C3845ISR VPN Failover with Dynamic RRI and Multiple IPsec Peer
Denitions
1 C3845ISR-A#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn nsss s aaa accc cttt tiii ivvv veee e
2
3 ID Interface IP-Address State Algorithm Encrypt Decrypt
4
continues
From the Library of Ahmed Aden
ptg12115235
278 Chapter 7: Solutions for Geographic Site-to-Site High Availability
Geographic IPsec VPN High Availability with IPsec+GRE
and Encrypted Routing Protocols
Tunneling trafc in GRE prior to encryption with IPsec enables the encryption of multicast trafc.
This is due to the fact that the multicast trafc 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 trafc, including RPs
that use multicast updates, through an encrypted tunnel. As such, sending routing protocol updates
5 C3845ISR-A#sss shhh hooo owww w iii ippp p rrr rooo ouuu uttt teee e sss sttt taaa attt tiii iccc c
6
7 C3845ISR-A#ddd deee ebbb buuu uggg g ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn nsss s aaa accc cttt tiii ivvv veee e
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#sss shhh hooo owww w iii ippp p rrr rooo ouuu uttt teee e sss sttt taaa attt tiii iccc c
36 S 192.168.2.0/24 [1/0] via 200.1.1.2
Example 7-7 Verifying C3845ISR VPN Failover with Dynamic RRI and Multiple IPsec Peer
Denitions (Continued)
From the Library of Ahmed Aden
ptg12115235
Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing Protocols 279
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 trafc in the overall
trafc prole upward, the need to secure this type of trafc increases proportionally. IGP multicast
update trafc is one such critical multicast application that is often included in the crypto
switching path.
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
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
trafc is then encrypted with a transform dened in the IPsec conguration 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
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.
3
10 7
1
6
EIGRP AS 10
WAN
200.1.1.0/24
OSPF 10
Network_A
192.168.1.0/24
EIGRP AS 10
Network_B
192.168.2.0/24
C3845ISR-A
200.1.1.1 200.1.1.2
C3845ISR-B
Host-A
Server-B
EIGRP RP Update: 192.168.2.0/24
Next Hop: 200.1.1.2
EIGRP RP Update: 192.168.1.0/24
Next Hop: 200.1.1.1
2 2
4
9
5
8
From the Library of Ahmed Aden
ptg12115235
280 Chapter 7: Solutions for Geographic Site-to-Site High Availability
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 congured on C3845ISR-A and B. Once the GRE tunnel and RP
conguration is complete on C3845ISR-A and B and trafc 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.
2. The GRE tunnel interfaces created in #1 are congured 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 trafc 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 trafc from Host-A to Server-B out of the GRE tunnel interface.
4. When the trafc 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 trafc 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 trafc 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 C3845ISR-
A in #8, and decapsulates the resulting GRE packet.
10. C3845ISR-A forwards the return trafc 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
NOTE Beware that control plane trafc 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.
From the Library of Ahmed Aden
ptg12115235
Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing Protocols 281
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 trafc 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 conguration
elements are listed for C3845ISR-A and B of Figure 7-3 in Example 7-8, and the verication of
the conguration is provided using the diagnostic commands in Example 7-9 later in our
discussion of IPsec+GRE HA.
Thus far, weve 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 benets 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 condentiality, 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 ows. 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 ow, 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 todays 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 ows 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
From the Library of Ahmed Aden
ptg12115235
282 Chapter 7: Solutions for Geographic Site-to-Site High Availability
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 specic 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
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.
EIGRP AS 10
Network_A
192.168.1.0/24
C3845ISR-C
C3845ISR-B
C3845ISR-A
Host-A
EIGRP AS 10
Network_B
192.168.2.0/24
Server-B
WAN
200.1.1.0/24
(OSPF 10)
2
1
7
9
6
10
4
8
200.1.1.1
200.1.1.2
200.1.1.3
5
7
4
S0/0: 200.1.1.1
Tun0: 192.168.0.1
3
10
EIGRP Update: 192.168.2.0/24
Next Hop: 200.1.1.2
EIGRP Update: 192.168.1.0/24
Next Hop: 200.1.1.1
S0/0: 200.1.1.3
Tun0: 192.168.0.3
S0/0: 200.1.1.2
Tun0: 192.168.0.2
3
C3845ISR-A Remove EIGRP Routes
EIGRP Update w/o Route: 192.168.2.0/24
Next Hop: 200.1.1.2
C3845ISR-A Remove EIGRP Routes
EIGRP Update w/o Route: 192.168.1.0/24
Next Hop: 200.1.1.1
From the Library of Ahmed Aden
ptg12115235
Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing Protocols 283
IKE keepalives intervals can be congured 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-As 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 Cs 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 trafc to Server-B. C3845ISR-A uses a routing table entry learned via
EIGRP RP updates sent in #5 to forward the trafc from Host-A through the IPsec+GRE
tunnel.
6. The trafc 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.
NOTE The default SA lifetimes for IKE and IPsec SAs in Cisco IOS are 38400s and 3600s,
respectively.
From the Library of Ahmed Aden
ptg12115235
284 Chapter 7: Solutions for Geographic Site-to-Site High Availability
7. C3845ISR-C decrypts the trafc received in #6, decapsulates the resulting GRE packet, and
forwards the trafc to Server-B based on the destination address in the original IP header sent
from Host-A.
8. Server-B forwards the return trafc to C3845ISR-C. C3845ISR-C uses a routing table entry
learned via EIGRP RP updates sent in #4 to forward the return trafc from Server-B back to
Host-A through the IPsec+GRE tunnel.
9. The trafc 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 trafc received in #9, decapsulates the resulting GRE packet, and
forwards the trafc 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 conguration used on
C3845ISR-A in Figure 7-4 providing HA using multiple IPsec peer denitions and redundant
GRE tunnels. The failover process described previously for the IPsec+GRE deployment illustrated
in Figure 7-4 is veried in Example 7-9.
Internet Security Association and Key Management Protocol (ISAKMP) is congured to use
preshared key (PSK) authentication with an MD5 hash, DES encryption (default), and a group 2
Dife-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 trafc 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 dene 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 dened in their own respective process IDs (10 and 20) under the same crypto map,
chap7-IPsec+gre:
Crypto ACL 101 denes GRE trafc from the Tunnel12s source IP to Tunnel12s destination
IP to be protected in the crypto switching path. Crypto ACL 101 is congured to protect all
trafc 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 denes GRE trafc from the Tunnel13s source IP to Tunnel12s destination
IP to be protected in the crypto switching path. Crypto ACL 102 is congured to protect all
trafc 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).
From the Library of Ahmed Aden
ptg12115235
Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing Protocols 285
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 protocols 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 dened in the crypto ACLs 101
and 102 accordingly.
Example 7-8 IPsec HA Conguration Using IPsec+GRE with Multiple Crypto-Process IDs
and Redundant, Load-Sharing GRE Interfaces (C3845ISR-A)
1 C3845ISR-A#sss shhh hooo owww w rrr ruuu unnn nnnn niii innn nggg g--- -ccc cooo onnn nfff fiii iggg g
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
continues
From the Library of Ahmed Aden
ptg12115235
286 Chapter 7: Solutions for Geographic Site-to-Site High Availability
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 conrms 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, conrms 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, conrms 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 conrmed 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.
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
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#sss shhh hooo owww w ccc crrr ryyy yppp pttt tooo o eee ennn nggg giii innn neee e ccc cooo onnn nnnn neee eccc cttt tiii iooo onnn nsss s aaa accc cttt tiii ivvv veee e
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
Example 7-8 IPsec HA Conguration Using IPsec+GRE with Multiple Crypto-Process IDs
and Redundant, Load-Sharing GRE Interfaces (C3845ISR-A) (Continued)
From the Library of Ahmed Aden
ptg12115235
Dynamic Multipoint Virtual Private Networks 287
Dynamic Multipoint Virtual Private Networks
At this point, weve 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 conguration
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 conguration 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.
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#sss shhh hooo owww w iii ippp p eee eiii iggg grrr rppp p iii innn nttt teee errr rfff faaa accc ceee esss s
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#sss shhh hooo owww w iii ippp p eee eiii iggg grrr rppp p nnn neee eiii iggg ghhh hbbb booo orrr rsss s
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#sss shhh hooo owww w iii ippp p rrr rooo ouuu uttt teee e eee eiii iggg grrr rppp p 111 1000 0 ||| | iii innn nccc clll luuu uddd deee e TTT Tuuu unnn nnnn neee elll l
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
Example 7-9 Verifying IPsec VPN Failover with IPsec+GRE with Multiple Crypto-Process IDs and
Redundant, Load-Sharing GRE Interfaces (C3845ISR-A) (Continued)
From the Library of Ahmed Aden
ptg12115235
288 Chapter 7: Solutions for Geographic Site-to-Site High Availability
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 todays enterprise-class networks:
Conguration 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
conguration. The creation of unique GRE tunnel interfaces on the hub IPsec VPN gateway
for each branch causes conguration 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 congured on the hub IPsec VPN
gateway. As well 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 conguration
requirements of traditional point-to-point IPsec+GRE networks, yielding a more streamlined
and manageable conguration 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 gateways 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.
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 trafc 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
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 trafc. Any time a spoke requires IPsec-
secured connectivity to the hub, regardless of whether or not DMVPN is congured, 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.
From the Library of Ahmed Aden
ptg12115235
Dynamic Multipoint Virtual Private Networks 289
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 trafc.
DMVPN Component-Level Overview and System Operation
At this point, weve covered several key design drivers for DMVPN in IPsec+GRE environments,
including DMVPNs ability to ease conguration 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 congured 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) congured at the hub for the destination spokes physical IP address.
This IP address is subsequently used when building the IPsec VPN tunnel that secures the
trafc 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, condentiality, and nonrepudiation. Although
DMVPN does not change IPsec or ISAKMP protocols themselves, DMVPN does greatly
simplify the conguration of IPsec and ISAKMP respective to traditional IPsec+GRE
conguration 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.
From the Library of Ahmed Aden
ptg12115235
290 Chapter 7: Solutions for Geographic Site-to-Site High Availability
Figure 7-5 Enterprise DMVPN Topology
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 specic 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.
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
NOTE In a DMVPN environment, all trafc 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.
EIGRP AS 10
Network_A
192.168.1.0/24
C3845ISR-B
C3845ISR-A
C7304
Host-A
EIGRP AS 10
Network_A
192.168.2.0/24
Host-A
EIGRP AS 10
Network_B
192.168.3.0/24
Server-B
3
2
6
7
8 10
1
5
S0/0: 200.1.1.1
S0/0: 200.1.2.1
Lo0: 200.1.0.1
Tun0: 192.168.0.1
S0/0: 200.1.2.2
Tun0: 192.168.0.2
S0/0: 200.1.1.2
Tun0: 192.168.0.1
4 9
OSPF 10
WAN
200.1.1.0/24
From the Library of Ahmed Aden
ptg12115235
Dynamic Multipoint Virtual Private Networks 291
the NHS 192.168.0.1 have a manually dened NHS denition mapped to the C7304s
loopback interface, (200.1.0.1).
3. The NHS on C7304 returns C3845ISR-Bs 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-Bs 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 trafc 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 trafc 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.
Trafc can now ow bidirectionally over the IPsec+GRE tunnel between Networks A and B
behind C3845ISR-A and B, respectively.
9. Host-A forwards trafc 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
trafc before GRE decapsulating it and eventually forwarding on to Server_B.
10. Server-B forwards return trafc 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 trafc before GRE decapsulating it and eventually forwarding on
to Host-A.
The process described above illustrates several benets of DMVPN from administrative,
management, and scalability perspectives. The congurations for C7304, C3845ISR-A,
C3845-ISR-B can be referenced in Examples 7-12 and 7-13 to further reinforce the illustration of
these benets. Before reviewing the required congurations for the DMVPN implementation
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.
From the Library of Ahmed Aden
ptg12115235
292 Chapter 7: Solutions for Geographic Site-to-Site High Availability
topology of Figure 7-5, lets quickly review the DMVPN benets against the step-by-step
DMVPN operation on C3845ISR-A and B described above:
Zero-Touch Spoke Provisioning on the Hub (C7304): DMVPN conguration 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 conguration. The required hub
conguration 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 trafc 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-
specic conguration elements on C3845ISR-A and B. DMVPN accomplishes this by
enabling the peer to dynamically learn peering information via NHRP from the NHS
congured on the hub (C7304), as illustrated in steps 2, 3, and 5 previously. This enables
administrators to push a generic, uniform, IPsec conguration to each spoke (C3845ISR-A
and B). The common IPsec conguration for spoke IPsec VPN gateways C3845ISR-A and B
is illustrated in Example 7-11.
As with traditional IPsec+GRE, the ISAKMP must be congured to establish the Phase 1 SAs that
DMVPN will use to build Phase 2 SAs. Unlike the congurations 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 prole
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 prole congured earlier. This effectively turns on ISAKMP on
physical interface protecting the tunnel and also includes all GRE trafc sent out of this interface
to be included in the crypto switching path. As such, there is no concept of a crypto ACL for
dening crypto-protected trafc ows in a DMVPN. Instead, all trafc 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
From the Library of Ahmed Aden
ptg12115235
Dynamic Multipoint Virtual Private Networks 293
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.
The IP address of the tunnel interface is injected in to EIGRP 10. The routing protocol
conguration in this design is congured 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 ow 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.
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.
Example 7-10 DMVPN Hub Conguration for C7304 (Figure 7-5)
1 ccc crrr ryyy yppp pttt tooo o ccc caaa a ttt trrr ruuu usss sttt tppp pooo oiii innn nttt t III IOOO OSSS S___ _CCC CAAA A111 1
2 eee ennn nrrr rooo olll llll lmmm meee ennn nttt t uuu urrr rlll l hhh httt tttt tppp p::: :/// //// /222 2000 0000 0... .111 1... .222 2... .111 1000 0000 0
3 !!! !
4 ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 111 1000 0
5 hhh haaa asss shhh h mmm mddd d555 5
6 ggg grrr rooo ouuu uppp p 222 2
7 ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eeee eppp paaa alll liii ivvv veee e 111 1000 0
8 !!! !
9 ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ddd dmmm mvvv vppp pnnn n777 7 eee esss sppp p--- -333 3ddd deee esss s eee esss sppp p--- -mmm mddd d555 5--- -hhh hmmm maaa accc c
10 !!! !
11 ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ppp prrr rooo offf fiii illl leee e ccc chhh haaa appp p777 7--- -ddd dmmm mvvv vppp pnnn n--- -ppp prrr rooo offf fiii illl leee e
12 sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ddd dmmm mvvv vppp pnnn n777 7
13 !!! !
14 iii innn nttt teee errr rfff faaa accc ceee e TTT Tuuu unnn nnnn neee elll l000 0
15 iii ippp p aaa addd dddd drrr reee esss ssss s 111 1999 9222 2... .111 1666 6888 8... .000 0... .111 1 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
16 nnn nooo o iii ippp p rrr reee eddd diii irrr reee eccc cttt tsss s
17 iii ippp p mmm mttt tuuu u 111 1444 4111 1666 6
18 iii ippp p nnn nhhh hrrr rppp p aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tiii iooo onnn n ddd dmmm mvvv vppp pnnn n777 7
19 iii ippp p nnn nhhh hrrr rppp p mmm maaa appp p mmm muuu ulll lttt tiii iccc caaa asss sttt t ddd dyyy ynnn naaa ammm miii iccc c
20 iii ippp p nnn nhhh hrrr rppp p nnn neee ettt twww wooo orrr rkkk k--- -iii iddd d 777 7
21 iii ippp p nnn nhhh hrrr rppp p hhh hooo olll lddd dttt tiii immm meee e 333 3666 6000 0
22 nnn nooo o iii ippp p sss sppp plll liii ittt t--- -hhh hooo orrr riii izzz zooo onnn n eee eiii iggg grrr rppp p 111 1000 0
continues
From the Library of Ahmed Aden
ptg12115235
294 Chapter 7: Solutions for Geographic Site-to-Site High Availability
In terms of encryption and routing processes, the conguration 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 congured to use this static map to query for the unknown next-hop IP addresses using
NHRP. Although the NHS is dened 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.
23 ttt tuuu unnn nnnn neee elll l sss sooo ouuu urrr rccc ceee e FFF Faaa asss sttt tEEE Ettt thhh heee errr rnnn neee ettt t000 0/// /000 0
24 ttt tuuu unnn nnnn neee elll l mmm mooo oddd deee e ggg grrr reee e mmm muuu ulll lttt tiii ippp pooo oiii innn nttt t
25 ttt tuuu unnn nnnn neee elll l kkk keee eyyy y 000 0
26 ttt tuuu unnn nnnn neee elll l ppp prrr rooo ottt teee eccc cttt tiii iooo onnn n III IPPP Psss seee eccc c ppp prrr rooo offf fiii illl leee e ccc chhh haaa appp p777 7--- -ddd dmmm mvvv vppp pnnn n--- -ppp prrr rooo offf fiii illl leee e
Example 7-11 DMVPN Spoke Conguration for C3845ISR-A and B (Figure 7-5)
1 ccc crrr ryyy yppp pttt tooo o ccc caaa a ttt trrr ruuu usss sttt tppp pooo oiii innn nttt t III IOOO OSSS S___ _CCC CAAA A111 1
2 eee ennn nrrr rooo olll llll lmmm meee ennn nttt t uuu urrr rlll l hhh httt tttt tppp p::: :/// //// /222 2000 0000 0... .111 1... .222 2... .111 1000 0000 0
3 !!! !
4 ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p ppp pooo olll liii iccc cyyy y 111 1000 0
5 hhh haaa asss shhh h mmm mddd d555 5
6 ggg grrr rooo ouuu uppp p 222 2
7 ccc crrr ryyy yppp pttt tooo o iii isss saaa akkk kmmm mppp p kkk keee eeee eppp paaa alll liii ivvv veee e 111 1000 0
8 !!! !
9 ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ddd dmmm mvvv vppp pnnn n777 7 eee esss sppp p--- -333 3ddd deee esss s eee esss sppp p--- -mmm mddd d555 5--- -hhh hmmm maaa accc c
10 !!! !
11 ccc crrr ryyy yppp pttt tooo o III IPPP Psss seee eccc c ppp prrr rooo offf fiii illl leee e ccc chhh haaa appp p777 7--- -ddd dmmm mvvv vppp pnnn n--- -ppp prrr rooo offf fiii illl leee e
12 sss seee ettt t ttt trrr raaa annn nsss sfff fooo orrr rmmm m--- -sss seee ettt t ddd dmmm mvvv vppp pnnn n777 7
13 !!! !
14 iii innn nttt teee errr rfff faaa accc ceee e TTT Tuuu unnn nnnn neee elll l000 0
15 iii ippp p aaa addd dddd drrr reee esss ssss s 111 1999 9222 2... .111 1666 6888 8... .000 0... .333 3 222 2555 5555 5... .222 2555 5555 5... .222 2555 5555 5... .000 0
16 iii ippp p mmm mttt tuuu u 111 1444 4111 1666 6
17 iii ippp p nnn nhhh hrrr rppp p aaa auuu uttt thhh heee ennn nttt tiii iccc caaa attt tiii iooo onnn n ddd dmmm mvvv vppp pnnn n777 7
18 iii ippp p nnn nhhh hrrr rppp p mmm maaa appp p 111 1999 9222 2... .111 1666 6888 8... .000 0... .111 1 222 2000 0000 0... .111 1... .111 1... .111 1
19 iii ippp p nnn nhhh hrrr rppp p nnn neee ettt twww wooo orrr rkkk k--- -iii iddd d 777 7
20 iii ippp p nnn nhhh hrrr rppp p hhh hooo olll lddd dttt tiii immm meee e 666 6000 0000 0
21 iii ippp p nnn nhhh hrrr rppp p nnn nhhh hsss s 111 1999 9222 2... .111 1666 6888 8... .000 0... .111 1
22 ttt tuuu unnn nnnn neee elll l sss sooo ouuu urrr rccc ceee e EEE Ettt thhh heee errr rnnn neee ettt t000 0/// /000 0
23 ttt tuuu unnn nnnn neee elll l ddd deee esss sttt tiii innn naaa attt tiii iooo onnn n 222 2000 0000 0... .111 1... .111 1... .111 1
24 ttt tuuu unnn nnnn neee elll l kkk keee eyyy y 000 0
25 ttt tuuu unnn nnnn neee elll l ppp prrr rooo ottt teee eccc cttt tiii iooo onnn n III IPPP Psss seee eccc c ppp prrr rooo offf fiii illl leee e ccc chhh haaa appp p777 7--- -ddd dmmm mvvv vppp pnnn n--- -ppp prrr rooo offf fiii illl leee e
Example 7-10 DMVPN Hub Conguration for C7304 (Figure 7-5) (Continued)
From the Library of Ahmed Aden
ptg12115235
Summary 295
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 VPNs 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, weve 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 trafc 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 conguration and
management in large-scale IPsec+GRE designs. Additionally, DMVPN can be congured such
that spokes can be provisioned without any additional conguration on the hub. This is a very
attractive feature of DMVPN, as it eliminates the possibility of misconguration 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
conguration (including crypto ACL and peer conguration), DMVPN spoke conguration can
be deployed uniformly across different spokes, as shown in our DMVPN conguration examples
relevant to the design topology of Figure 7-5.
From the Library of Ahmed Aden
ptg12115235
From the Library of Ahmed Aden
ptg12115235
C H A P T E R
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 dened
in the IETFs IPSec-related RFCs. However, there are no requirements currently dened by the
IETF that specically 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 availability
the ability to determine the availability of a remote peer and to rapidly detect the change in
a remote peers 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 ofce 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 conguration, 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.
From the Library of Ahmed Aden
ptg12115235
298 Chapter 8: Handling Vendor Interoperability with High Availability
Figure 8-1 Vendor Interoperability and Peer Availability: Inability to specify multiple peers
In this scenario, the remote VPN gateway does not have the ability to dene multiple IPSec peers,
Reverse Route Injection (RRI), or IPSec+GRE. Instead, the branch encryptor, IPSec-GW-A1,
relies on manually dened 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 congured 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 trafc
across the redundant serial link between C2800ISR-A1 and C7206VXR-B1.
C7206VXR-B1
C7206VXR-A1
HSRP Virtual
Interface with SSO
Site A
IPSec-GW-A1
C2800ISR-A1
C7206VXR-B1
Site B
Redundant Peers without Peer Availability Mechanism
Site A
IPSec-GW-A1 3
5
C7206VXR-B1
IPSec-GW-A1
Prim
ary IPSec VPN
Tunnel
Peering to an HSRP Virtual Interface No Peer Availability Mechanism
IPSec VPN Tunnel (Failover)
Si
Si
Si
Si
Si
Si
2
C7206VXR-A1
C2800ISR-A1
1
4
GRE Tunnels on Redundant Peers without Peer Availability Mechanism
GRE
GRE + IPSec
Cleartext failover path available if encryptor allows
traffic to pass without active IKE and IPSec SAs.
Prim
ary IPSec VPN Tunnel
C7206VXR-A1
Prim
ary IPSec VPN Tunnel
C2800ISR-A1
Site B
Site B
Site A
From the Library of Ahmed Aden
ptg12115235
Vendor Interoperability Impact on Peer Availability 299
3. IPSec-GW-A1 does not support the denition of multiple IPSec peers and is therefore
incapable of negotiating a Phase 2 Security Assotiation with C7206VXR-B1.
4. Because the trafc ows 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 trafc using the IPSec
SA with C7206VXR-A1, which is now unavailable.
5. IPSec-GW-A1s Phase 2 negotiations continually fail, causing all trafc ows 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 trafc ows (as is the case with crypto ACLs), then IPSec+GRE could be used to
differentiate the trafc ows (ows would be based on source and destination GRE tunnel
endpoints) by encapsulating them in GRE before the trafc 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-A1s crypto ACL
equivalent would be congured to bypass crypto operations for the redundant GRE tunnel trafc.
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 benets while presenting a single tunnel termination point for
the branches.
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.
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.
From the Library of Ahmed Aden
ptg12115235
300 Chapter 8: Handling Vendor Interoperability with High Availability
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.
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 enterprises headquarters.
Figure 8-2 Lack of Peer Availability Mechanisms and the Impact on IPSec VPN Reconvergence
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-GW-
A2 does not support IKE keepalives or DPD, but as per RFC 2401, IPSec-GW-A2 does associate
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.
C7206VXR-B2
Site B
Redundant Peers without Peer Availability Mechanism
Site A
IPSec-GW-A2
3
P
rim
ary IP
S
ec V
P
N
Tu
n
n
el
Si
Si
C7206VXR-A2
1
4
S
eco
n
d
ary IP
S
ec V
P
N
Tu
n
n
el
C2800ISR-A2
2
From the Library of Ahmed Aden
ptg12115235
Vendor Interoperability Impact on Path Availability 301
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 trafc 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-A2s SADB, IPSec-GW-
A2 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, C7206VXR-
B2 (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.
Weve 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
From the Library of Ahmed Aden
ptg12115235
302 Chapter 8: Handling Vendor Interoperability with High Availability
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 benet of IPSec is that it can be used to provide data condentiality 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
condentiality 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 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 partners IPSec gateways support
adequate RP capabilities in order to establish and maintain the IPSec VPN tunnel.
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 conguration and
design options, in Chapter 12, Solutions for Handling Dynamically Addressed Peers.
From the Library of Ahmed Aden
ptg12115235
Vendor Interoperability Impact on Path Availability 303
Consider the scenario in which an extranet partners 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 trafc, including all IPSec control plane trafc, to networks on the same
directly connected segment, that IPSec VPN gateway is incapable of forwarding control plane
trafc to the appropriate Layer 3 IPSec tunnel termination point.
Figure 8-3 Lack of RP Support and the Impact on Site-to-Site IPSec VPN High-Availability
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) trafc 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 congure routes each
time a partner residing on a different IP network is added to the extranet. Additionally, the manual
conguration 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
Extranet Partner A
IPSec-GW-A3
Extranet Partner A
ISP
(Layer 3 Cloud)
IPSec-GW-C3
Extranet Partner B
IPSec-GW-B3
Routing protocol support allows aggregation of many
inbound tunnels without scalability and management
disadvantages of static routes and enables efficiencies
gained using dynamic crypto maps.
Lack of L3 awareness prevents
IPSec VPN gateways from
establishing tunnels with peers that
are not on the same L2 domain.
Extranet Partner B
IPSec-GW-D3
Si
Si
C7206VXR-B3
C7206VXR-A3
Site B
From the Library of Ahmed Aden
ptg12115235
304 Chapter 8: Handling Vendor Interoperability with High Availability
additional administration to the IPSec aggregation points (static routes and static IPSec peers can
be added during the same conguration 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 rewall 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 trafc 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.
L2 L3
RRI
Lack of RRI support prevents networked
nodes on domain A from learning of
routes to routed domain C.
Server_B4
Host_A4
IPSec VPN Tunnel
Service Provider
(Routed Domain B)
IPSec VPN Tunnel
L3 nodes will not have entries for routed
domain C, causing failures at the first
L2/3 boundary within routed domain A.
L2 L3
Routed Domain A
Routed Domain C
RRI
Si
Si
Si
Si
From the Library of Ahmed Aden
ptg12115235
Vendor Interoperability Impact on Path Availability 305
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 As VPN gateways
(IPSec-GW-A4 and IPSec-GW-B4) do not support RRI (and are not equipped nor congured 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_As
communications to Server_B will fail at the rst 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-A4s SADB upon successful negotiation of a Phase 2 SA.
These static routes can then be redistributed into segment As RP to populate the routing tables of
the remaining Layer 3 nodes within the segment.
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 trafc ows
themselves, while native RRI does not, thereby making IPSec+GRE the compelling design
alternative where multicast trafc must be transmitted with data condentiality 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).
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.
From the Library of Ahmed Aden
ptg12115235
306 Chapter 8: Handling Vendor Interoperability with High Availability
Figure 8-5 IPSec Vendor Interoperability and Lack of GRE Support.
Figure 8-5 illustrates a scenario in which multicast trafc, 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 trafc between the
two partners. The failure occurs on Extranet Partner Bs 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.
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.
TIP GRE ofoad 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 ofoad deployments,
please refer to Chapter 10, Further Architectural Options for IPsec.
C2800ISR-A5
Multicast
Sender
Multicast traffic cannot pass through the
IPSec VPN without prior GRE encapsulation.
RP Update
IPSec-GW-B5
Multicast
Receivers
C2800ISR-A5 uses IPSec+GRE, but IPSec-GW-B5 can only
terminate the IPSec tunnel (not the GRE tunnel).
Multicast Traffic
IPSec Tunnel GRE Tunnel
RP Update
Si
Si
From the Library of Ahmed Aden
ptg12115235
Vendor Interoperability Design Considerations and Options 307
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 vendors IPSec VPN gateway, so long as that vendors 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. Weve 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 Congurations,
that the management of SAs in an IPSec VPN gateways SADB are managed over a secure
channel, called an IKE security association (or Phase 1 SA). This SA can be negotiated in one
From the Library of Ahmed Aden
ptg12115235
308 Chapter 8: Handling Vendor Interoperability with High Availability
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 ofine 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
C2800ISR-A6
C2800ISR-A6 resets
and recovers.
IPSec-GW-B6
Invalid SPI detected
1
3
5
6
2
New phase 1 and 2 SA negotiation
Invalid SPI notify 4
Si
Si
From the Library of Ahmed Aden
ptg12115235
Vendor Interoperability Design Considerations and Options 309
Consider the scenario in which C2800ISR-A6 was to go ofine and then return due to an
interface failure, a system reset, or a power failure. When the C2800ISR-A6 goes ofine, 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 trafc from IPSec-GW-A6 and nds no SPI in its SADB
for the received trafc. 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 trafc 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.
From the Library of Ahmed Aden
ptg12115235
310 Chapter 8: Handling Vendor Interoperability with High Availability
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.
In this scenario, the two IPSec VPN gateways at the enterprises 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 StatementsOnly 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 DPDThe 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.
The design benets of stateful IPSec HA extend far beyond the added exibility 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
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.
C7206VXR-B7
C7206VXR-A7
Site B
HSRP Virtual
Interface with
SSO
Site A
IPSec-GW-A7
Si
Si
Prim
ary IPSec VPN Tunnel
HSRP/VRRP virtual interface provides out of chassis
tunnel termination redundancy and eliminates the need
for multiple peering statements on IPSec-GW-A7.
Stateful HA allows for failover without
renegotiating SAs, reducing the need for
IKE keepalives on IPSec-GW-A7.
IPSec VPN
Tunnel (Failover)
C2800ISR-A7
From the Library of Ahmed Aden
ptg12115235
Summary 311
such, exibility 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 benets 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.
From the Library of Ahmed Aden
ptg12115235
From the Library of Ahmed Aden
ptg12115235
C H A P T E R
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 efciency is therefore enabled for sales, marketing, consulting, and any other
eld employee in the enterprises mobile workforce. In this chapter, we will expand on the
Remote Access VPN design introduction provided in Chapter 3, Basic IPsec VPN Topologies
and Congurations, 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 ofce or other small remote location. Although the secure tunneling
requirement of an RAVPN can come in many different avors 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 users laptop.
As such, there is little need for high-availability specic to the client in an RAVPN
implementation.
NOTE When there are signicant 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.
From the Library of Ahmed Aden
ptg12115235
314 Chapter 9: Solutions for Remote-Access VPN 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 Denitions on the VPN Client Prole
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.
From the Library of Ahmed Aden
ptg12115235
IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination 315
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 denes VRRP
as an election protocol that dynamically assigns responsibility for a virtual router to one of the
VRRP routers on a LAN.
In RAVPN environments, this VRRP LAN is typically a network segment attached to a rewall
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 denition (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 rewall
design at the Internet edge.
The VPN3000 concentrator conguration 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. Conguration of the RAVPN group and password on the VPN3000 is illustrated
in Figure 9-2.
Figure 9-3 illustrates the following parameters that can be assigned to a given IPsec VPN client
during IKE Mode cong. 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 conguration, SEP cards 1-4 are actively participating in the acceleration of IPsec on
the concentrator for this group.
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
From the Library of Ahmed Aden
ptg12115235
IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination 316
Figure 9-1 Dual-DMZ VPN Concentrator Design with VRRP-Based HA
Si
Si
VPN3060-A
Public IP: 10.1.1.1
DNS: 200.1.1.17
VPN3060-B
Public IP: 10.1.1.2
VPN3060-C
Public IP: 10.1.1.3
Inner DMZ Outer DMZ
Inside Outside
IEDGE-C6509-B
4948G-DMZ-PRI
4948G-DMZ-PUB
PIX535-Standby
PIX535-Main
To: CORE
IEDGE-C6509-A
IEDGE-7304-A
IEDGE-7304-B
To: CORE
Static NAT Translations:
200.1.1.100->10.1.1.100
200.1.1.101->10.1.1.1
200.1.1.102->10.1.1.2
200.1.1.103->10.1.1.3
All IPsec VPN
concentrators
participate in the
same VRRP Group,
using a VRRP Virtual
Router IP address of
10.1.1.100.
Internet
2
4
4 1
3
5
From the Library of Ahmed Aden
ptg12115235
IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination 317
Figure 9-2 VPN3000 IPsec Group and Password Conguration
Figure 9-3 VPN3000 General Conguration (Client SEP Card, DHCP/Address Scope, and DNS Server
Assignment)
Figure 9-4 illustrates the IPsec conguration 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).
From the Library of Ahmed Aden
ptg12115235
318 Chapter 9: Solutions for Remote-Access VPN High Availability
Figure 9-4 VPN3000 Group IPsec and ISAKMP Conguration
IKE mode cong 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 conguration of these
parameters for assignment to the client via IKE mode cong.
Figure 9-5 VPN3000 Client Conguration (Banner, NAT-T Policy, Subnet Mask Assignment, IPsec Split
Tunnel Policy)
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 dened locally
From the Library of Ahmed Aden
ptg12115235
IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination 319
on the IPsec VPN concentrator using IKE mode cong. Figure 9-6 illustrates the corresponding
conguration on the VPN3000 concentrator.
Figure 9-6 Dening Address Assignment Methods on the VPN3000
Figure 9-7 illustrates the conguration of the appropriate address pool corresponding to the
dened address assignment method displayed in Figure 9-6.
Figure 9-7 Assigning Client Addresses from Dened IP Address Pool on the VPN3000 Concentrator
From the Library of Ahmed Aden
ptg12115235
320 Chapter 9: Solutions for Remote-Access VPN High Availability
As we had discussed previously in Figure 9-4, Phase 1 SA authentication can be done with per-
user granularity when IKE x-Auth is used. Figure 9-4 provides us with the appropriate group and
password conguration 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 congured 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
Figure 9-9 illustrates the conguration 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 users IPsec
VPN tunnel. IPsec is the only tunneling protocol congured for this client to use on this
particular VPN concentrator.
IPsec transform sets can be congured on a per-user basis. Figure 9-10 illustrates the appropriate
IPsec transform conguration at the user level.
From the Library of Ahmed Aden
ptg12115235
IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination 321
Figure 9-9 VPN3000 Conguration for General RAVPN User Authentication and Authorization Policies
with IKE X-Auth
Figure 9-10 Dening Per-User Allowed IPsec Transform Polices with IKE X-Auth on VPN3000
Concentrators
From the Library of Ahmed Aden
ptg12115235
322 Chapter 9: Solutions for Remote-Access VPN High Availability
The VPN3000 concentrator must be congured 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 concentrators 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 trafc from the
concentrators private network through the public interface and across the IPsec VPN tunnels.
More specic static routes are required to route trafc in the opposite direction, inbound from
IPsec RAVPN clients to IP-enabled resources on the enterprises private network.
OSPF: Instead of manually inserting more specic static routes pointing out of the
concentrators 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
concentrators public interface with more specic IP subnets le