Bug #5758


Problems when changing IKEv1/IKEv2 in IPSec Phase 1

Added by Christoph Filnkößl over 8 years ago. Updated over 8 years ago.

Web Interface
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


When adding or editing an IPSec Phase 1 there are some errors in the UI:

  • Negotiation Mode should be removed on IKEv2, that field sometimes disappears after a few seconds, sometimes it doesn't.
  • AES-GCM can't be chosen as an Encryption Algorithm

Tested on 2.3.b.20160110.1555 - 64bit

Actions #1

Updated by Anonymous over 8 years ago

  • Status changed from New to Feedback
  • Assignee set to Christoph Filnkößl

AES-GCM was removed deliberately. RFC 4106 does not specify the use of AES-GCM for phase 1

We are unable to reproduce the Negotiation Mode issue. This is some fairly simple Javascript/jQuery code and your "after a few seconds" is suspicious. Either it should hide instantly, or it should not hide. Perhaps a browser/Javascript setting issue?

Actions #2

Updated by Jim Thompson over 8 years ago

RFC 4106 section 8.2 says:

"This document does not specify the conventions for using AES-GCM for IKE Phase 1 negotiations. For AES-GCM to be used in this manner, a separate specification is needed, and an Encryption Algorithm Identifier needs to be assigned. Implementations SHOULD use an IKE Phase 1 cipher that is at least as strong as AES-GCM. The use of AES CBC [RFC3602] with the same key size used by AES-GCM-ESP is RECOMMENDED."

See also rfc4869 sections 3.1 and 3.2.

Which also recommend AES-CBC + HMAC-SHA-384.

RFC 4543 ( has similar language to rfc4869.

In summary, any use of AES-GCM for Phase 1 is an error. As such, the fact that "AES-GCM can't be chosen as an Encryption Algorithm" is not a bug.

Actions #3

Updated by Anonymous over 8 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF