ASA Tunnel stopped working "Duplicate first packet detected"

[Max Kalachov]

Hi guys,

I have a VPN tunnel that stopped working after a couple of years, without any changes made to it or the firewalls.

I'm running a simple S2S VPN between two ASA firewalls,  Side A (AAA.AAA.AAA.AAA) and Side B (BBB.BBB.BBB.BBB)

Today it stopped working and on one of the sides I see the following log:

5 May 23 2021	22:59:47 713202	IP = AAA.AAA.AAA.AAA, Duplicate first packet detected.  Ignoring packet.

I tried to reset the pre-shared-key on both sides, reboot (including gracefully) the FW on Side A, and tried to rebuild the VPN on both sides (via ASDM, but including deleting remains of the config from CLI). The same result each time, I see the same log.

-- FW A current config --

crypto map outside_map 2 match address outside_cryptomap_1
crypto map outside_map 2 set pfs 
crypto map outside_map 2 set peer BBB.BBB.BBB.BBB 
crypto map outside_map 2 set ikev1 transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5

group-policy GroupPolicy_BBB.BBB.BBB.BBB internal
group-policy GroupPolicy_BBB.BBB.BBB.BBB attributes
 vpn-tunnel-protocol ikev1
 
tunnel-group BBB.BBB.BBB.BBB type ipsec-l2l
tunnel-group BBB.BBB.BBB.BBB general-attributes
 default-group-policy GroupPolicy_BBB.BBB.BBB.BBB
tunnel-group BBB.BBB.BBB.BBB ipsec-attributes
 ikev1 pre-shared-key *****
 ikev2 remote-authentication pre-shared-key *****
 ikev2 local-authentication pre-shared-key *****

access-list outside_cryptomap_1 extended permit ip object-group DM_INLINE_NETWORK_3 object-group DM_INLINE_NETWORK_7

-- FW B current config --

crypto map WAN_map 2 match address WAN_cryptomap_1
crypto map WAN_map 2 set pfs 
crypto map WAN_map 2 set peer AAA.AAA.AAA.AAA 
crypto map WAN_map 2 set ikev1 transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5

group-policy GroupPolicy_AAA.AAA.AAA.AAA internal
group-policy GroupPolicy_AAA.AAA.AAA.AAA attributes
 vpn-tunnel-protocol ikev1 

tunnel-group AAA.AAA.AAA.AAA type ipsec-l2l
tunnel-group AAA.AAA.AAA.AAA general-attributes
 default-group-policy GroupPolicy_AAA.AAA.AAA.AAA
tunnel-group AAA.AAA.AAA.AAA ipsec-attributes
 ikev1 pre-shared-key *****
 ikev2 remote-authentication pre-shared-key *****
 ikev2 local-authentication pre-shared-key *****

access-list WAN_cryptomap_1 extended permit ip object-group DM_INLINE_NETWORK_25 object-group DM_INLINE_NETWORK_35

Any ideas or suggestions?

P.S I hope I added all relevant configurations (except NAT) these days I almost not working with the CLI.

A little update, once I saw a few more logs.

6	May 23 2021 23:28:56 713905	Group = AAA.AAA.AAA.AAA, IP = AAA.AAA.AAA.AAA, P1 Retransmit msg dispatched to MM FSM
5	May 23 2021 23:28:56 713201	Group = AAA.AAA.AAA.AAA, IP = AAA.AAA.AAA.AAA, Duplicate Phase 1 packet detected.  Retransmitting last packet.
5	May 23 2021 23:28:48 713202	IP = AAA.AAA.AAA.AAA, Duplicate first packet detected.  Ignoring packet.

If I run "show crypto isa" on both firewalls I see the following:

Side A

4   IKE Peer: 65.39.245.132
    Type    : user            Role    : initiator 
    Rekey   : no              State   : MM_WAIT_MSG2

Side B

4   IKE Peer: 69.67.250.174
    Type    : user            Role    : responder 
    Rekey   : no              State   : MM_WAIT_MSG3

Thank you

Regards,

Max

[marce1000]

 - Check this thread for hints :

              https://community.cisco.com/t5/vpn/error-713201-duplicate-phase-packet-detected/td-p/1647720

 M.

[Max Kalachov]

Thank you for the link. The only hint there, that something is blocking the connectivity or particular VPN packets. I've seen that on other topics where the "crypto asakmp" is stuck on MM_WAIT_MSG2 and MM_WAIT_MSG3.

In my case, both ASA are the gateways of the networks and connected directly to upstream providers. However, yesterday I noticed an additional behavior that wasn't there at the time I created this post. The ICMP connectivity between WAN IP addresses (only) of both firewalls was affected. So basically firewalls could not ping each other from the WAN interface to the WAN interface, however, all other connectivity remained the same, including connectivity to NAT addresses (different external IPs) behind the same WAN interfaces.

Later on, the connectivity restored, and the tunnel started working again without any intervention from my side. So I'm checking with one of our upstream providers, and they are checking with their peer (the next hop to our network).

Thank you

Max