Description

In cOS Core version 14.00.10, the default High proposal list for IKE and IPsec was updated to also include AES-GCM as Encryption Algorithm. This should not have caused any problems as the change was to add an additional algorithm to the High proposal list without changing or removing existing algorithms. But unfortunately one case that slipped through testing was if IKEv1 was used for either Initiator or Terminator (and the default High proposal list is not always used in all test scenarios). AES-GCM is an IKEv2 only algorithm and will not work for IKEv1.

The problem

Normally, when an IPsec tunnel is initiated or terminated, one matching proposal is enough for both sides (Initiator/Terminator) to agree on which algorithms and proposals to use in order to establish the tunnel. However, due to this problem, even if the remote endpoint (being the initiator) sends, for example, the standard AES (which should be fine), cOS Core would reply with “No_Proposal_Chosen” because it erroneously fails to match the proposal due to AES-GCM being allowed in the proposal list.

If cOS Core attempts to be the initiator no output will be printed in the “ike -snoop” log as the IKE snoop only listens for incoming or sending IKE negotiations, in this case the problem happens / is detected before any packets are being processed so the IKE snoop output will be empty but the normal log would give a clear log entry of what the problem is. Below is a log Example on how it can look if an IKEv1 tunnel tries to be the initiator and AES-GCM is in the proposal list:

2023-06-26 12:33:17 IPSEC 01802022 Warning(4) event=ike_sa_failed action=no_ike_sa statusmsg="AES-GCM IKEv1 IKE cipher error" reason="AES-GCM can not be used as IKE cipher in IKEv1" local_peer="192.168.98.14:4500 ID (null)"
remote_peer="192.168.98.10:4500 ID (null)" spi_i=0x3458be918a9bf6d9 spi_r=0x0000000000000000 initiator=TRUE ipsec_if=IPsec_To_VSG-HA

Solution

The solutions to the problem are straightforward:

1. Create a new IKE and IPsec proposal list and remove AES-GCM from the selection and use that proposal list on the affected tunnel(s).
2. Alternatively modify the default HIGH proposal list and remove AES-GCM from it.
3. Change to use IKEv2 instead of IKEv1.

If possible, #3 is recommended as IKEv2 is superior to IKEv1.

Once cOS Core version 14.00.11 is released, this issue will no longer be a problem as AES-GCM will be excluded for both incoming and outgoing negotiations if IKEv1 is used (defect ID : COP-24366).

Related articles