Cisco ASA: Received a DELETE PFKey message from IKE

KB ID 0001720

Problem

I was debugging a VPN tunnel today. (From a Fortigate to a Cisco ASAv). I was messing around with the encryption and hashing, when the tunnel fell over. Phase 1 was establishing fine but not Phase 2 (IPSEC). 

I’ve got better skills on the ASA, so that’s where I was debugging;

IPSEC: Received a PFKey message from IKE
IPSEC: Parsing PFKey GETSPI message
IPSEC: Creating IPsec SA
IPSEC: Getting the inbound SPI
IPSEC DEBUG: Inbound SA (SPI 0x00000000) state change from inactive to embryonic
IPSEC: New embryonic SA created @ 0x00007fc98613ea60,
    SCB: 0x85567700,
    Direction: inbound
    SPI      : 0x3B5A332E
    Session ID: 0x00004000
    VPIF num  : 0x00000002
    Tunnel type: l2l
    Protocol   : esp
    Lifetime   : 240 seconds
IPSEC: Received a PFKey message from IKE
IPSEC DEBUG: Received a DELETE PFKey message from IKE for an inbound SA (SPI 0x3B5A332E)
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) destroy started, state embryonic
IPSEC: Destroy current inbound SPI: 0x3B5A332E
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) free started, state embryonic
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) state change from embryonic to dead
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) free completed
IPSEC DEBUG: Inbound SA (SPI 0x3B5A332E) destroy completed

Solution

Google that error and you get some posts about NAT, that we’re  not applicable to me. I took a look on the Fortigate and the only clue there was;

Forti-FW # diagnose vpn tunnel list
list all ipsec tunnel in vd 0
------------------------------------------------------
name=Tunnel-To-SiteB ver=2 serial=1 192.168.100.100:0->192.168.100.111:0 dst_mtu=1500
bound_if=4 lgwy=static/1 tun=intf/0 mode=auto/1 encap=none/512 options[0200]=frag-rfc  run_state=0 accept_traffic=0 overlay_id=0

proxyid_num=1 child_num=0 refcnt=14 ilast=1 olast=782 ad=/0
stat: rxp=0 txp=0 rxb=0 txb=0
dpd: mode=on-demand on=1 idle=20000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
proxyid=Tunnel-To-SiteB proto=0 sa=0 ref=1 serial=2
  src: 0:192.168.1.0/255.255.255.0:0
  dst: 0:172.16.1.0/255.255.255.0:0
run_tally=1

There’s not much I can discern from that either; 

sa=0 There is a mismatch between selectors (or no traffic is being initiated).
sa=1 IPsec SA is matching and there is traffic between the selectors.
sa=2 Only seen during IPsec SA rekey

So I went back to basics and checked the Phase 2 on BOTH, firstly the Fortigate;

Fortigate Phase 2

For the uninitiated: GCM Protocols DON’T require a hashing algorithm, (that’s why you can’t see SHA or MD5 on there), they disappear when a GCM protocol is selected.

Then on the Cisco ASA;

Cisco-ASA(config-ipsec-proposal)# show run crypto ipsec
crypto ipsec ikev2 ipsec-proposal FORTIGATE
 protocol esp encryption aes-gmac-256
 protocol esp integrity null <--Note: This can say anything it gets ignored!

Or if you prefer the ASDM;

Cisco ASA Phase 2 ipsec proposals

THE ANSWER IS STARING YOU/ME IN THE FACE. I just didn’t realise yet, I changed the phase 2 protocols to DES/MD5 and the tunnel came up, I walked up through the protocols and options and discovered what I’d done wrong.

Root Cause: The ASA is set to use AES-GMAC-256 that’s a DIFFERENT PROTOCOL to the AES256GCM configured on the Fortigate! The ASA should be set to AES-GCM-256! (So the Phase 2 proposals didn’t match).

Cisco-ASA(config)# crypto ipsec ikev2 ipsec-proposal FORTIGATE
Cisco-ASA(config-ipsec-proposal)# protocol esp encryption aes-gcm-256
WARNING: GCM\GMAC are authenticated encryption algorithms.esp integrity config is ignored

Or, via ASDM (from the same location as above);

Cisco AES-GCM-256

Problem solved!

Related Articles, References, Credits, or External Links

NA

Author: PeteLong

Share This Post On

Submit a Comment

Your email address will not be published.