Common IKEv2 ISAKMP Negotiation errors (and how to fix them) – Part 1

There are an abundance of ISAKMP errors that can occur during tunnel negotiation and this is widely due to the fact that the RFC is not very restrictive, it allows for a wide range of configurations and allows the peers to work it out amongst themselves.
Over multiple posts I’m going to cover most of the errors that I’ve seen out in the wild at troubleshooting IKEv2 tunnels with Strongswan, Cisco Meraki, Fortinet and many other vendors, and their likely/guaranteed fix.

It’s important to note that logging in ISAKMP exchanges are significantly different whether or not you are the responder, or the initiator of a tunnel. The RFC states that the Responder does not have to specifically say why they are denying a tunnel, they can give a generic NOTIFY reply with an error that could have multiple root causes. When investigating IKEv2 tunnel formation issues, try to always be the responder of the tunnel so that you can see exactly what you’re being sent, and why you device is rejecting the tunnel.

Most of these tests are done with Strongswan, but apply to any IKEv2 peer, including Cisco Meraki, Fortinet, Palo Alto, and more.

If you’re just here to find a clean set of config that will work with an Enterprise device (such as forming an IKEv2 tunnel to Cisco Meraki), then check out this blog post – Forming an IKEv2 tunnel with a Cisco Meraki MX using Strongswan – swanctl.

NO_PROPOSAL_CHOSEN

Likely one of the most common errors – NO_PROPOSAL_CHOSEN can occur in both Phase 1 and Phase 2, and essentially means that the device did not accept the Phase 1 or Phase 2 proposals that were sent.

This can be such a wide range of errors that it’s hard to accurately pinpoint. Some examples include, but are not limited to:

– Encryption Settings (Phase 1/2)
– Authentication Settings (Phase 1/2)
– Configured IKE Version

In short, “check the basics” – make sure that all of the expected configuration matches on both sides – this error is usually that simple.

Below, you can see the difference in logging – the initiator just receives a NO_PROPOSAL_CHOSEN, as seen below, however, the Responder can see what was sent, and the reason why we’re sending a NO_PROPOSAL_CHOSEN – in this case, it’s a mismatch in ENCRYPTION_ALGORITHIM (AES_CBC_128 was configured instead of the proposed AES_CBC_256).

