IPsec tunnel seems to present wrong IKEv2 proposal

[zachary.quinn]

Thanks in advance for any help you can provide as i am new to IPsec tunnels and inherited this undocumented solution!

We have a Site-To-Site vpn between a Cisco ASA (HQ Site) and Firepower 2140 (Branch Site). The tunnel is configured to use a presharedkey and ikev2 and has been working for a long time until recently. After a power outage (at the ASA end) the tunnel is refusing to re-establish. When I debug crypto ikev2 protocol on the ASA (assuming I am reading it correctly!) I see the incoming connection request from the FTD but the proposal is not what is configured on the FTD. The ASA and the FTD each sit behind Sophos UTM appliances in a firewall sandwich design. So far as I can tell they are fine as internet access at the branch is working, I can see the IPsec request arrive at the ASA and the AnyConnect remote access vpn to the HQ via the ASA is working fine.

HQ ASA Debug:

IKEv2-PROTO-2: Received Packet [From [BranchIP]:500/To [WAN_InterfaceIP]:500/VRF i0:f0]
Initiator SPI : 94B31A5E937BB2C1 - Responder SPI : 0000000000000000 Message id: 0
IKEv2 IKE_SA_INIT Exchange REQUESTIKEv2-PROTO-3: Next payload: SA, version: 2.0 Exchange type: IKE_SA_INIT, flags: INITIATOR Message id: 0, length: 570
Payload contents:
SA Next payload: KE, reserved: 0x0, length: 44
last proposal: 0x0, reserved: 0x0, length: 40
Proposal: 1, Protocol id: IKE, SPI size: 0, #trans: 4 last transform: 0x3, reserved: 0x0: length: 8
type: 1, reserved: 0x0, id: DES
last transform: 0x3, reserved: 0x0: length: 8
type: 2, reserved: 0x0, id: SHA1
last transform: 0x3, reserved: 0x0: length: 8
type: 3, reserved: 0x0, id: SHA96
last transform: 0x0, reserved: 0x0: length: 8
type: 4, reserved: 0x0, id: DH_GROUP_2048_MODP/Group 14
KE Next payload: N, reserved: 0x0, length: 264
DH group: 14, Reserved: 0x0

dc b5 1b f3 78 e2 4e 69 f2 69 4b bf a1 9f 11 ca
bd 7e a4 a1 2e d5 8a 18 9b eb 08 58 32 ab 9e 3b
d7 11 38 39 f4 b6 e3 81 ba 7e 1c dc 76 6d 3e af
f2 f1 4f c5 42 d4 45 5c d2 9c 3c 64 1f 7e 1a b4
06 1b 8e 7c b5 25 d3 6f 95 40 1e d4 fc 18 3c 66
94 e5 42 6d 87 2a 7b 47 6e 1d f5 7e f1 f6 5a fb
70 94 06 26 e6 6f 11 a7 9e fc c6 ac 1f fe 22 92
47 38 e2 df 9d 0c 76 77 52 bc 7f 3d a8 d0 b4 f3
1a c5 5c b4 0d 39 76 cb 49 02 58 ef 4a 3d ba 7c
6c 00 36 3c cb 4d 77 10 aa ba b8 a9 88 97 8e 56
94 db 68 66 69 9f b1 6a 98 63 92 81 76 26 92 b6
09 7e ab ea fa ba d0 61 60 c1 03 fc 39 63 72 08
f2 3a 4f bb 87 84 62 97 c7 88 6f a3 65 94 52 da
79 cf b0 2b 95 8a b2 93 eb 56 c8 39 3f c0 93 dd
77 cf 74 7c db 8a 11 34 58 52 40 4e 1f 95 2d 94
1d 26 bb d0 45 64 4f 8d de 71 b2 5a 30 9a b2 07
N Next payload: VID, reserved: 0x0, length: 68

