I'm having an issue with using a secondary peer on a L2L tunnel on ASA 8.2(2)4. The tunnel comes up fine, but I'm seeing it sometimes decide to sporadically switch to the secondary peer. I read something about possibly needing to specify the connection type as originate-only, but then the IPSec SA never builds for either peer. As soon as I change it back to bidirectional the IPSec SA builds. Traffic should always be originating from my side. Applicable parts of my config are below.
access-list RAS_cryptomap_100 extended permit ip object-group cryptomap_100_trusted_local any
access-list SNAT extended permit ip 10.67.74.0 255.255.255.0 any
I am currently not experiencing the issue. I removed the secondary peer and let the tunnel build and settle down and then added it back. It has not repeated the issue yet. I am, however, seeing the below in the logs currently for the primary peer.
May 28 2010 13:59:06 oraappvpn02 : %ASA-4-402119: IPSEC: Received an ESP packet (SPI= 0x8530B4A1, sequence number= 0x6862B) from 184.108.40.206 (user= 220.127.116.11) to 18.104.22.168 that failed anti-replay checking.
This has crept again and seems to coincide with when the peers change. When the primary peer has an issue and the ASA connects to the secondary peer, the tunnel appears to have some instability. In the logs I see lots of entries from both peers. Could it be that the primary is trying to reestablish the tunnel and is causing the ASA to have issues?
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...