Monday, July 2, 2018


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
  •    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 and 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 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
     ^      ^
=(  @  @ )=
     /  \

No comments:

Post a Comment