Knowledge Search


×
 

[SRX] IPSEC VPN IKEv2 with dynamic end points fail to get established or renew

  [KB31306] Show Article Properties


Summary:

An implementation of IPSEC with IKEv2 and several gateways using DEP (dynamic end points) can face instability during VPN establishment or renewing.

Symptoms:

Some IKEv2 VPNs experience problems and may not come up. The following logs are seen in the KMD debug level 15:

May 10 09:12:43.107 SRX kmd[5136]: IKE negotiation failed with error: Authentication failed. IKE Version: 2, VPN: VPN_A Gateway: GW_A, Local: x.y.w.z/500, Remote: a.b.c.d/500, Local IKE-ID: Not-Available, Remote IKE-ID: Not-Available, VR-ID: 0
May 10 09:12:43.107 SRX kmd[5136]: IKE Phase-2: Negotiations failed. Local gateway: x.y.w.z, Remote gateway: a.b.c.d

The IPs in the logs are showing the correct IP of the VPN peers that are trying to get connected [a.b.c.d / x.y.w.z] but the name of the VPN [VPN_A] and the Gateway [GW_A] are from another configured VPN which is already established.

This issue affects all SRX platforms and may occur if the following conditions are present:
  • IKEv2 with Dynamic end points – DEP
  • Several gateways configured with the same external interface, but different policy for each gateway.
Cause:

As per IKEv2 protocol, we do not receive the peer ID in the first packet. Hence, we select the first matching IKE gateway object, and only when the ID is received in subsequent packets, we shift to the correct IKE gateway. Because of this possible shift, we need to have the same security settings on these gateways (the correct one and the one initially chosen). Otherwise, this would be a security hole.

Solution:

For DEP use case, to guarantee the same level of security after shifting to the right IKE gateway object, we need to have the same IKE policy on all gateways using the same external interface.

Starting from Junos 12.3X48-D40 and 15.X49-D70, it is possible to use different IKE polices. However, they must all have the same IKE proposals. This change allows the use of different PSK or different local certificates while still avoiding a security hole.

For versions before Junos 12.3X48-D40 and 15.1X49-D70, the following configuration should be used:

[edit security ike]
root@srxHUB#
...
policy A {
     proposals P1;
     certificate {
          local-certificate local-cert;
          peer-certificate-type x509-signature;
     }
}
gateway A {
     ...
     ike-policy A;
     dynamic hostname SRX_A;
     local-identity hostname srxHUB.juniper.net;
     external-interface reth1.0;
     version v2-only;
}
gateway B {
    ...
    ike-policy A;        <<<--- Same policy as Gateway above
    dynamic hostname SRX_B;
    local-identity hostname srxHUB.juniper.net;
    external-interface reth1.0;
    version v2-only;
}


For the versions above, different policies can be used, but same proposal must be in place:

[edit security ike]
root@srxHUB#
..
policy A {
      proposals P1;
      pre-shared-key ascii-text "$9$utAoB1hXxdbwgBIWxN-2g5QznApBID"; ## SECRET-DATA
}
policy B {
      proposals P1;            <<<--- Same proposal as in the policy above
      pre-shared-key ascii-text "$9$utAoB1hXxdbwgBIWxN-2g5QznApBIE"; ## SECRET-DATA
}
gateway A {
      ...
      ike-policy A;
      external-interface reth1.0;
      version v2-only;
}
gateway B {
      ...
      ike-policy B; 
      external-interface reth1.0;
      version v2-only;
}

Related Links: