ASA L2L with secondary peer

Unanswered Question
May 28th, 2010

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

!

object-group network cryptomap_100_trusted_local
network-object host 34.56.78.90

!

global (RAS) 2 34.56.78.90

nat (BP) 2 access-list SNAT

!

crypto map ras_map 100 match address RAS_cryptomap_100
crypto map ras_map 100 set peer 12.34.56.78 23.45.67.89
crypto map ras_map 100 set transform-set ESP-3DES-MD5
crypto map ras_map 100 set nat-t-disable
crypto map ras_map interface RAS

!

tunnel-group 12.34.56.78 type ipsec-l2l
tunnel-group 12.34.56.78 ipsec-attributes
pre-shared-key <removed>
!

tunnel-group 23.45.67.89 type ipsec-l2l
tunnel-group 23.45.67.89 ipsec-attributes
pre-shared-key <removed>

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
hdashnau Fri, 05/28/2010 - 10:51

You need to run debugs to see why the first peer is not coming up or (if it was up and working before) why it is dropping:

debug cry isa 127

debug cry ipsec 127

-heather

David Niemann Fri, 05/28/2010 - 11:03

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 12.34.56.78 (user= 12.34.56.78) to 99.99.99.99 that failed anti-replay checking.

David Niemann Mon, 02/14/2011 - 11:11

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?

Actions

This Discussion