Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 5 replies
  • Subscribers 40 subscribers
  • Views 5241 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Default IPsec IKEv2 policy has a bug, or all combinations IPsec IKEv2 policy have the BUG in v18 GA?!?

alda

Hello all,

Have any of you successfully activated v18 GA IPsec policies with IKEv2 protocol? Whichever IPsec policy I have defined with IKEv2, the tunnel will disconnect without obvious cause at the latest within 2 hours of tunnel activation. Only when I use the default IPsec IKEv2 policy does the following error message appear in stronswan.log:

2020-02-29 07:29:00 26[NET] <End_tunnel_1|226> received packet: from XX.XX.XX.XX[500] to YY.YY.YY.YY[500] (36 bytes)
2020-02-29 07:29:00 26[ENC] <End_tunnel_1|226> parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
2020-02-29 07:29:00 26[IKE] <End_tunnel_1|226> received NO_PROPOSAL_CHOSEN notify error
2020-02-29 07:29:00 26[DMN] <End_tunnel_1|226> [GARNER-LOGGING] (child_alert) ALERT: the received IKE_SA proposals did not match: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/CURVE_25519, IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/CURVE_25519, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/ECP_521, IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_521, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192, IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_8192, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_8192, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_4096, IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_4096, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096, IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_H
2020-02-29 07:29:00 26[IKE] <End_tunnel_1|226> IKE_SA NO_PROPOSAL_CHOSEN set_condition COND_START_OVER
2020-02-29 07:29:00 26[IKE] <End_tunnel_1|226> IKE_SA has_condition COND_START_OVER retry initiate in 60 sec

It is evident from the error message that the IPsec IKEv2 policy will not be negotiated and the tunnel is disconnected, but then the IPsec tunnel will automatically establish itself without the necessary intervention.

If I use another IPsec IKEv2 policy then the error message will not appear, but the whole IPsec tunnel will be disconnected again within 2 hours. The IPsec tunnel will always disconnected at the latest within two hours, regardless of the key life for Phase I and Phase II. I have tried all possible combinations of the life of both keys, but the tunnel has never been connected for more than two hours.

I defined the IPsec IKEv1 policy (for example phase I: 14400, AES256 - SHA2 256, DH2048; phase II: 3600, AES256 - SHA2 256, DH2048) then this IKEv1 tunnel is very stable (in my test about 5 days) for a long time. However, as soon as the IKEv1 IPsec policy at both ends of the tunnel is changed to IKEv2, the tunnel will reliably disconnect within 2 hours of tunnel activation.

Does anyone have a similar experience with IPsec IKEv2 tunnels? Or, what IPsec IKEv2 policy do you use and the tunnel is stable and doesn't disconnect?

Regards

alda



This thread was automatically locked due to age.
  • 0

    All my IPsec Connections are still stable since V18. Using the standard IKEv2 Policy. 

    So you are using XG - XG? Both V18? Or which device you are connecting to?

    Looks like your Rekeying does not work properly, therefore the Connection is dying. 

    Who starts the connection? 

    Is it VTI or Policy based? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Hello LuCar Toni,

     yes, both ends are XG v18 GA and both are vmware appliances too. Both ends could re-initiate tunnel too. 

    I do not understand your question "Is it VTI or Policy based?" It's a site-to-site tunnel between two networks, that's all. 

    Regards

    alda

  • 0 in reply to alda

    So its a Site to Site tunnel (Policy Based), not a Tunnel Interface (VTI)? 

    How many SAs are you building up? Is there a difference in your test?

    If you switch to Tunnel Interface, is this tunnel stable or not? 

     

    Both are VMware, on the same ESXi? Do both Gateways have a Static IP or Dynamic? Do you use any identifier in the Tunnel? 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    Hello LuCar Toni,

    as I wrote it is classical Site-to-site IPsec tunnel, not a Tunnel Interface and this IPsec tunnel is an asymmetric tunnel 2:1 (2 networks in the data center : 1 network at the branch).

    What difference do you mean, could you specify it? I tried different settings in my tests, as I wrote in my first email. But probably the most important thing I found out is in the penultimate paragraph of my first email. Thus, the IPsec policy with IKEv1, which is stable in the long term with only a change to IKEv2 (at both ends of the tunnel, of course) will change to unstable with a regular collapse of the IPsec tunnel within 2 hours at the latest.

    I do not need to change the topology of the IPsec tunnel to another, I am involved with the topology that I use.

    Both ESXi hypervisor are 6.7.0 Update 3 (Build 15160138), both IPsec gateways have a static public IP address and at the both ends is used as an identifier FQDN. 

    But maybe I already know what's the problem. I need a few more hours to verify my theory. So far, it seems that after changing a single parameter, the IPsec IKEv2 tunnel is stable. If my theory will be confirmed, it will be definitely the BUG. 

    I give you a little help, open any default IPsec policy (for IKEv1 or IKEv2) and remember the parameters values within the IPsec policy. Now click Add to create a new IPsec policy. Perhaps at first glance you will see the change in one parameter that causes the IPsec IKEv2 tunnel to collapse within 2 hours at the latest.

    Regards

    alda

  • 0 in reply to alda

    Do you mean the Rekey Fuzz Parameter? 

    Should not be the issue, because this parameter actually only gives a "random value".

    https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey 

    Percentage by which any margin is randomly increased (may exceed 100%). Randomization may be disabled by setting rekeyfuzz=0%.

     

     

     

    __________________________________________________________________________________________________________________

Unfiltered HTML