4f 3a 6d 29 17 80 e1 0a a8 f3 0a fd 98 1c a2 d1
a1 b8 90 5b 03 d8 26 d4 77 d2 b9 b1 6a 8e bd ff
f3 3b 9b 9b 06 24 82 9d 9a e7 98 b1 22 98 96 00
79 63 f0 b7 eb 0e 2e 3d 0c 4e a5 fe 3e 9a 36 4e
IKEv2-PROTO-5: Parse Vendor Specific Payload: CISCO-DELETE-REASON VID Next payload: VID, reserved: 0x0, length: 23

43 49 53 43 4f 2d 44 45 4c 45 54 45 2d 52 45 41
53 4f 4e
IKEv2-PROTO-5: Parse Vendor Specific Payload: (CUSTOM) VID Next payload: NOTIFY, reserved: 0x0, length: 59

43 49 53 43 4f 28 43 4f 50 59 52 49 47 48 54 29
26 43 6f 70 79 72 69 67 68 74 20 28 63 29 20 32
30 30 39 20 43 69 73 63 6f 20 53 79 73 74 65 6d
73 2c 20 49 6e 63 2e
IKEv2-PROTO-5: Parse Notify Payload: NAT_DETECTION_SOURCE_IP NOTIFY(NAT_DETECTION_SOURCE_IP) Next payload: NOTIFY, reserved: 0x0, length: 28
Security protocol id: IKE, spi size: 0, type: NAT_DETECTION_SOURCE_IP

97 34 fd 42 31 52 69 c3 b3 fe 75 33 1b e3 99 e5
11 1f 00 23
IKEv2-PROTO-5: Parse Notify Payload: NAT_DETECTION_DESTINATION_IP NOTIFY(NAT_DETECTION_DESTINATION_IP) Next payload: NOTIFY, reserved: 0x0, length: 28
Security protocol id: IKE, spi size: 0, type: NAT_DETECTION_DESTINATION_IP

b1 b3 0c 31 b8 7b 49 f3 05 8e 06 c6 ec 30 cc c7
7f 0b d5 cf
IKEv2-PROTO-5: Parse Notify Payload: IKEV2_FRAGMENTATION_SUPPORTED NOTIFY(IKEV2_FRAGMENTATION_SUPPORTED) Next payload: VID, reserved: 0x0, length: 8
Security protocol id: Unknown - 0, spi size: 0, type: IKEV2_FRAGMENTATION_SUPPORTED
IKEv2-PROTO-5: Parse Vendor Specific Payload: FRAGMENTATION VID Next payload: NONE, reserved: 0x0, length: 20

40 48 b7 d5 6e bc e8 85 25 e7 de 7f 00 d6 c2 d3

Decrypted packet:Data: 570 bytes
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: IDLE Event: EV_RECV_INIT
IKEv2-PROTO-2: (779): Checking NAT discovery
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: IDLE Event: EV_CHK_REDIRECT
IKEv2-PROTO-5: (779): Redirect check is not needed, skipping it
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: IDLE Event: EV_CHK_CAC
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: IDLE Event: EV_CHK_COOKIE
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: IDLE Event: EV_CHK4_COOKIE_NOTIFY
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: R_INIT Event:EV_VERIFY_MSG
IKEv2-PROTO-2: (779): Verify SA init message
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: R_INIT Event:EV_INSERT_SA
IKEv2-PROTO-2: (779): Insert SA
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: R_INIT Event:EV_GET_IKE_POLICY
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: R_INIT Event:EV_PROC_MSG
IKEv2-PROTO-2: (779): Processing IKE_SA_INIT message
IKEv2-PROTO-5: (779): Failed to verify the proposed policies
IKEv2-PROTO-1: (779): Failed to find a matching policy
IKEv2-PROTO-1: (779): Received Policies:
Proposal 1: DES SHA1 SHA96 DH_GROUP_2048_MODP/Group 14

IKEv2-PROTO-1: (779): Failed to find a matching policy
IKEv2-PROTO-1: (779): Expected Policies:
Proposal 1: AES-GCM-256 AES-GCM-192 AES-GCM-128 SHA256 DH_GROUP_256_ECP/Group 19

