cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

690
Views
0
Helpful
3
Replies
Highlighted
Beginner

Curious ISAKMP behavior

I have been trying to figure out a very funny vpn connection between a meraki and an ASA.  Now I am the cisco technician here, and the problem is that two site to site vpns keep on negotiating.  I have xed out the public IP address, but the public IPs for the VPNs are the same.  Then the first VPN seems to be accepting traffic but when it goes to send the traffic it sends the information out of the second VPN connection.  Has anyone ever seen two vpns coming up for the same connection (there is only one vpn configured for this connection on each device).

pfpd2# show isakmp

   Active SA: 2

    Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)

Total IKE SA: 2

1   IKE Peer: XX.XX.XX.41

    Type    : L2L             Role    : responder

    Rekey   : no              State   : MM_ACTIVE

2   IKE Peer: XX.XX.XX.41

    Type    : L2L             Role    : initiator

    Rekey   : no              State   : MM_ACTIVE

Global IKE Statistics

Active Tunnels: 2

Previous Tunnels: 3

In Octets: 8744

In Packets: 81

In Drop Packets: 0

In Notifys: 64

In P2 Exchanges: 2

In P2 Exchange Invalids: 0

In P2 Exchange Rejects: 0

In P2 Sa Delete Requests: 1

Out Octets: 8352

Out Packets: 83

Out Drop Packets: 0

Out Notifys: 124

Out P2 Exchanges: 3

Out P2 Exchange Invalids: 0

Out P2 Exchange Rejects: 0

Out P2 Sa Delete Requests: 2

Initiator Tunnels: 1

Initiator Fails: 0

Responder Fails: 0

System Capacity Fails: 0

Auth Fails: 0

Decrypt Fails: 0

Hash Valid Fails: 0

No Sa Fails: 0

Global IPSec over TCP Statistics

--------------------------------

Embryonic connections: 0

Active connections: 0

Previous connections: 0

Inbound packets: 0

Inbound dropped packets: 0

Outbound packets: 0

Outbound dropped packets: 0

RST packets: 0

Recevied ACK heart-beat packets: 0

Bad headers: 0

Bad trailers: 0

Timer failures: 0

Checksum errors: 0

Internal errors: 0

Everyone's tags (3)
3 REPLIES 3

Curious ISAKMP behavior

Hello James,

Is there any specific reason to have this scenario?

Same protected traffic and same remote peer IP?

If not, I would suggest to create one single crypto map, add the protected traffic and the peer IP and test it again.

Thanks.

Portu.

Beginner

Re: Curious ISAKMP behavior

While there are two crypto maps on is for a seperate tunnel altogether.  This is the same crypto map negotiating two tunnels.  Its really weird.  I think it is something on the meraki side.  Is there any way to stop my side from initiating the vpn negotiation.  I really don't have any control on the other side.

This is not intentional, the meraki initiates negotation, as does the asa, and they both follow through to completion.  The result is two VPN tunnels, and only one vpn to the peer in question is configured in each device.

pfpd2# show run crypto map

crypto map outside_map 1 match address outside_cryptomap_1

crypto map outside_map 1 set peer XX.XX.XX.41

crypto map outside_map 1 set transform-set ESP-3DES-SHA

crypto map outside_map 2 match address outside_2_cryptomap

crypto map outside_map 2 set peer XX.XX.XX.13

crypto map outside_map 2 set transform-set ESP-3DES-SHA

crypto map outside_map interface outside

Re:Curious ISAKMP behavior

Actually there is a max number of ISAKMP connections that the Router will accept from the same peer. As long as they negotiate two different SAs you should be OK.

Now, could you please include the "show crypto ipsec sa peer remote-peer-ip", I'd like to verify the output. There are some VPN devices which do not support more than one SA per tunnel, so they create two tunnels and in this case it seems like the Router is accepting them.

Please share the output.

Thanks.

Sent from Cisco Technical Support Android App

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here