Support Center > Search Results > SecureKnowledge Details
IKEv2 Site to Site VPN instability when tunnel is narrowed Technical Level
Symptoms
  • IKEv2 Site to Site VPN traffic fails for certain ports for the same source and destination when SecureXL is enabled.

  • IKEv2 negotiation is repeated for this peer.

  • Kernel debug shows that the packet is dropped because no Security Association (SA) is found, even though there is a valid SA for the subnet.
    The valid SA is formed:
    [vs_4];[tid_0];[fw4_0];calc_tunnel_instance: Tunnel Params = peer: x.x.x.x, methods: (Tunnel 3DES MD5), IDs: [xxx.xxx.xxx.xxx/xx]<-->[xxx.xxx.xxx.xxx/xx];
    [vs_4];[tid_0];[fw4_0];calc_tunnel_instance: hash 1628888145, instance 0/1;
    [vs_4];[tid_0];[fw4_0];create_new_MSA: MSA for IPsec, will belong to instance 0;
    [vs_4];[tid_0];[fw4_0];create_mspi: --- NEW MSPI === xxx (i: 0) (generated in 1 iteration(s));

    The SA is not found due to the narrowing of selectors. You will see the narrowed IP range/host IP:
    [kern];[tid_0];[SIM-204537923];vpn_ipsec_encrypt: packet needs to be encrypted with mspi xxx;
    [kern];[tid_0];[SIM-204537923];sim_db_get_any_sa: searching sa xxx in table xx;
    [kern];[tid_0];[SIM-204537923];sim_db_get_any_sa: failed to find SA, tab id xx, ret_val -1;
    [kern];[tid_0];[SIM-204537923];vpn_send_outbound_sa_notification: no outbound SA found! mspi=xxx;
    [kern];[tid_0];[SIM-204537923];sim_mgr_nt_start_ex: type=ntNoOutboundSA conn=Empty nt_params_sz=4;
    ...
    [kern];[tid_0];[SIM-204537923];vpn_encrypt: vpn_ipsec_encrypt returns 3;
    [kern];[tid_0];[SIM-204537923];sim (vpn_encrypt): drop due vpn_ipsec_encrypt returns

  • The output of "vpn tu tlist" command shows the following indication for narrowing:
    • If there is narrowing and the local gateway is the initiator, you see the text: * * * Eclipsed * * *
    • If narrowing occurred and the local gateway is the responder, you see the text: * * * Narrow * * *


  • When the initiator of the negotiation requests Traffic Selectors (TS) that is wider than the one the responder is willing to accept, the responder replies with a narrowed range. The final TS is set to the narrowed range. In this case we can see in IKEView difference in TSi/TSr between the request and response messages. If the initiator offers a narrow TS than the one configured on the responder, the TS is also set to this narrowed range. In this case narrowing is not visible in IKEView.
Cause

The Narrowing is an IKEv2 feature where one side narrows the TS (Traffic Selectors - the Encryption Domain​​s proposed for the tunnel) requested by the other side.

Technically, the FW kernel instance that owned the tunnel traps the VPN daemon for generating a specific IPsec SA. If the Narrowing occurs during the IKE negotiation, the created SA may be stored in a different FW instance. This is because the TSs are considered when calculating the designated tunnel instance. Therefore, this FW instance flip can be the root cause of the outage that results from Narrowing.

In another case, SecureXL fails to find encryption keys because of the unnecessary narrowing process and drops the packet.
FW traps VPND to renegotiate the tunnel because of a missing outbound SA message sent by PPAK. 

Possible reasons for Narrowing: 

  • Narrowing of traffic selectors usually happens if some subnet address range fragments are associated with another Security Gateway managed by the same Security Management Server (overlapping).
  • When there is a simple mismatch in VPN configuration with the peer.

Solution
Note: To view this solution you need to Sign In .