Proposal 2: AES-CBC-256 AES-CBC-192 SHA256 SHA1 SHA256 SHA96 DH_GROUP_256_ECP/Group 19 DH_GROUP_2048_MODP_256_PRIME/Group 24 DH_GROUP_1536_MODP/Group 5

IKEv2-PROTO-1: (779): Failed to find a matching policy
IKEv2-PROTO-1: (779):
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: R_INIT Event:EV_NO_PROP_CHOSEN
IKEv2-PROTO-2: (779): Sending no proposal chosen notify
IKEv2-PROTO-5: Construct Notify Payload: NO_PROPOSAL_CHOSENIKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: R_INIT Event: EV_ENCRYPT_MSG
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: R_INIT Event:EV_TRYSEND
(779):
IKEv2-PROTO-2: (779): Sending Packet [To [BranchIP]:500/From [WAN_InterfaceIP]:500/VRF i0:f0]
(779): Initiator SPI : 94B31A5E937BB2C1 - Responder SPI : 0D4AD51E67469A9E Message id: 0
(779): IKEv2 IKE_SA_INIT Exchange RESPONSEIKEv2-PROTO-3: (779): Next payload: NOTIFY, version: 2.0 (779): Exchange type: IKE_SA_INIT, flags: RESPONDER MSG-RESPONSE (779): Message id: 0, length: 36(779):
Payload contents:
(779): NOTIFY(NO_PROPOSAL_CHOSEN)(779): Next payload: NONE, reserved: 0x0, length: 8
(779): Security protocol id: IKE, spi size: 0, type: NO_PROPOSAL_CHOSEN
(779):
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: INIT_DONE Event: EV_FAIL
IKEv2-PROTO-2: (779): Failed SA init exchange
IKEv2-PROTO-1: (779): Initial exchange failed
IKEv2-PROTO-1: (779): Initial exchange failed
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: EXIT Event: EV_ABORT
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: EXIT Event: EV_CHK_PENDING_ABORT
IKEv2-PROTO-5: (779): SM Trace-> SA: I_SPI=94B31A5E937BB2C1 R_SPI=0D4AD51E67469A9E (R) MsgID = 00000000 CurState: EXIT Event: EV_UPDATE_CAC_STATS
IKEv2-PROTO-2: (779): Abort exchange

So if I am reading this correctly the FTD is proposing Proposal 1: DES SHA1 SHA96 DH_GROUP_2048_MODP/Group 14 but this is not what I am expecting from the config below.

In the FTD GUI VPN Topology we have the following:

Topology - Point to Point
IKEv1 - UNchecked
IKEv2 - checked

IKE Tab:
IKEv2 Settings Policy - HQ-VPN
Auth Type - Preshared Manual Key
Key is set in both fields

IPsec Tab:
Crypto Map Type - Static
IKEv2 Mode - Tunnel
Transform Sets IKEv2 Proposals - SHA-256
Enable Reverse Route Injection- Checked
Enable PFS - Checked
Modulus Group - 19
Lifetime Duration - 28800
Lifetime Size - 4608000

Advanced Tab:
Keepalive Messages traversal - checked
Bypass Access Control - UNchecked
Use certificate map configured in endpoints to determine the tunnel - UNchecked
Use certificate OU field to determine the tunnel - checked
Use IKE Identity to determine the tunnel - checked
Use peer IP to determine the tunnel - checked

Looking at the IKEv2 Policy HQ-VPN in the Gui:

Priority: BLANK
Lifetime: 86400
Integrity Algorithms - SHA256
Encryption Algorithms - AES-192, AES-256
PRF Algorithms - SHA256
DH Group - 19, 21

However I am not seeing this HQ-VPN policy in the running-config output. Should this policy be displayed in the running config? Should the priority be set? Does it matter if there is only the one policy configured? Am I correct in that Priority 1 means use first?

FTD Cli Running Config