root@jburst:~$ swanctl -i -i Phase1-Strongswan -c Phase2-Strongswan
[IKE] initiating IKE_SA Phase1-Strongswan[8] to 192.168.10.11
[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
[NET] sending packet: from 192.168.60.5[500] to 192.168.10.11[500] (464 bytes)
[NET] received packet: from 192.168.10.11[500] to 192.168.60.5[500] (36 bytes)
[ENC] parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
[IKE] received NO_PROPOSAL_CHOSEN notify error

Jun 20 11:34:21 16[CFG] <4> looking for an IKEv2 config for 192.168.10.11…192.168.60.5
Jun 20 11:34:21 16[CFG] <4> candidate: 192.168.10.11…192.168.60.5, prio 3100
Jun 20 11:34:21 16[CFG] <4> found matching ike config: 192.168.10.11…192.168.60.5 with prio 3100
Jun 20 11:34:21 16[IKE] <4> local endpoint changed from 0.0.0.0[500] to 192.168.10.11[500]
Jun 20 11:34:21 16[IKE] <4> remote endpoint changed from 0.0.0.0 to 192.168.60.5[500]
Jun 20 11:34:21 16[IKE] <4> 192.168.60.5 is initiating an IKE_SA
Jun 20 11:34:21 16[IKE] <4> IKE_SA (unnamed)[4] state change: CREATED => CONNECTING
Jun 20 11:34:21 16[CFG] <4> selecting proposal:
Jun 20 11:34:21 16[CFG] <4> no acceptable ENCRYPTION_ALGORITHM found
Jun 20 11:34:21 16[CFG] <4> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
Jun 20 11:34:21 16[CFG] <4> configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
Jun 20 11:34:21 16[CFG] <4> looking for IKEv2 configs for 192.168.10.11…192.168.60.5
Jun 20 11:34:21 16[CFG] <4> candidate: 192.168.10.11…192.168.60.5, prio 3100
Jun 20 11:34:21 16[CFG] <4> received supported signature hash algorithms: sha256 sha384 sha512 identity
Jun 20 11:34:21 16[IKE] <4> received proposals unacceptable
Jun 20 11:34:21 16[ENC] <4> added payload of type NOTIFY to message
Jun 20 11:34:21 16[ENC] <4> order payloads in message
Jun 20 11:34:21 16[ENC] <4> added payload of type NOTIFY to message
Jun 20 11:34:21 16[ENC] <4> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
Jun 20 11:34:21 16[ENC] <4> generating NOTIFY payload finished
Jun 20 11:34:21 16[NET] <4> sending packet: from 192.168.10.11[500] to 192.168.60.5[500] (36 bytes)
Jun 20 11:34:21 04[NET] sending packet: from 192.168.10.11[500] to 192.168.60.5[500]
Jun 20 11:34:21 16[MGR] <4> checkin and destroy IKE_SA (unnamed)[4]
Jun 20 11:34:21 16[IKE] <4> IKE_SA (unnamed)[4] state change: CONNECTING => DESTROYING

AUTHENTICATION_FAILED

AUTHENTICATION_FAILED errors are usually related to PSK, Remote ID or Local ID mismatches. The error can sometimes show differently, depending on what the remote vendor is, or if the Remote ID is a hostname instead of an IP address. Some common errors that can all be troubleshot with the same technique would be:

IDir ‘x.x.x.x’ does not match to ‘y.y.y.y’

“no shared key found for”

An example below, shows that my device receives an AUTHENTICATION_FAILED error, and checking from the Responders logs, we can see that a remote ID is configured that we don’t have set:

root@jburst:~$ swanctl -i -i Phase1-Meraki -c Phase2-Meraki
[IKE] initiating IKE_SA Phase1-Meraki[11] to 192.168.10.11
[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
[NET] sending packet: from 192.168.60.5[500] to 192.168.10.11[500] (464 bytes)
[NET] received packet: from 192.168.10.11[500] to 192.168.60.5[500] (472 bytes)
[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
[IKE] authentication of '192.168.60.5' (myself) with pre-shared key
[IKE] establishing CHILD_SA Phase2-Meraki{24}
[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
[NET] sending packet: from 192.168.60.5[4500] to 192.168.10.11[4500] (348 bytes)
[NET] received packet: from 192.168.10.11[4500] to 192.168.60.5[4500] (76 bytes)
[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
[IKE] received AUTHENTICATION_FAILED notify error
initiate failed: establishing CHILD_SA 'Phase2-Meraki' failed

Jun 20 11:39:51 15[IKE] <8> local endpoint changed from 192.168.10.11[500] to 192.168.10.11[4500]
Jun 20 11:39:51 15[IKE] <8> remote endpoint changed from 192.168.60.5[500] to 192.168.60.5[4500]
Jun 20 11:39:51 15[CFG] <8> looking for peer configs matching 192.168.10.11[192.168.10.11]…192.168.60.5[192.168.60.5]
Jun 20 11:39:51 15[CFG] <8> no matching peer config found
Jun 20 11:39:51 15[IKE] <8> peer supports MOBIKE
Jun 20 11:39:51 15[ENC] <8> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
Jun 20 11:39:51 15[NET] <8> sending packet: from 192.168.10.11[4500] to 192.168.60.5[4500] (76 bytes)
Jun 20 11:39:51 15[MGR] <8> checkin and destroy IKE_SA (unnamed)[8]
Jun 20 11:39:51 15[IKE] <8> IKE_SA (unnamed)[8] state change: CONNECTING => DESTROYING
Jun 20 11:39:51 04[NET] sending packet: from 192.168.10.11[4500] to 192.168.60.5[4500]

This line is saying that the remote peer is sending us the combination of 192.168.10.11 (Local ID 192.168.10.11) and 192.168.50.5 for us (192.168.60.5 as Remote ID)

In this case, I have the remote ID set to 192.168.60.50, not 192.168.60.5 – so we have no matching config for a remote ID of 192.168.60.5, and deny the tunnel:.

root@raspberrypi:~# cat /etc/swanctl/swanctl.conf | grep -A1 "remote {"
remote {
id=192.168.60.50

In another example, I fix the remote ID issue but cause a PSK mismatch to occur. The first peer gets the exact same AUTHENTICATION_FAILED log, but on my own logs, you can now see:

Jun 20 11:44:14 15[CFG] <9> looking for peer configs matching 192.168.10.11[192.168.10.11]…192.168.60.5[192.168.60.5]
Jun 20 11:44:14 15[CFG] <9> candidate "Phase1-Meraki", match: 20/20/3100 (me/other/ike)
Jun 20 11:44:14 15[CFG] selected peer config 'Phase1-Meraki'
Jun 20 11:44:14 15[IKE] tried 1 shared key for '192.168.10.11' - '192.168.60.5', but MAC mismatched
Jun 20 11:44:14 15[IKE] peer supports MOBIKE
Jun 20 11:44:14 15[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
Jun 20 11:44:14 15[NET] sending packet: from 192.168.10.11[4500] to 192.168.60.5[4500] (76 bytes)
Jun 20 11:44:14 15[MGR] checkin and destroy IKE_SA Phase1-Meraki[9]
Jun 20 11:44:14 15[IKE] IKE_SA Phase1-Meraki[9] state change: CONNECTING => DESTROYING
Jun 20 11:44:14 04[NET] sending packet: from 192.168.10.11[4500] to 192.168.60.5[4500]

We tried to use the PSK that we had configured, and there was a mismatch, and as such, the tunnel fails to form.

This is another example where it’s significantly more helpful to get the ISAKMP exchange from the Responders perspective – the Initiator only sees AUTHENTICATION_FAILED in both cases, and this is widely unhelpful.

TS_UNACCEPTABLE

TS_UNACCPETABLE specifically refers to a subnet mismatch between the two peers. This has a lot of variance depending on individual vendor’s configuration. Generally, IKEv2 prefer an identical subnet match, or otherwise a subset of the subnets to be chosen.

For example, if I have 10.0.0.0/23 configured, and the initiator sends me 10.0.0.0/24, most IKEv2 implmentations will form the tunnel with 10.0.0.0/24 instead, since it is a subset of 10.0.0.0/23. However, if the initiator tries to form a tunnel with a subnet that does not exist on the Responder, we’ll generally have issues (also depending on implimentation).

In this example, we see the TS_UNACCEPTABLE when we Initiate. Checking on the Responder, we can see that we received 10.68.69.0/24, but we have 10.68.68.0/24 configured locally, so this is unacceptable, and the tunnel does not form.

root@jburst:~$ swanctl -i -i Phase1-Meraki -c Phase2-Meraki
[IKE] initiating IKE_SA Phase1-Meraki[18] to 192.168.10.11
[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
[NET] sending packet: from 192.168.60.5[500] to 192.168.10.11[500] (464 bytes)
[NET] received packet: from 192.168.10.11[500] to 192.168.60.5[500] (472 bytes)
[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
[IKE] authentication of '192.168.60.5' (myself) with pre-shared key
[IKE] establishing CHILD_SA Phase2-Meraki{33}
[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
[NET] sending packet: from 192.168.60.5[4500] to 192.168.10.11[4500] (348 bytes)
[NET] received packet: from 192.168.10.11[4500] to 192.168.60.5[4500] (140 bytes)
[ENC] parsed IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(NO_ADD_ADDR) N(TS_UNACCEPT) ]
[IKE] authentication of '192.168.10.11' with pre-shared key successful
[IKE] peer supports MOBIKE
[IKE] IKE_SA Phase1-Meraki[18] established between 192.168.60.5[192.168.60.5]…192.168.10.11[192.168.10.11]
[IKE] scheduling reauthentication in 12409s
[IKE] maximum IKE_SA lifetime 13849s
[IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built
[IKE] failed to establish CHILD_SA, keeping IKE_SA
initiate failed: establishing CHILD_SA 'Phase2-Meraki' failed

Jun 20 11:52:42 08[IKE] maximum IKE_SA lifetime 15787s
Jun 20 11:52:42 08[CFG] looking for a child config for 10.68.69.0/24 === 192.168.12.0/24
Jun 20 11:52:42 08[CFG] proposing traffic selectors for us:
Jun 20 11:52:42 08[CFG] 10.68.68.0/24
Jun 20 11:52:42 08[IKE] traffic selectors 10.68.69.0/24 === 192.168.12.0/24 unacceptable
Jun 20 11:52:42 08[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jun 20 11:52:42 08[ENC] generating IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(NO_ADD_ADDR) N(TS_UNACCEPT) ]

Conclusion

We’ll continue to look through Phase 1 and Phase 2 IKSAMP IKEv2 errors in following blog posts, but this begins to tackle the more common problems – and we’ll dive into more errors in future posts as well.

NO_PROPOSAL_CHOSEN, AUTHTNETICATION_FAILED and TS_UNACCEPTABLE account for a significant amount of IKEv2 tunnel formation problems.

Was your error not covered? Check out Part 2 – Common IKEv2 ISAKMP Negotiation errors (and how to fix them) – Part 2