IPsec virtual private network fundamentals: [an introduction to VPNs] [4th print ed.] 1587052075, 9781587052071

Citation preview

IPsec Virtual Private Network Fundamentals

James Henry Carmouche, CCIE No. 6085

Cisco Press 800 East 96th Street Indianapolis, Indiana 46240 USA

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 publisher, except for the inclusion of brief quotations in a review. Printed in the United States of America 1 2 3 4 5 6 7 8 9 0 First Printing

June 2006

Library of Congress Cataloging-in-Publication Number: 2004107143 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 fitness is implied. The information is provided on an “as is” basis. The authors, Cisco Press, and Cisco Systems, Inc. shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the discs or programs that may accompany it. The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc.

Corporate and Government Sales Cisco Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales. For more information please contact: [email protected]

U.S. Corporate and Government Sales

For sales outside the U.S. please contact:

International Sales

1-800-382-3419

[email protected]

Feedback Information At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional technical community. Readers’ feedback is a natural continuation of this process. If you have any comments regarding how we could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at [email protected]. Please make sure to include the book title and ISBN in your message. We greatly appreciate your assistance.

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

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 GSU’s newly introduced security platforms. In addition to his product and solution development experience, Henry has more than six years of technical consulting experience, including three years as a network consulting engineer in the Cisco Advanced Services Group. Henry earned an M.B.A. degree from UNC’s Kenan-Flagler Business School and a B.S. degree in mechanical engineering from Lehigh University. Henry currently lives in Chapel Hill, NC, with his wife and two sons.

About the Technical Reviewers Aamer Akhter, CCIE No. 4543, joined Cisco Systems in 1998 after graduating from Georgia Tech with a B.S. degree in electrical engineering to work in the Cisco Technical Assistance Center. He then supported the larger enterprise customers from Cisco in the NSA unit, where he helped design and deploy several large Layer 2 networks. Aamer later moved to Networked Solutions Integration Test Engineering (NSITE), where after a brief stint with IPsec VPNs, he moved into a new group for testing MPLS-VPNs. Five years later, MPLS-VPNS had matured much but testing of MPLS-related technologies still continues. Aamer is currently leading a team for testing Layer 3 VPNs and related technologies in a cross-Cisco effort. Jason Guy is an engineer within the Cisco Systems’ NSITE Security team, an organization responsible for network-based security solution testing. Jason is a member of a team responsible for testing, validating, scaling, and assisting in deployment of the Cisco security solution. Jason’s primary focus is on firewalls, IPsec Remote Access, and SSL VPN testing. Prior to his work on the security technologies, Jason worked on the AToM Layer 2 VPN and MPLS VPN teams. Jason received his Masters of Computer Engineering degree from North Carolina State University in Raleigh, NC. Mark J. Newcomb, CCNP, CCDP, is a retired network security engineer. Mark has more than 20 years experience in the networking industry, focusing on the financial and medical industries. Mark is a frequent contributor and reviewer for Cisco Press books.

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.

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. I’d like to thank Mike O’Shea for his support and friendship over the course of developing this book. Mike’s sound professional and personal advice have helped me endure the ebbs and flows of sanity while balancing a challenging workload and added development responsibilities associated with writing this book. Thank you to Pavan Reddy, one of the sharpest technical minds in Advanced Services, who was instrumental in helping me outline and define this scope of work and whose technical advice and words of encouragement throughout the course of developing this book have proven to be invaluable. And on that note, many thanks go out to Andrew Cupp and Brett Bartow for their patience, understanding, and support during this process. An author could not have asked for a more professional team to work with while developing and publishing his work.

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, find 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 difficulty registering on Safari Bookshelf or accessing the online edition, please e-mail [email protected].

viii

Contents at a Glance Introduction Part I

xvii

Introductory Concepts and Configuration/Troubleshooting

Chapter 1

Introduction to VPN Technologies

Chapter 2

IPsec Fundamentals

Chapter 3

Basic IPsec VPN Topologies and Configurations

Chapter 4

Common IPsec VPN Issues

Part II

3

5

35

Designing VPN Architectures

105

141

205

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

Part III

Advanced Topics

207 235

Chapter 12

Solutions for Handling Dynamically Addressed Peers

452

313

389

Public Key Infrastructure and IPsec VPNs

Index

297

359

Chapter 11

Appendix A Resources

267

449

391 417

ix

Contents Introduction Part I Chapter 1

xvii

Introductory Concepts and Configuration/Troubleshooting Introduction to VPN Technologies

3

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 Drivers—A Practical Example 30 Site-to-Site VPN Business Drivers—A 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 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

42

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 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

79

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

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 Firewall’s 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 IPsec’s Influence on DiffServ and LLQ/CBWFQ 181 IPsec’s Effect on IntServ and RSVP 183

xii

Solving Fragmentation Issues in IPsec VPNs 183 Path MTU Discovery 184 Fragmentation Behavior on Cisco IOS VPN Endpoints Solutions for Preventing Fragmentation 193 The Effect of Recursive Routing on IPsec VPNs 197 Summary 200

Part II Designing VPN Architectures Chapter 5

189

205

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 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

210

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 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

267

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

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 Chapter 11

389

Public Key Infrastructure and IPsec VPNs PKI Background 391 PKI Components 394 Public Key Certificates 394 Registration Authorities 395 Certificate Revocation Lists and CRL Issuers Certificate Authorities 397 PKI Cryptographic Endpoints 397

391

396

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 CA’s Certificate 403 Forwarding and Signing of Public Keys 403 Obtaining and Using Public Key Certificates 403 PKI and the IPSec Protocol Suite—Where PKI Fits into the IPSec model 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

404

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 Study—Using Dynamic Addressing with Low-Maintenance Small Home Office Deployments 432 Summary 446

Appendix A Resources

449

Books 449 RFCs 449 Web and Other Resources

Index 452

450

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 configuration examples and output (not general command syntax), boldface indicates commands that are manually input by the user (such as a show command).

■

Italics indicate arguments for which you supply actual values.

■

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

■

Square brackets [ ] indicate optional elements.

■

Braces { } indicate a required choice.

■

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

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 financial, government), explaining the need for increased information authentication, confidentiality, and non repudiation for secure transmission of confidential data (government records, financial data, billing information). The primary development objective of this book is to create a work that aids network architects, administrators, and managers in their efforts to integrate IPsec VPN technology into their existing IP infrastructures. The focus is on IPsec deployments in Cisco network environments, from simple site-to-site virtual private network (VPN) configurations to comprehensive VPN strategies, including architectural redundancy and interoperability.

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

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

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 IPsec’s development and the types of organizations that rely on IPsec to secure data transmissions. The book then proceeds to outline the basic IPsec/Internet Security Association and Key Management Protocol (ISAKMP) fundamentals that were developed to meet demand for secure data transmission. The book proceeds to cover the design and implementation of IPsec VPN architectures using an array of Cisco products, starting with basic concepts and proceeding to more advanced topics, including HA solutions and public key infrastructure (PKI). Sample topology diagrams and configuration examples are provided to help reinforce the fundamentals expressed in the text, and to assist the reader in translating explained IPsec concepts into practical working deployment scenarios. Case studies are incorporated throughout the text in order to map the topics and concepts discussed to real-world solutions. Chapters 1 through 4 compose Part I of this book, covering the most basic concepts required to develop an understanding of IPsec VPNs. The chapter content provided in Part I aims to help the reader achieve the following objectives: ■

Understand the background of IPsec VPN development

■

Differentiate IPSEC/SSL VPN from other VPN technologies

■

Understand the underlying cryptographic technologies that compose an IPsec VPN

■

Understand basic IPsec VPN configuration techniques

■

Understand common issues that can affect all IPsec designs

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

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

■

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

xix

■

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

■

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

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

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

■

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

■

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

■

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

■

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

■

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

xx

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

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

■

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

This page intentionally left blank

Part I: Introductory Concepts and Configuration/Troubleshooting

Chapter 1

Introduction to VPN Technologies

Chapter 2

IPsec Fundamentals

Chapter 3

Basic IPsec VPN Topologies and Configurations

Chapter 4

Common IPsec VPN Issues

CHAPTER

1

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

VPN Overview of Common Terms A VPN is a means to securely and privately transmit data over an unsecured and shared network infrastructure. VPNs secure the data that is transmitted across this common infrastructure by encapsulating the data, encrypting the data, or both encapsulating the data and then encrypting the data. In the context of VPN deployments, encapsulation is often referred to as tunneling, as it is a method that effectively transmits data from one network to another transparently across a shared network infrastructure. A common encapsulation method found in VPNs today is Generic Routing Encapsulation (GRE). IP-based GRE is defined in IETF RFC 2784 as a means to enclose the IP header and payload with a GRE-encapsulation header. Network designers use this method of encapsulation to hide the IP header as part of the GRE-encapsulated payload. In doing so, they separate or “tunnel” data from one network to another without making changes to the underlying common network infrastructure. Although GRE tunnels have primitive forms of authentication, as we’ll explore in later chapters when discussing dynamic multipoint VPN (DMVPN) deployments, they currently provide no means to provide confidentiality, integrity, and non-repudiation natively. Nevertheless, GRE tunneling is a fundamental component of many different IP Security Protocol (IPsec) designs, and will be discussed frequently in subsequent chapters.

6

Chapter 1: Introduction to VPN Technologies

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

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

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

■

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

■

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

■

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

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

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

Confidentiality and Authenticity in Encrypted Communications Plain Text

Plain Text

Hey Charlie, what did you learn at school today?

Hey Charlie, what did you learn at school today?

Cipher: RSA Charlie’s Encryption Key

Cipher: RSA

Cipher Text:

Charlie’s Decryption Key

Cipher Text:

4$h5*&FsW@4^%TY&^i*f

4$h5*&FsW@4^%TY&^i*f

Charlie

James Charlie shares his encryption key only with James

Encrypting messages relies on the use of a key to encrypt clear text and to decrypt ciphered messages. In the exchange of messages in Figure 1-1, both James and Charlie require the appropriate keys to encrypt and decrypt communications from each other. Assuming that these keys were exchanged or derived securely (for example, via a Diffie-Hellman exchange, which is discussed in detail in Chapter 2, “IPsec Fundamentals”), when James receives a message from Charlie that he is able to decrypt, he can be assured that the message has been delivered with full confidentiality, and vice versa. Hashes and digital signatures protect the integrity of a specific communication of data. Hashes and digital signatures append unique messages to the original message before transmission that ensure that the message has not been tampered with in transit. Figure 1-2 illustrates the operation of a hash performed on a message to ensure data integrity. By providing a unique fingerprint specific only to the sender of the message, a digital signature also provides the receiver a method of message authentication and sender non-repudiation. Notice in Figure 1-3 that digital signatures require the use of a public decryption key unique to the sender's private encryption key. The use of this cryptographic keypair thus guarantees message authenticity, ensuring that the message was sent from the authentic origin, and safeguards against sender non-repudiation, preventing a situation in which the sender of a specific message intentionally and falsely denies their transmittal of the message. While a secure hash can provide data integrity, digital signatures provide added levels of security by offering message authentication and sender non-repudiation, the operation of which is illustrated in Figure 1-3.

8

Chapter 1: Introduction to VPN Technologies

Figure 1-2

Data Integrity, Secure Hashes

James appends message digest to original message

Plain Text

Plain Text

Hey Charlie, what did you learn at school today?

Hey Charlie, what did you learn at school today?

Hash: MD5

Hash: MD5

Hash Value:

Hash Value:

Hash Value:

Fsd$#^@43#@Ad5J$

Fsd$#^@43#@Ad5J$

Fsd$#^@43#@Ad5J$

Charlie

James

Charlie verifies the James message digest with his own

Hey Charlie, what did you learn at school today? Charlie separates James’ message digest from original message

Fsd$#^@43#@Ad5J$

Figure 1-3

Message Authenticity and Data Non-Repudiation with Digital Signatures Charlie verifies the James message digest with his own

Plain Text Hey Charlie, what did you learn at school today?

James encrypts the message digest

Hash: MD5

Hash Value:

Hash Value:

Fsd$#^@43#@Ad5J$

Cipher: RSA

Charlie decrypts the digital signature

Fsd$#^@43#@Ad5J$

James’ Decryption Key Cipher: RSA

Hash: MD5

Digital Signature

Hey Charlie, what did you learn at school today?

James’ Encryption Key

Hash Value: Fsd$#^@43#@Ad5J$

Digital Signature

James

Charlie

Hey Charlie, what did you learn at school today? Digital Signature James appends message digest to original message

Charlie separates James’ message digest from original message

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 we’ll discuss throughout the course of this book, VPNs have been designed to protect data at almost every layer of the OSI stack. For example, customers in different market verticals will deploy a range of encryption technologies, from Layer 1 bulk encryptors to encryption technologies embedded within the applications themselves (SSL-based VPNs). The OSI model consists of 7 layers, Physical, Data-Link, Network, Transport, Session, Presentation, and Application. Although our primary focus will be IPsec VPNs, which are a Layer 3 VPN technology, it is important to understand IPsec VPNs within the context of other VPN technologies corresponding to different layers within the OSI stack. Figure 1-4 illustrates the OSI stack and provides some examples of VPN technologies that operate at each corresponding OSI layer Figure 1-4

VPN Technologies and the OSI Model

Open-Standard Interconnect (OSI) Model Layer

VPN Technology

Layer 7, Application

Secure HTTP (HTTPS) S/MIME, PGP

Layer 6, Presentation

N/A

Layer 5, Session

N/A

Layer 4, Transport

SSL and TLS SOCKS, SSH

Layer 3, Network

IPSec Deployments, MPLS VPNs

Layer 2, Data Link

VPDN-PPTP, L2TP, L2F ATM Cell Encryptors Frame-Relay Frame Encryptors

Layer 1, Physical

Optical Bulk Encryptors Radio Frequency (RF) Encryptors

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 confidentiality. Most VPDNs rely on the use of PPP to encapsulate data in transit across a common network infrastructure. Typical VPDN deployments consist of one or many PPP clients establishing a PPP session that terminates on a device at the opposite end of the tunnel, usually located at a central location within the enterprise or service provider edge. In doing so, a secure point-to-point tunnel is established from the client’s network to the PPP concentrator. After the tunnel has been established, the client's network appears as if it were the same network as the enterprise side, while the underlying common network infrastructure across which data is tunneled remains unchanged. Common VPDN technologies deployed in today’s networks include Layer 2 Forwarding Protocol, Point-to-Point Tunneling Protocol, and Layer 2 Tunneling Protocol.

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

L2F Data Packet Format UDP

L2F Encapsulation PPP Encapsulation

PPP Payload

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.

VPN Technologies

11

L2F Topology and Tunnel Establishment

Figure 1-6

PPP Client, Mobile Worker

Step 4 Step 2

NAS Step 5

Step 1

Cisco Secure ACS, ISP

Step 6

PPP Client, Branch Office PSTN/ISDN Connections

PPP Client, Telecommuter

PPP Client, Small Home Office

Cisco Secure ACS, Corporate

Home Gateway PPP Client, Mobile Worker

Step 3

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

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

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

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

NAS initiates a tunnel connection to the home gateway.

3.

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

4.

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

12

Chapter 1: Introduction to VPN Technologies

PPP Authentication with CHAP

Figure 1-7

Step 1: PPP CHAP Authentication Operation 1) Establish link (LCP); initiate PPP negotiation PPP Client, Small Home Office

2) Select CHAP as PPP authentication scheme

NAS

3) Acknowledge PPP authentication scheme 4) Challenge 5) Create one-way hash and use as response 6) Create one-way hash; verify client’s response; accept or reject connection

5.

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

6.

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

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

Point-to-Point Tunneling Protocol Point-to-point Tunneling Protocol (PPTP), a technology originally created by Microsoft, provides a seamless integration of remote PPP capable devices into an enterprise network. PPTP leverages authentication parameters inherent to native PPP and the tunneling capabilities of GRE to establish a VPDN. After a client has established a PPTP tunnel to a concentrator on a centralized enterprise network resource, that client appears as if it were part of the enterprise network itself, regardless of the underlying common infrastructure that the data is tunneled across. Consider the following exchange between a small remote office network (the PPP client) and a corporate VPDN (PPTP) concentrator. Figure 1-8 illustrates the order of operations executed when a client accesses the VPDN using PPTP. The PPP client in this scenario needs to connect to their enterprise network. The corporation’s security policy mandates that data be separated from the common service provider infrastructure and that central network connectivity provided by the service provider must remain transparent to the PPP clients, who are PSTN or ISDN attached. In order to accomplish this task, PPTP is used to provide an end-to-end tunnel for PPP connections inbound to the service provider.

VPN Technologies

13

PPTP Topology and Tunnel Negotiation

Figure 1-8

PPP Client, Mobile Worker Step 4 Step 3

PPP Client, Branch Office

Step 2 Step 1

PSTN/ISDN Connections

Service Provider Network NAS/PAC

PPP Client, Telecommuter

PPP Client, Small Home Office

Enterprise Network Gateway Router

PIX/PNS

PPP Client, Mobile Worker

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

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

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

2.

Now that the PPP client has accessed the service provider network, the client has IP connectivity to the PNS at its corporate headquarters. The PPP client and the PNS must maintain two connections to one another—a 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

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

3.

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

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

4.

Figure 1-9

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

Data Link Header

IP Header PPTP Header PPP Header

PPP Payload

Data Link Trailer

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

The preceding scenario describes a voluntary PPTP tunnel negotiation between the PPP client, which also acts as its own PAC, and the corporate PIX Firewall, acting as the PNS. In a compulsory PPTP tunnel negotiation, the NAS would act as the PAC and would multiplex multiple sessions

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. 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.

Figure 1-10

A PPTP Compulsory Tunnel Setup between PAC and PNS

PPP Client Step 4 Step 3 Step 1 Step 2

PPP Client

PSTN/ISDN Connections

PPP Client

Service Provider Network NAS/PAC

Enterprise Network Gateway Router

PIX/PNS

PPP Client

PPP Client

As depicted in Figure 1-10, only a single tunnel is negotiated between the PAC/PNS pair. In a voluntary exchange, it is possible that all 5 PPP clients dialing into the NAS terminate separate tunnels with the PIX/PNS. As such, compulsory tunnel architectures can be used to keep tunnel termination overhead low on the PNS. In the examples in this chapter, the voluntary tunnel negotiation option could yield up to five times the tunnel maintenance of a compulsory tunnel negotiation option (five PPP clients initiating tunnels to the PIX in a voluntary arrangement vs. one tunnel initiated from the NAS in a compulsory setting). Compulsory tunnels, however, do not offer end-to-end confidentiality with MPPE. In the preceding compulsory arrangement, the PPP connections to the NAS would remain unencrypted—only the connection from the PAC to the PNS would be encrypted with MPPE. As such, those network administrators requiring fully confidential exchange of data in their PPTP environments should choose to allow their clients to voluntarily negotiate an end-to-end PPTP tunnel with the PNS or, in this case, the corporate PIX Firewall. In doing so, the network administrator can ensure that all legs of the VPDN from their remote dialup hosts using PPP to their corporate PNS are encrypted for end-to-end data confidentiality.

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 tunnel—control 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

Data Link Header IP Header UDP Header

L2TP Header

PPP Header

PPP Payload

Data Link Trailer

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

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 customer’s dialup connection using PPP as the Layer 2 protocol. In this example, the access server also serves as the LAC. The LNS is located on the customer premises and terminates the L2TP tunnel originated from the LAC. Figure 1-12

L2TP Tunnel Negotiation Step 2

Cisco Secure ACS, ISP PPP Client, Mobile Worker Step 4 Step 3

NAS/LAC Step 1

Step 5

Service Provider Network

PPP Client, Branch Office Step 6

Cisco Secure ACS, Corporate

PSTN/ISDN Connections

PPP Client, Telecommuter

LNS PPP Client, Small Home Office

PPP Client, Mobile Worker

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

The user dials in to the NAS/LAC over PSTN or ISDN. The user establishes a PPP connection with the NAS and is authenticated with CHAP.

2.

The user initiates an L2TP tunnel and is prompted for a username and password. The ISP inspects the remote user’s username and authenticates it against its central authentication database via TACACS+ or RADIUS.

3.

Once authenticated, the LAC initiates an L2TP tunnel to the LNS located at their corporate facility.

4.

The LNS receives the request for tunnel negotiation and optionally authenticates the request against the corporate central authentication database via TACACS+ or RADIUS. The LNS responds with either an acceptance or a rejection of the tunnel initiation to the LAC.

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 traffic over a shared media through the use of VPN Routing and Forwarding Instances (VRFs). In an MPLS network, different devices play different roles to achieve this logical separation: ■

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

■

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

NOTE MP-BGP plays a critical role in the convergence of an MPLS VPN. For more information on MP-BGP and its role in MPLS VPNs, please refer to the following IETF RFC: http://www.ietf.org/rfc/rfc2547.txt

■

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

VPN Technologies

19

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

Traffic is IP-Routed to the Provider Edge (PE) C Customer Network C

CE PE Routers use MP-BGP to distribute VPNv4 routes to one another over the network of P routers.

IP Switched P

PE

IP Switched

IP Switched

Customer Network A

C

P CE

CE

PE

Label Switched 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 B

PE

C

PE

IP Switched CE Customer Network D

= VPN #1

= VPN #2

C

When the traffic from the customer edge reaches the PE router, it is then label switched across the MPLS Service Provider core to its destination PE router. In this manner, customer routing and IP addressing information is kept virtual and private from the provider core—the P routers use

20

Chapter 1: Introduction to VPN Technologies

MPLS labels and an associated LFIB entry to forward the traffic across the MPLS core rather than IP addressing information. When MPLS-switched traffic arrives at the destination PE router, traffic can be forwarded to neighboring CE routers based on the previously installed VPNv4 address learned from MP-BGP advertisements from neighboring MP-BGP–enabled PE routers. The CE routers perform IP RIB lookups to determine the appropriate destination and forwarding decisions within the customer core IP network. The operation of MPLS offers separation of multiple virtual data networks across a shared network such as an ISP. The addition of MPLS labels at the service provider core allows customers to separate networks from other customers virtually over a shared core network such as a service provider network. The use of route descriptors on PE nodes provides separation at the control plane, allowing customers to use overlapping address space and overlapping services that would normally present conflict within a non-MPLS environment. As mentioned previously, data-plane separation is achieved using VPN labels to make the forwarding decisions on PE routers.

IPsec VPNs IPsec VPNs encrypt data at the Layer 3 IP packet layer, offering a comprehensively secure VPN solution through providing data authentication, anti-replay protection, data confidentiality, and data integrity protection. As such, IPsec is one of the most widespread VPN technologies in today’s enterprise, service provider, and government networks. Using ESP in tunnel mode, IPsec supports the rewrite of Type of Service (ToS) bits into an outer IP header, thereby supporting encrypted data payloads while preserving quality of service (QoS) within a given network. IPsec is a standards-based protocol and therefore supports interoperability across products from multiple vendors. NOTE Although IPsec is standards based, there are many optional components of IPsec (not required for RFC compliance) and proprietary innovations that present compatibility considerations in multi-vendor environments. We will discuss these design considerations in greater detail in Chapter 8, “Handling Vendor Interoperability with High Availability.”

As we will discuss, IPsec is supported within Cisco IOS on a wide array of different routers, firewalls, VPN Service Modules, VPN concentrators, and VPN clients. Likewise, Cisco offers a variety of different hardware-based VPN acceleration options for enhanced VPN performance within a network. IPsec will serve as the primary VPN discussion point for the duration of this book. IPsec VPNs tunnel data across shared media using ESP, AH, or a combination of both. These two standards-based protocols both use symmetric encryption technology.

VPN Technologies

21

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

Transport Layer VPNs Transport layer VPNs provide an additional layer of security at the transport of the OSI stack. Transport layer VPNs typically consist of a client application and a server. A transport layer VPN will undergo a handshake to agree on common parameters to use for the SSL or TLS session, including cryptographic keying material and transforms. The messages in this handshake are confidentially exchanged between client and server, typically with a form of public key encryption such as RSA encryption. During the handshake, the client and server also agree on a set of symmetric session keys and a symmetric key transform, such as DES or 3DES, for bulk data encryption over the SSL VPN. Secure Socket Layer VPNs In today’s network architectures, Secure Socket Layer (SSL) VPNs represent one of the most popular choices for transport layer security. SSL was originally developed by Netscape in 1994 to secure client/server applications across the Internet. SSL is effective at providing data authentication, data integrity, and data confidentiality between client and server applications, but it does not offer data non-repudiation services. As discussed before, SSL is performed over TCP in the transport layer of the OSI stack, as illustrated in Figure 1-14. Figure 1-14

SSL and the OSI Stack Secure Socket Layer (SSL) Services Layer 4, Transport, TCP Layer 3, Network, IP Layer 2, Data Link Layer 1, Physical

22

Chapter 1: Introduction to VPN Technologies

SSL follows five broad steps when establishing a secure session—client 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

1

SSL Client

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

SSL Client

3 SSL Client

2 SSL Concentrator

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

SSL Client

SSL Concentrator

SSL Concentrator

4 SSL Concentrator

5

Session Authentication FINISHED Message • Hash of all exchanged messages executed in the handshake including the Client FINISHED message

5 SSL Concentrator

SSL Client

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

VPN Technologies

23

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

Client Exchange of Cryptographic Parameters—The 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 Parameters—The server responds to the CLIENTHELLO message with a SERVER-HELLO message and, optionally, several other messages: • SERVER-CERTIFICATE—Contains the servers’s public key for server authentication and pre-master secret encryption. • SERVER-KEY-EXCHANGE—Optionally used to encrypt the CLIENT-KEY-EXCHANGE message in Step 3 below. • CLIENT-CERTIFICATE-REQUEST—The SSL concentrator or server can optionally request a client certificate for authentication. If this message is sent to the client, the client’s server must be forwarded to the SSL concentrator and successfully validated. The SERVER-HELLO will specify the parameters to use for the SSL session, including the highest version ID and the strongest supported symmetric key cipher specified in the CLIENT-HELLO message from Step 1. At this point, the client and server should have the appropriate information necessary to agree on cryptographic parameters. A SERVERHELLO-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 Derivation—The client is now ready to generate and share its pre-master secret key with the SSL server. The pre-master secret is comprised of a 48-byte value (in the case where RSA is used). This value is then encrypted with the SSL server’s public key and forwarded to the SSL server using a CLIENT-KEY-EXCHANGE message. Optionally, the client will also forward two additional messages at this point in the SSL handshake: • CLIENT-CERTIFICATE—The client must possess a certificate and forward it to the server using this message if the client receives a CLIENT-CERTIFICATE-REQUEST in Step 2 above.

24

Chapter 1: Introduction to VPN Technologies

• CERTIFICATE-VERIFY—This message is a hash of all previous handshake messages appended. It is sent to the SSL server to validate the authenticity and data integrity of the CLIENT-CERTIFICATE message (and all other previous handshake messages) if the client receives a CLIENT-CERTIFICATE-REQUEST in Step 2 above. The SSL Server decrypts the CLIENT-KEY-EXCHANGE message to obtain the pre-master secret sent by the client. The client and server then derive the master secret by hashing the pre-master secret with the ClientRandom and ServerRandom values shared in Step 1. The master key is then used to derive 4 session keys that SSL will use to encrypt data: • Client Write MAC Secret—Client uses this key to create a hash appended to the original message; server uses this key to verify the hash. • Server Write MAC Secret—Server uses this key to create a hash appended to the original message; client uses this key to verify the hash. • Client Write Key—Client uses this key to encrypt messages; server uses it to decrypt messages. • Server Write Key—Server uses this key to encrypt messages; client uses it to decrypt message. The client concludes this phase of the SSL handshake by sending a CLIENT-FINISHED message to the server. The FINISHED message contains a hashed value of all previous messages in the handshake to this point. The server verifies this message to determine that the previous exchanges have indeed been authentic with preserved data integrity. 4.

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

5.

Confidential Exchange of Data with Preserved Integrity—The 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.

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 significant modifications, specifically with respect to support for different cryptographic algorithms, that make the two incompatible with one another. TLS has big implications in 802.1x identity-based networking systems, because extensible authentication protocol with TLS (EAP-TLS) is part of the 802.1x standard. Additionally, TLS is a critical component in wireless network security. Although not formally a component of the newly ratified 802.11i IEEE standard for wireless network security, EAP-TLS is the de facto means of authentication in 802.11i-compliant networks.

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

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

Simple Site-to-Site Design Scenario IPSec tunnel over routed links

IPSec tunnel over point-to-point link

Network A

Network B

Although the two IPsec tunnel implementations in Figure 1-16 use the same physical topology to accomplish a similar task, there is a significant difference between these two simple site-to-site VPN designs. For example, if a smaller router is used for the WAN connection, there could be a

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 flexibility to choose between the two tunnel deployments is enabled by the fact that IPsec VPNs operate at Layer 3, the network layer, of the OSI model. As such, VPNs are no longer limited to bulk data-link encryption techniques on physical point-to-point links. Instead, an IPsec VPN tunnel could be used to secure traffic between two endpoints over a series of routed networks. The simple design decision presented in Figure 1-16 is just an introduction to the wide array of design options that should be considered when securing a network with a Layer 3 VPN technology such as IPsec. Site-to-Site VPN connections are not only used to secure connectivity between two different organizations, but they are also used to secure links within an organization itself. As technology continues to evolve, network nodes such as routers and switches are becoming more and more capable of handling cryptographic operations involved with IPsec VPNs. As such, the growth of site-to-site VPNs within internal corporate enterprise networks has grown accordingly. Figure 1-17 shows a common network topology in enterprise network WANs—a 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. 3800 Series ISR

3745 Branch Router

l

ne

un

7200VXR Head-End

T ec

S

IP

el

unn

ec T

IPS

IPSe

IPSec over multiple L3 (routed) hops

c Tun

IPS

ec

Tu

nel

nn

el

2800 Series ISR

2651XM Branch Router

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

Common VPN Deployments

27

TIP In a hub-and-spoke topology, a dynamic multipoint VPN (DMVPN) configuration can help scale the number of security associations supported. DMVPNs use next hop routing protocol (NHRP) and multipoint GRE (mGRE) tunnels to establish direct security associations between the branches, as opposed to one security association (SA) from branch to head-end and another from head-end to the destination branch. Chapter 8 covers DMVPN in greater detail. Site-to-site VPN deployments are also popular in corporate extranets. When an organization requires dedicated site-to-site connectivity to a peer organization or subsidiary, often, a dedicated, high-speed WAN circuit is provisioned, not unlike the way Enterprise Network A is connected to Enterprise Network B in Figures 1-16 and 1-17. When an organization requires multiple dedicated external connections to other peer organizations, extranets are formed. Figure 1-18 illustrates an extension of the VPN topologies illustrated in Figure 1-16 and 1-17 to include a extranet deployment comprised of multiple site-to-site IPsec VPN tunnels. Corporate Extranet and Site-to-Site VPNs Branch_A

Branch_B

Corporate Extranet

Extranet Partner Network #1 Branch_D ne Tu n

IP

l

c

ne

Se

ec

n Tu ec

IP

Tun n

el

Se

l

cT un

IPSe

ne

l

c Tu

nne

l

Branch_C

IPS

Figure 1-18

S

IP

el

unn cT

el

e IPS

n un cT

e

IPS

IPSe

Extranet Partner Network #2

c Tu

nnel

IPS

ec T unn

el

IP

Se

Se

IP

IPS

Tu n

Se

l

l

c

ec

ne

ne

Extranet Partner Network #3

n Tu l

ne

ec IPS

nel Tun

nel Tun

Branch_D

Branch_H Branch_E

Branch_G

IP

c

cT un

Branch_F

Extranet Partner Network #4

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 components—the VPN client and the VPN concentrator: ■

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

■

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

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

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

Business Drivers for VPNs

Figure 1-19

29

RAVPN Implementation

RAVPN Infrastructure

IPSec Client, Mobile Worker

VPDN Infrastructure

PPP/VPDN Client, Mobile Worker

Corporate Extranet

PPP/VPDN Client, Small Home Office

IPSec Client, Telecommuter ISP (IP Network)

IPSec Tunnel

nel

el

c Tun

unn

IPSe

ec T

IPS

PPP/VPDN Client, Telecommuter

IPSec Client, Small Home Office IPSec Tunnel

PPP over PSTN/ ISDN

Extranet Partner Network #1 l

ne

IPSec Client, Branch Office

c

Se

n Tu

IP

l

nne c Tu

Enterprise Branch Infrastructure and DMZ

IPSe

Extranet Partner Network #2

IPSec Tunnels IPSe

c Tu

nnel

IPS

el

c

Se l

ne

n Tu

n Tu

Extranet Partner Network #3

l

ec

ne

IPS

el

n Tun

c

Se

ec

IP

IPS

IP Se cT un ne l

IP

ec T unn

el

n Tun

Extranet Partner Network #4

Business Drivers for VPNs As the amount of data that traverses untrusted, shared infrastructures continues to increase, so does the need for secure transmission of that data. Now that you've seen some introductory concepts related to site-to-site VPNs, here are some examples of real-world business applications for site-to-site VPN deployments. Global financial services organizations transfer billions of dollars worth of information across data links every day. Consider the common scenario of an institutional investor making a substantial equity trade based on real-time market data. The receiver of that instruction must be assured that the originator of the trade is authentic, or else millions of dollars could be lost by executing the transaction. Multiply the number of these types of transactions by thousands, and the economics of a VPN investment become apparent—the losses resulting from a single attack on such an institution could justify the investment required for the entire VPN deployment.

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 media—the service provider core. Retailers have responded by investing in transport-layer security mechanisms such as SSL to provide authentic, confidential exchange of data with ensured integrity. Providing VPN capabilities for additional security over connectivity to the retailer guarantees the private exchange of customer data, which is critical to consumer adoption of online ordering systems. Regional hospitals and large insurance companies have been mandated by law to ensure the privacy of patient’s medical information under the Health Insurance Portability and Privacy Act (HIPPA) of 1996. Consider the frequent communication of hospitals around the world to global health-insurance providers, and the need for large-scale deployment of site-to-site technologies becomes apparent. Health care providers represent just one element of critical infrastructure in which the demand for VPN technologies is growing. IPsec VPN solutions offer a robust and scalable solution to secure connectivity between hospitals and from hospital to insurance provider.

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

Site-to-Site VPN Business Drivers—A Practical Example In the previous example, we discussed how a standard RAVPN deployment can decrease direct labor costs by enabling greater efficiencies in a mobile workforce. While IPsec RAVPNs provide costs savings in one form, site-to-site IPsec VPNs can yield cost savings in a different form, by

IPsec VPNs and the Cisco Security Framework

31

decreasing the overall operation expenditures associated with the enterprise’s maintenance of its dedicated WAN circuits. Consider the case of an enterprise network in which the WAN architecture consists of a hub-andspoke model with 160 branch sites connecting to the enterprise’s headquarters over dedicated T-1 circuits. The enterprise’s IT staff is interested in migrating their dedicated T-1 circuits to ISP broadband connections, but they cannot do so unless their data is guaranteed to be confidentially transmitted between the branch offices and headquarters. The enterprise addresses this need for confidentiality by establishing IPsec VPN gateways at each remote branch location and by building a site-to-site IPsec VPN tunnel between each branch IPsec VPN gateway and a VPN gateway located at the corporate headquarters. The variable costs associated with the enterprise’s current dedicated circuit deployments are approximately $480/month for a single site. Business-class single-site broadband service offered to the enterprise has been quoted at approximately $35/month, yielding a decrease in variable costs of approximately 92.7 percent. Although there are added fixed costs associated with migrating to an ISP-based site-to-site IPsec VPN solution, such as the initial fixed costs of buying the IPsec VPN headend router and associated branch site IPsec VPN gateways, the decrease in variable costs ($71,200/month or $854,400/year) greatly outweighs the initial expenditures associated with the architectural shift.

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

Corporate Security Policy

Test

Monitor

Improve

Figure 1-20

32

Chapter 1: Introduction to VPN Technologies

This book explores many secure designs relying on IPsec for confidentiality, authentication, non-repudiation, and data authenticity. Those designs will incorporate many of the products that fit within various segments of the security wheel comprising Cisco’s end-to-end security product line, including firewalls, intrusion detection systems, authentication, authorization and accounting (AAA) technologies, policy management, and, most importantly, encryption technologies. With respect to Cisco’s overall security strategy, this book focuses on how the existence of IPsec helps to improve a corporate security policy and how IPsec can be deployed effectively to secure a network within the scope of that security policy. NOTE The security wheel is a common framework for developing a security policy. Cisco builds components enabling effective and comprehensive enforcements of all components of the security wheel. The Cisco Security Wheel is a component of the Cisco’s SAFE architecture. For more information on SAFE, please refer to the following URL: http://www.cisco.com/go/safe

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

Layer 2 VPDN technologies: L2F, L2TP, and PPTP

■

Layer 3 VPN technologies: MPLS, L2TPv3, and IPsec

■

Layer 4 VPN technologies: SSL and TLS

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

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

Summary

33

■

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

■

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

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

CHAPTER

2

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

Security Protocols

■

Key Exchange Mechanisms

■

Algorithms Required for Encryption and Secure Key Exchange

■

SA Definitions and Maintenance

In this chapter, we will introduce the cryptographic components and concepts necessary to understand how IPsec delivers on promises of secure transmittal of data across untrusted media. In order to understand the encryption algorithms and security protocols used by IPsec, one must first understand how encrypted messages are formed. In this chapter, we will discuss the basic elements of encryption that will clarify the cryptographic mechanisms used within the IPsec protocol suite. Additionally, we will explore IPsec’s establishment of secure data tunnels, IPsec VPNs, with other peers. IPsec employs the Internet Key Exchange (IKE) protocol to exchange keys. This chapter will cover the critical importance of IKE within the IPsec protocol suite and its role in establishing IPsec Security Associations (SAs). NOTE The IKE protocol is used within the Internet Security Association and Key Management Protocol (ISAKMP) framework. However, throughout the course of this text, especially when describing SA establishment, the terms IKE and ISAKMP will be used interchangeably.

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

36

Chapter 2: IPsec Fundamentals

Cryptographic processes use three basic components to deliver upon these criteria for success—a key, a cryptographic mathematical function (also called a cipher), and a message to be encrypted or decrypted. A one-thousand-foot view of the process is as follows: the message is fed into the cipher algorithm, which uses the key to transform the original message into a format that is undecipherable to anybody who does not possess the appropriate decryption key. As depicted in Figure 2-1, the exchange between James and Charlie relies heavily on encryption and decryption keys. In any cryptographic operation, these appropriate keys must be obtained in order to encrypt and decrypt messages. In some cases, the encryption key and decryption key may be one and the same. In other cases, they may be intentionally different from one another (one used for encryption, the other used for decryption). We will now explore how these two different types of encryption (symmetric and asymmetric) provide for data confidentiality in VPN deployments. Figure 2-1

Encryption—A One-Thousand-Foot View Plain Text

Plain Text

Test – ABCD1234

Test – ABCD1234

Cipher: RSA

Encryption Key

Cipher: RSA

Cipher Text: 4$h5*&FsW@4^%TY&^i*f

James

Decryption Key

Cipher Text: 4$h5*&FsW@4^%TY&^i*f

Charlie

Asymmetric Encryption In an asymmetric encryption scheme, each party derives a private and public key pair, as shown in the following text. As noted by the name, public keys can be exchanged securely with communications partners, while private keys must be kept secret. In asymmetric cryptographic operations, private keys are generally used to decrypt data, while public keys are used to encrypt data. In the scenario depicted in Figure 2-2, James and Charlie will exchange public keys to encrypt traffic to one another. James will then use Charlie’s public key to encrypt his message to Charlie, and Charlie must use his private key to decrypt the message. The same operation will transpire in the future when Charlie replies to James—Charlie’s reply will be encrypted with his James’ public key, and James will have to use his private key to decrypt Charlie’s reply. Thus the requirement for James and Charlie to exchange public keys before any encrypted communication can take place. Of critical importance is that these public keys be exchanged securely and only between the appropriate parties. As we will see in later sections, effective methods exist to guarantee the authenticity of key exchange across untrusted media.

Overview of Cryptographic Components

Figure 2-2

37

Asymmetric, Public Cryptographic Setup and Key Exchange Message: Test Send – ABCD1234

James

Charlie

Private Key, James

Private Key, Charlie

Public Key, James

Public Key, Charlie

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

Exchanging Messages with Asymmetric Cryptography

1

2 Public Key, Charlie

Message: Test Send – ABCD1234

Private Key, Charlie

Encrypted Message Cipher:

Cipher:

@#4w{3%d2q@!#4a

RSA

RSA

Encrypted Message @#4w{3%d2q@!#4a

Encrypted Message

Decrypted Message

@#4w{3%d2q@!#4a

Test Send – ABCD1234

James

James

Charlie

3

Charlie

4 Public Key, James

Encrypted Message 3A&s(}”>s,%43Sf*5

Private Key, James

Message: Cipher: RSA

Cipher:

Test Reply – ZYXW9876

Encrypted Message

RSA

3A&s(}”>s,%43Sf*5

Encrypted Message 3A&s(}”>s,%43Sf*5

James

Charlie

Message: Test Reply – ZYXW9876

James

Charlie

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 Charlie’s public RSA key.

2.

Charlie receives the message from Step 1 and decrypts it with his private RSA key.

3.

Charlie crafts a response to James and encrypts it with James’ public RSA key.

4.

James receives the message from Step 3, and decrypts it with his private RSA key.

The original message never crosses the shared media in cleartext. Confidentiality is maintained, in that intermediary parties that exist between Charlie and James are unable to view the original, unencrypted message contents as they do not possess the required private key for 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 Charlie’s reply. Let’s now have a look at the effect of a compromised public key in the exchange between James and Charlie in Figure 2-4. Figure 2-4

An Attempt to Compromise an Asymmetric Key Cryptosystem 1 James sends Public Key to Charlie.

Public Key, James

2

Olivia intercepts James’ Public Key.

Private Key, James Encrypted Data Encrypted Data

3

Charlie sends Public Key to James.

4

Private Key, Charlie

Olivia cannot decrypt encrypted data sent from James to Charlie. Only Charlie’s Private Key can decrypt data encrypted with Charlie’s Public Key.

4

Public Key, Charlie

Olivia cannot decrypt encrypted data sent from Charlie to James. Only James’ Private Key can decrypt data encrypted with James’ Public Key.

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 key—she cannot decrypt messages from him.

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

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

James crafts a message to be sent to Charlie. Note that, in this step, James and Charlie are preconfigured with a shared, symmetric, key used for both encryption and decryption.

2.

James encrypts the message crafted in Step 1 with his shared symmetric key and forwards the ciphered message to Charlie.

3.

Charlie decrypts the message received in Step 2 with his shared symmetric key, making the original cleartext message available for interpretation.

Unlike asymmetric encryption, the shared secret key used in symmetric encryption is used not only to encrypt data, but also to decrypt the data. James begins the exchange by using his shared, secret key to encrypt his message to Charlie. Because the operation is considered to be symmetric, James and Charlie have identical keys for encryption and decryption. Now that Charlie has James’ message, Charlie uses the secret key shared between James and Charlie to decrypt the message.

40

Chapter 2: IPsec Fundamentals

Figure 2-5

Symmetric Key Encryption 1

Message: Test Message – ABCD1234

James

Charlie

Shared Secret Key

Shared Secret Key

2 Shared Secret Key

Message: Test Send – ABCD1234

Encrypted Message Cipher: AES

@#4w{3%d2q@!#4a

Encrypted Message @#4w{3%d2q@!#4a

James

Charlie

3 Shared Secret Key

Cipher: AES

Encrypted Message @#4w{3%d2q@!#4a

Decrypted Message Test Message – ABCD1234

James

Charlie

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

Overview of Cryptographic Components

41

NOTE Transforms used in IPsec Security Associations, such as Data Encryption Standard (DES), 3DES, and AES, are symmetric encryption algorithms. As such, IPsec relies heavily on symmetric key encryption to deliver confidential exchange of data. Let’s return to Olivia’s attempt to compromise the confidential communication between James and Charlie. This time, Olivia intercepts the symmetric key that James and Charlie share for both encrypting and decrypting data communications between them. In this case, Olivia does not need an additional key to talk with James and Charlie—the symmetric key is sufficient to both encrypt and decrypt data to and from both James and Charlie. When comparing Figure 2-6 with Figure 2-4, the simplicity of Olivia’s man-in-the-middle attack on James and Charlie’s symmetrically encrypted conversation relative to their asymmetrically encrypted conversation can be observed. An Attempt to Compromise a Symmetric Key Cryptosystem

Figure 2-6

1

2

Symmetric Key

Symmetric Key Encrypted Data Encrypted Data

3

Unlike asymmetric cryptographic operations, symmetric key transforms are more susceptible to attack if a symmetric key becomes compromised. For this reason, symmetric keys are typically not exchanged over an untrusted medium. Instead, they are typically derived over a secured medium. NOTE As we will discuss later in this text, IPsec uses the Diffie-Hellman algorithm to derive shared secret keys for bulk data encryption with a symmetric key transform. Diffie-Hellman is facilitated over a trusted channel secured with IKE. The following order of operation describes the effect of a compromised symmetric key illustrated in Figure 2-6. 1.

James and Charlie create and share symmetric transform keys over an untrusted medium.

2.

Olivia intercepts the symmetric key shared between James and Charlie in Step 1 above.

3.

Olivia can now encrypt and decrypt messages to and from James and Charlie. This enables her to eavesdrop on conversations between James and Charlie. She is also able to falsely impersonate James and Charlie and craft messages to and from both of them.

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 fixed-length code. The fixed length code is then appended to the original message before transmission. A basic hashing function consists of an algorithm and a key that is known to both sender and receiver, as described in the scenario between James and Charlie illustrated in Figure 2-7. Before sending his message to Charlie in Step 1 of Figure 2-7, James performs a mathematical operation, or hashing function, on the original message. The output of that mathematical operation is called a hash value, or message digest, which is then appended to the original message and sent to Charlie. In Step 2 of Figure 2-7, Charlie then removes the hash value from the original message and runs the same hash operation on the original message received. Charlie then compares his hash value with the one that James had sent appended to the original message. If the two hash values match, then Charlie can be assured that the message’s integrity has not been compromised. That is to say that James’ message to Charlie has not been modified and has not been spoofed by a source other than James himself. Although message digests provide data integrity, they do not provide message authenticity unless the original message is hashed with a secret key shared between the two endpoints. This operation is commonly used in routing protocol authentication and also in the creation of hashed message authentication codes (HMACs) used for bulk data encryption by a symmetric key transform defined an IPsec SA. In order for a hash to effectively provide data integrity, the hash operation must have the following characteristics: ■

Identical input messages must consistently yield the same output.

■

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

■

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

■

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

■

Each unique input message should yield a unique output value.

Overview of Cryptographic Components

Figure 2-7

43

Creating and Verifying a Message Digest 1 Shared Secret Key Message:

Hash Value:

Test Message: Charlie, are you there?

Hash: MD5

Fsd$#^@43#@Ad5J$

Hash Function/Algorithm Message: Test Message: ABCD1234

Hash Value: Fsd$#^@43#@Ad5J$

James

Charlie

Shared Secret Key

Shared Secret Key

2 Shared Secret Key

Hash Value: Hash: MD5

Fsd$#^@43#@Ad5J$

Hash Function/Algorithm

Hashes match: Message authentic w/integrity

Message: Test Message: Charlie, are you there?

Hash Value: Fsd$#^@43#@Ad5J$

James

Charlie

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 varies—MD5 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.

44

Chapter 2: IPsec Fundamentals

NOTE Although SHA-1 and MD5 are 160- and 128-bit computations, respectively, the length of the resulting hash is sometimes truncated to 96 bits in length in transmission. Secure Cisco networks use hashing operations for a variety of things, including routing protocol authentication and in various applications of IPsec and IKE. Within the IPsec framework, hashing algorithms are used when appending message digests to the messages exchanged to generate shared secret keys during IKE, when collaborating with a certificate authority, when building Digital Signatures, and when computing a keyed message authentication check for shared secretkey 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-themiddle attacks. Digital Signatures use a combination of hashes and asymmetric encryption in order to secure the integrity of the hash exchanged between two peers. Preserving data integrity ensures that a message has not been altered or compromised en route to its destination. A Digital Signature is an encrypted form of a hashed message. As such, a Digital Signature can be verified only by those parties containing the necessary public key that corresponds to the private key used to encrypt the hash. Therefore, if the Digital Signature is verified, its source is deemed to be authentic, as the public key would not decrypt a message digest value encrypted by a different private key. Consider again the exchange of a message between two routers, James and Charlie. A Digital Signature can be used to provide an additional level of authenticity over a standard hash. The first step that James takes to create the Digital Signature of his original message is derivation of a public and private key pair associated with the original message. Figure 2-8 illustrates the process of creating and validating a Digital Signature. 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.

Overview of Cryptographic Components

45

Generating and Verifying a Digital Signature

Figure 2-8 1

2 Public Key

Message:

Private Key

Hash Value:

Test Message: Let’s go get some lunch

Hash: MD5

Hash Value:

Fsd$#^@43#@Ad5J$

DIGITAL SIGNATURE

Cipher:

Fsd$#^@43#@Ad5J$

RSA

Hash Function/Algorithm Message:

Message:

Test Message: Let’s go get some lunch

Test Message: Let’s go get some lunch

Hash Value:

DIGITAL SIGNATURE

Fsd$#^@43#@Ad5J$

Charlie

James

James

Private Key

Public Key

Public Key

Private Key

3

James forwards original message to Charlie

Encrypted Hash, or Digital Signature is appended to the message and forwarded to Charlie

Charlie

James’ Public Key is forwarded to Charlie to decrypt the Digital Signature

4 Public Key

Message:

Public Key

Test Message: Let’s go get some lunch

Hash Value: Decipher RSA

DIGITAL SIGNATURE

Hash: MD5

Hash Function/Algorithm Message: Test Message: Let’s go get some lunch

Hash Value: Fsd$#^@43#@Ad5J$

James

Charlie

James

Fsd$#^@43#@Ad5J$ Hashes match: message authentic w/integrity

Hash Value: Fsd$#^@43#@Ad5J$

Charlie

Up until this point in the exchange, the process of creating a hash value and creating a Digital Signature has been identical, save one item—James’ 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 exist—private keys are used for encryption, and public keys are used for decryption. Digital Signatures typically follow this behavior—private keys are used to encrypt, and public keys are used to decrypt, contrary to typical asymmetric key usage.

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 fingerprint of the original message—it is derived from the original message through a hash function and encrypted for data integrity and authenticity as James’ public key is the only key that can be used to decrypt the hash value. James must therefore securely forward his public key to Charlie so that Charlie can decrypt the hash for verification. When Charlie receives the original message, a Digital Signature, and public key from James, he must attempt to verify the authenticity and integrity of the message. Charlie’s first task is the decryption of the Digital Signature that James had sent with James’ public key. The output of this decryption process should be the message digest of the hash of James’ original message. After decrypting the Digital Signature, Charlie now has the original message digest of James’ original message. Charlie can now hash James’ original message and compare the resulting message digest to the newly decrypted message digest that was sent by James. If the two message digests match, the message is believed to be authentic, with preserved integrity.

Public Key Encryption Methods In almost every form of commercially available cryptographic scheme, which would include all of the components used in IPsec, the cipher used is generally known. It is the key that is used within the cipher that makes the encryption harder to crack. Consider the asymmetric key encryption scheme used by James and Charlie. Charlie and James must have each other’s public key to encrypt communications that are decipherable by the other party. Let’s say that another party, Olivia in this case, decided to play a trick on James and Charlie by convincing them that she was Charlie and James, respectively. Figure 2-9 illustrates how a public key can be compromised by a user inserting themselves between two cryptographic endpoints. Charlie’s keypair has been compromised. Olivia can now send messages to Charlie and decrypt messages from Charlie originally intended for James and vice versa. The type of attack that Olivia executes on James’ and Charlie’s conversation is typically referred to as a man-in-the-middle attack. The steps in Figure 2-9 are as follows: 1.

Olivia authenticates herself to Charlie as James and to James as Charlie. Charlie and James intend to exchange their public keys with one another. But, because Olivia has authenticated as James to Charlie and as Charlie to James, James and Charlie actually exchange public keys with Olivia.

2.

James encrypts a message to Charlie with Olivia’s public key, thinking that he is using Charlie’s public key, and transmits it to Olivia unknowingly.

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 Charlie’s public key and forwards it on.

5.

Charles receives the message from Olivia, thinking it was from James. Charlie then uses his private key to decrypt the message and reads the altered message sent by Olivia in Step 3.

Figure 2-9

Compromised Keys in an Asymmetric Exchange Message Altered

Message:

New Message:

Go Tar Heels!

Go Tar Heels!

2 James

3

Go Blue Devils!

Go Blue Devils!

4

5

1

1

Hi, I’m Charlie, give me your public key so that we can talk.

Hi, I’m James, give me your public key so that we can talk.

Charlie

Public Key, James

Public Key, Charles

Private Key, James

Private Key, Charles Public Key, Olivia Private Key, Olivia

Olivia

Apply this type of attack to an exchange of financial account information between large global financial organizations, the exchange of patient health care records between regional hospitals and their insurance providers, or a customer and retailer exchanging credit card information over the Internet, and it becomes apparent why it is absolutely critical that the keys used in the exchange of encrypted data be exchanged securely and privately. ISAKMP employs several operations to protect the authenticity and integrity of cryptographic keys. There are generally three different methods for doing so, all of which will be discussed later in this chapter—Preshared Authentication Keys, RSA Encrypted Nonces, and RSA Signatures. As we’ll discuss at several points throughout this text, many of these methods are secured by the computational difficulty of factoring two large prime numbers. Let us begin our exploration of these techniques by discussing the RSA encryption algorithm.

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 defined IKE preshared keys (see Figures 2-4 and 2-6 for the added value of asymmetric cryptography). Consider the exchange of information between James and Charlie in Figure 2-9. Figure 2-10 shows how the encryption and decryption processes work when using RSA encryption. 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.

Public Key Encryption Methods

Figure 2-10

49

Encrypting Data with the RSA Encryption Algorithm 1 RSA Pub James (E = 11, M = 15) RSA Private James (D = 3)

James

Charlie

Random Prime #1, (P) = 5 Random Prime #2, (Q) = 3 Modulus (M) = (P) × (Q) = 15 Encryption Exponent (E) = 11 Decryption Exponent (D) = 3

2 RSA Pub James (E = 11; M = 15)

RSA Private James (D = 3)

James

3

Charlie

Clear Text:

Clear Text:

Charlie – did you catch the Saints’ game last night?

Charlie – did you catch the Saints’ game last night?

Decryption Cipher = [(CT) ^ D] mod M

Encryption Cipher = [(PT) ^ E] mod M

Cipher: RSA

RSA Private James (D = 3, M = 15)

Cipher: RSA

Cipher Text: f8desa0RQ(eQW*()SD

James

3.

RSA Public James (E = 11, M = 15)

Cipher Text: f8desa0RQ(eQW*()SD

Charlie

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

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 difficulty of factoring large numbers. As such, encryption mechanisms that effectively use the RSA algorithm use values for P and Q of at least 100 decimal values in length. NOTE Cisco manufactures crypto engines that can support key length (modulus) sizes of up to 2048 bits in length. As we’ve discussed, generation of RSA key pairs can be computationally expensive. The longer the key modulus selected when generating RSA keypairs, the longer it takes the processor to generate the keys. RSA encryption is useful in certain site-to-site VPN topologies. However, as the number of crypto peers scales upwards, the maintenance of RSA keypairs can become cumbersome, both in terms of processor load on network devices and in terms of key maintenance and administration required. In order to solve these issues, RSA signatures can be deployed to increase the scalability of an RSA encryption environment and ease the administrative overhead required to maintain the RSA-encrypted environment without sacrificing the cryptographic strength delivered by deploying the RSA encryption algorithm. RSA Signatures IPsec crypto endpoints running Cisco IOS support authentication using RSA Signatures using X.509-based Certificates and Certificate authorities. This method of authentication, though more complicated to configure, offers a more scalable configuration alternative to RSA encryption and preshared keys. Crypto endpoints using RSA signatures use X.509 certificates to authenticate and enroll with the CA. Using a central resource for authentication services, the Certificate Authority, simplifies maintenance on both crypto endpoints. This is particularly useful in large networks, as

The IP Security Protocol (IPsec)

51

administrators now configure each crypto endpoint to use the CA for authentication, instead of manually configuring preshared keys for each peer. Cisco IOS supports RSA signatures when negotiating ISAKMP SAs. The operation and configuration of crypto endpoints using RSA signatures is covered in greater detail in Chapter 11, “Public Key Infrastructure and IPsec VPNs.”

Diffie-Hellman Key Exchange Network infrastructures are increasingly relied on for transferring bulk amounts of data, which lends itself more to a symmetric crypto solution. Given this trend, many network architects turn to the Diffie-Hellman algorithm to securely derive shared keys across an untrusted network infrastructure. NOTE Diffie-Hellman is a core component of the IKE protocol. Aspects of the DiffieHellman algorithm will be covered in additional detail in the IKE and perfect forward secrecy (PFS) section of this chapter. Diffie-Hellman key exchange was designed for crypto endpoints to derive shared secret session keys across unsecured media. The shared secret keys are negotiated between crypto endpoints dynamically. As such, administrators need to specify only the prime modulus (MODP) size for use in the Diffie-Hellman exchange. IKE uses Diffie-Hellman keys to encrypt the ISAKMP SA over which IPsec SAs are established. Likewise, Diffie-Hellman is used to generate keys to be used in the ciphers specified in IPsec transforms. These transforms, when used in conjunction with DiffieHellman keys, will be used by IPsec to encrypt and decrypt data as it passes through the VPN tunnel.

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

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

An Overview of IPsec Mechanics

1

2

Cryptographic Components

3 IPSec Components

Apply cryptographic components to IPSec fundamentals (cipher, SA construct)

Security Association and Key Management

Clarify SA and Key Management concerns within IPSec framework (ISAKMP, DiffieHellman, xauth and mode config)

IPsec Modes IPsec uses two different modes to establish a secure communication channel between network nodes—Transport Mode and Tunnel Mode. The secure communications channel that IPsec provides is commonly referred to as an IPsec SA. IPsec and IKE SAs are discussed in greater detail later in this chapter. NOTE IPsec security associations are unidirectional. As such, when two cryptographic endpoints use IPsec to create a secure communications channel between each other, there are two IPsec SAs involved—one in each direction. IPsec modes have different applications in different architectures. This is due largely to the fact that tunnel and transport modes protect different parts of the IP packet, yielding different degrees of confidentiality. The key choice in selection of an IPsec operational mode is determination of what parts of IP headers and payloads are to be kept confidential. Transport Mode RFC 2401 defines a transport mode SA as one that connects two IPsec hosts together. In IPsec transport mode SAs using Encapsulating Security Payload (ESP), only upper-layer protocols are kept

The IP Security Protocol (IPsec)

53

confidential. This is because the ESP-encapsulated payload starts after the IP header and options. Figure 2-12 illustrates the resulting format of an ESP-encapsulated IP packet using transport mode. Figure 2-12

An ESP-Encapsulated IP Packet Using Transport Mode IP Header

ESP TCP Header Header

ESP Trailer

Data

ESP Auth.

Encrypted

Authenticated

Unprotected

Unprotected

Tunnel mode places the ESP header before the IP header, offering confidentiality for IPencapsulated 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

VC2

I can’t see the original source and dest IP addresses, so I can’t use WFQ to hash them in to the correct conversation!

VC3 VC5

VC1

VC4

ATM OC3 (VC’s 1, 2, 3, 4, and 5)

James

Kristen

Charlie

Sent on VC4 to James Outer IP Header

ESP Header

Original IP Header

TCP Header

Data

ESP Trailer

ESP Auth.

All of my original souirce and destination addresses are now the tunnel source and destination address located in the Outer IP Header.

54

Chapter 2: IPsec Fundamentals

TIP Using the QoS preclassify feature in IOS 12.1T or later IOS can preserve the operation of Weighted Fair Queuing on the IPsec endpoint. If the SA created in Figure 12-13 between James and Charlie were transport mode, the original source and destination addresses would be visible. If inner IP header information is not deemed to be confidential information by security administrators, then transport mode can be employed to maintain per-conversation QoS consistency. Note that the scenario above describes one such inconsistency between IPsec and QoS techniques in IP networks, but there are others. We will discuss challenges of designing QoS into an IPsec VPN in greater detail in Chapter 4, “Common IPsec VPN Issues.” Tunnel Mode Tunnel mode IPsec SAs have different protection boundaries from transport mode SAs. In a tunnel mode SA, not only are upper-layer protocols afforded confidentiality services, but the IP header information is also protected. IP communications are maintained within the IPsec tunnel by creating an “outer” IP header that is prepended to the outside of the ESP-protected boundary. Figure 2-14 illustrates the format of an ESP-encapsulated IP packet in tunnel mode. Figure 2-14

An ESP-Encapsulated IP Packet Using Tunnel Mode Note: Original IP Header kept confidential, encapsulated in ESP. Outer IP header prepended maintain IP connectivity.

Outer IP Header

ESP Original IP TCP Header Header Header

Data

ESP Trailer

ESP Auth.

Encrypted

Authenticated

Unprotected

Unprotected

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

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 confidentiality services by executing a transform on plain text data. Common ciphers used in the IPsec transforms are DES, 3DES, and AES. All of these transforms conform to specifications for IPsec’s symmetric-key cryptographic requirements per RFC 2401. Another item that all of these transforms have in common is that they can all be deployed in using ESP, authentication headers (AH), or a combination of the two. ESP ESP provides a combination of security services for IPsec-processed IP packets. Examples of the services offered by ESP include data confidentiality, data origin authentication, data integrity assurance mechanisms, and data flow confidentiality. The services offered by ESP depend on which services are negotiated during IPsec security association establishment. As such, any service, or combination of services, can be selected by the administrator before SA negotiation takes place. ESP can be deployed in transport or tunnel mode. Additionally, it can be deployed alone, or in conjunction with authentication headers. Encryption—Message and Traffic-Flow Confidentiality ESP provides confidentiality services by allowing the use of popular symmetric key encryption ciphers such as DES, 3DES, and AES. Assuming that a user selects DES as their transform cipher, the encrypting device would take input data at 64-bit blocks and encrypt them using a key 56 bits in length. ESP would then “wrap,” or encapsulate, the ciphered payload with an ESP header (IP protocol number 50). The 64-bit blocks of the original message can be chained together using cipher block chaining (CBC) or CFB, yielding greater antireplay and data integrity protection. The format of an ESP-processed IP packet varies based on which IPsec transform mode is selected. In transport mode, the header is placed before the ciphered payload, and after the IP header. As such, ESP in transport mode offers only confidentiality protection for Layer 4–7 protocol information—it is effective at providing confidentiality to the IP-encapsulated payload of the original message. To increase the protective boundary of ESP on a per-packet basis, administrators can select tunnel mode when defining their IPsec transforms. ESP in tunnel mode includes the original IP header in the ciphered payload. The ESP header is placed before the ciphered inner IP header, and after the cleartext outer IP header. As such, IPsec in tunnel mode protects the source and destination of the IP traffic flows themselves, in addition to Layer 4–7 protocol information protected in transport mode.

56

Chapter 2: IPsec Fundamentals

NOTE 3DES and AES are considered to be stronger encryption ciphers than DES, as they use longer encryption keys (128-bit key for 3DES and 256-bit key for AES). However, they are also more computationally expensive, and administrators should therefore carefully balance the need for confidentiality with the cost of their VPN infrastructure. Each ESP packet is marked with a security parameter index (SPI). The SPI enables encrypting and decrypting devices to understand which SA the ESP packet belongs to. SPIs are a 32-bit arbitrarily derived by the destination IPsec peer during IKE. Using SPIs to identify the packet’s appropriate SA is critical, as each SA may be processed under a variety of different parameters, such as selected encryption transforms and Diffie-Hellman keys. In addition to the SPI, a sequence number is created for each ESP packet. Sequence numbers increase incrementally, per packet, offering built-in antireplay protection for ESP-processed traffic in both tunnel (Figure 2-14) and transport mode (Figure 2-12). Data Authentication and Integrity ESP defines a built-in authentication header, in the form of a Keyed-HMAC. This HMAC is inserted in to the ESP header to provide data integrity and authentication services to the ESPprocessed traffic. In the context of IPsec, an HMAC would be specified as part of the transform selected. IPsec provides us with all of the ingredients necessary for building an HMAC, such as a shared secret key (typically derived through Diffie-Hellman exchange), a hash function (IPsec RFC accepts MD 5 and SHA-1), and fixed message input. NOTE Message input for creating an HMAC, in this case, is the ciphered format of the original message, as ESP authentication always occurs after encryption.

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

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

Message is broken in to 512-bit blocks.

2.

Shared secret key is x-or’d with specified array to create “K1.”

3.

(First Message Block + K1) is hashed with a specified hash function (such as MD 5 or SHA-1) to create “Hash1.”

The IP Security Protocol (IPsec)

4.

Shared secret key is x-or’d again with another specified array to create “K2.”

5.

(Hash1 + K2) is hashed with a specified hash function to create “Hash2.”

6.

Shared secret key is x-or’d again with another specified array to create “Kn.”

7.

(Hashn + Kn) is hashed with a specified hash function to create “Hash(n+1).”

57

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

As we’ve discussed before, symmetric key algorithms used in ESP can leverage mechanisms such as CBC to securely chain ESP-processed packets together. CBC leverages ensure that repetitive plain text input does not yield identical cipher text within the same sequential block. This is accomplished by including a feedback step that chains blocks together in a sequence. The feedback for the first block in the sequence is referred to as the Initialization Vector (IV), and is derived randomly. Symmetric key transforms using CBC protect data from the malicious insertion of data between chained blocks and from the malicious derivation of plain text input into a non-CBC chained cipher text stream. AH When confidentiality is not required, administrators can choose to deploy IPsec with AH, instead of with ESP. IPsec AH was created with the intention of providing data authenticity and integrity services to as much of the IP packet as possible. IPsec AH yields data authenticity, antireplay, and data integrity services by appending an additional field, called the authentication header, protecting the data payload and parts of the original IP header. Unlike ESP, however, IPsec AH does not provide data confidentiality. Because AH authenticates parts of the IP header, AH protects both upper- and lower-layer information within the IP header, while ESP protects only upper-layer protocols in transport mode. Figure 2-15 illustrates the format of an IP packet encapsulated with Authentication Headers using transport mode. Figure 2-15

IPsec Authentication Headers in Transport Mode IP Header

Authentication TCP Header Header

Data

Authenticated

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

58

Chapter 2: IPsec Fundamentals

Figure 2-16

IPsec Authentication Headers in Tunnel Mode Outer IP Header

Authentication Header

Inner IP Header

TCP Header

Data

Authenticated

Like ESP encapsulation, AH encapsulation also employs SPIs so that the appropriate SA can be located for a given IP packet. IP Payload Compression Protocol (IPPCP) and LZS When deploying confidentiality services using IPsec, encrypting the IP payloads renders many lower-layer protocol compression mechanisms, such as PPP Compression Control Protocol, ineffective. IPComp provides a framework for compressing IP packets in VPN environments that use encryption for confidentiality purposes. IPPCP compresses the IP datagram in full, including IP header. In this process, an IPPCP header is inserted immediately before this new IPPCPcompressed 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 Original IP Header

IPComp Header

Data

Compressed

Note: 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.

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 stateless—the decompression and compression of a given packet does not depend on any other packet being processed. Lempel Ziv Stac (LZS) is a very efficient compression algorithm that is being used in conjunction with IPComp in many VPN operations. LZS is capable of compression strings as short as two octets in length. In order to effectively support compression in IPsec environments that use encryption for confidentiality, compression of the data payload must occur before the packet is compressed.

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 efficient mechanism for compressing encrypted IP packets, but it also cleanly and securely integrates into IPsec negotiation using ISAKMP and IKE.

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

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

■

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

■

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

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

Matched Traffic—IPsec peers must be configured to encrypt and decrypt sets of the same data; otherwise, the endpoints of the IPsec tunnel will fail to negotiate an IPsec SA. If James specifies encrypted data that is outside of Charlie’s data set to be decrypted from James, then the IPsec will reject the SA establishment. If James specifies encrypted data that matches Charlie’s set of decrypted data, then the IPsec will accept the SA. Figure 2-18 illustrates a scenario in which IPsec SA negotiation fails due to a traffic set mismatch defined in the cryptographic endpoint’s crypto ACLs.

60

Chapter 2: IPsec Fundamentals

Figure 2-18

IPsec Traffic Set Mismatch and SA Negotiation 1 Traffic going from Workstation A to Workstation B matches the James crypto map ACL

Encrypted Traffic from James does not match Charlie’s decryption scope

IPSec SA Negotiation

20.0.0.0/8

Serial2/0 10.0.0.0/8 .1

Serial2/0 10.0.0.0/8 .2

James I want to encrypt traffic from 20.0.1.0/24 to 30.0.0.0/8

Workstation A 20.0.1.1/24

Charlie’s Scope of Encryption

Charlie

30.0.0.0/8

I want to encrypt traffic from 30.0.1.0/24 to 20.0.1.0/24

James’ Scope of Decryption

Workstation B 30.0.100.1/24

IPSec SA Negotiation

2

20.0.0.0/8

Serial2/0 10.0.0.0/8 .1

James I want to encrypt traffic from 20.0.1.0/24 to 30.0.0.0/8

Serial2/0 10.0.0.0/8 .2

Charlie

30.0.0.0/8

I want to encrypt traffic from 30.0.0.0/8 to 20.0.1.0/24

James’ Scope of Decryption matches Charlie’s Scope of Encryption and vice-versa. As such, IPSec accepts the proposed ranges of addresses from James and Charlie.

■

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

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

The IP Security Protocol (IPsec)

■

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

10.0.0.0/8

I must support IPSec SAs for all valid peers. I therefore use SPIs to uniquely identify these SAs.

Kristen

ATM3/0 Includes Subinterfaces A3/0.1, .2, and .3 Includes ATM VC’s 1, 2, and 3.

ATM3/0.1 VC1

ATM3/0.3 VC3

0/ 1. 1. 0.

James

IPSec Transform: AH, DES Cipher SHA-1 HMAC Authentication.

20.0.0.0/8

IPSec Transform: ESP, AES Cipher MD5-HMAC Authentication.

17

0.

1.

170.1.1.4/30

30

ATM3/0.2 VC2

17

Figure 2-19

61

1.

8/

30

Ziggy

40.0.0.0/8

Charles

IPSec Transform: ESP, AES Cipher

40.0.0.0/8

62

Chapter 2: IPsec Fundamentals

IPsec SAs are unidirectional—in one direction only. As such, an IPsec tunnel must establish at least two SAs—one from source to destination and one from destination to source. NOTE IPsec requires the negotiation of a unique SA for each direction of the IPsec tunnel and for each protocol used (AH, ESP, or combination thereof).

Within the IPsec protocol suite, there is another, different, type of SA that must be negotiated before an IPsec SA can be negotiated—the 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. IKE and IPsec SA Negotiation

Figure 2-20

4 3 2 5

1

20.0.0.0/8

Serial2/0 10.0.0.0/8 .1

James

Serial2/0 10.0.0.0/8 .2

Charlie

30.0.0.0/8

Workstation A

Workstation B

20.0.1.1/24

30.0.100.1/24

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

James receives a packet that meets the criteria for encryption, triggering the IKE SA negotiation.

2.

The two routers, James and Charlie, authenticate with each other by exchanging Manually Defined Preshared keys, RSA Encrypted Nonces (public only), or CA-signed RSA Certificates. An IKE SA is formed between the routers.

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 Diffie-Hellman to establish a shared session key. As a part of the negotiation, the two peers will assign a unique SPI that will identify the encrypted packets in each established SA. This SPI number will be included in the IPsec encapsulation of every encrypted packet.

4.

The cleartext packets can now be encrypted using the agreed symmetric key transfer negotiated in Step 3; James encrypts the subsequent traffic from Workstation A accordingly and forwards to Charlie.

5.

Charlie, on receiving the packet, looks up the SPI to find out how to decrypt the packet. The encrypted payload is decrypted. Charlie uses the inner IP header to forward the unencrypted IP packet to its final destination.

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

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

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

64

Chapter 2: IPsec Fundamentals

Figure 2-21

IPsec Transform Creation Decision Tree Select an IPSec Transform

NO

Do encrypted packets also require broad authentication services?

YES

Is confidentiality a requirement?

Select AH as IPSec Protocol

NO

YES

Select ESP and AH to be included in the transform set

Do lowerlayer protocols require confidentiality or full authentication protection?

Select ESP as IPSec Protocol

Do lower-layer protocols require full authentication protection?

YES

NO

Select Transport Mode

NO

YES

Select Tunnel Mode

Select Tunnel Mode

Select Transport Mode

Strongest Stronger Strong

How Strong of an Encryption Cipher do I need?

Do I need additional Authentication and Integrity?

DES

NO

3DES

AES

No HMAC Authentication

Do I need additional Authentication and Integrity?

YES

YES

MD 5

NO

Strong

How Strong do I need the HMACs to be?

Stronger

SHA-1

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.

Example 2-1

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

James# config ure termin al James#c *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.

crypto IPsec trans form-set IPSECVPN- 1 ? James(config)#c 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

crypto IPsec trans form-set IPSECVPN-1 e sp-des ah-sh a-hmac James(config)#c end James(config)#e James(config)#

2.

Example 2-2

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

James# config ure termin al James#c *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.

crypto IPsec trans form-set IPSECVPN-1 e sp-des ah-sh a-hmac James(config)#c mode ? James(cfg-crypto-trans)#m transport

transport (payload encapsulation) mode

tunnel

tunnel (datagram encapsulation) mode

mode tu nnel James(cfg-crypto-trans)#m end James(cfg-crypto-trans)#e James#

66

Chapter 2: IPsec Fundamentals

3.

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

4.

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

As one may have inferred, not all of the above parameters must be selected. For example, one can choose not to include authentication headers in a transformed payload and only select ESP. Likewise, no authentication method can be selected when defining transforms. As such, it helps to think of transform creation as a series of sequential decisions as depicted by the flowchart in Figure 2-21. NOTE In Figure 2-21, the path that James had chosen to select his transform in Examples 2-1 and 2-2 is noted with shading.

As we’ll see in later sections of this book, Charlie must be configured with a transform set that matches James’ for the IPsec tunnel to negotiate properly. The transform set defines a variety of security parameters that will be negotiated over IKE when IPsec SAs are formed. Crypto Map Configuration Transform processes are performed at the interface level, and are therefore not activated until they are bound to an interface, or group of interfaces, using a crypto map. In IOS, crypto maps are used for a variety of different configuration items that are discussed in later sections of this chapter, including PFS, TED, x-Auth, and other options. At a minimum, a crypto map must be configured with three items before it is activated by IOS: ■

An existing crypto ACL to define traffic to be transformed.

■

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

■

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

Consider Charlie’s configuration of a crypto map when setting up an IPsec tunnel to James in Figure 2-20. It is assumed that Charlie has configured a transform set named “IPSECVPN-1” that

The IP Security Protocol (IPsec)

67

matches the one that James had configured in Examples 2-1 and 2-2. Charlie matches any SMTP traffic destined James 20.0.0.0/8 network by referencing ACL 101 in his crypto map. Last, Charlie defines James’ serial interface IP address as the IPsec tunnel endpoint so that IPsec understands which destination the Charlie’s IPsec SA to James (remember—IPsec builds two unidirectional SAs) should reference. Example 2-3 illustrates Charlie’s configuration of the three minimal objectives to establish his crypto map and the binding of the crypto map to his serial interface. Charlie configures a crypto map to communicate with James via IPsec. To achieve this, Charlie configures a crypto map named “IPSECMAP-1,” as illustrated in line 5 of Example 2-3. He then selects ISAKMP over manual keying, allowing Charlie and James to dynamically establish a secure channel over which to negotiate IPsec SAs. When Charlie builds his crypto map, IOS warns that an ACL, peer, and transform must be configured for the crypto map to be activated. Charlie references access-list 101 as traffic to be processed by IPsec in this crypto map (Example 2-3, line 8). Charlie selects the IP address of James’ serial interface as the IPsec tunnel endpoint to be referenced in the IPsec SA (Example 2-3, line 9). Transform set “IPSECVPN-1” is then selected as the transform to be executed on traffic matching ACL 101, as illustrated in Example 2-3, lines 8 and 11, respectively. When Charlie wants to encrypt e-mail traffic (SMTP) destined to James (hosts on 20.0.0.0/8), he sets up ACL 101 to reference SMTP traffic destined to that subnet and tells IPsec to use ACL 101 when deciding which traffic to process in IPsec (see above crypto map entry). Finally, Charlie binds the crypto map to his egress interface toward James, the intended IPsec tunnel endpoint (Example 3-1, line 15). To communicate with Charlie using IPsec, James first configures a crypto map named “IPSECMAP-1.” He selects ISAKMP over manual keying, allowing Charlie and James to dynamically establish a secure channel over which to negotiate IPsec SAs. When James builds his crypto map, IOS warns that an ACL, peer, and transform must be configured for the crypto map to be activated. James references access-list 101 as traffic to be processed by IPsec in this crypto map, after which he selects the IP address of Charlie’s serial interface as the IPsec tunnel endpoint to be referenced in the IPsec SA. The transform set “IPSECVPN-1” is then referenced as the transform to be executed on traffic matching ACL 101 (Example 2-3, lines 25 and 27, respectively). When James wants to encrypt e-mail traffic (SMTP) destined to Charlie (hosts on 30.0.0.0/8), he sets up ACL 101 to reference SMTP traffic destined to that subnet and tells IPsec to use ACL 101 when deciding which traffic to process in IPsec (Example 2-3, line 29). James then binds the crypto map to his egress interface toward Charlie, the intended IPsec tunnel endpoint (Example 2-3, line 31). Example 2-3

Minimum IOS Configuration Objectives for a Crypto Map

Charlie# config ure termina l Charlie#c *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

68

Chapter 2: IPsec Fundamentals

Example 2-3

Minimum IOS Configuration Objectives for a Crypto Map (Continued)

Charlie(config)# crypto map IPSECMAP-1 10 IPsec-isakmp % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured. match address 101 Charlie(config-crypto-map)#m set pe er 10.1.1.1 Charlie(config-crypto-map)#s set tr ansform IPSEC VPN-1 Charlie(config-crypto-map)#s exi t Charlie(config-crypto-map)#e access -list 101 permit tcp 30.0.0.0 0.2 55.255.255 2 0.0.0.0 0.255.255.255 Charlie(config)#a eq smtp Charlie(config)# interf ace serial 2/0 Charlie(config)#i crypt map IPSECMA P-1 Charlie(config-if)#c end Charlie(config-if)#e Charlie# James# config ure termin al James#c *Mar

6 04:11:38.663: %SYS-5-CONFIG_I: Configured from console by console

Enter configuration commands, one per line.

End with CNTL/Z.

James(config)# crypto map IPSECMAP-1 10 IPsec-isakmp % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured. match address 101 Charlie(config-crypto-map)#m set pe er 10.1.1.2 James(config-crypto-map)#s set tr ansform IPSE CVPN-1 James(config-crypto-map)#s e xi t James(config-crypto-map)#e access-list 101 permit tcp 20.0.0.0 0.255.255.255 30.0.0.0 0.255.255.255 eq James(config)#a smtp interf ace serial 2/0 James(config)#i crypt map IPSECMA P-1 James(config-if)#c end James(config-if)#e James#

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

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 Diffie-Hellman keys using PFS. NOTE PFS is a means by which to improve the freshness of IPsec shared secret keys generated using Diffie-Hellman. PFS is discussed in greater detail later in this chapter.

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

IPsec Manual Keying Configuration—James

James# config ure termin al James#c *Mar

6 04:11:38.663: %SYS-5-CONFIG_I: Configured from console by console

Enter configuration commands, one per line.

End with CNTL/Z.

James(config)# crypto IPsec trans form-set IPSECVPN -2 esp-des James(config)#c mode tu nnel James(cfg-crypto-trans)#m crypto map IPSECMA P-2 10 I Psec -manual James(config)#c set pee r 10.1.1.2 James(config-crypto-map)#s set ses sion-key inb ound es p 1001 cipher 1234abcd123 4abcd James(config-crypto-map)#s auth enticator 0 1 set ses sion-key out bound e sp 1000 ciph er abcd1234ab cd12 34 James(config-crypto-map)#s authenti cator 01 set tra nsform-set I PSECVPN -2 James(config-crypto-map)#s match a ddress 101 James(config-crypto-map)#m exit James(config-crypto-map)#e access-list 101 permit tcp 20.0.0.0 0.255.255.255 30.0.0.0 0.255.255.255 eq James(config)#a smtp interf ace serial2/ 0 James(config)#i crypto map IPSECMA P-2 James(config-if)#c end James(config-if)#e James#

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

70

Chapter 2: IPsec Fundamentals

Example 2-5

James’ IPsec SA Establishment Process

debug crypto IPs ec James#d *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#

The IP Security Protocol (IPsec)

71

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

IPsec Manual Keying Example—Charlie

config ure termina l Charlie#c *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.

crypto IPsec trans form-set IPSECVPN -2 esp-des Charlie(config)#c crypto map IPSECMA P-2 10 IPsec -manual Charlie(config)#c set pee r 10.1.1.1 Charlie(config-crypto-map)#s set ses sion-key inb ound es p 1000 cipher abcd1234abc d1234 Charlie(config-crypto-map)#s authent icator 01 set ses sion-key out bound e sp 1001 ciph er 1234abcd1 2 34ab cd Charlie(config-crypto-map)#s a uthenticato r 01 set tra nsform-set I PSECVPN -2 Charlie(config-crypto-map)#s match a ddress 101 Charlie(config-crypto-map)#m ex it Charlie(config-crypto-map)#e access -list 101 pe rmit tcp 30.0.0.0 0.2 55.255.255 2 0.0.0.0 0.255.255.25 5 Charlie(config)#a e q smt p interf ace serial2/ 0 Charlie(config)#i crypto map IPSECMA P-2 Charlie(config-if)#c end Charlie(config-if)#e Charlie#

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

Charlie’s IPsec SA Establishment Process

debug crypto IPse c Charlie#d *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

72

Chapter 2: IPsec Fundamentals

Example 2-7

Charlie’s IPsec SA Establishment Process (Continued) remote_proxy= 10.1.1.1/255.255.255.255/47/0 (type=1), protocol= ESP, transform= esp-des

(Tunnel),

lifedur= 3600s and 4608000kb, spi= 0x3E9(1001), conn_id= 134219728, keysize= 0, flags= 0xA *Mar

5 20:26:57.657: IPSEC(initialize_sas): ,

(key eng. msg.) INBOUND local= 10.1.1.2, remote= 10.1.1.1, local_proxy= 10.1.1.2/255.255.255.255/47/0 (type=1), remote_proxy= 10.1.1.1/255.255.255.255/47/0 (type=1), protocol= ESP, transform= esp-des

(Tunnel),

lifedur= 3600s and 4608000kb, spi= 0x3E8(1000), conn_id= 134219729, keysize= 0, flags= 0x2 *Mar

5 20:26:57.657: Crypto mapdb : proxy_match src addr

: 10.1.1.2

dst addr

: 10.1.1.1

protocol

: 47

src port

: 0

dst port

: 0

*Mar 5 20:26:57.657: IPSEC(crypto_IPsec_sa_find_ident_head): reconnecting with the same proxies and 10.1.1.1 *Mar

5 20:26:57.657: IPSEC(policy_db_add_ident): src 10.1.1.2, dest 10.1.1.1, dest_port 0

*Mar 5 20:26:57.657: %CRYPTO-5-SESSION_STATUS: Crypto tunnel is UP . Peer 10.1.1.1:500 *Mar

5 20:26:57.657: IPSEC(create_sa): sa created,

(sa) sa_dest= 10.1.1.1, sa_prot= 50, sa_spi= 0x3E9(1001), sa_trans= esp-des , sa_conn_id= 134219728 *Mar

5 20:26:57.657: IPSEC(create_sa): sa created,

(sa) sa_dest= 10.1.1.2, sa_prot= 50, sa_spi= 0x3E8(1000), sa_trans= esp-des , sa_conn_id= 134219729 Charlie#

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

Charlie Verifies SA Establishment with James and Verifies Encryption/Decryption Activity in His IPsec Crypto Engine

show c rypto IPsec sa Charlie#s interface: FastEthernet0/0 Crypto map tag: IPSECMAP-2, local addr. 10.1.1.2

The IP Security Protocol (IPsec)

Example 2-8

73

Charlie Verifies SA Establishment with James and Verifies Encryption/Decryption Activity in His IPsec Crypto Engine (Continued)

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: show c rypto engin e connect ion active Charlie#s

continues

74

Chapter 2: IPsec Fundamentals

Example 2-8

Charlie Verifies SA Establishment with James and Verifies Encryption/Decryption Activity in His IPsec Crypto Engine (Continued) IP-Address

State

Algorithm

Encrypt

Decrypt

2000 FastEthernet0/0

ID Interface

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 show c rypto IPsec sa Charlie#s

The IP Security Protocol (IPsec)

Example 2-8

75

Charlie Verifies SA Establishment with James and Verifies Encryption/Decryption Activity in His IPsec Crypto Engine (Continued)

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

76

Chapter 2: IPsec Fundamentals

Example 2-8

Charlie Verifies SA Establishment with James and Verifies Encryption/Decryption Activity in His IPsec Crypto Engine (Continued)

show c rypto engin e connect ion active Charlie#s IP-Address

State

Algorithm

2000 FastEthernet0/0

ID Interface

10.1.1.2

set

DES_56_CBC

Encrypt 1500

Decrypt 0

2001 FastEthernet0/0

10.1.1.2

set

DES_56_CBC

0

1499

Charlie#

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

James Checks Decryption of Charlie’s Traffic (ICMP Echo Request) and Then Verifies That He Is Encrypting Responses to Charlie (ICMP Echo Replies)

show c rypto IPse c sa James#s 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

The IP Security Protocol (IPsec)

Example 2-9

77

James Checks Decryption of Charlie’s Traffic (ICMP Echo Request) and Then Verifies That He Is Encrypting Responses to Charlie (ICMP Echo Replies) (Continued) 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:

show c rypto engi ne connect ion active James#s IP-Address

State

Algorithm

2000 FastEthernet0/0

ID Interface

10.1.1.1

set

DES_56_CBC

Encrypt 1499

Decrypt 0

2001 FastEthernet0/0

10.1.1.1

set

DES_56_CBC

0

1499

James#

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

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 we’ve discussed that use manual SAs, IKE SAs can be established on the fly and torn down at a time period negotiated. As we had discussed before, IPsec specifies two SAs. The type of SA is the IPsec SA, which we reviewed in fair detail in examples 2-1 through 2-9. The second one, which we have yet to discuss in great detail, is the IKE SA. It is over this SA, the one that IKE establishes, that IPsec can now dynamically establish and tear down its SA between crypto endpoints.

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

Crypto endpoint authentication procedures

■

IPsec SA negotiation, maintenance, and timeout

■

Cryptographic key generation and exchange techniques (Diffie-Hellman)

■

Threat mitigation (antireplay, DoS mitigation techniques)

However, ISAKMP is a framework for delivering these services—it does not define the protocol for them. As such, ISAKMP is designed to be key-exchange independent, and supports a number of key exchange protocols. In the IPsec world, we are concerned with one of these key exchange protocols—IKE. The protocol used for key exchange and SA negotiation in IPsec today, IKE, uses the framework outlined in ISAKMP to deliver upon authentication, SA negotiation, key generation and exchange, and native threat mitigation services. IKE represents a number of key exchange and SA negotiation protocols (Oakley and SKEME) that have been combined to fit within the ISAKMP framework. Oakley is a key exchange and management protocol that allows for the exchange of multiple keys and their corresponding services. SKEME supplies anonymity and nonrepudiation using its own key exchange method. IKE combines the strengths of Oakley and SKEME in a comprehensive protocol for establishing a secure channel over which to establish IPsec SAs.

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 defined. This is not the case with IKE/ ISAKMP. IKE dynamically creates IPsec SAs upon the transmittal of traffic matching the IPsec policy. This is done by exchanging a series of messages over UDP port 500. IKE allows the crypto endpoints to negotiate a lifetime for each SA. This enables network administrators to use their SADB more efficiently through establishing security associations only when needed and automatically tearing down stale SAs at the end of their agreed-upon lifetime. Example 2-10 illustrates the configuration of the IPsec SA lifetime that Charlie would like to negotiate with James during IKE. Example 2-10

Charlie Specifies a Lifetime for His IPsec SAs, Negotiated with James During IKE

Charlie# config ure termina l Charlie#c Enter configuration commands, one per line.

End with CNTL/Z.

crypto isakmp poli cy 10 Charlie(config)#c lifeti me ? Charlie(config)#l

lifetime in seconds

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

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

■

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

■

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

80

Chapter 2: IPsec Fundamentals

■

Manual keying negates antireplay techniques between crypto peers.

■

There is no CA support for manual session keys.

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

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

Charlie# config ure termina l Charlie#c Enter configuration commands, one per line.

End with CNTL/Z.

crypto isakmp po licy 10 Charlie(config)#c group ? Charlie(config-isakmp)#g 1

Diffie-Hellman group 1

2

Diffie-Hellman group 2

5

Diffie-Hellman group 5

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

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

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

IKE and ISAKMP

Figure 2-22

81

James and Charlie Derive Shared Secret Keys Using Diffie-Hellman Shared Secret Key, DH

4

4

Derive Shared Secret Number: DHS = (B* ^ A) mod (P) = 8

Shared Secret Key, DH

Derive Shared Secret Number DHS = (A* ^ B) mod (P) = 8

3

Select Number (Kept Private), B = 7 B* = (Q ^ B) mod (P) = 2

2

Select Number (Kept Private), A = 3 A* = (Q ^ A) mod (P) = 6

Random Prime #1, (P) = 11 Random Prime #2, (Q) = 19

1 James

Charlie

Message:

Message:

Test Message: Let’s go play some basketball

Test Message: Let’s go play some basketball

Note: Cipher: DES

Cipher Text: f8desa0RQ(eQW*()SD

These can be any symmetric key transforms, such as DES, 3DES, or AES

5

Cipher: DES

Cipher Text: f8desa0RQ(eQW*()SD

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

Charlie and James derive two large, random numbers P and Q, and exchange them with one another. Usually, this is done in a master-slave relationship, where one party will derive the two numbers to be used in the DH exchange and forward them over to its peer. In this case, Charlie derives the numbers and exchanges them with his peer, James.

2.

James selects a large random number, A, which he keeps private. He uses this number to calculate the value of A*, which is defined by the equation A* = (Q ^ A) mod (P). Once he has finished his calculation, James shares the value of A* with Charlie.

3.

Charlie selects a large random number B, which he keeps private. He uses this number to calculate the value of B*, which is defined by the equation B* = (Q ^ B) mod (P). Charlie then shares this value with James.

82

Chapter 2: IPsec Fundamentals

4.

James and Charlie derive their shared, secret (Diffie-Hellman) keys from the values of B* and A*, respectively. Charlie uses the equation DHS = (A* ^ Q) mod P and James uses the equation DHS = (B* ^ Q) mod P to derive the shared key, commonly referred to as a DiffieHellman Secret Key.

5.

Now that James and Charlie have a shared secret key, they can choose one of many effective symmetric key encryption algorithms to use. Examples of such symmetric encryption transforms include DES, 3DES, and AES, which will be explored later in this chapter.

In the example used above, small numbers are used for illustration purposes only. In reality, the effectiveness of the Diffie-Hellman algorithm depends largely on the size of the values selected for P, Q, A, and B mentioned above. As with RSA encryption, P and Q must be large, randomly selected prime numbers. A and B can be any large, randomly selected numbers—they do not have to be prime. A Diffie-Hellman derived keypair presents two mathematical tasks to would-be attackers who wish to compromise the shared secret key’s confidentiality. First, an attacker must be able to derive A from seeing Q ^ A. This would require the computation of a discrete algorithm. The second strength is similar to one of RSA’s key strengths—the attacker must be able to factor two large prime numbers. Hence, Diffie-Hellman values for P and Q share the same requirement as an RSA key modulus—it must be large and random. Diffie-Hellman does not typically specify a modulus size directly. Instead, the modulus of a Diffie-Hellman key is referred to as the Diffie-Hellman group. There are four different Diffie-Hellman Groups that yield a DHS that is approximately equal to a 70–80-bit symmetric key in strength. NOTE Existing Diffie-Hellman groups have traditionally accommodated commercially available symmetric cryptographic exchanges such as DES and 3DES. But, because the AES transform supports up to 256-bit encryption, stronger symmetric keys are required. Hence, demand has been sparked for a fifth Diffie-Hellman group. RFC 3526 describes the development of DH group 5 in more detail.

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

IKE and ISAKMP

Example 2-12

83

James Configures IPsec and IKE Encryption Ciphers.

James# config ure termin al James#c Enter configuration commands, one per line.

End with CNTL/Z.

crypto isakmp poli cy 10 James(config)#c encryp tion 3DES James(config-isakmp)#e end James(config-isakmp)e James#

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

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

Pre-Shared Keys

■

RSA Encryption (Encrypted Nonces)

■

RSA Signatures (X.509 certificate based—requires X.509 CA)

Pre-Shared Keys For smaller networks on which keys can be manually defined, IKE preshared keys (PSKs) can be used. PSKs are manually defined in the IKE policy of each crypto endpoint. Once crypto and ISAKMP policies are attached to active crypto interfaces, IKE attempts to exchange PSKs with the appropriate crypto peer, or IPsec tunnel endpoint. NOTE A defined, static PSK may specify a single peer to share a key with. Alternately, a range of peers can be specified for a single key using wildcard subnet masks in the ISAKMP key definition. A single IKE PSK defined for use with multiple peers using wildcard subnet masks is typically referred to as a wildcard preshared key. To guarantee authenticity of this message exchange, IKE appends a message digest to the key through a user-defined hash algorithm (MD5 or SHA-1). Example 2-13 shows the required IKE configurations on James and Charlie.

84

Chapter 2: IPsec Fundamentals

Example 2-13

IKE Configurations for James and Charlie Using PSKs

Charlie# config ure termina l Charlie#c *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.

crypto isakmp ke y unctarhe els address 1 0.1.1.1 Charlie(config)#c crypto isakmp po licy 10 Charlie(config)#c Charlie(config-isakmp)# encryption 3des Charlie(config-isakmp)# authentication pre-share Charlie(config-isakmp)# group 2 Charlie(config-isakmp)# lifetime 50000 end Charlie(config-isakmp)#e config ure termina l Charlie#c Enter configuration commands, one per line.

End with CNTL/Z.

crypto map IPSEC MAP-3 10 I Psec -isakmp Charlie(config)#c % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured. Charlie(config-crypto-map)# set peer 10.1.1.1 Charlie(config-crypto-map)# set transform-set IPSECVPN-2 Charlie(config-crypto-map)# match address 101 end Charlie(config-crypto-map)#e Charlie# crypto isakmp po licy 10 James(config)#c James(config-isakmp)# encryption 3des James(config-isakmp)# authentication pre-share James(config-isakmp)# group 2 James(config-isakmp)# lifetime 50000 e xit James(config-isakmp)#e crypto isakmp ke y unctarhe els address 1 0.1.1.2 James(config)#c crypto map IPSEC MAP-3 10 IPsec -isakmp James(config)#c % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured. match address 101 James(config-crypto-map)#m set tr ansform James(config-crypto-map)#s set tr ansform-set IPSECVPN -2 James(config-crypto-map)#s set pe er 10.1.1.2 James(config-crypto-map)#s end James(config-crypto-map)#e

While pre-shared keys are effective in smaller, trusted environments, the obvious pitfalls associated with manual keying exist. Somebody could verbally compromise the key, or the key could be a simple key that is easily guessed (administrator’s home town, favorite baseball team, birthday, and so on). Because all peers share the same wildcard PSK, that key must be changed on all peers using that key, which can lead to increased administrative overhead. As such, wildcard PSKs have inherent security flaws primarily related to inability to effectively manage the eviction of a once-trusted IPsec peer in the group and are generally not recommended without the use of

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 certificates), which enable administrators to have the crypto endpoint dynamically generate a pair of cryptographic keys for authentication. Remember that IKE is designed to enable the setup and teardown of SAs dynamically, which means that key exchange will be done more often. As such, the low computational overhead that PSK authentication offers makes it an attractive design option when their VPN performance is the top design criterion. RSA Encryption (Encrypted Nonces) A nonce is a random, or “nonsense,” number. IKE can be configured to use the RSA cryptographic algorithm to verify the identity of peers before continuing IKE Phase I negotiation. Nonces are used to add randomness to the exchange, making it harder to crack. Figure 2-23 illustrates the creation and exchange of RSA encrypted nonces. When using the RSA encrypted nonce method of ISAKMP authentication, the cryptographic endpoints follow the following series of exchanges, as numbered in Figure 2-23: 1.

Initiator (James) and Responder (Charlie) generate an RSA public and private keypair.

2.

Initiator and Responder exchange public keys.

3.

The Initiator creates a nonce and forwards it to the Responder.

4.

The Responder encrypts the nonce with the Initiator’s public RSA key (obtained in Step 1), and forwards the ciphered message to the Initiator.

5.

The Initiator decrypts the ciphered nonce from the Responder. If the value matches the original nonce, the Responder has authenticated with the Initiator (Hash_I).

6.

The Responder creates a nonce and forwards it to the Initiator.

7.

The Initiator encrypts the nonce with the Initiator’s public RSA key (obtained in Step 1), and forwards the ciphered nonce to the Responder (Hash_R).

8.

The Responder decrypts the ciphered message with its own private RSA key. If the decrypted nonce matches the original nonce sent from the Responder, the Initiator has authenticated with the responder.

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

86

Chapter 2: IPsec Fundamentals

Figure 2-23

RSA-Encrypted Nonce Authentication

James

Charlie

Public Key, James

Public Key, Charlie

1

2 Private Key, James

1 Private Key, Charlie

3 Nonce, I Cipher: RSA

Public Key, James 4 Hash_I

5 Cipher: RSA

Private Key, James

Nonce, I 6 Nonce, R Cipher: RSA

7 Hash_R

8 Cipher: RSA

Nonce, R

RSA Signatures and X.509 Certificates RSA signatures are a form of Digital Signature, the operation of which is described previously in Figure 2-8. RSA signatures, however, combine the strength of a standard Digital Signature with

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 certificates with an X.509 compliant Certificate Authority (CA). ITU-T X.509 Certificates and CAs were developed to aid administrative burden in asymmetric cryptographic deployments through leveraging a central point of administration, or a CA, for cryptographic endpoints to register their public keys and to obtain the public keys of their peers. In order to effectively exchange this information, the CA must communicate certificates in a standard format that is agreed upon with its peers. ITU-T X.509 formatted certificates are commonly accepted as the standard for this type of public key cryptosystem. NOTE X.509 is discussed in greater detail in Chapter 11, “Public Key Infrastructure and IPsec VPNs.” Figure 11-2 illustrates the format of an X.509v3 certificate.

Certificate Authorities enable network administrators to effectively manage large-scale crypto deployments by concentrating the administration of public key distribution into one source. In doing so, administrators can be assured that keys are exchanged with authentic sources and destinations. The use of CA-based PKI does not enhance the level of confidentiality exchanged in an asymmetric key crypto deployment. It does, however, enforce data authentication in a fashion that enables enhanced scalability in the number of encrypting/decrypting peers. Endpoints using RSA signatures for IKE authentication will enroll using Simple Certificate Enrollment Protocol (SCEP), as defined by the X.509 standard. The transport used to distribute certificates in the exchange previously described uses a client-server application such as HTTP, FTP, or Lightweight Directory Access Protocol (LDAP). Cisco Systems manufactures a full set of network devices and appliances that use X.509-based PKI cryptosystems that leverage protocols such as HTTP for certificate transport, including firewalls, intrusion detection systems, routers, switches, and VPN concentrators. NOTE Public Key Infrastructures using the RSA Signatures method of IKE authentication are discussed in greater detail in Chapter 11, including design concepts and a more detailed description of the Endpoint-CA relationship within a PKI. The mechanics for configuring and troubleshooting IKE authentication with RSA-sigs is also discussed in greater detail in Chapter 11. The process of enrolling VPN endpoints in to the PKI using a CA and RSA-sigs is discussed in greater detail in Chapter 11 and summarized in Appendix A of this text.

IKE Phase I Negotiation As we’ve discussed, the goal of IKE is establishment of a secure channel over which to exchange security parameters, such as those that comprise IPsec SA. This negotiation is referred to as Phase

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

■

Diffie-Hellman Group Number (MODP size)

Once these methods are agreed upon, the peers begin the negotiation process. The result of Phase I IKE negotiation is the establishment of an ISAKMP SA. Once ISAKMP SA has been negotiated between crypto endpoints, an authenticated channel for confidential establishment IPsec SAs can be established. Main Mode Main mode IKE negotiation provides identity protection between the two crypto endpoints. It does, however, consume more resources than aggressive mode. Likewise, main mode involves a more complicated exchange than aggressive mode. Main mode enables two crypto endpoints to establish an ISAKMP SA securely, without ever exchanging the identity of either crypto endpoint in clear text. To do this, IKE in Main Mode follows three steps with a set of three messages. Consider the main mode exchange between James and Charlie in Figure 2-24. Figure 2-24

ISAKMP Negotiation in Main Mode

James

Charlie James sends security proposal to Charlie, containing options and preferences for encryption cipher, authentication hash, authentication method, and Diffie-Hellman group number.

1 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.

2

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).

3

Charlie sends authentication message to James (encrypted with Diffie-Hellman key and selected cipher, authenticated with hash).

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 parameters—encryption cipher, authentication hash, authentication method, and Diffie-Hellman Group number. James initiates the process by sending a list of available proposals. Charlie responds by selecting a proposal from James’ list of options and replying to James.

2.

Charlie and James exchange Diffie-Hellman public keys and nonces. The two parties are able to derive shared Diffie-Hellman keys from this information.

3.

Charlie and James are now able to authenticate each other. Now that they have shared session keys derived from Diffie-Hellman exchange, and an agreed-upon cipher, the authentication messages can be encrypted. This allows for a purely confidential exchange when establishing ISAKMP SA, as identity messages are never sent in the clear and are sent with appended hashes for message authentication.

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

Aggressive Mode Unlike IKE negotiation in main mode, which involves three exchanges, aggressive mode involves only two exchanges. As with main mode, aggressive mode exchange involves an exchange of messages targeted at agreeing on encryption cipher, authentication hash, authentication method, and Diffie-Hellman group number. Unlike main mode, in aggressive mode the sender’s and receiver’s identities are not encrypted because they are sent concurrently with cryptographic elements needed for encryption in the first IKE aggressive mode exchange. In an aggressive mode exchange, the Diffie-Hellman group number and encryption cipher are negotiated only in the IPsec SA. Once a security proposal has been agreed upon, the two crypto endpoints authenticate each other in clear text. In summary, IKE aggressive mode exchanges all of the information that IKE main mode does, but instead of using a 3-step exchange, aggressive mode uses a 2-step exchange. Condensing the number of exchanges weakens the security of the process, as the sender’s and receiver’s identities are exchanged in cleartext. Figure 2-25 illustrates the negotiation of an IKE SA using aggressive mode.

90

Chapter 2: IPsec Fundamentals

Figure 2-25

IKE Exchange in Aggressive Mode

James

Charlie 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 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).

2

Charlie sends authentication message to James (unencrypted, but authenticated with message-digest verification).

Aggressive mode is useful for VPNs that require rapid ISAKMP SA establishment. They are also useful on crypto endpoints with low processing resources, such as software-based VPN clients on low-end workstations. The obvious tradeoff is that authentication information in ISAKMP SA negotiation is performed in the clear, and is only protected by the insertion of a message digest using the selected authentication hash algorithm. By default, Cisco IOS will attempt to negotiate Phase 1 using main mode. If main mode fails, the default behavior is to automatically try to negotiate the SA using aggressive mode. Cisco IOS can be configured to disallow the use of aggressive mode as an option for Phase 1 negotiation, as illustrated in Example 2-14. Example 2-14

Disallowing Aggressive Mode as an Option for Phase 1 Negotiation

crypto isakmp ag gressive-m ode disable James(config)#c

IKE Phase II Negotiation The goal of IKE Phase II negotiation is establishment of IPsec SAs between two endpoints. IKE uses Diffie-Hellman key exchange to negotiate the shared secret key to be used in the encryption cipher specified in the IPsec transform set. The IPsec SA can include the shared Diffie-Hellman key used to encrypt the ISAKMP SA, or it can be renegotiated over the ISAKMP SA during Phase II negotiation. Quick Mode IKE Phase II negotiation is done in only one mode, quick mode. Due to the fact that Phase II negotiation’s goal is establishment of an IPsec SA, quick mode exchange must inform both crypto endpoints of the IPsec mode to use ESP and AH and all other relevant variables needed

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

James

Charlie 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 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.

2

Charlie verifies the authentication hash’s message digest.

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

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

■

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

■

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

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

92

Chapter 2: IPsec Fundamentals

Example 2-15

Configuring PFS

config ure termina l Charlie#c Enter configuration commands, one per line.

End with CNTL/Z.

crypto map IPSEC MAP-3 10 I Psec -isakmp Charlie(config)#c set pf s ? Charlie(config-crypto-map)#s group1

D-H Group1 (768-bit modp)

group2

D-H Group2 (1024-bit modp)

group5

D-H Group5 (1536-bit modp)

set pf s group5 Charlie(config-crypto-map)#s end Charlie(config-crypto-map)#e Charlie#

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

Dead Peer Detection and IKE Keepalives Crypto endpoints use IKE keepalives to poll the validity of active ISAKMP SAs. IKE keepalives enable routers to quickly detect when IPsec and ISAKMP SAs become inactive, or stale. This enables the crypto endpoints to optimally maintain the SADB, which also enables greater IPsec SA scalability on crypto endpoints. When a crypto endpoint does not receive three keepalives in a row, it tears down the SAs associated with that peer and initiates IKE Phase 1 negotiation with the next peer referenced in the crypto map. Figure 2-27 illustrates the process of detecting a stale SA with IKE Keepalives. Example 2-16 illustrates Kristen’s configuration for failover using IKE DPD to a redundantly defined IPsec peer. To do this, Kristen specifies the use of IKE keepalives. If Kristen’s primary peer, 10.1.1.2, goes offline, she will attempt to negotiate another IPsec VPN tunnel with 10.1.1.3 after missing three IKE keepalives spaced 10s apart (Example 2-16, line 9). In addition, Kristen must have two peers defined in her crypto map in order to facilitate this failover (Example 2-16, lines 16 and 17). Because Kristen uses IKE PSKs, she must also have the shared secret key defined with both peers (Example 2-16, lines 10 and 11).

IKE and ISAKMP

Figure 2-27

Detecting Stale SAs with IKE Keepalives ISP

Internet Gateway

Default Gateway to .1. Charlie also injects default gateway back to Kristen via the chosen RP.

.1

Default Gateway to .1. James also injects default gateway back to Kristen via the chosen RP.

192.168.1.0/24 .3

.2

Charlie

James

(10.1.1.3)

(10.1.1.2)

Kristen’s crypto map is configured with a redundant peer and pre-shared key (see Example 3-13). After her 3rd missed keepalive from James, she automatically begins IKE Phase I negotiation with Charlie.

RP

James’ link to Kristen fails, and as such, his IKE keepalives no longer reach Kristen.

Kristen (10.1.1.100)

Example 2-16

Kristen Uses DPD and IKE Keepalives for VPN High Availability

Kristen config ure termina l Kristen#c Enter configuration commands, one per line.

End with CNTL/Z.

crypto isakmp poli cy 10 Kristen(config)#c hash s ha Kristen(config-isakmp)#h authen tication pre- share Kristen(config-isakmp)#a encryp tion 3des Kristen(config-isakmp)#e exit Kristen(config-isakmp)#e Kristen(config)#crypto isakmp keepalive 10 crypto isakmp key ncstatew olfpack ad dress 10.1.1. 2 Kristen(config)#c crypto isakmp key ncstatew olfpack ad dress 10.1.1. 3 Kristen(config)#c crypto map IPSECVP N-1 10 I Psec -isakmp Kristen(config)#c % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured. match a dd 101 Kristen(config-crypto-map)#m set pee r 10.1.1.2 Kristen(config-crypto-map)#s set pee r 10.1.1.3 Kristen(config-crypto-map)#s set tra ns IPSECVPN- 1 Kristen(config-crypto-map)#s end Kristen(config-crypto-map)#e Kristen#

93

94

Chapter 2: IPsec Fundamentals

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

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

Define the ISAKMP policy. Within the ISAKMP policy, define security parameters to be used with ISAKMP provided in the following list: • Authentication Method • Authentication Hash Algorithm • Encryption Cipher • Diffie-Hellman MODP Group

Step 2

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

Step 3

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

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

IKE and ISAKMP

Example 2-17

James and Charlie Use ISAKMP Policies for IKE Negotiation

James# config ure termin al James#c crypto isakmp poli cy 10 James(config)#c encryp tion 3des James(config-isakmp)#e authen tication pre- share James(config-isakmp)#a group 2 James(config-isakmp)#g lifeti me 50000 James(config-isakmp)#l exit James(config-isakmp)#e crypto isakmp poli cy 20 James(config)#c hash m d5 James(config-isakmp)#h authen tication rsa- encr James(config-isakmp)#a group 5 James(config-isakmp)#g exit James(config-isakmp)#e crypto isakmp key unctarhe els address 1 0.1.1.2 James(config)#c crypto IPsec trans form-set IPSECVPN -1 esp-des James(config)#c crypto map IPSECMA P-1 10 I Psec -isakmp James(config)#c set pee r 10.1.1.2 James(config-crypto-map)#s set tra nsform-set I PSECVPN -1 James(config-crypto-map)#s match a ddress 101 James(config-crypto-map)#m exit James(config-crypto-map)#e interf ace serial2/ 0 James(config)#i crypto map IPSECMA P-1 James(config-if)#c end James(config-if)#e James# Charlie# config ure termina l Charlie#c crypto isakmp poli cy 10 Charlie(config)#c encryp tion 3des Charlie(config-isakmp)#e authen tication pre- share Charlie(config-isakmp)#a group 2 Charlie(config-isakmp)#g lifeti me 50000 Charlie(config-isakmp)#l exit Charlie(config-isakmp)#e crypto isakmp key unctarhe els address 1 0.1.1.1 Charlie(config)#c crypto IPsec trans form-set IPSECVPN -2 esp-des Charlie(config)#c crypto map IPSECVP N-1 10 I Psec-isakmp Charlie(config)#c set pee r 10.1.1.1 Charlie(config-crypto-map)#s set tra nsform-set I PSECVPN -2 Charlie(config-crypto-map)#s match a ddress 101 Charlie(config-crypto-map)#m ex it Charlie(config-crypto-map)#e interf ace serial2/ 0 Charlie(config)#i crypto map IPSECMA P-1 Charlie(config-if)#c end Charlie(config-if)#e Charlie#

95

96

Chapter 2: IPsec Fundamentals

Figure 2-28

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).

Charlie’s 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.

James and Charlie use ISAKMP policy 10 (pre-shared keys, 3DES cipher, DiffieHellman group 2, and SA lifetime of 50000 to establish ISAKMP and IPSec SAs.

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

IKE Mode Configuration

■

IKE Extended Authentication (x-Auth)

We will use an RAVPN topology in which remote clients with software-based IPsec VPN clients installed use mode configuration for client IP address assignment and IKE x-Auth to enable administrators to provision increased granularity when authenticating client sessions. Mode Configuration Using mode config, administrators can dynamically manage RAVPN client addressing, domain names, WINS servers, and DNS servers on the RAVPN concentrator itself. This greatly simplifies administrative overhead of the RAVPN for both network administrators and users. Mode config will provide the RAVPN client with an IP address that will be used as the IP address of the inner ESP or AH header. The client’s publicly available address, usually assigned by the clients’ ISP, will populate the outer ESP or AH header.

IKE and ISAKMP

97

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

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

■

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

Example 2-18

VPN Concentrator Settings for Extended Authentication

Kristen# config ure termina l Kristen#c Enter configuration commands, one per line.

End with CNTL/Z.

aaa ne w-model Kristen(config)#a aaa au thentication login R AVP N-aaa group tacacs+ Kristen(config)#a aaa au thorization network RAVPN-aaa gro up tacacs+ Kristen(config)#a crypto isakmp poli cy 10 Kristen(config)#c hash m d5 Kristen(config-isakmp)#h authen tication pre- share Kristen(config-isakmp)#a crypto isakmp clien t confi guration gro up RAVPN-grou p Kristen(config-isakmp)#c key ncs tatewolfpack Kristen(config-isakmp-group)#k domain cisco.com Kristen(config-isakmp-group)#d pool RA VPN-pool Kristen(config-isakmp-group)#p e xit Kristen(config-isakmp-group)#e crypto IPsec trans form-set RAVPN-trans form esp-aes esp-s ha-hmac Kristen(config)#c mode tu nnel Kristen(cfg-crypto-trans)#m exi t Kristen(cfg-crypto-trans)#e crypto dynamic-map RAVPN-d yn 10 Kristen(config)#c set tra nsform-set R AVPN-1 Kristen(config-crypto-map)#s ex it Kristen(config-crypto-map)#e crypto map RAVPN-m ap clien t authenticat ion list RAV PN-aaa Kristen(config)#c crypto map RAVPN-m ap isakm p authori zation list R AVP N-aaa Kristen(config)#c crypto map RAVPN-m ap clien t configurati on address r espond Kristen(config)#c crypto map RAVPN-m ap clien t configur ation address i nit iate Kristen(config)#c crypto map RAVPN-m ap 10 IP sec-isakmp dy namic RAVPN- dyn Kristen(config)#c interf ace FastEthe rnet0/0 Kristen(config)#i crypto map RAVPN-m ap Kristen(config-if)#c

continues

98

Chapter 2: IPsec Fundamentals

Example 2-18

VPN Concentrator Settings for Extended Authentication (Continued)

ex it Kristen(config-if)#e ip loc al pool RA VPN-pool 1 0.1.1.1 10.1 .1.254 Kristen(config)#i Access-list 101 permit tacacs -server ho st 100.1.1 .254 Kristen(config)#t tacacs -server di rected-req uest Kristen(config)#t tacacs -server ke y Cisco Kristen(config)#t

Figure 2-29

Address Assignment with IKE Extended Authentication Kristen uses x-Auth to authenticate James’s user information against AAA/TACACS+ server.

CiscoSecure AAA Server Kristen uses x-Auth to authenticate Charlie’s user information against AAA/TACACS+ server.

Kristen Kristen’s is configured with a dynamic crypto map to negotiate Phase ⌱ IKE with James and Charlie. Kristen’s 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).

James

Kristen assigns (initiates) a private address to use for his IPSec tunnel endpoint.

Kristen responds to Charlie’s request for a IP address to use for his IPSec tunnel endpoint.

Kristen and James complete IKE Phase I authentication.

Charlie and Kristen complete Phase I IKE authentication.

I want to allow Kristen to assign me an IP address to use for my IPSec tunnel endpoint.

ISP

Charlie

I want to request an address, and have Kristen respond with an IP address for me to use for my tunnel endpoint.

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

IKE and ISAKMP

99

X-Auth is not a replacement for IKE Phase I’s existing authentication capabilities. Instead, x-Auth occurs in addition to IKE Phase I negotiation and occurs after IKE authenticates the crypto endpoint. TIP As x-Auth is not exactly described in Phase I negotiation, and Phase II negotiation cannot complete before Phase I negotiation (and subsequently x-Auth), x-Auth is commonly said to occur during Phase 1.5 negotiation.

As such, to use x-Auth, administrators must configure native Phase I authentication schemes and x-Auth parameters. Example 2-18 shows IPsec RAVPN configurations on an IOS-based VPN concentrator configured for x-Auth and authentication, authoring, and accounting (AAA) (as displayed in Figure 2-29). NOTE Example 2-18 contains dynamic crypto maps and wildcard PSKs, both of which are outside of the scope of this chapter. These topics are covered in greater detail in Chapter 14.

In the scenario in Example 2-18, Kristen is a router running Cisco IOS that is concentrating IPsec tunnels used for remote access by James and Charlie. Kristen uses several parameters to authenticate her remote access clients—group ID and key. All remote access clients must be configured with these keys in order to authenticate with Kristen. This is done in IKE Phase I negotiation. Additionally, Kristen uses x-Auth to authenticate and authorize James and Charlie against an AAA database on the TACACS+ server, 100.1.1.254. Kristen is configured to serve her remote clients with an address from the pool “RAVPN-pool,” and assign them a domain name of “cisco.com.” TIP In the configuration in Example 2-18, Kristen will attempt to authenticate any remote client that attempts to connect to her. An ACL can be configured under the ISAKMP group to prevent malicious hosts from continuously trying to connect to the concentrator, initiate authentication processes, and consume unacceptable amounts of processing overhead. Likewise, a dynamic crypto map is used, which does not define a traffic set to protect traffic (protects all traffic from concentrator to client). An access list can be added to the dynamic crypto map to provide further granularity in the protected traffic set definition.

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 we’ve covered thus far is dissected into several major topics that build upon one another: ■

Overview of Cryptographic Components

■

Overview of IPsec Operation

■

Overview of ISAKMP Operation

As we’ve discussed earlier in this chapter, IPsec relies on many fundamental cryptographic operations to provide authenticity, integrity, confidentiality, and nonrepudiation services to IP data transmissions. Examples of such cryptographic components discussed include hashing functions and message digest creations, Digital Signatures, asymmetric key encryption, and symmetric key encryption. A secure hash ensures data integrity by performing a mathematical operation based on the original contents of the cleartext message. The resulting value of this mathematical operation is called a message-digest. The sender appends the message digest to the cleartext message and sends both to the receiver. The receiver then performs the same mathematical operation, or hash, on the received cleartext message. The results of this mathematical operation are then compared to the message digest sent from the sender. If the receiver’s message digest compares to the sender’s message digest, then the message’s integrity has not been compromised. In this operation, data authenticity, sender nonrepudiation, or confidentiality have not been provided. A Digital Signature provides data integrity, just as a hash function would. However, unlike a simple message digest, Digital Signatures also provide data authenticity and sender nonrepudiation. Digital Signatures do this by performing a hash based on the original message contents and a public cryptographic key (of a public/private asymmetric keypair). The resulting message digest is then encrypted with the private key of the asymmetric key pair, resulting in a Digital Signature. The sender sends its public key, the original cleartext message, and an appended Digital Signature to the receiver. The receiver then decrypts the Digital Signature with the public key received from the sender. At this point, the receiver performs the same hashing function on the cleartext message contents and the public key received from the sender. If the resulting message digest matches the decrypted message digest received from the sender, then the message is said to be authentic with preserved data integrity. Note that the original message was sent in the clear, and

Summary

101

that Digital Signatures therefore do not provide data confidentiality services to the original message. In different areas of the IPsec framework (including IKE), encryption and decryption can occur in one of two ways: symmetric key encryption and asymmetric key encryption. Symmetric key encryption refers to a cipher algorithm that uses the same key for encryption and decryption. Symmetric key encryption is therefore not suited for sharing keys over an untrusted medium. IPsec uses symmetric key transforms in its Phase II SA, as symmetric key transforms are better suited for bulk data transfer. Examples of symmetric key encryption ciphers include DES, 3DES, and AES. Asymmetric key encryption refers to a cipher algorithm that uses one key for encryption (typically the public key) and one key for decryption (typically the private key). Asymmetric key encryption provides increased flexibility with key exchange, enabling a public key to be exchanged over a relatively untrusted medium. Asymmetric encryption, however, is computationally more expensive than symmetric encryption and is therefore less suited to performing bulk data transfer. IKE commonly uses asymmetric key encryption for Phase I SA authentication. Examples of such asymmetric key encryption techniques include RSA-encrypted nonces and RSA Signatures. IPsec provides data authenticity, sender nonrepudiation, data integrity, and data confidentiality. At this point, we’ve discussed the mechanics of IPsec with and without IKE. Because IPsec ciphers require a symmetric key for bulk data encryption, keys must be defined manually on IPsec endpoints when IKE is not used. IPsec secures data by creating two unidirectional security associations between the two cryptographic endpoints. Those security associations specify the following components required to secure data transmissions between the endpoints: ■

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

■

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

■

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

■

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

■

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

102

Chapter 2: IPsec Fundamentals

■

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

■

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

IPsec specifies two protocols for data transformation: ESP, IP Protocol 50 or AH IP Protocol 51. ESP provides data confidentiality, while AH does not. Yet AH provides a broader scope of data authenticity and integrity than does ESP. In addition to the symmetric transform executed with AH or ESP, optional HMAC authentication can be performed on the data cipher blocks using either MD5 or SHA-1 hash algorithms. As we’ve discussed thus far, IPsec must use symmetric key transforms for bulk data ciphering. This requires that the symmetric key must be manually defined for every SA on each cryptographic endpoint. This presents substantial key and SA management scalability issues. The IKE protocol can be used in conjunction with IPsec to dynamically negotiate the elements required to establish an IPsec (Phase II) SA over an untrusted medium. IKE does this by first establishing an authenticated, secure channel across the untrusted medium using either one of three authentication methods: ■

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

■

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

■

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

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

Summary

103

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

CHAPTER

3

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

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

Step 2

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

Step 3

If IKE is required, decide on ISAKMP policy parameters (create Internet Security Association and Key Management Protocol policy), addressing the following tasks in your configuration: • Authentication method (select one of the following): Assign key and peer if pre-shared. Create and share RSA public keys if RSA-encr. Authenticate and enroll with CA if RSA-sig. • Diffie-Hellman Key Modulus (Group #) • Hash used for IKE authentication • Encryption method used for IKE channel

106

Chapter 3: Basic IPsec VPN Topologies and Configurations

Figure 3-1

High-Level Configuration Process for IPsec VPN

Configure IPSec Transform Set via process described in Figure 2-20

Does VPN require dynamic session keys using DH?

Configure Static IPSec Session Keys as part of Crypto Map (IPSec-Manual)

No

Configure Crypto Map to use ISAKMP for dynamic session keys. Yes

Configure Crypto Map Properties Pre-Shared Keys What type of authentication method is required?

Define traffic to be included in crypto path in ACL and reference ACL in Crypto Map

RSA-Encryption

RSA-Signatures

Strongest

How strong must the hash be during IKE? Stronger

Strongest

How strong must encryption of the IKE channel be?

Reference IPSec Transform Set in Crypto Map

MD-5 (128-bit)

SHA-1 (160-bit) Do I need DH keys to be freshly derived for IKE and IPSec?

No

AES (256-bit) Yes

Stronger

Strong

Strongest

How long must the DH session keys be?

Define IPSec peer, or multiple peers if HA is required

3DES (168-bit) Select DH modulus to use when PFS renegotiates DH

DES (56-bit)

Group5 (1536-bit) Strong

Stronger

Strong

Group2 (1024-bit)

Stronger

Group1 (512-bit)

Strongest

Group2 (1024-bit)

Group5 (1536-bit)

Group1 (512-bit) Reference Crypto Map on Appropriate VPN Interfaces

Site-to-Site IPsec VPN Deployments

Step 4

107

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

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

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

Step 6

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

Step 7

Apply crypto map to crypto interfaces.

Site-to-Site IPsec VPN Deployments The most basic form of IPsec VPN is represented with two VPN endpoints communicating over a directly connected shared media, or dedicated circuit, which closely resembles bulk encryption alternatives at Layer 1 and 2 of the OSI stack (see Table 1-1 for VPN technologies and the OSI stack). This scenario, while simple to deploy and manage, can be cost prohibitive and does not yield many of the benefits of IPsec VPN connectivity over a routed domain (multiple Layer 3 hops between endpoints). Indeed, because IPsec is a Layer 3 VPN technology, it was designed to function across multiple Layer 3 hops in order to circumvent many of the scalability and manageability issues in previous VPN alternatives. As such, IPsec deployed over a routed domain will also provide further scalability, flexibility, and availability over and beyond the simple dedicated-circuit model. In this section, we will explore design concepts related to both topologies and the corresponding configuration and verification processes required.

Site-to-Site VPN Architectural Overview for a Dedicated Circuit Site-to-site IPsec VPNs are typically deployed when two or more autonomous systems wish to communicate with each other over an untrusted media when confidential exchange of data is required. Consider the situation described in Figure 3-2, where three autonomous systems wish to communicate using dedicated T-1 circuits between each pair. It is important to note that, assuming that each autonomous system (AS) does not act as a transit AS, there is only one path between each AS. Therefore, in this specific case, there is no benefit to configuring redundant peering options or sourcing IPsec tunnel endpoints from highly available IP addresses (such as a loopback address). In this simple site-to-site topology, it is most common to source IPsec VPN tunnel endpoints on the physical interfaces (DS-3 in this case) themselves. This type of topology does not leave room for much in the way of IPsec HA design, and therefore, it is relatively simple to deploy. We will now explore the configuration steps necessary to establish the basic site-to-site IPsec VPN described earlier, and then we will outline some common techniques used to verify the establishment and operation of the IPsec VPN tunnel.

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 AS #1

DS-3 200.1.1.8/30

P

ES

ES

DS-3 200.1.1.0/30

P

Loopback 1 201.1.1.1/32 AS1-7304A

AS #2

AS #3

Loopback 1 202.1.1.1/32 AS2-3745A

Loopback 1 203.1.1.1/32 AS3-3745A

ESP DS-3 200.1.1.4/30

GRE Encapsulated Tunnels

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

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

■

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

■

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

■

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

■

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

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).

■

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

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

Site-to-Site VPN Configuration on AS1-7301A

show r unning-conf ig AS1-7304A#s ! 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

110

Chapter 3: Basic IPsec VPN Topologies and Configurations

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

Site-to-Site VPN Configuration on AS2-3745A

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

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

Site-to-Site IPsec VPN Deployments

Example 3-3

111

Site-to-Site VPN Configuration on AS3-3745A

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

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

Verify the establishment of ISAKMP SAs.

Step 2

Verify the establishment of IPsec SAs.

Step 3

Verify that basic network connectivity has been established over the VPN.

Step 4

Verify that the Crypto Engine is actively participating in IPsec and that protected traffic is being encrypted and decrypted.

Step 5

Check physical interface statistics for errors.

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

112

Chapter 3: Basic IPsec VPN Topologies and Configurations

ISAKMP SA States for IKE Main Mode SA Negotiation

Table 3-1

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 stage—there is no state.

MM_SA_SETUP

The peers have agreed on parameters for the ISAKMP SA.

MM_KEY_EXCH

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

MM_KEY_AUTH

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

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

Table 3-2

Example 3-4

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 stage—there is no state.

AG_INIT_EXCH

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

AG_AUTH

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

Verification of ISAKMP SAs for AS1-7304A

show c rypto isak mp sa AS1-7304A#s dst

src

state

200.1.1.10

200.1.1.9

QM_IDLE

conn-id slot 2

0

200.1.1.1

200.1.1.2

QM_IDLE

1

0

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 specified in the Crypto ACLs for this SA (211.0.0.0/ 8->212.0.0.0/8 for AS1VPN process 10 and 211.0.0.0/8->213.0.0.0/8 for AS1VPN process 20).

■

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

■

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

■

The peering encryption/decryption activity for this security association.

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

Example 3-5

Verification of IPsec SAs for AS1-7304A

show c rypto IPsec sa AS1-7304A#s 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

114

Chapter 3: Basic IPsec VPN Topologies and Configurations

Example 3-5

Verification of IPsec SAs for AS1-7304A (Continued)

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

Site-to-Site IPsec VPN Deployments

Example 3-5

115

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

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

Verification of Connectivity along the Crypto Path

show a ccess-list 102 AS1-7304A#s Extended IP access list 102 10 permit ip host 201.1.1.1 host 202.1.1.1 show a ccess-list 103 AS1-7304A#s Extended IP access list 103 10 permit ip host 201.1.1.1 host 203.1.1.1 pi n g AS1-7304A#p Protocol [ip]: Target IP address: 202.1.1.1

continues

116

Chapter 3: Basic IPsec VPN Topologies and Configurations

Example 3-6

Verification of Connectivity along the Crypto Path (Continued)

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

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

Site-to-Site IPsec VPN Deployments

117

ones previously displayed in Example 3-4). Because IPsec SAs are unidirectional, we confirm that there are 4 SAs present in AS1-7304A’s SADB: ■

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

■

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

■

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

■

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

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

Crypto Engine Verification

show c rypto engin e connect ions active AS1-7304A#s ID Interface

IP-Address

State

Algorithm

Encrypt

Decrypt

1 Se0/0.12

200.1.1.1

set

HMAC_SHA+3DES_56_C

0

0

2 Se0/0.13

200.1.1.9

set

HMAC_SHA+3DES_56_C

0

0

2000 Se0/0.12

200.1.1.1

set

HMAC_SHA+AES_CBC

0

99

2001 Se0/0.12

200.1.1.1

set

HMAC_SHA+AES_CBC

99

0

2002 Se0/0.13

200.1.1.9

set

HMAC_SHA+AES_CBC

0

99

2003 Se0/0.13

200.1.1.9

set

HMAC_SHA+AES_CBC

99

0

Site-to-Site Architectural Overview over a Routed Domain The design considerations of a site-to-site IPsec VPN change considerably once the underlying transit media changes. Consider the preceding site-to-site IPsec VPN example—how would our design change if we were to replace the existing dedicated DS-3 links between ASs with DS-3 uplinks to an Internet service provider? Network designers face the challenge of dealing with multicast traffic in the crypto switching path. Multicast traffic, including Interior Gateway Protocol (IGP) multicast hellos and multicast data feeds, cannot be sent natively across an IPsec VPN tunnel. Instead, the multicast data must be encapsulated with unicast header (such as IP generic routing encapsulation (GRE)) before being presented to the IPsec crypto engine. Typically, these design considerations have encouraged the use of leased-line connectivity for VPN extension and the insertion of GRE tunnels through the IPsec tunnel (commonly referred to as IPsec+GRE) to accommodate the multicast traffic associated with the routing protocol updates

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 offices over an independently maintained routed domain, such as the Internet. The smaller branch offices consist of a number of routed nodes and, as such, would benefit from getting Route Processor (RP) updates from the campus network. Figure 3-3 demonstrates how the addition of a site-to-site IPsec VPN across the independently maintained routed domain would preclude the smaller home offices from exchanging RP updates with the campus network at the corporate HQ. Due to IPsec’s inability to natively encrypt multicast traffic, the design in Figure 3-3 presents the following design considerations: ■

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

■

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

■

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

The solution to these design considerations is to add GRE tunnels to the IPsec VPN implementation. RP traffic between the corporate HQ and branch networks will then be encapsulated with GRE headers and forwarded in the crypto switching path across the ISP network. We will discuss IPsec+GRE architectures in greater detail later in this chapter. Consider the following example, in which a corporation, a large global financial organization, wants to allow extranet connectivity to its partners. The primary use of this extranet connection is to stream multicast data containing video and market information to decision makers within the global financial organization. This must be done securely and with confidentiality. The insertion of an independently maintained routed domain between the corporate extranet partner and the global financial organization breaks the multicast tree between the two parties, as illustrated in Figure 3-4.

Site-to-Site IPsec VPN Deployments

Figure 3-3

IPsec RAVPN Extension to Small Home Office over the Internet

HQ Campus Net 201.4.0.0/16

Si

Si

201.3.1.4/30 Loopback 1 201.1.1.1/32 HQ-7304A

201.3.1.0/30 Loopback 1 201.2.2.2/32 HQ-3745AS

Corporate HQ DS-3 200.1.1.0/30

ISDN-PRI 199.1.1.0/24

3

ISP T-1 200.1.1.4/30

ISDN-BRI 199.1.1.8/30 ISDN-BRI 199.1.1.4/30

T-1 200.1.1.8/30

1

1 2 B1-3745A Loopback 1 202.1.1.1/32

2 B2-3745A Loopback 1 203.1.1.1/32

Branch1 Net 201.4.129.0/28

Branch2 Net 201.4.129.128/28

Branch-1

Branch-2

T-1 Recovery from ISDN Failover IPSec VPNs Routing Protocol Update

119

120

Chapter 3: Basic IPsec VPN Topologies and Configurations

Figure 3-4

Corporate Extranet Connection Using Internet Uplinks and IPsec VPNs

Extranet crypto engine does not process PIM updates or multicast traffic— sent in cleartext

Campus Net:

Extranet partner’s crypto engine does not encrypt multicast feeds to campus net.

ISP

201.40.0.0/16

Extranet Partner 199.1.1.0/24

Multicast Reciever A

Multicast Reciever B

201.4.1.1/24

201.4.2.1/24

Campus Extranet

IPTV Server

Tibco Server

(224.0.0.2) 199.1.1.200

(224.0.0.1) 199.1.1.100

Extranet Partner

Multicast Traffic from Quote Server and IPTV Server PIM Messages (Join, Prune, etc.)

The extranet model breaks multicast in two areas. First, underlying media is not configured to support peripheral interface manager (PIM) or multicast routing. Therefore, even without IPsec, the multicast tree would never form properly with this deployment. Second, assuming that the multicast tree could be established, IPsec would fail to send multicast flow in ciphered format. Again, the addition of GRE to the corporate extranet would allow extension of PIM traffic across the Internet. Additionally, because the PIM updates are encapsulated in GRE prior to encryption, the PIM packets encapsulated in GRE would be processed in the crypto switching path and forwarded securely across the IPsec VPN. TIP The Cisco V3PN solution outlines a VPN architecture that accommodates voice and video over IPsec. Because IP multicast is a key component of many voice and video streaming technologies, V3PN requires the use of IPsec+GRE. For more information on V3PN, please refer to the following documentation on CCO http://www.cisco.com/en/US/partner/netsol/ns340/ns394/ns171/ns241/networking_solutions_ sub_solution_home.html

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

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

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

Multicast Packet GRE Encapsulation (IP Multicast Encapsulated GRE Encapsulated in ESP) Outer ESP GRE Original Multicast TCP IP Header Header Header IP Header Header

Data

ESP Trailer

ESP Auth.

Encrypted

Authenticated

Unprotected

Unprotected

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

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 fields, and trailer (subtotal of approximately 56 bytes). Increasing packet sizes in this fashion also increases the chances that the packet will be fragmented after it has been encrypted, as would be the case if the encrypted packet exceeds the MTU of a link somewhere in the path between the two VPN endpoints. This can cause problems on the decrypting router, which will attempt to decrypt the fragmented packets in the process switching path (without hardware assist), causing scalability issues in terms of performance. Path MTU discovery can be deployed in conjunction with the Cisco IOS IPsec prefragmentation, enabling the encrypting router to dynamically determine the smallest MTU of the path between VPN endpoints. The encrypting VPN router is then capable of fragmenting to the appropriate MTU for the path on a per-SA basis using IPsec prefragmentation, assuring that the fragmentation of IPsec packets always occurs prior to encryption and is therefore done in the fast path. NOTE Common fragmentation issues in IPsec VPNs are discussed in detail in Chapter 4, “Common IPsec VPN Issues.” Available solutions for fragmenting prior to encryption, including path MTU discovery and IPsec prefragmentation, are also discussed in Chapter 4.

GRE and Weighted Fair Queuing Some quality of service (QoS) techniques, such as weighted fair queuing (WFQ), perform conversation hashing decisions based on the original source and destination IP address, which can be ubiquified after IPsec or GRE encapsulation. While DiffServ markings are copied to the outer IP header in tunnel mode IPsec, the original source and destination are not carried forward into outer IP header. In order to appropriately execute hashing decisions in WFQ operations, packets must therefore be classified prior to encapsulation. Cisco IOS supports IPsec QoS pre-classify functionality on IOS VPN endpoints to assure that flow and conversation-based queuing decisions can be executed accurately in IPsec VPN environments. QoS and the IPsec Anti-Replay Window Altering the scheduling of packets before IPsec processing (as is the case with QoS pre-classify) conflicts with sequencing schemes native to IPsec that are used for anti-replay protection. Cisco IOS offers IPsec QoS Pre-Classify, which allows packets to be queued prior to ESP, AH, or GRE encapsulation. Alternatively, anti-replay windows can be increased to ensure that IPsec packets are received within the anti-replay window even when reordered and delayed due to queuing decisions on nodes between IPsec VPN endpoints. When deploying QoS in vendor-diverse environments, it is recommended that the operation be monitored to ensure that packet reordering does not conflict with anti-replay functions native to IPsec.

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

123

Site-to-Site IPsec+GRE Sample Configurations Thus far, we have introduced the requirement of unicast presentation of data flows to the IPsec crypto engine. In this section, we will discuss working IPsec+GRE configuration procedures, examples, and verification techniques to use when encapsulating multicast traffic with a unicast header so that it can be processed with encrypted with IPsec. Cisco IOS Site-to-Site IPsec+GRE Configuration We will now alter the configurations that we built in Examples 3-1 through 3-3 to include GRE encapsulation prior to the encapsulation of ESP. The IPsec transform and ISAKMP polices will remain consistent with Examples 3-1 through 3-3, as will the some of the crypto map configuration elements, such as the PFS and peering configurations. However, other crypto map configuration elements, such as the crypto ACLs, will change to accommodate GRE traffic. We will also demonstrate IOS QoS for IPsec VPNs by configuring the routers to classify packets prior to GRE encapsulation and crypto processing. The topology used for these configurations is depicted in Figure 3-2, but instead of native IPsec ESP tunnels, the ESP-encapsulated pointto-point GRE tunnels are used between the edge routers of AS#1, AS#2, and AS#3. Example 3-8 illustrates some of the configuration changes made to AS1-7304A to accommodate IPsec+GRE. One of the most important differences in this configuration compared to Example 3-1 is the change in the crypto ACLs. Note that in Example 3-8, the crypto ACLs protect GRE traffic from the GRE tunnel source and destination address from AS1-7304A to AS2-3745A and AS33745A, respectively. This will effectively encrypt all traffic passing over the GRE tunnels from AS1-7304A to AS2-3745A and AS3-3745A. In addition to the crypto ACL change on ASS1-7304A, several measures are taken to guarantee that encrypted packets are not fragmented. AS1-7304A’s crypto engine will attempt to fragment packets to the path MTU (discovered through path MTU discovery between the two VPN endpoints) of the appropriate SA in the SADB. Additionally, AS1-7304A is configured to set the DF bit in the outer IP header of the encrypted fragments, effectively ensuring that network nodes between the two crypto endpoints are not able to fragment encrypted messages while in transit. Example 3-8

Site-to-Site VPN Configuration on AS1-7301A

show r un AS1-7304A#s ! crypto df-bit set ! crypto ipsec fragmentation before-encryption !

continues

124

Chapter 3: Basic IPsec VPN Topologies and Configurations

Example 3-8

Site-to-Site VPN Configuration on AS1-7301A (Continued)

! access-list 101 permit gre host 201.1.1.1 host 202.1.1.1 access-list 102 permit gre host 201.1.1.1 host 203.1.1.1 ! interface Tunnel12 ip address 200.1.12.1 255.255.255.252 qos pre-classify tunnel source 201.1.1.1 tunnel destination 202.1.1.1 ! interface Tunnel13 ip address 200.1.13.1 255.255.255.252 qos pre-classify tunnel source 201.1.1.1 tunnel destination 203.1.1.1 ! interface Loopback1 ip address 201.1.1.1 255.255.255.255 !

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

Site-to-Site VPN Configuration on AS2-3745A

show r un AS2-3745A#s ! 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

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

Example 3-9

125

Site-to-Site VPN Configuration on AS2-3745A (Continued)

qos pre-classify tunnel source 202.1.1.1 tunnel destination 203.1.1.1 ! interface Loopback1 ip address 202.1.1.1 255.255.255.255 !

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

Site-to-Site VPN Configuration on AS3-3745A

show r un AS3-3745A#s ! 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 !

126

Chapter 3: Basic IPsec VPN Topologies and Configurations

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

Verification of tunnel establishment

■

Verification of RP (including PIM) adjacencies through the tunnel

Once these basic tunneling operations have been verified, they must be re-verified after the addition of IPsec. In addition to that re-verification, the administrator should also verify the establishment of ISAKMP SA, IPsec SA, and that traffic passed over the IPsec+GRE tunnel is actually being encrypted, as we explored in Examples 3-4 through 3-7. Example 3-8 demonstrates the non-crypto GRE verification steps on AS1-7304A (prior to the addition of the crypto map to the physical interface) and the verification of the full IPsec+GRE tunnel (after the crypto map has been applied to the physical interface). Again, note that all EIGRP traffic is kept confidential from the OSPF core via IPsec processing of all GRE traffic (which in this case includes all EIGRP traffic— 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

Verification of GRE Tunnels and Tunneled Routing Protocols on AS1-7304A

show i p int brie f AS1-7304A#s Interface

IP-Address

OK? Method Status

FastEthernet0/0

unassigned

YES NVRAM

administratively down down

Protocol

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

ping 1 92.168.12. 2 AS1-7304A#p 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

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

127

Verification of GRE Tunnels and Tunneled Routing Protocols on AS1-7304A (Continued)

Example 3-11

ping 1 92.168.13.2 AS1-7304A#p 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 show i p eigrp int erfaces AS1-7304A#s IP-EIGRP interfaces for process 192 Xmit Queue

Mean

Pacing Time

Multicast

Pending

Peers

Un/Reliable

SRTT

Un/Reliable

Flow Timer

Routes

Lo1

0

0/0

0

Tu12

1

0/0

736

Tu13

1

0/0

277

Interface

0/10

0

0

71/2702

6362

0

71/2702

3710

0

sh ip eigrp neigh bors AS1-7304A#s IP-EIGRP neighbors for process 192 H

Address

Interface

Hold Uptime

SRTT

(sec)

(ms)

RTO

Q

Seq

Cnt Num

1

192.168.13.2

Tu13

12 00:18:36

277

5000

0

41

0

192.168.12.2

Tu12

12 00:19:01

736

5000

0

48

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

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

sh cry pto engine conn acti ve AS1-7304A#s 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

128

Chapter 3: Basic IPsec VPN Topologies and Configurations

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

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

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

■

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

■

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

■

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

■

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

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 enterprise’s centrally located resources. NOTE This section on hub-and-spoke architecture only discusses HA items directly relevant to the physical layout of the IPsec VPNs themselves. IPsec HA design optimization in IOS, ASA, and VPN3K appliances is discussed comprehensively in Chapters 6 through 10.

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

Hub-and-Spoke IPsec VPN Variations

Hub and Spoke Design #1: Standard Hub and Spoke Design, No High-Availability

Hub and Spoke Design #2: Clustered Design to Redundant Hubs Hub A

Cluster A

Hub B

Cluster B

Hub and Spoke Design #3: Redunant Spokes Clustered to Redundant Hubs

Hub C

Hub A

Cluster C

Cluster A

Hub B

Cluster B

Hub C

Cluster C

Standard Hub-and-Spoke Design without High Availability The simplest hub-and-spoke design consists of single-circuit, single-spoke connectivity to a hub router at a central facility, as described in the first design of Figure 3-6. This design, while simple from an architectural standpoint, does not allow much in the way of HA design enhancements, because this design is typically found in branch deployments that do not require high degrees of network uptime. From a performance perspective, the design considerations are focused largely on the hub. Because the spoke devices are maintaining minimal IPsec VPN tunnels and GRE tunnels, the IPsec and GRE performance is likely to be at the platform maximum when stressed. This is not

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 Scalability—The hub router must have the appropriate amount of memory to accommodate the SADB for the whole hub/spoke deployment. Remember from our previous discussions in Chapter 2, “IPsec Fundamentals,” that the number of IPsec SAs needed will be the twice the number of IPsec connections plus one SA for each IKE channel.

■

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

■

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

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

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

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

Increased Tunnel Termination/Maintenance Capacity—Using multiple hub routers decreases the amount of memory required for SA maintenance on a per-platform basis, because the SAs are spread across three aggregation points (as opposed being concentrated

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 Capacity—Distributed Hub IPsec processing also presents two additional multicast fanout points to the design. This type of distribution at the multicast fanout points can dramatically improve the switching performance of the hub-and-spoke deployment, because computational resources for copying multicast packets, encapsulating them in GRE, and encrypting them are tripled at the aggregation points.

■

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

Redundant Clustered Spoke Design to Redundant Hubs Design #3 in Figure 3-6 describes a topology similar to Design #2, but with redundant routers at the spoke. This is the most highly–available design discussed in this chapter, and it will lead us in to design concepts discussed in Chapters 6–10. It is also the most expensive of the three designs to deploy, as it doubles the amount of hardware to be purchased at the spoke level. With respect to the design of the IPsec VPNs themselves, the addition of redundant spoke routers could boost performance of the IPsec VPN, especially if both IPsec tunnels were concurrently active and traffic from the spoke is load-balanced across the two redundant spoke routers. These benefits, however, although useful, are only local to the spoke itself, which is why it is more common to invest in redundancy and load-balancing improvements at the hub before adding it to the spokes. Additionally, large-scale deployment of redundant spoke routers will require more processing capability to accommodate increased IKE processing, or increased SADB capacity if a “hot” standby model is required (see Chapters 6–10 for design concepts surrounding IPsec HA in IOS). Because of this, the primary benefit of adding an additional, redundant, router to a spoke in the greater hub/spoke design is redundancy at that particular branch. For this reason, it is most common to see only highly-available branches pursue this design, while other spokes are deployed using the framework we have discussed in Designs #1 or #2. The cost-benefit analysis of pursuing redundant uplinks and redundant routers at the spoke must be weighed carefully against the cost (both computational and monetary) of deployment. It is rare to see blanket rollouts of Designs #1, #2, or #3 shown in Figure 3-6. Instead, it is much more common to see designs that incorporate elements of all three designs on a per-spoke performance– and HA-requirement–basis.

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. We’ve discussed some of the business drivers for enterprise adoption of RAVPN deployments during our introduction to VPNs in Chapter 1. Now we will explore some common architectures for delivering RAVPN services to the enterprise. NOTE Cisco Systems Business Ready Teleworker Solutions fully outlines the business justification for RAVPN deployments. Please refer to the following resources on CCO for more information on Cisco Business Ready Teleworker Solutions: http://www.cisco.com/application/pdf/en/us/guest/netsol/ns241/c649/ ccmigration_09186a00801ea79d.pdf

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

RAVPN Clients RAVPN clients typically come in two general flavors, hardware-based clients and software-based clients. Software-based VPN clients run locally on the user’s remote workstation or laptop, and they are used to connect to a centrally managed VPN concentrator, typically located on the enterprise campus. The strength of software-based VPN clients is rooted in the mobility that they provide. When deployed on a user’s laptop, a software-based VPN client can securely extend confidential communications from the campus to anywhere that a VPN client can access Layer 3 communications. Software-based VPN clients are therefore useful for tunneling data from centrally located campus resources to the end user. However, they do have limitations, and because of these limitations, the use of hardware-based VPN clients is merited in some situations. Specifically, software-based VPN clients terminate VPN connectivity locally on teleworkers’

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 flows. Hardware-based clients, though inherently less mobile, address many of the functional limitations found in software-based IPsec VPN clients. Hardware-based VPN clients are typically found in small, remote locations that do not have dedicated connectivity to a central hub IPsec router. These devices are commonly found at home offices that have DSL- or cable-modem connectivity to the Internet. The hardware-based VPN client maintains the IPsec VPN (and GRE tunnel termination) to the concentrator, while allowing cleartext IP communications locally within the small home office or branch. Therefore, hardwarebased VPN components add a networked element to the SOHO (small office, home office) or small branch environment that allows users to extend voice, video, and data securely from the campus. In order to deliver both mobility and breadth of services to remote teleworkers, it is very common to see users deploy both software-based VPN clients and hardware-based VPN clients at the same time. Having the hardware-based VPN connectivity extends virtually all IP services available on the campus to relatively fixed remote locations. Software-based VPN communications allows users to extend communications in highly mobile scenarios. All of these services must be accommodated on the concentrator side of the VPN. For this reason, the variation in RAVPN topology is most commonly seen at the concentrator end of the design, which is what we will focus the remainder of this chapter’s RAVPN discussion on.

Standalone VPN Concentrator Designs Due to the nature of IPsec and firewalls, the placement of the VPN concentrator in a DMZ design is critical to the success of the greater RAVPN architecture. Figures 3-7 through 3-10 outline several DMZ topologies that we will use to explore common design issues which must be addressed in RAVPN design. Each of these designs pertains to an IPsec VPN concentrator deployment for effective termination of client IPsec VPN tunnels in an RAVPN environment. VPN Concentrator on Outside Network with Single DMZ The DMZ layout illustrated in Figure 3-7 is one of the most common, and most effective, designs in RAVPN/DMZ integration. This design allows for increased security, because inside traffic from the VPN concentrator is firewalled from the firewall’s DMZ interface to its inside interface.

134

Chapter 3: Basic IPsec VPN Topologies and Configurations

Figure 3-7

VPN Concentrator Placement in Single-DMZ Design Enterprise

Inside

DMZ 1

Outside

Service Provider

Also, the firewall can add an additional layer of proxy authentication AAA authentication in conjunction with an ACS server located on the inside network, offering a comprehensive authentication, authorization, and accounting solution for traffic types all the way up to Layer 7. The processing of traffic inbound from the DMZ can be further inspected for network attacks using either the PIX IOS-based signature set or a compatible, more comprehensive, signature set maintained on an external Network Intrusion Detection Systems (NIDS) appliance. As we will also see with the design in Figure 3-8, there are no IPsec-specific modifications that need to be added to the firewall ACL configuration. Likewise, there are no additional Network Address Translation (NAT) considerations to account for on the firewall. This design does, however, require marginally increased filtering capability on the firewall, as cleartext traffic from the IPsec VPN concentrator is now being processed on the DMZ interface on its way to the inside network. VPN Concentrator and Firewall in Parallel Placing the VPN concentrator in parallel with the firewall eliminates the possibility of human error when opening up holes in the firewall ACL to allow IPsec traffic from inbound VPN clients to the concentrator (as with the design illustrated in Figure 3-10). Figure 3-8 provides an illustration of a standard DMZ design that places the VPN concentrator in parallel with the firewall.

Remote Access VPN Deployments

Figure 3-8

135

Parallel VPN Concentrator and Firewall DMZ Design Enterprise

Inside

Outside

Service Provider

Additionally, this topology presents no computational overhead on the firewall for processing IPsec traffic in to the VPN concentrator. Instead, that traffic is focused solely on the VPN concentrator. Likewise, the concentrator is not burdened by non-VPN traffic, as would be the case if the concentrator were placed in series with the firewall on the outside network. The parallel configuration described in the design of Figure 3-8 also simplifies the NAT configuration on both the firewall and the DMZ. Although IPsec itself can accommodate environments where addresses are being translated, this topology eliminates the NAT processing of VPN traffic firewall and concentrator. Therefore, for RAVPN IPsec tunnels, the need for vendor-specific IPsec extensions such as NAT-T (IPsec NAT Transparency) is avoided. NOTE NAT can cause implementation issues in IPsec networks if not properly designed for. For more information concerning common issues related to NAT in IPsec networks, please refer to Chapter 4, “Common IPsec VPN Issues.” Solutions for IPsec in NAT environments, such as IPsec NAT-T, are also discussed in Chapter 4.

VPN Concentrator with Dual DMZs to Firewall Using two DMZ interfaces for inside and outside VPN traffic, as described in the design shown in Figure 3-9, can also be an effective means by which to integrate a VPN concentrator into a DMZ. This design should be deployed when increased protection of the VPN concentrator itself is

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 firewall, as opposed to the Internet gateway, to switch packets to the appropriate directly connected interface. As a result, it would be the firewall’s responsibility to forward VPN traffic directly connected to DMZ1 interface and allowed NAT’d (if necessary) enterprise traffic directly to the inside interface. Figure 3-9

VPN Concentrator with Dual DMZs to Firewall Enterprise

Inside

DMZ 2 DMZ 1

Outside

Service Provider

Locating the VPN concentrator’s outside interface behind the DMZ inserts a layer of filtering and authentication of IPsec traffic before the concentrator, thereby adding another layer of hardening to the design. There are also tradeoffs to the design, because the outside ACL of the firewall must be altered to allow ISAKMP, ESP, and AH traffic through to the concentrator. In addition to punching holes through the ACL to accommodate VPN traffic, this design also increases the computation overhead associated with VPN traffic on the firewall, because traffic is processed twice (once on the outside interface, and again as traffic is received from the concentrator on the second DMZ interface). What to Avoid in DMZ/VPN Concentrator Topologies We will use the design shown in Figure 3-10 to highlight a few things to avoid when positioning a VPN concentrator in a DMZ. The fourth design places the concentrator in a position that requires

Remote Access VPN Deployments

137

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

What to Avoid in DMZ/VPN Concentrator Topologies Enterprise

Location A Inside Moving concentrator inside firewall decreases effectiveness of firewall design Outside Location B

Service Provider

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

Clustered VPN Concentrator Designs The RAVPN designs we have discussed thus far only assume the use of a single VPN concentrator. However, all of these designs can be hardened further through the deployment of multiple concentrators in the appropriate location, commonly referred to as “clustering.” The deployment of a VPN cluster offers redundancy locally at the concentrator level, and it also allows for increased scalability in terms of the number of inbound IPsec VPN tunnels from VPN clients that

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 Enterprise

Inside

DMZ 1

3x cluster triples local concentrator redundancy and IPSec VPN tunnel processing capacity

Outside

Service Provider

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

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

Site-to-site IPsec VPNs

■

Site-to-site IPsec+GRE VPNs

■

Hub-and-spoke IPsec VPN topologies

■

Remote access VPN topologies

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-tosite IPsec VPN over a dedicated circuit and site-to-site IPsec VPN over a routed domain. The introduction of a routing protocol between the two crypto endpoints provides a material alteration to the VPN topology. As with site-to-site IPsec VPN design variations, we have also covered several variations of huband-spoke IPsec VPN deployments, including the following: ■

Standard hub-and spoke design (no hub redundancy)

■

Clustered hub-and-spoke design to redundant hubs

■

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

Our discussion in this chapter of the basic advantages to each of the preceding hub-and-spoke variations will provide useful context when discussing resilient IPsec VPN design strategies in future chapters. Finally, we have introduced several common DMZ designs with various IPsec VPN concentrator placement alternatives. These design alternatives included the following: ■

Standalone VPN concentrator DMZ design

■

Parallel VPN concentrator and firewall DMZ design

■

Dual DMZ VPN concentrator design

■

Serial VPN concentrator placement on inside firewall interface

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

CHAPTER

4

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

IKE SA Proposal Mismatches

■

IKE Authentication Failures

■

IPsec SA Proposal Mismatches

■

Crypto ACL Mismatches

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

IPsec in Firewalled Environments

■

IPsec in NAT Environments

■

IPsec and Quality of Service

■

IPsec and Fragmentation

■

IPsec and Recursive Routing

IPsec Diagnostic Tools within Cisco IOS The most commonly used categories of diagnostic tools used within Cisco IOS are show and debug commands. Throughout the course of this chapter, we will use variations of these two command sets to diagnose issues commonly found within Cisco IOS. As we’ve discussed, there are detailed steps that occur during the formation of Internet Security Association and Key

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 flow

■

show crypto engine qos

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

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

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

ISAKMP SA Negotiation Resulting in ISAKMP Proposal Mismatch .1

Network_B 202.1.1.0/24

200.0.0.0/30

Router_B

.2

Network_A 201.1.1.0/24

Router_A

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

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

show c rypto isak mp policy Router_A#s 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

144

Chapter 4: Common IPsec VPN Issues

Example 4-1

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

Default protection suite encryption algorithm:

DES - Data Encryption Standard (56 bit keys).

hash algorithm:

Secure Hash Standard

authentication method:

Rivest-Shamir-Adleman Signature

Diffie-Hellman group:

#1 (768 bit)

lifetime:

86400 seconds, no volume limit

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

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

show c rypto isak mp policy Router_B#s 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

Common Configuration Issues with IPsec VPNs

145

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

Router A sends its configured ISAKMP policies 10, 20, and 30 to Router B.

2.

Router B checks policy 10 obtained in step 1 against its own configured policies, beginning with the lowest numbered policy and ending with the highest.

3.

If Router B does not find a match in step 2, it checks policy 20 obtained in step 1 against its own configured policies, starting with the lowest numbered and ending with the highest.

4.

If Router B does not find a match in step 3, it checks policy 30 obtained in step 1 against its own configured policies, starting with the lowest numbered and ending with the highest.

5.

If Router B does not find a match in step 4, then a proposal mismatch has occurred, and the Phase 1 negotiation times out.

In order to confirm that IKE proposal mismatches have occurred in an IPsec VPN tunnel negotiation, we will inspect the output of the ISAKMP SA negotiation between Routers A and B. Routers A and B are using preshared IKE authentication in a site-to-site VPN, but have not been configured with matching ISAKMP policies. We will execute the command debug crypto isakmp on routers A and B to highlight that an IKE proposal mismatch is indeed the cause of ISAKMP SA negotiation failure. Example 4-3 displays debugging output as ISAKMP policies proposed by Router_A are checked against locally configured policies on Router_B. In the diagnostic output shown in Example 4-3, Router_B checks proposals sent from Router_A for potential matches. Router_B begins by checking the ISAKMP proposals sent from Router_A against its own configured ISAKMP proposals. It does this by checking all of the proposals received (starting with lowest numbered and ending with highest) against favored policy (lowest numbered). If there are no matches, it checks the received policies in the same order against its next-lowest-numbered policy. This process continues until a match is found or all policies have been checked and no match has been found. In this specific proposal, the encryption proposed for encrypting the IKE channel does not match (see Examples 4-2 and 4-3 for ISAKMP proposal information for Router_A and Router_B), and Router B continues to check other offered proposals against its locally configured ISAKMP policies. Example 4-3, line 12, confirms that a proposal mismatch has occurred. Router_B finds that no ISAKMP proposals sent from Router_A match its own configured ISAKMP policies and therefore deletes the Phase1 SA and Phase1 negotiation times out on Router_A, as confirmed in Example 4-3, line 18. Example 4-3

Isolating IKE Proposal Mismatches on the Initiating VPN Endpoint (Router A)

1

debug crypto isak mp Router_B#d

2

Crypto ISAKMP debugging is on

3

!

continues

146

Chapter 4: Common IPsec VPN Issues

Example 4-3

Isolating IKE Proposal Mismatches on the Initiating VPN Endpoint (Router A) (Continued)

4

!

5

*Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):Checking ISAKMP transform 1 against priority 10 policy

6

*Feb 16 12:11:02.379: ISAKMP:

encryption 3DES-CBC

7

*Feb 16 12:11:02.379: ISAKMP:

hash MD5

8

*Feb 16 12:11:02.379: ISAKMP:

default group 2

9

*Feb 16 12:11:02.379: ISAKMP:

auth pre-share

10 *Feb 16 12:11:02.379: ISAKMP:

life type in seconds

11 *Feb 16 12:11:02.379: ISAKMP:

life duration (VPI) of

0x0 0x1 0x51 0x80

12 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):Encryption algorithm offered does not match policy! 13 ! 14 ! 15 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):no offers accepted! 16 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0): phase 1 SA policy not acceptable! (local 200.0.0.2 remote 200.0.0.1) 17 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):peer does not do paranoid keepalives. 18 *Feb 16 12:11:02.379: ISAKMP:(0:0:N/A:0):deleting SA reason "Phase1 SA policy proposal not accepted" state (R) MM_NO_STATE (peer 200.0.0.1)

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

IKE Authentication Failures and Errors Recall from our previous discussions that, in Cisco IOS, there are three methods offered to authenticate peers wanting to negotiate an ISAKMP SA: preshared keys (PSKs), RSA signatures, or RSA encryption. As we had discussed in Chapter 2, all three authentication methods have distinct elements used when authenticating IKE Peers. We will discuss common IKE authentication failure issues within the context of each of these three authentication methods. IKE Authentication Errors and PSKs There are two conditions that must be met for two IPsec VPN endpoints to authenticate each other using IKE PSKs. First, matching keys must be configured on the two endpoints. Second, the endpoints must be configured to share these keys with the correct peer. Router_A and Router_B are now configured with matching ISAKMP policies for Phase 1 negotiation, but still have problems preventing them from authenticating one another. We will examine debugging output on the routers in Figure 4-2 to highlight authentication failures directly attributable to mismatched keys and mismatched peers.

Common Configuration Issues with IPsec VPNs

147

Troubleshooting IKE PSK Authentication

Figure 4-2

Router_A

Router_B

.1

Network_A 202.1.1.0/24

200.0.0.0/30

Loopback 1 = 201.0.0.1/32 IKE PSK = Tarheels

.2

Network_B 202.2.2.0/24

Loopback 1 = 201.0.0.2/32 IKE PSK = Bluedevils

IKE Preshared Keys are mismatched and shared with incorrect peers (Router_ A sources session from 201.1.1.1) Router_A, ISAKMP Policy 30 = Router_B, ISAKMP Policy 10

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

1

Mismatched IKE PSK on Router_A (Corresponds with Mismatched Key for Router_B in Example 4-5) show c rypto isakm p policy Router_A#s

2 3

Global IKE policy

4

#

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 11

lifetime:

86400 seconds, no volume limit

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

148

Chapter 4: Common IPsec VPN Issues

Example 4-4

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

28

lifetime:

86400 seconds, no volume limit

29

show c rypto isak mp key Router_A#s

30

Keyring

Hostname/Address

PSK

default

200.0.0.2

tarheels

31 32

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

1

Mismatched IKE PSK on Router_B (Corresponds with Mismatched Key for Router_A in Example 4-4) show c rypto isak mp policy Router_B#s

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 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

show c rypto isak mp key Router_A#s

30

Keyring

Hostname/Address

PSK

default

200.0.0.1

bluedevils

31 32

Common Configuration 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, confirms that the two crypto peers have agreed on an IKE proposal. However, Example 4-6, line 18, confirms that the SA fails negotiation due to a PSK mismatch. Example 4-6

PSK Authentication Failure Between Two IKE Endpoints

1

debug crypto isak mp Router_A#d

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 its sanity check or is malformed

failed

Mismatched Peer Addresses in IKE PSK Definition As we have discussed, there are two elements to troubleshoot in a PSK authentication scheme. Thus far, we’ve covered IKE failure due to PSK mismatches. Now, let’s turn our attention to IKE issues surrounding peering specification on PSKs. Suppose that, in Figure 4-2, Router_A decides to source all peering sessions from its loopback interface (loopack 1, ip=201.0.0.1/32). The default behavior of an IOS IPsec endpoint is to source the IPsec VPN tunnel from the IP address of the physical interface where the crypto map is applied. Example 4-7 changes IPsec peering behavior from the router’s default settings by instructing the router to use a loopback interface for sourcing the IPsec VPN tunnel. Example 4-7

Router_A Sources IPsec VPNs from Its Loopback1 Interface (201.0.0.1)

! crypto map Route r_A_Map lo cal-address Loopback1 ! interf ace Loopba ck1 ip add ress 201 .0.0.1 255 .255.25 5.255

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 first change their IPsec peering definition in their crypto map to point to Router_A’s new source (its loopback address, 201.0.0.1). This change is illustrated in the configuration fragment provided in Example 4-8. Example 4-8

Necessary Peering Changes Required on Router_B

! crypto isakmp key tarheels address 2 01.0.0.1 ! crypto map Router _B_Map 1 0 I Psec-isakmp set peer 2 01.0. 0.1

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

IKE Authentication Failure Due to PSKs Not Being Shared with the Correct Peer Addresses

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

Solving Key Mismatch and Peer Mismatch Issues on Router_A and Router_B Indeed, the administrators of Router_B realize that they had made a mistake in selecting “bluedevils” as the IKE PSK and fix the problem. Additionally, all of the ISAKMP address information on PSK definitions on Router_A and Router_B have changed to be consistent. Now that Router_A and Router_B can agree on an ISAKMP policy and PSK with the appropriate peering information intact, an IKE can successfully be negotiated as evidenced by debugging output from IKE Phase 1 negotiation on Router_B (Example 4-10). Example 4-10, line 13,

Common Configuration Issues with IPsec VPNs

151

confirms that the two crypto peers have agreed on an ISAKMP proposal, and Example 4-10 line 22 confirms that the SA has been authenticated. Once Phase 1 negotiation is complete, the ISAKMP SA can be verified without debugging, using show commands, as illustrated in Example 4-10, lines 23–25. Successful IKE Authentication Using PSKs (Router_B)

Example 4-10 1

debug crypto isak mp Router_B#d

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

25 200.0.0.2

201.0.0.1

QM_IDLE

conn-id slot 1

0

IKE Authentication Errors with RSA Encryption As with the PSK method of authenticating IKE peers, IKE authentication failures using RSA encryption are commonly attributed to two categories—mismatched 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 keys—the 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.

152

Chapter 4: Common IPsec VPN Issues

IKE Authentication Failure—Mismatched RSA Public Keys

Figure 4-3

Router_A Network_A 202.1.1.0/24

Router_B

.1

200.0.0.0/30

Loopback 1 = 201.0.0.1/32

.2

Network_B 202.2.2.0/24

Loopback 1 = 201.0.0.2/32

Router_B has been mistakenly configured with Router_A’s private/encryption key, leading to an IKE authentication failure.

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

Router_A’s (Figure 4-3) RSA Key Configuration for IKE SA Establishment with Router_B

1

show c rypto key mypubkey r sa Router_A#s

2

% Key pair was generated at: 8:56:03 UTC Feb 17 2005

3

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

22

show c rypto key pubkey-cha in rsa add 20 0.0.0.2 Router_A#s

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

Common Configuration Issues with IPsec VPNs

153

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

Router_B’s (Figure 4-3) RSA Key Configuration for IKE SA Establishment with Router_A

1

show c rypto key m ypubkey r sa Router_B#s

2

% Key pair was generated at: 08:59:17 UTC Feb 17 2005

3

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 11 12

28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162 C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4 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

show c rypto key p ubkey-cha in rsa addr ess 200.0.0. 1 Router_B#s

24

25

Key address:

200.0.0.1

26

Usage: General Purpose Key

27

Source: Manually entered

28

Data:

29

307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00B86AD5 F0E1D956

30

E29630DC 64D5FAE8 F6FA9E74 3894D9B9 0DCA97AE 454F4937 063499B2 2B84C46E

31

7D5D2647 22D3AC56 DC9017DC 5D6938AD A57C4629 098C2DA3 8F16376A DDD145DA

32

70712AD0 EB07850F 5B96A6E2 7CCA8D60 3783E7D9 30EE2DD8 3B020301 0001

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

154

Chapter 4: Common IPsec VPN Issues

Troubleshooting IKE Authentication Failures with RSA Encryption

Example 4-13 1

debug crypto isa kmp Router_A#d

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 debug crypto isa kmp 19 Router_B#d 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

Common Configuration 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 fixed the mismatching key problem in Example 4-11 through Example 4-13, and have updated their IPsec configuration to peer with Router_A’s loopback address. However, they have not updated the address that ISAKMP should use when authenticating the IKE channel with Router_B’s public/encryption key (see configurations listed in Figure 4-4). Therefore, Router_B cannot select the appropriate public key to authenticate the IKE channel with Router_A. Once again, this leads to an IKE Authentication error, which eventually causes ISAKMP SA negotiation to time out. RSA Encryption and ISAKMP Peer Mismatches

Figure 4-4

Router_A Network_A 202.1.1.0/24

Router_B

.1

200.0.0.0/30 .2

Loopback 1 = 201.0.0.1

Network_B 202.2.2.0/24

Loopback 1 = 201.0.0. 2

Router_B has not been configured to use Router_A’s decryption key with the correct address, which is now its loopback 1 interface (201.0.0.1)

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

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

1

show c rypto key m ypubkey r sa Router_A#s

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

show c rypto key p ubkey-cha in rsa addr ess 200.0.0. 2 Router_A#s

21

Key address:

200.0.0.2

continues

156

Chapter 4: Common IPsec VPN Issues

Example 4-14

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

22

Usage: General Purpose Key

23

Source: Manually entered

24

Data:

25

30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 009F63BF

26

64DF17DF CD836EA2 FA556169 95A05572 FCF7F1E1 BA7DC493 18408EC0 F98B78BE

27

28FAE232 3132AF97 CE73D4B5 07F10A86 CFD038F3 FBC44FF2 2C323420 D1430162

28

C026DF34 DD6E4AB5 EA3BB45F 1F184393 DD4C0A3C C9DAD616 F876784B EC9A9AF4

29

5F2D692F 238F3B82 09C4AD90 2569E1B6 9AD98833 D6700467 A7880202 0D020301 0001

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

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

1

show c rypto key mypubkey r sa Router_B#s

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

show c rypto key pubkey-cha in rsa addr ess 200.0.0. 1 Router_B#s

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

Common Configuration Issues with IPsec VPNs

157

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

Example 4-16 1

sh run Router_B#s

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 10

4A6AB4F3 8ACFFE4D 6B409C93 6BB3DAE3 D7D13398 3C48C7A1 B5020301 0001 quit

11 ping 12 Router_B#p 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 201.0.0.1:500 Id: 201.0.0.1

.

Peer

show c rypto isakm p sa 20 Router_B#s 21 dst

src

state

22 201.0.0.1

200.1.1.2

QM_IDLE

conn-id slot 1

0

show c rypto key p ubkey-cha in rsa 23 Router_B#s 24 Codes: M - Manually configured, C - Extracted from certificate 25 26 Code Usage 27 M

General

IP-Address/VRF 201.0.0.1

Keyring

Name

default

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

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

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

Authenticating the CA and Obtaining the CA Certificate

■

Enrolling with the CA and Obtaining Public Key Certificates

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

Troubleshooting IKE Authentication Errors with RSA Signatures IOS_CAROOT 202.1.3.2/24

Network_C 202.1.3.0/24 Router_C Loopback 1 = 202.0.0.3

.3

Network_A 202.1.1.0/24

.1

Network_B 202.2.2.0/24

.2

DWDM Ring = 200.0.0.0/24 Router_A

Loopback 1 = 202.0.0.1 Loopback 192 = 192.168.1.1/24

Router_B Loopback 1 = 202.0.0.2 Loopback 192 = 192.168.2.1/24

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

Common Configuration Issues with IPsec VPNs

Example 4-17

159

RSA Signatures Configuration on Router_A (Figure 4-5)

show c rypto ca c ertificate s Router_A#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 show c rypto key mypubkey r sa Router_A#s % 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

160

Chapter 4: Common IPsec VPN Issues

Example 4-17

RSA Signatures Configuration on Router_A (Figure 4-5) (Continued)

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 show c rypto key pubkey-cha in rsa Router_A#s Codes: M - Manually configured, C - Extracted from certificate Code Usage C

IP-Address/VRF

Signing

Keyring

Name

default

X.500 DN name:

cn=IOS_CAROOT C

Signing

192.168.2.1/

default

Router_B.cisco.com

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

RSA Signatures Configuration on Router_B (Figure 4-5)

show c rypto ca c ertificate s Router_B#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

Common Configuration Issues with IPsec VPNs

Example 4-18

161

RSA Signatures Configuration on Router_B (Figure 4-5) (Continued)

Validity Date: start date: 09:06:11 UTC Feb 24 2005 end

date: 09:06:11 UTC Feb 24 2008

Associated Trustpoints: IOS_CAROOT show c rypto key mypubkey r sa Router_B#s % 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 show c rypto key pubkey-cha in rsa Router_B#s Codes: M - Manually configured, C - Extracted from certificate Code Usage C

IP-Address/VRF

Signing

Keyring

Name

default

X.500 DN name:

cn=IOS_CAROOT C

Signing

192.168.1.1

default

Router_A.cisco.com

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

162

Chapter 4: Common IPsec VPN Issues

enroll with the CA, RSA_CAROOT. Router_B’s clock is set incorrectly, which leads the router to believe that the CA certificate is outside of the appropriate period of validity. CA Authentication Failure Due to Inconsistent Clock Settings

Example 4-19

sh clo ck Router_B#s 09:55:30.262 UTC Wed Apr 26 2002 crypto pki authen ticate IO S_CAROOT Router_B(config)#c % Error in saving certificate: status = FAIL %CRYPTO_PKI: CA Cert not yet valid or is expired start date: 14:40:58 UTC Feb 17 2005 end

date: 14:40:58 UTC Feb 17 2008

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

Example 4-20 1

crypto pki authen ticate IO S_CAROOT Router_B(config)#c

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

debug crypto pki server IOS_CAROOT#d

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 show c rypto pki certifica tes 13 Router_B#s 14 CA Certificate 15

Status: Available

16

Certificate Serial Number: 01

17

Certificate Usage: Signature

18

Issuer:

19 20 21 22 23 24 25

cn=IOS_CAROOT Subject: cn=IOS_CAROOT Validity Date: start date: 14:40:58 UTC Feb 17 2005 end

date: 14:40:58 UTC Feb 17 2008

Associated Trustpoints: IOS_CAROOT

Common Configuration Issues with IPsec VPNs

163

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

Example 4-21

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

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

Example 4-22 1

debug crypto pki s erver IOS_CAROOT#d

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

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 verification methods described earlier in this chapter after peers can successfully authenticate and enroll to the PKI to ensure that the remaining mechanics of IKE SA negotiation have been successfully executed. It is equally important to inspect the certificates for validity after PKI authentication and enrollment, in order to avoid IKE authentication errors with RSA signatures. Once certificates have been received by each VPN endpoint, they should be checked for consistency. Consider once again the IKE authentication exchange between Router_A and Router_B in Figure 4-5. We can confirm the existence of signed certificates on both Router_A and Router_B, as illustrated in Example 4-23. Example 4-23

Verifying the Existence of Certificates on IOS PKI VPN Endpoints

show c rypto ca c ertificate s Router_A#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 show c rypto ca c ertificate s Router_B#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

Common Configuration Issues with IPsec VPNs

165

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

Verifying the Establishment of an ISAKMP SA Using RSA Signatures on Router_A

debug crypto isa kmp Router_A#d ! ! *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 show c rypto isak mp sa Router_A#s dst

src

state

200.0.0.2

200.0.0.1

QM_IDLE

conn-id slot 1

0

show c rypto engi ne connect ion s active Router_A#s ID Interface

IP-Address

State

Algorithm

Encrypt

Decrypt

1 FastEthernet0/0

200.0.0.1

set

HMAC_SHA+3DES_56_C

0

0

2000 FastEthernet0/0

200.0.0.1

set

HMAC_SHA+AES_CBC

0

2

2001 FastEthernet0/0

200.0.0.1

set

HMAC_SHA+AES_CBC

2

0

IPsec SA Proposal Mismatches Recall from our IPsec overview in Chapter 2 that the IPsec SAs cannot be established until there is an ISAKMP SA (unless manual keying is used). Up until this point, we’ve discussed common troubleshooting tactics for debugging Phase 1 negotiation errors. Now we will assume that an ISAKMP SA has been established and explore some common issues to troubleshoot in Phase 2 negotiation of the IPsec SA. In order for two peers to successfully negotiate an IPsec SA, they must agree on three things specific to Phase 2 negotiation: ■

The IP addresses used for IPsec tunnel termination

166

Chapter 4: Common IPsec VPN Issues

■

The symmetric IPsec transforms to use on crypto-protected traffic after an IPsec SA has been negotiated

■

The scope of protected traffic in the crypto switching path

NOTE Other items in the crypto path can be negotiated during Phase 2 negotiation even if they are mismatched. Such elements of the IPsec SA include the SA lifetime and perfect forward secrecy (PFS) group modulus.

Now that the routers in Figure 4-5 have been able to authenticate one another using RSA Signatures, and can establish an ISAKMP SA, we will insert an error in to the crypto map that prevents us from negotiating an IPsec SA. On Router_B, we will change the peering address to point to Router_C instead of Router_A. In Example 4-25, we will intentionally insert an incorrect peer on Router_B in order to illustrate peer mismatch diagnostic output on the IOS CLI in Example 4-26. Example 4-25

Inserting a Peering Error on Router_B

conf t Router_B#c Enter configuration commands, one per line.

End with CNTL/Z.

crypto map pki4 1 0 Router_B(config)#c set pe er 200.0.0.10 Router_B(config-crypto-map)#s end Router_B(config-crypto-map)#e Router_B#

As expected, Router_A and Router_B can establish an ISAKMP SA, but are unable to complete Phase 2 negotiation due to the peering inconsistency introduced in Example 4-25. We can confirm the inconsistency by debugging the Phase 2 negotiation process using the debug crypto IPsec command. Example 4-26 provides diagnostic output indicating a peering address inconsistency on Router_B causing the IPsec SA negotiation to fail. Example 4-26

Identifying IPsec Proposal Mismatch Issues

debug crypto IPs ec Router_A#d 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..... debug crypto IPs ec Router_B#d Router_B# Feb 24 11:52:30.627: IPSEC(key_engine): got a queue event with 1 kei messages

Common Configuration Issues with IPsec VPNs

Example 4-26

167

Identifying IPsec Proposal Mismatch Issues (Continued)

Feb 24 11:52:30.791: IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) INBOUND local= 200.0.0.2, remote= 200.0.0.1, local_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4), remote_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4), protocol= ESP, transform= esp-aes esp-sha-hmac

(Tunnel),

lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42 Feb 24 11:52:30.791: Crypto mapdb : proxy_match src addr

: 202.2.2.0

dst addr

: 202.1.1.0

protocol

: 0

src port

: 0

dst port

: 0

Feb 24 11:52:30.791: IPSEC(validate_transform_proposal): peer address 200.0.0.1 not found Feb 24 11:52:30.795: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at 200.0.0.1 Feb 24 11:53:00.315: IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) INBOUND local= 200.0.0.2, remote= 200.0.0.1, local_proxy= 202.2.2.0/255.255.255.0/0/0 (type=4), remote_proxy= 202.1.1.0/255.255.255.0/0/0 (type=4), protocol= ESP, transform= esp-aes esp-sha-hmac

(Tunnel),

lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x42 Feb 24 11:53:00.315: Crypto mapdb : proxy_match src addr

: 202.2.2.0

dst addr

: 202.1.1.0

protocol

: 0

src port

: 0

dst port

: 0

Feb 24 11:53:00.315: IPSEC(validate_transform_proposal): peer address 200.0.0.1 not found

Let us now insert another error that causes Phase 2 negotiation failure. In Example 4-27, we will remedy the peering issue introduced in Example 4-25 and diagnosed in Example 4-26. We will also reconfigure the crypto transform in transform set “pki4,” introducing a transform set mismatch with Router_A (Router_A uses esp-aes esp-sha-hmac for its transform). Example 4-27

Correcting the Peering Inconsistency in Example 4-15 and Example 4-16 and Creating a Mismatched IPsec Transform Set on Router_B

conf t Router_B#c Enter configuration commands, one per line.

End with CNTL/Z.

crypto map pki4 10 Router_B(config)#c no set peer 200.0.0. 3 Router_B(config-crypto-map)#n set pee r 200.0.0.1 Router_B(config-crypto-map)#s exi t Router_B(config-crypto-map)#e crypto IPsec trans form-se t pki4 esp-ae s esp-md5-hm ac Router_B(config)#c end Router_B(cfg-crypto-trans)#e Router_B#

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 negotiation—the negotiation of the IPsec SA. The routers in Figure 4-5 are now configured to use different transforms. Originally, Router_A and Router_B would use SHA1 Hash-based Message Authentication Code (HMAC) authentication in their transform sets. But, Router_B now uses the incorrect algorithm (MD-5 vs. SHA-1) to create the HMACs. As such, the routers are not able to agree on an IPsec proposal. As before, we will confirm this by debugging the IPsec crypto engine (debug crypto IPsec). The diagnostic output in Example 4-28 highlighted below confirms a mismatch in the IPsec transform causing a quick mode to fail to negotiate an IPsec SA. Example 4-28

Diagnosing IPsec Proposal Inconsistencies—Identifying 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

Common Configuration 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, cryptoprotected address spaces between VPN endpoints must be consistent for an IPsec SA to be established. These crypto-protected address spaces are defined with ACLs, commonly referred to as crypto ACLs. When crypto ACLs specify inconsistent scopes of addresses between two peers, the expected result is that ISAKMP SA negotiation will complete successfully, but IPsec SA negotiation will fail. We will now walk through several examples of acceptable and unacceptable crypto ACL definition, and then explore some methods for diagnosing crypto ACL definition problems using Cisco IOS IPsec debugging capabilities. NOTE The protected address and port ranges specified in crypto ACLs are commonly shown as “proxies” in the crypto debugging output in Cisco IOS and ASA IPsec VPN endpoints.

The first case we will discuss demonstrates a crypto ACL definition that will facilitate successful IPsec SA negotiation. However, the next three examples of crypto ACLs present inconsistencies in crypto-protected address spaces that will cause Phase 2 SA proposals to be rejected. Configurations illustrating a valid crypto ACL match for Router_A and Router_B are provided in Example 4-29. NOTE The crypto ACL’s described in Cases 2 through 4 below will not preclude Phase 2 SA negotiation when TEDv3 is used. Although the ACL’s are inconsistent, TEDv3 probes will dynamically discover consistent crypto-protected scopes and install the appropriate information in the IPsec SADB. The use of TED is discussed in greater detail in Chapter 12, “Solutions for Handling Dynamically Addressed Peers.”

Example 4-29

Crypto ACL Match

show a ccess-list 101 Router_A#s 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# show a ccess-list 101 Router_B#s Extended IP access list 101 10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 Router_B#

In Example 4-30, Router_B has an extra access-list entry (ACE) in the crypto ACL (ACE #20). However, ACE 10 is consistent between routers A and B. As such, traffic matching ACE 10 will facilitate successful Phase1 and 2 SA negotiations. Traffic matching ACE 20 on Router-B will

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_B’s ACE 20 in crypto ACL 101. The traffic matching ACE 20 will subsequently be dropped. Example 4-30 provides the configurations on Router_A and Router_B illustrating the missing crypto ACE on Router_A. Example 4-30

Crypto ACL Mismatch Due to Missing ACE on Router_A

sh acc ess-list 1 01 Router_A#s 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# sh acc ess-list 1 01 Router_B#s Extended IP access list 101 10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 20 permit ip 192.168.2.0 0.0.0.255 202.1.3.0 0.0.0.255 Router_B#

Example 4-31 provides a configuration in which the crypto ACLs on both Router_A and Router_B define scopes of protected address spaces that are inconsistent with the opposite peer’s scope of protected source addresses. For example, Router_A protects traffic destined for any IP address that is sourced from 192.168.1.0/24. What would occur if traffic was sent from 192.168.1.1 to Router_A’s physical IP address, 200.0.0.2? Router_A would encrypt the traffic as it matches ACE 10 in ACL 101. Router_B, however, would not encrypt the return traffic, as traffic sourced from 200.0.0.2 is not defined anywhere in its crypto ACL. For this reason, Phase 2 SA negotiation will fail when such an inconsistency is defined in the crypto ACL’s of two IPsec peers. Example 4-31

Crypto ACL Mismatch Due to Inconsistent Destination Address Ranges

show a ccess-list 101 Router_A#s Extended IP access list 101 10 permit ip 192.168.1.0 0.0.0.255 any Router_A# show a ccess-list 101 Router_B#s Extended IP access list 101 10 permit ip 192.168.2.0 0.0.0.255 any Router_B#

In the case provided in Example 4-32, the ACL defines a tighter scope of address space on Router_B’s crypto ACL. As such, if Router_B initiates the Phase 2 exchange, then an IPsec SA will be established successfully in the SADB, and traffic will pass. However, if Router_A initiates the Phase 2 exchange, the IPsec SA proposal will be rejected by Router_B for the same reasons discussed in Example 4-31.

Architectural and Design Issues with IPsec VPNs

Example 4-32

171

Crypto ACL Mismatch Due to Inconsistent Destination Address Scope on Router_B

sh acc ess-list 1 01 Router_A#s Extended IP access list 101 10 permit ip 192.168.1.0 0.0.0.255 any (24 matches) Router_A# sh acc ess-list 1 01 Router_B#s Extended IP access list 101 10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 Router_B#

Architectural and Design Issues with IPsec VPNs Aside from issues related to configuring ISAKMP and IPsec policy, there is a variety of network elements that can interfere with optimal operation of an IPsec VPN if it is not managed correctly. In this section, we will discuss several of the most common troubleshooting challenges present IPsec VPN implementations today face. We will also discuss several effective techniques for diagnosing the problems that can result from improper design, and the appropriate solutions to remediate those problems.

Troubleshooting IPsec VPNs in Firewalled Environments As we’ve discussed in our overview of the IPsec protocol in Chapter 2, many items need to be passed between two VPN endpoints in order to dynamically create tunnels securely using IKE and to successfully pass IPsec packets once a Phase 2 SA has been established. Most firewalls, by default, employ a “closed” model of security (by default, nothing is allowed) in which the firewall must be explicitly instructed to allow the required protocols through by an administrator. When deploying IPsec in firewalled environments, care must be taken to allow the required elements to securely pass, or problems could arise with VPN operation and performance. We will discuss two common issues in firewalled VPN environments—firewall fragmentation handling, filtering of required IPsec protocols, and filtering of Internet Control Message Protocol (ICMP) unreachables. Allowing the Required IPsec Protocols to Pass It is very common to see IPsec VPN sessions that traverse firewalls. One such example that we’ve discussed in Chapter 2 is in a DMZ design. Another popular application for such a design is in secure extranet designs. Most firewalls available in today’s marketplace employ a closed policy by default, allowing no traffic to pass from low-security interfaces to interfaces assigned higher security levels. This includes protocols necessary for IPsec and IKE to operate effectively. Unless manual IPsec session keys are used, firewalls between IPsec peers must allow ISAKMP traffic (UDP port 500) to pass between the IPsec VPN endpoints. Additionally, IPsec traffic must be allowed through the firewall, or encrypted traffic will get blocked at the firewall outside

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. NOTE Although IPsec transforms can include the ESP protocol, AH protocol, or both ESP and AH protocols together, it may not be necessary to open up firewall configurations to allow them both. Figure 4-6 assumes that all Remote Nets use ESP and AH. Administrators should verify the protocol selected in their IPsec transforms, as it may not be necessary to allow both ESP and AH through the firewall.

Figure 4-6 illustrates a firewalled IPsec VPN tunnel deployment in which tunnels are built from a central, firewalled aggregation site out to smaller remote locations. Figure 4-6

IPsec VPN Traffic Through Firewalls Allowing ISAKMP messages through the firewall allows SAs to be built successfully and allows encrypted traffic flows through the corresponding IPsec tunnels.

30

.0/

.0 0.1

16

.2

.6

Enterprise 10.0.0.0/8

.1

Remote_Net_A 192.168.1.0/24

160.1.4.0/30

Remote_Net_B 192.168.2.0/24

201.1.1.0/28

Firewall blocks ISAKMP (UDP 500), ESP (IP 50), and AH (IP 51) by default.

.10

160

.1.8

.0/3

0

Remote_Net_C 192.168.2.0/24

IPsec Tunnels

Example 4-33 provides the firewall ACL configuration that is employed to enable IPsec tunnels to be built between the Campus_Net and Remote_Nets A, B, and C in Figure 4-6. Example 4-33

Firewall Configuration for Crypto Traffic in Figure 4-6

DMZ-PIX-MAIN(config)# show access-list 101 access-list 101; 9 elements access-list 101 line 1 permit udp host 160.1.0.2 host 201.1.1.1 eq isakmp access-list 101 line 2 permit udp host 160.1.0.2 eq isakmp host 201.1.1.1 access-list 101 line 3 permit esp host 160.1.0.2 host 201.1.1.1 access-list 101 line 3 permit ah host 160.1.0.2 host 201.1.1.1 access-list 101 line 4 permit udp host 160.1.0.6 host 201.1.1.1 eq isakmp access-list 101 line 5 permit udp host 160.1.0.6 eq isakmp host 201.1.1.1 access-list 101 line 6 permit esp host 160.1.0.6 host 201.1.1.1 access-list 101 line 3 permit ah host 160.1.0.2 host 201.1.1.1 access-list 101 line 7 permit udp host 160.1.0.10 host 201.1.1.1 eq isakmp access-list 101 line 8 permit udp host 160.1.0.10 eq isakmp host 201.1.1.1

Architectural and Design Issues with IPsec VPNs

Example 4-33

173

Firewall Configuration for Crypto Traffic in Figure 4-6 (Continued)

access-list 101 line 9 permit esp host 160.1.0.10 host 201.1.1.1 access-list 101 line 3 permit ah host 160.1.0.2 host 201.1.1.1 DMZ-PIX-MAIN(config)# show access-group access-group 101 in interface outside

Firewall’s Handling of Fragmented IPsec Packets In addition to ensuring that the appropriate protocols are allowed to communicate through the firewall, it is critical that network designers should also account for the design considerations presented by the way that firewalls handle fragmented packets. When an IPsec packet is fragmented, the information relevant to the firewall’s filtering decision, such as data found in the Layer 3 and 4 headers, is obscured in noninitial fragments. NOTE All fragments of a fragmented IPsec packet must be decrypted before they can be reassembled. This behavior can bypass the crypto hardware switching path, leading to performance degradation in IPsec networks. It is therefore critical to account for fragmentation issues in IPsec designs. We will discuss IPsec MTU and fragmentation issues and available solutions for fragment handling in IPsec networks (virtual fragmentation reassembly, IPsec prefragmentation, and path MTU discovery) later in this chapter.

As such, the firewall will potentially allow fragments to pass without inspection, as shown in Figure 4-7. Figure 4-7

Firewall Fragment Handling in IPsec Networks IPsec Tunnel Intermediate Router, ISP_GW_B, fragments encrypted traffic between ISP_GW_A and ENT_DMZ_IN

ENT_DMZ_IN

ENT_FW

ENT_GW

ISP_GW_A

ISP_GW_B

ISP_Net MTU = 1500

MTU = 1500

MTU = 512

MTU = 4470

Outer IP Encrypted Fragment Header Payload #1

Outer IP ESP Encrypted ESP Header Header Payload Auth

Outer IP Encrypted Fragment Header Payload #2 Outer IP Encrypted Fragment Header Payload #3

Firewall cannot decrypt fragments to perform reassembly. Virtual Fragmentation Reassembly allows fragment inspection without reassembly.

… Outer IP Header

Last Encrypted Fragment Payload

174

Chapter 4: Common IPsec VPN Issues

Cisco PIX firewalls by default are configured to detect when a fragmented packet has been received and to make filtering decisions on the initial fragment and all noninitial fragments without actually reassembling the packet. This feature is called Virtual Fragment Reassembly. Virtual Fragmentation Reassembly provides the firewall with the ability to make filtering decisions on fragments without having to decrypt each packet in the fragmented chain. Virtual Fragmentation Reassembly does indeed consume computational resources on the firewall, but does provide an ideal solution when filtering decisions must be made on noninitial IPsec packet fragments. Figure 4-7 demonstrates the improved handling of fragmented packets in IPsec networks. In the case illustrated in Figure 4-7 above, packets are being fragmented at an intermediary point between the two IPsec VPN gateways, ISP_GW_A and ENT_DMZ_IN. The DMZ firewall, ENT_FW, receives the fragments, and is configured for virtual fragmentation reassembly. The firewall therefore does not do any reassembly. Instead, it will initially allow only the first fragment in the fragment chain through without being inspected. Virtual Fragment Reassembly enables the firewall to inspect the remaining fragments of the original packet without reassembling the packet. Virtual Fragmentation Reassembly therefore plays a vital role in this example, as the firewall would have to decrypt each fragment in the chain in order to reassemble the packet, which it is not configured to do. Filtering of ICMP Unreachables ICMP unreachables are commonly used by hackers to find and exploit network vulnerabilities, and are a fundamental component of scanning techniques used to find openings in firewalled environments. As such, it is very common that firewalls not reply to filtered messages with ICMP unreachables. This behavior breaks a fundamental tool that IPsec can use to avoid the performance problems that can arise from fragmenting packets after encryption—Path MTU Detection (PMTUD). As discussed in greater detail later in this chapter, PMTUD sends ICMP messages along the path, relying on information in ICMP unreachable messages to throttle down the MTU that the PMTUD device must fragment to before encrypting with IPsec. The insertion of a firewall along the PMTUD path effectively breaks this model, because it will suppress the response of the ICMP unreachable that is to carry MTU sizing information back to the fragmenting PMTUD device.

NAT Issues in IPsec VPN Designs NAT was introduced to solve problems with the depletion of publicly available address space. It does this by translating the private source or destination IP addresses into public ones. As we had discussed previously in Chapter 2, “IPsec Fundamentals,” IPsec was designed, in part, to prevent the manipulation of data while in transit between the two endpoints of the IPsec VPN tunnel. Considering that IPsec in tunnel mode protects the IP header from manipulation, incompatibilities

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, specifically the source and destination addresses or ports, when the packet is en route from a given source to a given destination. The nature of IPsec is to detect and prevent the malicious manipulation of packets between a given source and destination. Therein lies the origin of IPsec/NAT incompatibilities—the nature of NAT is to manipulate a packet, while the nature of IPsec is to preserve the packet’s integrity. Recall from our discussion in Chapter 2 that IPsec defines a suite of protocols, such as AH and ESP, that can operate in different modes, such as tunnel or transport, and include varying degrees of authentication, or strengths in optional HMACs within a given transform. Because each protocol protects different portions of the IP packet in different ways, the effect of NAT can vary on a per-protocol basis. Some of the protocol-specific examples of inherent IPsec/NAT incompatibility include: ■

IPsec AH Keyed Message Integrity Check (MIC) Failures in NAT Environments

■

Inbound IPsec SA Selector Inconsistencies in NAT Environments

■

IKE Rekeying Failures in PAT Environments

■

Overlapping IPsec Security Policy Database Entries

■

IPsec Security Parameter Index Conflicts on NAT Devices

■

Embedded IP Address Translation Limitations

■

Unidirectional NAT Support

■

TCP and User Datagram Protocol (UDP) Checksum Failures

IPsec AH Keyed MIC Failures in NAT Environments Authentication Header protocol includes source and destination addresses in the keyed MIC in order to provide a greater scope of authentication and integrity than the ESP protocol. Manipulating the source/destination address of the packet between VPN endpoints using AH will cause a MIC failure at the receiving VPN endpoint. ESP does not have this specific incompatibility, as source and destination information is not included in the integrity check.

176

Chapter 4: Common IPsec VPN Issues

Inbound IPsec SA Selector Inconsistencies in NAT Environments If IKE authenticates Phase 2 selectors, and the initiator’s source address is translated en route to the responder, then RFC 2401 requires that the responder drop the decapsulated packet, as the translated IP address does not match the SA selector value. IKE Rekeying Failures in PAT Environments An IKE responder must respond to IKE requests on the correct port. In nonPAT environments, this is UDP 500 by default. However, in situations in which IKE initiators have their ports translated to something other than 500, the IKE responder must be able to respond to the IKE request on the translated port, and must be able to do so predictably and reliably for IKE rekey messages to reach their correct destinations (correct IKE initiators). Overlapping IPsec Security Policy Database Entries When two or more IPsec initiators use their source address as its Phase 2 identifiers, an IPsec responder could view the two sources as identical. The responder could, therefore, potentially install overlapping security policy database entries for multiple sources. As a result, the responder is at risk of forwarding traffic over the incorrect SAs to its sources. The creation of overlapping security policy database entries in an IPsec responder resulting from duplicate NAT inside local addresses used as Phase 2 SA identifiers is illustrated in Figure 4-8. Figure 4-8

SPD Confusion in NAT Environments NAT 10.1.1.1

170.1.1.100

10.1.1.1 170.1.1.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.

WAN 200.1.0.0/216

170.1.2.0/24 10.1.1.1

10.1.1.1

170.1.2.100 NAT

Security policy database (SPD) conflict for IPsec initiators with the identity of “10.1.1.1”

Architectural and Design Issues with IPsec VPNs

177

IPsec Security Parameter Index Conflicts on NAT Devices When two initiators attempt to negotiate a Phase 2 SA with the same destination, and Security Parameter Index (SPI)-based NAT is occurring between source and destination, SPI conflicts can sometimes occur on that NAT device leading to forwarding confusion from responder to initiator. Consider the scenario in Figure 4-9. The responder will install two different SPI entries (i.e., 2001 and 2002). However, because inbound and outbound SPI creation occurs independently of one another, the two initiators could indeed install similar SPI entries (i.e., both would claim to have installed SPI 2000 for the same destination). Because traffic from both Router_A and Router_B use the same UDP source port information, the NAT devices use overlapping SPIs for forwarding decisions. As a result, the traffic from the responder could be forwarded to the incorrect initiator due to the SPI conflict in the NAT device (i.e., the NAT device does not know which initiator to forward SPI 2000 traffic to). Figure 4-9

SPI Overlap in NAT Device 10.1.1.1

Router_A

Routers A and B simultaneously initiate IPsec VPN tunnels the concentrator, choosing identical SPIs (2000). NAT

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).

WAN 200.1.0.0/216 170.1.1.0/24

200.0.0.0/24

200.0.0.1

200.0.0.100

Translation Table: 10.1.1.1, SPI 2000 -> 170.1.1.1 10.1.1.2, SPI 2000 -> 170.1.1.2

Router_B 10.1.1.2

Embedded IP Address Translation Limitations Some applications have addressing information embedded in to the payload of the IP packet. In both ESP and AH protocols, the payload of the packet is integrity protected. Therefore, changes to that payload, such as those NAT would attempt to execute, are not possible within the ESP and AH encapsulated payloads. Unidirectional NAT Support In some cases, a NAT device will install an NAT/PAT entry only once a packet is received from a given interface (i.e., inside to outside). Once that entry is installed on the NAT device, traffic can be forwarded in both directions. However, until that entry is installed, traffic received in other directions (i.e., outside to inside) will not get forwarded, as a NAT/PAT entry will not be dynamically created for traffic received on that interface.

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 verified. This specific incompatibility does not affect IPsec in tunnel mode or IPsec+GRE, as neither of these methods requires validation of UDP/TCP checksums that use a translated source and destination IP address in their calculations. IPsec NAT Transparency (NAT-T) IPsec NAT-T enables an IPsec VPN endpoint to dynamically detect the support for NAT-T on its remote endpoint and to detect the presence of NAT devices between the two endpoints. If NAT is detected through the use of NAT-T, then the two endpoints will dynamically agree on the appropriate handling of IPsec NAT-T packets (such as UDP encapsulation of ESP packets, and so on). NAT-T, therefore, enables the two VPN endpoints to seamlessly establish an IPsec VPN endpoint across one or more NAT points that may exist between the two endpoints. Consider the example described in Figure 4-10 in which two routers, Router_A and Router_B, communicate with one another through a firewall, Ent_FW. Figure 4-10

The Operation of IPsec NAT-T 10.0.0.0/24

201.1.0.0/24 10.0.0.1

201.1.0.200 NAT

1

Router_A Initiates Phase 1 Negotiation with Router_B. Vendor ID string sent. (MM1) Router_B responds with its Vendor ID string, confirming that it supports NAT - T (MM2).

2

3

NAT-Detect message exchanged and verified (hashes of saddr, daddr, sport, and dport) in MM3 and MM4.

3

4

Routers Negotiate NAT - T information in SA establishment if step 3 detects NAT. (QM1 and QM2)

4

5

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

Routers A and B are both capable of NAT-T, and dynamically agree on the handling of IPsec packets across the NAT’d path through the following sequence of exchanges: 1.

Router_A sends its vendor ID to Router_B during IKE Phase 1 negotiation. This phase of NAT-T is commonly referred to as a “NAT Support” exchange.

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 verified at the remote end. If the hash values match, then it can safely be determined that NAT does not exist. If the hash values do not match, then it can safely be determined that NAT does exist.

4.

After NAT-D payloads are exchanged to detect NAT information, IPsec Quick Mode messages are exchanged to decide which peer (none, either, or both) will use NAT-T. This negotiation is performed during IKE Phase 2 in Quick Mode (QM1 and QM2).

5.

In Figure 4-10, inside source address translation is being performed by the PIX. IPsec endpoints have determined this behavior using NAT-T steps 1-4 described above. In this case, Routers A and B will both encapsulate ESP packets in UDP, hereby remedying three incompatibilities with IPsec and NAT: — Incompatibility between ESP and AH with PAT — Incompatibility between IKE fixed ports and PAT — Incompatibility between UDP checksums and NAT (intermediate NAT-T UDP header checksum set to 0)

NOTE As noted above, Cisco IOS will attempt NAT-T during IKE Phase 1 negotiation. Cisco IOS configures NAT-T automatically, and there is no manual configuration required. To disable the encapsulation of ESP packets in UDP using NAT-T, execute the following command from the IOS CLI: Router_A(config)#no crypto IPsec nat-transparency udp-encapsulation

SPI-Based NAT IPsec SPIs provide another element that a NAT device can use to forward data between two endpoints. When IPsec traffic is passed through a NAT device, various crypto-protected elements are often translated by NAT, including source IP addresses, destination IP addresses, source ports, and destination ports. Another field that can be use to populate the translation table in a NAT device is the IPsec SPI. As we had discussed previously, though, IPsec and NAT incompatibilities arise when overlapping IPsec tunnels with overlapping SPIs are passed through the NAT device.

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. NOTE Additional configuration information on IPsec and SPI-based NAT can be obtained at the following link with a valid CCO account:

The Influence of IPsec on Traffic Flows Requiring QoS As networking technologies begin to mature and become more widespread, time- and delaysensitive applications are increasingly migrating toward a converged solution. Many of these applications are considered critical to the needs of businesses in different vertical markets. As such, a need for guaranteed timely delivery and ordering of these applications emerges. In today’s networked environment, a variety of QoS mechanisms exist to guarantee the timely delivery of delay-sensitive business critical data communications in IP networks. QoS in and of itself is so broad and deep in scope that we cannot cover it in its entirety. We will, however, discuss several common inconsistencies between IPsec and QoS that present design challenges: ■

Traffic Flow Hash Ubiquification: Flow-based QoS techniques, such as Weighted-Fair queuing (WFQ) rely on the original source and destination IP addresses of the packet to hash traffic flows in to “conversations.” Certain IPsec protocols and modes effectively ubiquify the information needed to perform this hashing decision—the source and destination IP address. Consider the example of IPsec ESP in Tunnel mode. In this example, the inner IP header will be encapsulated within the ESP boundary and encrypted. Therefore, if the router wants to use WFQ to hash this traffic flow into a conversation, it will not be able to, as it will be unable to read the encrypted original source and destination IP address. Because most VPN endpoints supporting QoS rely on flow-based QoS techniques such as WFQ and Low-Latency Queueing/class-based weighted fair queueing (LLQ)/(CBWFQ), it is critical that the IPsec VPN endpoint have the capacity to classify traffic flows before IPsec or generic routing encapsulation (GRE) encapsulation or both. Cisco IOS offers this functionality with the IPsec Preclassify feature.

■

Packet Reordering and the IPsec Antireplay Window: If packets are received outside of the antireplay window in an IPsec VPN, they will be dropped. The nature of QoS is to reorder packets, which can sometimes result in delay of queued traffic. It is critical to ensure that

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 traffic flows locally on a network device. LLQ/CBWFQ requires that packets within a traffic flow be identified in some way. This is typically achieved by marking the packet by setting the DiffServ bits in the IP header. Network devices are therefore able to differentiate that traffic from other traffic flows and treat it (queue it) with the appropriate level of urgency. The scope of effect of LLQ/CBWFQ decisions is contained to the local device only.

■

Resource Reservation Protocol (RSVP): RSVP uses an exchange of RSVP signaling messages between two endpoints to reserve resources for delay-sensitive traffic between the two endpoints. Unlike LLQ/CBWFQ, where LLQ/CBWFQ classification and queuing decisions are local in scope, the scope of RSVP queueing decisions is end-to-end. Although RSVP can be configured to work in tandem with DiffServ-based QoS, it can also be configured to place traffic in the RSVP-reserved queue regardless of what type of DiffServ policy is configured on that specific network node.

TIP For more detailed information on LLQ/CBWFQ and DiffServ, visit CCO at the following URLs: DiffServ—The Scalable End-to-End QoS Model http://www.cisco.com/en/US/partner/tech/ tk543/tk766/technologies_white_paper09186a00800a3e2f.shtml Implementing DiffServ for End-to-End Quality of Service http://www.cisco.com/en/US/ partner/products/sw/iosswrel/ps1834/products_feature_guide09186a0080080466.html

As mentioned previously, QoS requires the use of end-to-end messaging techniques and the interpretation of certain bit values within the IP header. In some cases, if care is not taken during an IPsec/QoS deployment, IPsec can obfuscate the necessary messaging and IP header bits needed to deliver QoS. We will discuss QoS within this context, and explore some available techniques for delivering QoS within an IPsec VPN deployment. IPsec’s Influence on DiffServ and LLQ/CBWFQ In this section, we will explore a Voice over IP (VoIP) deployment in a branch networking scenario. VoIP is delay-sensitive—that 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

182

Chapter 4: Common IPsec VPN Issues

occurs (other packets are dropped instead). For these reasons, QoS must be used for IP traffic over the Frame-Relay links. Figure 4-11

IPsec and DiffServ in a VoIP implementation 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).

Phone_A

DiffServ bits in the IP header are used to make the appropriate QoS classifications when executing on queuing decisions.

IP

IP

Router_A

IP

Router_B

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.

IP

IPsec VPN Tunnel VoIP RTP Stream

IP Phone_B

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.

DiffServ is implemented in conjunction with LLQ/CBWFQ to deliver QoS for voice traffic to and from the branches. Because the company’s security policy mandates confidentiality for voice traffic, IPsec VPNs have been configured between the enterprise headend router and all branch routers, posing several design considerations with the IPsec/DiffServ requirements: ■

If AH is used, changes to the IP header are not permitted (the AH MIC invalidates them on the receiving VPN endpoint). This prevents remarking on network devices between the phones. Therefore, RTP traffic must be marked accordingly prior to IPsec encapsulation (either on the routers or phones) if AH is used.

■

In both AH and ESP, if packets are received outside the antireplay window, they are dropped. Therefore, if traffic is delayed in queue due to QoS decisions, it could get dropped if it is received outside of the antireplay window at the opposite end of the IPsec VPN tunnel.

■

With ESP, the original IP header and QoS information is encapsulated in ESP and encrypted with the appropriate transform. This effectively renders the DiffServ bits needed for QoS unreadable by intermediate network nodes between the two IPsec VPN endpoints. Unless these bits are successfully copied to the outer IP header ESP encapsulation, network nodes between the two IPsec VPN endpoints may not appropriately classify the IPsec-processed RTP packet.

Architectural and Design Issues with IPsec VPNs

183

IPsec’s Effect on IntServ and RSVP In addition to issues outlined with the DiffServ and LLQ/CBWFQ, RSVP implementations with IPsec VPNs provide further design issues to address. As we had mentioned previously, RSVP provides a signaling method to proactively provision resources between a given source and destination. RSVP does so by exchanging a series of RSVP PATH and RSVP RESV messages between the source and destination. If intermediate network nodes between the RSVP source and destination are unable to decipher the RSVP RESV messages, as would be the case if they were encrypted in an IPsec VPN, intermediate network nodes cannot use the RSVP-RESV messages to dynamically reserve resources between source and destination (illustrated in Figure 4-12). Figure 4-12

IPsec and RSVP Signaling Incompatibility 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.

Phone_A IP

IP

IP

Router_A

Router_B

IP

IP

IP

IP

IP

IP

IP Phone_B

IPsec VPN Tunnel VoIP RTP Stream

Therefore, to dynamically provision resources on intermediate nodes between a source and destination that require timely, ordered delivery of IP-based application traffic, RSVP signaling messages must be forwarded outside of the crypto path.

Solving Fragmentation Issues in IPsec VPNs In IPsec VPN environments, it is critical to address MTU and fragmentation issues. Otherwise, the entire VPN is at risk of performance and operation issues. We will discuss the effect of fragmentation reassembly and MTU issues in this section, and provide solutions for proper IPsec design in environments in which MTU is likely to be exceeded, resulting in fragmentation. The effect of fragment handling between encryption devices is largely focused on the encryption device that is performing the reassembly of the fragmented packet. Although most network devices and VPN endpoints available today can fragment encrypted packets in the crypto-switched fast path, the decrypting IPsec endpoint must decrypt all fragments in the chain before the packet

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 MTU = 1500

MTU = 1500

MTU = 1400

MTU = 1500

IPsec Tunnel (ESP in Tunnel Mode)

IP

IP

IP

Router_A

Router_C

IP

Router_B

IP

IP

IP Server_B 1500-bytes Host_A

ESP Encap 1500 + 52

Original IP Packet

Original IP Packet

1500-bytes

1400-bytes Fragment

Fragment

Fragment 2 + IP Header

Reassemble

Packet reassembly prior to decryption is executed at the process level on the decrypting endpoint, resulting in material degradation in crypto switching performance.

120-bytes Fragment 1 + IP Header 72-bytes

Fragment 1 + IP Header 72-bytes Decrypt 1500-bytes

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.

Architectural and Design Issues with IPsec VPNs

Figure 4-14

185

PMTUD and IPsec MTU = 1500

MTU = 1414

MTU = 512

MTU = 1500

IP

IP

IP

Router_A

Router_C

IP

Router_B

IP

IP

IP 1

2

ICMP (1500-bytes)

DF Set?

Host_A

Server_B

Length < 1414 MTU? 3 ICMP Unreachable (Use MTU = 1414)

Drop

4 ICMP (1414-bytes)

DF Set? 5 Length < 1414 MTU?

ICMP (1414-bytes) 6 ICMP Unreachable (Use MTU = 512)

7 ICMP (512-bytes)

DF Set? Length < 512 MTU?

Drop

DF Set? Length < 1414 MTU?

ICMP (512-bytes)

DF Set? Length < 512 MTU?

ICMP (512-bytes)

DF Set? Length < 1500 MTU?

ICMP (512-bytes) 8 ICMP Echo Reply

Administrators have enabled IP PMTUD on their workstations and servers such that fragmentation reassembly issues can be avoided on Router_B. Host_A executes PMTUD using the following process: 1.

Host_A creates an IP packet sized to the appropriate MTU of its locally attached segment and sets the DF bit before transmitting it to Server_B.

2.

Router_A receives the packet, notes that the DF bit is set. Router_A’s serial link has an MTU of 1414. Because the DF bit is set and the packet from Host_A to Server_B exceeds the MTU of the serial interface, it is dropped.

3.

Router_A sends an ICMP Unreachable message back to Host_A, carrying the MTU (1414) of the next hop (the serial interface between Router_A and C).

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_C’s link to Router_B (512), the packet is dropped.

6.

Router_C sends an ICMP Unreachable message back to Host_A, carrying the MTU (512) of the next hop (serial interface between Router_C and A).

7.

Host_A sends another ICMP message of 512 bytes in length to Server_B with the DF bit set.

8.

The 512 byte ICMP message is lower than the MTU of any individual link in the path. It is therefore successfully forwarded to Server_B. Server_B sends an ICMP Echo Response back to Host_A, indicating to Host_A that 512 is the MTU of the path.

NOTE The routers in the above scenario are used to illustrate the general operation of PMTUD. IPsec and IPsec+GRE tunnels use a slightly different configuration of PMTUD than the previous, known as “Tunnel Path MTU Discovery.” The specific operation of fragment handling using PMTUD in IPsec and IPsec+GRE environments is discussed in greater detail later in this chapter.

IPsec in Cisco IOS can be configured to copy the DF bit value in to the outer IP header in ESPprocessed packets. As such, the ICMP traffic that PMTUD relies on to operate correctly does not have to be explicitly excluded from the crypto switching path. There are several issues that must be addressed if PMTUD is to be part of one’s design strategy to mitigate fragmentation reassembly issues in IPsec VPNs. In this section, we will briefly highlight some of the most common ones: ■

Permitting ICMP Unreachable Messages

■

Rate-Limiting ICMP Messages

■

PMTUD Not Supported on End-Hosts

■

Adjusting TCP Maximum Segment Size

■

Clearing the DF-Bit

Permitting ICMP Unreachable Messages As we’ve discussed previously in our overview of the PMTUD protocol, PMTUD relies heavily on ICMP unreachable messages to communicate the MTU of segments back to the fragmenting host. It is very common for security devices, such as firewalls, to deny ICMP unreachable

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 defined to avoid fragmentation reassembly issues. Adjusting TCP Maximum Segment Size Hosts sending IP packets greater than the TCP Maximum Segment Size (MSS) are at risk of fragmentation. Strictly speaking, the TCP MSS is the maximum amount of data that a host is willing to accept in an IP datagram. Hosts compare TCP MSS buffers sizes with MTU to determine the MTU for their transmissions. The result will be the lower of the TCP MSS or the MTU less 40 bits (an allocation for IP header and TCP header, both 20 bits in length). Once determined, each host communicates the selected values to the opposite host via the following exchange described in Figure 4-15.

188

Chapter 4: Common IPsec VPN Issues

Figure 4-15

TCP MSS, IP MTU, and Fragmentation MTU = 1500

MTU = 2048

IP

IP

Router_A

Router_C

IP

Router_B

IP

IP

IP

MSS Buffer = 20k

IP

MSS Buffer = 16k

1 Server_B

Host_A 2 3 4

The following order of events describes the sequence illustrated in Figure 4-15 above: 1.

Host_A has an MSS buffer of 20k and an MTU of 1500. It compares the MSS buffer with the MTU of the link, less a 40-bit allocation for IP and TCP header addition (1500 – 40 = 1460) and selects the lower value of 1460 (1460 < 20000) to send to Host_B.

2.

Host_B has a 16k MSS buffer and a 2048 interface MTU size. It does a similar comparison to Host_A’s in step 1 and selects 2008 (2048 – 40). It then compares the received value from Host_A and selects the lower value of 1460 as its MSS value (1460 < 2008).

3.

Host_B signals its MSS of 2008 to Host_A.

4.

Host_A compares the received value of 2008 with its TCP MSS value derived in Step 1 and selects the lower of the two values, 1460, as its TCP MSS.

TCP MSS values use MTU values to help avoid fragmentation. In the example above, MTU values are selected, as they are smaller than TCP MSS values. However, if the MSS value were to be smaller than the MTU, then Hosts A and B will select the MSS + 40 bytes as the maximum packet length for TCP traffic. Note that, in this case, the larger MTU value would still be used for UDP traffic. Clearing the DF-Bit If the DF bit is cleared somewhere along the PMTUD path between source and destination, the network nodes along the path will fragment the ICMP PMTUD message rather than dropping it and replying with an ICMP unreachable. This will obviously break the operation of PMTUD. Most IP-enabled devices available today are capable of clearing the DF bit in an IP header.

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 specifics of fragment handling and PMTUD differ slightly from nonVPN environments. In this section, we will discuss the handling of fragments in IPsec and IPsec+GRE tunnels and some additional solutions available for avoiding fragmentation in IPsec VPN environments. IPsec VPNs use Tunnel Path MTU Discovery to interpret MTU information of ICMP Unreachable messages and update the Path MTU of the corresponding IPsec SA. The typical PMTUD operation and fragment handling of an IPsec VPN is illustrated in Figure 4-16. Figure 4-16

Fragment Handling and PMTUD Operation with IPsec Tunnels MTU = 1500

MTU = 1500

MTU = 1400

MTU = 1500

ESP

IP

IP

Router_A

IP

Router_C

IP

Router_B

IP

IP

IP Server_B

ESP Encap ICMP (1500-bytes)

1500 + 58 DF Set?

Host_A

Length < 1500 MTU?

ICMP Unreachable (Use MTU = 1442)

Drop ESP Encap

ICMP (1442-bytes)

1442 + 58

ICMP (1500-bytes)

DF Set? Length < 1400 MTU?

Update SA PMTU Timeout and Retransmit

ESP Encap

ICMP (1442-bytes)

1442 + 58

ICMP Unreachable (Use MTU = 1400)

Drop

DF Set? Length < 1400 MTU?

ICMP Unreachable (Use MTU = 1342)

Drop ESP Encap

ICMP (1342-bytes)

1342 + 58

ESP Decap ICMP (1400-bytes)

ICMP (1400-bytes)

1400 – 58

ICMP (1342-bytes) ICMP Echo Reply

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 (1500bytes—58bytes max ESP overhead) back to Host_A.

3.

Host_A receives the ICMP Unreachable message with the MTU information, and forwards another ICMP packet of 1442 bytes in length to Router_A. Router_A encapsulates the packet with ESP and forwards it across the VPN with the DF bit set in the outer header.

4.

Router_C receives the ICMP message from Router_A in Step 3 and notes that the packet exceeds the MTU of its serial interface to Router_B. Because the DF bit is set, Router_C drops the packet and forwards an ICMP Unreachable to Router_A with the MTU size of 1440 embedded.

5.

Router_A receives the ICMP Unreachable message from Router_C in Step 4. Router_A notes the MTU size of 1440 in the PMTU field of the SA that is established with Router_B. Router_A does not send a new ICMP message of 1440 in length, but instead this is handled by Host_A in step 6.

6.

Host_A retransmits an ICMP message of 1442 in length, as it never received an acknowledgement from the original ICMP message sent in Step 2.

7.

Router_A compares the ESP-encapsulated packet size (1442+58) of the packet received in step 6 above with its path MTU (1440) and drops the packet. Router_A responds with an ICMP unreachable with the MTU of 1342 (1400 PMTU less ESP overhead of 58 bytes) embedded.

8.

Host_A sets its MTU to 1342 and forwards a new 1342-byte message to Server_B. The message and associated ESP overhead is now lower than the end-to-end path MTU, resulting in a successful transmission from Host_A to Server_B.

As we’ve discussed in previous sections of this chapter, and in others, it is sometimes necessary to encapsulate certain traffic types in GRE prior to processing them with IPsec. Processing of multicast traffic, for example, is one instance in which one would seek to encapsulate the plain text traffic in GRE prior to encapsulating it in ESP. This is commonly referred to as IPsec+GRE. This process includes an additional 24 bytes of overhead, as the GRE header is applied in addition to the ESP or AH headers. More importantly, it adds additional steps to the Tunnel PMTUD operation while trying to avoid fragmentation. Figure 4-17 illustrates the fragment handling process using PMTUD in an IPsec+GRE scenario.

Architectural and Design Issues with IPsec VPNs

Figure 4-17

Fragment Handling and PMTUD Operation with IPsec+GRE Tunnels MTU = 1500

MTU = 1500

MTU = 1400 GRE

IP

IP

Router_A

MTU = 1500

ESP

Router_C

IP

IP

Router_B

IP

IP

IP Server_B

GRE Encap ICMP (1500-bytes)

1500 + 24 DF Set?

Host_A

Length < 1496 MTU?

ICMP Unreachable (Use MTU = 1472)

Drop GRE Encap

ICMP (1472-bytes)

1472 + 24 DF Set? Length < 1496 MTU? ESP Encap 1472 + 58 DF Set? Length < 1500 MTU? Drop Set GRE MTU = 1414

Timeout and Retransmit

GRE Encap

ICMP (1472-bytes)

1472 + 24

ICMP Unreachable (Use MTU = 1414)

Length < 1414 MTU?

DF Set?

GRE Encap ICMP (1414-bytes)

1414 + 24 DF Set? Length < 1496 MTU? ESP Encap 1438 + 58 DF Set? Length < 1500 MTU?

Update SA PMTU Timeout and Retransmit ICMP (1414-bytes)

ICMP (1442-bytes)

ICMP Unreachable (Use MTU = 1400)

DF Set? Length < 1400 MTU? Drop

GRE Encap 1414 + 24 DF Set? Length < 1496 MTU? ESP Encap 1438 + 58 DF Set? Length < 1400 MTU? Drop Set GRE MTU = 1342

Timeout and Retransmit ICMP (1414-bytes)

GRE Encap 1414 + 24 DF Set?

ICMP Unreachable (Use MTU = 1318)

Drop Length < 1342 MTU? GRE Encap

ICMP (1414-bytes)

1318 + 24 DF Set? Length < 1342 MTU? ESP Encap 1342 + 58 DF Set? Length < 1400 MTU? ICMP Echo Reply

191

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 (1500—GRE header length of 24).

3.

Host_A sends a 1476 byte packet with the DF bit set to Server_B.

4.

Router_A receives the packet, noting that the DF bit has been set. The router encapsulates the packet in GRE and then attempts to encapsulate it in ESP. The added ESP encapsulation pushes the MTU over the serial interface MTU of 1414, so Router_A drops the packet. ESP sends an ICMP error message to GRE indicating an MTU of 1376 bytes (1414 less max ESP header length of 38 bytes). GRE records this value as the new tunnel IP MTU.

5.

Host_A retransmits the 1476-byte packet in step 3, as no acknowledgement was received. Router_A drops this packet as it exceeds the tunnel IP MTU derived in step 4. Router_A responds with an ICMP Unreachable message with the tunnel IP MTU of 1414.

6.

Host_A sends a new ICMP message of 1414-bytes in length to Server_B. Router_A encapsulates in GRE, and then encapsulates in ESP. The DF bit is copied to the outer IP header in the ESP packet before transmitting across the IPsec VPN.

7.

Router_C receives the packet, and notes that the DF bit is set. The size of the packet is now 1414, as GRE and ESP headers have been added to the original ICMP message sent in step 6. Router_C drops the packet, as it exceeds the MTU of the link to Router_B and has the DF bit set. Router_C sends an ICMP unreachable message to Router_A with the MTU of 1400.

8.

Router_A receives the ICMP unreachable message from Router_C in step 7 above and updates the PMTU field of its IPsec SA to Router_B with the 1400-byte value.

9.

Host_A retransmits the 1414-byte ICMP message in step 6 to Server_B, as no acknowledgement was received.

10.

Router_A receives the packet, and encapsulates it in GRE. Once ESP encapsulation is applied, the length of the packet exceeds the 1400-byte IPsec SA PMTU obtained from Router_C in step 8. ESP sends an ICMP message to GRE with an MTU of 1342 (1400—58 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.

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 finally forwards the original ICMP PMTUD message to Server_B.

16.

Server_B acknowledges the receipt of the message, confirming that Host_A is to use an MTU size of 1338 bytes for this path.

NOTE Although the DF bit in PMTUD ICMP messages is always set so as to properly detect areas of fragmentation, ICMP Unreachable responses to these messages are sent with the DF bit set to 0. As such, it is important to note that ICMP PMTUD messages sent from source to destination will never be fragmented, but the responses to those messages could quite possibly be fragmented along the return path.

Solutions for Preventing Fragmentation In previous sections, we’ve discussed the most common method for preventing 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 filtering of ICMP messages at various points within the network. As such, it is important to understand other ways in which fragmentation can be avoided when designing an IPsec VPN. We will discuss several techniques for mitigating IP fragmentation other than PMTUD in this section. IPsec Prefragmentation IPsec Prefragmentation is a Cisco IOS feature that enables an encrypting IPsec VPN endpoint to attempt fragmentation before encryption if a size of the encrypted packet and additional header information exceeds the MTU of the path in between endpoints. PMTUD can be used to determine the path of the SA and the MTU of that path. Doing so in conjunction with IPsec Prefragmentation provides a very scalable and manageable method of increasing the overall performance of an IPsec VPN where fragmentation after encryption is a possibility. Example 4-34 illustrates how to configure IPsec crypto DF-bit overwrite with IPsec Lookahead Fragmentation such that the path MTU of the SADB will be dynamically determined using tunnel PMTUD, and large packets will be fragmented (those exceeding the Path MTU for that SA in the SADB) before encryption.

194

Chapter 4: Common IPsec VPN Issues

Example 4-34

Enabling IPsec Prefragmentation with PMTUD and Crypto DF-bit Rewrite

config Router_A#c config ure termin al Router_A#c Enter configuration commands, one per line.

End with CNTL/Z.

crypto IPsec df-b it set Router_A(config)#c crypto IPsec frag mentation before-encr yption Router_A(config)#c Router_A(config)#

TIP Although in the case of Example 4-34, Router_A will attempt to fragment large packets before encrypting them, there are many configuration instances in which IPsec Lookahead Fragmentation and DF-bit overwrite are configured incorrectly. It is critical to understand the interdependencies of the DF-bit setting and the Lookahead Fragmentation setting addressing IPsec fragmentation design considerations. For a full listing of DF-bit interoperability with IPsec Lookahead Fragmentation settings, please refer to the following URL on CCO: http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/ products_feature_guide09186a0080115533.html

Figure 4-18 illustrates a client server exchange that does not support PMTUD. Note that, even though there is no exchange of ICMP messages, the Path MTU is still discovered and updated in Router_A’s IPsec SADB. There are three key operations that enable this feature: ■

Lookahead Fragmentation: Before forwarding an IPsec packet, Router_A predetermines the encapsulated packet size, and compares it with the MTU in the SADB. If it is predetermined to exceed that MTU size, the packet is fragmented before it is encrypted.

■

Crypto DF-bit Rewrite: When PMTUD is not supported, it is important that Router_A be able to set the DF bit in the outer IP header of IPsec-encapsulated packets. This prevents fragmentation, and triggers ICMP unreachables needed to adjust the Path MTU in Router_A’s SADB.

■

Processing of MTU Information in ICMP Unreachables: Router_A is capable of deciphering MTU information of ICMP unreachables (received when IPsec packets with DF=1 are dropped). It uses this information to dynamically update the path MTU in its SADB.

The exchange between Router_A and Router_B in Figure 4-18 illustrates how all of these three features work in concert to minimize the effect of postencryption fragmentation in IPsec VPN deployments where PMTUD is note-enabled on the endstations:

Architectural and Design Issues with IPsec VPNs

Figure 4-18

195

IPsec Fragment Handling Without PMTUD-Enabled Endstations MTU = 1500

MTU = 1500

MTU = 1400

MTU = 1500

ESP

IP

IP

Router_A

IP

Router_C

IP

Router_B

IP

IP

IP Server_B IP (1500-bytes)

Lookahead Fragment 1500 + 58 < MTU?

Host_A Set Path MTU = 1400

Pre-Frag Router configured to manually clear the DF bit so that IPsec prefragmentation can occur (See Example 4-11)

Packet = 1442 bytes Fragment = 78 bytes ESP Encap 1442 + 58

Set DF = 1

ESP + IP (1500-bytes)

DF Set? Length < 1400 MTU?

Router configured to set DF bit in every outside IP header applied during ESP encapsulation.

Set PMTU in SADB to MTU = 1400

ICMP Unreachable (Use MTU = 1400)

Drop

ESP Encap 78 + 58

Set DF = 1

ESP + IP (136-bytes)

DF Set? ESP Decap Length < 1400 MTU?

Timeout and Retransmit ICMP (1500-bytes)

IP + ESP (136-bytes)

136 – 58

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.

Lookahead Fragment 1500 + 58 < MTU? Pre-Frag Packet = 1342 bytes

Reassemble Length < 1500 MTU?

Fragment = 78 bytes

IP (1342 bytes + 158 bytes)

ESP Encap 1342 + 58 Set DF = 1

IP + ESP (1400-bytes)

DF Set? ESP Decap Length < 1400 MTU?

IP + ESP (1400-bytes)

1400 – 58

ESP Encap 158 + 58 Set DF = 1

IP + ESP (216-bytes)

DF Set? ESP Decap Length < 1400 MTU?

IP + ESP (216-bytes)

216 – 58

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.

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 ( IPSecB2)

IPSec_A2

Secon

Fa0/0 IPSec_B2

) ec_B2 -> IPS PN Tu c_A1 nnneel l(I(IPSe n u P T S N ec_A2 ec VP -> IPS ry IPS ec_B1 conda

dary IP

Network_A

Sec V

Se

IPSec_A1

/1

rial0

Fa0/0

Se

Serial0/0

Site A

Fa0/0

Serial0/0

Serial0/0

Network_B )

Primary IPSec VPN Tunnel (IPSec_A1 -> IPSecB1)

IPSec_B1 Ser

Fa0/0

ial0

/1

Serial0/0

Fa0/0

Fa0/0

WAN_EdgeA2

WAN_EdgeB2

Site B

214

Chapter 5: Designing for High Availability

NOTE Further explanation of design considerations and configuration of sourcing and terminating IPSec tunnels on loopback interfaces can be found in Chapter 6, “Site-to-Site Local HA Solutions.” More detail on IPSec VPN design with redundant IPSec peering statements can be found in Chapter 7, “Site-to-Site Geographic HA Solutions.”

RP-based IPSec HA Because IPSec itself is a Layer 3 VPN technology, IPSec is dependent on the existence of a stable IP transport between tunnel termination points to operate effectively. This means that IPSec requires accurate and timely updating of routing information on intermediate nodes between the termination points of the IPSec tunnel. The routing protocol of the IP infrastructure underneath the IPSec tunnel is responsible for communicating routing information to nodes in between the IPSec tunnel termination endpoints. If there is an RP failure between the two termination points of the IPSec tunnel, then IPSec traffic will not be able to flow between the two endpoints, eventually leading to expiration of the previously negotiated SA lifetimes or timeout of the IKE keepalives (if enabled). Fortunately, IPSec is not path-discriminate—IPSec traffic will take any available Layer 3 path from the tunnel source to tunnel destination before tearing down the tunnel. Administrators can therefore leverage the use of routing protocols between tunnel endpoints to provide numerous routed paths between source and destination. Figure 5-8 illustrates a design in which the dedicated WAN circuits incorporated into the designs in Figures 5-1 through 5-7 are replaced with uplinks to an ISP, presenting a much higher degree of HA beyond the interface of the WAN_Edge routers. The ISP has many different paths through which to route packets between the WAN_Edge routers as opposed to just one with the dedicated WAN circuits. Figure 5-8

RP-Based HA between IPSec Tunnel Termination Points WAN_EdgeA1 Fa0/0

WAN_EdgeB1

l0/0

Seria

Serial0/0

Fa0/0

Primary IPSec VPN Tunnel

1 l0/ ria Se

nn

el

1 /1

Routed Infrastructure

Network_B

al0

c

Se

IPSec_B2

l0/

T PN IPS ec V S e IP c V PN ry da Tu on ary

Fa0/0

ri Se

IPSec_A1

Fa0/0

el

n un

nd

1

Network_A

ISP Layer 3

co

0/

l ria Se

Se

ria

Fa0/0

Se

IPSec_A2

Fa0/0

IPSec_B1

Primary IPSec VPN Tunnel

Site A

Fa0/0

Serial0/0

WAN_EdgeA2

l0/0

Seria

WAN_EdgeB2

Fa0/0

Site B

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. WARNING You may have noticed already that, as with most value-added services, increased HA usually comes with increased cost. In the context of the design illustrated in Figure 5-5, this cost is represented by the doubling of fee-based WAN links on the WAN_Edge routers (8 ISP uplinks versus 4 dedicated WAN circuits). Because of this, investing in increased HA is a business decision, and the needs of the business should be carefully evaluated when investing in the increased benefit of added IPSec HA. If overlooked, administrators face the risks associated with over-designed IPSec deployments, including increased maintenance, management, complexity, and costs.

Managing Peer and Path Availability In any IPSec VPN design, it is important to ensure that both IPSec peers are available to one another, reachable through the IP-enabled infrastructure. An IPSec peering point can be thought of as a tunnel termination point. Each IPSec VPN tunnel endpoint must know how to source the IPSec VPN tunnel locally and how to reach the target termination point (its IPSec peer) from the tunnel source in order to successfully negotiate a Phase 2 SA. This requirement is referred to as peer availability. It is also important to ensure that when peers are unavailable to one another, the SADB is managed properly so that IPSec VPN tunnels are allowed to reconverge in HA environments. NOTE Improper management of peer availability can lead to the existence of stale SAs, prohibiting rapid reconvergence of IPSec VPNs in failover scenarios. The impact of stale SAs on IPSec HA designs is discussed in detail in Chapter 6, “Site-to-Site Local HA Solutions,” and Chapter 7, “Site-to-Site Geographic HA Solutions.”

Once peer availability has been addressed, it is important to make sure that the encrypted path (the IPSec VPN tunnel) is available to traffic to be included in the encrypted path. In other words, traffic to be encrypted must be able to be effectively routed through the IPSec VPN tunnel. This is referred to as crypto path availability. There are several common instances in which path availability may be impeded, the most common of which is when routing protocol traffic cannot

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 traffic to be included in the encrypted path, as either cleartext domain will not know how to route to the other because RP updates are not natively exchanged across the IPSec VPN tunnel or ciphertext routed domain. We will discuss this particular example in greater detail later in this section.

Peer Availability In this section, we will explore features of IPSec and ISAKMP that can be used to manage peer availability—Dead 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

On-Demand Dead Peer Detection (DPD) IPSec_B1

2

Si

5

IPSec_A

Prim

ary IP

3

Sec V

PN Tu

nnel

4

Si 1

IPSec_B2

Site A

Site B

IKE Keepalives (DPD with Periodic Queries) IPSec_B1

Si

5

IPSec_A

Prim

ary IP

2 3 4

Sec V

PN Tu

nnel

Si 1

IPSec_B2

Site A

Site B

When an IPSec peer goes offline, the SADB retains the security associations for that peer for the length of the lifetimes negotiated during Phase 1 and 2 SA negotiations. For example, if two IPSec VPN gateways establish IKE and IPSec SAs using the default lifetimes IPSec tunnel were to fail, stale IKE and IPSec SAs could remain present in the SADB for up to 86400 seconds (1 day) and 3600 seconds (1 hour), respectively. This behavior, if not managed properly, can lead to confusion when negotiating new SAs with new peers (see Chapter 6, “Site-to-Site Local HA Solutions,” and

Managing Peer and Path Availability

217

Chapter 7, “Site-to-Site Geographic HA Solutions,” for more detail on IPSec High Availability) and inefficient use of memory on the IPSec gateway itself. Although these SAs would remain in the SADB of the remote IPSec SADB for an excessively long time, there are methods of reaping stale SAs from the SADB in a more expedient fashion. The default behavior of Cisco IOS is to use on-demand Dead-Peer Detection. On-demand DPD expedites the discovery and removal of stale SAs by sending out DPD status query messages when the status of the remote peer is questionable and there is traffic to be forwarded in the crypto path to that peer. Consider the scenario illustrated Figure 5-9, in which IPSec_B1 fails. IPSec_A uses on-demand DPD to expedite the discovery and removal of SAs with the dead peer, IPSec_B1, using the following steps: 1.

A failure occurs on IPSec_B1, preventing it from successfully terminating the IPSec VPN tunnel from IPSec_A.

2.

IPSec_A receives traffic from the workstations at Site_A and must forward the traffic across the encrypted path to Site_B through its IPSec VPN tunnel to IPSec_B1.

3.

IPSec_A forwards a DPD status query message to IPSec_B2 in order to determine the status of the peer.

4.

IPSec_B1 is unable to respond to the DPD status query message sent by IPSec_A. Steps 3 and 4 are retried a number of times, corresponding to the specified retry value.

5.

IPSec_A waits to receive a response to its DPD status query message sent in Step 3. When it receives no response from IPSec_B1, IPSec_A begins to purge its SADB of the security associations previously negotiated with IPSec_B1.

One important element of the DPD process described above is the fact that with on-demand DPD, traffic must be forwarded to the remote peer to initiate the discovery of the dead peer (Step 2). If traffic is not sent to that peer, then the DPD status query message will not be forwarded to the remote peer, and the tunnel SAs will remain installed in the local gateway’s SADB for the duration of their previously negotiated lifetimes. This could potentially cause issues with reconvergence if, for example, a redundant IPSec tunnel were to be negotiated over the redundant path between Site A and Site B. One way of eliminating stale SAs in such a scenario is to enable the use of IKE keepalives, which provision for the removal of stale SAs from the SADB regardless of whether or not traffic is actively being forwarded to the dead peer. The process of SA removal with IKE keepalives, also depicted in Figure 5-9, operates in the following manner: 1.

The primary IPSec gateway for Site B goes offline.

2.

The IPSec gateway for Site A forwards its first IKE keepalive to the dead peer at Site B

3.

Site A’s IPSec gateway does not receive a response to the first IKE keepalive within the configured keepalive interval (default of 10 seconds). Site A’s IPSec gateway forwards a second IKE keepalive to the dead peer at Site B.

218

Chapter 5: Designing for High Availability

4.

Site A’s IPSec gateway does not receive a response to the first IKE keepalive within the configured keepalive interval. Site A’s IPSec gateway forwards a third IKE keepalive to the dead peer at Site B.

5.

After Site A has waited the duration of the keepalive interval without receiving a response to its third IKE keepalive, it declares that its peer at Site B is dead and removes the security associations with Site B’s IPSec gateway from its own local SADB.

The two concepts described above are critically important when designing large-scale enterprise IPSec deployments. On-demand DPD and periodic DPD provide two different methods of proactively detecting stale SAs left over from dead IPSec peering sessions. On-demand DPD requires traffic along the encrypted path to initiate DPD status queries and consumes less overhead than periodic DPD (IKE keepalives), while periodic DPD can proactively detect dead peers without the presence of traffic in the encrypted path. Improper management of the IPSec SADB can lead to operational issues in HA environments and platform scalability issues specifically relating to excessive CPU utilization on platforms managing DPD for a large number of SAs. We will discuss the use of DPD to streamline the reconvergence process of an IPSec tunnel in our discussion of IPSec High Availability in Chapter 6, “Site-to-Site Local HA Solutions,” and Chapter 7, “Site-to-Site Geographic HA Solutions.”

Path Availability As we have already mentioned in our discussion of the IPSec protocol in Chapter 3, “Basic VPN Topologies and Configuration,” IPSec will not encrypt multicast traffic without the use of a prior instantiation of encapsulation using another tunneling protocol such as GRE. In many designs, it may be desirable to separate routing protocol domains while still joining routed domains between the two opposite ends of the IPSec tunnel, as shown in Figure 5-10. Figure 5-10

IPSec and Multicast RP Updates To unify RP domains A and B using the IPSec VPN tunnel, the IPSec VPN gateways must use either RRI or IPSec + GRE.

IPSec-A

IPSec-B Routed Domain C

Routed Domain A

IPSec VPN Tunnel

Multicast RP updates from domain A to B cannot pass across the IPSec VPN tunnel.

Routed Domain B

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 configure the RP to use unicast updates, rather than multicast updates. Configuring of unicast neighbors in RP processes come with added configuration, management, and scalability issues. However, in simpler site-to-site IPSec VPN environments, the configuration of unicast updates can be configured with a minimal increase in management and administration while eliminating the overhead added by GRE headers in an IPSec+GRE scenario. Unlike most routing protocols, Border Gateway Protocol (BGP) natively uses unicast updates by establishing a TCP session on port 179. Therefore, RP updates using BGP can be sent through the crypto switching path without the use of GRE prior to encryption. Encrypted BGP updates are useful in designs requiring inter-AS connectivity between disparate IGP RP domains. Like unicast RP updates, BGP updates eliminate packet overhead and encapsulation inherent to IPSec+GRE designs. This method represents the fourth method of preserving RP information between two routed domains on opposite ends of an IPSec VPN tunnel that we’ve discussed in this chapter. The complete list of methods is as follows: ■

Reverse Route Injection (including static routes)

■

Multicast routing updates encapsulated in GRE

■

Unicast RP updates using unicast IGP neighbor definition

■

Unicast RP updates with BGP

Depending on the crypto platform selected, packets encapsulated in GRE may not be forwarded in hardware, regardless of whether or not some method of crypto hardware assist is present on the IPSec VPN gateway. It is therefore critically important to evaluate all options of preserving RP consistency across the VPN tunnel so as not to force traffic outside of the fast crypto switching path by unnecessarily using GRE on a platform that does not support the encapsulation of GRE packets in hardware.

Managing Path Symmetry IPSec is a stateful protocol, meaning that it relies on the maintenance of a state table (SADB) and security associations (SAs) to process information in the crypto switching path. It is therefore important to make sure that traffic is sent to, and received from, the appropriate tunnel termination points present in Phase 2 SAs. Figure 5-11 illustrates a situation in which the IPSec VPN tunnel is broken due to path asymmetry.

220

Chapter 5: Designing for High Availability

IPSec VPN Failure Due to Path Asymmetry

Figure 5-11

Site_A

IPSec_A 1 Stateful firewall allows return IPSec traffic for sessions initiated from the inside (Site_A to Site_B) to return along Path #1.

3 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.

IEDGE_A1 IEDGE_A2 PATH #1

2

INET_A

The serial link between INET_A and IEDGE_B1 fails, causing the asymmetric routing between Site_A and Site_B.

INET_B

PATH #2 IEDGE_B1 IEDGE_B2

IPSec_B

Site_B

In Figure 5-11, a failure occurs on the IPSec tunnel between IPSec_A and IPSec_B due to asymmetric routing. In this case, all RP traffic is sent in the clear, resulting in one contiguous RP domain. When a failure occurs between INET_A and IEDGE_B1, the routing protocol reconverges in a manner that causes asymmetric routing between Site_A and Site_B. Specifically, after the failure, resources on Site_A chooses Path #1 to Site_B, while Site_B chooses Path #2. All interfaces on both IPSec_A and IPSec B are configured for IPSec, but there is a firewall prohibiting IPSec reconvergence along Path #2. This example illustrates just one scenario in which IPSec VPN tunnels can be broken when asymmetric paths exist between tunnel endpoints. We will discuss several methods for guaranteeing path symmetry in an IPSec VPN, including the tuning of routing protocol for path symmetry and the role of HSRP-based IPSec tunnel termination in path symmetry.

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 Site_A

IPSec_A

Stateful firewall allows return IPSec traffic for sessions initiated from the inside (Site_A to Site_B) to return along Path #1.

PATH #2 IEDGE_A1 IEDGE_A2

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.

PATH #1 INET_A INET_B

IEDGE_B1 IEDGE_B2

IPSec_B

Site_B

222

Chapter 5: Designing for High Availability

In Figure 5-12, the IEDGE routers at both Site_A and Site_B are configured to forward traffic to the next hop of IPSec_A1 and IPSec_B1, respectively, unless the IPSec VPN gateways are down. This configuration helps to avoid the path symmetry problems experienced previously, as illustrated in Figure 5-11, regardless of any topological changes in between Site_A and Site_B that may cause a shift in the Layer 3 paths between IPSec VPN gateways. NOTE There are many ways to instantiate the RP metric changes to achieve the behavior discussed above and illustrated in Figure 5-12—static routes would be one option, policy-based routing could be another, and hard-coded routing protocol metrics yet another. The specific methods of RP tuning, however, are outside of the scope of this discussion.

Load Balancing, Load Sharing, and High Availability Load balancing between IPSec VPN tunnels provides some of the benefits of High Availability but, in general, meets a different set of design objectives than does HA. When discussing HA designs, we have typically included designs in which redundancy is built into the IPSec system. Specifically, these are designs that have IPSec VPN tunnels which are used strictly for backing up encrypted communications when the primary IPSec VPN tunnel is down—only one tunnel, main or standby, is used at a time. When traffic is load balanced between multiple IPSec VPN tunnels, the traffic flows are divided and shared across the IPSec VPN tunnels. Unlike the redundancy options discussed up to this point, a load-balancing design uses multiple IPSec VPN tunnels simultaneously and therefore does not take a main/backup approach to IPSec VPN design. That said, load-balanced designs provide some degree of HA, since when any one of the IPSec VPN tunnels supporting the loadbalanced design fails, the remaining operational IPSec VPN tunnels can assume the extra load that was originally forwarded through the failed IPSec VPN tunnel. In this section, we will explore several methods for building load-balanced IPSec VPN designs.

Load-Sharing with Peer Statements IPSec VPNs can use the underlying routing protocol to load balance encrypted traffic across multiple paths. Although the effectiveness of load-balancing IPSec VPN tunnels using routing protocol depends somewhat on the capabilities of the routing protocol itself (such as equal-cost load-balancing capabilities within OSPF), a load-balanced solution also requires the appropriate configuration of crypto ACLs, crypto maps, and crypto peers. Figure 5-13 illustrates a scenario in which the crypto ACLs are configured to load balance traffic between two IPSec VPN tunnels between IPSec_A and IPSec_B.

Load Balancing, Load Sharing, and High Availability

Figure 5-13

223

Multiple Peer Statements and Load Balancing

10.2.1.0/24

10.1.2.0/24

10.1.1.0/24

Si

.1

200.1.1.0/30

10.2.2.0/24

Si

.2 IPSec VPN Tunnel #1

200.0.0.2/24

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.4/24

IPSec VPN Tunnel #2

IPSec_A

IPSec_B

.3 200.1.1.4/30

.4

Routing-protocol traffic between the two IPSec VPN endpoints, IPSec_A and IPSec_B, is exchanged in cleartext, allowing the IPSec tunnels to be built, as in Figure 5-13. RRI is used to preserve routing continuity between the two routed domains on opposite ends of the IPSec tunnel between IPSec_A and IPSec_B. The traffic flows in Figure 5-13 are forced over the two IPSec tunnels in a load-shared format by configuring the crypto ACLs to forward traffic over the corresponding tunnel to the appropriate peer IP address—traffic from 10.1.1.0/24 to 10.1.2.0/24 takes Path #1, while traffic from 10.2.1.0/24 to 10.2.2.0/24 takes Path #2. Examples of proper and improper usage of load balancing with alternate peering statements are illustrated in Examples 5-1 and 5-2, respectively. Example 5-1

Using Multiple Peering Statements for Load Balancing and Redundancy

crypto map chap5 -loadbal 1 0 ipsec-isa kmp ! # set p eer 200 .0.0. 2 set tra nsform-set c h ap6-dualint ! # match addre ss 1 01 re verse-route crypto map chap 5-loadbal 1 0 ipse c-sak mp ! # set peer 200.0.0.4 s et tr ansform-se t chap6-du a lint

continues

224

Chapter 5: Designing for High Availability

Example 5-1

Using Multiple Peering Statements for Load Balancing and Redundancy (Continued)

! # match add ress 102 reverse -route ! access-lis t 101 pe rm it ip 10.1 .1.0 0.0.0.2 55 10.1.2 .0 0.0.0.255 access -list 102 permit ip 10.2. 1.0 0 .0.0.255 10.2 .2.0 0. 0.0.255

Note that in Example 5-1, traffic is manually shared between two different tunnel termination endpoints, 200.0.0.2 and 200.0.0.4, by splitting the traffic flows out into separate crypto ACLs, 101 and 102. Let us now look at a configuration example where multiple peers are used, but only for pure redundancy and no load balancing. Using the configuration listed in Example 5-2, IPSec_A uses 200.0.0.2 as the destination tunnel termination address for the encrypted traffic flow specified in crypto ACL 101. If 200.0.0.2 is unavailable, the crypto engine will use 200.0.0.4 for IPSec peering for traffic matching ACL 101. Unlike Example 5-1, ACL 101 is configured to match all traffic flows. This results only in IPSec tunnel termination point redundancy—no load sharing is achieved.. Example 5-2

Using Multiple Peering Statements for Redundancy Only

crypto map chap5- redundant 10 ipsec-isa kmp set peer 200. 0.0.2 set peer 200.0 . 0.4 set transfo rm-set chap 6- dualint match address 1 0 1 reverse-rou te ! access -lis t 101 pe rmit ip 10 .1.1.0 0.0 .0.255 10.1.2 .0 0.0.0. 255 acc ess-list 10 1 permit ip 10.2.1 .0 0.0.0.255 10. 2.2. 0 0.0.0.255

Routing Remember that one key benefit of Layer 3 (L3) encryption technologies, like IPSec over Layer 2 (L2) encryption technologies, is that traffic flows can be kept confidential and secure over multiple L2 domains. It is therefore important that the underlying routing protocol between IPSec tunnel termination endpoints be configured to evenly distribute IPSec traffic across multiple available L3 paths en route to the appropriate target tunnel termination point. Figure 5-14 shows some examples of appropriate and inappropriate IPSec traffic distribution across multiple routed paths between the tunnel termination endpoints.

Load Balancing, Load Sharing, and High Availability

Figure 5-14

225

Intermediate RP Impact on IPSec Traffic Flow Distribution Scenario 1 – Unbalanced Routed Paths Router_A

Router_C

Router_E

VPNGW_A

VPNGW_C

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.

VPNGW_D

VPNGW_B Router_B

Router_D

Router_F

Scenario 2 – Balanced Routed Paths Router_A

Router_C

Router_E VPNGW_C

VPNGW_A

Ensuring RP metrics forces IPSec traffic over both available L3 paths andyields more effective utilization of bandwidth between tunnel termination endpoints.

VPNGW_D

VPNGW_B Router_B

Router_D

Router_F

Domain Name System (DNS) IPSec clients can be configured to use DNS to resolve the IP address of their IPSec peer. This allows designers to use DNS server load balancing to distribute the number of IPSec sessions across multiple IPSec VPN concentrators. In this type of design, the DNS server would resolve the same hostname to multiple addresses. When it receives a query from one of the IPSec clients to resolve the concentrator’s hostname to a given IP address to be used for Phase 1 and 2 negotiations, the DNS server would return the first IP address associated with the concentrator’s hostname. The DNS server would then continue to map subsequent resolutions to the other addresses mapped with the concentrator’s hostname, yielding a round-robin distribution of inbound IPSec sessions from the IPSec VPN clients across the various IPSec VPN concentrators. Figure 5-15 illustrates the mechanics of a DNS-based, load-balanced IPSec RAVPN implementation. 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.

226

Chapter 5: Designing for High Availability

DNS-Based Load Balancing

Figure 5-15

3

4

1

6

IPSec_Client5b IPSec_Client5a 7

DNS Servers 2

9 5

ISP 8

IPSec_Client5c

IPSec_Cluster5 200.1.1.1

200.1.1.2

Outside 200.1.1.3

DMZ Outside Si

Si

DMZ Inside Inside

Si

Si

Si

Si

Si

Si

Si

Si

Si

Si

The following sequence of operations corresponds to the order of operations illustrated in Figure 5-15, outlining the DNS-based load balancing of IPSec tunnels from VPN clients to the IPSec VPN cluster: 1.

IPSec_Client5a initiates Phase 1 negotiation with the concentrator using the hostname IPSec_Cluster5. The client attempts to resolve the hostname with its configured DNS server in order to identify the peer IP address.

2.

The DNS server returns the first IP address in the name record for IPSec_Cluster5, 200.1.1.1 (the first concentrator in the cluster).

3.

IPSec_Client5a initiates an IKE and IPSec SA negotiations with the first concentrator in the cluster using the peer IP address of 200.1.1.1.

4.

IPSec_Client5b attempts Phase 1 negotiation with the concentrator using the hostname IPSec_Cluster5. The client attempts to resolve the hostname with its configured DNS server in order to identify the peer IP address.

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 configured DNS server in order to identify the peer IP address.

8.

The DNS server returns the third IP address in the name record for IPSec_Cluster5, 200.1.1.3 (the third concentrator in the cluster).

9.

IPSec_Client5a initiates an IKE and IPSec SA negotiations with the third concentrator in the cluster using the peer IP address of 200.1.1.3.

CAUTION The example above illustrates a basic round-robin distribution of DNS resolutions as clients request the IP address corresponding to the name of their VPN Concentrator. Take care when configuring your DNS server to ensure that the DNS name resolutions are being returned in the appropriate order with which you would like the sessions to be load balanced across your VPN concentrators.

Subsequent clients follow the same round-robin approach since the DNS server returns the three IP addresses in a round-robin fashion each time a name resolution request for IPSec_Cluster5 from the clients. This results in an even distribution of IPSec client sessions within the concentrator cluster.

Cisco VPN3000 Concentrator Clustering VPN concentrator clustering enables network administrators to effectively distribute the load of IPSec VPN tunnels from remote IPSec VPN clients. Recall that DNS-based load balancing maps multiple VPN concentrator IP addresses to a common DNS name which all clients use to establish their IPSec VPN tunnels. DNS-based load balancing of IPSec sessions therefore provides a round-robin distribution of inbound IPSec VPN sessions on the concentrator IP addresses that share the same hostname. NOTE VPN3000 Clustering is a Cisco proprietary function. For environments that use IPSec VPN concentrators from other manufactures, another alternative such as DNS-based load balancing should be considered.

One major limitation of this type of deployment is that the DNS server that is doing the load balancing has no awareness of the current load on the concentrator to which it is effectively assigning the next inbound IPSec VPN session. This is not the case in a clustered deployment of IPSec VPN3000 concentrators. VPN3000 concentrators can be configured to intelligently direct

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 stepby-step process of inbound IPSec VPN tunnel termination from remote IPSec VPN clients on a VPN3000 concentrator cluster, but first let’s discuss the VCA configuration tasks that must be accomplished on the VPN3000 to achieve IPSec VPN load balancing within the cluster:

Table 5-1

■

VPN Virtual Cluster IP Address—This is the IP address that the remote IPSec VPN clients use as their IPSec peer address in Phase 1 and 2 negotiations. As the VCA master will distribute (load-balance) these inbound IPSec VPN sessions to the concentrator with the lowest load in the cluster, all concentrators within the VPN3000 cluster must share this address.

■

VPN Virtual Cluster UDP Port Number—This is the UDP port number that the VCA master will use to communicate with the secondary VCAs to gather load information from each VPN3000 concentrator in the cluster.

■

Encryption and Shared Secret—VCA communications between concentrators in the cluster can be encrypted using IPSec. If encryption is enabled, then a shared secret key must be entered to cipher and decipher the communications between the VCA master and its secondary VCAs.

■

Enabling Load Balancing—The load-balancing enable radio button must be checked for the VPN3000 concentrator to participate in the cluster.

■

Priority—Concentrators within a cluster are assigned a priority to determine which cluster will assume the role of the master VCA. The first concentrator in the cluster assumes the role of master VCA; subsequent concentrators to come online within the cluster are secondary VCAs. When the master VCA fails, then the concentrator with the highest priority assumes the role of master VCA. If upon master-VCA failure two secondary VCAs share the same priority, the concentrator with the lowest IP address will break the tie and become master VCA. Table 5-1 shows the default priority for various VPN3000 models. VPN3000 Priority Default Settings VPN Concentrator Model

Priority Default

3005

1

3015

3

3020

4

Load Balancing, Load Sharing, and High Availability

229

VPN3000 Priority Default Settings (Continued)

Table 5-1

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 configuration of VCA clustering on VPN3000 series IPSec VPN concentrators and ASA5500 series VPN appliances. Figure 5-16 depicts a scenario in which inbound IPSec VPN sessions are load-balanced between a cluster of Cisco VPN3000 concentrators. Figure 5-16

IPSec Session Load Balancing Using VPN3000 Concentrator Clustering

ISP 3

1

5

Si

Si

1

VPN3000_B

VPN3000_A 2

1

2

7

7

7

6 8 4

VPN3000_C

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 configured priorities within the cluster as it comes online first.

2.

The master VCA in the cluster, VPN3000_A, gathers information on the current session load on the secondary VCAs in the cluster, VPN3000_B and VPN3000_C.

3.

A remote VPN client initiates an IPSec VPN tunnel to the virtual cluster IP address.

4.

The master VCA in the cluster, VPN3000_A, directs the negotiation of the Phase 1 and 2 SAs to the concentrator with lowest load in the cluster (determined previously in Step 2), VPN3000_B.

5.

An IPSec VPN tunnel is established between the IPSec VPN client and VPN3000_B.

6.

A failure occurs on VPN3000_A, causing it to clear all IPSec SAs from its SADB and leave the concentrator cluster.

7.

The concentrator with the highest priority (VPN3000_B) takes over as the VCA master and collects information on session load from the secondary VCAs in the cluster (VPN3000_A and VPN3000_C).

8.

Once VPN3000_A recovers and rejoins the cluster, the new master VCA (VPN3000_B) redirects IPSec VPN tunnel negotiations to VPN3000_A, since it has the lowest load in the cluster.

It is important to observe the behavior of the cluster upon failure of one of the concentrators. Were this to occur, a DNS-based round-robin session load balancing alternative would continue to evenly load balance sessions across the concentrators in the cluster, unaware that VPN3000_A is vastly underutilized after it recovers in Step 8, described above. Using the VCA protocol, VPN3000 concentrators can make this distinction and therefore have enough load-balancing intelligence to assign IPSec client sessions to the underutilized concentrator until its load is roughly equal to that of the other concentrators in the cluster.

IPSec Session Load-Balancing Using External Load Balancers Using an external load balancer to distribute IPSec VPN sessions to their corresponding concentrator could prove to be a useful design choice when VPN clustering is not an option. As VPN Concentrator clustering is only supported on VPN3000 Series Concentrators, this design scenario could present itself when another brand of concentrator is selected. Figure 5-17 shows a sample topology that uses a Content Switch Module (CSM)in the 6509 switch facing the VPN concentrators.

Load Balancing, Load Sharing, and High Availability

Figure 5-17

231

Load Balancing IPSec VPN Sessions with External Load Balancers

7206VXR-VPNA

Session #1

IPSec_ClientA

Concentrator_A IPSec_ClientB

Session #2

Concentrator_B

ISP

Si

C6509-Edge Content Switch Module

7206VXR-VPNB

IPSec_ClientC

Session #3

Concentrator_C

The content switch module in Figure 5-17 is distributing IPSec VPN sessions to the concentrators behind it in a round-robin fashion. Unlike a cluster of VPN3000 concentrators running the VCA protocol, the CSM will not normally query the concentrators behind it for detailed session-load information unless a script is executed on the concentrator instructing it to do so. Instead, the CSM will only query the concentrator for its operational state using ICMP probes. The 6500 CSM does support scripting languages, such as TCL, which could be used to instruct the CSM to query (for example, with SNMP) the concentrators for information on their current session load, which in turn could be used to execute the load-balancing decision on the next inbound IPSec VPN session. WARNING Although the CSM does allow administrators to write scripts that could be used for inbound IPSec session load balancing, support for this solution is severely limited. Additionally, the configuration, maintenance, and operation of this solution are all far more difficult than that of virtual clustering with VPN3000 series concentrators and ASA5500 VPN appliances.

TIP The CSM supports scripting languages, such as TCL, that could be used to configure the CSM to query (for example, with SNMP) the concentrators for their tunnel load. The CSM could then use that information to load-balance the inbound IPSec VPN tunnels across the VPN concentrators behind the CSM. Although this presents a viable alternative to session load balancing, using VCA clustering on the VPN3000s is the best supported solution for dynamic session load balancing on VPN3000 IPSec VPN concentrators and ASA5500 VPN appliances.

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 five very broad components of IPSec VPN HA that should be explored when designing HA into an IPSec VPN deployment: ■

Network redundancy

■

Termination redundancy

■

Path availability mechanisms

■

Path symmetry mechanisms

■

Load balancing alternatives

This chapter ties in with various topologies discussed in previous HA discussions, and the book continues to do so in subsequent HA chapters. There are many different design options for each of the HA categories listed previously in this summary and introduced previously in this chapter. Table 5-2 shows some design concepts that you should be familiar with at this point in the text and the area of HA to which they pertain. Table 5-2

HA Design Summary HA Deployment Option

HA Deployment Category

Advantages and disadvantages of terminating IPSec on multiple interfaces versus terminating IPSec on a Virtual Interface (HSRP/VRRP).

Termination redundancy

IKE Keepalives and Dead Peer Detection—The similarities and differences of each and when to use one or the other.

Path availability

When to use multiple peering statements for tunnel redundancy and when to rely on the underlying RP for tunnel redundancy.

Termination redundancy network redundancy

What load balancing is and where it fits into the IPSec HA paradigm.

Load balancing and HA

Summary

Table 5-2

233

HA Design Summary (Continued) HA Deployment Option

HA Deployment Category

Encrypted RPs and GRE Keepalives—Why they are useful and the associated packet and performance overhead.

Path availability

BGP and IGPs with Unicast Neighbors—When they are a useful design alternative to encrypted RPs.

Path availability

How RRI, RP Metrics, and HSRP can all be used to abate IPSec control plane issues with path asymmetry.

Path symmetry

DNS-based IPSec load balancing, RP-based IPSec load balancing, IPSec load balancing alternate with peering statements, VPN3000 clustering with VCA, and IPSec load balancing with external load balancers: What each method requires, the advantages/disadvantages of each, and when to consider each design option.

Load balancing and HA

The ensuing chapters discuss these design concepts in greater detail, including configuration and troubleshooting steps. Each subject is presented in the context of local High Availability (Chapter 6, “Site-to-Site Local HA Solutions”) and geographic High Availability (Chapter 7, “Site-to-Site Geographic HA Solutions”). Many of the IPSec HA design options introduced in this chapter, such as VPN3000 clustering, pertain to RAVPN environments. The HA discussions in Chapter 9, “Remote Access VPN High Availability,” focus solely on RAVPN environments.

CHAPTER

6

Solutions for Local Site-to-Site High Availability As we discussed in Chapter 5, “Designing for High Availability,” there are many ways to design for High Availability (HA) in IPsec virtual private network (VPN) designs. One critical design goal in an IPsec VPN requiring HA is to ensure that elements local to the VPN endpoint are designed with the required amount of redundancy. In this chapter, we will discuss those design alternatives available locally on the router, otherwise known as “local IPsec HA.” During our discussion, we will explore the advantages and disadvantages of each design, and we will wrap up with a summary comparison of those local HA design techniques previously discussed.

Using Multiple Crypto Interfaces for High Availability It is very common for a networked IPsec VPN endpoint in a site-to-site deployment to have multiple interfaces available for IPsec configuration. One technique that can be used for local HA is to employ the use of multiple, redundant crypto interfaces in the IPsec VPN design. There are both advantages and disadvantages to leveraging this approach to IPsec local HA. Before we explore those advantages and disadvantages, let us first have a look at the failover process involved when activating multiple crypto interfaces for HA while exploring the simple site-tosite layout shown in Figure 6-1. Figure 6-1

Multiple Crypto Interface Configurations for IPsec HA Primary Link between Se0/0 Fails

4

Primary Link between Se0/0 Restored

6

4 6

1 ESP

5

6

Serial0/0 = 200.0.0.1

Network_A

Network_B

Serial0/0 = 200.0.0.2

Serial0/1 = 200.0.0.3

201.1.1.0/24

202.1.1.0/24

Serial0/1 = 200.0.0.4

Router_A

Router_B Redundant ESP Tunnel

3 7

7 3

2

3

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 traffic over the redundant link between Router_A (Se0/1) and Router_B (Se0/1).

3.

The traffic from Step 2 matches the crypto ACL applied to the crypto map of the redundant interface on Router_A (Se0/1), thereby triggering ISAKMP, and subsequently IPsec, SA negotiation.

4.

If the primary link remains down longer than the negotiated SA lifetimes, and if IKE keepalives are disabled, the original, primary, ISAKMP, and IPsec SAs time out.

TIP The use of IKE keepalives can enable the teardown of obsoleted SAs such as in Step 4 (and later in Step 7 of this example). If IKE keepalives were enabled on Router_A and Router_B, the routers would not have to wait the duration of the negotiated SA lifetime to tear down the SAs, even if they are not in use.

5.

When the primary link is restored, the routing protocol on Router_A and Router_B reconverges such that traffic is now once again routed over the link between Router_A (Se0/0) and Router_B (Se0/0).

6.

The re-routed traffic in Step 5 matches the crypto ACL of the crypto map applied to the primary interface of Router_A (Se0/0), thereby triggering another negotiation of ISAKMP and IPsec SAs.

7.

If the primary link stays up for longer than the negotiated SA lifetimes, and IKE keepalives are disabled, the ISAKMP and IPsec SAs established in Step 3 time out.

The use of crypto maps on redundant interfaces represents the most basic form of local HA available today. As one can tell from the preceding process, IPsec failover relies heavily on the reconvergence of the underlying routing protocol that the IPsec VPN tunnel is built on. Although this design is simple to deploy and to configure, there are quite a few ways to tune the process to fail over quicker. The failover scenario of Figure 6-1 and Example 6-1 describes the most simplistic, untuned way of providing local HA. The ISAKMP configuration on Router_A and Router_B must be capable of using matching preshared keys with both peers. Router_A’s configuration, which is displayed in Example 6-1, would not only need to use the key “cisco” with 200.0.0.2 as the primary, but also with the redundant peer—200.0.0.4. Router_A’s crypto map configuration, also displayed in Example 6-1, uses redundant peer definitions within the same crypto map. If the first peer is unavailable, Router_A will use 200.0.0.4. This configuration is well suited for this environment

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). Example 6-1

Local IPsec HA Using Separate Physical Interfaces

Router_A# show running-config ! ! crypto isakmp policy 10 encr 3des authentication pre-share crypto isakmp key cisco address 200.0.0.2 crypto isakmp key cisco address 200.0.0.4 crypto isakmp keepalive 10 ! crypto IPsec transform-set chap6-dualint esp-3des esp-sha-hmac ! crypto map chap6-dualint 10 IPsec-isakmp set peer 200.0.0.2 set peer 200.0.0.4 set transform-set chap6-dualint match address 101 reverse-route ! ! interface Serial0/0 no ip address no fair-queue crypto map chap6-dualint ! interface Serial0/1 no ip address no fair-queue crypto map chap6-dualintT ! ! access-list 101 permit ip 201.1.1.0 0.0.0.255 202.1.1.0 0.0.0.255

Let us take a look at some of the areas of this process that present opportunities for improvement and introduce some available design solutions: ■

Routing protocol reconvergence

■

Stale security associations

■

IKE and IPsec SA renegotiation

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 traffic be inspected by the crypto access list of the interfaces’ crypto map before the new ISAKMP and IPsec SAs can be negotiated. Because of this, the availability of this design will directly depend on, among other things, the speed of RP reconvergence. With Cisco IOS, RP timers can be tuned to maximize the speed of reconvergence, resulting in faster failover to the redundant IPsec VPN tunnel. NOTE The discussion of RP timers is relevant to our discussion only in that speedy RP reconvergence times aid IPsec tunnel failover times. The subject is otherwise outside the scope of this publication. Tuning RP timers in an enterprise network produces an extremely large variety of effects beyond what we have discussed in relation to IPsec. For this reason, extreme caution should be exercised when altering RP timers in a network.

In some instances, it may make sense to use floating static routes to expedite IPsec local HA even further. The floating static route approach describes a situation in which a static route is installed in the configuration with a higher administrative distance than an identical dynamically learned route. If that dynamically learned route is somehow removed from the routing table, then the floating static route is immediately installed. Additionally, floating static routes are simple to deploy, and they require less overhead. For these reasons, it may make sense in a network design to employ them in lieu of a full RP-based failover solution. One such popular instance in which floating static routes are commonplace is in highly available IPsec branch offices. Figure 6-2 illustrates the failover process of an IPsec HA branch failover scenario. Example 6-2 illustrates the configuration of a floating static route on Branch_6A. Note in the configuration provided in Example 6-2, Ent_Main4a is using the loopback interface of Branch_4a to authenticate Phase 1 SAs and to negotiate Phase 2 SAs. Therefore, if Ent_Main4a is unable to effectively and rapidly route to that loopback interface, neither Phase 1 nor Phase 2 negotiations will complete successfully. Floating static routes can be used as follows to provide a means for rapid failover in this scenario: With floating static routes, the routing table does not need to wait on an update from Branch_4a to install the route to 10.1.1.4. Instead, the floating static route is immediately installed after the route with a lower admin distance is lost, thereby aiding the speed of reconvergence in the overall failover of the IPsec VPN tunnel. Like Ent_Main4a, Branch_4a uses a floating static route for failover of its IPsec tunnel. This allows Branch_4a to immediately renegotiate Phase 1 and Phase 2 SAs with Ent_Main4a without waiting for establishment of an RP adjacency and receipt of an RP update across the redundant link, thus trimming down the time it takes for the IPsec VPN to reconverge over the redundant path. Note in Example 6-2 the admin distance of 254 on this static route. Once the primary link is restored and an RP update with a lower admin distance is received over that path, that route will overwrite the static route in Branch_4a’s routing table.

Using Multiple Crypto Interfaces for High Availability

239

Floating Static Routes and IPsec Tunnel Failover

Figure 6-2

Call Manager

SMTP

WWW

FTP

Campus_Net 10.0.0.0/16 Ent_Main4A

Lo192 = 10.1.1.1/32

Floating Static Route to Branch_4A

Main IPSec Tunnel

Secondary IPSec VPN Tunnel Floating Static Route to Ent_Main4A

Lo192 = 10.1.1.4/32

Branch_4A

Branch4A_Net 10.1.4.0/24

IP

Example 6-2

IP

IP

IP

IP

Using Floating Static Routes for Fast IPsec HA Failover

hostna me Ent_Mai n4A ! ! cry pt o i sakmp key c isco addres s 10.1.1.4 ! !

continues

240

Chapter 6: Solutions for Local Site-to-Site High Availability

Example 6-2

Using Floating Static Routes for Fast IPsec HA Failover (Continued)

crypto map chap6- hainterfa ce 10 ip sec-isakmp crypto map chap6 -hainterfa ce lo cal -address loop back10 se t peer 1 0.1.1.4 set transf orm-set chap6-hai nterface ! ! ip rou te 10.1.1. 4 255. 2 55.255.255 200.1.1.6 25 4 ip rou te 10.1.4.0 255.255. 255.0 20 0.1.1.6 254 hostna m e Branch_4a ! ! crypto i sak mp key cisco addr ess 10.1 .1 .1 ! ! crypto m ap chap6-h ai nterfac e local-add ress lo opback10 crypt o map chap6 - haint erface 10 ipsec-isak mp set peer 10.1.1.1 set tra nsform-set chap6-haint e rface ! ! ip route 0.0.0.0 0.0.0.0 20 0.1.1.5 254

Now that we have briefly discussed the motivators for using floating static routes in local IPsec HA scenarios, we will consider the disadvantages of such a design that arise as the scale and complexity of the network increases. There are many situations in which floating static routes may not be a viable option. For example, a large routed domain between the VPN endpoints rather than a single Layer-3 hop (as is the case in Figure 6-1 and Figure 6-2) could make the use of static routes difficult to scale and manage. While floating static routes have design advantages in simple local IPsec HA deployments, a full RP-based approach to IPsec HA is recommended as the scale of the network increases.

Impact of Stale SAs on IPsec Reconvergence When new SAs are negotiated, the old (stale) SAs are not automatically reaped from the SADB. If IKE keepalives are not enabled, therefore, stale SAs can remain in for the duration of their original lifetime. As we have discussed in Chapter 4, “Common IPsec VPN Issues,” stale IPsec and ISAKMP SAs can cause problems in IPsec VPNs. As we will see later in this section when discussing stateful and stateless IPsec HA solutions, stale SAs must be removed in order for an IPsec tunnel to fail over to its redundant peer. IPsec HA mechanisms therefore rely on IKE keepalives to reap stale SAs left in the SADB upon failover so that new SAs can be negotiated with the redundant peer. Improper handling of stale SAs can therefore lead to increased convergence times, or in some cases the inability to failover to a redundant peer in HA environments.

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 traffic is forwarded matching a configured Crypto ACE on that interface’s crypto map. This adds another layer of delay to the failover process, presenting us with another opportunity for optimizing local IPsec HA design. This hurdle for failover to a redundant IPsec VPN tunnel is inherent to a “stateless” failover. However, because we are currently speaking only of local HA solutions, this failover can be mitigated by sourcing updates from a highly available address (such as a loopback address) rather than the physical interface itself. In doing so, the original IPsec and ISAKMP SAs are preserved, and the failover time is limited to RP reconvergence across the redundant physical link. Consider once again the HA IPsec branch scenario in Figure 6-2. The branch and hub now use loopback64 to initiate/terminate the IPsec tunnel. Recall that Branch_4A uses a floating static route for Layer-3 redundancy to minimize failover delay attributable to RP reconvergence. Additionally, Branch_4A and Ent_Main4A use their loopback interface for IPsec tunnel termination. This method removes the dependency of the physical interface state to maintain the local state of IPsec. Therefore, Branch_4A can now fail over without having to renegotiate IPsec and ISAKMP SAs. NOTE It is important to note that when the RP fails, the hub in this case will not know how to get to the branch loopback interface. The loopback interfaces must be able to communicate in order for the IPsec tunnel to come up, because they are the precise endpoints used to terminate the tunnel. Note that in Figure 6-2 and Example 6-2, there are two floating static routes on Hub_Main4A—one to establish connectivity between the loopback interfaces for IPsec failover and another to establish connectivity to the actual branch network (“Branch4A_Net” of Figure 6-2).

Example 6-3 illustrates a configuration in which IPsec and ISAKMP are sourced and terminated on highly available (loopback) interfaces. In this case, Branch_4a uses the highly available loopback interface of Ent_Main4a to identify the peer to use the key “cisco” with when authenticating Phase 1 SAs. Alternatively, Branch_4a could have been configured to share the key with a hostname, such as “Ent_Main4a”, to accomplish the same thing. Branch_4a also uses the loopback interface as the termination point for the IPsec VPN tunnel. Because the IP address 200.1.1.5 is available to Branch_4a over either WAN link to Ent_Main4a, this separates the availability of the IPsec VPN tunnel from the availability of any one given physical interface, thereby providing a means of local HA between Branch_4a and Ent_Main4a.

242

Chapter 6: Solutions for Local Site-to-Site High Availability

Example 6-3

IPsec Tunnel Termination to Highly Available Interfaces

hostna me Branch_4 A ! ! crypto isakmp key cisco add ress 200. 1.1.5 crypt o isakmp k eepalive 1 0 ! crypto map ch ap6-ha interface local-addr ess loopb ack10 crypto ma p cha p6-hainterf ace 10 IPse c-isakmp set p eer 200.1. 1.5 set transf orm-set cha p 6 -hainterfac e match addr ess 101

Now that we have introduced some of the basic challenges with IPsec tunnel failover in HA environments and discussed some of the basic concepts of designing resiliency into the local design of the IPsec VPN, we will look at some of the more robust alternatives to HA design. We will begin our exploration of these HA design concepts by discussing a prevalent improvement to the “stateless” HA designs previously discussed in this chapter. Following our discussion of stateless HA concepts and solutions, we will discuss the concept of “stateful” HA design requirements and some effective solutions for IPsec Stateful HA VPNs.

Stateless IPsec VPN High-Availability Alternatives Stateless IPsec VPN HA refers to a scenario in which the state of a given Phase 1 or Phase 2 SA is not replicated to another separate, redundant IPsec device. In this section, we will discuss solutions for providing a highly available VPN design using stateless mechanisms, specifically HSRP/VRRP (Hot Standby Router Protocol/ Virtual RRP) for termination of the IPsec VPN tunnel and Reverse-Route Injection for keeping routing protocol information consistent between the two private routing domains that use the IPsec VPN tunnel for confidential communications between them.

Solution Overview for Stateless IPsec High Availability The stateless local IPsec HA design in this chapter uses the simple network topology depicted in Figure 6-3 to illustrate the required underlying concepts.

Stateless IPsec VPN High-Availability Alternatives

243

Stateless Local IPsec High Availability Topology

Figure 6-3

Cleartext Routed Domain D

Ciphertext Routed Domain

10.0.0.0//8

200.1.0.0/16

Cleartext Routed Domain A

C7206VXR-STANDBY (Standby HSRP Router)

192.168.1.0/24 10.0.0.0/8 2651XM-VPNA VPN Gateway el

PN

V Sec

IP

HSRP Virtual Interface

n Tun

Public Routed Domain

IPSec VPN Tunnel

Cleartext Routed Domain B 192.168.2.0/24 10.0.0.0/8 2651XM-VPNB VPN Gateway

IPS

ec

VPN

Tun n

el

192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 C7206VXR-MAIN (Primary HSRP Router)

Cleartext Routed Domain C 192.168.3.0/24 10.0.0.0/8 2651XM-VPNC VPN Gateway

In any stateless IPsec HA design, there are two key objectives that must be achieved. Objective 1: Highly Available Termination—The termination of the IPsec VPN tunnel must be highly available to the peering IPsec VPN gateway. This peering alternative must be adequate in reducing latency in IPsec VPN reconvergence attributable to RP reconvergence. The termination point should also eliminate any one physical device (this could be an interface or the gateway itself) as a single point of failure in the design. The primary solution is to use a virtual interface to terminate the IPsec tunnel. HSRP or VRRP can be deployed to provide a virtual interface common to one or more physical devices. Using an HSRP or VRRP virtual interface as the endpoint of an IPsec VPN tunnel preserves routing protocol information in the protected routed domain, eliminating latency attributable to the reconvergence of the routing protocol on the protected side of the VPN. This solution provides a design alternative when a single physical point of failure in the VPN network topology is unacceptable. NOTE While terminating an IPsec VPN tunnel on virtual interface precludes RP reconvergence from stalling IPsec VPN reconvergence, the HSRP or VRRP failover timers can stall IPsec VPN failover in such a scenario. We will discuss latency associated with these timers and how to minimize this latency later in this chapter.

Objective 2: Layer-3 Continuity across the IPsec VPN Tunnel—As we have discussed in previous chapters, most RP updates are multicast-based. For this reason, they cannot be tunneled through an IPsec VPN without encapsulating them in GRE prior to their inclusion in the crypto

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 configured for RRI, it injects routing information backwards into the protected routed domain upon successfully negotiating an IPsec SA. In this scenario, C7206VXRMAIN (or potentially C7206VXR-STANDBY) injects a static route for VPN-2651XM’s protected IP address space backward into the enterprise network routing domain, as illustrated in Figure 6-3. Hot Standby Routing Protocol Hot Standby Routing Protocol (HSRP) provides a virtual interface that can be shared between two redundant routers. There are two main components of the HSRP protocol: ■

The creation of a virtual interface inclusive of a virtual MAC address residing on the same broadcast domain as the two physical redundant interfaces (at least one physical interface on each router in the HSRP group).

■

The communication of interface state and priority between each router with a physical interface in the HSRP group. This exchange is facilitated with the use of HSRP Hello messages sent to the all routers multicast destination address (224.0.0.2).

These two components work together to create a virtual interface that represents two or more physical interfaces on the same broadcast domain, addressed on the same subnet. In this section, we will describe a method of IPsec HA that uses this virtual interface to provide a stateless method of redundancy. NOTE This chapter discusses HSRP and VRRP in the context of IPsec HA only. For more detail on the operation of the Hot Standby Router Protocol (HSRP), refer to the following URL on CCO: http://www.cisco.com/en/US/partner/tech/tk648/tk362/tk321/tsd_technology_support_subprotocol_home.html Also note that we will only discuss HSRP IPsec HA alternatives, because many of the features required for stateless and stateful IPsec HA are Cisco proprietary features that work only on HSRP. For standards-track virtual interface capability, refer to the IETF’s Virtual Router-Router Protocol charter: http://www.ietf.org/html.charters/vrrp-charter.html IPsec VPN tunnel termination on an HSRP interface eliminates a single point of failure in the IPsec VPN design. Consider the layout illustrated in Figure 6-3. In a nonredundant site-to-site VPN, 2651XM-VPNA would establish Phase 1 and Phase 2 SAs with only one endpoint. In this scenario, redundancy has been built into the design on cleartext routed domain A. Because of this, any device terminating an IPsec VPN tunnel at cleartext routed domain “a,” such as 2651XMVPNA, would have the benefit of an HSRP-based redundant termination point.

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. TIP Recall that without the use of IPsec+GRE, multicast traffic, inherent to the operation of many routing protocols, cannot be passed across the VPN. When a fully dynamic exchange of RP information is required, consider tunneling the routing protocol traffic through the VPN using GRE. This deployment is discussed in greater detail in Chapter 3, “Basic IPsec VPN Topologies and Configurations.”

RRI RRI can be deployed to maintain consistency between routed domains over an IPsec VPN tunnel when RP updates and hellos cannot be exchanged across the IPsec VPN tunnel. RRI does this by automatically injecting routes backward into the cleartext routing domain upon negotiation of a Phase 2 IPsec SA. Consider again the topology described in Figure 6-3. When 2651XM-VPNA completes Phase 2 SA negotiation with the redundant HSRP pair of 7200VXRs on cleartext routed domain “D,” the active HSRP router of the pair (in this case C7206VXR-MAIN) injects RRI-learned static routes to cleartext routed domain “A” into C7206VXR-MAIN’s routing table. RRI accomplishes this by inspecting the IP address space to be included in the crypto switching path, as defined by the crypto ACLs configured on each peer. Remember that in order for an IPsec Phase 2 SA to be negotiated correctly, the protected address space defined in the ACLs on each peer must match. C7206VXR-MAIN is configured to redistribute these RRI-learned static routes into the IGP of cleartext routed domain “A.” NOTE For more information on protected address space definition and the impact of crypto ACL mismatches on Phase 2 SA negotiation, refer to Chapter 3, ”Basic IPsec VPN Topologies and Configurations.”

After a Phase 2 SA is negotiated, RRI inspects the crypto-protected address space that the two VPN endpoints have agreed on and entered in the SADB. The VPN endpoints create static routes for the corresponding address space agreed upon in Phase 2 negotiation and entered in the SADB. TIP VPN routes created by RRI appear as static routes, but they can be injected into a dynamic routing protocol using the redistribute static command under the Routing Protocol subconfiguration menu.

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 confidential and are therefore passed in ciphertext across a ciphertext routed domain. Figure 6-4 illustrates this topology. Step-by-Step Stateless Local IPsec HA Failover.

Figure 6-4

Cleartext Routed Domain D

Ciphertext Routed Domain

10.0.0.0/8

200.1.0.0/16

C7206VXR-STANDBY (Standby HSRP Router)

Cleartext Routed Domain A

5

192.168.1.0/24 10.0.0.0/8

1 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24

2651XM-VPNA VPN Gateway

nel

Sec

un NT

VP

IP

6

Public Routed Domain 1

IPSec VPN Tunnel

4

Cleartext Routed Domain B 192.168.2.0/24 10.0.0.0/8 2651XM-VPNB VPN Gateway

IPS

ec

VPN

Tun n

el

192.168.1.0/24 192.168.2.0/24 192.168.3.0/24

Cleartext Routed Domain C 192.168.3.0/24

1 10.0.0.0/8

2

3

HSRP Virtual Interfaces

C7206VXR-MAIN (Primary HSRP Router)

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

2651XM-VPNC VPN Gateway

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 firm decide to deploy stateless HA at cleartext routed domain D. The configuration of the gateways on domains A, B, and C are config-ured normally for site-to-site connectivity, with one exception—the remote peer is defined as the HSRP virtual IP address of the redundant pair of IPsec VPN gateways at cleartext routed domain D. The key thing to remember in this step is that the single point of failure at cleartext routed domain D is eliminated by this solution. This provides IPsec HA at the terminating peer for confidential communications used by domains A, B, and C. Again, the only configuration change required on the VPN gateways in domains A, B, and C is to define the HSRP standby IP address of domain D as the remote IPsec peer and, if using preshared keys for Phase 1 negotiation, ensure that the appropriate ISAKMP preshared key is used with that IP address. Example 6-4 provides the configuration of an IPsec branch router, 2651XM-VPNA, in the network topology illustrated in Figure 6-4. The branch router is configured to share its ISAKMP key with 200.1.2.1, the HSRP virtual interface of C7206VXR-MAIN and STANDBY so that either router can complete Phase 1 negotiations with 2651XM-VPNA. 2651XM-VPNA is also configured to use the HSRP virtual interface of C7206VXR-MAIN and STANDBY to terminate the IPsec tunnel. This allows 2651XM-VPNA to terminate the IPsec VPN tunnel on either C7206VXR-MAIN or STANDBY, thereby taking full advantage of the stateless IPsec HA configuration in cleartext routed domain D. RRI is used to dynamically inject an IP route for cleartext routed domain D into cleartext routed domain A. RRI accomplishes this by dynamically creating static routes to 10.0.0.0/8 on 2651XM-VPNA upon successful negotiation of an IPsec SA. The RRI-learned routes are manually redistributed into the RP on 2651XM-VPNA and are subsequently propagated throughout cleartext routed domain A. This provides network elements in cleartext routed domain A the ability to route IP packets to target destinations on cleartext routed domain D. Example 6-4

Branch Configuration for Stateless IPsec HA

hostna me 2651XM- VPNA ! ! cry pto is akmp key ci sco addr e ss 200.1.2.1 ! ! crypto map chap6- stateless 1 0 IPsec- isakmp set peer 2 00.1.2.1 set t ransform-se t chap6- state less match a ddress 101 reverse-route

248

Chapter 6: Solutions for Local Site-to-Site High Availability

To support the stateless HA configuration at domain D, HSRP must be configured on interfaces facing the remote branches A, B, and C in order to provide a virtual IP address that the VPN gateways on A, B, and C can terminate their IPsec VPN tunnels on. Example 6-5 shows the configuration additions required of C7206VXR-MAIN and C7206VXR-STANDBY needed to support HSRP-based termination of the IPsec VPN tunnels inbound from 2651XM-VPNA, 2651XM-VPNB, and 2651XM-VPNC. Example 6-5

Aggregator (C7206VXR-MAIN and C7206VXR-STANDBY) Configuration on Cleartext Domain D for Stateless IPsec HA

hostna me C7206VXR -MAIN ! ! cr y pto isakmp keepalive 1 0 ! ! crypto map chap6 -statele ss 10 ip sec-isakmp s et p ee r 200.1.1. 1 set tra nsfor m-set chap6 -stateless ma t ch address 101 r everse-r out e ! cryp to map chap 6-sta teless 2 0 ipsec-isa kmp se t peer 200 .1.1.5 set tran s form-set ch ap6-statel ess m atch addre ss 102 rever se -route ! crypto map chap6- stateles s 30 ipsec- isakmp set peer 200.1 .1.9 set transf orm-set ch ap6-state less match add ress 103 re ve rse-route ! interfa ce Fas tEthernet 0/0 ip address 20 0.1.2.11 2 55.255.255. 0 ip directed -broadcast speed a uto half -duplex standby 1 ip 200.1.2 .1 sta ndby 1 p reem pt st andby 1 nam e cha p6-vpnha st andby 1 tr ack F astE thernet0/1 75 ! acce ss- list 101 permit ip 10.0.0 .0 2 55.0.0.0 192. 168.1.0 255.255.255 .0 access- list 1 02 permit ip 10.0.0. 0 255 .0.0.0 1 92.168.2.0 25 5.25 5.2 55.0 access -list 103 pe rmi t ip 10.0. 0.0 255.0.0.0 192.168.3 .0 255.255.25 5. 0 crypt o map chap6 -state less redun dancy chap6-v pnh a

Stateless IPsec VPN High-Availability Alternatives

Example 6-5

249

Aggregator (C7206VXR-MAIN and C7206VXR-STANDBY) Configuration on Cleartext Domain D for Stateless IPsec HA (Continued)

hostna me C7206VX R-STANDBY ! ! crypt o isakmp ke epalive 1 0 ! ! crypto map chap6-stat eless 1 0 ipsec-isakm p se t peer 200. 1.1.1 set trans form-set ch ap6-stateles s match addr ess 101 revers e -route ! crypto ma p chap6- statel ess 20 ipsec -isakmp s et peer 20 0.1.1.5 s et t ra nsform-set chap6-state l ess match add ress 102 re verse-route ! crypt o map cha p6-stat eless 30 ip sec-isa kmp set peer 2 00.1.1.9 set tr ansform-se t chap6-st atele ss match address 103 reverse-r oute ! ! i nterface FastEthern et0/0 i p addre ss 2 00.1.2.12 255.255.255 .0 ip directed-b roadcast speed au to half-du plex st a ndby 1 ip 2 00.1.2.1 stan dby 1 preempt standby 1 n ame chap6-v pnha crypto ma p chap6-st ateless red undan cy c hap6-vpnha ! access -lis t 101 per mit ip 10.0 .0.0 255 .0.0.0 192.16 8.1.0 255. 255.255.0 access-lis t 102 permit ip 1 0.0.0.0 255.0 . 0.0 192. 168.2.0 255.2 55.2 55 .0 access- list 103 p ermit ip 10.0.0.0 255 .0.0.0 19 2.168.3.0 25 5.255.255.0

Example 6-5 provides the configuration of the redundant headend routers performing IPsec VPN tunnel aggregation for the branches. IKE keepalives are the primary means by which to notify the crypto engine that the IPsec SAs previously established are no longer valid and must be torn down. After three keepalives are missed, the crypto engine will tear down Phase 1 and Phase2 SAs with its peers, allowing the remote peers to rebuild those SAs with the redundant gateway,

250

Chapter 6: Solutions for Local Site-to-Site High Availability

C7206VXR-STANDBY. Line 4 of the configuration enables the use of IKE keepalives on C7206VXR-MAIN. IKE keepalives are also configured on C7206VXR-STANDBY, as shown in line 42 of the configuration, so as to allow C7206VXR-MAIN to preemptively assume active HSRP router responsibilities when a failure has been restored. C7206VXR-MAIN uses HSRP to present a highly available virtual interface for branch routers to terminate their IPsec VPN tunnels on. The HSRP standby interface is also the IP address that the IPsec VPN tunnel will be sourced from on C7206VXR-MAIN or C7206VXR-STANDBY, depending on which of the two is the active HSRP router. The IPsec and ISAKMP preshared key peering statements on 2651XMVPNA, 2651XM-VPNB, and 2651XM-VPNC must be configured to use this interface to take advantage of the stateless IPsec HA configuration between redundant peers C7206VXR-MAIN and STANDBY. Tracking other interfaces on the router allows HSRP to fail over based on downstream information. In this scenario, C7206VXR-MAIN tracks Fa0/1. If the tracked interface fails, HSRP decrements its priority by 50. C7206VXR-STANDBY then recognizes the priority change, further realizing that its priority is higher (75 > 50) and forcing C7206VXRSTANDBY 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, chap6stateless, for IPsec HA. This instructs the crypto engine to bind crypto information to the HSRP information for stateless IPsec HA. For example, the IPsec processes on C7206VXR-MAIN and STANDBY need to know to use the standby address (200.1.2.1) for tunnel termination and origination rather than the physical IP address of 200.1.2.11 and 12, respectively. Without referencing the HSRP standby name in the crypto map, the default behavior of peering directly from the physical interface IP would occur, effectively negating the benefits of HSRP-based stateless IPsec HA. The crypto map, “chap6-stateless”, is applied to the physical interface configured for redundancy with HSRP. Note that this interface is configured to automatically inject routing information backwards in to cleartext routed domain D using RRI. Example 6-5 also includes the configuration for the redundant router providing stateless IPsec HA, C7206VXR-STANDBY. C7206VXR-STANDBY’s crypto map is identical to that of C7206VXRMAIN. Note that it too uses RRI to update routing protocol information for cleartext routed domain D. This will happen only when HSRP and IPsec both fail over to C7206VXR-STANDBY. The physical interface configured for redundancy using HSRP is located on the same subnet as C7206VXR-MAIN. Many of the HSRP and IPsec parameters configured are identical between C7206VXR-MAIN and STANDBY, such as the crypto transform sets used, ISAKMP parameters, and HSRP standby interface IP addresses. Others are different, such as interface tracking configuration—C7206VXR-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.

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 configured for RRI, which occurs in this step. RRI determines what routes to inject backwards into the appropriate routing domain by inspecting the protected address space negotiated in Phase 2 and entered in the IPsec SADB. Example 6-6 shows the output of C7206VXR-MAIN, which is the active HSRP router terminating an IPsec connection for 2651XM-VPNA. Before taking any steps to verify the crypto operation, HSRP operation is confirmed to be operating correctly, as shown in lines 1–16 of Example 6-6. As C7206VXR-MAIN is the active HSRP router (confirmed in lines 3 and 4 of Example 6-6), it will also actively assume responsibilities for terminating Phase 1 and Phase 2 SAs with its remote peers. The output from C7206VXR-MAIN SADB shows the current ISAKMP and IPsec SAs associated with 2651XM-VPNA. The standby IP address that remote peers will use for IPsec tunnel termination is shown in line 5. According to the output listed in line 10, C7206VXR-MAIN will attempt to preempt other interfaces in the HSRP group to become the active router whenever a priority change is detected within the group. Therefore, C7206VXR-MAIN will take advantage of preemption to resume active router responsibilities once a failure has been repaired on C7206VXR-MAIN Fa0/0 or Fa0/1. C7206VXR-MAIN will track Fa0/1 and Lo10, and will decrement the default priority of 100 by 75 (yielding a priority of 25). When C7206VXRSTANDBY detects this (it is configured to preempt), it will take over as the active router for the HSRP group, as its priority of 50 is greater than C7206VXR-MAIN’s new priority of 25. Also, C7206VXR-STANDBY will also take over as the IPsec tunnel termination point for 2651XMVPNA, 2651XM-VPNB, and 2651XM-VPNC once the appropriate amount of IKE keepalives are missed and new Phase 1 and Phase 2 SAs are negotiated. Note that the source IP address listed for the IPsec SAs in lines 21 and 22 is identical to the HSRP standby IP address listed in line 5. Lines 19–22 therefore confirm that C7206VXR-MAIN is actively terminating IPsec VPN tunnels on the standby IP interface for the appropriate HSRP group. Example 6-6

C7206VXR-MAIN IPsec SADB before HSRP Failover

C7206V XR-MAIN#sh ow standby Fa stEthernet 0/0 - Group 1 State is A ctive 14 s t ate changes, last state c hange 2 d13h Virtual I P add ress is 200.1.2. 1 Active virtual MAC addre ss is 00 0 0.0c07.ac01 Lo cal virt ual M AC address is 0000.0c 07.ac01 (v1 default) Hell o time 3 sec, ho ld time 1 0 sec Next h ello sent i n 0.276 s ecs Pre emption en a bled

continues

252

Chapter 6: Solutions for Local Site-to-Site High Availability

Example 6-6

C7206VXR-MAIN IPsec SADB before HSRP Failover (Continued)

Active ro uter is lo cal St a ndby router is 200.1.2 .1 2, pri ority 50 (ex pires i n 7.840 sec ) Priority 100 (defaul t 100) Track int e rface Fa stEthernet 0/1 sta te Up decreme nt 75 Track int erface Loo pback10 sta te Up decre ment 75 IP redu ndancy name is “c hap6-vpn ha” (cfgd) C72 06VXR-MAIN #s how crypto eng ine connect ions active ID Interfa ce

IP-Add ress

State

Algo rithm

8 Fa stEth ernet0/0

200. 1. 2.11

se t

HMAC_SHA +3DES_56 _C

Enc rypt 0

Decrypt 0

200 1 FastEthe rnet0/0

200.1.2.1

set

3DES+SHA

4

0

2 002 FastE therne t0/0

2 00.1.2.1

set

3 DES+SHA

0

4

C72 06VXR-MAI N#

Note here that there will be reconvergence delay attributable to reconvergence of the routing tables on either side of the IPsec tunnel. The convergence delay of the IPsec design attributable to RP reconvergence can vary greatly based on a large number of variables, such as the routing protocol used, the size of the routing table, the configuration of RP timers, and the platforms selected to perform the routing functionality, among others. Because of this, within the context of this work, we will consider the total system failover time to include RRI but not system-wide RP reconvergence. In your network design, be advised that the reconvergence of routed domains should be analyzed regardless of whether a stateful or stateless IPsec HA design is selected. Note also that in the SADB, C7206VXR-MAIN is instructed to encrypt traffic to 192.168.1.0/24, the address range used cleartext domain A. Because C7206VXR-MAIN does not receive RP updates, which are multicast, across the VPN tunnel, C7206VXR is configured to inject routes in to cleartext domain D using RRI. In Example 6-7, 2651XM-VPNA inserts a VPN route using static RRI as soon as a complete static crypto map is applied to an interface, which, as we will see in Example 6-9, is slightly different from the behavior on C7206VXR-MAIN. Unlike dynamic crypto maps, static crypto maps must have manually defined peering information and completed crypto ACLs to successfully negotiate Phase 2 with a peer. RRI immediately inserts a VPN (static) route for the destination address space in the crypto ACL with a next hop of the peer IP of the IPsec VPN tunnel defined in the crypto map. This is confirmed by the insertion of the VPN (or RRI-learned) route being added (confirmed by line 5) without any IPsec SAs actively present in the SADB (confirmed by lines 10–13). Example 6-7

Verifying RRI for Domain A: RRI with Static Crypto Maps on 2651XM-VPNA

2651XM -VPNA#debug crypto i psec Crypto I PSEC debug gin g i s on ! !

Stateless IPsec VPN High-Availability Alternatives

Example 6-7

253

Verifying RRI for Domain A: RRI with Static Crypto Maps on 2651XM-VPNA (Continued)

*Mar 3 08:16:13.962: IPSEC(rte_mgr): VPN Route Added 10.0.0.0 255.0.0.0 via 200.1.2.1 in IP DE FAUL T TABLE ! ! 2651X M-VPNA#sh ip route s tatic S

10 .0.0. 0/ 8 [1/0] via 200.1.2.1

26 51 XM-VPNA#sh ow crypto e ng ine con nections act ive ID Interface

IP-A ddr ess

Stat e

Algori thm

Encrypt

De crypt

2651X M-VPNA#

Example 6-8 shows the required configuration for RRI on C7206VXR-MAIN and the resulting output from the routing table that shows an RRI-injected route into cleartext domain D for cleartext domain A’s routes upon successful negotiation of a Phase 2 SA between C7206VXRMAIN and C2651XM-VPNA. Unlike static crypto maps, RRI with dynamic crypto maps will not inject routing information until a Phase 2 SA is negotiated. Initially, RRI is configured on C7206VXR-MAIN, but the crypto SADB and IP routing table are both empty, as confirmed by lines 1–4 and lines 5 and 6 of Example 6-8, respectively. When an IPsec SA is negotiated with 2651XM-VPNA (negotiation is also initiated by 2651XM-VPNA), C7206VXR-MAIN learns the tunnel termination endpoint to use on 2651XM-VPNA and which traffic to encrypt dynamically, as shown in lines 14–19. Using this information, C7206VXR-MAIN uses RRI to inject a route into the routing table for cleartext routed domain D, as confirmed in lines 7–15 and in lines 20 and 21. Note that C7206VXR-MAIN has negotiated Phase 1 and Phase 2 SAs with 2651XM-VPNA, providing C7206VXR-MAIN with enough information to create a route for encrypted traffic using RRI. We can now verify that the VPN route appears in the routing table with the correct IP, subnet mask, and next hop, as shown in lines 20 and 21. CAUTION VPN routes injected by RRI appear as static routes and therefore will only exist in the routing table of the RRI-enabled IPsec VPN gateway without the aid of a selected routing protocol. To successfully propagate RRI-learned routes to the routing tables of all networked nodes participating in the routed domain, static routes must be redistributed into the chosen routing protocol.

Example 6-8

Verifying RRI for Domain A: DRI with Static Crypto Maps on C7206VXR-MAIN

C7206V XR-MAIN#sh crypto en gine connecti ons active I D In terface

IP -Address

State

Alg o r ithm

Encrypt

D ecry pt

C7206VXR-M AIN#show ip route static

continues

254

Chapter 6: Solutions for Local Site-to-Site High Availability

Example 6-8

Verifying RRI for Domain A: DRI with Static Crypto Maps on C7206VXR-MAIN (Continued)

debug crypto ips ec C7206VXR-MAIN#d 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 ! ! sh cry pto engine connectio ns active C7206VXR-MAIN#s ID Interface

IP-Address

State

Algorithm

7 FastEthernet0/0

200.1.2.11

set

HMAC_SHA+3DES_56_C

Encrypt 0

Decrypt 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

show i p route st atic C7206VXR-MAIN#s S

192.168.1.0/24 [1/0] via 200.1.1.1

Notice in Example 6-8 that C7206VXR only injects a route for 192.168.1.0/24 into cleartext routed domain D. This is because C2651XM-VPNB and C2651XM-VPNC have yet to negotiate Phase 2 SAs with C7206VXR-MAIN. Once this occurs, C7206VXR-MAIN will inject routes for cleartext routed domains B (192.168.2.0/24) and C (192.168.3.0/24). Step 3: Active Router Failure Once the IPsec VPN SAs are all established between the active HSRP router C7206VXR-MAIN and 2651XM-VPNA, 2651XM-VPNB, and 2651XM-VPNC, assume that C7206VXR-MAIN were to fail for some reason. In a nonredundant environment, all connectivity from cleartext domains A, B, and C to critical resources at cleartext domain D would be lost. Remember, though, that in this scenario, HSRP is used between C7206VXR-MAIN and C7206VXR-STANDBY and that C2651XM-VPNA, C2651XM-VPNB, and C2651XM-VPNC are using that HSRP virtual IP address to terminate their IPsec VPN sessions to cleartext routed domain D. When C7206VXRMAIN fails, therefore, C7206VXR-STANDBY takes over as the VPN aggregator for inbound IPsec VPN tunnels initiated by C2651XM-VPNA, C2651XM-VPNB, and C2651XM-VPNC. Because C2651-VPNA, C2651-VPNB, and C2651-VPNC are configured to use the HSRP virtual IP address shared between C7206VXR-MAIN and C7206VXR-STANDBY, and because this address does not change during failover, there is no required reconfiguration on C2651XMVPNA, 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

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 predefined timers: ■

Hello Timer—The amount of time between transmissions of HSRP hello messages.

■

Hold Timer—The amount of time elapsed between receipt of HSRP hello messages for a neighboring HSRP router (active or standby) to be considered down.

These timers, of course, can be changed to optimize convergence in a stateless IPsec HA scenario. Example 6-9 shows configuration changes on C7206VXR-MAIN and C7206VXR-STANDBY to decrease the amount of time it takes HSRP, and hence the amount of time it takes the system, to reconverge. Example 6-9

HSRP Tuning Example for Optimal Stateless IPsec HA Reconvergence.

C7206VXR-MAIN# interf ace fa0/0 C7206VXR-MAIN(config)#i standby 1 timers ms ec 30 m sec 100 C7206VXR-MAIN(config-if)#s

CAUTION Tuning HSRP timers for subsecond reconvergence upon failover greatly increases the amount of HSRP traffic on the subnet local to the routers in the HSRP group. Additionally, when timers are tuned for subsecond relay of HSRP hellos and holdtimes, delay between the peers on the same subnet could impact the timely processing of hellos, leading to inconsistent flux in HSRP states. Exercise caution when tuning HSRP timers this tightly in order to avoid inconsistencies in the behavior of the IPsec HA design, including potential unexpected failover due to successive missed HSRP hellos within a configure hold timer window.

Although HSRP timers can be tuned to trim seconds off of the overall delay in reconvergence of the IPsec tunnel itself, HSRP failover delay accounts for only part of the overall reconvergence. As we will discuss later, IPsec and ISAKMP both have elements contributing much more delay to the overall reconvergence than HSRP itself, such as transmission of IKE keepalives, among other things. Step 5: IPsec Reconvergence After HSRP successfully fails over from C7206VXR-MAIN to C7206VXR-STANDBY, an additional step of IPsec reconvergence must occur before data can successfully be passed between domain D and domains A, B, and C. This extra step in the reconvergence of the solution is a key characteristic of a stateless failover. Because C7206VXR-STANDBY does not have any awareness of the state of C7206VXR-MAIN’s SADB, C7206VXR-STANDBY must therefore rebuild the ISAKMP and IPsec SAs in its own SADB after HSRP has reconverged.

256

Chapter 6: Solutions for Local Site-to-Site High Availability

Again, there is no manual intervention or configuration change required on any of the IPsec peers for this particular failover scenario to complete—it is done dynamically once traffic is passed from C2651XM-VPNA, C2651XM-VPNB, and C2651XM-VPNC to C7206VXR-STANDBY. However, waiting for stale SAs to be torn down contributes more delay to the failover of a stateless HA solution than any other step in the process. The Cisco IOS default life of an ISAKMP SA is 24 hours, and the Cisco IOS default life of an IPsec SA is 1 hour. In an HA scenario, these SAs would need to be removed for new ones to be built with the redundant peer, leading to unacceptably long reconvergence times. At a minimum, IKE keepalives are required to identify stale SAs from a failover scenario and to remove them so that they can be replaced with new SAs with the redundant peer. TIP Even if IKE keepalives are used, the lowest configurable number in IOS is 10 seconds between keepalives, yielding a total failover delay attributable to stale SA teardown of approximately 30 seconds (3 keepalive intervals × 10s/keepalive interval). Example 6-10 shows output from the SADB after a failure on C7206VXR-STANDBY and the reconvergence of HSRP and IPsec processes. Note that the peering and proxy fields in the SADB are identical to those listed in Example 6-6. With HSRP debugging enabled on C7206VXRSTANDBY, the administrator is able to diagnose the order of events when a failure occurs on C7206VXR-MAIN. The HSRP process begins with diagnostics confirming that C7206VXRSTANDBY 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 5–9 confirms the transition of the redundancy group that the crypto process uses, “chap6-vpnha”, from standby to active. This allows the local crypto process to bind IPsec and ISAKMP peering information to the virtual IP address rather than to the physical or loopback interface IP. The diagnostic output in line 11 confirms that C7206VXRSTANDBY’s Fa0/0 interface is the current active HSRP interface for the group. Also confirmed in line 14 is the HSRP standby IP address that should be used by the redundancy group “chap6vpnha” to populate local tunnel termination information in C7206VXR-STANDBY’s SADB. Like C7206VXR-MAIN, C7206VXR-STANDBY is also configured to preemptively assume active router responsibilities when an HSRP priority change is sensed within the HSRP group, as shown in line 19. However, while C7206VXR-MAIN uses this information to reclaim the role of active router after a failure has been restored, C7206VXR-STANDBY will only preempt to take over when priority is decremented on C7206VXR-MAIN due to the failure of one of its tracked interfaces. Example 6-10

C7206VXR-STANDBY IPsec SADB after HSRP Failover

debug standby eve nts C7206VXR-STANDBY#d 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

Stateful IPsec VPN High-Availability Alternatives

Example 6-10

257

C7206VXR-STANDBY IPsec SADB after HSRP Failover (Continued)

*Jul 1 3 19:47:37 .191: HSRP : Fa0/0 Grp 1 Standby -> Active *Ju l 13 19:47: 37.19 1 : %HSRP-6-S TATECHANGE: F ast Ethernet0/0 G rp 1 state Standb y -> Active *Ju l 13 19:47: 37.191: HS RP: Fa0/ 0 Grp 1 Redun dancy “chap6 -vpn ha” state Sta ndby -> A ctive *Jul 13 19:47:40.191: HSRP: Fa0/0 Grp 1 Redundancy group chap6-vpnha state Active -> Active *Jul 13 19:47:43.191: HSRP: Fa0/0 Grp 1 Redundancy group chap6-vpnha state Active -> Active C7206V XR-STANDB Y# sh stand FastEt hernet0/0 - Group 1 State is Activ e 14 stat e changes, last state chan ge 00:00:41 Vir tual IP a ddress is 200.1. 2 .1 Active v irtual MAC ad dress is 0000.0c07 .ac01 Local virtual MA C address is 0000.0 c07.ac01 (v1 de f ault) Hel lo time 3 s ec, h old time 1 0 sec Next he l lo sent in 0. 436 secs Pree mption enabled Active rou ter is l ocal S tandby rout e r is unkno wn Priority 5 0 (co nfigured 50 ) IP redund a ncy name is “chap6- vpnha” (cfgd)

Step 6: Post-HSRP RRI Execution The final step in the reconvergence of the system is to propagate routes into the respective VPN domains. As IPsec VPN connections are built from VPN gateways C2651XM-VPNA, C2651XMVPNB, and C2651XM-VPNC to C7206VXR-STANDBY and the SADBs are populated with the appropriate protected address scopes to be included in the crypto switching path, RRI injects routes into the appropriate cleartext routing domains. In this step, RRI on C7206VXR-STANDBY is executed in the same way that C7206VXR-MAIN executed RRI in Step 2 earlier in this process.

Stateful IPsec VPN High-Availability Alternatives Site-to-Site IPsec HA can be designed to reconverge quicker upon failover when a stateful design alternative is used. Recall that in stateless IPsec failover, there is a reconvergence delay directly attributable to rebuilding IPsec SAs with the redundant router upon failover. Stateful IPsec HA builds the appropriate entries in the redundant VPN gateway’s SADB in advance and employs a mechanism to accurately maintain state parity between the active and standby VPN gateways, thereby effectively precluding the need for IPsec to renegotiate Phase 1 and Phase 2 SAs upon failover. We will now explore the additional components required for an IPsec VPN design with stateful local High Availability.

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, 2651XMVPNB, and 2651XM-VPNC). In our discussion of stateful IPsec HA designs, we will discuss a design in which the IPsec VPN tunnels are both sourced from and terminated on statefully redundant HSRP virtual interfaces. The stateful design in Figure 6-5 illustrates this behavior. Notice that in Figure 6-3 and Figure 6-4, only the concentrating end of the VPN design (domain D) incorporated redundant termination of the IPsec tunnels from domains A, B, and C on an HSRP virtual interface, while in Figure 6-5, a stateless IPsec HA design has been incorporated at all domains to allow for redundant origination and termination of the IPsec VPN tunnel at domains A, B, and C. Figure 6-5

Stateful IPsec High Availability Topology 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.

2

Cleartext Routed Domain D 10.0.0.0/8

Ciphertext Routed Domain

10.0.0.0/8

200.1.0.0/16

3

2

1 2651XM-VPNA1 Active Gateway ec

IPS

el unn NT

VP

2651XM-VPNB2 Standby Gateway

Public Routed Domain IPSec VPN Tunnel

192.168.1.0/24 192.168.2.0/24 192.168.3.0/24

192.168.1.0/24 2651XM-VPNA2 Standby Gateway

C7206VXR-STANDBY (Standby HSRP Router)

4 2

Cleartext Routed Domain A

Cleartext Routed Domain B

1

192.168.2.0/24 10.0.0.0/8 2651XM-VPNB1 Active Gateway

IPS

ec

VPN

Tun n

el 2651XM-VPNC2 Standby Gateway

3

1

C7206VXR-MAIN (Primary HSRP Router)

HSRP Virtual Interfaces

10.0.0.0/8

2651XM-VPNC1 Active Gateway 192.168.3.0/24

Cleartext Routed Domain C

4

Stateful IPsec VPN High-Availability Alternatives

259

The following list briefly describes the stateful failover of the IPsec VPN tunnel illustrated in Figure 6-5: 1.

A branch router, such as 2651XM-VPNA, 2651XM-VPNB, or 2651XM-VPNC, establishes an IPsec VPN tunnel to the HSRP standby interface shared between C7206VXRVPN-MAIN and C7206VXRVPN-STANDBY.

2.

C7206VXR-MAIN communicates the contents of its IPsec SADB to C7206VXR-STANDBY via Stateful Switchover.

3.

C7206VXR-MAIN recognizes the presence of a new IPsec SA from Step 1 and injects an RRI-learned route in to Domain D.

4.

A reconvergence event occurs on C7206VXR-MAIN. This could be, for example, the failure of a tracked interface or a failure of the device itself, such as a power failure.

5.

HSRP state changes from Standby to Active on C7206VXR-STANDBY. C7206VXR-MAIN is now either unavailable or has transitioned from Active to Standby.

6.

The IPsec tunnel fails over to C7206VXR-STANDBY. There is no Phase 1 and Phase 2 renegotiation due to the prior synchronization of SADB state in step 2.

7.

C7206VXR-STANDBY injects an RRI-learned route for the SAs learned and activated in Steps 2 and 6, respectively.

In this section, we will discuss in greater detail the step-by-step failover of an IPsec VPN tunnel in a stateful HA design, but first, we will look at some of the key components of a stateful IPsec HA design that differ from a stateless IPsec redundancy designs. HSRP and RRI The stateful HA designs discussed in this chapter all use HSRP and RRI in the same way that the stateless designs do. Therefore, the reconvergence delay attributable to reconvergence of HSRP and re-injection of RRI routes is similar between stateful and stateless designs. Additionally, HSRP timers and RRI configurations should be similar between stateful and stateless designs. The key ingredient of a stateful design, which is also the key differentiator between stateful and stateless local IPsec HA alternatives, is the communication of state between the active and standby IPsec gateways configured for tunnel termination on the HSRP interface. This communication requires a function called Stateful Switchover (SSO), which we will now explore. Stateful Switchover (SSO) and IPsec High Availability SSO is the primary differentiator between stateful and stateless HA designs outlined in this chapter. Unlike stateless IPsec HA designs in which there is no sharing and synchronization of IPsec state between the redundantly configured IPsec gateways, there is a synchronization and mutual update of state information between redundant gateways in a stateful design. The mechanism used to communicate, synchronize, and maintain the state between two or more

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 configured by SSO and are therefore available on the redundant peer prior to failover. NOTE IKE keepalives are not supported with SSO in a stateful IPsec HA environment. Dead Peer Detection (DPD), however, is supported in stateful IPsec HA deployments.

By default, SSO uses the standards-based Stream Control Transmission Protocol (SCTP), defined in RFC 2970, to transport IPsec state information between redundant IPsec gateways. SCTP is similar to TCP in that it is connection-oriented and reliable, but it also has notable differences. One such underlying difference is that SCTP provides message ordering and reliability, whereas TCP provides these services for the actual bytes of the message. Because of this, SCTP is well suited for the reliable, sequenced exchange of state messages used to provide IPsec HA between two redundant IPsec gateways. As with HSRP and RRI, there are timers within SSO that can be tuned. Ideally, those timers should be set so that the state of each gateway is most accurately reflected in its redundant peers, rather than simply to aid in the speed of reconvergence among failover. Remember, SSO exists so that the state of the IPsec SADB is already built on the redundant peer before failover. As such, there should be no failover delay attributable to SSO if the state of each VPN gateway’s SADB is correctly synchronized. Example 6-11 shows SSO output on C7206VXR-MAIN in Figure 6-5. The key difference between stateful (Example 6-11) and stateless (Example 6-5) configurations is the configuration of SSO to communicate the SADB state between active and redundant IPsec VPN gateways prior to a convergence event taking place. Configuration lines 4 and 5 instruct SSO to use the standby group with the name “chap6-vpnha” for redundancy. This indirectly binds SSO to the redundant crypto process. (Note from previous examples that the crypto process is also bound to this HSRP group as well.) As discussed previously, SSO uses stream control transport protocol (SCTP) to relay SADB state information from active to standby IPsec VPN gateways. The configuration in lines 7–17 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 C7206VXRSTANDBY as the remote IP, and port 6666 as the Layer 4 source and destination ports. Example 6-11

SSO Configuration on C7206VXR-MAIN (Figure 6-5)

C7206V XR-MAIN#sho w running -config ! ! re dundancy in te r-device scheme standby ch ap6- vpnha ! ipc z one defaul t

Stateful IPsec VPN High-Availability Alternatives

Example 6-11

261

SSO Configuration on C7206VXR-MAIN (Figure 6-5) (Continued)

associati on 6 n o shutdown protocol sctp loc al-port 6 666 l ocal-ip 200 .1.2.11 retransmi t-timeout 200 50 00 pa th-retransm it 10 ass o c-retr ansmit 20 remote-p o r t 6666 r emote-ip 20 0.1.2 .12

Stateful High Availability Failover Process The following sections describe the stateful High Availability failover process: ■

Step 1: Initial IPsec VPN Tunnel Establishment

■

Step 2: SADB Synchronization with SSO

■

Step 3: Pre-HSRP Failover RRI Execution

■

Step 4: Active Router Failure

■

Step 5: HSRP Reconvergence

■

Step 6: IPsec Reconvergence

■

Step 7: Post-HSRP RRI Execution

Step 1: Initial IPsec VPN Tunnel Establishment As with a stateless IPsec HA design, an IPsec VPN tunnel must first be built. Stateful IPsec HA offers a key design differentiator in this step: Whereas stateless IPsec HA allows the network designer to terminate the IPsec tunnel on an HSRP Virtual Interface, a stateful design allows the designer to both terminate and source the IPsec tunnel from HSRP virtual interfaces, thereby offering redundancy at both the origination and termination points of the IPsec VPN (a stateless design only offers redundancy at the termination points). This key point of differentiation is enabled with stateful IPsec HA using SSO. Step 2: SADB Synchronization with SSO As we have discussed several times, in order for a design to be stateful, the IPsec SADB must be synchronized between active and failover IPsec VPN gateways. When IPsec Phase 1 and Phase 2 SAs are populated in the active router’s SADB, they are then shared with the redundant router prefailover using SCTP (the transport protocol for SSO messages). As we will see in later steps and

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. CAUTION Although SCTP eliminates certain vulnerabilities inherent to the nature of TCP, SADB information passed using SCTP in an SSO-enabled design is sent in cleartext, not ciphertext. Therefore, administrators should be advised not to allow SCTP messages to cross an untrusted domain, such as a Layer 2 domain spanned across multiple untrusted switched domains.

Step 3: Pre-HSRP Failover RRI Execution RRI propagates routing information in a stateful IPsec HA deployment in the same way that it does in a stateless IPsec HA deployment. There should be no additional decrease in system reconvergence attributable to RRI injection when selecting a stateful IPsec HA design alternative over a stateless one. Be aware, however, that as with a stateless IPsec HA option, injecting routes via RRI in a failover scenario will require RP reconvergence behind the IPsec VPN, contributing to the overall system reconvergence delay. Step 4: Active Router Failure To trigger failover between redundant peers, an active router must first fail. Although this step is similar to what occurs in a stateless failover design, note that one key difference is that this failover can occur on either side of the VPN tunnel because there is redundancy built into the source of the IPsec VPN tunnel in this design. Step 5: HSRP Reconvergence As with a stateless design, HSRP must reconverge. The HSRP timers should be tuned for rapid failover in this stateful design in the same manner that they are tuned in a stateless design. It is important to note, however, that unlike a stateless design, HSRP reconvergence is the only process that contributes to the delay of the overall IPsec VPN tunnel. Step 6: IPsec Reconvergence The key difference between stateless and stateful IPsec HA solutions is that there is no reconvergence of IPsec in the overall reconvergence of the system. This is because the redundant router has already been informed of the IPsec SA state that it should use by its active counterpart prior to failover. For this reason, there is no failover delay attributable to Phase 1 and 2 IPsec negotiation in a stateful IPsec HA design.

Summary

263

Step 7: Post-HSRP RRI Execution Once the standby IPsec VPN gateway assumes the crypto forwarding responsibilities for traffic through the IPsec VPN tunnel, it must update the local routing table with itself as the VPN gateway for routes on the opposite side of the IPsec VPN tunnel. This is done through RRI in the same manner outlined in our discussion of stateless IPsec HA.

Summary In this chapter, we discussed several key components that comprise a highly available IPsec VPN design. These components provide local IPsec HA in either of two design 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 floating static routes to eliminate reconvergence delay due to RP updates and the use of highly available interfaces to eliminate reconvergence delay attributable to teardown and setup of IPsec and ISAKMP SAs (see Table 6-1 for a summary comparison of path redundant VPN designs and HSRP-based IPsec tunnel termination designs). We also discussed the benefits of stateless IPsec High Availability when terminating IPsec VPN tunnels on HSRP virtual interfaces without the synchronization of IKE and IPsec SADB states between active and redundant IPsec gateways prior to the experience of a reconvergence event. Stateless IPsec HA solutions provide High Availability at the platform level through leveraging the use of HSRP, rather than at the interface level. Stateless IPsec HA solutions therefore add an additional level of resiliency to the system over and beyond the level of resiliency provided by a

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 group’s local network.

Overhead

IKE keepalives; maintenance of redundant tunnel. SADB increases as number of redundant sessions increases.

HSRP hellos on the local HSRP group segment. Can be significant if using subsecond HSRP reconvergence within the HSRP group.

Reconvergence Delay: Phase 1 & 2 SA Maintenance

Stale SAs become a risk in redundant path schemes—use 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.

Summary

Table 6-1

265

Summary Design Considerations for Stateless IPsec HA (Continued) Design Consideration

Use of Redundant Paths and Interfaces

Stateless HSRP-Based IPsec Tunnel Termination

Reconvergence Delay: Redundancy Protocols

None—design relies strictly on the availability of the redundant path and the stability of the underlying routing protocol.

HSRP must reconverge before IPsec can reconverge. Note that although HSRP can be tuned for subsecond failover, it is recommended that care be taken when tuning HSRP timers that tightly.

Reconvergence Delay: Routing Protocols

Design depends heavily on RP reconvergence. When RP scalability and management are not a concern, use of floating static routes can be configured to decrease failover delay attributable to RP reconvergence.

HSRP virtual interfaces must be routable and reachable by their remote peers, but this design minimizes impact due to RP failures.

Stateful IPsec VPN High Availability Design Summary Stateful IPsec tunnel termination on virtual interface using SSO is the only local site-to-site HA method discussed in this chapter. Stateful IPsec HA aids the reconvergence of IPsec tunnels in a failover scenario, because the SADB state information on the primary peer is proactively relayed to the redundant peer prior to failover. The two peers use SSO to relay the information and use HSRP to provide a redundant point of origination and termination of the IPsec tunnel itself. Instead of providing a variety of design benefits over stateless HA methods, stateful HA provides one major advantage—minimal reconvergence delay. This is achieved by eliminating the teardown and setup of Phase 1 and Phase 2 SAs. Recall from our previous discussions of stateless IPsec HA that Phase 1 and Phase 2 SAs must be reaped and rebuilt when a failover situation occurs. This is not the case with stateful HA. Recall also that three IKE keepalives must be missed for the SAs to be reaped, and that, at a minimum, those keepalive intervals are set to occur every 10 seconds. This contributes at least 30 seconds of failover delay to the stateless solution, enough delay to cause many business-critical, time-sensitive applications to fail when the IPsec tunnel fails over. Stateful designs eliminate the 30 seconds of failover delay. Instead, stateful IPsec failover delay is attributable only to RP reconvergence and HSRP reconvergence (which can be configured for subsecond failover). For this reason, stateful failover designs are ideally suited for IPsec deployments where HA is required at the tunnel termination point and business-critical, timesensitive applications require rapid IPsec VPN reconvergence.

CHAPTER

7

Solutions for Geographic Site-to-Site High Availability In Chapter 5, “Designing for High Availability,” we had introduced elements of local IPsec Virtual Private Network (VPN) high availability and geographic IPsec VPN high availability. At this point, you should feel comfortable incorporating high availability in to the design of your IPsec VPN tunnel termination points using the design principals discussed in Chapter 6, “Solutions for Local Site-to-Site High Availability.” In this chapter, we will extend our focus of IPsec VPN High Availability (HA) to incorporate design principals specific to geographic IPsec VPN HA. The design concepts pertaining to geographic HA are discussed in detail in this chapter, and reinforced with case studies illustrating applications of each design option: ■

Multiple Peer Statements with Routing Protocols and Reverse Route Injection

■

Encrypted Routing Protocols Using IPsec and Generic Routing Encapsulation (GRE)

■

Peer Management with Dynamic Multipoint VPN (DMVPN)

Use of the design topics discussed in this chapter in conjunction with the local IPsec VPN HA topics discussed in Chapter 6 should provide you with the design awareness needed to begin to address fundamental IPsec VPN HA design challenges.

Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers This design option for IPsec VPN Geographic HA leverages two components to deliver continuity of cleartext routed domains across an untrusted network in a highly available fashion: Reverse Route Injection (RRI) and Multiple IPsec Peering statements. Each delivers complementary functions to deliver the overall solution—RRI 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

268

Chapter 7: Solutions for Geographic Site-to-Site High Availability

across an untrusted intermediate network using an IPsec VPN tunnel for data confidentiality, authenticity, integrity, and nonrepudiation, RRI can be configured on each IPsec VPN tunnel endpoint to inject routes to the remote (on the opposite side of the IPsec VPN tunnel) cleartext network back into its local cleartext routed domain. Figure 7-1 illustrates the injection of remote routes in to a local routed domain in an IPsec environment using RRI. Simple Site-to-Site IPsec VPN Design with RRI

Figure 7-1

RRI-Learned Route: 192.168.2.0/24 Next Hop: 200.1.1.2

WAN 200.1.1.0/24 OSPF 10

EIGRP AS 10 3 4

Host-A

RRI-Learned Route: 192.168.1.0/24 Next Hop: 200.1.1.1

200.1.1.1

1

C3845ISR-A

3 200.1.1.2

2 5

EIGRP AS 10

4

6 C3845ISR-B

Network_A 192.168.1.0/24

Server-B

Network_B 192.168.2.0/24

The following is an explanation of the steps illustrated in Figure 7-1: 1.

Host-A on Network A sends traffic to Server-B on Network B, using a default route injected in to the network by C3845ISR-A. This traffic flow causes C3845ISR-A to initiate an IPsec VPN tunnel negotiation.

2.

C3845ISR-A and B negotiate Phase 1 and then Phase 2 IPsec SAs with one another, successfully creating an IPsec VPN tunnel between Network A and Network B.

3.

C3845ISR-A and B are configured for RRI. When Phase 2 SAs are successfully completed in step 2, C3845ISR-A creates static routes for Network B into its routing table. Likewise, C3845ISR-B injects static routes for Network A into its routing table.

4.

The administrators of Network A and Network B have configured their routing protocol processes on C3845ISR-A and C3845ISR-B to redistribute static routes into the routing protocols for Network A and Network B, respectively. The routing protocols distribute the route injected by RRI by sending RP updates back in to their RP domain.

NOTE Routing Protocols (RPs) in this scenario are contained within Networks A and B. There is no exchange of routing protocol updates across the IPsec VPN tunnel established in Step 2 above. Multicast traffic such as the RP traffic used in this example cannot be encrypted in a site-to-site IPsec VPN. Instead, in this example, RRI is used to preserve routing information from Network A to B and vice versa across the IPsec VPN tunnel.

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 traffic to Server-B to the next hop address of the IPsec VPN peer on C3845ISR-B. C3845ISR-B receives the traffic from C3845ISR-A and forwards it to Server-B, using a route learned by Network_B’s IGP.

6.

Server-B forwards the return traffic to C3845ISR-B. C3845ISR-B uses the static route in its routing table learned via RRI in step 3 to forward the return traffic from Server-B to the next hop address of the IPsec VPN tunnel peer IP address on C3845ISR-A. C3845ISR-A receives the return traffic from C3745ISR-B and forwards it to Host_A using a route learned by Network_B’s IGP.

This process illustrates dynamic RRI in a basic geographic site-to-site IPsec VPN example. As we’ll later see when discussing RRI using multiple IPsec peering statements, the use of RRI in and of itself does not necessarily provide for IPsec HA. Instead, RRI is a component of HA when coupled with multiple peering statements or spread across multiple IPsec VPN tunnel termination points using the stateless or stateful local HA techniques discussed in Chapter 6. Examples 7-1 and 7-2 illustrate the basic configuration and verification of C3845ISR-A and B, respectively, for a simple site-to-site IPsec VPN deployment without geographic or local HA. Example 7-1 provides several notable configuration tasks relevant to successful RRI implementation. C3845ISR-A is configured to use dynamic RRI (Line 9) to insert the static routes corresponding to the destination IP address in crypto ACL 101 (Lines 8 and 19) using a next-hop IP address of 200.1.1.2 (C3845ISR-A’s IP). These routes will be injected only after an IPsec SA is present in the C3845ISR-B’s security association database (SADB). C3845ISR-A uses the RP EIGRP AS 10 to populate this route in the routing table of other networked nodes in Network A. To do this, the RRI-learned routes must be redistributed in to the routing protocol by issuing the redistribute static command provided in Line 13 of Example 7-1. Enhanced Interior Gateway Routing Protocol (EIGRP) requires that the routes be given an EIGRP-specific metric, which is accomplished either by adding a metric for static routes only or by creating a default metric for redistributed routes, as shown in Example 7-1, line 15. RRI will use the destination IP network (192.168.2.0/24) in crypto ACL 101 to populate a static route in the routing table. The next hop for this route will be the IPsec peer defined in the crypto map, 200.1.1.2 (Example 7-1, line 6). Example 7-1

Simple Site-to-Site RRI (Dynamic) Configuration on C3845ISR-A from Figure 7-1

1

show r unning-confi g C3845ISR-A#s

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

270

Chapter 7: Solutions for Geographic Site-to-Site High Availability

Example 7-1

Simple Site-to-Site RRI (Dynamic) Configuration on C3845ISR-A from Figure 7-1 (Continued)

10 ! 11 ! 12 router eigrp 10 13

redistribute static

14

network 10.0.0.0

15

default-metric 1500 10 128 128 1500

16

no auto-summary

17 ! 18 ! 19 access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Like C3845ISR-A in Example 7-1, C3845ISR-B is configured to use dynamic RRI to insert the static routes corresponding to the destination IP address in crypto ACL 101 using a next-hop IP address of 200.1.1.1 (C3845ISR-A’s IP). Because the router is configured for dynamic RRI (Example 7-2, line 9), these routes will be injected only after an IPsec SA is present in the C3845ISR-B’s SADB. C3845ISR-B uses the RP EIGRP AS 10 to populate this route in the routing table of other networked nodes in Network A. To do this, the RRI-learned routes must be redistributed in to the routing protocol. EIGRP requires that the routes be given an EIGRP-specific metric, which is accomplished either by adding a metric for static routes only or by creating a default metric for redistributed routes as shown later. RRI will use the destination IP network (192.168.1.0/24) in crypto ACL 101 to populate a static route in the routing table. The next hop for this route will be the IPsec peer in the crypto map, 200.1.1.1. Example 7-2

Simple Site-to-Site RRI (Dynamic) Configuration on C3845ISR-B from Figure 7-1

1

sh run C3845ISR-B#s

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

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 traffic flow triggering the IPsec VPN tunnel negotiation uses a predefined default route injected by C3845ISR-A. In the above process, a predefined route is required, as dynamic RRI will not inject a route for hosts on Network A to use until a Phase 2 SA is created (step 3). Static RRI, however, would have injected routes for Network B in to Network A as soon as the crypto ACL was referenced on a valid crypto map on a valid crypto interface. Therefore, with static RRI, the RRI learned routes could have been used instead of the predefined default route injected in step 1. Examples 7-3 and 7-4 illustrate the configuration and verification of static RRI respectively. CAUTION Static RRI injects a route before the establishment of a Phase 2 SA, which provides a way for interesting traffic to trigger the establishment of a Phase 2 SA. However, if the IPsec tunnel cannot be established (for example, if the path is severed between the two IPsec tunnel endpoints), traffic destined for the RRI-learned static route could potentially become black-holed, as that static route will always exist in the routing table regardless of the presence of an IPsec (Phase 2) SA in the SADB.

Example 7-1, lines 5-9, define the crypto map to be used. The crypto map “chap7-rri-1” applies, at a minimum, the transform set, IPsec peer, and crypto ACL to a crypto interface. In this example, crypto acl 101 defines the traffic to be included in the crypto switching path on this interface. The crypto map also applies the 3DES/MD5-HMAC transform referenced in the transform set “chap7-rri-1” and the peer 200.1.1.2. Static RRI is configured on this crypto map (Example 7-1, line 9), immediately injecting a static route in to the routing table. Once this crypto map has a valid crypto ACL, peer, and transform set, the application of the crypto map to the interface static RRI immediately injects the appropriate static route in to the routing table (see Example 7-4 for verification). EIGRP AS 10 is configured to redistribute static routes, which is required to inject the RRI learned static routes in to the dynamic routing protocol. This effectively injects RRIlearned static routes for Network B into the private network behind C3845ISR-A (Network A). In order for EIGRP to successfully redistribute the static routes, a metric must be defined specific to the redistribute static command, or with the default-metric command as listed below. ACL 101 defines the traffic to be included in the crypto switching path. RRI will use the destination IP address of the crypto ACL defined in the ACL to populate the RRI static route destination in the routing table. RRI will use the IPsec peer defined in the crypto map as the next-hop IP for this route.

272

Chapter 7: Solutions for Geographic Site-to-Site High Availability

Example 7-3

Static RRI Configuration

1

sh run C3845ISR-A#s

2

Building configuration...

3

!

4

!

5

crypto map chap7-rri-1 10 IPsec-isakmp

6

set peer 200.1.1.2

7

set transform-set chap7-rri-1

8

match address 101

9

reverse-route static

10 ! 11 interface Ethernet0/0 12

ip address 200.1.1.1 255.255.255.252

13

half-duplex

14

crypto map chap7-rri-1

15 ! 16 ! 17 router eigrp 10 18

redistribute static

19

network 10.0.0.0

20

default-metric 1500 10 128 128 1500

21

no auto-summary

22 ! 23 ! 24 access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

Note from the console output in Example 7-4, lines 18-20, that a Phase 2 SA is not required to inject RRI-learned routes with static RRI—the static route will exist in the routing table regardless of whether IPsec has successfully established Phase 2 SAs or not. Also note from the console output in Example 7-4, line 3, that RRI inserted a static route immediately, prior to the negotiation of IPsec or IKE SAs Example 7-4

Static RRI Verification

1

crypto map chap7- rri-1 10 IPsec-isakm p C3845ISR-A(config)#c

2

reverse -route static C3845ISR-A(config-crypto-map)#r

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

show c rypto isak mp sa C3845ISR-A#s

5

dst

src

state

conn-id slot

6 7

show c rypto IPse c sa C3845ISR-A#s

8 9 10

interface: Ethernet0/0 Crypto map tag: chap7-rri-1, local addr. 200.1.1.1

11 12

protected vrf:

Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers

Example 7-4

273

Static RRI Verification (Continued)

13

local

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

ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)

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:

show c rypto engine connect ions active 38 C3845ISR-A#s 39 40

ID Interface

IP-Address

State

Algorithm

Encrypt

Decrypt

show i p route stat ic 41 C3845ISR-A#s 42 S

192.168.2.0/24 [1/0] via 200.1.1.2

NOTE The default behavior of RRI in Cisco IOS for static crypto maps was to inject static routes as soon as a valid crypto ACL was referenced on a valid crypto interface. For dynamic crypto maps, the default behavior of RRI in Cisco IOS was to inject static routes upon the successful creation of a Phase 2 SA. In IOS versions 12.3(14)T and later, the default behavior for both static and dynamic crypto maps and RRI is to inject static routes upon the successful establishment of a Phase 2 SA.

Until this point in the chapter, we have discussed only simple RRI scenarios used to preserve routing table continuity between two networks situated on opposite ends of the IPsec VPN tunnel. We’ve discussed how this can be done without the use of routing protocol exchanges across the

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 definitions with one termination at each end of the tunnel. Chapter 6 discusses several methods of designing local HA in IPsec VPNs, and we will now expand those discussions to include geographic HA methods using the definition of multiple IPsec VPN peers. Figure 7-2 illustrates a variation on Figure 7-1 that adds geographic HA by adding multiple IPsec peering statements on Network_A’s IPsec VPN gateway, C3845ISR-A. These peers point to two separate IPsec VPN gateways on Network B, C3845ISR-B and C. (The number steps in Figure 7-2 are discussed later in this section.) Figure 7-2

Geographic HA with RRI and Multiple IPsec Peers RRI-Learned Route: 192.168.1.0/24 Next Hop: 200.1.1.1

EIGRP AS 10

RRI-Learned Route: 192.168.2.0/24 Next Hop: 200.1.1.2

OSPF 10 EIGRP AS 10

2

200.1.1.2

C3845ISR-A 3 1 4 Host-A

6/7

3

2 Server-B

200.1.1.1

1

WAN 200.1.1.0/24

4 8

5 9

200.1.1.3

Network_A 192.168.1.0/24 RRI-Learned Route: 192.168.2.0/24 Next Hop: 200.1.1.2 200.1.1.3

1

C3845ISR-B

6/7 C3845ISR-C

Network_B 192.168.2.0/24

RRI-Learned Route: 192.168.1.0/24 Next Hop: 200.1.1.1

The redundancy added by defining multiple peers on IPsec VPN gateway C3845ISR-A does not radically change the RRI processes we’ve discussed in the simpler design illustrated in Figure 7-1 and Example 7-1 through Example 7-4. However, it does heighten the need for dynamic RRI over static RRI. This is due to the fact that, when multiple peers are defined, static RRI creates two identical routes to different next-hop IP addresses (the opposite end of the IPsec VPN tunnel). Example 7-5 illustrates static RRI behavior when multiple IPsec peers are defined, in which C3845ISR-A attempts to do per-packet load balancing between multiple next-hops (peers) for the same RRI-learned route. Two peers defined here cause static RRI to inject a static route with two equal cost paths in to the routing table (one valid next-hop to each of the defined peers, 200.1.1.2

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 traffic forwarded to the invalid peer is subsequently dropped). The connection entries in the crypto engine reflect the packet loss described above. Only half of the fifty packets are encrypted/decrypted using the current active IPsec SA in the crypto engine SADB. The router attempts to forward the other half to an invalid peer, and they are subsequently dropped. Example 7-5

Static RRI with Multiple IPsec Peering Statements

1

pi n g Host-A#p

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 show r unning-confi g 15 C3845ISR-A#s 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 show i p route stat 26 C3845ISR-A#s 27 S

192.168.2.0/24 [1/0] via 200.1.1.2

28

[1/0] via 200.1.1.3

29 show c rypto engine connec tions active 30 C3845ISR-A#s 31 32

IP-Address

State

Algorithm

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

33

ID Interface

Encrypt

Decrypt

The behavior of Example 7-5 will lead to other unexpected behavior, potentially including the black holing of valid IP traffic to the inactive peer IP address. In order to avoid this behavior,

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 definitions in Figure 7-2: 1.

C3845ISR-A and C3845ISR-B successfully negotiate an IPsec VPN tunnel and inject RRIlearned static routes in to their routing protocol processes for Network A and Network B, respectively.

2.

A failure occurs on the serial link between C3845ISR-A and C3845ISR-B, causing IPsec VPN peers to miss three IKE keepalives and tear down the IPsec VPN tunnel.

3.

C3845ISR-A and B remove the RRI-learned route in step 1 from their routing table.

4.

Host_A continues to send traffic to Server-B, causing C3845ISR-A to initiate Phase 1 SA negotiation with C3845ISR-C.

5.

C3845ISR-A negotiates Phase 1 and 2 SAs with C3845ISR-C sequentially, using the backup IPsec peer definition (C3845ISR-C).

6.

C3845ISR-A and C are both configured for dynamic RRI. Therefore, once the IPsec VPN tunnel has reconverged from the failover in step 2, static routes for Networks A and B are populated in the routing tables of C3845ISR-C and A, respectively, once the crypto-protected address space defined in the crypto ACLs is reflected and populated in the IPsec SADB.

7.

C3845ISR-A and C are configured to redistribute static routes, effectively injecting the RRIlearned static routes in step 5 in to their routing protocols.

8.

Once both RPs have converged to include the RRI-learned routes, C3845ISR-A uses the static route learned by RRI to forward traffic to Server-B to the next hop address of the IPsec VPN peer on C3845ISR-C. C3845ISR-C receives the traffic from C3845ISR-A and forwards it to Server-B, using a route learned by Network_B’s IGP.

9.

Server-B forwards the return traffic to C3845ISR-C. C3845ISR-C uses the static route in its routing table learned via RRI in step 3 to forward the return traffic from Server-B to the next hop address of the IPsec VPN tunnel peer IP address on C3845ISR-A. C3845ISR-A receives the return traffic from C3745-C and forwards it to Host_A using a route learned by Network_B’s IGP.

While RRI provides continuity for IP routing across IPsec VPN tunnels, it is the use of multiple peering statements on C3845ISR-A that provides the redundancy that lends itself to a highly available design. This design option can be further tuned to yield a greater degree of availability using IKE keepalives or IKE dead peer detection (DPD). For more information on IKE keepalives and DPD, please refer back to previous discussions in Chapter 5. Example 7-6 provides sample configurations for the HA design illustrated in Figure 7-2 using RRI with Multiple IPsec Peer

Geographic IPsec VPN HA with Reverse Route Injection and Multiple IPsec Peers

277

definitions on C3785-A. The successful reconvergence process described above is verified using the diagnostic commands included in Example 7-7. The crypto map in Example 7-7 is configured with redundant peers. Dynamic RRI is configured under the crypto map, injecting static routes for the destination IP address configured in Crypto ACL 101 to the next-hop of the IPsec peer actively populated in the SADB. Unlike Static RRI, this route is populated only upon population of the SADB with the appropriate Phase 2 SA. RRI uses the destination IP defined in crypto ACL 101 (192.168.2.0/24) to populate the static routing table upon successful creation of a Phase 2 SA. Example 7-6

C3845ISR-A Configuration Using Dynamic RRI with Multiple IPsec Peer Definitions

1

show r unning-confi g C3845ISR-A#s

2

Building configuration...

3

!

4

!

5

crypto map chap7-rri-1 10 IPsec-isakmp

6

set peer 200.1.1.2

7

set peer 200.1.1.3

8

set transform-set chap7-rri-1

9

match address 101

10

reverse-route

11 ! 12 ! 13 access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

As confirmed by the diagnostic output of Example 7-7, lines 1-4, the crypto engine has no active SADB entries. As such, RRI will not populate the static routing table with the appropriate static routes (Example 7-7, lines 5-6). With static RRI, the configuration of Example 7-6 would populate the routing table with a static route regardless of the state of C3845ISR-A’s SADB. Debugging the crypto IPsec process enables us to determine exactly when the RRI-learned static route is populated in the routing table by dynamic RRI (Example 7-7, line 18). A Phase 2 SA is created, also illustrated in Example 7-7 below (lines 21-28). The destination proxy address is the RRIlearned route, and the IPsec peer IP of this SA is the RRI-learned route’s next hop. IPsec SAs are now confirmed to exist in C3845ISR’s SADB, as shown by the diagnostic output pertaining to C3845ISR-A’s crypto engine in Example 7-7, lines 29-34, following. As expected, dynamic RRI created a route for the destination proxy address (192.168.2.0/24) defined in crypto ACL 101 and the IPsec peer address used in the Phase 2 SA (200.1.1.2). Example 7-7

1

Verifying C3845ISR VPN Failover with Dynamic RRI and Multiple IPsec Peer Definitions show c rypto engine connect ions active C3845ISR-A#s

2 3

ID Interface

IP-Address

State

Algorithm

Encrypt

Decrypt

4

continues

278

Chapter 7: Solutions for Geographic Site-to-Site High Availability

Example 7-7

5

Verifying C3845ISR VPN Failover with Dynamic RRI and Multiple IPsec Peer Definitions (Continued) show i p route st atic C3845ISR-A#s

6 7

debug crypto IPs ec C3845ISR-A#d

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

show c rypto engi ne connect ions active 29 C3845ISR-A#s 30 31

IP-Address

State

Algorithm

Encrypt

Decrypt

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

32

ID Interface

show i p route st atic 35 C3845ISR-A#s 36 S

192.168.2.0/24 [1/0] via 200.1.1.2

Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing Protocols Tunneling traffic in GRE prior to encryption with IPsec enables the encryption of multicast traffic. This is due to the fact that the multicast traffic is represented as a payload of a unicast packet after it has been encapsulated with GRE. As such, once the packet has been encapsulated in GRE, it is presented to the crypto engine as a unicast packet. We have referred to this as IPsec+GRE in previous chapters. IPsec+GRE is a key design option for passing multicast traffic, including RPs that use multicast updates, through an encrypted tunnel. As such, sending routing protocol updates

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 traffic in the overall traffic profile upward, the need to secure this type of traffic increases proportionally. IGP multicast update traffic is one such critical multicast application that is often included in the crypto switching path. TIP Cisco IOS includes unicast RP update features for BGP and most IGPs. Encrypted unicast RP updates can be exchanged over the IPsec VPN tunnel to preserve IP routing continuity without the use of GRE. More information on Unicast RP updates is provided in Chapter 5.

Sending RP updates across the IPsec tunnel enables RP adjacencies to be built between two networks situated on opposite sides of an IPsec tunnel, as illustrated in Figure 7-3. This solution therefore serves as an alternative to RRI for preserving IP routing continuity between IP networks across an IPsec VPN tunnel. Figure 7-3

IPsec+GRE with Encrypted Routing Protocol Updates EIGRP RP Update: 192.168.2.0/24 Next Hop: 200.1.1.2

EIGRP AS 10 4

EIGRP RP Update: 192.168.1.0/24 Next Hop: 200.1.1.1

WAN 200.1.1.0/24 OSPF 10

EIGRP AS 10 5

2

2

3 10 Host-A

C3845ISR-A

Network_A 192.168.1.0/24

200.1.1.1

9

1

6 200.1.1.2

8

7 C3845ISR-B

Server-B

Network_B 192.168.2.0/24

The administrators of the network illustrated in Figure 7-3 face the same challenges as in the network topologies of Figures 7-1 and 7-2. Instead of using RRI to allow Network A and Network B to route between one another over the IPsec VPN tunnel, the administrators choose to create a GRE tunnel between C3845ISR-A and B through which RP updates are exchanged. All GRE traffic is then encrypted with a transform defined in the IPsec configuration on C3845ISR-A and B. This effectively allows the administrators of Network A and B to run the same routing protocol, preserving continuity of the routing tables of Network A and B by leveraging encrypted RP

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 configured on C3845ISR-A and B. Once the GRE tunnel and RP configuration is complete on C3845ISR-A and B and traffic is received matching a active crypto ACL, the crypto engine initiates the negotiation of Phase 1 and 2 SAs on C3845ISRA and B, completing the creation of the IPsec+GRE tunnel.

NOTE Beware that control plane traffic such as GRE Keepalives, RP Hellos, and RP updates passing through the GRE tunnel will keep the IPsec+GRE tunnel up, as they are encapsulated in GRE causing a match on the IPsec+GRE crypto ACL.

2.

The GRE tunnel interfaces created in #1 are configured to forward EIGRP RP updates between C3845ISR-A and B. Routes for Network A are populated in the routing tables of networked nodes throughout Network B and vice versa.

3.

When Host-A sends traffic to Server-B, C3845ISR-A uses a route table entry for Server-B learned via EIGRP in #2 to make the Layer 3 forwarding decision. C3845ISR-A therefore forwards traffic from Host-A to Server-B out of the GRE tunnel interface.

4.

When the traffic is encapsulated in GRE, the crypto engine recognizes a crypto ACL match, causing the GRE packet resulting from #3 to be encrypted using ESP and forwarded to C3845ISR-B across the IPsec VPN tunnel.

5.

C3845ISR-B receives the encrypted traffic from #4 and decrypts it. After the ESP header is removed, the resulting GRE packet is then decapsulated.

6.

C3845ISR-B now forwards the resulting packet from #5 to Server-B using the destination IP of the original IP packet sent by Host-A in #3.

7.

When Server-B sends return traffic to Host-A, C3845ISR-B uses a routing table entry for Host-A learned via EIGRP in #2 to make the Layer 3 forwarding decision.

8.

C3845ISR-B encrypts the GRE packet resulting from the GRE encapsulation in #7 using ESP, and subsequently forwards the encrypted packet to C3845ISR.

9.

C3845ISR-A removes the Extended Services Processor (ESP) header attached by C3845ISRA in #8, and decapsulates the resulting GRE packet.

10.

C3845ISR-A forwards the return traffic from Server-B to Host-A using the destination of the original IP packet created in #7.

The important difference in this design is that encrypted routing protocols essentially replace RRI as a means of IP routing continuity between Network A and Network B. With IPsec+GRE, routing protocols updates can be exchanged only once the IPsec tunnel is successfully established, which is more akin to a dynamic RRI implementation as opposed to a static one. Unlike either mode of

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 traffic between the tunnel endpoints. This is due to the fact that the crypto engine will now be presented with a GRE header resulting from the GRE encapsulation for inclusion in the crypto switching path based on a crypto ACL match, rather than the original headers now included as parts of the GRE payload. These necessary configuration elements are listed for C3845ISR-A and B of Figure 7-3 in Example 7-8, and the verification of the configuration is provided using the diagnostic commands in Example 7-9 later in our discussion of IPsec+GRE HA. Thus far, we’ve covered two options for establishing IP routing continuity between two networks across an IPsec VPN tunnel: IPsec+GRE with encrypted RP updates and RRI. Generally speaking, each method is used to accomplish the same task of enabling each end of an IPsec VPN tunnel to route to the opposite end. However, each method has different benefits and requirements. Keep several design considerations, such as the ones provided in the following list, in mind when choosing one or another: ■

Encrypted IP Multicast Application Requirements: If there are other IP multicast applications that require data confidentiality, then IPsec+GRE may be a requirement regardless of the need for encrypted multicast updates. RRI does not provide a solution for IP multicast data flows. Instead it is a means to preserve unicast IP routing continuity across the IPsec VPN tunnel. Therefore, if IPsec+GRE is a requirement based on IP multicast application flow, then the same IPsec+GRE tunnel can be used for encrypted multicast RP updates.

■

GRE Support and Scalability: If GRE is unsupported; another means of preserving IP routing continuity is therefore required. The scalability and performance of GRE is a more common concern than support for GRE itself. In many of today’s IPsec VPN platforms, GRE encap/decap processes are not supported in hardware. This becomes a disadvantage on higher-end VPN platforms that accelerate crypto in hardware, as the GRE process then becomes the bottleneck. If encrypted IP multicast flows are not a requirement, RRI becomes a more attractive design option for geographic HA when the crypto switching path must be executed in hardware.

■

Reverse Route Injection Support: RRI is not an Internet Engineering Task Force (IETF) standard, and is instead a feature proprietary to Cisco IPsec VPN platforms. In vendor-diverse environments, the IPsec VPN design options available to network architects do not include RRI.

At this point, the fundamental differences, requirements, and design drivers behind an RRI or IPsec+GRE decision should be clear. However, the IPsec+GRE solutions presented thus far

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 specific to geographic HA in IPsec+GRE, noting that these elements should indeed be coupled with the local HA design concepts covered in Chapter 6 for a full IPsec+GRE HA design. The numbered steps in Figure 7-4 are covered later in this section. Geographic HA with IPsec+GRE and Encrypted Multicast RP Updates

Figure 7-4

C3845ISR-A Remove EIGRP Routes EIGRP Update w/o Route: 192.168.1.0/24 Next Hop: 200.1.1.1 C3845ISR-A Remove EIGRP Routes EIGRP Update w/o Route: 192.168.2.0/24 Next Hop: 200.1.1.2

EIGRP AS 10

S0/0: 200.1.1.2 Tun0: 192.168.0.2

3

EIGRP AS 10

2

C3845ISR-B

200.1.1.2

C3845ISR-A 6 3 10 Host-A

1

200.1.1.1

10

5

S0/0: 200.1.1.1 Tun0: 192.168.0.1

4

WAN 200.1.1.0/24 (OSPF 10) 9

7 200.1.1.3

Network_A 192.168.1.0/24 EIGRP Update: 192.168.2.0/24 Next Hop: 200.1.1.2

Server-B

C3845ISR-C 4

S0/0: 200.1.1.3 Tun0: 192.168.0.3

7 8

Network_B 192.168.2.0/24

EIGRP Update: 192.168.1.0/24 Next Hop: 200.1.1.1

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.

Geographic IPsec VPN High Availability with IPsec+GRE and Encrypted Routing Protocols

283

NOTE The default SA lifetimes for IKE and IPsec SAs in Cisco IOS are 38400s and 3600s, respectively. IKE keepalives intervals can be configured as frequently as 10s apart. Therefore, using IKE keepalives potentially expedites stale SA cleanup from the SADB from as long as 3600s to as short as 30s (three missed IKE keepalives at 10s intervals). As such, IKE keepalives and DPD are a critical part of geographic HA concepts for both RRI and IPsec+GRE designs. IKE keepalives and DPD are also a critical part of IPsec peer availability, which is discussed in detail in Chapter 5. After the IPsec VPN peers have been managed appropriately, and a new IPsec VPN tunnel has been established, the GRE tunnel must be established. This component of the overall reconvergence process is not expected to be materially relevant to the routing protocol reconvergence that must occur once the GRE tunnel is established. Once the IPsec+GRE tunnel is established, RP neighbor adjacency must be built between the two GRE tunnel interfaces. This process can vary based on the routing protocol selected. However, consider, as an example, that most EIGRP interfaces use a default hold timer of 15s (three times the 5s hello interval), which is the time it will take for that EIGRP neighbor to be declared dead so that a new one can be established to a viable peer. For geographic IPsec HA deployments, the reconvergence component associated with RP reconvergence plays a critical role when deciding between IPsec+GRE vs. IPsec with RRI. Consider the failover scenario in Figure 7-4 in which the following steps are executed to facilitate reconvergence IPsec+GRE tunnel and associated EIGRP neighbor: 1.

A failure occurs between C3845ISR-A and C3845ISR-B, causing C3845ISR-A’s primary IPsec peer to become unavailable (C3845ISR-B).

2.

C3845ISR-A fails to receive responses to 3 IKE keepalives timed at 10s intervals, causing C3845ISR-A to reap the IKE and IPsec SAs from its SADB.

3.

During the time it takes to miss the three IKE keepalives in #2, the EIGRP holddown timer expires for the EIGRP neighbor relationship between C3845ISR-A and B, at which point the EIGRP neighbor is removed from the neighbor table.

4.

C3845ISR-A and C’s routing tables reconverge, causing all of the routes learned over the tunnel interface to B to point over the GRE tunnel interface to C3845ISR-C.

5.

Host-A forwards traffic to Server-B. C3845ISR-A uses a routing table entry learned via EIGRP RP updates sent in #5 to forward the traffic from Host-A through the IPsec+GRE tunnel.

6.

The traffic in #6 is encapsulated in GRE by C3845ISR-A. After the packet is GREencapsulated, it is encrypted with ESP and forwarded to the redundant IPsec peer at C3845ISR-C.

284

Chapter 7: Solutions for Geographic Site-to-Site High Availability

7.

C3845ISR-C decrypts the traffic received in #6, decapsulates the resulting GRE packet, and forwards the traffic to Server-B based on the destination address in the original IP header sent from Host-A.

8.

Server-B forwards the return traffic to C3845ISR-C. C3845ISR-C uses a routing table entry learned via EIGRP RP updates sent in #4 to forward the return traffic from Server-B back to Host-A through the IPsec+GRE tunnel.

9.

The traffic in #8 is encapsulated in GRE by C3845ISR-C. After it is GRE-encapsulated, the packet is encrypted with ESP and forwarded to the IPsec peer at C3845ISR-A.

10.

C3845ISR-A decrypts the traffic received in #9, decapsulates the resulting GRE packet, and forwards the traffic on to Host-A based on the destination address in the original IP header sent from Server-B in #8.

Similar to our discussion of RRI with multiple IPsec peers, IPsec+GRE in and of itself does not provide added degrees of availability to the design. Instead, IPsec+GRE is hardened using multiple, redundant, IPsec peers and redundant GRE tunnel interfaces that enable the IPsec+GRE tunnel to reconverge over a redundant path. This concept is referred to as path availability, and is discussed in greater detail in Chapter 5. Example 7-8 includes a sample configuration used on C3845ISR-A in Figure 7-4 providing HA using multiple IPsec peer definitions and redundant GRE tunnels. The failover process described previously for the IPsec+GRE deployment illustrated in Figure 7-4 is verified in Example 7-9. Internet Security Association and Key Management Protocol (ISAKMP) is configured to use preshared key (PSK) authentication with an MD5 hash, DES encryption (default), and a group 2 Diffie-Hellman modulus. A PSK of Cisco is used to authenticate IKE SAs with C3845ISR-A (200.1.1.2) and B (200.1.1.3). The cipher used on the cleartext traffic sent through the IPsec VPN tunnel to the spokes is ESP 3DES with MD5 HMAC authentication on the ciphered blocks. Unlike our previous discussions of RRI with multiple crypto maps, this IPsec+GRE design leverages multiple crypto map process IDs (10 and 20) to define different IPsec peers and crypto ACLs. This effectively enables the use of two IPsec+GRE tunnels to become active simultaneously, offering the ability to load balance across each in an active/active fashion. There are two crypto ACLs that are defined in their own respective process IDs (10 and 20) under the same crypto map, “chap7-IPsec+gre”: ■

Crypto ACL 101 defines GRE traffic from the Tunnel12’s source IP to Tunnel12’s destination IP to be protected in the crypto switching path. Crypto ACL 101 is configured to protect all traffic through GRE tunnel 12. It accomplishes this by including any GRE packets sourced from 1.1.1.1 (GRE tunnel source on C7304) to 2.2.2.2 (GRE tunnel destination on C3845ISR-A).

■

Crypto ACL 102 defines GRE traffic from the Tunnel13’s source IP to Tunnel12’s destination IP to be protected in the crypto switching path. Crypto ACL 102 is configured to protect all traffic through GRE tunnel 13. It accomplishes this by including any GRE packets sourced from 1.1.1.1 (GRE tunnel source on C7304) to 3.3.3.3 (GRE tunnel destination on C3845ISR-B).

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 protocol’s updates and hellos will not be protected by IPsec. A second routing protocol is used to provide continuity between two routed domains on opposite sides of the IPsec VPN tunnel. In this case, EIGRP (EIGRP 10) is used to accomplish this by sending EIGRP hellos and updates across the GRE tunnel. These routing protocol updates and hellos will be encrypted because they are encapsulated with GRE, which is defined in the crypto ACLs 101 and 102 accordingly. Example 7-8

IPsec HA Configuration Using IPsec+GRE with Multiple Crypto-Process IDs and Redundant, Load-Sharing GRE Interfaces (C3845ISR-A)

1

show r unning-confi g C3845ISR-A#s

2

Building configuration...

3

!

4

!

5

crypto isakmp policy 10

6

hash md5

7

authentication pre-share

8 9

group 2 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

286

Chapter 7: Solutions for Geographic Site-to-Site High Availability

Example 7-8

IPsec HA Configuration Using IPsec+GRE with Multiple Crypto-Process IDs and Redundant, Load-Sharing GRE Interfaces (C3845ISR-A) (Continued)

33 ! 34 interface Loopback1 35 ip address 1.1.1.1 255.255.255.255 36 ! 37 ! 38 router eigrp 10 39

network 10.0.0.0

40

network 12.1.1.0 0.0.0.3

41

network 13.1.1.0 0.0.0.3

42

no auto-summary

43 ! 44 router ospf 10 45

log-adjacency-changes

46

network 1.1.1.1 0.0.0.0 area 0

47

network 200.1.1.0 0.0.0.255 area 0

48 ! 49 ! 50 access-list 101 permit gre host 1.1.1.1 host 2.2.2.2 51 access-list 102 permit gre host 1.1.1.1 host 3.3.3.3

The crypto engine entries shown in Example 7-9, lines 1-9, verify two active IPsec VPN tunnels, each with their own ISAKMP SA and 2 IPsec SAs. This confirms that the IPsec+GRE implementation is currently redundant in an active/active load-balanced format across the two tunnels. The output in Example 7-9, lines 11-18, confirms that both the local interface providing connectivity to private networks and the two GRE tunnels to the branches (C3845ISR-A and B) are all injected into the appropriate routing protocol (EIGRP AS 10) on C7304. Diagnostic output provided in Example 7-9, lines 20-26, confirms that there are three EIGRP neighbors currently established on C7304: one for connectivity to the private networks behind C7304 and two additional ones for connectivity to the private networks behind C3845ISR-A and B across the IPsec+GRE tunnels. Routes are being learned via EIGRP 10 over the two IPsec+GRE tunnel interfaces from C7304 to C3845ISR-A and B, respectively, as confirmed by Example 7-9, lines 28-40. Each route has two equal cost paths that C7304 will use to load balance over the two IPsec+GRE tunnels currently operating in an active/active fashion. Example 7-9

1

Verifying IPsec VPN Failover with IPsec+GRE with Multiple Crypto-Process IDs and Redundant, Load-Sharing GRE Interfaces (C3845ISR-A) show c rypto engi ne connect ions active C3845ISR-A#s

2 3

IP-Address

State

Algorithm

Encrypt

Decrypt

4

ID Interface 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

Dynamic Multipoint Virtual Private Networks

Example 7-9

287

Verifying IPsec VPN Failover with IPsec+GRE with Multiple Crypto-Process IDs and Redundant, Load-Sharing GRE Interfaces (C3845ISR-A) (Continued)

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 show i p eigrp inte rfaces 11 C3845ISR-A#s 12 IP-EIGRP interfaces for process 10 13 14

Xmit Queue

Mean

Pacing Time

Multicast

Pending

Peers

Un/Reliable

SRTT

Un/Reliable

Flow Timer

Routes

16 Fa0/1

1

0/0

1

17 Tu12

1

0/0

87

18 Tu13

1

0/0

192

15 Interface

0/10

50

0

71/2702

3134

0

71/2702

3294

0

19 show i p eigrp neig hbors 20 C3845ISR-A#s 21 IP-EIGRP neighbors for process 10 22 H

Address

Interface

23

Hold Uptime

SRTT

(sec)

(ms)

RTO

Q

Seq

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 show i p route eigr p 10 | include Tun nel 28 C3845ISR-A#s 29 D 30 31 D 32 33 D 34 35 D 36 37 D 38 39 D 40

10.1.2.0 [90/297270016] via 13.1.1.2, 00:11:04, Tunnel13 [90/297270016] via 12.1.1.2, 00:11:04, Tunnel12 192.168.2.2 [90/297398016] via 13.1.1.2, 00:11:04, Tunnel13 [90/297398016] via 12.1.1.2, 00:11:04, Tunnel12 192.168.2.3 [90/297398016] via 13.1.1.2, 00:11:04, Tunnel13 [90/297398016] via 12.1.1.2, 00:11:04, Tunnel12 192.168.2.1 [90/297398016] via 13.1.1.2, 00:11:04, Tunnel13 [90/297398016] via 12.1.1.2, 00:11:04, Tunnel12 192.168.2.4 [90/297398016] via 13.1.1.2, 00:11:04, Tunnel13 [90/297398016] via 12.1.1.2, 00:11:04, Tunnel12 192.168.2.5 [90/297398016] via 13.1.1.2, 00:11:04, Tunnel13 [90/297398016] via 12.1.1.2, 00:11:04, Tunnel12

Dynamic Multipoint Virtual Private Networks At this point, we’ve covered basic IP routing continuity options over IPsec VPN tunnels in the context of Geographic HA, each of which presents its own unique design challenges. In large-scale IPsec+GRE designs, two such unique design challenges include management and configuration on IPsec+GRE hub/aggregation routers and peer scalability in the hub/aggregation router SADB. DMVPN addresses these concerns, among others, by greatly decreasing the configuration and management effort on the IPsec+GRE hub/aggregation routers using mGRE with Next Hop Resolution Protocol (NHRP) and enabling spoke routers to dynamically build SAs directly to their desired spoke routers. In this section, we will review all of the required components of DMVPN and reinforce these components with an enterprise DMVPN deployment case study.

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 today’s enterprise-class networks: ■

Configuration Complexity and Size: Recall from our discussion of traditional IPsec+GRE designs earlier in this chapter that, each time a branch is added to the network, a GRE tunnel interface is added on the branch IPsec VPN gateway with its own unique point-to-point GRE tunnel interface on the central hub IPsec VPN gateway in order to complete the IPsec+GRE configuration. The creation of unique GRE tunnel interfaces on the hub IPsec VPN gateway for each branch causes configuration complexity and management as the number of branches increases. For example, a large enterprise-class network with 1000 IPsec+GRE enabled branches requires 1000 GRE tunnel interfaces to be configured on the hub IPsec VPN gateway. As we’ll discuss later in this section, a DMVPN design can decrease the 1000 IPsec+GRE interfaces described above to a single mGRE interface. DMVPN does this not by altering the standards-based IPsec protocol itself, but instead by changing the configuration requirements of traditional point-to-point IPsec+GRE networks, yielding a more streamlined and manageable configuration and management requirements of the overall design.

■

GRE and IPsec Scalability and Management: In a standard, traditional IPsec+GRE design, each spoke creates a Phase 1 and 2 SA to the hub. Additionally, the required point-to-point GRE tunnel from the hub to the branch consumes an IDB entry on the hub and branch. For example, in an enterprise network with 1000 branches, 2000 SAs would exist in the hub IPsec VPN gateway’s SADB, and 1000 IDB entries would exist to support the GRE tunnel termination. While DMVPN does not alter this SA requirement on the hub (a permanent hub-spoke SA is also created in DMVPN), DMVPN alters this behavior such that interface description block (IDB) entries are not statically created and consumed. Instead, they are created only when they are needed and only on the appropriate peers. Considering the 1000-branch example with DMVPN enabled, the GRE IDB requirement decreases from 1000 to potentially as little as 1 IDB required on the hub.

NOTE Even in DMVPN networks, having 1 GRE IDB entries is rare to the point of being infeasible. This implies 100 percent spoke-to-spoke traffic. Any time a spoke requires IPsecsecured connectivity to the hub, regardless of whether or not DMVPN is configured, 2 IPsec SAs and 1 IDB entry will be created on the hub. The example described previously is used to reinforce that, with DMVPN, IPsec SAs and GRE IDBs are created only as needed.

In addition to improved SA and IDB management, DMVPN decreases unnecessary decrypt/ reencrypt behavior on the hub IPsec VPN gateway for spoke-to-spoke communications. In traditional IPsec+GRE hub and spoke deployments, a branch must encrypt traffic to the hub, where it is decrypted and then reencrypted before sending to the destination branch in a spoke-tospoke scenario. We will explore in our step-by-step discussions how DMVPN can be used to

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-tospoke IPsec VPN traffic.

DMVPN Component-Level Overview and System Operation At this point, we’ve covered several key design drivers for DMVPN in IPsec+GRE environments, including DMVPN’s ability to ease configuration and management burden on administrators, increase IPsec scalability through better management of the IPsec SADB and GRE IDB entries, and increase IPsec scalability by eliminating processing load on the hub IPsec VPN gateway attributable to spoke-to-spoke communications. In this section, we will discuss the step-by-step process involved in hub-to-spoke and spoke-to-spoke communication examples in a DMVPN network. However, before we dive in to the step-by-step operation of DMVPN in these scenarios, it is important to understand the required components of the overall DMVPN architecture: ■

Multipoint GRE (mGRE): DMVPN requires a multipoint GRE tunnel configured on the hub IPsec VPN gateway and on its spokes. The mGRE tunnel is used to exchange routing protocols between the private IP networks at the mGRE tunnel endpoints. NHRP messages are also exchanged over the mGRE tunnel between the hub and its spokes when spoke IPsec VPN gateways attempt to create direct dynamic spoke-to-spoke IPsec VPN tunnels.

■

Next Hop Resolution Protocol (NHRP): When two private IP networks behind two spoke IPsec VPN gateways want to communicate with one another, the initiating IPsec VPN gateway uses NHRP to determine which peer it should negotiate Phase 1 and 2 IPsec SAs with. The initiating IPsec VPN gateway accomplishes this by leveraging NHRP to query the Next Hop Server (NHS) configured at the hub for the destination spoke’s physical IP address. This IP address is subsequently used when building the IPsec VPN tunnel that secures the traffic exchange between private networks across the mGRE tunnel.

■

IPsec and ISAKMP: As with standard IPsec+GRE deployments, DMVPN uses IPsec and ISAKMP for data authentication, integrity, confidentiality, and nonrepudiation. Although DMVPN does not change IPsec or ISAKMP protocols themselves, DMVPN does greatly simplify the configuration of IPsec and ISAKMP respective to traditional IPsec+GRE configuration requirements.

The components described above work in concert to deliver the overall DMVPN solution. Figure 7-5 illustrates an enterprise hub-and-spoke DMVPN design in which several spokes communicate in both a spoke-to-spoke and spoke-to-hub fashion.

290

Chapter 7: Solutions for Geographic Site-to-Site High Availability

Enterprise DMVPN Topology

Figure 7-5

EIGRP AS 10 S0/0: 200.1.2.2 Tun0: 192.168.0.2

C3845ISR-A

OSPF 10

1

3

EIGRP AS 10

Host-A

2 C7304 8 Host-A

Network_A 192.168.1.0/24

S0/0: 200.1.1.1 S0/0: 200.1.2.1 Lo0: 200.1.0.1 Tun0: 192.168.0.1

9

WAN 200.1.1.0/24

10

Network_A 192.168.2.0/24 4

EIGRP AS 10 6 7 5 S0/0: 200.1.1.2 Tun0: 192.168.0.1

C3845ISR-B

Server-B

Network_B 192.168.3.0/24

In the DMVPN topology, C3845ISR-A and B communicate to the hub securely using IPsec+GRE, without any dynamic next-hop discovery behavior with NHRP. In other words, in this topology, or any DMVPN topology, IPsec+GRE tunnels are created from hub-to-spoke once tunnel protection is enabled on the hub and spoke tunnel interfaces. The dynamic behavior of the DMVPN implementation of Figure 7-5 is introduced only when C3845ISR-A and B communicate with one another directly. In this case, NHRP is used to dynamically determine the peering information necessary to build a direct IPsec tunnel between the two spokes, effectively bypassing any crypto requirements on the hub for that specific spoke-to-spoke tunnel. The following list illustrates the sequence of events corresponding to dynamic spoke-to-spoke SA establishment between two endpoints illustrated in Figure 7-5: 1.

Host-A on Network A initiates a TCP session to Server-B on Network-B. C3845ISR-A looks up the route to Server-B and determines that the next hop is 192.168.2.1 and that the GRE interface (tunnel 0) is the egress interface, which is in the crypto switching path.

NOTE In a DMVPN environment, all traffic learned over mGRE tunnel is expected to be included in the crypto switching path. As such, there is no concept of crypto ACLs in a DMVPN design.

2.

C3845ISR-A does not have an entry in its NHRP mapping table for the next hop of 192.168.2.1, so it queries the NHRP next-hop server (192.168.0.1). All of the spokes using

Dynamic Multipoint Virtual Private Networks

291

the NHS 192.168.0.1 have a manually defined NHS definition mapped to the C7304’s loopback interface, (200.1.0.1). 3.

The NHS on C7304 returns C3845ISR-B’s physical interface IP (200.1.2.1) as the next-hop IP mapping to the next-hop IP of 192.168.2.1 in the forwarding decision by C3845ISR-A in #1.

4.

C3845ISR-A uses the C3845ISR-B’s physical interface IP returned in #3 as the IPsec peer for Phase 2 SA negotiation. C3845ISR-A uses this information to build IPsec SAs with C3845ISR-B.

5.

Server-B forwards return traffic to Host-A. Similar to C3845ISR-A in #1, C3845ISR-B does not have the appropriate next-hop entry.

6.

C3845ISR-B queries the NHRP next-hop server (192.168.0.1) on C7304 for the next-hop IP.

7.

The NHRP entry is returned by the NHS on C7304 (192.168.1.1 -> 200.1.1.1). The NHRP mapping entry is used by C3845ISR-B to forward traffic C3845ISR-A over the IPsec+GRE tunnel established in #4.

8.

Networks A and B run a separate instantiation of EIGRP (192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24 = EIGRP 10) from the physical networks used to build the IPsec tunnel in #4 (200.1.0.0/24, 200.1.1.0/24, 200.1.2.0/24 = EIGRP 1). Multicast RP updates for EIGRP 10 can now be exchanged between C3845ISR-A and B across the IPsec+GRE tunnel built in #4. Traffic can now flow bidirectionally over the IPsec+GRE tunnel between Networks A and B behind C3845ISR-A and B, respectively.

9.

Host-A forwards traffic to Server-B over the IPsec+GRE tunnels established between C3845ISR-A and B using DMVPN. The VPN Gateway, C3845ISR-A, performs GRE encapsulation on the data before encrypting it. C3845ISR-B performs decryption on the traffic before GRE decapsulating it and eventually forwarding on to Server_B.

10.

Server-B forwards return traffic to Host-A over the IPsec+GRE tunnels established between C3845ISR-A and B using DMVPN. The VPN Gateway, C3845ISR-B, performs GRE encapsulation on the returned data before encrypting it. C3845ISR-A performs decryption on the return traffic before GRE decapsulating it and eventually forwarding on to Host-A.

NOTE When the NHRP entry timeout intervals expire, the NHRP entries learned in #3 and #7 will be removed from the NHRP mapping tables on C3845ISR-A and B, respectively. This causes IPsec to tear down the VPN tunnel built between C3845ISR-A and B in #4.

The process described above illustrates several benefits of DMVPN from administrative, management, and scalability perspectives. The configurations for C7304, C3845ISR-A, C3845-ISR-B can be referenced in Examples 7-12 and 7-13 to further reinforce the illustration of these benefits. Before reviewing the required configurations for the DMVPN implementation

292

Chapter 7: Solutions for Geographic Site-to-Site High Availability

topology of Figure 7-5, let’s quickly review the DMVPN benefits against the step-by-step DMVPN operation on C3845ISR-A and B described above: ■

Zero-Touch Spoke Provisioning on the Hub (C7304): DMVPN configuration requires no maintenance on the hub (C7304) when adding spokes to the topology. In a traditional IPsec+GRE environment, a GRE tunnel interface must be added on the hub corresponding to that branch. DMVPN eliminates this requirement by using a single mGRE tunnel interface on the hub instead of a 1:1 branch-to-hub GRE interface configuration. The required hub configuration for C7304 in Figure 7-4 is provided in example 7-10.

■

Elimination of Decrypt/Reencrypt Behavior on Hub (C7304): DMVPN eliminates unnecessary decrypt/re-encrypt action on the hub. Note that, in step 4 previously, the IPsec VPN tunnel is terminated on C3845ISR-A and B. In a traditional IPsec+GRE environment, C3845ISR-A and B would terminate their IPsec+GRE tunnels on the hub, therefore requiring C7304 to decrypt/GRE decapsulate the inbound traffic from C3845ISR-A and GRE-re-encapsulate/encrypt it before forwarding it to C3845ISR-B.

■

Uniform IPsec Spoke (C3845ISR-A and B) Provisioning: DMVPN eliminates nodespecific configuration elements on C3845ISR-A and B. DMVPN accomplishes this by enabling the peer to dynamically learn peering information via NHRP from the NHS configured on the hub (C7304), as illustrated in steps 2, 3, and 5 previously. This enables administrators to push a generic, uniform, IPsec configuration to each spoke (C3845ISR-A and B). The common IPsec configuration for spoke IPsec VPN gateways C3845ISR-A and B is illustrated in Example 7-11.

As with traditional IPsec+GRE, the ISAKMP must be configured to establish the Phase 1 SAs that DMVPN will use to build Phase 2 SAs. Unlike the configurations used earlier in this chapter, this design uses RSA-sigs (the IOS default) to authenticate the IKE SA. The crypto transform used in this example is 3DES with MD5 HMAC authentication on the ciphered blocks. A crypto profile is used to bind the transform set described above to the tunnel interface used for DMVPN (Example 7-9, lines 11-12). Unlike traditional IPsec and IPsec+GRE designs, there is no need for a crypto map or crypto ACL in a DMVPN design. The IPsec transform set is applied to the interface by referencing the IPsec profile configured earlier. This effectively turns on ISAKMP on physical interface protecting the tunnel and also includes all GRE traffic sent out of this interface to be included in the crypto switching path. As such, there is no concept of a crypto ACL for defining crypto-protected traffic flows in a DMVPN. Instead, all traffic forwarded out of the GRE interface with tunnel protection enabled will be encrypted using the appropriate crypto transform. NHRP is used to dynamically learn next-hop addresses for spoke-to-spoke GRE tunnel terminations. NHRP Authentication is performed in cleartext, as shown in Example 7-10, line 18. Additional authentication is provided at the GRE layer using a tunnel key, as shown in Example 7-10, line 25. The NHRP network ID shown in Example 7-10, line 20, must be

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. TIP The GRE tunnel maximum transmission unit (MTU) can be adjusted to avoid fragmentation issues that could lead to performance issues if reassembly is required prior to decryption at the opposite end of the tunnel. Example 7-10, line 14, illustrates how this can be done on a DMVPN hub router. For more information on proper handling of IP fragmentation in IPsec VPNs, please refer to Chapter 4. The IP address of the tunnel interface is injected in to EIGRP 10. The routing protocol configuration in this design is configured in the same fashion as traditional IPsec+GRE: EIGRP 10 is used as the routing protocol for the tunnel interfaces and the private networks communicating over the IPsec+GRE DMVPN tunnels, while OSPF is used as the routing protocol for DMVPN IPsec and GRE tunnel establishment. Disabling split horizon for EIGRP AS 10 allows RP updates to be exchanged from spoke to spoke. Updates flow in to the mGRE tunnel interface on the hub and are then transmitted out of the hub to the destination spoke. EIGRP split horizon prevents this behavior, and is on by default, so it must be explicitly disabled when using EIGRP to route between private networks over the DMVPN IPsec+GRE infrastructure. DMVPN Hub Configuration for C7304 (Figure 7-5)

Example 7-10 1 2

crypto ca trustp oint IOS_C A1 enrol lment url http://200 .1.2.100

3

!

4

crypto isakmp po licy 10

5 6

hash md5 group 2

7

crypto isakmp ke epalive 10

8

!

9

crypto IPsec tra nsform-set dmvpn7 e sp-3des esp-m d5- hmac

10 ! 11 crypto IPsec profile chap7-dmvpn-profile 12

set t ransform-s et dmvpn7

13 ! 14 interface Tunnel0 15

ip ad dress 192. 168.0.1 25 5.25 5.255.0

16

no ip redirects

17

ip mt u 1416

18

ip nh rp authent ication dm vpn7

19

ip nh rp map mul ticast dyn amic

20

ip nh rp network -id 7

21

ip nh rp holdtim e 360

22

no ip split-hor izon eigrp 10

continues

294

Chapter 7: Solutions for Geographic Site-to-Site High Availability

DMVPN Hub Configuration for C7304 (Figure 7-5) (Continued)

Example 7-10 23

tunne l source F astEtherne t0/0

24

tunne l mode gre multipoin t

25

tunne l key 0

26

tunne l protecti on IPsec p rofile chap7 -dmvpn-profil e

In terms of encryption and routing processes, the configuration of the DMVPN spoke in Example 7-11 is similar to that of the DMVPN hub provided in Example 7-10. Unlike the hub (which is actually the NHS and is aware of all spoke addresses), the spoke dynamically learns next hop addresses for spoke-to-spoke GRE tunnel terminations via NHRP by querying the NHS. Like the hub, the spoke performs NHRP Authentication in cleartext, and additional authentication is provided at the GRE layer using a tunnel key. The NHRP network ID shown must match the hub in order for the spoke to effectively use the hub as the NHS for resolving next-hop queries. A static NHRP map (Example 7-11, line 18) is required on the spoke to allow queries to the NHS (192.168.0.1) to be mapped to the physical interface of the NHS itself (200.1.1.1). The spoke is then configured to use this static map to query for the unknown next-hop IP addresses using NHRP. Although the NHS is defined as a tunnel interface, it is manually mapped to a physical interface, as shown previously in this example. The NHS responds to NHRP next-hop queries that are subsequently used by DMVPN for dynamic spoke-to-spoke IPsec VPN tunnel establishment. DMVPN Spoke Configuration for C3845ISR-A and B (Figure 7-5)

Example 7-11 1 2

crypto ca trustp oint IOS_C A1 enrol lment url http://200 .1.2.10 0

3

!

4

crypto isakmp po licy 10

5 6

hash md5 group 2

7

crypto isakmp ke epalive 10

8

!

9

crypto IPsec tra nsform-set dmvpn7 esp-3des esp- md5- hmac

10 ! 11 crypto IPsec profile chap7-dmvpn-profile 12

set t ransform-s et dmvpn7

13 ! 14 interface Tunnel0 15

ip ad dress 192. 168.0.3 25 5.2 55.255.0

16

ip mt u 1416

17

ip nh rp authent ication dm vpn7

18

ip nh rp map 192 .168.0.1 2 00.1.1. 1

19

ip nhr p network- id 7

20

ip nhr p holdtime 600

21

ip nhr p nhs 192. 168.0.1

22

tunnel source Et hernet0/0

23

tunnel destinati on 200.1.1 .1

24

tunnel key 0

25

tunnel protectio n IPsec p ro file chap7-d mvpn-profil e

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 VPN’s tunnel termination point is designed to be, the availability of the IPsec VPN can still be dramatically affected if the appropriate Geographic HA design considerations are not accounted for. In this chapter, we’ve reviewed several sound design alternatives for providing Geographic HA, including: ■

Reverse Route Injection with Multiple IPsec Peers

■

IPsec+GRE Tunnels with Multiple Crypto Map Process IDs

■

Dynamic Multipoint Virtual Private Networks

Although all of these Geographic HA options are sound in certain design scenarios, the most paramount design driver that a network architect should address in the context of Geographic HA is the need to include IP multicast traffic in the crypto switching path. If it is deemed necessary that IP multicast forwarding must be enabled in the crypto switching path, the design alternatives available for geographic HA are quickly focused on IPsec+GRE alternatives. While RRI is still usable with GRE, it becomes substantially less desirable as dynamic multicast RP updates (e.g., RIP, EIGRP, OSPF, and so on) can be exchanged across the GRE tunnel, effectively precluding the need for RRI. Network architects should be wary that GRE encapsulation required in IPsec+GRE tunnels does affect the forwarding path on the IPsec VPN gateway. If the GRE encap/decap operation is not done in the fast path on the VPN platforms in your design, the GRE encap/decap could introduce a bottleneck in the IPsec+GRE switching path, potentially diminishing the value of hardware crypto accelerators that might be available on the IPsec VPN platform. If IP multicast forwarding is not required in the crypto switching path, RRI could be used as an alternative to IPsec+GRE in this scenario, eliminating the need for GRE encap/decap and enabling network architects to take full advantage of the crypto hardware accelerators on their IPsec VPN gateways. The key takeaway to consider when choosing IPsec+GRE (including DMVPN) or RRI is careful evaluation of the need for IP multicast forwarding, and careful consideration of RRI-based geographic HA when IP multicast is not required in the crypto switching path. DMVPN is a form of IPsec+GRE that dramatically decreased the complexity of configuration and management in large-scale IPsec+GRE designs. Additionally, DMVPN can be configured such that spokes can be provisioned without any additional configuration on the hub. This is a very attractive feature of DMVPN, as it eliminates the possibility of misconfiguration on the hub IPsec router during the addition of new spokes that would damage communications of those IPsec spokes already included in the DMVPN. Additionally, as DMVPN does not require crypto map configuration (including crypto ACL and peer configuration), DMVPN spoke configuration can be deployed uniformly across different spokes, as shown in our DMVPN configuration examples relevant to the design topology of Figure 7-5.

CHAPTER

8

Handling Vendor Interoperability with High Availability IPSec is a standards-based protocol, and as such, the Internet Engineering Task Force (IETF) and other standards bodies have provided substantial requirements to meet the standards defined in the IETF’s IPSec-related RFCs. However, there are no requirements currently defined by the IETF that specifically address IPSec High Availability (HA) requirements. This chapter examines several key components of IPSec virtual private network (VPN) design that make up a highly available design in a multi-vendor deployment. Within the context of these topics, this chapter discusses several barriers to HA design that vendor HA interoperability presents. The chapter then covers several options within IPSec itself that can be used as design alternatives to deliver a certain degree of HA in a vendor-diverse environment.

Vendor Interoperability Impact on Peer Availability In an IPSec HA environment, it is not only critical to determine the availability of both IPSec VPN tunnel endpoints, but also to quickly determine when a tunnel endpoint has become unavailable. Design issues discussed within this context all pertain to IPSec peer availability— the ability to determine the availability of a remote peer and to rapidly detect the change in a remote peer’s availability. This chapter discusses several vendor interoperability path availability limitations that preclude HA and must therefore be addressed in an IPSec HA environment, including the inability to specify multiple peers and the lack of peer-availability mechanisms.

The Inability to Specify Multiple Peers Figure 8-1 shows a network in which a remote branch office connects across an ISP to its campus internet edge, where there exist two VPN headend routers that are aggregating the termination of IPSec VPN tunnels from all remote branches. In this configuration, the enterprise has invested in out-of-chassis HA at their IPSec aggregation points. The solution does not use virtual interfaces (Hot Standby Router Protocol/Virtual Router Redundancy Protocol [HSRP/ VRRP]) but instead relies on the ability of the branch to failover to the redundant aggregation point when the primary aggregation point becomes unavailable.

298

Chapter 8: Handling Vendor Interoperability with High Availability

Figure 8-1

Vendor Interoperability and Peer Availability: Inability to specify multiple peers

Redundant Peers without Peer Availability Mechanism

Site A

C7206VXR-B1

Site B

4

Si

1

3

C2800ISR-A1 IPSec-GW-A1

Prim

ary IP

Sec V

Si

PN T unne

l

5

2

C7206VXR-A1 GRE Tunnels on Redundant Peers without Peer Availability Mechanism

Site A

C7206VXR-B1

Cleartext failover path available if encryptor allows traffic to pass without active IKE and IPSec SAs.

Site B Si

C2800ISR-A1

GRE GRE + IPS ec ec VP N Tun nel

Prima

ry IPS

IPSec-GW-A1

Si

C7206VXR-A1 Peering to an HSRP Virtual Interface – No Peer Availability Mechanism

Site A

Site B C7206VXR-B1

IPSec-GW-A1

C2800ISR-A1

l

unne PN T

ver) (Failo

cV IPSe

Prima

Si

HSRP Virtual Interface with SSO

ry IPS

ec VP

N Tun

nel

Si

C7206VXR-A1

In this scenario, the remote VPN gateway does not have the ability to define multiple IPSec peers, Reverse Route Injection (RRI), or IPSec+GRE. Instead, the branch encryptor, IPSec-GW-A1, relies on manually defined static routes to preserve continuity between the two routed domains at Sites A and B across the IPSec VPN tunnel. Therefore, the expected behavior is as follows (as numbered in Figure 8-1): 1.

IPSec-GW-A1 is configured to negotiate an IPSec VPN tunnel with C7206VXR-A1 with the IP address of 200.1.1.1. IPSec-GW-A and C7206VXR-A1 successfully negotiate Phase 1 and 2 SAs with each other to establish the IPSec VPN tunnel.

2.

A failure on the serial link between C2800ISR-A1 and C7206VXR-A1 occurs, forcing traffic across the redundant serial link between C2800ISR-A1 and C7206VXR-B1.

Vendor Interoperability Impact on Peer Availability

299

3.

IPSec-GW-A1 does not support the definition of multiple IPSec peers and is therefore incapable of negotiating a Phase 2 Security Assotiation with C7206VXR-B1.

4.

Because the traffic flows to be included in the crypto switching path on IPSec-GW-A1 remain consistent before and after the failure of the serial link between C7206VXR-A1 and C2800ISR-A1, IPSec-GW-A1 will continually try and fail to encrypt traffic using the IPSec SA with C7206VXR-A1, which is now unavailable.

5.

IPSec-GW-A1’s Phase 2 negotiations continually fail, causing all traffic flows in the crypto switching path to be discarded.

It is important to consider that in number 5, above, the results depend heavily on the capabilities of IPSec-GW-A1. For example, if IPSec-GW-A1 has the ability to distinguish between ciphertext and cleartext traffic flows (as is the case with crypto ACLs), then IPSec+GRE could be used to differentiate the traffic flows (flows would be based on source and destination GRE tunnel endpoints) by encapsulating them in GRE before the traffic were to reach IPSec-GW-A1 for crypto processing. Because IPSec-GW-A1 is still incapable of negotiating an IPSec SA with a redundant peer, the redundant path cannot be leveraged for ciphertext communications. However, the redundant path could still be used for cleartext data transfer, since IPSec-GW-A1’s crypto ACL equivalent would be configured to bypass crypto operations for the redundant GRE tunnel traffic. Although this method may be unacceptably insecure in failover scenarios, it does provide a cleartext alternative in emergency situations. Another solution to this problem is to somehow combine the two peering endpoints on C7206VXR-A1 and C7206VXR-B1 into a single yet redundant point of termination for remote IPSec endpoints. This would provide an HA solution for the vendor-diverse environment discussed above that is independent of the operation of IPSec-GW-A1 in Step 5. Recall that in Chapter 6, “Solutions for Local Site-to-Site High Availability,”we discussed the option of using HSRP or VRRP to create a virtual interface for tunnel termination point redundancy. In this scenario, HSRP or VRRP could be deployed between C7206VXR-A1 and C7206VXR-B1 to provide the same out-of-chassis HA benefits while presenting a single tunnel termination point for the branches. NOTE For the purposes of this chapter, the problem is presented only in the context of multiple tunnel termination points to illustrate issues with IPSec HA interoperability. For more information on stateful and stateless IPSec HA designs using HSRP and VRRP, please refer to Chapter 6, “Solutions for Local Site-to-Site High Availability.”

Although there are multiple widely deployed solutions, such as stateful and stateless HA using virtual interfaces, there are other alternatives for handling vendor interoperability within HA, such as QM Delete Notify, relying on IPSec and IKE SA lifetimes, and Invalid SPI recovery.

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. NOTE Cisco VPN concentrators, clients, and couters supporting IPSec provide for several mechanisms for managing peer availability, including IKE keepalives and Dead Peer Detection (DPD). For a more detailed discussion of IKE keepalives and DPD, please refer to Chapter 5, “Designing for High Availability.”

Figure 8-2 illustrates a network in which there is a remote IPSec VPN gateway that is dually homed to a pair of IPSec VPN headend devices at the enterprise’s headquarters. Figure 8-2

Lack of Peer Availability Mechanisms and the Impact on IPSec VPN Reconvergence

Redundant Peers without Peer Availability Mechanism

Site A

Site B C7206VXR-B2

4 1

3

nnel

Si

N Tu

ec VP

IPS dary

n Seco

C2800ISR-A2 IPSec-GW-A2

Prim

ary IP

Sec V

PN T unne

Si

l

2

C7206VXR-A2

The remote VPN gateway, IPSec-GW-A2, supports the use of multiple peers but does not support any peer availability mechanisms outside of those required by the RFC. For example, IPSec-GWA2 does not support IKE keepalives or DPD, but as per RFC 2401, IPSec-GW-A2 does associate

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 traffic that was in the crypto path to use the redundant tunnel termination point on C7206VXR-B2 (200.1.1.5).

2.

IPSec-GW-A2 does not have a mechanism for determining that the availability of the peer used to populate the Phase 2 SA in its Security Assotiation Database (SADB) (200.1.1.1) is now unavailable. IPSec-GW-A2 therefore waits for the lifetime of the Phase 2 SA in its SADB to expire.

3.

Upon expiration of the existing Phase 2 SA lifetime in IPSec-GW-A2’s SADB, IPSec-GWA2 then tries to renegotiate Phase 1 and 2 SAs with 200.1.1.1, which is still unavailable. IPSec-GW-A2 initiates Phase 1 and 2 SA negotiations with the redundant peer, C7206VXRB2 (200.1.1.5), after failing to negotiate SAs with C7206VXR-A2.

The impact on HA in this situation is realized in step 3. Although the system eventually reconverges after the lifetime of the Phase 2 SA (3600 seconds by default) expires, application data is being dropped while the stale SA remains in the SADB. The presence of the stale SA in IPSec-GW-A2 effectively inserts an unacceptably large delay in the overall reconvergence of the IPSec VPN onto the redundant path. If there were peer availability mechanisms present to speed the detection of the stale SA left over from the failure situation described in Figure 8-2, then the overall reconvergence process of the IPSec VPN would be greatly expedited. For more information on the operation IPSec with IKE Keepalives and Dead Peer Detection, please refer to Chapter 5, “Designing for High Availability.” We’ve discussed two popular options for expediting the detection of stale SAs in HA environments, IKE keepalives and DPD, and presented the design alternatives accordingly in Chapters 5 and 6. It is therefore important to integrate these options into the design of the IPSec VPN where possible. However, there may be situations where this is not possible, such as the scenario presented in Figure 8-2. Later in this chapter, we will discuss several design alternatives for handling this design consideration when peer availability mechanisms are not supported on the selected IPSec VPN gateways in the system design.

Vendor Interoperability Impact on Path Availability It is critical in an IPSec HA design that the IPSec VPN gateways and intermediate routers between the two gateways are capable of supporting and managing the availability of the path which the IPSec VPN tunnel traverses. Recall from our discussion of IPSec HA design in Chapter 5 that this

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 benefit of IPSec is that it can be used to provide data confidentiality between two endpoints which are multiple hops away. One such common IPSec VPN topology that is used to encrypt communications between networks multiple hops apart from one another is that of an RAVPN deployment, in which IPSec VPN clients encrypt communication from remote network across an ISP to a VPN concentrator at the enterprise campus or internet edge De-Militarized Zone (DMZ). IPSec is also used to provide data confidentiality across routed environments in extranet deployments. In this section, we will explore the impact of limited RP support on site-to-site IPSec VPN extranet deployment, as depicted in Figure 8-3. NOTE Common IPSec VPN deployments such as remote-acess VPN (RAVPN) and extranet deployments are presented in greater detail in Chapter 4, “Common IPsec VPN Issues.” Additionally, RAVPN High Availability is discussed in detail, including configuration and design options, in Chapter 12, “Solutions for Handling Dynamically Addressed Peers.”

Figure 8-3 shows a common deployment of IPSec VPNs in an extranet environment. In this scenario, the enterprise offers connectivity to its extranet partners over the internet. As such, all extranet communications between the enterprise and its extranet partners are spanned across multiple Layer 3 hops. This design requires that the extranet partner’s IPSec gateways support adequate RP capabilities in order to establish and maintain the IPSec VPN tunnel.

Vendor Interoperability Impact on Path Availability

303

Consider the scenario in which an extranet partner’s IPSec VPN gateway does not support the appropriate RP capabilities required of this deployment. Because the IPSec VPN gateway is only capable of sending IP traffic, including all IPSec control plane traffic, to networks on the same directly connected segment, that IPSec VPN gateway is incapable of forwarding control plane traffic to the appropriate Layer 3 IPSec tunnel termination point. Figure 8-3

Lack of RP Support and the Impact on Site-to-Site IPSec VPN High-Availability Extranet Partner A IPSec-GW-A3 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.

Extranet Partner B

C7206VXR-B3

IPSec-GW-B3

Site B

Si

ISP (Layer 3 Cloud)

Extranet Partner A Si

IPSec-GW-C3

Extranet Partner B

C7206VXR-A3

Lack of L3 awareness prevents IPSec VPN gateways from establishing tunnels with peers that are not on the same L2 domain.

IPSec-GW-D3

Routing Protocol support on the extranet edge routers concentrating inbound IPSec tunnels from the extranet partners is also critically important. Without the additional Layer 3 awareness that routing protocols provide, the aggregation routers will not be able to forward IPSec and Internet Security Association and Key Management Protocol (ISAKMP) traffic to the appropriate destination extranet-partner IPSec gateways. Static routes, if supported on the gateway, provide some relief from this limitation. However, they do not address scalability and management issues that arise on the aggregation routers, since administrators must manually configure routes each time a partner residing on a different IP network is added to the extranet. Additionally, the manual configuration required when using static routes for this type of deployment reduces the usefulness of dynamic crypto maps, since the manual addition the static routing entries themselves add

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 configuration window). In many situations, lack of RP support can be addressed by the addition of a static default route (if supported) pointing to an external router that can handle the additional required RP responsibilities. One such example in which this is common is when a PIX firewall is used to terminate IPSec VPN connections. Regardless of the workaround used to add the required Layer 3 capabilities, it is important that the Layer 3 infrastructure supporting the IPSec VPN tunnel is scalable, functional, and can quickly adapt to changes forcing reconvergence within the IPSec VPN tunnel itself.

IPSec HA Design Considerations for Lack of RRI Support Reverse Route Injection (RRI) enables IPSec VPN gateways to dynamically inject VPN routes into their local protected routed domain upon the establishment of a Phase 2 SA. RRI therefore serves as an effective method for preserving dynamic routing information for unicast traffic across an IPSec VPN tunnel. In Figure 8-4, there must be a means to exchange RP information between the two routed domains on the opposite ends of the IPSec VPN tunnel (routed domains A and C). Figure 8-4

IPSec Vendor Interoperability and Lack of RRI Support. L2 L3 L3 nodes will not have entries for routed domain C, causing failures at the first L2/3 boundary within routed domain A.

RRI

Server_B4

IPSec VPN Tunnel

Si

Si

Service Provider (Routed Domain B) Si Si

IPSec VPN Tunnel

Routed Domain C RRI

L2 L3 Host_A4

Lack of RRI support prevents networked nodes on domain A from learning of routes to routed domain C.

Routed Domain A

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 A’s VPN gateways (IPSec-GW-A4 and IPSec-GW-B4) do not support RRI (and are not equipped nor configured for any other means of routing information propagation), all the routing tables on all other nodes within segment A will not contain any of the routes for segment B. Therefore, Host_A’s communications to Server_B will fail at the first Layer 2/3 boundary it encounters within segment A. RRI would solve this problem by dynamically creating a static route based on the protected address space populated in IPSec-GW-A4’s SADB upon successful negotiation of a Phase 2 SA. These static routes can then be redistributed into segment A’s RP to populate the routing tables of the remaining Layer 3 nodes within the segment. NOTE RRI is introduced in greater detail in Chapter 5, “Designing for High Availability.” For more information on Local and Geographic HA design considerations, please refer to Chapters 6, “Solutions for Local Site-to-Site High Availability,” and 7, “Solutions for Geographic Site-to-Site High Availability,” respectively.

IPSec HA Design Considerations for Lack of Generic Routing Encapsulation (GRE) Support IPSec+GRE provides a means to exchange encrypted multicast RP updates across an IPSec VPN tunnel, thereby serving as an effective path availability design alternative to RRI. Additionally, IPSec+GRE designs provide effective support for native multicast traffic flows themselves, while native RRI does not, thereby making IPSec+GRE the compelling design alternative where multicast traffic must be transmitted with data confidentiality in the crypto switching path. For the purposes of our discussion here, we will consider an extreme case in which GRE encapsulation is not supported at all on a VPN gateway terminating an IPSec tunnel (shown in Figure 8-5).

306

Chapter 8: Handling Vendor Interoperability with High Availability

Figure 8-5

IPSec Vendor Interoperability and Lack of GRE Support. C2800ISR-A5 uses IPSec+GRE, but IPSec-GW-B5 can only terminate the IPSec tunnel (not the GRE tunnel).

Si

GRE Tunnel

IPSec Tunnel

RP Update

IPSec-GW-B5

RP Update

Multicast Receivers

C2800ISR-A5

Multicast Traffic

Multicast traffic cannot pass through the IPSec VPN without prior GRE encapsulation.

Si

Multicast Sender

Figure 8-5 illustrates a scenario in which multicast traffic, including RP updates, are exchanged between two extranet partners. Therefore, double-encapsulation (IPSec+GRE) is used to support the encrypted exchange of routing protocol updates and multicast application traffic between the two partners. The failure occurs on Extranet Partner B’s IPSec VPN gateway, which is capable of handling ESP encapsulation and decapsulation but is unable to handle the GRE encapsulation and decapsulation. There are varying degrees of support for GRE on IPSec VPN gateways affecting the performance of the solution. Therefore, it is important to understand the impact of all of the data permutations to be included in the switching path when selecting an IPSec gateway. TIP GRE offload scenarios are a relatively common design alternative for IPSec+GRE deployments in which there is inadequate GRE performance or support capabilities on the IPSec VPN gateway itself. For more information on IPSec+GRE with GRE offload deployments, please refer to Chapter 10, “Further Architectural Options for IPsec.”

Vendor Interoperability Design Considerations and Options At this point, we have covered some of the most prevalent and effective means to address siteto-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 vendordiverse deployments.

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 vendor’s IPSec VPN gateway, so long as that vendor’s implementation of IPSec is compliant with the RFC. Unfortunately, relying on SA lifetimes to expire before establishing a new set of SAs to a redundant IPSec gateway is the slowest of all available HA processes. As such, many alternatives to this method have been developed to speed reconvergence of IPSec VPN tunnels in HA environments. We’ve explored many of these design options in detail in previous discussions of HA, including the following: ■

IKE keepalives and dead peer detection (Chapter 5)

■

VPN concentrator clustering and the VCA protocol (Chapters 5 and 9)

■

DNS-based VPN Concentrator HA (Chapters 5 and 9)

■

Stateless HA with IKE keepalives and DPD (Chapter 6)

■

Stateful HA with SSO (Chapter 6)

■

Redundant peers with IKE keepalives and DPD (Chapter 6 and 7)

■

Redundant physical interfaces with IKE keepalives and DPD (Chapter 6 and 7)

■

Highly available (loopback) interfaces (Chapter 6)

Unfortunately, because HA is largely unaddressed by standards bodies, not all of these design options are globally available across all vendor implementations of IPSec. Now we will explore some additional alternatives to expiration of SA lifetimes that address potential limitations introduced by vendor interoperability in platform and vendor-diverse IPSec HA designs.

SADB Management with Quick Mode Delete Notify Messages Recall from our discussions in Chapter 3, “Basic IPsec VPN Topologies and Configurations,” that the management of SAs in an IPSec VPN gateway’s SADB are managed over a secure channel, called an IKE security association (or Phase 1 SA). This SA can be negotiated in one

308

Chapter 8: Handling Vendor Interoperability with High Availability

of two modes—main 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 mode—quick mode. Because IKE manages the setup and teardown of IPSec SAs, there must be some means for IKE to communicate to IPSec that it must tear down its Phase 2 SAs. The IKE module in an IPSec VPN gateway accomplishes this by sending a quick mode DELETE_NOTIFY message to the IPSec module within the gateway. Consider the case in which two gateways have negotiated an IPSec VPN tunnel successfully. The Phase 2 SA lifetime is the Cisco IOS default of 3600 seconds (1 day). Due to a failure somewhere within the IPSec VPN deployment, the VPN gateways have determined that the Phase 1 SA should be reaped from the SADB (via DPD or IKE keepalives). Phase 2 SAs, however, still remain in the IPSec SADB, and packets in the crypto path are dropped until these stale SAs are removed. If the gateways support quick mode DELETE_NOTIFY messages, the IKE module in each IPSec VPN gateway will send a DELETE_NOTIFY message to the IPSec module, instructing it to remove the Phase 2 (IPSec) SAs from its SADB. The result of this behavior is quicker teardown of stale IPSec SAs so that new, valid, Phase 1 and 2 SAs can be negotiated between the peers within the IPSec VPN tunnel.

Invalid Security Parameter Index Recovery Invalid Security Parameter Index (SPI) Recovery allows for reduced IPSec recovery times when an IPSec peer resets or goes offline and then returns. Figure 8-6 shows a standard site-to-site IPSec VPN in which vendor-diverse IPSec VPN gateways are used to terminate the IPSec VPN tunnel. Figure 8-6

Expediting IPSec VPN Tunnel Recovery with Invalid SPI Recovery C2800ISR-A6 resets and recovers.

1

Si

2

IPSec-GW-B6

6

5

Invalid SPI detected

C2800ISR-A6

3

Invalid SPI notify

New phase 1 and 2 SA negotiation

4

Si

Vendor Interoperability Design Considerations and Options

309

Consider the scenario in which C2800ISR-A6 was to go offline and then return due to an interface failure, a system reset, or a power failure. When the C2800ISR-A6 goes offline, it loses its Phase 1 and 2 SA entries in its SADB. Because IPSec-GW-A6 does not support the use of IKE Keepalives and DPD, it has no ability to reap the SAs in its SADB before their lifetimes expire. In order to expedite the initiation of Phase 1 and 2 SA renegotiations between the two peers, C2800ISR-A6 must therefore have some means by which to detect that the SAs must be reaped at the opposite end so that new ones can be negotiated. Invalid SPI Recovery is used on C2800ISR-A6 to accomplish this task. The following sequence of events summarizes the events occurring after a system reset occurs on C2800ISR-A6 in the network illustrated in Figure 8-6: 1.

C2800ISR-A6 reloads due to a power failure, losing all current entries in its SADB in the process. Upon recovery and a crypto ACL match, C2800ISR-A6 attempts to build new IKE and IPSec SAs (with new SPIs) with IPSec-GW-B6.

2.

Phase 1 and 2 SA lifetimes have not expired on IPSec-GW-A6, so IPSec-GW-A6 continues to forward packets to C2800ISR-A6 using the previously negotiated (now stale) SAs with C2800ISR-A6 in its SADB.

3.

C2800ISR-A6 receives the encrypted traffic from IPSec-GW-A6 and finds no SPI in its SADB for the received traffic. C2800ISR-A6 thereby detects an invalid SPI from IPSec-GW-A6.

4.

C2800ISR-A6 forwards an INVALID_SPI_NOTIFY message to IPSec-GW-A6 over the Phase 1 SA established in Step 4.

5.

IPSec-GW-A6 receives the INVALID_SPI_NOTIFY message forwarded in Step 5 and reaps the corresponding SAs from its SADB.

6.

IPSec-GW-A6 receives traffic to be forwarded in the crypto path to C2800ISR-A6, triggering a new negotiation of Phase 1 and 2 SAs with C2800ISR-A6.

Vendor Interoperability with Stateful IPSec HA As mentioned before, vendor-interoperability issues within HA can present themselves when an IPSec VPN gateway does not support the ability to use multiple, redundant, IPSec peers. One way to solve this is to use stateful IPSec HA on the opposite end of the IPSec VPN tunnel in order to make the two peering IP addresses look as if they were one single interface. As discussed previously in Chapter 6, “Solutions for Local Site-to-Site High Availability,” this is achieved using a virtual interface with HSRP or VRRP and communicating IPSec state information between the redundant IPSec gateways participating in the HSRP or VRRP group using SSO and SCTP.

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. Addressing Vendor Interoperability HA Issues with Stateful IPSec HA with HSRP and SSO.

Figure 8-7

HSRP/VRRP virtual interface provides out of chassis tunnel termination redundancy and eliminates the need for multiple peering statements on IPSec-GW-A7.

Site A

Site B C7206VXR-B7 nnel

N Tu

c VP

IPSe

Prima

C2800ISR-A7 IPSec-GW-A7

ry IPS

ec VP

r) ilove

Si

(Fa

HSRP Virtual Interface with SSO

N Tun

nel

Si

C7206VXR-A7 Stateful HA allows for failover without renegotiating SAs, reducing the need for IKE keepalives on IPSec-GW-A7.

In this scenario, the two IPSec VPN gateways at the enterprise’s internet edge DMZ present only one HSRP virtual interface instead of multiple physical or loopback interfaces for the extranet partners’ IPSec VPN gateways to peer to. This eliminates the need for several key capabilities that would be required for HA peering to redundant interfaces: ■

Multiple Peering Statements—Only one interface (the HSRP or VRRP virtual interface) is presented to the remote IPSec VPN gateway. Therefore, only one peering statement is required on the remote VPN gateway instead of two peering statements in the case of peering to multiple redundant physical or loopback interfaces.

■

IKE Keepalives or DPD—The use of a virtual interface keeps peering information consistent during a failover scenario from the perspective of the remote IPSec VPN gateway. SSO communicates the SADB state in advance of the failure to the redundant IPSec VPN gateway, precluding the need for Phase 1 and 2 renegotiations with the redundant IPSec VPN gateway after failover.

NOTE Detailed information on stateless and stateful IPSec HA can be found in Chapter 6. Likewise, detailed operational information on IKE keepalives and DPD can be found in Chapter 5, “Designing for High Availability.”

The design benefits of stateful IPSec HA extend far beyond the added flexibility of IPSec VPN gateway selection at the opposite end of the VPN tunnel, including, among others, subsecond IPSec VPN failover convergence with HSRP. Alternatively, when cost is an issue, achieving HA with DPD and or IKE keepalives to multiple peers could be a more appropriate design option. As

Summary

311

such, flexibility in IPSec VPN gateway selection should not drive HA strategy by itself. Instead, it is important to fully understand and consider all of the design benefits of each option presented in Chapters 5 through 7 when selecting a strategy for IPSec HA.

Summary This chapter discusses several key components that compose a highly available IPSec VPN design in a multi-vendor deployment. It introduces the barriers to HA design that vendor HA interoperability presents. The chapter covers several options that exist within IPSec itself that can be used as design alternatives in delivering a certain degree of HA in a vendor-diverse environment.

CHAPTER

9

Solutions for Remote-Access VPN High Availability As workforces become more virtualized and mobile, the growth in Remote-Access Virtual Private Network (RAVPN) deployments increases, which also drives the need for IPsec High Availability (HA) in RAVPN deployments. RAVPN deployments enable employees to securely access centralized corporate resources from any location with access to the Internet. Greater productivity and efficiency is therefore enabled for sales, marketing, consulting, and any other field employee in the enterprise’s mobile workforce. In this chapter, we will expand on the Remote Access VPN design introduction provided in Chapter 3, “Basic IPsec VPN Topologies and Configurations,” while examining several different approaches to building high-availability and load balancing in Remote Access VPN designs. RAVPNs typically refer to topologies in which remote users establish a secure tunnel from a remote location using either a piece of client software on their laptop or a small hardware-based client at a home office or other small remote location. Although the secure tunneling requirement of an RAVPN can come in many different flavors such as L2TP and PPTP, our discussions in this chapter will be based on IPsec-based RAVPNs. IPsec-based RAVPNs are composed of two key components: a VPN client and a VPN concentrator. To complete the RAVPN, the VPN client (whether software or hardware based) must negotiate an IPsec VPN tunnel over an IP transport (in the case of RAVPN, this IP transport is the Internet) to the VPN concentrator. In an IPsec RAVPN, the client-side network of the tunnel is typically very small, and in many cases is limited only to a single user’s laptop. As such, there is little need for high-availability specific to the client in an RAVPN implementation. NOTE When there are significant resources on the client-side private network of the RAVPN, network architects should consider migrating the design of the remote network to a small branch site-to-site IPsec VPN deployment. For more on site-to-site IPsec VPN HA, refer to Chapter 6, “Solutions for Local Site-to-Site High Availability,” and Chapter 7, “Solutions for Geographic Site-to-Site High Availability.”

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 Definitions on the VPN Client Profile

IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination IPsec RAVPN Concentrator HA can be achieved using a virtual interface protocol such as Hot Standby Router Protocol (HSRP) or Virtual Router Redundancy Protocol (VRRP). Using HSRP or VRRP, many VPN concentrators can be made to appear as a single IPsec peer to the IPsec clients. Should a VPN concentrator in the HSRP or VRRP peer group fail, the use of a virtual interface provides resiliency to the client, enabling the client to fail its IPsec session over to another concentrator participating in the HSRP or VRRP group. In this section, we will explore several tasks to consider when selecting virtual interfaces as the RAVPN design option for RAVPN HA.

IPsec RAVPN Concentrator High Availability Using 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 defines VRRP as an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. TIP For more information on VRRP and its many uses, please refer to the following sources of information: http://www.ietf.org/rfc/rfc3768.txt http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2284/ products_tech_note09186a0080094490.shtml

In RAVPN environments, this VRRP LAN is typically a network segment attached to a firewall DMZ interface on the enterprise Internet edge. Multiple VPN concentrators will be attached to the DMZ LAN, each with their own unique physical interface IP in the VRRP group. These physical interfaces will all appear to the IPsec VPN clients as a VRRP virtual router interface. As such, the clients will need only one peer definition (the VRRP router interface) to take full advantage of the redundancy provided by having multiple concentrators in the enterprise Internet edge demilitarized zone (DMZ). Figure 9-1 illustrates an enterprise RAVPN deployment in which a cluster of three VPN concentrators is deployed in a dual-DMZ firewall design at the Internet edge. The VPN3000 concentrator configuration for IPsec, Internet Security Association and Key Management Protocol (ISAKMP), and Group/User Management is illustrated in Figures 9-2 through 9-10. Remote access VPN tunnels are typically authenticated with IKE X-Auth for per-user SA authentication granularity. Authentication using IKE X-Auth requires that a Phase 1 SA be temporarily authenticated pending successful authentication with Internet Key Exchange (IKE) X-Auth in “Phase 1.5.” The IPsec group password is used to provide the temporary authentication of the Phase 1 SA. Configuration of the RAVPN group and password on the VPN3000 is illustrated in Figure 9-2. Figure 9-3 illustrates the following parameters that can be assigned to a given IPsec VPN client during IKE Mode config. In Figure 9-3, a VPN3000 concentrator is instructed to assign clients a DNS server of 200.1.1.17 and an IP address from the range of 192.168.0.0 to its clients. Also note that, in this configuration, SEP cards 1-4 are actively participating in the acceleration of IPsec on the concentrator for this group.

IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination

Figure 9-1

Dual-DMZ VPN Concentrator Design with VRRP-Based HA Inside

DNS: 200.1.1.17

Outside

IEDGE-7304-A

To: CORE

Si IEDGE-C6509-A

PIX535-Standby

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

Internet

PIX535-Main

To: CORE

Si

IEDGE-7304-B

IEDGE-C6509-B

Inner DMZ

5

VPN3060-A Public IP: 10.1.1.1

1

Outer DMZ

4

3 4 VPN3060-B Public IP: 10.1.1.2

4948G-DMZ-PUB

4948G-DMZ-PRI All IPsec VPN concentrators participate in the same VRRP Group, using a VRRP Virtual Router IP address of 10.1.1.100.

VPN3060-C Public IP: 10.1.1.3

2

316

IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination

317

Figure 9-2

VPN3000 IPsec Group and Password Configuration

Figure 9-3

VPN3000 General Configuration (Client SEP Card, DHCP/Address Scope, and DNS Server Assignment)

Figure 9-4 illustrates the IPsec configuration for this group, including the transform (Encapsulating Security Payload (ESP) 3DES with MD5 Hash-based Message Authentication Code (HMAC) Authentication) and the tunnel type (Remote Access).

318

Chapter 9: Solutions for Remote-Access VPN High Availability

Figure 9-4

VPN3000 Group IPsec and ISAKMP Configuration

IKE mode config can be used to assign additional parameters, such as the IP subnet mask, client banner, split tunnel policy, and NAT-T policy. Figure 9-5 illustrates the configuration of these parameters for assignment to the client via IKE mode config. Figure 9-5

VPN3000 Client Configuration (Banner, NAT-T Policy, Subnet Mask Assignment, IPsec Split Tunnel Policy)

There are many different methods to assign a client an IP address, as illustrated in Figure 9-6. In this chapter, we will assign IPsec VPN clients an IP address from an address pool defined locally

IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination

319

on the IPsec VPN concentrator using IKE mode config. Figure 9-6 illustrates the corresponding configuration on the VPN3000 concentrator. Figure 9-6

Defining Address Assignment Methods on the VPN3000

Figure 9-7 illustrates the configuration of the appropriate address pool corresponding to the defined address assignment method displayed in Figure 9-6. Figure 9-7

Assigning Client Addresses from Defined IP Address Pool on the VPN3000 Concentrator

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 peruser granularity when IKE x-Auth is used. Figure 9-4 provides us with the appropriate group and password configuration for IKE Phase 1 authentication, and Figure 9-8 provides us with an example of user and password credentials that will be validated with x-Auth in “Phase 1.5” negotiation. In this case, we are using the VPN3000 itself as the user database for x-Auth. However, the VPN3000 can also be configured to authenticate user credentials supplied via x-Auth using an external RADIUS database. Figure 9-8

Creating VPN3000 Internal User Database Accounts for Authentication and Authorization with IKE X-Auth

Figure 9-9 illustrates the configuration of general RAVPN user authentication and authorization parameters for a given user account on the VPN3000. In this case, any four of the available SEP modules are available for processing the termination of this user’s IPsec VPN tunnel. IPsec is the only tunneling protocol configured for this client to use on this particular VPN concentrator. IPsec transform sets can be configured on a per-user basis. Figure 9-10 illustrates the appropriate IPsec transform configuration at the user level.

IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination

321

Figure 9-9

VPN3000 Configuration for General RAVPN User Authentication and Authorization Policies with IKE X-Auth

Figure 9-10

Defining Per-User Allowed IPsec Transform Polices with IKE X-Auth on VPN3000 Concentrators

322

Chapter 9: Solutions for Remote-Access VPN High Availability

The VPN3000 concentrator must be configured with the appropriate routing protocol information in order for transparent IP connectivity to be maintained from IPsec RAVPN clients to enterprise resources located within the IPsec VPN concentrator’s private network. The VPN3000 can support multiple means by which to achieve this: ■

Static Routing: Typically, a static default route is used to route IP traffic from the concentrator’s private network through the public interface and across the IPsec VPN tunnels. More specific static routes are required to route traffic in the opposite direction, inbound from IPsec RAVPN clients to IP-enabled resources on the enterprise’s private network.

■

OSPF: Instead of manually inserting more specific static routes pointing out of the concentrator’s private interface, these routes can be learned dynamically via Open Shortest Path First (OSPF). A popular design option is use of a static default route pointing out of the concentrator’s public interface with more specific IP subnets learned dynamically through OSPF on the concentrator’s private interface.

■

RIP: Cisco VPN3000 concentrators support Routing Information Protocol (RIP) as well as OSPF. Instead of learning more specific routes via OSPF (or manually defining static ones), RIP can be used as an alternative routing protocol on the concentrator’s public or private interfaces.

In this example, we will explore the design option of using a combination of static default routing to the public network, with more specific IP subnets learned via OSPF from the enterprise network on the VPN3000 concentrator’s private interface. Samples of the required configuration can be found in Figures 9-11 through 9-14. Figure 9-11

VPN3000 Static Default Routing

IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination

323

The VPN3000 in this example uses OSPF to route traffic out of its private interface to the enterprise’s corporate network. Figure 9-12 provides the appropriate routing configuration on the VPN3000, including OSPF area configuration and other area-level configuration parameters. Figure 9-12

VPN3000 OSPF Routing Configuration

Figure 9-13 provides the interface-level configuration of the VPN3000’s private interface, including IP address, administrative state (up/down), speed, duplex, and maximum transmission unit (MTU). Figure 9-13

VPN3000 Private Interface Configuration

324

Chapter 9: Solutions for Remote-Access VPN High Availability

Figure 9-14 provides the interface-level configuration of the VPN3000’s public interface, including IP address, administrative state (up/down), speed, duplex, and MTU. Figure 9-14

VPN3000 Public Interface Configuration

NOTE Cisco VPN3000 concentrators and ASA5500 Series VPN appliances do not support HSRP. VRRP is the only virtual router protocol for first-hop redundancy supported by the VPN3000 series VPN concentrators. Routing platforms running Cisco IOS support HSRPbased RAVPN HA, as discussed later in this chapter.

In the RAVPN HA design of Figure 9-1, network architects have elected to use VRRP-based tunnel termination for high availability. Concentrators VPN3060-A, B, and C all have public interfaces on the outside DMZ that are configured in the same VRRP group. Initially, VPN3060-A is configured as the VRRP “Master” (it has the highest configured VRRP priority in the group). As the master, VPN3060-A is responsible for sending multicast keepalive polls to the other concentrators in the VRRP group using the link local multicast IP address of 224.0.0.18. If one or both of the other concentrators does not see a configurable amount of keepalives in their corresponding timed intervals, the remaining concentrators in the VRRP group will undergo an election to assume the role as the VRRP master router. This process allows for resiliency in the concentrator cluster design, as illustrated in the following failures scenario for VPN3060-A in Figure 9-1: 1.

VPN3060-A, B, and C are all configured for VRRP on the DMZ-Outside network segment. VPN3060-A is currently the VRRP master, assuming forwarding responsibility for RAVPN clients. A link failure on VPN3060-A’s public interface causes the concentrator to become unavailable to inbound IPsec VPN sessions from the VPN clients.

IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination

325

2.

VPN3060-B and C are configured to wait three successive timed intervals to receive a VRRP router advertisement from the master router before attempting an election for VRRP master router. After missing a VRRP advertisement from VPN3060-A in the third timed interval, VPN3060-B and C attempt to elect a new VRRP master through the exchange of their own VRRP router advertisement messages. As VPN3060-B has the second highest priority next to VPN3060-A, it becomes the new VRRP master router.

3.

When VPN clients attempt to negotiate IPsec VPN tunnels with the Concentrator Cluster using the VRRP Virtual Router IP address, the VPN3060-B will now be responsible for terminating the inbound IPsec VPN tunnels.

NOTE The VPN clients in this example are configured with only one IPsec peer corresponding to the VRRP Virtual Router IP address for the IPsec VPN concentrators in that VRRP group. As such, the clients are unaware of any changes that occur in the concentrator cluster due to the failure described above—they will always use the same IP address for their IPsec peer regardless of which VPN concentrator is the master for the VRRP group.

4.

VPN3060-A is configured to preempt the other concentrators when it recovers from a failure. This means that it will proactively attempt to reassume the role of VRRP master for the VRRP group after it recovers from a failure. VPN3060-A recovers from the failure in step 1, sending out a VRRP router advertisement message causing a new reelection to occur. VPN3060 has the highest priority in the group, thereby reassuming the role of VRRP master for the VRRP group.

5.

When VPN clients attempt to negotiate IPsec VPN tunnels with the Concentrator Cluster using the VRRP Virtual Router IP address, the VPN3060-A will now be responsible for terminating the inbound IPsec VPN tunnels.

Figure 9-15 illustrates the VRRP required on all VPN concentrators in the network topology illustrated in Figure 9-1. It is critically important to consider that, in the above RAVPN design, there is no dynamic communication of IPsec configuration or state between the Master VRRP concentrator and its backup VRRP concentrators. As such, on Cisco ASA5500 and VPN3000 series IPsec VPN concentrators, VRRP-based HA options are considered to be stateless. In a VRRP-based RAVPN HA design, the master and backup concentrators must have identical IPsec and ISAKMP settings, so that clients are able to use any concentrator that happens to be the VRRP master at any given point in time. Inconsistencies in these configuration settings can lead to inconsistent success in IPsec VPN tunnel negotiation across the cluster, as some concentrators will be appropriately configured to successfully terminate inbound IPsec VPN tunnels from VPN clients, while others will not.

326

Chapter 9: Solutions for Remote-Access VPN High Availability

Figure 9-15

VPN3000 VRRP-Based IPsec RAVPN HA Configuration

TIP IOS IPsec features can be configured to support HSRP-based termination of IPsec VPN tunnels in a stateful manner between two IOS-based IPsec VPN concentrators (routers configured for RAVPN). Chapter 6 covers the comparison of stateless vs. stateful IPsec VPN tunnel termination in greater detail.

Additionally the network design illustrated in Figure 9-1 requires that all of the VPN clients use the same VRRP Virtual Router IP address for IPsec peering to the concentrator cluster. While this does provision for high availability in the concentrator cluster, it does not provision for session load balancing. We will discuss how IPsec session load balancing can be achieved in highly available RAVPN implementations using Virtual Clustering later in this chapter. In this section, we’ve discussed how VRRP can be used for VPN Concentrator High Availability. The concepts of RAVPN HA discussed above are all stateless in nature, meaning that, when VPN clients successfully negotiate IPsec VPN tunnels with the concentrator, this state is not communicated to the backup concentrators in the cluster. As such, when a failover occurs on a VPN concentrator terminating IPsec VPN sessions for multiple IPsec VPN clients, these clients must renegotiate Phase 1 and 2 SAs with the backup IPsec VPN concentrator. In the following section, we will explore a stateful RAVPN HA design using Cisco IOS-based RAVPN concentrators that enables us to avoid the renegotiation of Phase 1 and 2 SAs with the backup VPN concentrators when a failure occurs on master VPN concentrator.

IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination

327

IPsec RAVPN Concentrator HA Using HSRP HSRP operates in a similar fashion to VRRP. HSRP can therefore be used in a similar fashion to VRRP to provide IPsec Local HA. Thus far, we’ve discussed design options for providing stateless IPsec RAVPN HA in a VPN concentrator cluster design using VRRP. With Cisco IOS, the same design principals of a stateless RAVPN HA concentrator cluster design can be extended to incorporate stateful failover across different concentrators in a given cluster. This section discusses an IOS-based concentrator design that uses HSRP for stateful RAVPN high availability. In RAVPN concentrator cluster designs, HSRP provides high availability in a fashion similar to VRRP by electing an “active” (equivalent to the VRRP “master” concentrator) concentrator that is responsible for the forwarding of all traffic and session termination from all clients in the HSRP group. The other concentrators in the HSRP group are “standby” (equivalent to VRRP “backup” concentrators) until they assume active responsibilities due to a change in the network. Like VRRP, the HSRP active router sends periodic status messages to other concentrators in the HSRP group using a link local multicast address (HSRP=224.0.0.2, VRRP=224.0.0.18). If one or more concentrators in the HSRP group does not receive an HSRP status message within a configurable amount of timed windows, the standby concentrators then undergo an election to determine the new active HSRP concentrator/router. Like VRRP, the HSRP concentrator with the highest priority will assume the role of “active” and responsibilities for forwarding all traffic and terminating all inbound IPsec sessions for the HSRP group. TIP For more information on HSRP and its many uses, please refer to the following sources of information: http://www.ietf.org/rfc/rfc2281.txt http://www.cisco.com/en/US/partner/tech/tk648/tk362/tk321/tsd_technology_support_ sub-protocol_home.html

The solution for RAVPN HA discussed in this section is not primarily differentiated by the use of HSRP over VRRP. Instead, the key difference in this design is that it is stateful instead of stateless. Figure 9-16 presents a design with IOS-based VPN concentrators to deliver stateful failover across the different concentrators in the cluster. The following illustrates the HSRP-based stateful failover process for the topology depicted in Figure 9-16: 1.

VPN7301-A, B, and C are all configured for HSRP on the DMZ-Outside network segment. VPN7301-A is currently with the highest HSRP priority making it become the active concentrator and assume forwarding responsibility for RAVPN clients.

328

Chapter 9: Solutions for Remote-Access VPN High Availability

Figure 9-16

Dual-DMZ IOS-Based Concentrator Design with HSRP-Based Stateful HA.

Inside

Outside

DNS: 200.1.1.17

IEDGE-7304-A To: CORE PIX535-Standby

Si IEDGE-C6509-A

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

Internet

PIX535-Main

To: CORE

Si

IEDGE-7304-B

IEDGE-C6509-B

Inner DMZ

Outer DMZ

VPN7301-A Public IP: 10.1.1.1

3

1

1 8

7 5 2 VPN7301-B Public IP: 10.1.1.2 4948G-DMZ-PRI All IPsec VPN concentrators participate in the same HSRP Group, using an HSRP Standby Router IP address of 10.1.1.100.

4948G-DMZ-PUB

4

6

VPN7301-C Public IP: 10.1.1.3

3 2

2.

As clients successfully use the HSRP Standby IP interface currently active on VPN7301-A to terminate IPsec VPN tunnels, the state for each of these tunnels is periodically communicated using SSO and SCTP to the backup routers in the HSRP group (VPN7301-B and C).

IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination

329

TIP The stateful IPsec high availability design described here is a local IPsec HA design applied to Cisco routers running IOS and acting as a concentrator cluster in an RAVPN for IPsec VPN clients. The design leverages stateful failover concepts for site-to-site IPsec Local HA using HSRP and SSO. For more information on HSRP and SSO specifics in the context of IPsec Local HA, please refer to Chapter 6. 3.

A link failure on VPN7301-A’s public interface (GigE0/0) causes the concentrator to become unavailable to inbound IPsec VPN sessions from the VPN clients.

4.

VPN7301-B and C are configured to wait three successive timed intervals to receive a HSRP router advertisement from the master router before attempting to elect a new active HSRP router. After missing a HSRP advertisement from VPN7301-A in the third timed interval, VPN7301-B and C attempt to elect a new active HSRP router through the exchange of their own HSRP router advertisement messages. As VPN7301-B has the second highest priority next to VPN7301-A, it becomes new active HSRP router.

5.

The VPN clients that had established IPsec VPN tunnels with VPN7301-A when it was the active HSRP router in the cluster seamlessly fail their session over to VPN7301-B, the newly elected active HSRP router. This seamless transition of IPsec sessions is enabled by the proactive communication of IPsec state using SSO in step 1. Unlike the stateless HA scenario described previously using VRRP on VPN3000 and ASA5500 concentrators, the VPN clients transitioning their IPsec VPN sessions from VPN7301-A to VPN7301-B in this stateful HA failover process step do not have to renegotiate Phase 1 and 2 SAs with VPN7301-B.

6.

When VPN clients attempt to negotiate IPsec VPN tunnels with the Concentrator Cluster using the HSRP Standby IP address, VPN7301-B will be responsible for terminating the inbound IPsec VPN tunnels.

NOTE The VPN clients in this example are configured with only one IPsec peer corresponding to the HSRP Standby IP address for the IPsec VPN routers in that HSRP group. As such, the clients are unaware of any changes that occur in the concentrator cluster due to the failure described above—they will always use the same IP address for their IPsec peer regardless of which VPN router is the actively forwarding for that HSRP group.

7.

In this stateful IPsec RAVPN HA design, VPN7301-A is not configured to preempt the other routers in the HSRP group when it recovers from a failure. This means that it will rejoin the HSRP group as a standby router until another failure occurs and another HSRP election process is executed.

330

Chapter 9: Solutions for Remote-Access VPN High Availability

TIP When an IPsec device recovers and attempts to preempt other IPsec routers in the HSRP group, it will likely not have the appropriate state information to seamlessly transition the existing IPsec sessions from the existing active IPsec router. This will cause the sessions to be dropped and renegotiated with the preempting IPsec VPN router. This behavior essentially negates the use of stateful HA, reverting back to a stateless failover. In stateful HA configurations, disabling preemption enables a router to relearn IPsec session state using SSO as a standby HSRP router. As such, when another failure occurs, this router is now prepared to assume the role of the active IPsec VPN router and to seamlessly transition IPsec VPN sessions in a stateful manner. 8.

IPsec VPN clients will continue to use VPN7301-B as their IPsec RAVPN peer until a change in the network forces another HSRP election. In the meantime, VPN7301-A has recovered as a standby HSRP router in the cluster, and is receiving periodic HSRP advertisements and IPsec SSO state messages from VPN7301-B. Therefore, when a change in the network forces another HSRP election, VPN7301-A will have the appropriate IPsec SADB entries for Phase 1 and 2 SAs to the VPN clients required to seamlessly assume forwarding responsibilities for those clients as the active HSRP router without forcing the VPN clients to renegotiate Phase 1 and 2 SAs.

The design process described above effectively increases HA baselined in the VRRP-based dual-DMZ concentrator design of Figure 9-1, but provides little in the way of session load balancing across the concentrators in the cluster in active/active/active scenarios. When deploying this design, administrators face the same load-balancing challenges faced in our discussion of VRRP-based RAVPN HA concentrator cluster deployment. The stateful design described in this section can leverage the use of multiple HSRP groups to load balance across the VPN routers VPN7301-A, B, and C when all three routers in the cluster are active. Example 9-1 illustrates the configuration of the VPN routers VPN7301-A, B, and C for RAVPN IPsec session concentration using HSRP for stateful IPsec HA. In order to support IPsec stateful HA, VPN7301-A is configured to preemptively communicate the state of the SADB using SSO to VPN7301-B and C using the redundancy scheme “chap9-stateful” as shown in lines 8 and 9 of Example 9-1. Proactive communication of the IPsec SADB state to redundant IPsec gateways is accomplished with the SSO configurations in lines 11-22. The crypto engine is then instructed to use this SSO stateful failover configuration during the application of the crypto map in line 56. In addition to these SSO-specific configuration elements required for stateful failover, VPN7301-A’s configuration has several elements required for RAVPN Termination, described in the following bulleted list: ■

IKE X-Auth (Lines 4-5, 41, 43, 62, and 63): IKE x-Auth required to authenticated IKE SAs based on specific user accounts with either Terminal Access Controller Access Control System+ (TACACS+) or RADIUS (RADIUS is used in this example).

IPsec RAVPN Concentrator High Availability Using Virtual Interfaces for Tunnel Termination

331

■

IKE Mode Config—Group Key Definition (Lines 32-33): Required to complete the IKE Phase 1 SA before IKE x-Auth can occur (Phase 1.5).

■

IKE Mode Config—Client Address Assignment (Line 29): During IKE, Mode Config can be used to assign a variety of parameters to a VPN client, including IP addresses, domain names, and default gateways. Line 29 instructs the IOS VPN concentrator to assign clients IP addresses with Mode Config from the defined pool “chap9-stateful-pool.”

■

Dynamic Crypto Map Configuration (Lines 37-39): A dynamic crypto map is required, as the IPsec VPN peers’ (VPN clients) IP addresses are unknown (they will vary based on their location and assigned DHCP address).

■

Static Crypto Map Configuration (Lines 41-44): The static crypto map references the dynamic crypto map. To facilitate RAVPN Concentration, the static crypto map also references the authentication, authorization, and accounting (AAA) list to be used for authenticating and authorizing VPN clients with x-Auth. The crypto map also specifies whether or not to initiate IP address assignment or respond to an address assignment request with IKE Mode config. In this case, VPN7301-A is instructed to initiate IP address assignment with IKE Mode Config.

■

Interface-Level Crypto Configuration (Line 56): This configuration line binds all of the crypto information defined in the static crypto map “chap9-stateful-static” to the crypto interface, FastEthernet0/0, on VPN7301-A. Additionally, because the dynamic crypto map “chap9-stateful-dynamic” was previously referenced in the static crypto map, the elements referenced in the dynamic crypto map configuration are also bound to this crypto interface. Note that the inter-device redundancy configuration “chap9-stateful” is appended to the end of the interface crypto map configuration. This effectively binds the stateful HA SSO redundancy configuration “chap9-stateful” to the crypto process configured for FastEthernet0/0.

■

Address Pool Definition (Line 59): IKE Mode Config has been previously configured to assign VPN clients from IP addresses from this pool, “chap9-stateful-pool.”

■

RADIUS Server Configuration (Line 62-63): These commands configure the VPN7301-A to use the RADIUS Server IP “10.0.0.101” and key “cisco123” for authenticating VPN client credentials using IKE x-Auth.

Example 9-1

VPN7301—A Stateful IPsec RAVPN HA Configuration

1

show r unning-conf ig VPN7301-A#s

2

!

3

!

4

aaa authentication login ravpn-auth group radius

5

aaa authorization network ravpn-auth group radius

6

!

7

!

8

redundancy inter-device

continues

332

Chapter 9: Solutions for Remote-Access VPN High Availability

Example 9-1

VPN7301—A Stateful IPsec RAVPN HA Configuration (Continued)

9

scheme standby chap9-stateful

10 ! 11 ipc zone default 12

association 6

13

no shutdown

14

protocol sctp

15

local-port 6666

16

local-ip 10.1.1.1

17

retransmit-timeout 200 5000

18

path-retransmit 10

19

assoc-retransmit 20

20

remote-port 6666

21

remote-ip 10.1.1.2

22

remote-ip 10.1.1.3

23 ! 24 ! 25 crypto isakmp policy 10 26

authentication pre-share

27

hash md5

28

group 2

29 crypto isakmp client configuration address-pool local chap9-stateful-pool 30 31 ! 32 crypto isakmp client configuration group chap9-stateful 33

key cisco123

34 ! 35 crypto IPsec transform chap9-stateful-trans esp-3des esp-md5-hmac 36 ! 37 crypto dynamic-map chap9-stateful-dyn 10 38

set transform-set chap9-stateful-trans

39

reverse-route

40 ! 41 crypto map chap9-stateful-static client authentication list ravpn-auth 42 crypto map chap9-stateful client configuration address initiate 43 crypto map chap9-stateful-static isakmp authorization list ravpn-auth 44 crypto map chap9-stateful-static 10 IPsec-isakmp dynamic chap9-stateful-dyn 45 ! 46 ! 47 interface FastEthernet0/0 48

ip address 10.1.1.1 255.255.255.0

49

ip directed-broadcast

50

speed auto

51

half-duplex

52

standby 1 ip 10.1.1.100

53

standby 1 priority 30

54

standby 1 preempt

IPsec RAVPN Concentrator HA Using the VCA Protocol

Example 9-1

333

VPN7301—A Stateful IPsec RAVPN HA Configuration (Continued)

55

standby 1 name chap9-stateful-static

56

crypto map chap9-stateful-static redundancy chap9-stateful

57 ! 58 ! 59 ip local pool chap9-stateful-pool 192.168.1.1 192.168.1.100 60 ! 61 ! 62 radius-server host 10.1.1.101 auth-port 1645 acct-port 1646 63 radius-server key cisco123

NOTE VPN7301-B and C are configured in a similar manner to VPN7301-A. They use the same radius server and key and the same HSRP standby address among other similarities. Additionally, the IPsec and ISAKMP configurations are identical between VPN7301-A, B, and C. The main differences on VPN7301-B and C are: SSO Peering Definitions: VPN7301-B must peer with A and C, and VPN7301-C must peer with A and B. HSRP Priority Definition: VPN7301-A and B are configured with lower HSRP priorities. Physical IP Addressing: VPN7301-B’s and C’s physical IP addresses are different from VPN7301-A, following the addressing information provided in Figure 9-16.

At this point, we’ve explored both stateful and stateless RAVPN HA designs, illustrating how system reconvergence can be expedited through the proactive communication of SADB state from the active concentrator (active router in the HSRP group) to the backup concentrators (standby routers in the HSRP group) resulting in a seamless failover from the VPN client’s perspective (no renegotiation of IKE Phase 1 or 2 SAs). However, stateful and stateless IPsec VPN designs share one common design limitation—neither provide for IPsec session load balancing, as all IPsec VPN client connections are terminated on the active HSRP (or master VRRP) router or concentrator in the concentrator cluster. Cisco VPN concentrators support dynamic per-session load balancing across the different concentrators in the cluster using Virtual Cluster Agent (VCA), which we will discuss in the following section.

IPsec RAVPN Concentrator HA Using the VCA Protocol VCA has become a very popular means by which to provide Local HA in VPN concentrator cluster designs. In a design that uses VCA, the VPN concentrators participating in the cluster are known as VCAs. The VCAs each communicate their status to one another using the VCA protocol. VCA architecture is proprietary to Cisco Systems IPsec VPN concentrators. Additionally, VCA

334

Chapter 9: Solutions for Remote-Access VPN High Availability

is not supported in Cisco IOS, and is supported only in VPN3000 series concentrators and the ASA5500 series Adaptive Security Appliances. The example in this section uses ASA5500s to illustrate the load-balancing and HA concepts provided by VCA. Example 9-2 provides the IPsec RAVPN user, group, IPsec, and ISAKMP configurations that will support the VCA configurations illustrated in Figure 9-17, Figure 9-18, and Figure 9-19 later in this section. The ASA5540 VPN Appliance configuration in Example 9-2 requires security level interface configurations in the same manner that one would configure a PIX firewall. From the ASA5540 VPN concentrators perspective, configuring security level 0 on Ethernet0/0 makes Ethernet0/0 the VPN concentrator public interface. Defining security level 100 on Ethernet0/1 makes it the VPN concentrator’s private interface. In a manner similar to the IOS configuration previously discussed in Example 9-1, a dynamic crypto map, “chap9-3-dyn,” is configured on all ASA5500s to accommodate change in VPN client IP addresses as they move from one location to another (line 27). RRI will inject a route for the host in to the corporate network after the SADB is populated with a Phase 2 SA for that IPsec VPN client (line 28). The dynamic crypto map is referenced in the static crypto map “chap9-3-stat” so that it can be bound to one or more physical interfaces on ASA5540-A. ISAKMP configuration ASA5540 is configured in two parts. First, a standard ISAKMP policy is configured, including authentication method, encryption cipher, hash, SA lifetime, and Diffie-Hellman Group Modulus. This part of ASA5540’s ISAKMP configuration is provided in Example 9-2, lines 31-36. Second, a tunnel group is configured to configure various extensions to IKE, including IKE x-Auth and IKE Mode Config. The tunnel-group configuration for ASA5540 is included in Example 9-2, lines 39-45. The tunnel group configuration for ASA5540-A in Example 9-2 enables the following capabilities: ■

Tunnel-Group Type Definition (Line 39): The Tunnel Group is defined as a Remote Access Tunnel group, enabling parameters for RAVPN within the tunnel group configuration options.

■

IKE Mode Config—Address Assignment (Line 41): Allocates IP addresses from the range specified in the pool “chap9-3-pool” when assigning VPN clients their IP addresses.

■

IKE X-Auth—Authentication (Line 42): Specifies the AAA Server Group “chap9-3-xauth” (which in turn uses a RADIUS server, “10.1.1.101,” and a key of “cisco123”) for use when authenticating VPN clients with RADIUS.

■

IKE X-Auth—Authorization (Line 43): Specifies the AAA Server Group “chap9-3-xauth” (which in turn uses a RADIUS server, “10.1.1.101,” and a key of “cisco123”) for use when authorizing VPN clients with RADIUS.

IPsec RAVPN Concentrator HA Using the VCA Protocol

■

335

IKE Pre-Shared Group Key (Line 45): A group key is required to complete IKE Phase 1 Authentication before IKE x-Auth can occur during Phase 1.5 negotiation.

WARNING Normally, wildcard or preshared group keys are not recommended as a best practice unless they are supplemented with a more granular form of authentication such as IKE x-Auth. This is because of the group member eviction difficulties they present. When group keys are used with IKE x-Auth, this risk is mitigated because of the required authentication of individual user credentials in conjunction with the validation of the group key. Caution should be taken when wildcard or group preshared keys are used without a more granular supplemental form of IKE authentication such as IKE X-Auth. Example 9-2

ASA5540—A Basic IPsec RAVPN Configuration (Figure 9-17, Figure 9-18, and Figure 9-19)

1

ASA5550-A# show run

2

: Saved

3

:

4

ASA Version 7.0(2)

5

names

6

!

7

interface Ethernet0/0

8

nameif outside

9

security-level 0

10

ip address 10.1.1.1 255.255.255.0

11 ! 12 interface Ethernet0/1 13

nameif inside

14

security-level 100

15

ip address 10.0.0.1 255.255.255.0

16 ! 17 ! 18 aaa-server chap9-3-xauth protocol radius 19 aaa-server chap9-3-xauth host 10.0.0.101 20

key cisco123

21 ! 22 ! 23 ip local pool chap9-3-pool 192.168.1.1-192.168.1.100 24 ! 25 ! 26 crypto IPsec transform-set chap9-3 esp-3des esp-md5-hmac 27 crypto dynamic-map chap9-3-dyn 10 set transform-set chap9-3 28 crypto dynamic-map chap9-3-dyn 10 set reverse-route 29 crypto map chap9-3-stat 10 IPsec-isakmp dynamic chap9-3-dyn 30 crypto map chap9-3-stat interface outside 31 isakmp enable outside 32 isakmp policy 10 authentication pre-share

continues

336

Chapter 9: Solutions for Remote-Access VPN High Availability

Example 9-2

ASA5540—A Basic IPsec RAVPN Configuration (Figure 9-17, Figure 9-18, and Figure 9-19) (Continued)

33 isakmp policy 10 encryption 3des 34 isakmp policy 10 hash sha 35 isakmp policy 10 group 2 36 isakmp policy 10 lifetime 86400 37 ! 38 ! 39 tunnel-group chap9-3-group type IPsec-ra 40 tunnel-group chap9-3-group general-attributes 41

address-pool chap9-3-pool

42

authentication-server-group (outside) chap9-3-xauth

43

authorization-server-group chap9-3-xauth

44 tunnel-group chap9-3-group IPsec-attributes 45

pre-shared-key *

46 Cryptochecksum:4b678d738ff3aa2976e916cca5687442 47 : end

NOTE The configurations for ASA5540-B and ASA5540-C use the same base RAVPN IPsec configuration. The only difference is the change in IP addresses on the Inside and Outside interfaces: ASA5540-B, Outside = 10.1.1.2/24 ASA5540-B, Inside = 10.0.0.2/24 ASA5540-C, Outside = 10.1.1.3/24 ASA5540-C, Inside = 10.0.0.4/24

Unlike single-group VRRP or HSRP-based IPsec RAVPN HA designs, all VPN concentrators in a VCA-enabled cluster forward traffic in a load-balanced fashion. VCA achieves this by directing incoming sessions to the least-loaded concentrator in the VCA cluster. Like HSRP and VRRPbased RAVPN HA designs, VCA employs the use of configurable priority levels to elect a “master” VCA in the cluster (the other concentrators in the cluster are referred to as “secondary” concentrators). The master VCA is responsible for polling the secondary concentrators for their current load attributable to inbound IPsec VPN client session processing. Unlike HSRP and VRRP, there is no concept of preemption, meaning that, when a VCA rejoins concentrator cluster, it will join as a secondary concentrator. With VCA, election of the master concentrator occurs only when the current master concentrator fails. Figure 9-17 illustrates a VCA-enabled concentrator cluster design that we will use to illustrate the designation of a master concentrator in the VCA cluster.

IPsec RAVPN Concentrator HA Using the VCA Protocol

Figure 9-17

337

VCA Cluster Master Concentrator Election

Inside

DNS: 200.1.1.17

Outside

IEDGE-7304-A

To: CORE

Si

PIX535-Standby

IEDGE-C6509-A

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

Internet

PIX535-Main To: CORE

Si

IEDGE-7304-B

IEDGE-C6509-B

Inner DMZ

Outer DMZ 1a

ASA5510-A is the VCA Master resulting from Step 1, as it was the first concentrator powered on. Subsequent concentrators powered on are always secondaries, even if they have a higher VCA priority.

1b

ASA5540-A Public IP: 10.1.1.1

3

6

When ASA5510-A recovers, it does not resume its previous role as VCA master, regardless of its configured priority. Instead, ASA5510-C remains the VCA master until it becomes unavailable and causing another VCA election.

ASA5540-B Public IP: 10.1.1.2

2

4948G-DMZ-PRI

4948G-DMZ-PUB

All three concentrators, ASA5510-A, B, and C participate in the cluster, the VCA Virtual IP address is 10.1.1.100.

1c When ASA5510-A becomes unavailable in Step 3, ASA5510-B and C undergo an election process to determine the VCA master. ASA5510-C is elected VCA master as it has the highest priority between ASA5510-A and C.

ASA5540-C Public IP: 10.1.1.3

4 5

2

The following ordered sequence of events corresponding to the network topology in Figure 9-17 describes the VCA master election process when all three VPN concentrators are brought online

338

Chapter 9: Solutions for Remote-Access VPN High Availability

together, and the election process that occurs when the VCA master (ASA5540-A) goes offline and then returns: 1.

The concentrators are powered up in following order ASA5540-A (Priority 1) first, followed by ASA5540-B (Priority 5), then ASA5540-C (Priority 10). This is shown in steps 1a, 1b, and 1c, respectively. Even though ASA5540-A has the lowest priority in the VCA cluster, it becomes the master concentrator, as it was the first concentrator to join the cluster.

2.

When ASA5540-B and C are brought online after ASA5540-A, they send User Datagram Protocol (UDP) messages on 9023 (default) to ASA5540-A with their session load information, defined as the percentage of consumed IPsec sessions on the concentrator (active sessions/max sessions). ASA5540-A uses this information to load balance IPsec sessions from VPN clients across the three active concentrators in the cluster (ASA5540-B and C). ASA5540-B and C join as secondary controllers regardless of their priority.

3.

A link failure occurs, causing ASA5540-A’s public interface to become unavailable.

4.

ASA5540-B and C to elect a new VCA master. ASA5540-C becomes the master controller, as it has the highest configured priority.

5.

ASA5540-B sends keepalives to ASA5540-C with its session load information. ASA5540-C uses this information to appropriately load balance inbound IPsec sessions from the VPN clients between itself and ASA5540-B (ASA5540-A is currently offline).

6.

ASA5540-A recovers from link failure in step 3, and joins as a secondary controller in the VCA cluster. ASA5540-A sends a keepalive message to ASA5540-C, the current master, with its current session load information. ASA5540-C uses this information to load balance inbound IPsec sessions from the VPN clients across all three active concentrator clusters (ASA5540-A, B, and C).

NOTE VCA priorities are defined as part of the VCA IPsec session load-balancing configuration on the ASA5500. Example 9-3 provides a sample of this configuration later in this chapter.

Although the VCA protocol does not always elect the concentrator with the highest priority value as the master concentrator (as is the case with HSRP/VRRP with preemption enabled), it is still good practice in platform diverse VCA concentrator clusters to assign higher priority values to platforms with higher session capacity. In situations where VCA priorities are identical, the VCA secondary with the lowest IP address will assume the role of master VCA concentrator during an election. Table 9-1 provides a list of VPN3000 default VCA priority values.

IPsec RAVPN Concentrator HA Using the VCA Protocol

Table 9-1

339

VPN3000 Default VCA Priority Values VCA Concentrator Platform

Default VCA Priority Values

VPN3005

1

VPN3015

3

VPN3030

5

VPN3060

7

VPN3080

9

TIP In scenarios in which all IPsec VPN concentrator platforms in the VCA-enabled RAVPN design are identical, setting all of the VCA priority values to the highest setting (10), can potentially speed reconvergence by decreasing the time it takes to complete the VCA election process.

Once a master concentrator exists in the cluster, secondary concentrators can join the VCA cluster and immediately participate in the VCA IPsec session load-balancing operation. The secondary concentrators use the VCA protocol, sending messages over a configurable UDP port number to the VCA master concentrator declaring their session load to the master concentrator. When a VPN client initiates a new IPsec VPN tunnel to the concentrator cluster, the VCA master concentrator redirects the IPsec session to the concentrator with the lowest IPsec session load. The session load is defined as the currently number of active IPsec sessions managed by the concentrator divided by the maximum number of sessions supported by the concentrator. TIP Although each VCA-enabled concentrator has a default value for the number of supported sessions, this value is a configurable VCA option.

VPN clients use the VCA Virtual IP address for the concentrator cluster (shared by all concentrators in the cluster). When a client attempts to build an IPsec VPN tunnel to the concentrator cluster using the VCA Virtual IP address, the VCA master concentrator returns the physical public IP address of the concentrator in the cluster with the lowest session load. The IPsec VPN client subsequently initiates an IPsec VPN tunnel with that concentrator determined to have the lowest session load in the VCA cluster. The result is that each IPsec VPN client is assured that it is building an IPsec VPN tunnel with the IPsec VPN concentrator with the greatest amount of available processing resources relative to any of the other VPN concentrators in the VCA cluster at any given point in time. Figure 9-18 illustrates the load-balancing operation of VCA clustering in a dual-DMZ firewall design with three clustered ASA5540s used for IPsec VPN tunnel termination from RAVPN clients.

340

Chapter 9: Solutions for Remote-Access VPN High Availability

Figure 9-18

VCA Cluster IPsec Session Load Balancing

Inside

Outside

DNS: 200.1.1.17

IEDGE-7304-A

To: CORE

Si IEDGE-C6509-A

PIX535-Standby 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

Internet

6

Client-C

4

PIX535-Main

2 To: CORE

Client-B

Si

IEDGE-7304-B Client-A

IEDGE-C6509-B

Inner DMZ ASA5510-A is the VCA master concentrator responsible for assessing current load on the secondary concentrators (ASA5510-B and C) and redirecting inbound sessions initially destined to the VCA Virtual address to the concentrator physical IP addresses.

Outer DMZ ASA5540-A Public IP: 10.1.1.1

1

7

ASA5540-B Public IP: 10.1.1.2

4948G-DMZ-PUB

4948G-DMZ-PRI ASA5510-A redirects initial sessions to the VCA Virtual IP in steps 2, 4, and 6 to the secondary concentrators in the cluster (ASA5510-B, and C) in steps 3, 5, and 7.

1

5

ASA5540-C Public IP: 10.1.1.3

3

Once a VCA master concentrator has been elected and secondary VCA concentrators have been identified in the cluster, the VCA master concentrator can begin to distribute the load of IPsec VPN sessions inbound from various VPN clients to the secondary VCA concentrators in the cluster. The

IPsec RAVPN Concentrator HA Using the VCA Protocol

341

following ordered sequence of events corresponding to those events illustrated in Figure 9-18 describes the process of distributing IPsec VPN sessions inbound from VPN clients across the different IPsec VPN concentrators participating in a cluster using the VCA protocol: 1.

The concentrators are all configured in the same cluster. ASA5540-A is currently the VCA master concentrator for the cluster. ASA5540-B and ASA5540-C send keepalive messages to ASA5540-A with their session load information, indicating that they currently are managing 51 and 50 IPsec sessions, respectively. ASA5540-A stores this information to execute future load-balancing decisions.

2.

Client-A initiates an IPsec VPN tunnel to the Concentrator Cluster using the VCA Virtual IP of 200.1.1.100. Initially, this session is destined for ASA5540-A, the master concentrator in the cluster.

3.

ASA5540 redirects the session to ASA5540-C (200.1.1.103), as it has the lowest session load level (50 sessions) relative to its IPsec session capacity.

4.

Client-B initiates an IPsec VPN tunnel to the Concentrator Cluster using the VCA Virtual IP of 200.1.1.100. Initially, this session is destined for ASA5540-A, the master concentrator in the cluster.

5.

ASA5540 redirects the session to ASA5540-B (200.1.1.102) even though ASA5540-A and B’s loads are identical. This is because the VCA master will redirect client sessions to its secondary concentrators until it has the lowest load in the cluster. The rationale behind this is that the VCA master is burdened by the overhead of session redirection and should therefore redirect sessions to secondary concentrators with equal session loads (equaling an overall lesser load due to the absence of VCA session administration overhead on the secondary controller).

6.

Client-C initiates an IPsec VPN tunnel to the Concentrator Cluster using the VCA Virtual IP of 200.1.1.100. Initially, this session is destined for ASA5540-A, the master concentrator in the cluster.

7.

ASA5540 does not redirect the session, but instead returns its own physical IP address (200.1.1.101) to the VPN client for IPsec peer, as ASA5540-A has the lowest number of managed sessions (ASA5540-A has 50 sessions, and ASA5540-B and C both now have 51 sessions after accepting sessions from Client A and B in steps 3 and 4, respectively).

Example 9-3 provides the necessary configuration required for an ASA5500 to participate in a VCA cluster. The following configuration specifies a priority of 9, making ASA5540 the most likely concentrator in the cluster to become the VCA master concentrator. In addition to the VCA priority, all of the participating concentrators in the VCA cluster must be configured with an identical VCA cluster IP address. In this case, ASA5540-A is configured to participate in the VCA cluster with the VCA cluster IP address of 200.1.1.100. It is instructed to encrypt exchanges between concentrators in the cluster with a key of “cisco123.”

342

Chapter 9: Solutions for Remote-Access VPN High Availability

Example 9-3

ASA5540—A VCA Load-Balancing Configuration

ASA5540-A(config)# vpn load-balancing ASA5540-A(config-load-balancing)# priority 9? ASA5540-A(config-load-balancing)# cluster key cisco123 ASA5540-A(config-load-balancing)# cluster ip address 200.1.1.100 ASA5540-A(config-load-balancing)# cluster encryption? ASA5540-A(config-load-balancing)# participate

NOTE The load-balancing configurations on ASA5540-B and C are identical to ASA5540-A in every way except for the priority definition (ASA5540-B = 5, ASA5540-C = 3). The cluster key and IP address must be identical across all VPN concentrators in the VCA-enabled cluster. The concentrator with the highest priority has the best chance of becoming the master concentrator.

It is important to note that, in Figure 9-17, Figure 9-18, Example 9-2, and Example 9-3, identical VPN concentrator platforms were selected to more clearly illustrate the load-balancing process in a concentrator cluster using VCA. One major benefit of the VCA protocol is that it factors each platform’s capacity in to its load-balancing scheme. As such, if a smaller concentrator (such as a VPN3005) capable of supporting a smaller amount of sessions were to be introduced to the VCA cluster, the master concentrator would factor the smaller capacity of the VPN3005 when redirecting IPsec VPN client sessions. This is achieved by each concentrator’s definition of session load: the number of current sessions divided by the number of maximum sessions. In the case of the VPN3005 joining a cluster of ASA5540s, the VPN3005 would express its load as a percentage of the active sessions relative to its platform session capacity to the master, thereby providing the master VCA controller with a metric incorporating the platforms session capacity. As such, a VCA master controller will often continue to assign IPsec sessions to higher-capacity concentrators, such as the ASA5530 concentrators previously, even if they have a greater raw session count than lower-capacity concentrators such as the VPN3005. Through proper implementation of VCA-enabled concentrators in an RAVPN design, IPsec VPN clients can be assured that they are terminating their IPsec tunnel on the concentrator with the highest degree of available computational resources of any concentrator in the VCA cluster. VCA therefore offers a method of load balancing that yields the most efficient use of IPsec processing resources in Cisco-based IPsec RAVPN concentrator designs of any of the designs discussed.

IPsec RAVPN Geographic HA Design Options Once the RAVPN has the appropriate amount of resiliency designed into the VPN concentrator cluster, there are several design options that can be selected for VPN clients to take full advantage of the resilient concentrator cluster design. In this section, we will explore the use of geographic HA in

IPsec RAVPN Geographic HA Design Options

343

an RAVPN. First, we will discuss how Domain Name System (DNS) can be configured to load balance inbound IPsec sessions from the VPN clients across multiple concentrators in a given cluster. After exploring this design alternative, we will then add the use of multiple peer definitions in the IPsec VPN client profile to provide resilient peering to multiple IPsec VPN concentrators. We will explore how these geographic HA options can be deployed in a standalone fashion, or in tandem for increased geographic IPsec HA.

VPN Concentrator Session Load Balancing Using DNS Geographic HA can be designed in to an RAVPN deployment using DNS-based load balancing. In this section, we will explore how resolving a single IPsec VPN concentrator hostname to multiple IP address assigned to the public interfaces of different VPN concentrators in a cluster can result in a round-robin distribution of IPsec VPN client sessions across the VPN concentrators in a given cluster. Figure 9-19 illustrates a RAVPN deployment in which IPsec VPN clients resolve the hostname cluster-main.cisco.com to the various IP addresses of the public interfaces on the VPN concentrators in the cluster in a round-robin fashion. The following order of operations describes the numbered process of DNS-based round-robin IPsec VPN session load balancing across redundantly configured VPN concentrators: 1.

Client-A initiates an IPsec VPN tunnel to the concentrator cluster using the hostname “cluster-main.cisco.com.” Client-A attempts to resolve the IP address of “clustermain.cisco.com” sing the DNS server at 200.1.1.17.

2.

The DNS server at 200.1.1.17 responds with the first IP address assigned to clustermain.cisco.com (200.1.1.101), which is also the IP address of the public interface configured on ASA5540-A.

3.

Client-A establishes an IPsec VPN tunnel to ASA5540-A using the IP address of 200.1.1.1 for IPsec peering.

4.

Client-B initiates an IPsec VPN tunnel to the concentrator cluster using the hostname “cluster-main.cisco.com.” Client-B attempts to resolve the IP address of “clustermain.cisco.com” using the DNS server at 200.1.1.17.

5.

The DNS server at 200.1.1.17 responds with the second IP address assigned to clustermain.cisco.com (200.1.1.102), which is also the IP address of the public interface configured on ASA5540-B.

6.

Client-B establishes an IPsec VPN tunnel to ASA5540-B using the IP address of 200.1.1.102 for IPsec peering.

7.

Client-C initiates an IPsec VPN tunnel to the concentrator cluster using the hostname “cluster-main.cisco.com.” Client-C attempts to resolve the IP address of “clustermain.cisco.com” using the DNS server at 200.1.1.17.

344

Chapter 9: Solutions for Remote-Access VPN High Availability

Figure 9-19

RAVPN DNS-Based IPsec Session Load Balancing

Inside

Outside

DNS: 200.1.1.17

IEDGE-7304-A

To: CORE

Si IEDGE-C6509-A

8

PIX535-Standby

7

5

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

Internet

2

4 Client-C

1 Client-B

To: CORE PIX535-Main

Si

IEDGE-7304-B

Client-A

IEDGE-C6509-B

Inner DMZ

Outer DMZ ASA5540-A Public IP: 10.1.1.1

3

ASA5540-B Public IP: 10.1.1.2

4948G-DMZ-PUB

4948G-DMZ-PRI IPsec VPN sessions from clients D, E, F, and others are evenly distributed across the concentrators ASA5540-A, B, and C as the DNS Server at 200.0.0.17 continues to return the different public IP addresses for the hostname “clustermain.cisco.com” in the same round-robin format as shown here for Client-A, B, and C.

8.

6

ASA5540-C Public IP: 10.1.1.3

9

The DNS server at 200.1.1.17 responds with the third IP address assigned to clustermain.cisco.com (200.1.1.103), which is also the IP address of the public interface configured on ASA5540-C.

IPsec RAVPN Geographic HA Design Options

9.

345

Client-C establishes an IPsec VPN tunnel to ASA5540-C using the IP address of 200.1.1.103 for IPsec peering.

The process described above continues in a round-robin fashion as new IPsec VPN clients attempt to build IPsec VPN tunnels with the IPsec VPN concentrator cluster. Although this method of RAVPN IPsec session load balancing is not as efficient or effective as VCA, it does ensure that inbound IPsec VPN tunnels are evenly distributed across the concentrators in the cluster. With DNS-based load balancing, an even distribution of IPsec VPN tunnels is achieved. Even distribution provides an effective means of load balancing, but perhaps not the most effective and efficient. VCA, however, does not provide an even distribution of inbound IPsec VPN sessions across the clusters. Instead, IPsec VPN session distribution decisions are made based on actual session load information taken from the concentrators in the cluster, accounting for platform-specific capacity considerations and fluctuation in IPsec session load statistics on the concentrators in the cluster. RAVPN HA designs using VCA are supported only by Cisco VPN concentrators, and as such, using VRRP-based RAVPN HA or DNS-based load balancing both present viable design alternatives for RAVPN HA in vendor-diverse environments. However, in Cisco-based RAVPN HA concentrator cluster designs, VCA adds an extra layer of intelligence to load balancing and redundancy operations that enable optimized distribution of IPsec VPN sessions across the different concentrators in the VCA cluster.

VPN Concentrator Redundancy Using Multiple Peers Another layer of Geographic HA can be built in to the RAVPN design by defining multiple IPsec peers in the IPsec VPN client profile. In this section, we will explore two designs that use multiple IPsec peers for Geographic HA: ■

Multiple IPsec Peers with HSRP-Based VPN Concentrator HA and DNS-Based Load Balancing

■

Multiple IPsec Peers with Multiple VCA Concentrator Clusters for HA and Load Balancing

Figures 9-20 through 9-22 illustrate the VPN client configuration required to leverage geographic HA using multiple IPsec peer definitions. The configuration is the same regardless of whether that peer represents an HSRP Standby interface or a VCA Virtual IP address. The first design we will discuss deploys a stateless IPsec VPN concentrator design using HSRPbased tunnel termination with multiple HSRP groups for HA and DNS-based. In Figure 9-19, the three IPsec VPN concentrators are configured for stateful HA using three HSRP groups with different HSRP Virtual Router IP addresses. Instead of statically assigning VPN clients to a VRRP group, the concentrators in this cluster use DNS-based load balancing to dynamically return a

346

Chapter 9: Solutions for Remote-Access VPN High Availability

different HSRP Virtual Router IP address when a round-robin VPN client establishes an IPsec VPN session to the concentrator. The load-balancing configuration for Figure 9-23 is summarized in Table 9-2. Figure 9-20

IPsec VPN Client Authentication Configuration

Figure 9-21

IPsec VPN Client Transport Configuration

IPsec RAVPN Geographic HA Design Options

Figure 9-22

Configuring Backup Peers on Cisco VPN Clients

Figure 9-23

Geographic IPsec HA Using Multiple IPsec Peer Hostnames in the VPN Client Profile, DNS-Based Load Balancing, and VRRP-Based IPsec VPN concentrator Local HA

347

Hostname: Client-Bou3 DNS Reply:200.1.1.103 (HSRP Group 3 Virtual Router IP)

12 Hostname: Client-Bou4 Not Connected

17

11

Hostname: Client-Cha2 DNS Reply: 200.1.1.102 (HSRP Group 2 Virtual Router IP)

16 12

Internet, East

5

11 Hostname: Client-Bou5 Not Connected

19

Boulder, CO

12

Internet, West

Hostname: Client-Bou6 Not Connected

4

Hostname: Client-Bou2 DNS Reply:200.1.2.102 (HSRP Group 2 Virtua Router IP)

Hostname: Client-Cha4 Not Connected

7

9 8 9

15

Hostname: Client-Cha3 Not Connected

5

2

2

Hostname: Client-Bou1 DNS Reply:200.1.2.101 (HSRP Group 1 Virtual Router IP)

Hostname: Client-Cha1 DNS Reply: 200.1.1.101 (HSRP Group 1 Virtual Router IP)

Charlotte, NC

Outside

1

Hostname: Client-Cha5 Not Connected

Outside

14

Inside

Inside DNS: 200.1.2.17

To: CORE IEDGE-C6509-BOU1

IEDGE-C6509-CHA1

Static NAT Translations: 200.1.2.101->10.2.1.1 200.1.2.102->10.2.2.1 200.1.2.103->10.2.3.1

PIX535-Standby

DNS: 200.1.1.17

To: CORE

Si

IEDGE-7304-BOU1

Si

Static NAT Translations: 200.1.1.101->10.1.1.1 200.1.1.102->10.1.2.1 200.1.1.103->10.1.3.1

To: CORE

PIX535-Standby

IEDGE-7304-CHA1

To: CORE PIX535-Main

PIX535-Main

Si

Si

IEDGE-7304-BOU2

IEDGE-C6509-BOU2

IEDGE-7304-CHA2

IEDGE-C6509-CHA2

Inner DMZ

Inner DMZ HSRP Group 1 Master IP: 10.1.1.0/24

VPN7301-BOU-A Public IP: 10.2.1.1

HSRP Group 1 Master IP: 10.1.1.0/24

VPN7301-CHA-A Public IP: 10.1.1.1

3

4948G-DMZ-PRI

HSRP Group 2 Master IP: 10.1.2.0/24

VPN7301-BOU-B Public IP: 10.2.2.1

10 4948G-DMZ-PUB

4948G-DMZ-PRI

HSRP Group 2 Master IP: 10.1.2.0/24

VPN7301-CHA-B Public IP: 10.1.2.1 4948G-DMZ-PUB

13 HSRP Group 3 Master IP: 10.1.3.0/24

VPN7301-BOU-C Public IP: 10.2.3.1

6

802.1q trunks

HSRP Group 3 Master IP: 10.1.3.0/24

VPN7301-CHA-C Public IP: 10.1.3.1

802.1q trunks

18

348

Chapter 9: Solutions for Remote-Access VPN High Availability

Table 9-2

VRRP-Based Stateless IPsec RAVPN HA Load Balancing with Multiple VRRP Groups, DNS-Based Load Balancing, and Multiple Peer Definitions in the IPsec VPN Client Profile Cluster Hostname: charlotte-vpn.cisco.com DNS IP Resolutions: 200.1.1.100 200.1.2.100 200.1.3.100

HSRP Group#: 1 IP: 200.1.1.100

HSRP Group#: 2 IP: 200.1.2.100

HSRP Group#: 3 IP: 200.1.3.100

Concentrator:

Priority: 30

Priority: 20

Priority: 10

VPN7301-CHA-A

Status: Master

Status: 1st Backup

Status: 2nd Backup

Concentrator:

Priority: 10

Priority: 30

Priority: 20

VPN7301-CHA-B

Status: 2nd Backup

Status: Master

Status: 1st Backup

Concentrator:

Priority: 20

Priority: 10

Priority: 30

VPN7301-CHA-C

Status: 1st Backup

Status: 2nd Backup

Status: Master

Cluster Hostname: boulder-vpn.cisco.com DNS IP Resolutions: 200.2.1.100 200.2.2.100 200.2.3.100

VRRP Group#: 1 IP: 200.2.1.100

VRRP Group#: 2 IP: 200.2.2.100

VRRP Group#: 3 IP: 200.2.3.100

Concentrator:

Priority: 30

Priority: 20

Priority: 10

VPN7301-BOU-A

Status: Master

Status: 1st Backup

Status: 2nd Backup

VPN Clients: 1st + Every Other 3rd

VPN Clients: 2nd + Every Other 3rd

VPN Clients: 3rd + Every Other 3rd

VPN Clients: 1st + Every Other 3rd

IPsec RAVPN Geographic HA Design Options

349

VRRP-Based Stateless IPsec RAVPN HA Load Balancing with Multiple VRRP Groups, DNS-Based Load Balancing, and Multiple Peer Definitions in the IPsec VPN Client Profile (Continued)

Table 9-2

Cluster Hostname: boulder-vpn.cisco.com DNS IP Resolutions: 200.2.1.100 200.2.2.100 200.2.3.100

VRRP Group#: 1 IP: 200.2.1.100

VRRP Group#: 2 IP: 200.2.2.100

VRRP Group#: 3 IP: 200.2.3.100

Concentrator:

Priority: 10

Priority: 30

Priority: 20

VPN7301-BOU-B

Status: 2nd Backup

Status: Master

Status: 1st Backup

Concentrator:

Priority: 20

Priority: 10

Priority: 30

VPN7301-BOU-C

Status: 1st Backup

Status: 2nd Backup

Status: Master

VPN Clients: 2nd + Every Other 3rd

VPN Clients: 3rd + Every Other 3rd

The design leverages the use of two concentrator clusters, boulder-vpn.cisco.com and charlottevpn.cisco.com. Each cluster acts as a “primary” cluster for its half of the VPN client population in the RAVPN design: boulder-vpn.cisco.com serves as the primary cluster for users in the western half of the country, while charlotte-vpn.cisco.com serves as the primary cluster for the eastern half of the country. The VPN clients are configured to use multiple IPsec peers for geographic HA. The IPsec VPN clients will therefore attempt to connect to their primary cluster first. If they are unable to connect to their primary cluster within a configurable timeout window, they will try the other cluster as a backup. Within each cluster, inbound IPsec sessions are distributed across three VRRP groups with skewed priorities consistent with the format in Table 9-2 using DNS-based load balancing. The following sequence of steps illustrates the order of operations executed when clients attempt to build IPsec VPN tunnels to the redundant pair of concentrator clusters illustrated in Figure 9-23. 1.

Client-Cha1 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.

2.

The DNS server returns the first HSRP Virtual Router IP address (Group 1 = 200.1.1.101) for charlotte-vpn.cisco.com.

350

Chapter 9: Solutions for Remote-Access VPN High Availability

3.

Client-Cha1 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-CHA-A (the Active HSRP Router for HSRP Group 1).

4.

Client-Cha2 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.

5.

The DNS server returns the second HSRP Virtual Router IP address (Group 1 = 200.1.1.102) for charlotte-vpn.cisco.com.

6.

Client-Cha2 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-CHA-B (the Active HSRP Router for HSRP Group 2).

7.

As long as the all of the concentrators in the VPN cluster charlotte-vpn.cisco.com are active, the DNS-server at 200.1.1.17 distributes the IPsec VPN sessions from the Charlotte clients evenly across the VPN concentrators in the Charlotte cluster (VPN7301-CHA-A, B, and C). This is achieved by using DNS-based load balancing to return the HSRP Virtual Router IP addresses corresponding to VPN7301-CHA-A, B, and C in a round-robin format following the same process as illustrated in steps 1-6 above.

8.

Client-Bou1 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.

9.

The DNS server returns the first HSRP Virtual Router IP address (Group 1 = 200.1.2.101) for boulder-vpn.cisco.com.

10.

Client-Bou1 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-BOU-A (the Active HSRP Router for HSRP Group 1).

11.

Client-Bou2 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.

12.

The DNS server returns the second HSRP Virtual Router IP address (Group 1 = 200.1.2.102) for boulder-vpn.cisco.com.

13.

Client-Bou2 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-BOU-B (the active HSRP Router for HSRP Group 2).

14.

As long as all of the concentrators in the VPN cluster boulder-vpn.cisco.com are active, the DNS server at 200.1.2.17 distributes the IPsec VPN sessions from the Boulder clients evenly across the VPN concentrators in the Boulder cluster (VPN7301-BOU-A, B, and C). This is achieved by using DNS-based load balancing to return the HSRP Virtual Router IP addresses corresponding to VPN7301-BOU-A, B, and C in a round-robin format following the same process as illustrated in steps 8-13 above.

15.

A power outage occurs in the Boulder Facility hosting the IPsec VPN concentrator cluster boulder-vpn.cisco.com, making all concentrators in the cluster unavailable.

IPsec RAVPN Geographic HA Design Options

351

16.

Client-Bou3 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname boulder-vpn.cisco.com to an IP address using the DNS server at 200.1.2.17. Due to the power outage in step 15 above, Client-Bou3 receives no reply from the DNS server at 200.1.2.17. Client-Bou3 queries 200.1.1.17 instead.

17.

The DNS server 200.1.1.17 returns the third HSRP Virtual Router IP address (Group 1 = 200.1.1.103) for charlotte-vpn.cisco.com to Client-Bou3.

18.

Client-Bou3 uses the IP address returned in step 2 to build an IPsec VPN tunnel with VPN7301-CHA-C (the Active HSRP Router for Group 3).

19.

As long as the all of the concentrators in the VPN cluster charlotte-vpn.cisco.com are active, the DNS-server at 200.1.1.17 distributes the IPsec VPN sessions from the Boulder clients evenly across the VPN concentrators in the Charlotte cluster (VPN7301-CHA-A, B, and C). This is achieved by using DNS-based load balancing to return the VRRP Virtual Router IP addresses corresponding to ASA5540-CHA-A, B, and C in a round-robin format. When the VPN concentrator cluster in Boulder recovers from the power outage in step 15, Boulder clients will revert back to boulder-vpn.cisco.com concentrator cluster.

TIP Upon recovery of a client’s primary IPsec VPN concentrator cluster, the active remote VPN tunnels on a given VPN concentrator cluster will not revert back to their primary VPN concentrator until they are torn down and renegotiated (for example, torn down by the client, or timed out by the VPN concentrator). For this reason, and for others, it is useful to configure an effective timeout period on the VPN concentrators for client RAVPN sessions.

VCA can easily replace HSRP intra-cluster HA method for boulder-vpn.cisco.com and charlottevpn.cisco.com in the load-balancing scenario described above. If VCA were elected as the design option for charlotte-vpn.cisco.com and boulder-vpn.cisco.com in the clusters above, the DNS server would simply be altered to return VCA Virtual IP addresses for the hostnames bouldervpn.cisco.com and charlotte-vpn.cisco.com to the IPsec VPN clients instead of the HSRP Virtual Router IP addresses in the scenario listed Figure 9-23 and Table 9-2. The IPsec VPN client profile configuration need not be changed when replacing HSRP with VCA—the VPN clients still use the hostnames charlotte-vpn.cisco.com and boulder-vpn.cisco.com to initiate IPsec VPN tunnels to the appropriate concentrator cluster. Within the VPN concentrator cluster, there are several key changes to the design that occur when changing from VRRP to VCA. Table 9-3 provides the information required to achieve Geographic HA using multiple hostnames for IPsec peering to IPsec VPN clusters enabled for load balancing and HA using VCA: ■

There is no need for DNS-based load balancing—The VCA master controller handles IPsec session load balancing within the cluster.

352

Chapter 9: Solutions for Remote-Access VPN High Availability

Table 9-3

■

There is no need for multiple HSRP groups or multiple HSRP Virtual Router IP addresses— VCA dynamically redirects inbound IPsec sessions to the appropriate concentrator based on its current load relative to the platform maximum load.

■

Although the VPN clients still use DNS to resolve the hostnames charlotte-vpn.cisco.com and boulder-vpn.cisco.com to an IP address, the DNS resolution for these hostnames is changed to yield a single VCA Virtual IP address to all DNS queries, rather than yielding multiple HSRP Virtual Router IP addresses in a round-robin fashion. VCA obsoletes the need for multiple DNS IP address under a single hostname. VCA IPsec RAVPN HA Load Balancing with DNS-Based Load Balancing and Multiple Peer Definitions in the IPsec VPN Client Profile Cluster Hostname: charlotte-vpn.cisco.com DNS IP Resolutions: 200.1.1.100

VCA Virtual IP: 200.1.1.100

Concentrator: ASA5540-CHA-A

Priority: 30

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.1.101 Status: Master

Concentrator: ASA5540-CHA-B

Priority: 20

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.1.102 Status: 1st Secondary

Concentrator: ASA5540-CHA-C

Priority: 10

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.1.103 Status: 2nd Secondary

Cluster Hostname: boulder-vpn.cisco.com DNS IP Resolutions: 200.1.2.100

VCA Virtual IP: 200.1.2.100

Concentrator: ASA5540-BOU-A

Priority: 30

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.2.101 Status: Master

Concentrator: ASA5540-BOU-B

Priority: 10

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.2.102 Status: 2nd Backup

Concentrator: ASA5540-BOU-C

Priority: 20

VPN Clients: VCA Load-Based Distribution

Public IP: 200.1.2.103 Status: 1st Backup

IPsec RAVPN Geographic HA Design Options

353

Figure 9-24 illustrates the operation of an RAVPN design in which multiple IPsec VPN peer definitions are configured in the VPN client profile to provide Geographic HA between two VCA-enabled RAVPN concentrator clusters in Boulder (boulder-vpn.cisco.com) and Charlotte (charlotte-vpn.cisco.com). We will used the stepped order of operation corresponding to Figure 9-24 to illustrate the order of operation that occurs when VPN clients attempt to access the VCA-enabled concentrator clusters in Boulder and Charlotte. Geographic IPsec HA Using Multiple IPsec Peer Hostnames and VCA Clustering for Local HA and Intracluster Session Load Balancing

Figure 9-24

Hostname: Client-Bou3 DNS Reply: 200.1.1.100 (VCA Virtual IP Address)

20 Hostname: Client-Bou4 Not Connected

19

18

20

Hostname: Client-Cha2 DNS Reply: 200.1.1.100 (VCA Virtual IP Address)

14

6

13 Hostname: Client-Bou5 Not Connected

14

23

15

Internet, West

Hostname: Client-Bou6 Not Connected

Hostname: Client-Cha3 Not Connected

6 5

Hostname: Client-Bou2 DNS Reply: 200.2.1.102 (VCA Virtual IP Address)

Internet, East

10 9 10 Hostname: Client-Bou1 DNS Reply: 200.2.1.100 (VCA Virtual IP Address)

Hostname: Client-Cha1 DNS Reply: 200.1.1.100 (VCA Virtual IP Address)

23

2

2

Hostname: Client-Cha4 Not Connected

1

Hostname: Client-Cha5 Not Connected

Boulder, CO

17

Charlotte, NC

Outside

Outside

14

Inside

Inside DNS: 200.1.2.17

To: CORE IEDGE-C6509-BOU1

To: CORE

Si

Static NAT Translations: 200.1.2.100->10.1.2.100 200.1.2.101->10.1.2.1 200.1.2.102->10.1.2.2 200.1.2.103->10.1.2.3

IEDGE-C6509-CHA1 PIX535-Standby

IEDGE-7304-BOU1

DNS: 200.1.1.17 Si

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

To: CORE

PIX535-Standby IEDGE-7304-CHA1

To: CORE PIX535-Main

PIX535-Main

Si

Si

IEDGE-7304-BOU2

IEDGE-C6509-BOU2

IEDGE-7304-CHA2

IEDGE-C6509-CHA2

Inner DMZ

Inner DMZ VCA IP: 10.1.1.100/24

ASA5540-BOU-A Public IP: 10.1.2.1

VCA IP: 10.1.1.100/24

ASA5540-BOU-B Public IP: 10.1.2.2

ASA5540-CHA-A Public IP: 10.1.1.1

ASA5540-CHA-B Public IP: 10.1.1.2 4948G-DMZ-PUB

4948G-DMZ-PRI

4948G-DMZ-PUB

4948G-DMZ-PRI

12

4

8

16

22 ASA5540-BOU-C Public IP: 10.1.2.3

ASA5540-CHA-C Public IP: 10.1.1.3

The following numbered list corresponding to the topology illustrated in Figure 9-24 describes the process of distributing inbound sessions from IPsec VPN clients when connecting to two geographically-disperse VPN concentrator clusters running the VCA session load-balancing protocol. 1.

Client-Cha1 looks up the first IPsec peer entry in its VPN Profile (charlotte-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.

354

Chapter 9: Solutions for Remote-Access VPN High Availability

2.

The DNS server returns the VCA Virtual IP address for charlotte-vpn.cisco.com (200.1.1.100).

3.

Client-Cha1 uses the IP address returned in step 2 to build an IPsec VPN tunnel with the cluster charlotte-vpn.cisco.com. The VCA master for charlotte-vpn.cisco.com (ASA5540CHA-A) returns the physical public IP address of the least-loaded concentrator, which is currently ASA5540-CHA-B, (200.1.1.102).

4.

Client-Cha1 uses the public IP address of ASA5540-CHA-B as its IPsec peer when building the IPsec VPN tunnel.

5.

Client-Cha2 looks up the first IPsec peer entry in its VPN Profile (charlotte-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.1.17.

6.

The DNS server returns the same VCA Virtual IP address for charlotte-vpn.cisco.com (200.1.1.100) as it returned in step 2—note that multiple DNS resolutions are not required here.

7.

Client-Cha2 uses the IP address returned in step 6 to build an IPsec VPN tunnel with the cluster charlotte-vpn.cisco.com. The VCA master for charlotte-vpn.cisco.com (ASA5540CHA-A) returns the physical public IP address of the least-loaded concentrator, which is now ASA5540-CHA-C, to Client-Cha2 to use when building the IPsec VPN tunnel.

8.

Client-Cha2 establishes an IPsec VPN tunnel to the public interface on ASA5540-CHA-C (200.1.1.103).

9.

Client-Bou1 looks up the first IPsec peer entry in its VPN Profile (boulder-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.

10.

The DNS server returns the VCA Virtual IP address for boulder-vpn.cisco.com (200.1.2.100).

11.

Client-Bou1 uses the IP address returned in step 11 to build an IPsec VPN tunnel with the cluster boulder-vpn.cisco.com. The VCA master for boulder-vpn.cisco.com (ASA5540BOU-A) returns the physical public IP address of the least-loaded concentrator, which is currently ASA5540-BOU-B.

12.

Client-Bou1 establishes an IPsec VPN tunnel to the public interface on ASA5540-BOU-B (200.1.2.102).

13.

Client-Bou2 looks up the first IPsec peer entry in its VPN Profile (boulder-vpn.cisco.com) and attempts to resolve the hostname to an IP address using the DNS server at 200.1.2.17.

14.

The DNS server returns the same VCA Virtual IP address for boulder-vpn.cisco.com (200.1.2.100) as it returned in step 11 above—note that there is no need for multiple DNS resolutions required here.

Summary

355

15.

Client-Bou2 uses the IP address returned in step 2 to build an IPsec VPN tunnel with the cluster boulder-vpn.cisco.com. The VCA master for boulder-vpn.cisco.com (ASA5540BOU-A) returns the physical public IP address of the least-loaded concentrator, which is now ASA5540-BOU-C.

16.

Client-Bou2 establishes an IPsec VPN tunnel to the public interface on ASA5540-BOU-C (200.1.2.103).

17.

A power outage occurs in the Boulder Facility hosting the IPsec VPN concentrator cluster boulder-vpn.cisco.com, making all concentrators in the cluster unavailable.

18.

Client-Bou3 looks up the first IPsec peer entry in its VPN Profile and attempts to resolve the hostname boulder-vpn.cisco.com to an IP address using the DNS server at 200.1.2.17. Due to the power outage in step 15, Client-Bou3 receives no reply from the DNS server at 200.1.2.17. Client-Bou3 queries 200.1.1.17 instead.

19.

Client-Bou3 attempts to resolve the backup IPsec peer hostname configured in its IPsec VPN profile (charlotte-vpn.cisco.com) with the DNS server at 200.1.1.17.

20.

The DNS server returns the VCA Virtual IP address for charlotte-vpn.cisco.com (200.1.1.100) to Client-Bou3.

21.

Client-Bou3 uses the IP address returned in step 2 to build an IPsec VPN tunnel charlottevpn.cisco.com. The VCA master for charlotte-vpn.cisco.com (ASA5540-CHA-A) returns the physical public IP address of the least-loaded concentrator, which is currently itself.

22.

Client-Bou2 establishes an IPsec VPN tunnel to the public interface on ASA5540-BOU-A (200.1.1.101).

23.

IPsec VPN sessions from both Charlotte and Boulder clients will continue to be load balanced across the concentrators participating the Charlotte VCA cluster. When the VPN concentrator cluster in Boulder recovers from the power outage in step 15, Boulder clients will revert to using boulder-vpn.cisco.com concentrator cluster for IPsec RAVPN session establishment.

Summary The availability of a remote access VPN infrastructure is largely centered around the concentration point of RAVPN tunnels. This chapter has focused on presenting designs scenarios that can be used to increase the availability of RAVPN concentration points. The designs presented in this chapter include: ■

Resilient RAVPN Concentrator Cluster Designs with VRRP

■

Resilient RAVPN Concentrator Cluster Designs with HSRP

356

Chapter 9: Solutions for Remote-Access VPN High Availability

■

Resilient RAVPN Concentrator Cluster Designs with VCA

■

Geographically Resilient Concentrator Designs with DNS-Based Load Balancing to HSRP Virtual Interfaces

■

Geographically Resilient Concentrator Designs with DNS-Based Load Balancing to VCA Virtual IP Addresses

All of the RAVPN design concepts discussed in this chapter can be deployed in tandem to maximize RAVPN accessibility for IPsec VPN clients. However, tying all of these components together can be daunting. Keeping that in mind, it is helpful to approach designing HA and load balancing in to the RAVPN in a layered format presented in this chapter: Step 1

Design Local HA for IPsec VPN Concentrators: First, ensure that the VPN concentrator located at the Internet Edge is available to the IPsec VPN clients. This can be accomplished using the following methods discussed in this chapter: • VRRP-Based Stateless IPsec VPN Tunnel Termination • HSRP-Based Stateful IPsec VPN Tunnel Termination • VCA Concentrator Clustering • DNS-Based Redundancy to Standalone Concentrators

Step 2

Incorporate Intracluster Load-Balancing Techniques: Second, once the concentrator cluster has been designed using one of the above Local HA methods, investigate the available options for load balancing within the redundancy method selected: • DNS-Based Load Balancing to Multiple Standalone Concentrators • VCA Session and Platform-Aware IPsec Session Load Balancing

Step 3

Incorporate Geographic HA Techniques: Lastly, once the concentrator cluster is highly available and properly load balancing IPsec sessions across the various concentrators in the cluster, administrators should evaluate the benefits of incorporating multiple, geographically redundant concentrator clusters into the RAVPN design. The two methods for providing Geographic HA between IPsec VPN clients and multiple IPsec VPN concentrators discussed in this chapter are: • Resolving a single concentrator hostname to multiple IPsec VPN concentrator public IP addresses, or, if VRRP/HSRP is used, multiple VRRP/HSRP Virtual Router IP addresses corresponding to different VRRP/HSRP groups. • Defining multiple IPsec VPN peers in the VPN clients IPsec profile.

Summary

357

In this chapter, we have covered the basic construction of a remote access VPN deployment, and applied the Local and Geographic HA concepts discussed in Chapters 6 and 7 to that construct to yield several highly available RAVPN design alternatives. In addition to RAVPN HA, we have embedded several effective means by which to load balance inbound client IPsec VPN sessions on a concentrator cluster. Lastly, the concept of multiple peers was introduced to provide the clients with Geographic HA by leveraging the use of geographically disperse and redundant IPsec VPN concentrator clusters.

CHAPTER

10

Further Architectural Options for IPsec Up until this point, we’ve discussed major deployments and best practice design fundamentals for IPsec VPN deployments. Situations may arise in which IPsec network architectures are forced to vary somewhat. In this chapter, we will explore the forces that cause this variation in the fundamentals of IPsec VPN designs and some of the strategies that can be used to address these variations: ■

IPsec VPN Tunnel Termination “On-a-Stick”

■

In-Path vs. Out-of-Path Encryption

■

Separate Termination of IPsec and GRE (GRE-offload)

We will discuss each of these above design options in detail, including the drivers for selecting that specific variant of IPsec design. Case studies for each of the above will be inserted after introducing each design variant to illustrate that particular design alternative in practice.

IPsec VPN Termination On-a-Stick When referring to technologies “on-a-stick,” we are typically describing a scenario in which the device performing that technical function is attached to the network using a single interface. Common examples that can reside “on-a-stick” include router-on-a-stick, NAT-on-a-stick, and IPsec VPN termination-on-a-stick. In this section, we will discuss the latest of the three, focusing on IPsec Virtual Private Network (VPN) deployment scenarios in which one or both IPsec VPN tunnel termination points are attached out-of-path using a single physical interface for network connectivity.

IPsec with Router-on-a-Stick Design Overview Although they do exist in many network deployments, cases in which administrators would opt for IPsec VPN tunnel termination “on-a-stick” are rare. Furthermore, of those existing cases, this design option is most commonly used as an alternative to accommodate other areas of the network architecture, rather than as an option that an administrator would choose over in-path IPsec VPN design options discussed previously.

360

Chapter 10: Further Architectural Options for IPsec

IPsec termination on-a-stick refers to a deployment scenario in which the IPsec tunnel termination point is attached to the network using a single network interface. As such, this design option places crypto and IPsec functionality outside of the data path, as illustrated in Figure 10-1. Figure 10-1

IPsec VPN Tunnel Termination “On-a-Stick”

Corporate Network (11.1.1.0/24): Traffic is encrypted between corporate centralized resources (11.1.1.0/24) and resources at the remote retail location (200.1.1.0/29).

Corporate Internet-edge router aggregates the termination from remote retail branches.

Router terminates the IPsec VPN tunnel, and is also used to perform NAT between inside and outside interfaces.

Outside Address (201.10.0.0/16): ISP provides a small routable IP address to the branch network LAN (201.1.1.0/29)

ISP

5

Inside Address (192.168.1.0/24):

Ciphertext

6

Loopback0

3

Cable modem acts as bridge for small branch LAN, resulting in a flatly addressed L2 LAN.

Ethernet0 1845ISR

Cleartext 4

Cable modem provides broadband interface to the ISP edge.

2

Router has single interface to bridged LAN, thereby attached “on-a-stick.”

1

Cable modem offers integrated bridged Ethernet interfaces for attaching workstations and servers at the remote retail site.

Figure 10-1 depicts a rare scenario in which IPsec using router-on-a-stick is required. Let’s now discuss some of the circumstances that force this scenario to exist. Single, Flatly Addressed L3 Domain The key design driver here is that the cable modem and integrated bridge provides only one flat Layer 2 domain for devices to attach to. Although it is rare to see a VPN concentrator with one interface (most devices will ship with multiple interfaces to reside in-path), the bridged layout of this network design on the LAN side presents only one interface from a L3 perspective. In other words, a second interface on the VPN concentrator or router would yield no benefit, as one would

IPsec VPN Termination On-a-Stick

361

be unable to assign it an IP address (it would conflict with the other interface connected to the bridged domain). Lack of In-Path Design Options The flat L3 network forces the IPsec VPN tunnel outside of the data path. Due to the fact that only one L3 interface can be attached to this bridged LAN, the encryptor is unable to reside inside the unencrypted data path. NOTE In-Path and Out-of-Path refer to the path of the unencrypted data flows. The encrypted data must flow through the IPsec VPN tunnel endpoint, even in “on-a-stick” implementations. In-Path versus Out-of-Path comparisons are discussed later in this chapter. In this situation, IPsec VPN tunnel termination “on-a-stick” can be used to provide encryption for resources on the bridged LAN in Figure 10-1. This design option involves several components, some of which are unique to this design. Single Interface to the Bridged LAN This interface resides outside of the unencrypted data path. This requires that network resources traversing the VPN tunnel use the IP address of the IPsec VPN tunnel termination point that connects to the bridged LAN as their default gateways. Crypto-Enabled Loopback Interface This interface essentially serves as the crypto interface used to terminate the IPsec VPN tunnel. In Chapter 6, “Solutions for Local Site-to-Site High Availability,” we discussed the use of a loopback interface to terminate the IPsec VPN tunnel for local High Availability (HA). In this situation, we will actually apply the crypto map to the loopback interface itself and loop encrypted traffic back onto the bridged LAN. Figure 10-2 displays this operation. Figure 10-2

IPsec VPN Tunnel Termination On-a-Stick Using Loopback Interfaces for Crypto 2 The crypto map is applied to the router’s Loopback 0 interface, instructing the crypto engine to apply the appropriate cryptographic operations on the data as it is looped back within the router.

Cleartext 1 Loopback0

Ethernet0

3

Ciphertext

362

Chapter 10: Further Architectural Options for IPsec

The process in Figure 10-2 is as follows: 1.

The IPsec VPN gateway (router-on-a-stick) in Figure 10-2 receives traffic from the bridged LAN. This traffic is in cleartext format.

2.

The router forwards the traffic to its loopback interface. The router inspects the traffic, matching it to a crypto ACL referenced in the crypto map that is applied to the crypto interface. The crypto engine applies the appropriate transform to the data matching the crypto ACL.

3.

The router forwards the traffic from step 2 on to the bridged LAN. The traffic is now in ciphered format, destined for the other end of the IPsec VPN tunnel.

NOTE These steps described vary slightly from the ones outlined in the ensuing case study, as the case study includes IPsec VPN tunnel termination on-a-stick and Network Address Translation (NAT) on-a-stick, while the example we have just discussed includes only IPsec VPN tunnel termination on-a-stick without NAT. Let’s now take a look at a case study that will illustrate the operation of IPsec VPN tunnel termination “on-a-stick,” including a real-world scenario in which this rare choice of IPsec design is used and working configurations.

Case Study: Small Branch IPsec VPN Tunnel Termination with NAT On-a-Stick In this section, we will discuss a scenario in which a large company in retail wants to deploy secure, low-cost IP communications at each of its stores globally. At each branch location, there are server applications that collect and store customer information and financial data. That data must be reliably relayed to centralized data storage facilities in the company’s data center, which is centrally located at the corporation’s headquarters. For this reason, the customer is interested in a simple, low-cost solution for relaying this information from their many retail locations over the WAN to the data center at the corporate HQ. The corporate IT staff is interested in using an Internet managed service to provide the WAN connectivity to HQ to meet several critical business objectives, including: ■

Support for many branches makes a low-cost managed solution a business requirement, as scaling the solution to the many branches will drive costs up regardless of the per-unit cost.

■

Data confidentiality is a business requirement, as confidential customer information (account numbers, marketing data) is required to be transmitted across a public domain (the Internet).

■

Multiple point-of-sale machines and small-scale servers at the remote retail location require a low-cost LAN solution (multiple Ethernet ports at the retail branch).

The corporation’s IT staff has been in contact with several service providers who will offer managed services that may meet the retailer’s business requirement. The managed service offers

IPsec VPN Termination On-a-Stick

363

basic IP connectivity using a cable modem at the remote retail location. The service also includes a workgroup switch for connecting devices together on the retailer’s LAN, but the functionality of the switch is very basic and therefore does not include support VLANs or 802.1q trunking. Given the retailer’s business objectives, these circumstances present design challenges at the retailer’s remote locations, including the following: ■

Limited publicly routable IP addressing space at the remote retail locations

■

No NAT functionality integrated in to the managed service offering

■

Lack of capabilities for providing data confidentiality (such as using IPsec or crypto) between the remote retail location and the corporate HQ

■

Lack of VLAN awareness on the managed service switch at the remote retail location supports only one L3 broadcast domain at the remote retail LAN

The retailer agrees to a small pilot of the Internet service provider’s (ISP’s) managed service. As depicted in remote retail store LAN pilot topology in Figure 10-1, the corporate IT staff elects to use a small IPsec-enabled router, such as the Cisco 1845 ISR, to enable two key services at the remote retail location—Data Confidentiality (IPsec) and NAT. Let us take a quick step-by-step look at the life of a packet on egress from the remote retail LAN en route to centralized corporate resources before diving in to some configuration examples for enabling data confidentiality and NAT in “on-a-stick” environments: 1.

Hosts and servers on the remote retail branch LAN initiate communications with centralized corporate resources using a default gateway of 192.168.1.2 on the 1845ISR.

2.

The 1845 receives the traffic from step 1 and matches it to an ACL referenced in a route-map that is used for policy routing. The policy route sets the output interface for traffic matching the ACL to router’s loopback201 address.

3.

Before making the forwarding decision described in step 2, the 1845ISR applies the NAT rules defined on the router, as the traffic matches the ACL referenced in the NAT configuration on the router and was received on the inside NAT interface (FastEthernet0/0).

4.

The traffic is forwarded to the loopback201 interface based on the rules defined in the policy routing configuration on the 1845ISR. The privately addressed source IP is translated in to the loopback201 IP (the outside NAT interface), which is publicly routable.

5.

The traffic translated using NAT in step 4 matches a crypto ACL referenced by a crypto map applied to the loopback201 interface. Before forwarding the traffic, the 1845ISR processes the traffic with the appropriate transform.

6.

The 1845ISR forwards the crypto-processed transform to the opposite end of the IPsec VPN tunnel. The packet is now encapsulated with Encapsulating Security Payload (ESP), and the outer IP header is populated with publicly routable IP addresses (the IP addresses of the IPsec peers agreed upon in Phase 2 SA negotiation).

364

Chapter 10: Further Architectural Options for IPsec

Data confidentiality is required across the WAN using IPsec VPN tunnel termination. The IPsec VPN gateway at the remote branch resides out-of-path, and is therefore considered to be deployed “on-a-stick.” This out-of-path design option was selected for the retailer’s pilot program due to the fact that the branch LAN switch is incapable of providing multiple L3 domains. As such, only one L3 domain is presented to the IPsec VPN-enabled router on-a-stick, supporting only a single L2 connection between the router and the switch. Example 10-1 provides a configuration for the retail branch LAN’s IPsec VPN gateway. The IPsec VPN gateway is configured to use the ESP-3DES with MD5 HMAC authentication on data sent to and received from the remote IPsec VPN gateway at 24.10.100.1, as illustrated in configuration lines 10 and 20, respectively. Note that, in line 20, the crypto map is applied to the loopback interface rather than a physical interface. It is important to note that the crypto map matches ACL 102 specifying the inside global IP address space as the source. This is because encryption occurs after NAT when the two are configured concurrently. As illustrated in Example 10-2, all traffic to be translated on-a-stick is policy routed to loopback 201. This enables traffic from the 10.0.0.0/8 address space on the retailer’s LAN to be NAT’d between inside (e0/0) and outside (lo201) before being encrypted using the crypto map on loopback 201. Provided in line 26 is the crypto ACL used by the retail branch LAN VPN gateway. Note that the source IP address space is the inside global address space. This configuration is required for IPsec to properly agree upon consistent protected address space when negotiating a Phase 2 SA, as encryption occurs after NAT. If not properly configured with the correct addresses, a crypto ACL scope inconsistency can cause Phase 2 negotiation to fail. Example 10-1

IPsec VPN Tunnel Termination “On-a-Stick” Using Logical (Loopback) Interfaces

show r unning-con fig C1845-VPN10-A#s Building configuration... ! #10.1.1.100 [403]

*Mar

2 23:23:21.816: NAT: s=10.1.1.100->200.1.1.1, d=11.1.1.1 [404]

*Mar

2 23:23:21.832: NAT: s=11.1.1.1, d=200.1.1.1->10.1.1.100 [404]

■

Example 10-4

Verify that Internet Key Exchange (IKE) and IPsec security associations (SAs) can be established between the device on-a-stick and the opposite endpoint of the IPsec VPN tunnel as in Example 10-4. Verifying Phase 1 and 2 IPsec SA Establishment

show c rypto isak mp sa C1845-VPN10-A#s dst

src

state

24.10.100.1

201.1.1.1

QM_IDLE

conn-id slot

C3800-VPN10-A#sh crypto IPsec sa

4

interface: Loopback201 Crypto map tag: on-a-stick, local addr. 201.1.1.1

0

IPsec VPN Termination On-a-Stick

Example 10-4

367

Verifying Phase 1 and 2 IPsec SA Establishment (Continued) protected vrf: local

ident (addr/mask/prot/port): (200.1.1.0/255.255.255.252/0/0)

remote ident (addr/mask/prot/port): (11.0.0.0/255.0.0.0/0/0) current_peer: 24.10.100.1:500 PERMIT, flags={origin_is_acl,} #pkts encaps: 14, #pkts encrypt: 14, #pkts digest 14 #pkts decaps: 14, #pkts decrypt: 14, #pkts verify 14 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 1, #recv errors 0 local crypto endpt.: 201.1.1.1, remote crypto endpt.: 24.10.100.1 path mtu 1514, ip mtu 1514, ip mtu idb Loopback201 current outbound spi: CD72F170 inbound esp sas: spi: 0xF8F64DEB(4176891371) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 1, crypto map: on-a-stick sa timing: remaining key lifetime (k/sec): (4535979/1289) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xCD72F170(3446862192) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 2, crypto map: on-a-stick sa timing: remaining key lifetime (k/sec): (4535979/1287) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas: C1845-VPN10-A#show crypto engine connections active ID Interface

IP-Address

State

Algorithm

4 Loopback201

201.1.1.1

set

HMAC_SHA+DES_56_CB

Encrypt 0

Decrypt 0

2000 Loopback201

201.1.1.1

set

HMAC_MD5+3DES_56_C

0

14

2001 Loopback201

201.1.1.1

set

HMAC_MD5+3DES_56_C

14

0

368

Chapter 10: Further Architectural Options for IPsec

■

Verify that the negotiation of the IPsec VPN tunnel can be initiated from either endpoint, and that no conflicts reside with NAT at the remote retail branch running IPsec and NAT on-a-stick.

In-Path Versus Out-of-Path Encryption with IPsec Design options that place the IPsec VPN tunnel termination endpoints directly in the data path refer to in-path IPsec VPN tunnel terminations. Figure 10-3 illustrates in-path versus out-of-path IPsec VPN design scenarios in which there is only one available interface for Demilitarized Zone (DMZ) access on the firewall. The administrator wants to encrypt certain traffic flows inbound through the firewall. However, for security reasons, all VPN traffic from and to the enterprise network must be encrypted and decrypted within the DMZ, hereby requiring an out-of-path design. If the firewall were able to terminate the IPsec VPN tunnels natively, without the use of an external IPsec VPN concentrator located in the DMZ, then an in-path design option (also illustrated in Figure 10-3) would be possible in this scenario. Figure 10-3

In-Path and Out-of-Path Design Options with Single DMZ IPsec VPN Tunnel Termination Inside Enterprise Network

Si

Si

Firewall processes packets twice when encryption is performed out of path.

DMZ Internet Edge Firewall

Cleartext DMZ

Loopback0

If IPsec is supported natively on the firewall, crypto processing can be achieved in-path.

Ciphertext Router-on-a-stick uses loopback0 interface to encrypt data flows.

When firewalls do not natively support IPsec, an external VPN gateway is often required to terminate IPsec tunnel in the DMZ.

In-Path Data Flow Out-of-Path Data Flow

Outside

Internet

In-Path Versus Out-of-Path Encryption with IPsec

369

The considerable majority of design options in today’s IPsec VPN environments are in-path. For this reason, among others, it is very common to see network nodes such as routers and switches embed integrated IPsec crypto engines and hardware-based crypto accelerators. The key design benefit of an in-path design is the ability to process crypto traffic in the fast switching path. This design benefit greatly boosts the overall performance of the IPsec VPN. Additionally, it enables network designers to incorporate hardware accelerators to increase performance in the crypto switching path even further. There are limitations with the next design option, out-of-path, that force crypto switching in the process switching path, thereby precluding hardware acceleration design options. In some scenarios, it may be necessary to place one or both IPsec VPN tunnel termination points outside of the data path. This is commonly referred to as “out-of-path” encryption. One such scenario that we’ve explored already is the use of IPsec tunnel termination on-a-stick. This scenario is also found when IPsec tunnels are terminated in firewalled environments, such as the one presented in Figure 10-4. In these scenarios, IPsec VPN termination points are typically located in a DMZ, which may require an out-of-path design. Figure 10-4

In-Path and Out-of-Path Design Options with Dual DMZ IPsec VPN Tunnel Termination Inside Enterprise Network

Si

DMZ2

Si

PIX has two DMZ interfaces, allowing VPN concentrators to have dual uplinks to the PIX, unlike an “on-a-stick” scenario.

Stateful Failover

DMZ1 The VPN concentrator switches packets from DMZ1 to DMZ2, encrypting the data in the fast switching path. While this is still “out-of-path,” the two interfaces to the PIX differentiate this design from “on-a-stick” implementations.

In-Path Data Flow

Out-of-Path Data Flow

ISP

Outside

370

Chapter 10: Further Architectural Options for IPsec

Out-of-Path Encryption Design Overview Although out-of-path encryption options include IPsec VPN tunnel termination “on-a-stick,” this subset of IPsec VPN design alternatives is not limited to that one option. Out-of-path design options can include a single interface, or they can include multiple interfaces. Figures 10-3 and 10-4 illustrate DMZ designs in which inbound IPsec VPN tunnels are terminated on concentrators in the DMZ. Note the comparison of the equivalent in-path design option also illustrated in both options. Figure 10-3 places the IPsec VPN router on-a-stick. Although this option can be effective when required (e.g., due to limited available interfaces on the firewall, and so on), many on-a-stick scenarios require a loopback interface to operate correctly, forcing crypto traffic in to the process switched path. Figure 10-4 illustrates an out-of-path design alternative that does not place the IPsec VPN tunnel termination point on-a-stick. Instead, this dual-DMZ design provisions dual uplinks from the concentrator to the firewall, enabling the IPsec VPN concentrator or gateway to switch all crypto traffic in the fast switching path, and to leverage any available onboard crypto hardware assist resources for increased performance. Although there are ways of optimizing out-of-path design options for increased performance, inpath designs generally yield higher overall performance, as they eliminate the overall switching load of the system. Although the dual-DMZ design of Figure 10-4 yields some performance benefits over the single-DMZ design of Figure 10-3, both scenarios require the firewall to switch the packets at least twice (once in cleartext en route to the IPsec VPN gateway, and once in ciphertext inbound from the IPsec VPN gateway). The in-path design alternative would be to terminate the IPsec VPN tunnels on the firewall itself, or to use an integrated chassis-based solution with installed modules for firewalling and concentrating IPsec VPN tunnels. NOTE Examples of integrated solutions from Cisco Systems include the Catalyst 6500 line of switching platforms that support the Firewall Services Module (FWSM) and IPsec VPN Service Port Adapters (VPN SPA), and the Cisco Integrated Services Router that supports onboard IPsec hardware accelerators and IOS Stateful Firewalling. Although in-path design options generally provide increased performance, and are generally more common, there may be design scenarios in which the needs of the network infrastructure require an out-of-path solution. This is commonly found in DMZ designs, such as the one illustrated in the case study described in the following section.

Case Study: Firewalled Site-to-Site IPsec VPN Tunnel Termination A large marketing firm has increasingly relied on incoming data flows from partner organizations and feeds. As such, the organization is now revisiting its traditional strategy of accepting data feeds from those partners at the Internet-edge DMZ. The corporate IT department has proposed a

In-Path Versus Out-of-Path Encryption with IPsec

371

pilot program to migrate connectivity between key partner organizations to a new extranet design currently in the planning process. The topology of the planned extranet project is illustrated in Figure 10-4. Although the firm's business is increasingly reliant on communications from key partners using the extranet described in Figure 10-4, the corporation’s IT security staff is still concerned that the extranet presents an attack vector if one of the partner networks were to be breached. It is therefore determined that the extranet will deploy statefully redundant firewalls to protect the network against attacks across inbound VPN tunnel traffic from partners. The firewall uses a dual-DMZ approach to address two technical design challenges in firewalled site-to-site IPsec VPN deployments: ■

First, IPsec (IP protocol 50) and Internet Security Association and Key Management Protocol (ISAKMP) (UDP Port 500) control plane traffic must be passed through (using a conduit or ACL) to the local point of IPsec VPN tunnel termination. Allowing such traffic through the firewall presents an attack vector for malicious network users if not managed properly.

■

Second, VPN traffic presented to the outside firewall interface is encapsulated in ESP or Authentication Header (AH). This renders the firewall incapable of making inspection and filtering decisions on the original packet, as it is presented as an encrypted payload. The firewall is therefore unable to determine whether or not the encrypted payload of the VPN traffic is carrying any malicious data.

Example 10-5 provides the firewall diagnostics illustrating the settings for out-of-path IPsec VPN tunnel termination on the extranet deployment illustrated in Example 10-4. The firewall’s security levels and interface IP addresses are configured in lines 1 through 16, allowing data to freely flow from inside networks to outside networks but not vice versa unless the firewall has the required state information to allow return traffic. The inside interface of the firewall is configured to passively listen for Routing Information Protocol (RIP) updates from other RIP routers on the local segment. The only exception to this passive behavior is that the firewall is configured to advertise a single default route to the other RIP routers on the segment. The firewall’s routing table is displayed in lines 20–26. Note there is a static default route pointing to the VPN concentrator on the inside DMZ interface. This effectively forwards all outbound L3 traffic to the concentrator cluster for encryption over the IPsec VPN tunnel. Of critical importance is the NAT and ACL entries on the firewall. Lines 27–34 show an active NAT ACL that is used for translating inside IP addresses in to the inner DMZ interface facing the inside interface of the VPN concentrator. Only traffic matching the ACL will be NAT’d on egress to the PIX. Subsequently, any traffic exiting the firewall that does not match this ACL will not be translated and forwarded to the inside network. This effectively hides all inside IP addresses from the traffic exiting the concentrator. Instead, presenting only one interface with multiple translations for original traffic matching the NAT ACL on the PIX (NAT Overload or PAT), effectively allowing for added security. The named ACL “vpngroup” is the ACL referenced by NAT instance 1, making it a NAT ACL. Traffic matching this ACL

372

Chapter 10: Further Architectural Options for IPsec

on received on the inside interface will be translated in to the IP information referenced in by the corresponding global instance. The global instance below (1) maps to traffic matching the NAT ACL above. The traffic matching the NAT ACL will therefore be translated to the IP address of the inner-inner interface on the firewall. The static shown in line 36 allows the outside extranet partner’s IPsec VPN gateways to reach the privately addressed VPN tunnel termination point (192.168.1.1) directly attached to the firewall’s outer-outer interface using a public IP address (200.1.1.3) within the IP address range assigned to the outside interface (200.1.1.0/24). The named ACL, “vpn-control,” allows crypto control plane traffic through the firewall to the outerouter interface. ISAKMP traffic (UDP port 500) (IP protocol 50) must be allowed to the concentrator to establish the appropriate SAs, and ESP must be allowed to transport encrypted traffic between the IPsec VPN tunnel endpoints. Note that, although this effectively pokes holes through the firewall, they do not go all the way through to the inside interface. This ACL works with the static translation above to limit access from traffic matching this ACL only to the concentrator on the outer DMZ. There is no exception or ACL on the inner DMZ interface allowing crypto control plane traffic through. Example 10-5

Dual-DMZ Firewall Design for Extranet Edge IPsec VPN Tunnel Termination

crvpn-pix525-a# show nameif nameif ethernet0 outside security0 nameif ethernet1 inside security100 nameif ethernet2 dmz-outer security51 nameif ethernet3 dmz-inner security52 crvpn-pix525-a# sh ip System IP Addresses: ip address outside 200.1.1.1 255.255.255.0 ip address inside 10.1.1.1 255.255.0.0 ip address dmz-outer 192.168.1.2 255.255.255.0 ip address dmz-inner 192.168.2.2 255.255.255.0 Current IP Addresses: ip address outside 200.1.1.1 255.255.255.0 ip address inside 10.1.1.1 255.255.0.0 ip address dmz-outer 192.168.1.2 255.255.255.0 ip address dmz-inner 192.168.2.2 255.255.255.0 crvpn-pix525-a(config)# show rip rip inside passive version 2 rip inside default version 2 crvpn-pix525-a(config)# sh route dmz-inner 0.0.0.0 0.0.0.0 192.168.2.1 1 OTHER static inside 10.1.0.0 255.255.0.0 10.1.1.1 1 CONNECT static inside 100.0.0.0 255.0.0.0 10.1.1.2 1 RIP dmz-outer 192.168.1.0 255.255.255.0 192.168.1.2 1 CONNECT static dmz-inner 192.168.2.0 255.255.255.0 192.168.2.2 1 CONNECT static outside 200.1.1.0 255.255.255.0 200.1.1.1 1 CONNECT static crvpn-pix525-a# show nat nat (inside) 1 access-list vpn-group1 0 0 crvpn-pix525-a# show access-list vpn-group1

In-Path Versus Out-of-Path Encryption with IPsec

Example 10-5

373

Dual-DMZ Firewall Design for Extranet Edge IPsec VPN Tunnel Termination (Continued)

access-list vpn-group1; 1 elements access-list vpn-group1 line 1 permit ip 100.1.1.0 255.255.255.0 30.1.1.0 255.255.255.0 (hitcnt=10) crvpn-pix525-a# show global global (dmz-inner) 1 interface crvpn-pix525-a# show static static (dmz-outer,outside) 200.1.1.3 192.168.1.1 netmask 255.255.255.255 0 0 crvpn-pix525-a# show access-list vpn-control access-list vpn-control; 2 elements access-list vpn-control line 1 permit esp host 200.1.1.2 host 200.1.1.3 (hitcnt=50) access-list vpn-control line 2 permit udp host 200.1.1.2 host 200.1.1.3 eq isakmp (hitcnt=0)

In this dual-DMZ scheme, all IPsec VPN tunnel traffic is terminated in the outer DMZ. After the concentrator decrypts the traffic inbound across the IPsec VPN tunnel on the outer DMZ, it forwards the traffic back to the firewall on the inner DMZ interface in cleartext. Now that the packet is presented to the firewall in cleartext, the firewall is now capable of making another filtering decision based on the full contents of the packet. Figures 10-5 through 10-10 illustrate the required configuration of the VPN concentrators deployed in the design topology depicted in Figure 10-4. The VPN concentrators can be configured for network connectivity via a console port and command-line interface (CLI). Once the concentrator is configured for network access, the VPN3000 concentrator GUI can be used to configure and manage the concentrator over either HTTP or HTTPS sessions. Figure 10-5 displays the VPN3060 IP address configuration for the concentrator cluster illustrated in Figure 10-4. Figure 10-5

Dual-DMZ, Out-of-Path, VPN 3060 Concentrator IP Addressing

374

Chapter 10: Further Architectural Options for IPsec

VPN3000 concentrators support routing protocols, including Open Shortest Path First (OSPF), RIP, and static routing. Figure 10-6 illustrates the definition of a default static route on the VPN3060 concentrators depicted in Figure 10-4. Figure 10-6

Dual-DMZ, Out-of-Path, VPN 3060 Concentrator Routing Table

Figure 10-7 illustrates the configuration of the VPN3060’s active IKE policies to use for authenticating Phase 1 SAs inbound from remote branch offices. Figure 10-7

IKE Proposal Selection on the VPN 3060 Concentrator

In-Path Versus Out-of-Path Encryption with IPsec

375

Although there are numerous preconfigured IKE proposals that can be activated on the VPN3060, they can be customized. Figure 10-8 provides an example of how to modify a preexisting IKE proposal on the VPN3060. Figure 10-8

IKE Proposal Configuration/Modification on the VPN 3060 Concentrator

Figure 10-9 displays the required IPsec peering configuration for a site-to-site IPsec VPN tunnel negotiation with the remote branch, which is, in this case, a small home office hardware VPN client with the IP address 200.1.1.2. Here, the IKE proposal “IKE-3DES-SHA1-DH2” is used for Phase 1 negotiation, and 3DES ESP transform (“ESP-3DES”) with 160-bit SHA1 MAC authentication (“ESP/SHA/HMAC-160”) is used for Phase 2 SA negotiation with 200.1.1.2. Figure 10-10 provides a continuance of the screen capture provided in Figure 10-9, and also depicts the crypto-protected address space specification to use in the IPsec Phase 2 SA negotiated with 200.1.1.2. In this case, traffic originated from 192.168.2.2 to 30.1.1.0/24 is included in the crypto switching path.

376

Chapter 10: Further Architectural Options for IPsec

Figure 10-9

Dual-DMZ, Out-of-Path, VPN 3060 IPsec VPN Tunnel Configuration (1 of 2)—Peering, IKE, and Transforms

Figure 10-10

(Figure 10-9 continued)Dual-DMZ, Out-of-Path, VPN 3060 IPsec VPN Tunnel Configuration (2 of 2)—Protected Address Space Definition

In-Path Versus Out-of-Path Encryption with IPsec

377

In the design topology illustrated in Figure 10-4 and the corresponding configuration examples presented in Figures 10-5 through 10-10, data is taken slightly out-of-path to the outer DMZ then injected back in-path on the inner DMZ. Although this type of design requires more processing overhead on the firewall, it is very popular and is in many cases the optimal design choice when increased security surrounding the VPN tunnel termination point is required. Alternatives such as the one described previously are the methods of choice for many Internet edge, WAN edge, and extranet edge designs. Now that the firewalled dual-DMZ infrastructure has been deployed and the VPN concentrator is configured for site-to-site VPN tunnel termination from the extranet partners, the firm’s IT staff takes several measures to verify the operation of the extranet infrastructure: Step 1

Example 10-6

Verify that inside addresses are being translated to the inner-inner address+port. The debug trace provided in Example 10-6 is initiated by a ping from 100.1.1.1 to 30.1.1.1 (matching the NAT ACL in Example 10-5). We can verify from these debug traces that the source address is being translated to the inside DMZ interface (192.168.2.2) and also that return traffic is being untranslated accordingly.

Verifying NAT Between Inside Addresses and the Inner-Inner Interface Address

crvpn-pix525-a# debug icmp trace 2241: ICMP echo-request from inside:100.1.1.1 to 30.1.1.1 ID=36 seq=0 length=80 2242: ICMP echo-request: translating inside:100.1.1.1/36 to dmz-inner:192.168.2.2/25 2243: ICMP echo-reply from dmz-inner:30.1.1.1 to 192.168.2.2 ID=25 seq=0 length=80 2244: ICMP echo-reply: untranslating dmz-inner:192.168.2.2/25 to inside:100.1.1.1/36

Step 2

Example 10-7

Verify that the private address allocated to the public concentrator address is being translated in to a publicly routable IP address on the outside interface. A ping from the extranet partner VPN gateway (200.1.1.2) to the outside address NAT’d to the VPN concentrator outside address (192.168.1.1) creates the following trace displayed in Example 10-7. We can determine that outside hosts are able to successfully use the outside address of 200.1.1.3 to reach the nonroutable concentrator outside address of 192.168.1.1

Verifying Static NAT Between Outside IP Address 200.1.1.3 and the VPN Concentrator Address (192.168.1.1)

debug icmp trace crvpn-pix525-a#d 2266: ICMP echo-request from outside:200.1.1.2 to 200.1.1.3 ID=58 seq=0 length=80 2267: ICMP echo-request: untranslating outside:200.1.1.3 to dmz-outer:192.168.1.1 2268: ICMP echo-reply from dmz-outer:192.168.1.1 to 200.1.1.2 ID=58 seq=0 length=80 2269: ICMP echo-reply: translating dmz-outer:192.168.1.1 to outside:200.1.1.3

378

Chapter 10: Further Architectural Options for IPsec

NOTE The debug trace previously requires that Internet Control Message Protocol (ICMP) traffic be allowed through the firewall from 200.1.1.2 to 200.1.1.3 using either an ACL or conduit. The IT staff inserts an entry in to the ACL permitting ICMP for troubleshooting purposes during initial install, then removes the ACE corresponding to ICMP before the extranet connection is committed in to production.

Step 3

Verify negotiation of IPsec and ISAKMP SAs on the remote extranet peer. In the design scenario listed in Figure 10-4, a router running Cisco IOS is used to terminate the IPsec VPN tunnel on the extranet partner side. The diagnostic output supplied in Example 10-8 verifies encryption and decryption occurring in the crypto engine for SA’s established with the extranet concentrator cluster.

NOTE The tunnel definition is actually built to the PIX outside interface IP (200.1.1.3) that is translated to the concentrator’s physical public IP (192.168.1.1). The static NAT entry configured on the PIX is listed in line 36 of Example 10-5.

Example 10-8

Verifying SA Establishment on the Remote Extranet Partner’s VPN Gateway

show c rypto engi ne connect ions active crvpn-3600-e#s ID Interface

IP-Address

State

Algorithm

Encrypt

Decrypt

2 Ethernet0/0

200.1.1.2

set

HMAC_SHA+DES_56_CB

0

0

2012 Ethernet0/0

200.1.1.2

set

HMAC_SHA+3DES_56_C

0

5

2013 Ethernet0/0

200.1.1.2

set

HMAC_SHA+3DES_56_C

5

0

Step 4

Verify the successful negotiation of IPsec LAN-to-LAN Sessions (Phase 2 SA) on the IPsec VPN concentrator. Figure 10-11 verifies that there is an active IPsec VPN session on a VPN3060 concentrator in the cluster in the design presented in Figure 10-5.

Separate Termination of IPsec and GRE (GRE-Offload)

Figure 10-11

379

Verifying SA Establishment on the Extranet DMZ Concentrator Cluster

Separate Termination of IPsec and GRE (GRE-Offload) In Chapter 3, “Basic IPsec VPN Topologies and Configurations,” we introduced the need to encapsulate traffic to be included in the crypto switching path in generic routing encapsulation (GRE) prior to crypto processing, a technique we’ve referred to as IPsec+GRE. Until now, we’ve explored integrated design options in which IPsec and GRE processing both occurred on the same VPN platform. In this section, we will discuss situations in which it is more appropriate to separate the processing of IPsec and GRE on to different platforms, a technique referred to as IPsec+GRE with GRE-offload.

GRE-Offload Design Overview The need to forward IP Multicast traffic in the crypto switching path is the most prominent driver for IPsec+GRE designs. This is because IPsec alone will not support the encrypted multicast traffic. However, if one were to encapsulate a multicast packet in GRE prior to encryption, this would present a unicast traffic flow (the GRE traffic flow, with a multicast payload) to the IPsec crypto engine. This enables IPsec to forward the unicast GRE packet to the opposite end of the tunnel, where the IPsec headers (ESP, AH, or both) are decapsulated before the GRE headers are

380

Chapter 10: Further Architectural Options for IPsec

decapsulated. This operation results in an IP multicast packet presented in cleartext to be forwarded in normal IP multicast forwarding path at the opposite end of the tunnel. In previous chapters, we’ve discussed several design issues that GRE encapsulation prior to encryption presents, including the effect of tunnel fragmentation (Chapter 5, “Designing for High Availability”) and the impact on geographic HA (Chapters 5 and 7, “Solutions for Geographic Siteto-Site High Availability”). These design considerations, however, apply to both consolidated and separated termination of IPsec and GRE in IPsec+GRE solutions. But, there are two key design considerations that mandate separate termination of IPsec+GRE tunnel termination—lack of support for GRE on the VPN gateways and insufficient performance for GRE on the IPsec VPN gateways. Lack of Support for GRE Processing In many circumstances, IPsec VPN-enabled devices will not support the termination of GRE. One such example in which IPsec VPNs are commonly terminated on IPsec VPN devices that do not support GRE is when PIX firewalls are used as the IPsec gateways. This is a perfectly valid solution for IPsec VPN tunnel termination, but in situations in which IPsec+GRE is required, a separate device is required to perform the GRE encapsulate/decapsulate operations on the firewall inside interface or DMZ. Figure 10-12 illustrates a GRE-offload scenario with PIX used as the IPsec VPN tunnel termination point. Figure 10-12

PIX IPsec VPN Tunnel Termination with GRE-Offload

Redundant firewall deployed for stateful failover (Active/Passive).

Site A

Switches are L2only (No native support for IPsec).

Switches are L2only (No native support for IPsec).

Redundant firewall deployed for stateful failover (Active/Passive).

Site B

DWDM MAN

PIX firewalls terminate the IPsec VPN tunnel on their outside interfaces. Alternatively, routers could be used to terminate GRE in the DMZ. Routers terminate the GRE tunnels inside the PIX firewalls, allowing multicast flows with IPsec + GRE.

PIX firewalls terminate the IPsec VPN tunnel on their outside interfaces. Alternatively, routers could be used to terminate GRE in the DMZ. Routers terminate the GRE tunnels inside the PIX firewalls, allowing multicast flows with IPsec + GRE.

Low GRE Performance IPsec+GRE is driving increased GRE performance in many integrated routing and switching platforms that support IPsec VPN tunnel termination. Many of today’s midrange routers and IPsec appliances still do not support hardware-based GRE forwarding. However, GRE performance is a

Separate Termination of IPsec and GRE (GRE-Offload)

381

critical design requirement in large-scale site-to-site IPsec VPN tunnel concentration platforms. It is therefore very common to see IPsec VPN processing and GRE tunnel processing separated in this type of environment, as illustrated in Figure 10-13. Figure 10-13

Large-Scale Site-to-Site IPsec+GRE VPN Tunnel Concentration with GRE-Offload

GRE portion of the IPsec + GRE tunnel is decapsulated here in hardare (GRE-Offload), after decryption and firwalling. Cleartext Firewalled Path

Enterprise Internet Edge Ciphertext Firewalled Path

To: Core

IPsec

Si Cleartext Firewalled Path

ISP IPsec

To: Core

Remote Branch Network VPN T unnel

VPN

To: Branch LAN

l Tunne

Si Ciphertext Firewalled Path

The branch network terminates the IPsec VPN.

Branch terminates GRE traffic (GRE-Offload) post decryption and firewalling.

IPsec VPN tunnel terminated at the Internet edge DMZ.

GRE portion of the IPsec + GRE tunnel is decapsulated here in hardare (GRE-Offload), after decryption and firwalling.

In Figure 10-13, IPsec is processed in hardware with high-speed IPsec VPN SPA included in the Catalyst 6500 switches at the enterprise campus WAN edge. The GRE processing is offloaded to the 7304 VXR routers behind 6500s so as to present all multicast traffic on egress to the branch in a unicast format to the 6500 VPN SPAs responsible for crypto processing. This design scenario is a very popular option, yielding high-speed hardware-assisted crypto forwarding for both unicast and multicast GRE payloads. The following case study aims to reinforce this design, in a realworld enterprise deployment. NOTE The Internet Engineering Task Force (IETF) is current working on a draft for encrypted multicast forwarding technique called Group Domain of Interpretation (GDOI) that enables native IPsec (without GRE) to support encryption of multicast IP flows. It further enables the multicast fanout to occur after encryption, which greatly decreases the load on the crypto engine relative to an IPsec+GRE scenario. GDOI is outside of the scope of book, but more information on IPsec, GDOI, and IP Multicast forwarding can be found within the following Internet draft for RFC 3547 located here: http://tools.ietf.org/wg/msec/draft-ietf-msec-gdoi/rfc3547.txt

382

Chapter 10: Further Architectural Options for IPsec

Case Study: Large-Scale IPsec VPN Tunnel Termination with GRE Offload A large retail bank currently employs multiple large-scale WAN aggregation hubs for its thousands of retail branch offices scattered across the nation. Although the WAN edge deployments all follow the same design layout illustrated in Figure 10-13, the bank’s IT staff has decided on multiple Internet-edge deployments located in Charlotte, Seattle, and Chicago to concentrate inbound WAN connectivity for the branches located in the eastern, western, and central United States, respectively. This offers the firm a measure of increased scalability and resiliency to disaster recovery over a consolidated single-site design. The bank had decided to expand its service offering some time ago by purchasing an investmentbanking arm and a private equity arm. In order to increase workforce flexibility, and expand the geographic presence of these services, the bank employs these staff members at remote locations from time to time. One key service that these professionals rely on is the timely and accurate feed of stock quotes using an IP multicast stock quote server application residing in one of the organization’s data centers in Dallas, Texas. The multicast traffic must therefore be confidentially transmitted from the data center across the WAN links to the remote branch locations. As such, multicast data is required to be encapsulated in GRE prior to being encrypted in IPsec, a technique we’ve previously referred to as IPsec+GRE. The typical bank branch is capable of terminating the IPsec+GRE traffic sequentially on the same IPsec VPN gateway. Therefore, a consolidated point of termination for IPsec and GRE tunnels is employed at the bank branch. However, due to sheer number of branches terminating their WAN connections at the three Internet-edge locations, scalability problems have presented themselves with a consolidated termination approach: ■

The encryptor at the headend relies on IPsec hardware acceleration to process all of the traffic inbound from the WAN in the crypto switching path. Lack of support for GRE hardware acceleration causes a bottleneck in the switching path when encapsulating/decapsulating the packets in GRE (IP traffic is being encrypted/decrypted faster than it can be encapsulated/ decapsulated in GRE).

■

The number IPsec and GRE tunnels terminated on the same platform are overrunning the WAN link aggregation platforms.

For these reasons, the firm decides to make some key alterations to its Internet-edge design using GRE-Offload. First, the IT staff has decided to increase the crypto switching capacity at the headend by introducing newer crypto hardware assist modules to its current platforms. The existing platforms, however, will not process the GRE traffic in the fast switching path. As such, the IT staff has decided to make a complementary investment to their new crypto processing hardware by investing in newer switching engines with onboard crypto hardware assist processors. Lastly, the firm has decided upon a staged update of its branch platforms to include increased crypto

Separate Termination of IPsec and GRE (GRE-Offload)

383

processing power. These branch platforms do not require GRE processing in hardware, as GRE scalability limitations were only being reached at the aggregation point of the IPsec+GRE VPN tunnels, not on the branches themselves. These changes all culminate in an Internet-edge design that follows the topology illustrated in Figure 10-13. Additionally, the firm decides to implement the following features in to the platform-specific design elements of its larger IPsec VPN architecture: ■

Dynamic Crypto Maps

■

IKE Extended Authentication

■

Separate Encrypted and Cleartext Firewall Paths

■

High Speed GRE Tunnel Termination for GRE Offload

Dynamic Crypto Maps and GRE-Offload Dynamic crypto maps are used on the headend platforms aggregating the IPsec VPN tunnels. This allows for better management of the SADB on the headend platforms. It also allows for decreased management of peering sessions to the branches as they are moved, added, or changed. Note that this option does not use Tunnel Endpoint Discovery (TED), and therefore only the branch routers can initiate the establishment of an IPsec VPN tunnel. It is important to consider the administration and configuration management differences between a traditional IPsec+GRE headend configuration and an IPsec+GRE configuration with GREOffload. With a traditional IPsec+GRE scenario in which both IPsec and GRE configuration occurs on the same box, the addition of a new IPsec+GRE tunnel on the IPsec+GRE headend forces the configuration to be changed regardless of whether dynamic crypto maps are used or not. The separation of IPsec and GRE configurations on IPsec+GRE changes the administration requirements in a GRE-Offload deployment. Although the configuration of the GRE headend router must be changed whenever an IPsec+GRE tunnel is added in an IPsec+GRE Offload scenario, dynamic crypto maps can be used on the router terminating the IPsec portion of the IPsec+GRE headend to eliminate the need to change the configuration of the crypto headend when a new IPsec+GRE tunnel is added. This design element of the IPsec with GRE-Offload configuration therefore eliminates the opportunity for configuration or administration errors during maintenance windows. TIP Dynamic Multipoint VPN can eliminate configuration changes on the headend router further. Like IPsec+GRE Offload, DMVPN employs the use of dynamic crypto maps to negate the need to alter the crypto configuration on the headend. In addition, DMVPN employs NHRP to provision the GRE portion of the IPsec+GRE tunnel dynamically. DMVPN headend configuration is therefore considered to be “touchless” when deploying new IPsec+GRE tunnels. We will discuss DMVPN in greater detail in Chapter 7, “Solutions for Geographic Siteto-Site High Availability.”

384

Chapter 10: Further Architectural Options for IPsec

Example 10-9 provides several key configuration elements required for IPsec+GRE with IKE xAuth. First, the two ends of the IPsec VPN tunnel must agree on parameters used to authenticate the IKE channel during Phase 1 negotiation. The IKE policy (10) used to accomplish this task is displayed in lines 1-5 of Example 10-9 following. In this case, an added layer of authentication is used to authenticate the IKE channel against a TACACS+ database. This is known as IKE x-Auth and is commonly referred to as IKE Phase 1.5 negotiation (Example 10-10). The dynamic map provided in lines 10 and 11, “c10-iedge-dyn,” references the transform set provided in line 8, “c10iedge-trans,” that defines the cryptographic transforms to be used in the Phase 2 SA. This dynamic crypto map is then bound to a static crypto map defined in configuration lines 13-14, which is then applied to the crypto interface with configuration line 21. Example 10-9

Dynamic Crypto Map Configuration on IPsec+GRE Crypto Headend Platform

crypto isakmp pol icy 10 encr 3 des authen tication pr e-share group 2 ! crypto isakmp key c10-i edge addres s 192.168 .0. 0 255.255.0.0 ! cryp to I Psec transform -set c10-ie dge-tr ans esp-3des esp-md5 -sha ! c rypto dyna mic-map c1 0-iedge-dyn 10 se t tran sfo rm-set c10 -iedge-tran s ! crypto m ap c10-ied ge-sta t local -address Loo pback1 crypto map c10-ie dge-stat 1 0 IPsec-isa kmp dynamic c10 -iedge-dyn ! interface S erial 0/0 ip addre ss 200. 1. 1.1 255.255 .255.252 en ca psulation frame-relay frame- relay inte rface-dlci 102 frame-re lay lmi-ty p e ansi crypto map c10-i edge-stat

IKE Extended Authentication (X-Auth) IKE x-Auth provisions another layer of authentication of the IKE SA using a unique username/ password on a centrally managed authentication, authorization, and accounting (AAA) server using either TACACS+ or RADIUS. This design option enables the enterprise to manage preshared keys (PSKs) used during x-Auth more granularly, eliminating issues with peer eviction from the group. IKE x-Auth is discussed in greater detail in Chapter 12, “Solutions for Handling Dynamically Addressed Peers.” The crypto headend platforms use the IKE X-Auth configuration supplied in Example 10-10.

Separate Termination of IPsec and GRE (GRE-Offload)

Example 10-10

385

IKE X-Auth Configuration on IPsec+GRE Crypto Headend Platform

aaa au thenticati on login v pn-auth group radius a aa a ut horization network vpn - auth grou p radius ! crypto map e xtranet cl ient authen tication list vpn-auth cry pto map e xtranet is akmp a uthori zation list vpn-aut h ! radiu s-server ho st 10.1. 20.100 ra dius-server key c isco

Firewalled Cleartext Traffic There are two paths through the firewall, allowing cleartext traffic to flow directly from inside to outside interface, and allowing crypto-switched traffic to flow bidirectionally between the outside and DMZ interfaces on the firewall. This design option allows for increased security for cleartext traffic, while allowing branches to establish IPsec tunnels through the firewall (hereby leveraging the dynamic crypto map on the headend IPsec VPN router). Example 10-11 provides the sample configuration for the IPsec+GRE deployment in Figure 10-13. Example 10-11

Firewall Configuration Example for IPsec+GRE Concentration in DMZ

crvpn-pix525-a(config)# nameif eth0 outside 0 crvpn-pix525-a(config)# ip address outside 200.1.1.10 255.255.255.0 crvpn-pix525-a(config)# nameif eth2 dmz-vpn 50 crvpn-pix525-a(config)# ip address dmz-vpn 192.168.1.100 255.255.255.0 crvpn-pix525-a(config)# nameif eth1 inside 100 crvpn-pix525-a(config)# ip address inside 10.1.1.1 255.255.255.0 ! crvpn-pix525-a(config)# access-list VPN permit udp any host 200.1.1.1 eq isakmp crvpn-pix525-a(config)# access-list VPN permit esp any host 200.1.1.100 ! crvpn-pix525-a(config)# access-group VPN in interface outside ! crvpn-pix525-a(config)# static (dmz-vpn,outside) 200.1.1.100 192.168.1.100

High-Speed GRE Tunnel Termination for GRE-Offload GRE tunnel termination is offloaded from the crypto headends to platforms that can encapsulate and decapsulate the GRE tunnel traffic in the fast switching path. In this case, as illustrated in Figure 10-13, the enterprise has elected Catalyst Supervisor 720 switching engine on their Internet-edge distribution switch pair to aggregate termination of the GRE tunnels from the Branch routers.

386

Chapter 10: Further Architectural Options for IPsec

Summary In this chapter, we’ve reviewed several architectural options, discussing the technical details of each and exploring their appropriateness in an IPsec VPN design. Some of the topics covered are more popular in today’s networked environment than others. Yet other architectural options such as IPsec with GRE-Offload have become so popular that many IPsec VPN designers consider them to be fundamentally mainstream. Regardless, each design in this chapter has a baseline fundamental IPsec design alternative. The majority of the designs discussed in this chapter, though useful in their given place and in very specific user cases where a more mainstream design cannot be implemented, should therefore be evaluated against the fundamental designs discussed in previous chapters to determine how adequately and effectively they meet your organization’s design objectives. This chapter covers IPsec with “router-on-a-stick” design. Designs “on-a-stick” refer to features and functionality running on a device with only one interface to the network infrastructure. Examples of technologies that can exist on-a-Stick include router-on-a-stick, NAT-on-a-stick, and IPsec-on-a-stick. Many of these technologies can exist together on-a-stick, as we had discussed in our case study earlier in this text. IPsec-on-a-stick can add value in situations in which only one interface is available to the network. However, because many on-a-stick functionality requires the use of a loopback interface on lower-end routing platforms, the switching performance of an ona-stick design can be somewhat compromised compared to that of a traditional in-path design. This coupled with the fact that most on-a-stick deployments can be revamped in to a traditional in-path design rather easily and at relatively low cost make on-a-stick deployments rare. The chapter also covers out-of-path IPsec VPN tunnels, design topologies in which encrypted data-plane traffic is directed outside of the unencrypted data-plane traffic flow due to crypto processing requirements. Out-of-path design alternatives for IPsec are perfectly valid. One such option is the termination of RAVPN clients on a concentrator cluster in the Internet-edge DMZ. As we have discussed previously in this chapter, this design calls for encrypted traffic to be passed from the outside firewall interface to the outside DMZ interface where it is decrypted at the concentrator cluster outside interface. The cleartext traffic is then forwarded from the concentrator cluster inside interface to the inner DMZ interface on the firewall where it is then allowed to pass to the firewall’s inside interface and eventually in to the inside network itself. This detour for encrypted traffic through the concentrator cluster on the DMZ is an out-of-path detour from what would have occurred during an unencrypted traffic flow, flowing directly from inside to outside interfaces and vice versa. Any potential decrease in performance due to out-of-path processing is vastly outweighed by the security benefits resulting from the firewalled location of the concentrator cluster, making this further architectural IPsec VPN design option the optimal choice for many network environments.

Summary

387

Finally, this chapter covers IPsec+GRE with GRE-Offload. IPsec+GRE is a requirement in many networks where confidentiality of IP multicast traffic is required. Such IP multicast traffic could include not only data-plane multicast flows such as IP/TV streams, multicast VoIP flows, and realtime multicast data feeds, but also multicast control-plane traffic such as multicast routing protocol updates (RIP, OSPF, EIGRP, ISIS, PIM, and so on). This design option has become increasingly popular. And, as the switching capacity for GRE tunnels increases in IPsec VPN platforms, this design will continue to merge with the set of baseline fundamental IPsec VPN designs.

Part III: Advanced Topics

Chapter 11

Public Key Infrastructure and IPsec VPNs

Chapter 12

Solutions for Handling Dynamically Addressed Peers

CHAPTER

11

Public Key Infrastructure and IPsec VPNs A Public Key Infrastructure (PKI) entails a system of cryptographic endpoints that use an infrastructure of trusted resources, such as Certificate Authorities (CAs) and Registration Authorities (RAs), to facilitate a cryptographic transaction in a trusted manner. In large enterprise-class IPSec VPN designs, the burden of key management can be overwhelming. When the number of cryptographic endpoints scales upwards, so does the need to for a centralized, scalable method of key management between the cryptographic endpoints, or in this case, between the IPSec VPN gateways. A PKI can be used in varying types of cryptographic solutions. However, in the context of IPSec VPN deployments, the PKI entails the following elements: ■

The cryptographic endpoints participating in the PKI are IPSec VPN gateways.

■

The resource trusted by the cryptographic endpoints of the PKI is the PKI Certificate Authority (and optionally, a system of Registration Authorities).

■

The secure transaction that needs to be facilitated in a trusted manner is the exchange of public keys between the cryptographic endpoints for authenticating and encrypting the IKE SA.

Using the elements listed in the bulleted list above, PKIs present a comprehensive and scalable design option for secure key management in large-scale IPSec VPN deployments. Cisco IPSec VPN technologies support PKIs using the RSA Signatures method of IKE authentication, which describes an asymmetric authentication and encryption scheme used in the negotiation and operation of Phase 1 SAs. In this chapter, we will discuss a brief history and overview of PKI, then proceed to discuss the advantages to deploying IPSec VPNs using the RSA Signature method of IKE authentication in a PKI architecture.

PKI Background Thus far, we’ve explored the concepts of symmetric key and asymmetric key encryption as they pertain to IPSec and various IPSec designs. Asymmetric key encryption leverages PKI to reinforce the community of trust within a network of cryptographic endpoints and other cryptographic elements, such as certificate authorities and registration authorities. Now, we will take a deeper look at asymmetric key encryption technology as it pertains to public key infrastructures (PKI).

392

Chapter 11: Public Key Infrastructure and IPsec VPNs

Lenin once said that “trust is good, but control is better”—he would have appreciated the need for asymmetric key encryption. Public key cryptography was born from the concept of controlling issues surrounding trust between two cryptographic endpoints that symmetric key encryption itself did not address. Remember that in symmetric key encryption, two cryptographic endpoints must share the same encryption key, since that key is also used for decryption. The integrity of this cryptographic operation relies on the security of the exchange of symmetric keys between the cryptographic endpoints. Therefore, the control of trust in a symmetric key encryption scheme lies on the secure channel over which the keys are exchanged, in addition to the strength of the keys themselves. Public key cryptography shifts the control of trust away from the secure channel of key exchange onto the generation of the asymmetric keypair—only a public key is exchanged freely, while the corresponding private key is not. In 1976, Whitfield Diffie and Martin Hellmann introduced the concept of public key cryptography in their publication entitled “New Concepts in Cryptography.” Their concept described an asymmetric cryptographic operation, outlining the use of two keys—a public key used only for encryption and a private key used only for decryption. The two keys are mathematically related, but related in a way such that it is computationally infeasible to derive one key from the other. Additionally, information encrypted with a public key can only be decrypted using the corresponding private key. This cryptographic concept moves control over the security of cryptographic keys away from the manner in which they are exchanged and into the derivation of the keys itself. Central to this concept is the fact that the public key of an asymmetric keypair can be freely distributed without compromising the confidentiality or integrity of encrypted communications. NOTE Although asymmetric cryptography provides a more secure framework for key management and exchange than that of a traditional symmetric key cryptographic operation, there are still trust and authentication issues inherent to pure asymmetric cryptography. We will discuss these issues as they pertain to RSA Encryption and IKE. We will then discuss the RSA Signature method of IKE authentication and how PKIs can be used effectively to address issues of trust and control in asymmetric cryptographic systems.

Consider the example in Figure 11-1, where Caroline intercepts the public key that James tries to send to Charlie so that Charlie can encrypt messages to James. Because the public key only encrypts information, Caroline cannot use the key to decipher encrypted communication between James and Charlie. Additionally, because James uses strong cryptographic keys, which are refreshed periodically, Caroline is not able to derive James’ private key from the public key that she has intercepted.

PKI Background

Figure 11-1

393

What Can Be Done with a Compromised Public Key?

Public Key

Caroline Intercepts James’ public key en route to Charlie.

Private Key

James

Charlie

Caroline can encrypt messages to James.

Caroline cannot decrypt messages from James.

Caroline

Although PKI does eliminate the need for authenticated, confidential distribution of symmetric keys, there must be additional mechanisms to enforce trust amongst cryptographic endpoints. As we have discussed, an attacker cannot do as much damage with a compromised public key as they could do with a compromised symmetric key. They could, however, have an impact in the authenticity of messages within the network. Because of this, there need to be additional measures to ensure that public keys are only exchanged among trusted cryptographic elements. Two measures that we have explored thus far, RSA encryption and Diffie-Hellman key exchange, have these elements of trust built into the cryptographic algorithm itself. Others rely on PKIs that use Certificate Authorities—central, trusted, repositories for maintaining keys with authentication and integrity. Consider again the example in which Caroline intercepts a public key en route from James to Charlie. Although Caroline is unable to decrypt information from James and Charlie, she is still capable of using the public key maliciously—she could, for example, now use James’ public key to encrypt information and send it to James as if she were Charlie. NOTE An attack scenario in which a malicious party inserts themselves in between two or more communicating partners to manipulate and eavesdrop on data in transit is commonly referred to as a man-in-the-middle attack. Recall that this attack was discussed in the scenario described in Figure 2-9 in Chapter 2, “IPsec Fundamentals.”

394

Chapter 11: Public Key Infrastructure and IPsec VPNs

How can James be certain that the information that he decrypts with is private key is authentic with preserved integrity knowing that his public key was distributed freely and openly? There exists a need for additional methods of data authentication and data integrity that deliver this level of trust, which is what PKI is all about.

PKI Components PKIs employ a suite of cryptographic devices that ensure that public keys are managed securely. These devices work in tandem with to perform a wide array of functions relevant to managing public key distribution, including the following: 1.

Authenticating and registering cryptographic endpoints

2.

Verifying the integrity of public keys

3.

Authenticating requests for stored public keys

4.

Securely issuing public key certificates

5.

Revoking public keys that are no longer valid

6.

Maintaining public key revocation information (CRL) and distributing the information (via CRL issuance or responding to Online Certificate Status Protocol [OCSP] messages)

7.

Securely storing valid public keys

We will now explore the function of each of these PKI elements, and then we will walk through the life of a PKI certificate and explore some working scenarios involving cryptographic endpoints and PKI.

Public Key Certificates The goal of an asymmetric key exchange is to securely distribute the public key to a party who wants to transmit (encrypt) data to the receiving (decrypting) party. A PKI helps to facilitate this key exchange securely while ensuring authenticity of both exchanging parties. The first step in this exchange is the creation of a public key certificate. A public key certificate can correspond to any node that can be referenced in the subject field of the public key certificate. NOTE PKI certificates in today’s cryptographic network follow the ITU-T standard formatting for X.509v3 certificates. X.509v3 certificates will be used when discussing PKI examples throughout the remainder of this chapter.

PKI Components

395

The public key certificate is generated by the certificate authority (CA). In order for the CA to generate the public key certificate for the corresponding cryptographic endpoint, the endpoint must first enroll with the CA. The process of enrollment includes registration, initialization, and certification of the cryptographic endpoint with nodes in the PKI, such as registration authorities (RAs) and CAs. We will use the following list to explore the process of enrollment within a PKI: 1.

The cryptographic endpoint registers with the CA or RA. During this process, the cryptographic endpoint makes its identity known to the certificate cuthority. The certificate cuthority will authenticate the cryptographic endpoint, issuing its public key to the cryptographic endpoint pending the success of that authentication.

2.

The cryptographic endpoint begins the initialization phase by generating a public/private keypair (if it has not already done so). The public key of that keypair is forwarded to the certificate authority.

3.

The CA signs the public key certificate with its private key to create a public key certificate for the cryptographic endpoint.

NOTE In public key cryptography, the private key is normally used for decryption, and the public key is normally used for encryption. When applying a digital signature, the opposite is true—private keys are used for encryption and public keys are used for decryption.

4.

Cryptographic endpoints can now request the public key certificate from the cryptographic endpoint described above. They can use the CAs public key (obtained in Step 1) to decrypt the public key certificate to obtain the appropriate public key.

Registration Authorities In many instances, the CA in a PKI will provide all of the PKI services needed to manage the public keys within the network. However, there are instances in which a CA may delegate tasks to one or more registration ruthorities (RA). The primary task that a CA may delegate to an RA is the verification and validation of the identity of the cryptographic endpoint that is attempting to use the PKI. There are, however, other functions that a CA may also delegate to an RA, including the following: ■

Verification that a cryptographic endpoint attempting to enroll a public key with the CA also has the appropriate private key that is to be used in conjunction with the public key (proof of possession)

■

Generation of the public/private keypairs to be used in the initialization phase of the enrollment process

396

Chapter 11: Public Key Infrastructure and IPsec VPNs

NOTE Cisco cryptographic endpoints support the RSA signature method for PKI. In this process, the RSA keypair is generated locally on the cryptographic endpoint, after which the endpoint attempts to enroll the public key with the CA. ■

Validation of public key parameters

■

Indirect issuance of Certificate Revocation Lists (CRL)

Although the RA is capable of offloading many critical PKI functions from the CA, an RA can only compliment a CA—it can never replace it. The CA is the central focus of a PKI, and it is the only device in the PKI that is capable of signing public key certificates from cryptographic endpoints.

Certificate Revocation Lists and CRL Issuers CRLs exist to tell cryptographic endpoints which public key certificates are no longer valid within a PKI. This function is critical to maintaining the integrity of the PKI, especially as it pertains to the freshness of the public keys used by cryptographic endpoints. Public keys that are renewed or expire periodically provide an additional measure of security to the PKI, since they give attackers less time to compromise a public key and deploy it maliciously. Public key certificates can be rendered invalid for a variety of different reasons. For example, an administrator can manually instruct a CA to revoke a public key certificate, or a certificate could be rendered invalid before the expiry of the timeout field within the certificate itself. TIP ITU-T X.509v3-compliant certificates must include a field called “validity period.” This field specifies the time range in which the certificate is considered valid. It is critical that the network time settings on the routers, CAs, and RAs are synchronized such that the validity period is accurately populated within the PKI’s public key certificates. Otherwise, problems relating to PKI usage could arise. The format of an X.509v3-formatted certificate is illustrated in Figure 11-2 later in this chapter.

CAs normally maintain the CRL in a PKI. The maintenance and issuance of the CRL, however, can be delegated to another entity within the PKI, such as an RA. Once issued to a cryptographic endpoint, the CRL is stored locally on that endpoint. The endpoint can then make the appropriate decisions regarding public key certificate usage by cross-referencing the locally stored CRL. TIP CRLs can grow to be quite large, which presents a problem on cryptographic endpoints that are memory constrained. OCSP was developed to help mitigate this issue on memoryconstrained devices. OCSP is covered in further detail later in this chapter.

Life of a Public Key Certificate

397

Certificate Authorities A CA represents the central resource of trust in a PKI. This is because the CA is the only element within the PKI that can issue public key certificates to cryptographic endpoints. A PKI does not have to have only one CA. PKIs can set up CAs redundantly or in a hierarchy of trust, in which multiple CAs are branched off of a trusted root CA. These two PKI topologies are illustrated in case studies at the end of this chapter. CAs are also usually responsible for maintaining the CRL and typically serve as the CRL Issuer. Although a CA may delegate CRL issuance or one of many more responsibilities to one or more RAs, the CA can assume responsibility for all of these functions such that an RA is not needed; the CA is capable of performing all of the tasks that we have discussed previously.

PKI Cryptographic Endpoints PKI was designed to scale asymmetric key encryption networks to include a variety of different cryptographic endpoints. As such, not only will network nodes oftentimes serve as cryptographic endpoints in a PKI, but workstations, applications, and other devices that live on the periphery of an IP network will also subscribe to the PKI. Therefore, a PKI cryptographic endpoint can be any host, server, network element, or peripheral device that wants to talk to another IP-enabled PKI cryptographic endpoint. Of course, these cryptographic endpoints must all be enrolled with the CA of the PKI, and they must also be able to obtain public key certificates for the PKI cryptographic endpoints that they want to encrypt data towards. We will now explore the process that cryptographic endpoints follow when setting up encrypted communications between one another in a PKI, by stepping through the life of a certificate.

Life of a Public Key Certificate The life of a public key certificate in a PKI depends largely on the implementation and design of the PKI itself. For example, the life of a certificate would change if one were to offload PKI functionality from a CA to a series of RAs. Likewise, the life of a certificate would change if one were to deploy a hierarchy of CAs, as opposed to using a single CA. However, the high-level process of creating and obtaining public key certificates is fairly consistent. Implementationspecific considerations are covered later in the chapter, but to fully appreciate them, we must first understand the general process of creating and obtaining public key certificates.

RSA Signatures and X.509v3 Certificates RSA signatures are a form of Digital Signature, the operation of which is described previously in this chapter and in Chapter 2, “IPsec Fundamentals.” RSA signatures combine the strength of a

398

Chapter 11: Public Key Infrastructure and IPsec VPNs

standard digital signature with the strength of the RSA encryption algorithm, also described above, to yield an RSA signature. Crypto-enabled network devices oftentimes will use RSA signatures when exchanging X.509-based certificates with a X.509 compliant certificate authority. Note that, unlike Internet Security Association and Key Management Protocol (ISAKMP) authentication designs that use preshared keys, the RSA signatures authentication method uses an RSA keypair. ITU-T X.509 certificates and certificate authorities were developed to aid administrative burden in asymmetric cryptographic deployments through leveraging a central point of administration, or a trustpoint, for cryptographic endpoints to register their public keys and to obtain the public keys of their peers. Such a trustpoint is commonly referred to as a certificate authority. In order to effectively exchange this information, the certificate authority must communicate certificates in a standard format that is agreed upon with by its peers. ITU-T X.509-formatted certificates are commonly accepted as the standard for this type of public key cryptosystem. Figure 11-2 illustrates the format of an X.509-formatted certificate. Figure 11-2

An ITU-T X.509 Certificate VERSION NUMBER SERIAL NUMBER ISSUER SUBJECT X.509 Cert: Charlie RSA Pub Charlie (E = 3, M = 33)

SUBJECT’S PUBLIC KEY (ALGORITHM, KEY) VALIDITY PERIOD (NOT BEFORE, NOT AFTER) OPTIONAL EXTENSIONS SIGNATURE ALGORITHM SIGNATURE

Certificate authorities allow network administrators to effectively manage large-scale crypto deployments by concentrating the administration of public key distribution into a single source. In doing so, administrators can be assured that keys are exchanged with authentic sources and destinations.

Life of a Public Key Certificate

Figure 11-3

Certificate Enrollment Procedure Using RSA Signatures and X.509 Certificates CA Certificate and Key Database X.509 Cert: James RSA Pub James (E = 11, M = 15)

X.509 Cert: Charlie RSA Pub Charlie (E = 3, M = 33)

4

4 5

SIGN

3

RSA Private CA (E = 5, M = 35)

James’ Certificate and Key Database X.509 Cert: James RSA Pub James (E = 11, M = 15)

Charlie’s Certificate and Key Database

RSA Public CA (D = 11)

2

1

5

SIGN

3

RSA Public CA (D = 11)

2

X.509 Cert: Charlie RSA Pub Charlie (E = 3, M = 33)

1

RSA Public CA (D = 11)

Certificate Authority 1

1 5

RSA Public James (E = 11, M = 15)

X.509 Cert: James RSA Pub James (E = 11, M = 15)

RSA Pub Charlie (E = 3, M = 33)

X.509 Cert: Charlie RSA Pub Charlie (E = 3, M = 33) 6

6

James VERIFY

Charlie DECRYPT

RSA Private James (D = 3) RSA Pub Charlie (E = 3, M = 33)

7

ENCRYPT

VERIFY

DECRYPT

RSA Private Charlie (D = 7)

7

7 7

ENCRYPT

RSA Public James (E = 11, M = 15)

399

400

Chapter 11: Public Key Infrastructure and IPsec VPNs

NOTE The use of CA-based PKI does not enhance the level of confidentiality exchanged in an asymmetric key crypto deployment. It does, however, enforce data authentication in a fashion that allows for enhanced scalability in the number of encrypting/decrypting peers. The following sequence illustrates the process of two endpoints, James and Charlie, communicating with one another using the RSA-signatures method of IKE authentication, as illustrated in Figure 11-3: 1.

James and Charlie request the CA’s certificate. They optionally confirm the authenticity of the CA by verifying its fingerprint (manually) and install the CA’s certificate, including its public (decryption) key.

2.

James and Charlie enroll with the CA upon completion of Step 2. During this process, they forward their public RSA key to the CA.

3.

When James and Charlie enroll with the CA, their public keys are received by the CA, then digitally signed with the CA’s private key, as shown in Figure 11-4, resulting in a public key certificate for both James and Charlie.

Figure 11-4

CA Signs the X.509 Certificate X.509 Cert: Charlie RSA Pub Charlie (E = 3, M = 33)

Hash: MD5

SIGN Hash Value: Fsd$#ˆ@43#@Ad5J$

RSA Private CA (E = 5, M = 35)

Cipher: RSA

RSA Signature 4$h5*&FsW@4ˆ%T&ˆi*f

Life of a Public Key Certificate

401

4.

The CA forwards the James and Charlie their CA-signed public key certificates, which are stored locally on both James and Charlie for future ISAKMP Phase I exchanges with other endpoints in the PKI that use the RSA-signatures method of authentication.

5.

When James and Charlie want to initiate ISAKMP Phase I negotiation with one another, they forward their CA-signed RSA public key certificates to one another.

6.

James and Charlie then use the CA Public Key (obtained in Step 1), to verify the CA’s digital signature (computed in Step 2) on the public key certificates they receive from one another in Step 5. This is displayed in Figure 11-5. If the CA’s certificate is verified successfully, then James and Charlie can be assured that the public keys were obtained from authentic sources and that their integrity has been preserved.

Figure 11-5

Verification of the CA-Signed Certificate Certificate Authority

Certificate and signature are sent from CA. Signature separated from certificate before verification is initiated.

RSA Signature 4$h5*&FsW@4ˆ%T&ˆi*f

X.509 Cert: Charlie RSA Pub Charlie (E = 3, M = 33)

Cipher: RSA

Hash: MD5

VERIFY RSA Public CA (D = 11) Hash Value:

Hash Value:

Fsd$#ˆ@43#@Ad5J$

Fsd$#ˆ@43#@Ad5J$

Message-digests match-certificate is authentic!

7.

James and Charlie can now use each other’s public keys to encrypt communications between each other. Note that James and Charlie’s private keys have been kept private throughout this exchange, ensuring confidentiality between the parties.

402

Chapter 11: Public Key Infrastructure and IPsec VPNs

NOTE Encryption with RSA signatures is only used for IKE. A Diffie-Hellman shared secret key is negotiated over the IKE channel encrypted with the RSA signatures. The IPSec SA then uses the Diffie-Hellman shared secret key to encrypt data between the two endpoints. Because only authentic endpoints have the CA public key, all of the authentic endpoints receiving a CA-signed public key certificate can be assured that the enclosed public key is authentic if the CA’s signature is successfully validated. Additionally, only authentic cryptographic endpoints, such as James and Charlie in this case, can use their private keys to decrypt communications between one another. In the preceding exchange, James and Charlie will enroll using Simple Certificate Enrollment Protocol (SCEP) as defined by the X.509 standard. The transport used to distribute certificates in the exchange described above using a client/server application such as HTTP, FTP, or LDAP. Cisco Systems manufactures a full set of network devices and appliances that utilize X.509-based PKI cryptosystems that leverage protocols such as HTTP for certificate transport, including firewalls, intrusion detection systems, routers, switches, and VPN concentrators.

Generating Asymmetric Keypairs on Cryptographic Endpoints The main component of a public key certificate is the public key itself. Because of this, cryptographic endpoints must generate asymmetric keys, which would include the public key, before a public key certificate can be created. As we have discussed before, the effectiveness of a public key cryptosystem depends on the difficulty of deriving a private key from a compromised public key. Therefore, the effectiveness of a public key cryptosystem is directly related to the strength, or modulus, of the asymmetric keypair itself. Most Cisco devices will support RSA keys modulus sizes between 512 and 2048. The stronger the keys, the harder it is to compromise the keypair. The tradeoff in selecting a large key modulus is that they consume more computational resources when ciphering messages. Additionally, a larger key modulus consumes more computational resources during the generation of the keys themselves.

Registration and Endpoint Authentication The life of a public key certificate begins when a cryptographic endpoint registers with the PKI. On Cisco devices, this process is initiated when the device is configured with the CA IP and certificate path. When a device attempts to enroll with the CA, an optional step can be executed to verify the authenticity of the cryptographic endpoint before it is registered with the PKI. Authenticating cryptographic endpoints during the registration phase can be bypassed on certain CA implementations. For example, a Microsoft Windows 2000 server running Certificate Services

Life of a Public Key Certificate

403

can be configured to automatically issue the CA certificate to the cryptographic endpoint without authentication. Alternatively, Windows 2000 Server can also be configured to wait until the CA administrator manually examines the request from the endpoint and instructs the CA to issue its certificate to the cryptographic endpoint.

Receipt and Authentication of the CA’s Certificate Once an endpoint has registered with the CA, the CA forwards its certificate, containing its public key, to the cryptographic endpoint. This step is critical to the endpoint’s ability to verify the CA’s signature when receiving public key certificates from other cryptographic endpoints, since the CA’s certificate contains the public key that corresponds to the private signing key. When the CA forwards its certificate to the endpoint, a step of authenticating the CA is typically executed. The CA’s certificate has a unique fingerprint that can be checked for authenticity. Alternatively, this authentication step can be skipped if such authentication is not needed.

Forwarding and Signing of Public Keys Once the CA and cryptographic endpoints have established a relationship of trust with one another, the cryptographic endpoint forwards its public key to the CA to be stored for other cryptographic endpoints to use. Before the CA forwards this public key to anybody, it signs it. To do this, the CA hashes the public key with a one-way hash algorithm, such as SHA-1 or MD-5. The message digest of that hash is then encrypted with the CA’s private key. Only those endpoints that have authenticated the CA (and, as a result, also have the CA public key) can decrypt the message digest and verify it. NOTE Cisco cryptographic endpoints support the RSA-signatures method of authentication in ISAKMP. The DSS-1 standard for signature formatting and creation is followed in this process.

As you may recognize, this is the same process of creating a digital signature, which we explored in Chapter 2, “IPsec Fundamentals.” The digital signature that the CA places on stored public keys is the very cornerstone of trust in a PKI.

Obtaining and Using Public Key Certificates Once a cryptographic endpoint has enrolled with the CA, it can now verify the public key certificates of cryptographic endpoints that are enrolled with the CA. Because the cryptographic endpoint has already obtained the CA’s certificate and public key, it can verify the CA’s signature on the public key certificates of other cryptographic endpoints that it wants to encrypt data towards.

404

Chapter 11: Public Key Infrastructure and IPsec VPNs

NOTE During the whole process of creating and obtaining public key certificates, the cryptographic endpoints’ private keys are never shared with anybody else, including the CA. This process ensures that only the cryptographic endpoint that originated the public/private keypair can decrypt data that was encrypted with its public key.

PKI and the IPSec Protocol Suite—Where PKI Fits into the IPSec model You may remember from our discussions of cryptographic components that asymmetric key encryption, while stronger than symmetric key encryption, is more computationally intensive than symmetric key encryption. Exactly how much more resources does asymmetric key encryption consume than symmetric key encryption? If the algorithms are executed in software, asymmetric key encryption is believed to be 1000 times slower than symmetric key encryption. If the algorithm is executed in hardware, this number decreases to a multiple of 100. Regardless, these numbers highlight the need for a cryptographic scheme that is more suited to bulk data transfer, a critical component of IPSec implementations. For these reasons, IPSec specifies the RSA-signature method for PKI compatibility for ISAKMP authentication only—symmetric key encryption is much better suited for bulk transfer of encrypted data. As such, IPSec specifies a symmetric key method for encrypted data transfer over the IPSec SA (i.e., DES, 3DES, AES). Diffie-Hellman session keys are derived for symmetric encryption of the IKE channel and for use with symmetric key ciphers in the IPSec SA itself. Using RSA signatures provides a strong and highly scalable method for authentication during the establishment of ISAKMP SAs. This limits the impact on CPU burden to ISAKMP SA negotiation only, which allows data encryption at the IPSec layer to be encrypted effectively and efficiently.

OCSP and CRL Scalability One design consideration that has received a lot of attention over the years in the PKI world is scalability surrounding CRLs. As we have discussed, CRLs were born of the need to tell cryptographic endpoints which public key certificates that they are using have expired or have been revoked by the CA or CA administrator. We have further discussed that CRLs are periodically issued to cryptographic endpoints by CRL issuers, and stored locally on the cryptographic endpoint itself. This presents problems on memory-constrained endpoints like workstations and network nodes. This problem begins to penetrate all areas of the PKI design as the size of the CRL grows and higher-end cryptographic devices are now struggling to accommodate the storage of the large CRL. The IETF’s PKIX working group has drafted proposals and RFCs for several alternative methods that would eliminate the need to store the CRL locally on the cryptographic endpoint itself. One of most widely used protocols is the Online Certificate Status Protocol.

Case Studies and Sample Configurations

405

TIP PKIX has defined many protocols to address PKI scalability issues surrounding CRL storage and other design topics. For more information on the PKIX and its initiatives you can view their charter at http://www.ietf.org/html.charters/pkix-charter.html.

OCSP OCSP was developed to provide routers with the ability to check for revoked certificates quicker and more frequently than they could when following the standard CRL-checking format. In an OCSP arrangement, cryptographic endpoints act as OCSP clients, and the CRL issuer typically acts as the OCSP responder. The client gets CRL information from the OCSP responder through the following exchange: 1.

The OCSP client receives a certificate from another peer.

2.

The OCSP client sends an OCSP request to the OCSP server for the validity of the certificate that it just received.

3.

The OCSP server checks the signature within the OSCP request to see if the OCSP request is well formed and that it contains the information it needs to formulate a response.

4.

The OCSP server crafts an OCSP response message containing one of three messages: • Good • Revoked • Unknown

5.

The OCSP responder digitally signs the response and forwards it to the OCSP client.

6.

The OCSP client receives the OCSP response message, and verifies the digital signature.

7.

The OCSP client uses the OCSP response message to determine the validity of the certificate received in Step 1.

NOTE Cisco IOS allocates 64k of memory for CRL processing. This is adequate for the majority of CRL sizes. However, for abnormally large CRLs, alternatives to standard CRL checking, such as OCSP, must be explored. The preceding exchange provides a scalable alternative to periodically downloading the full CRL from a CRL issuer. OCSP messages are ensured to be authentic and with integrity, since the CRL issuer digitally signs all OCSP responses.

Case Studies and Sample Configurations The following case studies represent a scaled-down version of an enterprise network. In real topologies, much more redundancy would be built into the network topology. However, for clarity

406

Chapter 11: Public Key Infrastructure and IPsec VPNs

and conciseness, the topology has been reduced to the critical network elements themselves. The network core consists of Catalyst 6500s, which branch off distribution switches at the company’s east and west campuses. The distribution layer switches in this case are represented by the Catalyst 4507Rs at each campus. A 7200VXR router serves as the headend for the company’s branch locations. Frame relay circuits extend the network to each branch, represented with a 3745 router. The topology described above is illustrated in Figure 11-6. Figure 11-6

Case Study PKI Topology

WEST CAMPUS

EAST CAMPUS

IOS-CA3

IOS-CAROOT .2 .1

AN

.11

_C

.0

A3

/2

4

IOS-CA1 .2

OT RO CA _ 24 AN .0/ 12 VL .1. 10

VL

10

VLAN_CA1 200.2.1.0/24

.1

.1

.1

.1

.2 VLAN_VPN 200.3.1.0/24

IOS-CA2

VLAN_CA2

.2

200.2.2.0/24

C4507R-EAST

C4507R-WEST .6

.10

C6509-CORE VLAN_WEST

VLAN_EAST

.5

200.0.0.8/24

.9

VLAN_W

.1 200.0.0.0/30

200.0.0.4/32

.2

7206VXR-MAIN

.1

102 201

103

104

Frame Relay

401 200

.1.1

2

.1.0/3

200.1

.9

301

3745-A Loopback 1 = 172.16.1.1/24 .6

200.1.1.4/32

.2

.5

.8/3

0

.10

3745-C Loopback 1 = 172.16.2.1/24

3745-B Loopback 1 = 172.16.2.1/24

Critical resources are located at the company’s east campus. Transmissions from these resources across the WAN to the branch offices must be kept confidential. Security administrators have selected asymmetric encryption as the method used to authenticate the IKE channels. As such, a

Case Studies and Sample Configurations

407

PKI-based implementation has been chosen to encrypt data from the company’s east campus to resources at the branch locations. This series of case studies will demonstrate various PKI deployments in the company’s west campus that are used to deliver these services.

Case Study 1: PKI Integration of Cryptographic Endpoints In the first case study, we will illustrate the basic enrollment and authentication processes of the cryptographic endpoints within the PKI. In this case, the cryptographic endpoints are represented by the frame-relay head-end (7206VXR) and its spokes (3745s). The CA for this case study is running on Cisco IOS 12.3.8T4 and is configured as displayed in Example 11-1. Example 11-1

Cisco IOS CA base configuration

crypto pki serve r IOS_CA1 g rant auto ! cryp to pki trus tpoi nt IOS_CA1 revoc ation- che ck crl rsakeypa ir IOS_C A1 ! crypto pki certifi cate chain IOS _CA1 certif icate ca 01 308201FD 3 0820166 A0 030201 02020101 300D 0609 2A864886 F7 0D0101 04050 030 12311030 0E060355 0 40314 07 49 4F535F 434131 30 1E17 0D30 343132 30 36313234 35 32305A 170 D3037 31323 036 3 132 3435 32305A30 12311030 0E06035 5 04031407 494F53 5F 4341313 0 819F300D 0609 2A 86 4886F70D 01010105 000 3818D 00308189 02818100 C 3AB99C2 CE7E000D CB 59AA96 C D5815EF 60ADA B83 DE6B67 B5 356BC735 7 F518745 EF 92A C71 B BCA8CB5 DFCD 8B63 DB0 5BDC9 194D16 65 181283E5 6 31C 9875 F782 1CCA 27179 00D EF7 3BD7A 0D86C2 B7 73170DB 4 41C66C 66 BBD25C19 2 801D 22E 2AC7E 22E 710B6B C9 184 803B E 9D5D3238 FC 704842 E 4728A05 943B7AEB AF 76F4B1 7E638C BD 02030100 01A3633 0 61300F06 035 51D13 0101F F04 053 00301 01FF300 E 060 3551D 0 F0101FF 040 40302 01 86301D 0603 551D 0E041604 1417 7FC9 2F8DE64D F61B73 0D 873B6 7BF 13A7E05 B 70301 F06 03551D2 3 04183016 8 01 41 77F C92F8DE6 4DF61B73 0D 873B 67 BF13A7E0 5B70300D 06092A86 4 886F70D 0101 040 5 00038181 004940A8 5E4ED5 BB 3DF84643 A B77E505 A8A9 6E9B 1D6 21471 56ADC25 B 7F BA3CEB E B755322 BB3 A50A1 8 B3B567D 4F4 B667D B84D986 0 F75 19B70 EF2529E 7 8B3F1E C7 90 880D87 8439 4162 B31D D 74F 0F2E4532 8E4EF645 15 766 A62 546CD102 BD670F6B 0 34FD CC6 040F90E F C68DDF1B 8A86354B 4 8289102 01700 B 77 C DB416A7 58605 FDE CF

Once the CA has been configured, the crypto endpoints must generate RSA keys for creating digital signatures, as shown when the Frame Relay headend 7206VXR enrolls with the PKI. These public RSA keys will be used to encrypt communications through the IKE channel, and the private keys will be used for decrypting communications through the IKE channel. Note that stronger keys are selected for stronger security than the default key modulus (512). Example 11-2 illustrates the process of generating an RSA keypair with Cisco IOS.

408

Chapter 11: Public Key Infrastructure and IPsec VPNs

Example 11-2

Generating RSA Keys for Use with RSA Signatures

crypto key genera te rsa 7206VXR-MAIN(config)#c The name for the keys will be: 7206VXR-MAIN.cisco.com Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus [512]: 1024 % Generating 1024 bit RSA keys ...[OK] e xit 7206VXR-MAIN(config)#e sh cry pto key my pubkey rsa 7206VXR-MAIN#s % Key pair was generated at: 11:08:26 PST Dec 6 2004 Key name: 7206VXR-MAIN.cisco.com Usage: General Purpose Key Key is not exportable. Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00F4F069 29F731C7 3A6A78AC FC28201F 4B278BEB 348C6450 C9B88510 1AC5948B 36C2DB4A 6C85C1E8 C689B5CD 841F60FA 53264AB2 AFBD8E3E 62235BD0 F48208E9 042B43E6 60F01AD0 B7F870C2 224FF2E5 7288E6CA 47BFDF36 E0D882B1 6B8FAA28 775CBE4B 13B83E11 090F731D D5640280 4EBEF7EE C5EF1ED7 B56A5E09 603377E2 DD020301 0001 % Key pair was generated at: 11:08:26 PST Dec 6 2004 Key name: 7206VXR-MAIN.cisco.com.server Usage: Encryption Key Key is exportable. Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00D6CD85 1A603369 F8598785 E0F3003C 81874E3A F10BC0FB 5401D977 CA445C6B C9EA191D C08AEFED 9A511972 7BD4B303 C748A7EC 3A6DB4BD 8B6193A9 6FA80D2F CC32E35D E7E4CE1C 74F4493F 6C9DF20F B26B1FFB A52BAD30 5D88B725 6EFF4CE1 71020301 0001

Once RSA keys have been created, the CA must be specified and authenticated. Example 11-3 shows the specification of a CA trustpoint on the 7206VXR. When authenticating a CA, the CA will provide the administrator with a unique fingerprint. The administrator must manually accept this fingerprint for the CA to be authenticated on the router. Example 11-3

Authenticating the CA with Cisco IOS

conf t 7206VXR-MAIN#c Enter configuration commands, one per line.

End with CNTL/Z.

crypto ca trustpo int IOS_C A1 7206VXR-MAIN(config)#c enroll ment url http ://200. 2.1.2 7206VXR-MAIN(ca-trustpoint)#e exi t 7206VXR-MAIN(ca-trustpoint)#e crypto ca authent icate IOS _ CA1 7206VXR-MAIN(config)#c Certificate has the following attributes:

Case Studies and Sample Configurations

Example 11-3

409

Authenticating the CA with Cisco IOS (Continued)

Fingerprint: 99282341 BE16A9D0 DE8614E4 A3557E48 % Do you accept this certificate? [yes/no]: yes Trustpoint CA certificate accepted. 7206VXR-MAIN(config)#

The 7206VXR has now authenticated the CA. Next, the 7206VXR must be enrolled with the CA for other endpoints to verify its validity in the PKI. Example 11-4 shows this enrollment process. The router prompts the administrator for a password that is used for revoking certificates if needed. Example 11-4

Enrolling a Cryptographic Endpoint in a PKI

crypto ca enroll IO S_CA1 7206VXR-MAIN(config)#c % % Start certificate enrollment .. % Create a challenge password. You will need to verbally provide this password to the CA Administrator in order to revoke your certificate. For security reasons your password will not be saved in the configuration. Please make a note of it. Password: Re-enter password: % The fully-qualified domain name in the certificate will be: 7206VXR-MAIN.cisco.com % The subject name in the certificate will be: 7206VXR-MAIN.cisco.com % Include the router serial number in the subject name? [yes/no]: no % Include an IP address in the subject name? [no]: Request certificate from CA? [yes/no]: yes % Certificate request sent to Certificate Authority % The certificate request fingerprint will be displayed. % The 'show crypto ca certificate' command will also show the fingerprint. CRYPTO_PKI:

Fingerprint:

56FB7367 20C98A75 82B96CE9 46C4D1F6

Dec

6 16:22:56.486:

Dec

6 16:23:07.717: %CRYPTO-6-CERTRET: Certificate received from

Certificate Authority

As a result of the enrollment process, the 7206VXR receives its own certificate signed by the CA. When 3745-A, B, and C enroll with the PKI through this same process, they will also receive their own CA-signed certificates. The spokes will then be able to exchange their certificates successfully with the 7206VXR to authenticate the IKE channel. Over this channel, an IPSec SA will be built and encrypted communications will be enabled between the spokes and the West Campus LAN.

410

Chapter 11: Public Key Infrastructure and IPsec VPNs

Case Study 2: PKI with CA and RA In this scenario, another Cisco IOS-based CA has been added—IOS_CA2. However, IOS_CA2 is acting strictly as a registration authority; it is not actually signing certificates for the crypto endpoints. Instead, IOS_CA2 offloads registration responsibility for IOS_CA1, which retains sole responsibility for enrolling and signing router certificates. In order to ensure that the CA is only granting certificates to those cryptographic endpoints which have already been processed by the registration authority, the configuration of IOS_CA1 is changed, as shown in Example 11-5, to automatically grant requests only if a trusted registration authority has previously processed them. Example 11-5

CA Configuration for RA Interoperability

config ure termina l IOS_CA1#c IOS_CA1(config)# crypto pki server IOS_CA1 IOS_CA1(cs-server)#c grant ra-auto IOS_CA1(cs-server)#g end IOS_CA1(cs-server)#e

The RA configuration looks similar to the configuration of a CA in Cisco IOS. The main difference is that RA mode must be selected under the CA server configuration. Additionally, the RA must be configured with a CA as its trustpoint, which is IOS_CA1 in this case. As such, IOS_CA2 will authenticate IOS_CA1 and enroll with IOS_CA1 in the same manner that a normal cryptographic endpoint would. IOS_CA2 must also be configured with its certificate name, along with other parameters for enrolling with the CA. Configuration of IOS_CA2 is displayed in Example 11-6. Example 11-6

RA Configuration for CA Interoperability

config ure termina l IOS-CA2#c crypto pki serve r IOS_RA1 IOS-CA2(config)#c grant auto IOS-CA2(cs-server)#g mode r a IOS-CA2(cs-server)#m no shu t IOS-CA2(cs-server)#n % Once you start the server, you can no longer change some of % the configuration. Are you sure you want to do this? [yes/no]: yes Error: There is an enrollment transaction in progress. Please wait or abort the current enrollment before starting a new enrollment transaction. % Enrollment in progress... % You have to re-enable the certificate server after the enrollment succeeds. ! ex it IOS-CA2(cs-server)#e crypto pki trust point IOS _RA1 IOS-CA2(config)#c enroll ment url htt p://200. 2.1.2:80 IOS-CA2(ca-trustpoint)#e serial -number IOS-RA2(ca-trustpoint)#s ip-add ress FastEth ernet0/1 IOS-CA2(ca-trustpoint)#i subjec t-name cn=IO S_RA1, o u =ioscs RA, o= cisco, c=us IOS-CA2(ca-trustpoint)#s

Case Studies and Sample Configurations

Example 11-6

411

RA Configuration for CA Interoperability (Continued)

revoca tion-check cr l IOS-CA2(ca-trustpoint)#r rsakey pair IOS_RA1 IOS-CA2(ca-trustpoint)#r end IOS-CA2(ca-trustpoint)#e

NOTE In Example 11-6, the enrollment URL points to an HTTP server enabled on the IOSbased CA Server, IOS-CA1. The IOS CA will store information requests from the RA, which must be manually granted. Example 11-7 shows the process of displaying requests from RA’s on IOS_CA1 and manually accepting them. Example 11-7

Managing RA Information Requests on IOS CAs

crypto pki server IOS_CA1 info reque sts IOS-CA1#c Enrollment Request Database: RA certificate requests: ReqID

State

Fingerprint

SubjectName

-------------------------------------------------------------14

pending

230B8A39AC85E0512A5D01EC1796D2C8

serialNumber=7F6AD0E2+ipaddress=200.2.2.2+hostname=IOS-RA1.cisco.com, cn=IOS_RA1,ou=ioscs RA,o=cisco,c=us Router certificates requests: ReqID

State

Fingerprint

SubjectName

crypto pki server IOS_CA1 ? IOS-CA1#c grant

Grant enrollment requests

info

Display info

password

One Time Password for SCEP enrollment

reject

Reject enrollment requests

request

Retrieve an enrollment request

revoke

Revoke certificate

crypto pki server IOS_CA1 grant 14 IOS-CA1#c

Note that in Example 11-6, once the RA, IOS_CA2, has authenticated and enrolled with CA, IOS_CA1, the RA server on IOS_CA2 shuts down. It will remain disabled until it is manually enrolled by the administrator on IOS_CA1, as shown in Example 11-8. Example 11-8

Re-Enabling the IOS Server on an RA

config ure termina l IOS-CA2#c crypto pki server IOS_RA1 IOS-CA2(config)#c no shu t IOS-CA2(cs-server)#n % Once you start the server, you can no longer change some of

continues

412

Chapter 11: Public Key Infrastructure and IPsec VPNs

Example 11-8

Re-Enabling the IOS Server on an RA (Continued)

% the configuration. Are you sure you want to do this? [yes/no]: yes % Certificate Server enabled. end IOS-CA2(cs-server)#e

Now that the RA has been fully enrolled with the CA, cryptographic endpoints must be configured to subscribe to the PKI with the RA (IOS_CA2). The cryptographic endpoints will subscribe to the PKI using the same procedure outlined in Case Study 1, with the exception of using IOS_CA2 as their trustpoint instead of IOS_CA1. Additionally, the endpoints must be told that they are using an RA instead of a CA for subscribing to the PKI. Otherwise, the interaction between the RA and CA will be transparent to the cryptographic endpoints. Example 11-9 shows the configuration of the IOS CA server (IOS-CA2 in Figure 11-6) to act as an RA. Example 11-9

Cryptographic Endpoint Enrollment with an RA

IOS-CA2# crypto pki trust point IOS_ RA1 IOS-CA2(config)#c enroll ment url htt p://200. 2.1.2:80 IOS-CA2(ca-trustpoint)#e !# enroll ment mode ra IOS-CA2(ca-trustpoint)#e

Case Study 3: PKI with Redundant CAs (CA Hierarchy) A third CA running on Cisco IOS has now been added to the topology. This CA will serve as the root CA in the PKI CA hierarchy. IOS_CA2 is now configured as a full CA server that subscribes to the root CA. As such, there are now two CA servers running on Cisco IOS that are subscribed to the root CA. NOTE Traditionally, PKIs have only accommodated two tiers in their hierarchies—the root CA comprises the first tier, and all other CAs in the second tier must subscribe to that tier-1 root CA. Cisco IOS supports multiple tier hierarchies for additional PKI scalability in later versions of 12.2T.

The two IOS-based CAs are configured to subscribe to the root CA as shown in Example 11-10 and Example 11-11. Example 11-10

IOS_CA1 Configuration

#confi gure termi nal IOS-CA1# #crypt o pki serve r IOS_CA1 IOS-CA1(config)# grant auto IOS-CA1(cs-server)#g ex it IOS-CA1(cs-server)#e

Case Studies and Sample Configurations

Example 11-10

413

IOS_CA1 Configuration (Continued)

crypto pki trustpo int IOS_ CA1 IOS-CA1(config)#c enroll ment url http ://10.1 .12.100:80 IOS-CA1(ca-trustpoint)#e revoca tion-check cr l IOS-CA1(ca-trustpoint)#r rsakey pair IOS_CA1 IOS-CA1(ca-trustpoint)#r end IOS-CA1(ca-trustpoint)#e

Example 11-11

IOS_CA2 Configuration

config ure termina l IOS-CA2#c crypto pki server IOS_CA2 IOS-CA2(config)#c grant auto IOS-CA2(cs-server)#g ex it IOS-CA2(cs-server)#e IOS-CA2(config)# crypto pki trustpoi nt IOS_ CA2 IOS-CA2(ca-trustpoint)#c enroll ment url http ://10.1 .12.100:80 IOS-CA2(ca-trustpoint)#e revoca tion-check cr l IOS-CA2(ca-trustpoint)#r rsakey pair IOS_CA2 IOS-CA2(ca-trustpoint)#r end IOS-CA2(ca-trustpoint)#e

NOTE The CAs in Example 11-10 and Example 11-11 are subordinate to the root CA, IOS_CAROOT. Each subordinate CA must download the root CA certificate and authenticate the root CA. Likewise, each subordinate CA is configured to enroll with the root CA (shaded text in Example 11-10 and Example 11-11). The root CA is configured to grant its certificate to the root CA, as shown in Example 11-12. The root CA can therefore use what is commonly referred to as a “self-signed certificate” when IOSCA1 and IOS-CA2 are unavailable, providing another layer of redundancy within the PKI hierarchy. Example 11-12

Root CA Configuration

config ure termina l IOS-CAROOT#c crypto pki server IOS_CARO OT IOS-CAROOT(config)#c grant auto IOS-CAROOT(cs-server)#g exi t IOS-CAROOT(cs-server)#e crypto pki trustpo int IOS_ CAR OOT IOS-CAROOT(config)#c revocat ion-check crl IOS-CAROOT(ca-trustpoint)#r rsakeyp air IOS_CAROO T IOS-CAROOT(ca-trustpoint)#r end IOS-CAROOT(ca-trustpoint)#e

Each cryptographic endpoint will authenticate the root CA and at least one of its subordinate CAs for redundancy. Likewise, each cryptographic endpoint will enroll with the root CA and one of its subordinates. Example 11-13 shows the configuration of redundant trustpoints on one of the

414

Chapter 11: Public Key Infrastructure and IPsec VPNs

Frame Relay spoke routers, 3745-A. Example 11-14 displays the configuration of the Frame Relay head-end 7206VXR. The Frame Relay hub router must authenticate and enroll with all of the CAs in the PKI, since not all of the Frame Relay spokes will have their certificates signed by the same CA. The process of enrollment for the cryptographic endpoints for each CA trustpoint configured is consistent with the procedures discussed in the previous case studies in this chapter. Example 11-13

Frame Relay Spoke (3745) Configuration for PKI Redundancy.

config ure termin al 3745-A#c crypto pki trustp oint IOS_ CAR OOT 3745-A(config)#c enroll ment url ht tp://10.1 .12.100:80 3745-A(ca-trustpoint)#e serial -number 3745-A(ca-trustpoint)#s ip-add ress Serial 0/0 3745-A(ca-trustpoint)#i revoca tion-check crl 3745-A(ca-trustpoint)#r e xit 3745-A(ca-trustpoint)#e crypto pki trustp oint IOS_ CA1 3745-A(config)#c enroll ment url ht tp://200. 2.1.2:80 3745-A(ca-trustpoint)#e serial -number 3745-A(ca-trustpoint)#s ip-add ress Serial 0/0 3745-A(ca-trustpoint)#i revoca tion-check crl 3745-A(ca-trustpoint)#r end 3745-A(ca-trustpoint)#e

Example 11-14

Frame Relay Hub (7206VXR) Configuration for PKI Redundancy

config ure termina l 7206VXR#c crypto ca trustp oint IOS_C AROOT 7206VXR(config)#c enroll ment url htt p://10.1 .12.100:80 7206VXR(ca-trustpoint)#e serial -number 7206VXR(ca-trustpoint)#s ip-add ress FastEth ernet0/1 7206VXR(ca-trustpoint)#i e xit 7206VXR(ca-trustpoint)#e crypto ca trustp oint IOS_C A1 7206VXR(config)#c enroll ment url htt p://200 .2.1.2:80 7206VXR(ca-trustpoint)#e serial -number 7206VXR(ca-trustpoint)#s ip-add ress FastEth ernet0/1 7206VXR(ca-trustpoint)#i e xit 7206VXR(ca-trustpoint)#e crypto ca trustp oint IOS_C A2 7206VXR(config)#c enroll ment url htt p://200. 2.2.2:80 7206VXR(ca-trustpoint)#e serial -number 7206VXR(ca-trustpoint)#s ip-add ress FastEth ernet0/1 7206VXR(ca-trustpoint)#i end 7206VXR(ca-trustpoint)#e

Summary As the scale of enterprise-class IPSec VPN designs increases, so do the design challenges associated with the scalability and management of the overall architecture. In this chapter, we’ve introduced the use of a PKI as a centralized, scalable resource for key management in large-scale IPSec VPN deployments. The PKI lends an additional degree of security to the overall IPSec VPN

Summary

415

architecture using a centralized, trusted resource (the PKI CA) to distribute public key certificates to each IPSec VPN gateway participating in the PKI. At this point, we have discussed how Cisco IPSec VPN gateways using RSA signatures for IKE Authentication authenticate and enroll with the CA of the PKI, obtain their public key certificates, and verify each other’s public key certificates using several different design alternatives including: ■

Standalone CA deployments

■

CA deployments using one or more RAs

■

CA hierarchies using multiple CAs for redundancy

We have also covered the basics for using PKI technology with Cisco IPSec VPN endpoints, and several design alternatives to deploying PKI resources. PKIs should be evaluated as the design option of choice using concepts and design scenarios discussed in this chapter when additional levels of secure, scalable key management are required within their IPSec VPN deployments.

CHAPTER

12

Solutions for Handling Dynamically Addressed Peers There often exist areas of IPSec design that could benefit from more flexible peering options. From this demand arose the creation of solutions to handle dynamically addressed IPSec peers. Although these solutions are used less frequently than the static peering design alternatives that we have discussed in previous chapters, they are commonly deployed when network designers anticipate that they will not know the addresses of certain remote IPSec peers within their greater VPN implementation. Dynamic peering solutions can add value to situations in which the peer of an IPSec VPN is not known in advance or is anticipated to change over time. For Cisco IOS and ASA-based IPSec VPN implementations, dynamic crypto maps were created as the foundation for addressing the need for dynamic peering alternatives. Tunnel Endpoint Discovery (TED) extends the functionality of dynamic crypto maps, enabling the local peer to proactively discover remote IPSec VPN peers, the addresses of which are unknown. This chapter explores the design issues surrounding the two core components of dynamic peering solutions—dynamic crypto maps and TED.

Dynamic Crypto Maps Dynamic crypto maps enable IPSec to negotiate ISAKMP and IPSec Security Associations (SA) that are initiated from remote endpoints, the addresses of which are unknown. Dynamic crypto maps by themselves do not enable a virtual private network (VPN) endpoint to proactively discover remote and unknown IPSec peers and does not enable a VPN endpoint to initiate ISAKMP and IPSec SA negotiation to undiscovered peers. Indeed, traffic that is in the crypto-protected path of a dynamic crypto map without TED will be dropped unless the remote peer has already initiated and negotiated an IPSec tunnel with the IPSec endpoint using that dynamic crypto map. In order to initiate ISAKMP and IPSec SA negotiation with unknown remote peers, dynamic crypto maps must be used in conjunction with TED, which is discussed later in this chapter. With static crypto maps, an IPSec peer is specified statically. This is not the case with dynamic crypto maps. Instead, because the peer is unknown, dynamic crypto maps will respond to ISAKMP and IPSec SA negotiation attempts from an array of previously unknown peers. Because of this, dynamic crypto maps have distinct differences from static crypto maps that change various concepts surrounding IPSec and ISAKMP design, deployment, and

418

Chapter 12: Solutions for Handling Dynamically Addressed Peers

administration. Here are some key components of static IPSec peering designs that can be dynamically discovered and configured by altering the design to use dynamic crypto maps: ■

Dynamic acceptance and configuration of the remote (initiating) peer’s IP address in the negotiated IPSec SA

■

Dynamic acceptance and configuration of the crypto-protected address space in the IPSec SA

NOTE In remote access VPN deployments, dynamic crypto maps are commonly used to facilitate additional dynamic functionality, such as the dynamic assignment of VPN client IP addresses, DNS/WINS servers, and IP domain names using IKE Mode Config. These scenarios are discussed in greater detail in Chapter 9, “Solutions for Remote Access VPN High Availability.”

With static crypto maps, all of the above items must be manually configured at both the local and remote peers. In a dynamic crypto map solution, only the remote endpoint must be statically configured—the local endpoint can use its dynamic crypto map to retroactively discover the remote peer’s IP address. Indeed, it is this dynamic nature that distinguishes dynamic crypto maps from static ones. We will explore configurations that enable dynamic functionality later in the chapter, but first we will explore the impact that dynamic crypto maps have on the operation of ISAKMP and IPSec.

Dynamic Crypto Map Impact on VPN Behavior Incorporating dynamic crypto maps into an IPSec VPN design can dramatically change the behavior of the VPN. It is therefore important that network administrators understand the way that dynamic crypto maps alter the behavior of the VPN. In the following sections, we will discuss the impact of dynamic crypto map design on ISAKMP SA negotiation and what routing considerations must be addressed in an IPSec VPN deployment using dynamic crypto maps. Then we will discuss security considerations of dynamic crypto maps when compared against static ones, as well as some measures to consider when securing VPN implementations using dynamic crypto maps. Dynamic Crypto Map Impact on ISAKMP/IKE Dynamic crypto maps will dynamically allocate a remote peer to the local IPSec configuration based on information provided by the remote peer itself. Indeed, ISAKMP negotiation cannot begin until a remote peer is defined. Therefore, once a router that uses dynamic crypto maps receives a request to initiate ISAKMP SA negotiation using a matching, locally configured ISAKMP policy, it creates and installs a temporary crypto map entry populated with the initiating endpoint’s peer so that it can then carry on with Phase 1 negotiation. This order of operations is illustrated later in Figure 12-1.

Dynamic Crypto Maps

419

A VPN endpoint that uses dynamic crypto maps must be configured with an ISAKMP policy that matches one proposed by the remote VPN endpoint. This behavior is consistent with static crypto maps with one exception—dynamic crypto maps typically use wildcard preshared keys. The use of wildcard preshared keys allows network administrators to define a key for use with a range of IP addresses, as opposed to just one. This is particularly useful in a dynamic crypto map scenario where there are a varying number of peers whose addresses are unknown. Wildcard preshared keys eliminate the need to know the peer’s exact address during IKE authentication, requirng only that it fall within a specific range. Example 12-1 illustrates a sample IKE configuration using a wildcard preshared key. NOTE The use of wildcard preshared keys leads to difficulties when attempting to evict an endpoint from the IPSec VPN. When the administrative overhead of static preshared keys is a concern, it is recommended that RSA signatures be used instead of wildcard preshared keys. Example 12-1

Wildcard Preshared Keys in ISAKMP Authentication.

!# cry p to is akmp key ex tranet ad dress 192.16 8.0.0 255.255 .0 .0

NOTE For increased security using dynamic crypto maps, IKE Extended Authentication (x-auth) can be used instead of pre-shared keys. IKE x-auth leverages a robust set of authentication and authorization commands in conjunction with centrally maintained TACACS+/RADIUS databases for increased security and scalability.

Routing Considerations with Dynamic Crypto Maps Designs leveraging the functionality of dynamic crypto maps introduce some additional design considerations that network designers must address within their routed infrastructures. The following list provides a brief introduction and explanation of considerations for IPSec VPNs with dynamic crypto maps: ■

IGP Multicast Routing Updates—Dynamic crypto maps allow broader definition of protected traffic sets, since multiple unknown peers can now dynamically negotiate different protected traffic sets with the same dynamic crypto map. However, caution should be exercised against using the any keyword in the dynamic crypto map’s ACL when defining broad scopes of protection, so that multicast routing protocol updates are not encrypted or dropped unnecessarily. As we’ve mentioned previously, traffic in the crypto path using a dynamic crypto map will not initiate IPSec tunnel negotiation; it will instead be dropped. Therefore, defining multicast and broadcast traffic in the crypto path using dynamic crypto maps can oftentimes lead to the discarding of routing updates and loss of RP adjacencies.

420

Chapter 12: Solutions for Handling Dynamically Addressed Peers

When using any keyword on the dynamic crypto map ACL, traffic such as multicast RP updates should be explicitly denied first. ■

Reverse Route Injection (RRI)—RRI is a feature that will dynamically inject routes into the IPSec VPN gateway’s routing table. Effective implementation of RRI allows network administrators to keep the routing table size manageable. With RRI, routes are injected dynamically into the routing table, which can subsequently be redistributed into the enterprise’s IGP for propagation throughout the network. This allows the VPN concentrator or router to inject routes for only those remote networks that have active IPSec VPN connections. This method can be used to efficiently scale the Interior Gateway Protocol (IGP) of an IPSec VPN implementation when used in conjunction with dynamic crypto maps.

Figure 12-1 illustrates an IPSec VPN deployment in which dynamic crypto maps are used in conjunction with RRI. Figure 12-1

Reverse Route Injection and Dynamic Crypto Maps No need for RP adjacency. AS199 has a static to AS1, RRI dynamically injects AS199 routes into AS1.

EIGRP AS#1

EIGRP AS#199 2

5 4 Local Network 200.0.0.0/8

Remote Network 214.1.1.0/32

3

199.1.1.0/24

1

The following is the operation of the IPSec-enabled infrastructure numbered in Figure 12-1: 1.

The remote network attempts to contact a resource on the enterprise network.

2.

The remote VPN endpoint sees the traffic in Step 1, successfully matches it against a crypto ACL, and initiates ISAKMP SA negotiation.

3.

The VPN aggregation point receives the request and finds a locally configured ISAKMP policy to match the ISAKMP proposal that it received in Step 2. The VPN aggregator creates a temporary crypto map entry populated with the remote peer address so that ISAKMP negotiation can continue.

4.

The VPN aggregator on the enterprise network uses a temporary crypto map installed in Step 3 to negotiate Phase 1 and 2 with the remote VPN endpoint.

5.

The VPN aggregator uses RRI to dynamically inject the 199.1.1.0/24 network into the enterprise network. This allows enterprise resources to route traffic over the VPN to the appropriate destination on the remote end of the IPSec VPN tunnel. When the ISAKMP and IPSec SAs for the remote network time out, the routes injected using RRI are allowed to time out.

Dynamic Crypto Maps

421

Security Considerations for Dynamic Crypto Maps As the number of remote peers associated with a dynamic crypto map scales upward, so too escalates the security concerns surrounding the use of wildcard preshared keys. Next, we will discuss two of these concerns, both directly related to key management for dynamically addressed peers, and how to use x-auth during ISAKMP authentication to harden security for dynamically addressed VPN peers. Key Administration and Scalability Multiple wildcard preshared keys can be defined, but the manual configuration involved makes it very difficult for each peer to use its own unique key for IKE authentication, since the number of remote and unknown peers scale upward. Therefore, using wildcard preshared keys for a large number of unknown peers presents a security risk, because many of those unknown peers typically use a common key. Using IKE x-auth in conjunction with a TACACS+ or RADIUS database such as Cisco Secure Access Control Server (ACS) provides a highly scalable, highly available solution for IPSec peers to authenticate with their own unique credentials. The addition of a peer to the group using a common wildcard preshared key for IKE authentication is a simple process—a single configuration of that key on the remote peer. However, removing a peer from that group is more involved and presents security risks. Once a peer is evicted from a group using a common preshared key, that key has become compromised, and must therefore be changed and updated on every remaining peer in the group. For this reason, it is apparent that wildcard preshared keys do not offer the administrative flexibility needed for secure IKE negotiation with dynamically addressed peers. Instead, IKE x-auth should be used so that a peer in the group can be removed without compromising the credentials that the remaining, dynamically addressed peers use for IKE authentication. IKE x-auth offloads Phase 1 authentication and authorization of remote peers to either a locally configured database on the aggregating router or to a centrally maintained database using TACACS+ or RADIUS. Figure 12-2 describes the authentication process used during IKE x-auth. Figure 12-2

ISAKMP Phase 1 Negotiation Using Extended Authentication (x-auth) AAA Server 4 3

5

2 6

Local Network 200.0.0.0/8

Remote Network 199.1.1.0/24

214.1.1.0/32

Local VPN Endpoint

1

Remote VPN Endpoint

422

Chapter 12: Solutions for Handling Dynamically Addressed Peers

The following is a description of the numbered process in Figure 12-2: 1.

The remote peer sends an ISAKMP proposal.

2.

The local peer checks the ISAKMP proposal against its locally configured policies and finds a match; an IKE SA is established with that proposal using preshared keys.

3.

The local peer sends a TACACS+ access-request message to the AAA server.

4.

The AAA server responds with either an access-accept or access-reject message, depending on whether the peer is successfully authenticated or not. In this case, the peer is authenticated by the AAA server and a TACACS+ access-accept message is forwarded back to the local peer.

5.

The local peer installs a temporary crypto map using the IP address peer that sent the ISAKMP proposal in Step 1.

6.

The two peers continue to negotiate IPSec SAs.

In the configuration in Example 12-2, the remote 3745 acts as an EZVPN client, connecting dynamically to the 7304, which in this case acts as the VPN concentrator. The concentrator receives the VPN group credentials and password, and uses the group password as the IKE preshared key. IKE x-auth is configured for additional security and flexibility in group and peer administration. Using x-auth, the concentrator prompts the client for an additional authentication check against its locally configured database. The client authenticates using its locally configured username and password under the appropriate group settings. NOTE IKE x-auth occurs after an IKE SA has been created but before an IPSec SA can be created. IKE x-auth therefore does not replace IKE itself, but rather occurs in addition to it. As such, IKE x-auth negotiation is commonly referred to as Phase 1.5 negotiation. Example 12-2

Configuring IKE X-Auth Using TACACS+ and AAA

AS1-7304A# ! !# ! username as 111 pr ivilege 15 passwor d 0 cis c o111 ! ! # ! aaa a uthenticati on lo gi n vpn-auth local aaa aut horiz ation netwo rk vpn-au th l ocal ! !# cryp to is akmp client configur at ion group ex tranet key cisco acl 111 save-passw o rd ! c rypto dyna mic -map extranet-dy n 10 set tr ansform-set extranet-t rans reverse -route ! !#< --The crypt o map “ex tranet” is instructed to use the AAA model “ vpn-au t h” !for extended au thenti cation and authorization o f IPs ec VPN client s.--> cr y pto map ext ranet clie nt authentic ation list v pn-a uth crypto map extranet i sa kmp authori zation list v p n !# c rypto map e xtrane t 10 ipsec-isa kmp dynamic extra net-dyn ! Inter faces Serial0/0 cryp to map extr a net AS111-3745A# ! !# cryp t o ipsec cli ent ezvpn a s111 -clien t connect auto !# grou p extranet key cisco mode client peer 200. 1.1.1 ! # user na me a s111 passw ord

cisco11 1

! ! # interf ace Loopba ck192

continues

424

Chapter 12: Solutions for Handling Dynamically Addressed Peers

Example 12-2

Configuring IKE X-Auth Using TACACS+ and AAA (Continued)

crypt o ipsec cli ent ezvpn as111-clie nt inside ! interface Serial0/0 crypt o ipsec cli ent ezvpn as111 -client

Unrestricted Peering and Traffic Flows By default, dynamic crypto maps allow peering sessions from any peer that IKE can authenticate. Likewise, by default, all traffic is allowed to and from all peers associating with that dynamic crypto map. Both of these areas can be secured by restricting peering sessions and using dynamic crypto map ACLs to restrict traffic. Example 12-3 describes a scenario in which a dynamic crypto map allows HTTP traffic only from peers 192.168.1.1–5, but allows both http and SMTP traffic from peers 192.168.1.6–10. Example 12-3

Restricting IPSec Peering and Traffic Flows in Dynamic Crypto Maps

AS1-7304A# ! crypto dynamic-ma p extran et-dyn 10 set peer 192.16 8. 1.1 set peer 192.1 68.1. 2 set pe er 192.168 .1.3 se t peer 1 92.168.1.4 set pee r 192 .168.1.5 set ip ac ce ss -group 113 in set trans form-se t extranet- trans mat ch address 111 reve rse- route crypto dyna mic-map e xtran et-dyn 20 set peer 1 92.168. 1.6 set peer 192.1 68.1 .7 set peer 192.1 68.1 . 8 set p eer 192.168 .1.9 se t peer 19 2.168.1.10 set i p access-g roup 114 in set tra nsform-set extranet-t r ans match a ddress 111 re verse-rou te ! acc ess-list 1 13 permit tcp 192.16 8.111 .0 0.0.0.255 192 .168.1.0 0 .0.0.255 eq www access-li st 113 pe rmit tcp 1 92.168 .11 1.0 0.0.0.255 192.168.1 .0 0 .0.0.255 eq s mtp ac cess -list 114 p ermit tcp 192. 168.11 1.0 0.0.0.255 192.1 6 8.1.0 0.0.0.2 55 eq www ac cess-list 114 permit tcp 1 92. 168.111.0 0.0 .0.255 19 2.168.1.0 0.0.0.255 eq sm tp

Dynamic Crypto Maps

425

Dynamic Crypto Map Configuration and Verification The design topology illustrated in Figure 12-3 outlines a site-to-site extranet deployment in which an organization maintains secure connectivity to its extranet partners, which are numerous. The organization relies on data feeds from extranet partners for services critical to the operation of the business but does not maintain control over the configuration of remote routers on the extranet partner’s premises. Instead, those configurations are maintained by the partner, and they are subject to change over time. As such, the organization has chosen to deploy dynamic crypto maps at its local aggregation point for extranet IPSec VPNs, allowing the extranet partners to change their configuration on the fly and dynamically update the IPSec SA peer configuration information on the aggregation router with minimal administrative overhead. Extranet Deployment and Dynamic Crypto Maps

Corp Campus Net AS#1

No changes required at campus—dynamic crypto map responds to changes made at partner’s VPN endpoint.

AS1-7304A

net

Extra

Extra

Dynamic Tunnel Response

net

Static Tunnel Initiation

tra

ne

t

Ex t

ne

Ex tra

Figure 12-3

AS113-3745A Partners makes changes to static crypto configuration on the fly.

Extranet Partner AS#113

426

Chapter 12: Solutions for Handling Dynamically Addressed Peers

Note the size of the extranet in Figure 12-3. The simple hub-and-spoke extranet design listed in this figure presents a fair amount of administrative overhead at the hub, especially when the partner sites control the policy on their VPN endpoint and are liable to make changes to their session on the fly. Deploying dynamic crypto maps (and TED, if necessary) can dramatically ease the hub administrator’s burden of accommodating the many anticipated changes made at the numerous extranet partner sites. To highlight the configuration of a dynamic crypto map, we will select a fixed (extranet partner) end of the tunnel and the dynamic end of the tunnel, and explore the connectivity between those two peers, as the greater extranet design is merely an extension of that dynamically established point-to-point IPSec VPN. NOTE For extranet designs such as this one, there typically will exist a certain amount of High Availability (HA) designed into the aggregation points. Our conversation in this chapter will focus solely on dynamically addressed peering, and, because of this, HA concepts are not incorporated into these configurations.

Example 12-4 provides a sample configuration for a hub router (AS1-7304A) supporting the extranet design discussed in Figure 12-3. Example 12-4

Configuration of AS1-7304A

!# cr ypto isakm p polic y 10 encr 3des hash md5 a u thenticatio n pre-share g ro up 2 !# crypto isak mp key ext rane t address 1 92.168.0.0 2 55. 255. 0.0 ! crypto ipse c tran sform -set extran et-trans esp-3des esp -md5-hmac ! !# crypt o dynamic-m ap extran et-dyn 10 set tran sform-s et ext ranet-tran s

Dynamic Crypto Maps

Example 12-4

427

Configuration of AS1-7304A (Continued)

match address 1 11 !# re verse-route ! ! !# crypto map extranet l oc al-address Lo opback1 c rypt o m ap extranet 10 ipsec-i sakmp dynam ic extranet-d y n ! ! ! ! in terface Lo opback1 ip a ddress 201. 1.1.1 255 .255 .255.255 ! interf ace Loo p back192 ip addres s 192.1 68.1.1 255.255.255. 0 ! in ter fac e Serial0/0 ip a ddress 200.1. 1.1 255.255 .255.25 2 encap sulation fr ame-rel ay frame- relay inter face-d lci 102 frame -relay lmi - t ype ansi !#< --The stati c c rypto ma p is referenc ed i n the physical interface c onfigurat ion. !The dynamic crypto map is indirectl y refer enced here, as it i s bound directly !to t he sp ecified static cryp to map below.--> crypto map ext r anet ! !# access-li st 111 per mi t ip 192.168 .1.0 0.0.0. 255 any

Example 12-5 provides a sample branch router (AS113-3745A) configuration used to establish an IPSec VPN tunnel to the corresponding hub router (AS1-7304A). The extranet topology for this configuration is illustrated in Figure 12-3, and hub configuration is provided in Example 12-5.

428

Chapter 12: Solutions for Handling Dynamically Addressed Peers

Example 12-5

Configuration of AS113-3745A

!# cryp to is akmp policy 10 encr 3 des hash md5 authe nticat i on pre-sha re group 2 cryp to i sakmp key extranet ad d ress 201. 1.1.1 ! ! c rypto ip sec transfo rm-set ext rane t-tra ns esp-3des e sp-md5- hmac ! ! crypto map extran et lo cal-addr ess Loopback 192 cry pto map e xtranet 10 ipsec -i sakmp set peer 201.1 .1 .1 set transf orm-set ext r anet -trans match addr ess 111 ! ! ! ! i nterface Lo opback 111 ip address 111.1.1.1 255. 255.255.0 ! in terface Lo opback192 ip add ress 19 2.168.111. 1 255.25 5.255.0 ! in terface Se rial0 /0 ip address 200.1.1.2 2 55.255.255 .252 encapsula ti on frame-r elay no fai r-qu eue clock rate 12800 0 fra m e-r elay inter face-dlci 2 0 1 cr ypto map ex tranet ! acce ss-list 111 permi t ip any 1 92.168.1.0 0. 0.0.255

Example 12-6 illustrates some basic techniques that administrators can use to verify the operation of a dynamic crypto map configuration such as the one on AS1-7304A. Example 12-6 illustrates the dynamic IPSec SA using the dynamic crypto map referenced in Example 12-4. The protected VRF (proxy) noted in the IPSec SA is consistent with the access list referenced in the dynamic crypto map of Example 12-4. The remote peer, 192.168.111.1, was learned dynamically. The IPSec SA is built from the IPSec headend loopback interface to the

Dynamic Crypto Maps

429

dynamically learned remote peer, 192.168.111.1. It is important to note that sourcing Phase 1 and 2 SAs from the router’s loopback behavior represents a departure from the default behavior, which is to source the IPSec tunnel from the physical interface to which the crypto map is bound. The encryption/decryption statistics for this SA show that five Internet Control Message Protocol (ICMP) messages were sent across the IPSec tunnel—four were encrypted and their responses were decrypted while the first was dropped during the negotiation of Phase 1 and 2 SAs. Example 12-6

Verifying the Dynamic Crypto Maps

show c rypto ipsec sa AS1-7304A#s interface: Serial0/0 Crypto map tag: extranet, local addr. 201.1.1.1 protected vrf: local

ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer: 192.168.111.1:500 PERMIT, flags={} #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 201.1.1.1, remote crypto endpt.: 192.168.111.1 path mtu 1500, media mtu 1500 current outbound spi: ACD63558 inbound esp sas: spi: 0x1EDD5D8D(517823885) transform: esp-3des esp-md5-hmac , in use settings ={Tunnel, } slot: 0, conn id: 2000, flow_id: 5, crypto map: extranet crypto engine type: Software, engine_id: 1 sa timing: remaining key lifetime (k/sec): (4474400/1132) ike_cookies: 0636F569 27CE6A48 BC7118C8 F037E068 IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xACD63558(2899719512) transform: esp-3des esp-md5-hmac ,

continues

430

Chapter 12: Solutions for Handling Dynamically Addressed Peers

Example 12-6

Verifying the Dynamic Crypto Maps (Continued) in use settings ={Tunnel, } slot: 0, conn id: 2001, flow_id: 6, crypto map: extranet crypto engine type: Software, engine_id: 1 sa timing: remaining key lifetime (k/sec): (4474401/1130) ike_cookies: 0636F569 27CE6A48 BC7118C8 F037E068 IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas:

The output in Example 12-7 verifies the operation of the crypto engine as traffic is passed along the VPN path. Note that four packets were decrypted/received from the remote host to initiate tunnel negotiation and that four responses to the packets were encrypted on the return path. This is consistent with the traffic statistics in the IPSec SA diagnostic output in Example 12-6. Example 12-7

Verifying Security Association Cryptographic Operations

show c rypto engi ne connect ions active AS1-7304A#s ID Interface

IP-Address

State

Algorithm

Encrypt

Decrypt

3 Serial0/0

200.1.1.1

set

HMAC_MD5+3DES_56_C

0

0

2000 Serial0/0

200.1.1.1

set

HMAC_MD5+3DES_56_C

0

4

2001 Serial0/0

200.1.1.1

set

HMAC_MD5+3DES_56_C

4

0

Tunnel Endpoint Discovery Tunnel Endpoint Discovery (TED) is a logical extension to the dynamic crypto maps that allows an endpoint to dynamically, proactively discover a previously unknown peer. TED therefore allows peers to proactively initiate the negotiation of IPSec tunnels with unknown peers when the local peer is brought online. TED accomplishes these tasks by sending TED probes out of the local VPN endpoint’s cryptoenabled interfaces. The remote peer does not need to have TED configured in order to be discovered by inbound TED probes. As we will see when configuring TED, VPN devices that receive TED probes on interfaces that do not have TED configured can successfully negotiate a dynamically initiated tunnel using TED. We will use Figure 12-4 to demonstrate how a TED-enabled router can dynamically determine the remote endpoint.

Tunnel Endpoint Discovery

Figure 12-4

431

Using TED to Initiate IPSec VPN Tunnel Negotiation Server – 201.1.1.100/24

Campus Net 201.1.1.0/24

AS1-7304A

4

t

ane

Extr

Ext

ran

et

5 7

Ext

3

AS113-3745A

ran

et

ran

Ext

et 2 6 1

Extranet Partner 111.1.1.0/24

Host – 111.1.1.100/24

In the extranet topology configured in Figure 12-4, a host on the extranet partner site wants to communicate with a server on the central campus. The extranet partner’s local VPN endpoint, however, does not know the peer address with which to build a tunnel. Instead, TED has been enabled on the extranet partner router so that the peer address can be dynamically discovered through the following steps (also referenced in Figure 12-4): 1.

A host wants to communicate securely with a resource on the opposite end of a VPN connection (to be created) and begins sending packets to the destination.

2.

The host’s local VPN gateway receives the packet, then checks its source and destination IP (s=111.1.1.100, d=201.1.1.100) against the crypto-protected address space defined in its configured crypto ACLs.

3.

If the VPN gateway finds a match against its configured crypto ACLs, it sends a TED probe with the original source (111.1.1.100/24) and destination (201.1.1.100/24) IP addresses in the payload out of its crypto-enabled interfaces.

432

Chapter 12: Solutions for Handling Dynamically Addressed Peers

4.

The router or VPN appliance on the remote side receives the TED probe, decapsulates it, and checks the source and destination address in the payload of the TED probe against its own crypto-protected address space in its own locally configured crypto ACLs.

5.

If the remote endpoint finds a match in Step 4, it sends a TED reply containing layer 3 addressing information of the destination to the original source (s=201.1.1.100/24, d=111.1.1.100/24).

6.

The local endpoint at the extranet site checks the TED reply against its crypto-protected address space in its crypto ACLs for a potential match.

7.

If the address space in the TED reply matches those in the local endpoint’s crypto ACLs, the local crypto endpoint initiates IKE negotiation with the peer that sent the TED reply.

In the next section, we will explore TED configuration and verification steps required. The configurations will follow the steps and dynamic crypto map procedures outlined previously in this chapter.

TED Configuration and Verification In this configuration, we will discuss enabling TED as well as the appropriate steps to take when verifying IPSec VPN operation using TED. As illustrated in Example 12-8, TED is only allowed on dynamic crypto maps. As a result, the only two prerequisites for the use of TED are the use of ISAKMP (TED is not supported with manual IPSec keying) and the use of dynamic crypto maps. Example 12-8

Enabling Tunnel Endpoint Discovery

AS1-7304A# ! !# crypto map extra n et 10 ip sec-isakmp dynami c ex tranet-dyn di scover

Enabling TED in this fashion allows AS1-7304A to initiate IPSec tunnel negotiation with AS1133745A. Without TED, traffic tagged as IPSec on AS1-7304A would be dropped if a remote peer had not initiated a VPN connection previously. With TED, however, this IPSec-tagged traffic would initiate ISAKMP Phase 1 negotiation to the remote peer, and traffic would therefore not be dropped.

Case Study—Using Dynamic Addressing with Low-Maintenance Small Home Office Deployments In this case study, we will discuss a large enterprise IPSec VPN deployment. The enterprise, in this case, is a large insurance provider that services customers nationally. In order to increase their scope of coverage and to keep operational expenses down, the provider is primarily comprised of

Using Dynamic Addressing with Low-Maintenance Small Home Office Deployments 433

small branch offices throughout the country. Additionally, the insurance provider has a pilot program that allows agents the opportunity to contract independently with the firm. As a result, the enterprise network must accommodate secure connectivity from a large number of small home offices. When data is transferred from the small branch offices and small office/home office (SOHO) environments to administration databases at the corporate campus headquarters, it is required by law to be done so with confidentiality. Therefore, the insurance provider has decided to invest in a highly flexible and scalable architecture for delivering confidential data transfer between small branches and SOHO environments and the corporate campus network. Of paramount importance to this discussion is the fact that the deployment of VPN endpoints to the thousands of SOHO and branch offices relies on dynamic crypto map usage at the headend. Dynamic crypto maps are required for the following reasons: ■

Agents do not manage the configuration of the VPN endpoints furnished by the firm. Instead, the configuration must be centrally managed by the insurance provider, limiting the involvement of the agent in the deployment process to strict “plug-and-play” behavior.

■

The firm realizes that numerous SOHO VPN deployments can lead to a high degree of change as agents move houses or locations within their region of coverage. The VPN deployment must therefore be able to dynamically reconfigure itself whenever there is such a change.

■

The NMS capabilities at the central site have no means by which to “push” the entire IPSec configuration to the VPN endpoints. Instead, the devices are minimally bootstrapped, and the user is simply instructed to enter a username/password for x-auth during IKE Phase 1 (see next requirement). This process is referred to as Easy Secure Device Deployment (EzSDD).

■

Because the deployment uses a combination of dynamic crypto maps and wildcard PSKs for IKE Phase 1 negotiation, Each VPN endpoint will perform x-auth at IKE “Phase 1.5.” This enables the network administrators to “evict” agents from the deployment securely without compromising the authentication materials used when authenticating the IKE SA.

To meet these needs, the firm has decided to deploy a dynamic crypto map at the headend router. The VPN endpoints at agent offices are dynamically bootstrapped when they are installed at the remote location. To accomplish this, each device is minimally configured using EzSDD to initiate the bootstrap process with minimal assistance from the agent at the remote office. The agent’s routers are therefore drop-shipped directly from Cisco Systems or their chosen reseller with EzSDD enabled by default. This allows the agent to simply plug in and power up the router, then follow several simple instructions on their web browser while connected to the router’s LAN port. Once the agent receives the drop-shipped router at their remote branch location, they power up the router, attach it to the cable or DSL modem supplied by their service provider, attach their workstation to an Ethernet port on the LAN side of the router and open a web browser to the HTTP server running on the supplied router. The agent follows several minimal instructions over the presented web

434

Chapter 12: Solutions for Handling Dynamically Addressed Peers

interface on their workstation to complete the configuration of their crypto endpoint. This process is commonly referred to as Trusted Transitive Introduction (TTI), consisting of three components: ■

Introducer—A device that is trusted by both the petitioner and the registrar. In this case, the introducer would be the insurance agent.

■

Petitioner—A new crypto endpoint that wishes to enroll in the PKI. In this case, the petitioner is the EzSDD endpoint that was drop-shipped directly from Cisco Systems or the selected reseller.

■

Registrar—A cryptographic device that is used to authorize access of new petitioners to the network. In this case, the registrar is the firm’s CA.

Figure 12-5 illustrates the TTI process between a remote site acting as a petitioner and registrar on the firm’s enterprise network. Figure 12-5

EzSDD Trusted Transitive Introduction Process Inside

DMZ Inside IS-C6509-D1 IS-VPN-3060

DMZ Outside Configuration Server

IS-3745-CA

Enterprise Si

IS-PIX535-MAIN DMZ-3750-A Petitioners

Outside

Registrar

IS-7304-A

Agent-NEast-A Agent-NWest-A Agent-NWest-B

Agent-NWest-D

Agent-NEast-C

n tio ple on om cti : C du on e3 tro cti as : In du Ph se2 ntro a :I Ph se2 a Ph

Agent-NWest-C

Agent-NEast-B

Service Provider

Agent-NEast-D Agent-SEast-A

Agent-SEast-D Agent-SEast-B

Agent-SWest-A Agent-SWest-B Agent-SWest-C Agent-SWest-D

Agent-SEast-C Petitioner-7401ASR Phase 1: Welcome

Introducer

Using Dynamic Addressing with Low-Maintenance Small Home Office Deployments 435

Phase 1 is referred to as the Welcome Phase. The agent connects their VPN gateway to their service provider. The device gets an IP address via DHCP and is now capable of contacting the registrar at the firm’s corporate HQ to request an enrollment. In this phase, the agent initiates either an HTTP or HTTPS session to the web server enabled on their new router. NOTE Of critical importance to this design is the use of DHCP in the initial bootstrap configuration. Because this configuration relies on DHCP to determine its IP address, it is difficult for the firm to deploy static crypto maps at the headend (the peer would have to have been defined).

When the petitioner’s HTTP server sees the session initiation come in from the introducer, it automatically generates the cryptographic keys required to enroll in the PKI. Likewise, a partial trustpoint (labeled TTI) is generated to facilitate this enrollment. Figure 12-6 illustrates the Welcome Phase web browser interface to the TTI process. Figure 12-6

TTI Welcome Phase Generation of Cryptographic Keys

The corresponding cryptographic keys are created on the petitioner, as illustrated in Example 12-9. When the introducer authenticates to the petitioner, the agent’s VPN gateway in this case, the petitioner installs a 1024-bit (default modulus) RSA keypair for future use when authenticating IKE Phase 1 using the RSA Signatures method of authentication. Output from the running configuration reflects the creation of a trustpoint for enrollment to the PKI using TTI and is also shown in Example 12-9.

436

Chapter 12: Solutions for Handling Dynamically Addressed Peers

Example 12-9

Automatic Petitioner Configuration Elements During the TTI Welcome Phase.

Router# Jul

1 12:49:02.131: %SSH-5-ENABLED: SSH 1.99 has been enabled

Jul

1 12:49:02.131: %CRYPTO-6-AUTOGEN: Generated new 1024 bit key pair

Router# show c rypto key mypubkey r sa Router#s % Key pair was generated at: 12:49:02 UTC Jul 1 2005 Key name: tti Usage: General Purpose Key Key is not exportable. Key Data: 30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00CDA621 6A21BAA1 D65FFB0C 4C4839D2 19377EAD D10A180D 5ECDD28D 8081FF70 8618E341 6629D0BF FF2F2655 B38B8957 65D7002F F04C08BE DDE0846F C39B5943 193A2BDA 49075218 B1837622 37E40173 513841B5 EEB57CCF 55D216D8 9B56FB7C 23B61125 D57A8327 2E8C399B 6479B982 9AB684F2 9CBAD06A 0E7126E4 3E32EB8D 8B020301 0001 % Key pair was generated at: 12:49:02 UTC Jul 1 2005 Key name: tti.server Usage: Encryption Key Key is not exportable. Key Data: 307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00E1E40D 0CC98F6B CFC7D37F 6DEA0068 1AD55330 475CA9DE C2136964 DFFB8A79 259F634D 8187F927 7BB42F39 66ACEF42 80EA530B 0B3B46E0 C6F9B7F3 B01CFFDE 0172D1C7 7EDB94C1 F514F15A EC8E94F9 0893FCBF 387382E2 E726E95D 1F37D6A0 41020301 0001 Router# #sh ru n Router# Building configuration... Current configuration : 1453 bytes ! ! ! ! crypto pki trustpoint tti revocation-check crl rsakeypair tti ! ! ! end

In the final stages of the EzSDD TTI Welcome Phase, the agent is prompted to enter the website used on the registrar to enroll their cryptographic endpoint into the secure domain. Figure 12-7 displays the instance in which the agent provides the TTI process with the URL necessary to transition from the Welcome Phase to the Introduction Phase.

Using Dynamic Addressing with Low-Maintenance Small Home Office Deployments 437

Figure 12-7

EzSDD Transition from Welcome Phase to Introduction Phase

Phase 2, called the Introduction Phase, is executed when the introducer (in this case, the insurance agent) is ready to authenticate their crypto endpoint on the registrar. Once the registrar’s website is entered, as in Figure 12-7, the petitioner will be prompted for a username and password, if required. In this case, the registrar is configured to use an external AAA database via RADIUS, such as Cisco Secure ACS, which in turn uses the firm's MS Active Directory backend infrastructure to validate the authentication credentials. Figure 12-8 illustrates the next step in the TTI Introduction Phase, providing confirmation that the agent’s credentials have been accepted by the registrar. Figure 12-8

EzSDD Introduction Phase Registrar Credential Confirmation

438

Chapter 12: Solutions for Handling Dynamically Addressed Peers

At this point, the registrar and petitioner have been successfully introduced, and the petitioner can therefore receive its configuration from the petitioner and enroll with the PKI. This is done in the third and final phase of the EzSDD TTI process, the Completion Phase. Figure 12-9 illustrates the completion of the TTI process for a remote branch, Branch-Florida15. At this point BranchFlorida15 has a full working configuration, and has successfully enrolled in the PKI. Figure 12-9

EzSDD Completion Phase

It is important to note that the registrar must be configured to support the authentication requests, configuration requests and pushes, and the certificate enrollment requests inbound from the petitioner. Upon successful authentication, the remote VPN gateway or TTI petitioner at the agent’s site requests a configuration from the database. The configuration database pushes the configuration to the remote VPN gateway, including routing protocol configuration, IPSec configuration, device AAA information, and x-auth configuration. NOTE At this point, the agent’s VPN gateway (petitioner) should be capable of temporarily negotiating a Phase 1 SA with the IPSec aggregation headend in the campus network at corporate headquarters. It is important to note that the VPN aggregation headend will use dynamic crypto maps, since the remote petitioner IP address are not known in advance. This enables the aggregation headend to accommodate the introduction of petitioners into the PKI dynamically, without manual configuration or maintenance from the firm’s IT staff.

Phase 3, the Completion Phase of the TTI process, consists mainly of the user enrolling with the PKI. Phase 3 is facilitated with the automatically generated keying material and trustpoint configuration obtained in Phases 1 and 2, accordingly. The introducer will be notified that the TTI

Using Dynamic Addressing with Low-Maintenance Small Home Office Deployments 439

process has been completed successfully on the web interface presented on their workstation. Figure 12-10 provides output from the Completion Phase of the TTI process, including the running configuration downloaded to the petitioner. Figure 12-10

Branch-Florida15 Configuration Verification Using TTI

Upon completion of these steps, IPSec and ISAKMP SAs can be established between the remote IPSec VPN gateway and the IPSec headend gateway. The configurations in Examples 12-10 and 12-11 illustrate the required configuration on the branch (TTI petitioner) and headend IPSec VPN gateways, respectively. Observe that while both VPN endpoints in this case study use static crypto maps, the headend router at the corporate headquarters must use a dynamic crypto map to accommodate the various agent SOHO devices. This element of the overall architecture exists primarily because the headend will never initiate Phase 1 negotiation to the branch. Instead, the branch will always initiate Phase 1 negotiation to the headend. This allows the dynamic crypto map at the headend to learn about remote peers with no additional configuration as the agents bring their IPSec gateways online. Example 12-10

Low-Touch SOHO and Small Branch IPSec VPN Endpoint Deployments—Remote IPSec VPN Endpoint/Petitioner Final Configuration

hostna me Branch- Florida15 ! ! !

continues

440

Chapter 12: Solutions for Handling Dynamically Addressed Peers

Example 12-10

Low-Touch SOHO and Small Branch IPSec VPN Endpoint Deployments—Remote IPSec VPN Endpoint/Petitioner Final Configuration (Continued)

ip dhc p pool rem- net net work 192.1 68.1.0 255 .255. 255. 0 defau lt-router 1 9 2.168.1. 1 ! ! ! crypto pk i t r ustpoint tt i e nrollment u rl http:// IS-VPNConc- A: 80 serial-numb er re vocati o n-check cr l rsake ypair tt i ! ! cry pto isakmp policy 10 ! ! crypto ips ec transfor m-set field -transf orm esp-3des esp -sha-hmac ! ! crypto map Br anch-F lorida15 10 ipsec-i sakmp set peer 2 00.1.1.1 set t ransform-se t field-t ransform ma tch address 10 1 ! interfa ce FastEthe rnet0 /0 ip addre ss 200.1.1. 23 255.255. 255.0 ip v irtual- reassembly ! ip na t outside speed a uto fu ll-duplex crypto m ap B ranch- Florida15 ! inte rface FastEthe rnet0/1 ip add res s 192.168. 1.1 255.25 5.255 .0 ip vir tual-reasse mbly

Using Dynamic Addressing with Low-Maintenance Small Home Office Deployments 441

Example 12-10

Low-Touch SOHO and Small Branch IPSec VPN Endpoint Deployments—Remote IPSec VPN Endpoint/Petitioner Final Configuration (Continued)

! ip na t insi d e spe ed auto f ull-duplex ! ip cl assless ! ! ! ip http server ip ht tp authe nticatio n local ip http se cure-ser ver ip h ttp secure - tr ustpoint ! ! ip nat in sid e source li st 1 interfa ce FastEthe rnet0/0 overl oad ! ! acces s-li s t 1 permit 192.168.0.0 0 .0. 255.255 ! acce ss-list 101 permit ip ho st 200.1.1.1 any ! End

The configuration shown in Example 12-11 illustrates a sample configuration of the headend router in this case study. Remember that this case study was written to illustrate the need for

442

Chapter 12: Solutions for Handling Dynamically Addressed Peers

dynamic crypto maps. Note that without the dynamic crypto map on IS-VPNConc-A in Example 12-11, each remote user would require their own static crypto map entry on IS-VPNConc-A. The use of dynamic crypto maps on the headend, however, allows IS-VPNConc-A to learn about its peers dynamically as they are brought online by the insurance agents at the remote sites. This greatly reduces the configuration and administration costs required to support the overall remote access VPN (RAVPN) system, ultimately resulting in drastically reduced operating expenses for the firm. Example 12-11

Low-Touch SOHO and Small Branch IPSec VPN Endpoint Deployments—Headend IPSec Concentrator/Registrar

hostna me IS-VPNCo nc-A ! ip d omain n ame cisco. com ! ! ! cr ypto pk i s erver cs1 grant a uto ! ! cr ypto pki tr ustpoint cs1 re vocation-ch eck crl rsake ypair cs1 ! ! crypto pk i trustpoin t IS- VPNConc-A enrollmen t url http://IS-V PNConc-A: 8 0 serial-n umber ip-addre ss FastEth ernet0/1 rev ocat ion -check none rsa keypair 10 24 ! ! !< --The follo wing regis trar config uration is requi red for EzSDD Peti tioners

Using Dynamic Addressing with Low-Maintenance Small Home Office Deployments 443

Example 12-11

Low-Touch SOHO and Small Branch IPSec VPN Endpoint Deployments—Headend IPSec Concentrator/Registrar (Continued)

!(Agen t Remote V PN Gateway s) to obtain their final configur ation. !This regis trar uses the PK I server cs1 (via t he trustpoint co nfigur ation !on this route r), a nd instructs the pet itioner and introducer t o obtain the !petiti oner con fi guration on the http se rver “con fserv-main” w hic h resides !on the ent erpri se netwo rk DMZ--> cr ypto pr ov isioning re gistrar pki- s erver cs1 templat e confi g h ttp://confs erv-main/Br anch-Flo rida15-confg us erna me remuser 1 privilege 15 pass word 0 cisco ! ! crypto isa kmp policy 10 ! ! crypt o ipsec tra nsform-s et RA VPN-trans esp -3des e sp-sha-hmac ! ! crypt o dynamic- m ap RAVPN- dyn 10 se t trans form-set RAVPN-tran s ! ! !< -- To apply a dynamic cr yp to map, it must first be r ef erenced !in a s tatic cry pto ma p--> crypto m ap RAV PN- stat 10 ips ec-isakmp dy nam ic RAVPN-dyn ! ! interfac e F astEthernet 0/1 ip addr ess 200.1.1.1 2 55.255.255 . 0 duplex aut o speed auto ! cryp to map RAVP N -stat ! !

continues

444

Chapter 12: Solutions for Handling Dynamically Addressed Peers

Example 12-11

Low-Touch SOHO and Small Branch IPSec VPN Endpoint Deployments—Headend IPSec Concentrator/Registrar (Continued)

ip htt p server ip http secu re- server i p http secu re-t rustpoint ! End

In this example, the headend router (IS-VPNConc-A) acts as the registrar for the EzSDD trusted transitive introduction process. In reality, the registrar will reside on another, separate IOS-based RA or CA within the enterprise network. Because the focus of this chapter is on dynamic crypto maps, the EzSDD registrar functionality is configured on the headend router for simplicity. NOTE For more information on EzSDD, log on to the following CCO resource with a valid user account: http://www.cisco.com/en/US/partner/tech/tk583/tk372/ technologies_white_paper0900aecd80128d1f.shtml http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/ products_feature_guide09186a008028afbd.html

Once the EzSDD process has completed, the user can then verify the establishment of the IPSec tunnel between the newly introduced router of the secure domain at the agent site and the headend router. Example 12-12 shows that the two crypto endpoints have established Phase 1 and Phase 2 SAs successfully. Note that the source of the SAs (the agent’s IPSec VPN gateway) is randomly attained via service provider’s DHCP server, rendering it impossible to manually configure the remote peer statically on the firm’s headend VPN router—a dynamic crypto map must be used to learn the remote peer’s address when the agent’s VPN gateway comes online. NOTE Although the VPN gateway at the remote site technically uses a static crypto map to manually define the peer IP of the VPN concentrator on the enterprise network, it is not initially configured as such. Instead, this address is provided to the VPN gateway (the petitioner) during the EzSDD TTI process, along with the full configuration of the router. The router is also enrolled in the enterprise’s PKI during this process.

Example 12-12 shows the establishment of Phase 1 and 2 SAs on the IPSec headend router, 3745Registrar. The source of the Phase 1 SA below is dynamically learned via the TTI process. Also note the consistency of the source IP addresses in the Phase 1 and 2 SAs—the source IP address of the remote peer (TTI petitioner) is the same as the dynamically learned source IP address in the Phase 1 SA.

Using Dynamic Addressing with Low-Maintenance Small Home Office Deployments 445

Example 12-12

Verifying SA Establishment on the IPSec Headend

show c rypto isakmp sa 3745-Registrar#s dst

src

state

200.1.1.1

200.1.1.23

QM_IDLE

conn-id slot status 24

0 ACTIVE

show c rypto ipsec sa 3745-Registrar#s interface: FastEthernet0/1 Crypto map tag: campus-stat, local addr 200.1.1.1 protected vrf: (none) local

ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)

remote ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0) current_peer 200.1.1.23 port 500 PERMIT, flags={} #pkts encaps: 307, #pkts encrypt: 307, #pkts digest: 307 #pkts decaps: 307, #pkts decrypt: 307, #pkts verify: 307 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 200.1.1.1, remote crypto endpt.: 200.1.1.23 path mtu 1500, ip mtu 1500 current outbound spi: 0x1C5F47BE(476006334) inbound esp sas: spi: 0x46C2BDC4(1187167684) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } conn id: 2003, flow_id: AIM-VPN/HPII:3, crypto map: campus-stat sa timing: remaining key lifetime (k/sec): (4459514/2316) IV size: 8 bytes replay detection support: Y Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x1C5F47BE(476006334) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } conn id: 2004, flow_id: AIM-VPN/HPII:4, crypto map: campus-stat sa timing: remaining key lifetime (k/sec): (4459514/2314) IV size: 8 bytes

continues

446

Chapter 12: Solutions for Handling Dynamically Addressed Peers

Example 12-12

Verifying SA Establishment on the IPSec Headend (Continued) replay detection support: Y Status: ACTIVE outbound ah sas: outbound pcp sas:

3745-Registrar#

Summary As workforces become increasingly mobile in nature, so does the need to gain secure network access from a varying physical locations. Dynamic peers allow network administrators to ensure network connectivity when remote network peers are either not known in advance or change to an unknown value over time. Dynamic peers also require less administrative effort than do static peers. Dynamically IPSec peer addressing has therefore become an increasingly popular design alternative in many large-scale enterprise IPSec VPN designs and in RAVPN designs. In this chapter, we have discussed the design issues that arise when supporting dynamically addressed peers in an IPSec VPN design, including: ■

Added support within ISAKMP for dynamically addressed peers

■

Impact of dynamically addressed peers on the routed infrastructure

■

Security considerations for dynamically addressed peers

We have also discussed the added features for addressing these fundamental design considerations, including the use of dynamic crypto maps, tunnel endpoint discovery, IKE Extended Authentication (x-auth), and IKE Mode Config. Effective IPSec VPN designs that employ the use of dynamically addressed peers commonly use many of these solution components. Dynamic crypto maps are central to the support of dynamically addressed peers, since no manual specification of a peer within the dynamic crypto map configuration is required. The chapter covers the use of dynamic crypto maps in IPSec headend configurations in extranet deployments and in large-scale branch and SOHO deployments. When a dynamic crypto map is used in conjunction with a static crypto map on the remote IPSec endpoint, only the remote IPSec VPN endpoint can initiate the negotiation of the IPSec VPN tunnel unless TED is used. TED allows an IPSec VPN endpoint such as the one described above to dynamically discover its remote IPSec VPN tunnel endpoint through the exchange of TED probes.

Summary

447

The changes brought forward by IKE Extended Authentication (x-auth) can be used to provide more granularity when authenticating a dynamically addressed peer. IKE x-auth occurs in addition to the negotiation of IKE itself and is very effective at eliminating group eviction difficulties that commonly arise from authenticating IKE with wildcard preshared keys. Refer to the previous discussion of IKE wildcard preshared keys for more discussion on this very important design consideration. IKE Mode Config can be used to assign a remote IPSec VPN endpoint various configuration elements, including the remote IPSec VPN endpoint’s IP address, as part of IKE Phase 1 negotiation.

APPENDIX

A

Resources Books Applied Cryptography, 2nd Edition, Bruce Schneier, John Wiley and Sons, Inc. 1996 Designing Network Security, M. Kaeo, Cisco Press, 1999

RFCs RFC 2105: Internet X.509 Public Key Infrastructure, C. Adams, S. Farrell, http://www.ietf.org/ rfc/rfc2510.txt, March 1999 RFC 2246: The TLS Protocol Version 1.0, T. Dierks, C. Allen, IETF, http://www.ietf.org/rfc/ rfc2246.txt, January 1999 RFC 2395: IP Payload Compression Using LZS, R. Friend, R. Monsour, IETF, http:// www.ietf.org/rfc/rfc2395.txt, December 1998 RFC 2401: Security Architecture for the Internet, S. Kent, R. Atkinson, IETF, http:// www.ietf.org/rfc/rfc2401.txt, November 1998 RFC 2402: IP Authentication Header (AH), S. Kent, R. Atkinson, IETF, http://www.ietf.org/ rfc/rfc2402.txt, November 1998 RFC 2406: IP Encapsulating Security Payload (ESP), S. Kent, R. Atkinson, IETF, http:// www.ietf.org/rfc/rfc2406.txt, November 1998 RFC 2408: Internet Security Association and Key Management Protocol, D. Maughan, M. Schertler, M. Schneider, J. Turner, IETF, http://www.ietf.org/rfc/rfc2408.txt, November 1998 RFC 2409: The Internet Key Exchange, D. Harkins, C. Carrel, IETF, http://www.ietf.org/rfc/ rfc2409.txt, November 1998 RFC 2412: The Oakley Key Determination Protocol, H. Orman, IETF, http://www.ietf.org/rfc/ rfc2412.txt, November 1998

450

Appendix A: Resources

RFC 2560: Online Certificate Status Protocol, M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, http://www.ietf.org/rfc/rfc2560.txt, June 1999 RFC 2631: Diffie-Hellman Key Agreement Method, E. Rescorla, IETF, http://www.ietf.org/rfc/ rfc2631.txt, June 1999 RFC 2748: Generic Routing Encapsulation (GRE), D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, IETF, http://www.ietf.org/rfc/rfc2784.txt, March 2000 RFC 3526: More Modular Exponential (MODP) Diffie-Hellman Groups for Internet Key Exchange (IKE), T. Kivenen, M. Kojo, http://www.ietf.org/rfc/rfc3526.txt, May 2003 RFC 3546: TLS Security Extensions, S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright, IETF, http://www.ietf.org/rfc/rfc3546.txt, June 2003

Web and Other Resources Cisco Secure Consulting Services (Security Wheel), http://www.cisco.com/warp/public/cc/serv/ mkt/sup/advsv/pavsup/sposass/cscsb_br.pdf Configuring IKE Extended Authentication, http://www.cisco.com/en/US/partner/products/sw/ iosswrel/ps1834/products_feature_guide09186a008007feb8.html Designing and Implementing a Secure Network Infrastructure, M. Kaeo, NANOG, http:// www.nanog.org/mtg-0310/pdf/kaeo.ppt, October 2003 How TLS/SSL Works, http://www.microsoft.com/technet/prodtechnol/windowsserver2003/ library/TechRef/c22a4d3d-6335-4b9b-b344-bbae041203b4.mspx Internet Draft: Simple Certificate Validation Protocol, T. Freeman, R. Housley, A. Malpani., http:/ /www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-16.txt, October 2004 Internet Key Exchange Mode Config, http://www.cisco.com/en/US/partner/products/sw/iosswrel/ ps5014/products_feature_guide09186a0080088172.html Office for Civil Rights—HIPAA, http://www.hhs.gov/ocr/hipaa/

Web and Other Resources

451

PKI Basics—A Technical Perspective, Shashi Kiran, Patricia Lareau, Steve Lloyd, PKI Forum, http://www.pkiforum.org/pdfs/PKI_Basics-A_technical_perspective.pdf, 2002 Security of the MPLS Architecture, http://www.cisco.com/en/US/partner/tech/tk436/tk428/ technologies_white_paper09186a00800a85c5.shtml Software IPPCP (LZS) with Hardware Encryption, http://www.cisco.com/en/US/partner/ products/sw/iosswrel/ps1839/products_feature_guide09186a0080110c00.html SSL/TLS Case Study, http://www.stanford.edu/class/cs259/lectures/02-SSL.pdf

Index Numerics 3DES (triple data encryption standard), 21

A–B aggressive mode negotiation, 89–90 AH (Authentication Headers), 6, 57–58 alternatives to IPsec VPN HA, stateful, 257–260 stateless, 242 HSRP, 244–245 RRI, 245 applying crypto maps in SOHO environments, 432–446 asymmetric cryptography, 392 asymmetric key encryption, 36–39, 46 impact on CPU processing, 404 asymmetric routing as cause of broken VPN tunnels, 220 authentication, 44 of public key certificates, 402 authentication errors (IKE), troubleshooting, 146–165 authentication services (IKE) preshared keys, 83–85 RSA encryption, 85 RSA signatures, 86–87 X.509 certificates, 86–87 BGP (Border Gateway Protocol), crypto path availability, 219 business drivers for VPNs, 29–30 remote access VPNs, 30 site-to-site VPNs, 30–31

C CA hierarchy configuration, case study, 412–414 CAs (Certificate Authorities), 393, 397 enrollment process, 395 RA interoperability, configuring, 410–412 case studies, PKI CA hierarchy, 412–414 configuring CA/RA interoperability, 410–412 cryptographic endpoint integration, 407–409 CBC (cipher block chaining), 55 CBWFQ (class-based weighted fair queuing), impact of IPsec on, 181–182 CE (customer edge) routers, 18–20 characteristics of effective VPNs, 6–7 cipher text, 6 ciphers, 36 Cisco IPSec VPN 3000 series concentrators, 225 Cisco Security Wheel, 31 Cisco VPN 3000 series concentrators, clustering, 227–230 clustered spoke VPN design, 130 clustered VPN concentrator designs, 137–138 commands, redistribute static, 245, 269 comparing In-Path and Out-of-Path encryption, 361, 368–369 compulsory tunnels, 13 concentrator clustering, 225–230 configuring CA hierarchy, case study, 412–414 CA/RA interoperability, case study, 410–412 crypto maps, 66–68 dynamic crypto maps, 425–430

geographic HA DMVPNs, 287–294 IPsec+GRE, 279–280, 283–287 RRI with multiple IPsec peers, 267–278 ISAKMP, 94–95 RAVPN HA DNS-based load balancing, 343–345 using multiple IPsec peers, 345, 348–355 with HSRP, 327–333 with VCA, 333–342 with VRRP, 315–326 site-to-site VPNs, 108–110 TED, 432 control messages, 16 creating message digests, 42–44 transforms, 63–66 CRLs, 396 scalability, 404 crypto ACLs, 169 mismatches, troubleshooting, 169–170 crypto engines, 50 crypto maps, 236 configuring, 66–68 multiple peering statements, tunnel termination HA, 213 crypto path availability, 215–218 cryptographic endpoints, 397 cryptographic key derivation (SSL VPNs), 23–24 CSM (Content Switch Module), external load balancing, 231–232

D data authentication, 44 data confidentiality, 6 in VPDN deployments, 10 data integrity, 7, 42–44 decryption, 6 deployment models hub-and-spoke VPNs, 128–130 clustered spoke design, 130 redundant clustered spoke design, 131 IPsec+GRE, 121–122 sample configurations, 123–125 tunnel establishment, verifying, 126–127 RAVPNs, 132 clients, 132 clustered VPN concentrator designs, 137–138 standalone VPN concentrator designs, 133–136 site-to-site VPNs, 107 configuring, 108–110 over routed domain, 117–120 verifying configuration, 111–117 DES (data encryption standard), 21 Diffie, Whitfield, 392 Diffie-Hellman key exchange, 51 secret key generation, 79–80, 82–83 DiffServ, impact of IPsec on, 181–182 digital signatures, generating, 44–46 distribute lists, 199 DMVPNs (Dynamic Multipoint VPNs), 27, 130 geographic HA, configuring, 287–294 DNS server load balancing, 225–227 in RAVPNs with geographic HA, 343–345

454

DPD (Dead Peer Detection)

DPD (Dead Peer Detection), 92–94 peer availability, 217 dual-DMZ tunnel termination, 372–373, 377 dynamic crypto maps, 418 and RRI, 420 applying in SOHO environments, 432–446 configuring, 425–430 impact on ISAKMP/IKE, 418–419 impact on VPN behavior, 418–424 routing considerations, 419–420 security considerations, 421 key administration and scalability, 421–424 unrestricted peering and traffic flows, 424 TED, 430–432 verifying, 425–430

E–F–G eliminating single points of failure for site-to-site VPNs, 209 enabling TED, 432 encryption, 6 asymmetric, 36–39 In-Path versus Out-of-Path, 361, 368–369 Out-of-Path, 370 symmetric, 21, 39–41 enrollment process, 395 for RSA signatures, 398, 402 for X.509 certficates, 398, 402 ESP (Encapsulating Standard Protocol), 6 confidentiality services, 55–56 data integrity and authentication services, 56–57 extensions for IKE mode config, 96–98 xauth, 98–99 external load balancers, 230–232 failover stateful HA failover process, 261–263 stateless HA failover process, 246–257

firewalled VPN environments ICMP unreachables, troubleshooting, 174 troubleshooting, 171–174 tunnel termination, 370–378 floating static routes, 238 flow-based QoS, impact of IPsec on, 180–181 format of L2F packets, 10 forwarding public key certificates, 403 fragmentation on Cisco IOS VPN endpoints, 189–193 PMTUD, 184–188 preventing with IPsec Prefragmentation, 193–196 with manual MTU adjustment, 196 Virtual Fragmentation Reassembly, 174 generating Diffie-Hellman secret keys, 79–83 digital signatures, 44–46 geographic HA, 267 DMVPNs, 287–294 IPsec+GRE, 279–280, 283–287 RRI with multiple IPsec peers, 267–277 goals of VPN implementation, 6–7 GRE-offload, 306, 379–383. See also IPsec+GRE model with cleartext firewall paths, 385 with dynamic crypto maps, 383–384 with high-speed tunnel termination, 385 with IKE x-Auth, 384–385

H HA (High Availability) geographic HA, 267 DMVPNs, 287–294 IPsec+GRe, 279–287 RRI with multiple IPsec peers, 267–277 in RAVPNs, 314 concentrator redundancy with multiple peers, 345, 348–355 DNS-based load balancing, 343–345 HSRP, 327–333

IV (Initialization Vector)

VCA, 333–342 VRRP, 315, 320, 323–326 load-balanced designs concentrator clustering, 227–230 DNS server load balancing, 225–227 external load balancers, 230–232 load sharing with peer statements, 222–224 routing, 224 peer availability, 216 on-demand DPD, 217 SSO, 259 stateful HA alternatives to, 257–260 failover process, 261–263 stateless HA alternatives to, 242–245 failover process, 246–257 tunnel termination redundancy, 210 on HSRP/VRRP virtual interfaces, 211 using RP-based IPsec HA, 214–215 with multiple peer statements, 212–214 handshake process (SSL VPNs), 22–24 hardware-based VPN clients, 133 hashes, 42 Hellman, Martin, 392 HMAC (hashed message authentication codes), 24, 42 home gateways, 10 HSRP (Hot Standby Routing Protocol), 244 RAVPN concentrator HA, 327–333 timers, tuning, 255 HSRP/VRRP virtual interfaces, tunnel termination point HA, 211 hub-and-spoke IPsec model, 128–130 clustered spoke design, 130–131 site-to-site VPNs, 26

I ICMP messages rate-limiting, 187 unreachables, troubleshooting in firewalled VPN environments, 174 identifying IPsec transform set mismatches, 168

IKE, 78 authentication errors, troubleshooting, 146–165 authentication services pre-shared keys, 83–85 RSA encryption, 85 RSA signatures, 86–87 X.509 certificates, 86–87 Diffie-Hellman secret key generation, 79–83 keepalives, removing stale SAs from SADB, 217 key mismatches, troubleshooting, 150–151 mode config extension, 96–98 Phase I negotiation aggressive mode negotiation, 89–90 main mode negotiation, 88–89 Phase II negotiation DPD, 92 IKE keepalives, 92–94 PFS, 91–92 quick mode negotiation, 90 SA negotiation and maintenance, 79 SA proposal mismatches, troubleshooting, 142–146 x-auth, 421 xauth extension, 98–99 impact of vendor interoperability on path availability, 301–305 In-Path encryption, 368–369 integrity, 7 IntServ, impact of IPsec on, 183 invalid SPI recovery, 308–309 IPComp, 58–59 IPPCP (IP Payload Compression Protocol), 58–59 IPsec Prefragmentation, 193–196 IPsec+GRE model, 121–122, 190 geographic HA, configuring, 279–280, 283–287 sample configurations, 123–125 tunnel establishment, verifying, 126–127 ISAKMP, 78 configuring, 94–95 ITU-T X.509v3–compliant certificates, 396 IV (Initialization Vector), 57

455

456

keepalives (IKE)

K–L keepalives (IKE), 92–94 key management need for, 77 PKI, 391–393 CAs, 397 CRLs, 396 cryptographic endpoints, 397 public key certificates, 394–395 registration authorities, 395–396 L2F (Layer 2 Forwarding), home gateways, 10 L2TP (Layer 2 Tunneling Protocol) control messages, 16 payload packets, 16 tunnel negotiation process, 17 LAC (L2TP Access Concentrator), 16 lack of RP support, effect on IPS HA design, 302–304 Layer 2 Forwarding Protocol, 10 packet format, 10 tunnel establishment process, 11–12 life cycle of public key certificates, 397 RSA signatures, 397, 401 X.509 certificates, 398, 401 limitations of vendor HA interoperability inability to specify multiple peers, 297–300 lack of peer availability mechanisms, 300–301 LLQ (low-latency queuing), impact of IPsec on, 181–182 LNS (L2TP Network Server), 16 load balanced designs concentrator clustering, 227–230 DNS server load balancing, 225–227 configuring in RAVPNs with geographic HA, 343–345 external load balancers, 230–232 load sharing with peer statements, 222–224 routing, 224 load sharing with peer statements, 222–224 local IPsec HA, 235 Lookahead Fragmentation, 194 LZS (Lempel Ziv Stac), 58–59

M–N–O main mode negotiation, 88–89 manual keying, 68–77 manual MTU adjustment, preventing fragmentation, 196 MD5 (Message Digest 5), 43 message digests, creating and verifying, 42–44 messages (ICMP), rate-limiting, 187 mismatched crypto ACLs, troubleshooting, 169–170 mismatched IKE SA proposals, troubleshooting, 142–146, 165–168 mismatched transform sets, identifying, 168 mode config extension (IKE), 96–98 MODP (prime modulus), 51 MP-BGP (Multiprotocol Border Gateway Protocol), 18 MPLS VPNs, 18–20 VRFs, 19 MPPE (Microsoft Point-to-Point Encryption), 13 MTUs (maximum transmission units), manual adjustment, 196 NAS (Network Access Server), 10 NAT (Network Address Translation) SPI-based, troubleshooting, 179–180 troubleshooting, 174–178 NAT Detect, 179 NAT-on-a-stick, IPsec VPN tunnel termination, 362–368 NAT-T, troubleshooting, 178–179 NHRP (next hop routing protocol), 27 nonces, 85 obtaining public key certificates, 403 OCSP (Online Certificate Status Protocol), 405 “on-a-stick” designs, 386 NAT-on-a-stick, 362–368 router-on-a-stick, 359–362 on-demand DPD, 217 OSI reference model, 9 Out-of-Path encryption, 368–370

registration authorities

P P (provider) routers, 18 packets, L2F, 10 path availability, 218, 284 and vendor HA availability, 301–305 path symmetry, managing, 219 payload packets, 16 PE (provider edge) routers, 18 peer availability, 215–216, 297 on-demand DPD, 217 peer mismatches (IKE), troubleshooting, 150–151 periodic DPD, 218 PFS (perfect forward secrecy), 69, 91–92 PKI (Public Key Infrastructure), 391–393 CAs, 397 case studies CA hierarchy, 412–414 configuring CA/RA interoperability, 410–412 cryptographic endpoint integration, 407–409 CRLs, 396 cryptographic endpoints, 397 enrollment process, 163 public key certificates, 394–395 registration authorities, 395–396 PMTUD (Path MTU Discovery), 184–188 PPTP (Point-to-Point Tunneling Protocol), 12 compulsory tunnels, 13 data structure, 14 tunnel negotiation process, 14 voluntary tunnels, 13 preshared keys, 83–85 preventing fragmentation with IPsec Prefragmentation, 193–196 with manual MTU adjustment, 196 proxies, 169 PSKs (preshared keys), troubleshooting mismatched peer addresses, 149–150 public key certificates, 394–395 authentication, 402 forwarding, 403 life cycle of, 397 obtaining, 403 registration process, 402

RSA signatures, life cycle of, 397, 401 signing, 403 X.509 certificates, life cycle of, 398, 401 public key cryptography, 392 public key encryption, 45–46 Diffie-Hellman key exchange, 51 RSA, 48–50 RSA signatures, 50

Q–R QoS (quality of service), impact of IPsec on DiffServ, 181–182 flow-based, 180–181 IntServ, 183 quick mode negotiation, 90 RAs (registration authorities), 395–396 CA interoperability, configuring, 410–412 rate-limiting ICMP messages, 187 RAVPNs (remote-access VPNs) deployment model, 132 clients, 132 clustered VPN concentrator designs, 137–138 standalone VPN concentrator designs, 133–136 HA, 314 DNS-based load balancing, 343–345 geographic HA, DNS-based load balancing, 345, 348–355 HSRP, 327–333 VCA, 333–342 VRRP, 315, 320, 323–326 reconvergence of routing protocols, impact on IPsec reconvergence, 238–240 recursive routing effect on IPsec VPNs, 197–200 symptoms of, 197–198 redistribute static command, 245, 269 redistribution distribute lists, 199 of VPN routes, 253 redundant clustered spoke VPN design, 131 registration authorities, 395–396 CA interoperability, configuring, 410–412

457

458

registration process for public key certificates

registration process for public key certificates, 402 remote-access VPNs business drivers, 30 SSL, 28 removing stale SAs from SADB, 217 round-robin approach to DNS resolution, 227 route descriptors, 20 router-on-a-stick, IPsec VPN tunnel termination, 359–362 routing, 224 RP-based IPsec HA, 214–215 RRI (Reverse Route Injection), 245 and dynamic crypto maps, 420 impact on vendor interoperability, 304–305 RSA encryption, 48–50, 85 IKE authentication errors, troubleshooting, 151–158 signatures, 23, 50, 86–87, 396 enrollment process, 398, 402 IKE authentication errors, troubleshooting, 158–165 life cycle of, 397, 401 RSVP (Resource Reservation Protocol), impact of IPsec on, 183

S sample IPsec+GRE model configurations, 123–125 SAs (security associations) IPsec tunnel security parameters, 59, 62–63 need for, 77 proposal mismatches, troubleshooting, 165–168 security parameters, manual keying, 68–77 transport mode, 52 tunnel mode, 54 scalability of CRLs, 404 SCEP (Simple Certificate Enrollment Protocol), 402 SCTP (Stream Control Transmission Protocol), 260 security wheel, 32 sender non-repudiation, 7 serialization delay, 196 session authentication (SSL VPNs), 24 SHA (Secure Hash Algorithm), 43

shared secret keys, 39 signing public key certificates, 403 single points of failure for site-to-site VPNs, 208–209 site-to-site IPsec VPNs, 25, 107 business drivers, 30–31 configuration, verifying, 111–117 configuring, 108–110 hub-and-spoke networks, 26 over routed domains, 117, 120 single points of failure, eliminating, 208–209 site-to-site IPsec+GRE model. See IPsec+GRE model software-based VPN clients, 132 SOHO deployments, applying dynamic crypto maps case study, 432–446 SPI (security parameter index), 56 SPI-based NAT, troubleshooting, 179–180 SSL VPNs, 21 cryptographic key derivation, 23–24 handshake process, 22–24 HMAC, 24 RAVPN architectures, 28 session authentication, 24 transport layer security, 25 tunnel establishment process, 22 SSO (stateful switchover), 259 stale SAs impact on IPsec reconvergence, 240 removing from SADB, 217 standalone VPN concentrator designs, 133–137 stateful IPSec HA, 212 alternatives to, 257–260 failover process, 261–263 stateless IPsec HA, 212 alternatives to, 242 HSRP, 244–245 RRI, 245 failover process, 246–257 goals of, 243–244 static crypto maps, 417–418 symmetric encryption, 21, 39–41 shared secret keys, Diffie-Hellman secret key generation, 79–83 symptoms of recursive routing, 197–198

voluntary tunnels

T TED (Tunnel Endpoint Discovery), 430–432 timers (HSRP), tuning, 255 topologies. See VPN topologies transform sets, identifying mismatches, 168 transforms AH, 57–58 creating, 63–66 ESP confidentiality services, 55–56 data integrity and authentication services, 56–57 IPComp, 58–59 LZS, 58–59 transport layer VPNs, SSL VPNs, 21 cryptographic key derivation, 23–24 handshake process, 22–24 HMAC, 24 session authentication, 24 transport layer security, 25 tunnel establishment process, 22 transport mode, 52, 55 troubleshooting IKE authentication errors, 146–165 peer mismatches, 150–151 SA proposal mismatches, 142–146, 165–168 mismatched crypto ACLs, 169–170 NAT issues in IPsec VPN designs, 174–178 SPI-based NAT, 179–180 NAT-T issues in IPsec VPN designs, 178–179 VPNs in firewalled environments, 171–174 TTI (Trusted Transitive Introduction), 434 tunnel mode, 54–55 tunnel termination. See also tunnels dual-DMZ firewall design, 372–373, 377 firewalled, 370–378 GRE-offload, 379–383 with cleartext firewall paths, 385 with dynamic crypto maps, 383–384 with high-speed tunnel termination, 385 with IKE x-Auth, 384–385 “on a stick” termination NAT-on-a-stick, 362–368 router-on-a-stick, 359–362

termination redundancy, 210 on HSRP/VRRP virtual interfaces, 211 using RP-based IPsec HA, 214–215 with multiple peer statements, 212–214 tunnels L2F establishment process, 11–12 load-balanced designs concentrator clustering, 227–230 DNS, 225–227 external load balancers, 230–232 load sharing with peer statements, 222–224 routing, 224 negotiation process, 17 PPTP compulsory, 13 tunnel negotiation process, 14 voluntary, 13 SA security parameters, 59, 62–63

V “validity period” field (ITU-T X.509v3compliant certificates), 396 VCA (Virtual Cluster Agent) protocol, 228 RAVPN concentrator HA, 333–342 vendor HA interoperability design considerations, 306 interoperability with stateful IPsec HA, 309–311 invalid security parameter index recovery, 308–309 Phase1/2 SA lifetime expiry, 307 SADB management, 307–308 impact on path availability, 301–305 limitations of inability to specify multiple peers, 297–300 lack of peer availability mechanisms, 300–301 verifying dynamic crypto maps, 425–430 IPsec+GRE model, tunnel establishment, 126–127 message digests, 42–44 site-to-site VPN configuration, 111–117 TED, 432 Virtual Fragmentation Reassembly, 174 voluntary tunnels, 13

459

460

VPDNs (virtual private dialup networks)

VPDNs (virtual private dialup networks), 10 L2TP, 16 control messages, 16 payload packets, 16 tunnel negotiation process, 17 Layer 2 Forwarding Protocol, 10 packet format, 10 tunnel establishment process, 11–12 PPTP, 12 compulsory tunnels, 13 data structure, 14 tunnel negotiation process, 14 voluntary tunnels, 13 VPN clients, 28 VPN concentrators, 28 VPN routes, redistribution, 253 VPN topologies hub-and-spoke, 128–130 clustered spoke design, 130 redundant clustered spoke design, 131 IPsec+GRE model, 121–122 sample configurations, 123–125 tunnel establishment, verifying, 126–127 RAVPNs, 132 clients, 132 clustered VPN concentrator designs, 137–138 standalone VPN concentrator designs, 133–136 site-to-site, 107 configuring, 108–110 over routed domain, 117, 120 verifying configuration, 111–117

VPN tunnel termination dual-DMZ firewall design, 372–373, 377 firewalled, 370–378 GRE-offload, 379–383 with cleartext firewall paths, 385 with dynamic crypto maps, 383–384 with high-speed tunnel termination, 385 with IKE x-Auth, 384–385 “on a stick” termination NAT-on-a-stick, 362–368 router-on-a-stick, 359–362 termination redundancy, 210 on HSRP/VRRP virtual interfaces, 211 using RP-based IPsec HA, 214–215 with multiple peer statements, 212–214 VPN3000 Clustering, 227–230 VRFs (VPN Routing and Forwarding Instances), 19 VRRP, RAVPN concentrator HA, 315, 320, 323–326

W-X-Y-Z wildcard preshared keys, 83 X.509 certificates, 86–87 enrollment process, 398, 402 life cycle of, 398, 401 x-auth, 421 xauth extension (IKE), 98–99