IKEV2_NOTIFY_TS_UNACCEPTABLE

IKEv2  has the means to  help diagnosed trafficSelectors mismatches. In this example we have a simple IKEv2  gateway on a PANOS device and using the NCP client I will demonstrate how.


The NCP has been configured with the following

•    local.identity blog
•    static address  192.168.127.12
•    split-tunnel networks ( one of which is not allowed by the PANOS  ipsec cfg  we will explore more later )
•     PSK ( no xauth or EAP )
•     PANOS gw is confgured only for 192.168.127.0/24 and 192.168.12.0/24 for the remote/local-subnet

Here's what the PANOS device expects  in a simple screenshot for the ipsec  tunnel

 Here's our NCPclient  configurations;

Here's what happens if the Initiator and Responder matches on the  traffic-selectors  ( take note of the TSI and TSR values )

So the  TSI ( initiator ) and TSR ( responder )  values are indicated for the IPSEC-SA.  If any party  provides traffic-selectors that are not allowed,  you will get a IKEV2_NOTIFY_TS_UNACCEPTABLE message similar to the following;

{ NCP client logs }

On the PAN device we have the following type of vpn logtypes that shows IPSEC-SA negotiations




How I force a bad  TS  was in my NCP cfg,  "  I have split-tunnel enabled with a proxyid that the PANOS device was not expecting  "

( example the network prefix  192.168.122.0/24 is not configured for the proxy-IDs  in the paloalto device  for this ipsec-tunnel )

With IKEv1 and a cisco ASA for example, this would  create a ESP payload error when TS values don't match. So always inspect the  IKEv2 message in a debug to look for mis-matches in TS values

NSE ( network security expert) and Route/Switching Engineer

kfelix  -----a----t---- socpuppets ---dot---com

     ^      ^

=(  @  @ )=

         o

     /  \