Description
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 (match the network as well as the subnet mask).
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.
In the example shown above, this would look like the following:
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 or AUTHENTICATION_FAILED in IKE_AUTH response (usually indicates key mismatch or peer ID issues), or NO_PROPOSAL_CHOSEN in response to CREATE_CHILD.
- This is also often the root cause when seeing a phase2 traffic selector to be up as well as down (by the same name). This is because the phase2 SA configured on the FortiGate does not match or is incompatible with the remote end (and hence stays down). However, when the remote proposes the phase2 selectors (as a subset of what is configured on the FortiGate, the phase2 comes up, and hence in the IPSec monitor, multiple entries are visible by the same phase2 name, with one SA down and other(s) up.
- 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.
Related articles:
IPsec VPN: Cannot access multiple remote subnets behind a Cisco PiX firewall
