Renegotiating LAN-to-LAN Configurations Between Cisco VPN Concentrators, Cisco IOS, and PIX Devices

Available Languages

Download Options

  • PDF     (13.5 KB)
    View with Adobe Reader on a variety of devices
Updated:February 2, 2006
Document ID:14111

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

This document reports the lab test results of IP Security (IPSec) LAN-to-LAN tunnel renegotiation between different Cisco VPN products in various scenarios, such as VPN device reboot, rekey, and the manual termination of IPSec security associations (SAs).

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco IOS® Software Release 12.1(5)T8

  • Cisco PIX Software Release 6.0(1)

  • Cisco VPN 3000 Concentrator software version 3.0(3)A

  • Cisco VPN 5000 Concentrator software version 5.2(21)

The IP traffic used in this test is bi-directional Internet Control Message Protocol (ICMP) packets between hostA and hostB.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Network Diagram

This is a concept diagram of the test bed.

renegotiate.gif

VPN devices represent a Cisco IOS router, a Cisco Secure PIX Firewall, a Cisco VPN 3000 Concentrator or a Cisco VPN 5000 Concentrator.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Test Scenarios

Three common scenarios were tested. The following is a brief definition of the test scenarios:

  • Manual termination of IPSec SAs—User logs on to the VPN devices and manually clears the IPSec SAs using the command line interface (CLI) or the graphical user interface (GUI).

  • Rekey—Normal IPSec phase I and phase II rekey when defined lifetime expires. In this test, the two VPN termination devices have the same phase I and phase II lifetime configured.

  • VPN device reboot—Either end of the VPN tunnel termination points was rebooted to simulate service outage.

Note: For LAN-to-LAN tunnels where the VPN 5000 Concentrator is used, the concentrator is configured using the MAIN mode and tunnel responder.

Test Results

Setup Manually Termination of IPSec SAs Rekey VPN Device Reboot
IOS to PIX
  • Tunnel reestablished after phase I or phase II SA is cleared on either side
  • Test traffic works
  • Test traffic still works after phase I or phase II rekey
  • With IKE keepalive enabled on both devices, tunnel reestablished
  • Test traffic1 works after tunnel recovered
IOS to VPN 3000
  • Tunnel reestablished after phase I or phase II SA is cleared on either side
  • Test traffic works
  • Test traffic still works after phase I or phase II rekey
  • With IKE keepalive enabled on both devices, tunnel reestablished
  • Test traffic1 works after tunnel recovered
IOS to VPN 5000
  • On IOS:
    • Test traffic still works after phase II SA is cleared
    • VPN tunnel goes down when phase I SA is cleared
    • Test traffic stops working
  • On VPN 5000:
    • Tunnel fails to recover after manually clearing the SA
    • Must clear both phase I and phase II SA on IOS to reestablish tunnel
  • Test traffic still works after phase II rekey
  • Phase I rekey brought down the tunnel
  • Test traffic stops working
  • Must manually clear SAs to bring the tunnel back
  • Tunnel fails to recover after reboot either VPN device (with bi-directional test traffic)
  • Test traffic stops working
  • Must manually clear the SA on the device which was not rebooted to bring the tunnel back
PIX to VPN 3000
  • Tunnel reestablished after phase I or phase II SA is cleared on either side
  • Test traffic works
  • Test traffic still works after phase I or phase II rekey
  • Test traffic1 works after tunnel recovered
  • With Dead Peer Detection (DPD)2 (enabled by default), tunnel reestablished
PIX to VPN 5000
  • On PIX:
    • Test traffic still works after phase II SA is cleared
    • VPN tunnel went down when phase I SA is cleared
    • Test traffic stops working
  • On VPN 5000:
    • Tunnel fails to recover after manually clears SA
    • Must clear both phase I and phase II SA on PIX to reestablish tunnel
  • Test traffic still works after phase II rekey
  • Phase I rekey brought down the tunnel
  • Test traffic stops working
  • Must manually clear SAs to bring the tunnel back
  • Tunnel fails to recover after reboot either VPN device (with bi-directional test traffic)
  • Test traffic stops working
  • Must manually clear the SA on the device which was not rebooted to bring the tunnel back
VPN 3000 to VPN 5000
  • On VPN 3000:
    • Tunnel is recovered after manually clear the session
    • Traffic still works
  • On VPN 5000:
    • Tunnel fails to recover after manually clear the tunnel
    • Test traffic stops working
    • Must clear SA on VPN 3000 to reestablish tunnel
  • Test traffic still works after either phase I or phase II rekey
  • Tunnel fails to recover after reboot of either VPN device (with bi-directional test traffic)
  • Test traffic stops working
  • Must manually clear the SA on the device which was not rebooted to bring the tunnel back

1 As described above, the test traffic used is bi-directional ICMP packets between hostA and hostB. In the VPN device reboot test, unidirectional traffic is also tested to simulate the worst case scenario (where traffic is only from the host behind the VPN device which is not rebooted to the VPN device which is rebooted). As can been seen from the table, with IKE keepalive or with DPD protocol, the VPN tunnel can be recovered from the worst case scenario.

2 DPD is part of the Unity protocol. Currently this feature is only available on the Cisco VPN 3000 Concentrator with software version 3.0 and above and on the PIX Firewall with software version 6.0(1) and above.

Related Information

Revision History

Revision Publish Date Comments
1.0
02-Feb-2006
Initial Release

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

This Document Applies to These Products