crypto ipsec ikev2 ipsec-proposal CSM_IP_2
protocol esp encryption des
protocol esp integrity sha-256
crypto ipsec security-association pmtu-aging infinite
crypto map CSM_Outside_map 1 match address CSM_IPSEC_ACL_2
crypto map CSM_Outside_map 1 set pfs group19
crypto map CSM_Outside_map 1 set peer xxx.xxx.xxx.xxx
crypto map CSM_Outside_map 1 set ikev2 ipsec-proposal CSM_IP_2
crypto map CSM_Outside_map 1 set reverse-route
crypto map CSM_Outside_map interface Outside
crypto ca trustpool policy
crypto ikev2 policy 3
encryption des
integrity sha
group 14
prf sha
lifetime seconds 86400
crypto ikev2 enable Outside

group-policy .DefaultS2SGroupPolicy internal
group-policy .DefaultS2SGroupPolicy attributes
vpn-idle-timeout 30
vpn-idle-timeout alert-interval 1
vpn-session-timeout none
vpn-session-timeout alert-interval 1
vpn-filter none
vpn-tunnel-protocol ikev1 ikev2
dynamic-access-policy-record DfltAccessPolicy
tunnel-group xxx.xxx.xxx.xxx type ipsec-l2l
tunnel-group xxx.xxx.xxx.xxx general-attributes
default-group-policy .DefaultS2SGroupPolicy
tunnel-group xxx.xxx.xxx.xxx ipsec-attributes
ikev2 remote-authentication pre-shared-key *****
ikev2 local-authentication pre-shared-key *****

To me it looks like the FTD is proposing the settings in crypto ikev2 policy 3. Is this a default policy? I can only see our HQ-VPN policy in the gui but it is not showing in the cli running config.

Any pointers in how to troubleshoot this further and ultimately fix the tunnel will be greatly appreciated.

TIA
Zac

[Rob Ingram]

@zachary.quinn seems like the FTD is sending DES encryption algorithm to the ASA. If the FTD is not licensed for the strong crypto then you are restricted to DES.

Is the FMC regsitered for smart licensing?

Did you get an error when creating the VPN topology? If you go to the VPN topology, what IKE/IPSec settings are listed, provide a screenshot.

[zachary.quinn]

Hi Rob, thanks for your reply.

As I mentioned this is an inherited system so I did not create the topology. How do I check the FTD for strong crypto and smart licencing? I will have an engineer at the remote site tomorrow so will be able to check then.

As for the available algorithms the list for 'Integrity' is MD5, SHA, SHA512, SHA256, SHA384 and NULL. Only SHA256 is selected. For 'Encryption' the list is AES, AES-256, DES, 3DES, AES-192, AES-GCM, AES-GCM-192, AES-GCM-256 and NULL. Only AES-192 and AES-256 are selected. 'PRF' is the same as Integrity. Diffie-Hellaman groups are 1,2,5,14,15,16,19,20 and 21. Only 19 and 21 are selected.

[Rob Ingram · Accepted solution]

@zachary.quinn 

https://www.cisco.com/c/en/us/support/docs/security/firepower-management-center/215838-fmc-and-ftd-smart-license-registration-a.html

Why do you get the error 'Strong crypto (i.e encryption algorithm greater than DES) for VPN topology s2s is not supported'?

This error is displayed when the FMC uses Evaluation Mode or Smart License Account is not entitled to a strong encryption license. Verify if the FMC is registered to the License Authority and Allow export-controlled functionality on the products registered with this token is enabled. If the Smart Account is not allowed to use a strong encryption license, you are not allowed to deploy VPN Site-to-Site configuration with ciphers stronger than DES.

[zachary.quinn]

Are there any CLI commands we can use to check the licencing side? There is no FMC in this deployment so everything is done on the device. I am now stongly suspicious that it may have lapsed.

[zachary.quinn]

So it turns out our device has been unregistered. Working with TAC to find out how and why but without a valid registration the access to strong encryption is disabled and therefore the tunnel won't re-establish. Thanks for pointing me in the right direction.

Best regards,

Zac

[Marius Gunnerud]

Do you have access to the ASA and its configuration?

I suspect that the ASA is configured differently.  In any case, I would look at this as a great opportunity to get away from the DES configuration that the FTD has.