How to fix IKEv2 IPSec tunnel: TS_UNACCEPTABLE error is observed in IKE debugs

This article describes the case when there is TS_UNACCEPTABLE coming up during IKE debugs.

Scope

IKEv2 IPSec tunnel on FortiGate.

Solution

When troubleshooting IKEv2 IPSec tunnels, the following error in IKE debugs can be observed:

ike V=root:0:L2L_LESA:4: received create-child response
ike V=root:0:L2L_LESA:4: initiator received CREATE_CHILD msg
ike V=root:0:L2L_LESA:4:L2L_LESA:4719: found child SA SPI 5913fda9 state=3
ike V=root:0:L2L_LESA:4: processing notify type TS_UNACCEPTABLE

Also, in the VPN event logs, the following errors are observed:

status="failure" init="local" exch="CREATE_CHILD" dir="inbound" role="initiator" result="ERROR"

While the error event logs for CREATE_CHILD can be due to many reasons such as Authentication/Encryption algorithms not matching on the two ends, or PFS mismatch, etc. The debugs indicate that the remote end did not find FortiGate’s proposed traffic selectors (TS) acceptable due to a possible mismatch in the traffic selectors on the FortiGate and the remote end.

Ensure that the Traffic selectors are an exact mirror image of each other on the two devices.

A common scenario where this happens is when the other device, where the VPN tunnel terminates, does not support multiple traffic selectors in the same SA.

For example, as of the date of writing this article, Cisco has a feature request open to support multiple traffic selectors under a single Child SA, which is not currently fixed.

Whereas, when creating an IPSec tunnel on the FortiGate using the wizard and specifying all the remote traffic selectors, will result in a configuration requiring a single SA with all of the specified traffic selectors (allowed per the IKEv2 RFC), an example is included below:

This is how it would appear on the CLI:

The fix in this situation would be to either:

Option 1: Use individual TS pairs such that one SA is negotiated for each pair of Traffic Selectors.

For the example above, this would like:

Option 2: If the remote device supports, use 0.0.0.0/0.0.0.0 to 0.0.0.0/0.0.0.0 as the Traffic Selectors.

This simplifies the configuration especially when there are a large number of TS pairs. Routes and policies can be used to restrict and control exactly what networks are accessible along with controlling what services are open on those networks.

Notes:

• For the same issue, depending on the device at the remote end, it can sometimes send different error codes as well, as observed in the debugs, ex: malformed message in IKE_AUTH response (usually indicates key mismatch).
• While this article discusses the issue for IKEv2, the same scenario of multiple traffic selectors in a single SA (default behavior of the FortiGate) being incompatible with other devices can apply to IKEv1 as well. The fix would be the same as discussed above.