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.
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
The solutions to the problem are straightforward:
- 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).
- Alternatively modify the default HIGH proposal list and remove AES-GCM from it.
- 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).
11 Jan, 2023 ipsec core vpn
24 Mar, 2023 core ipsec ippool dhcp
12 Apr, 2023 core proxyarp arp ipsec routing
23 Aug, 2022 core certificate oneconnect ipsec vpn
23 Nov, 2022 core ipsec
21 Feb, 2023 ipsec certificate windows ca core
22 Mar, 2021 core ipsec routing
13 Apr, 2023 core routing ospf ipsec
17 Jun, 2021 core ipsec routing
8 Mar, 2023 core l2tp ipsec
20 Feb, 2023 core vpn ipsec
14 Apr, 2021 core license ipsec
8 Sep, 2020 core ipsec rules access
29 Mar, 2023 ipsec core windows vpn l2tp
5 Apr, 2023 ipsec core
16 Sep, 2020 vpn ipsec ikev2 windows howto dh
7 Dec, 2022 ipsec ike troubleshoot core
14 Dec, 2022 core ipsec
5 Apr, 2023 core nps ipsec radius legacy
14 Mar, 2023 core ipsec vpn ikev2 certificate
23 Aug, 2022 core ipsec license memory
15 Mar, 2023 core ipsec ipv6
23 Aug, 2022 core connections ipsec memory
13 Feb, 2023 ipsec core routing failover
28 Mar, 2023 dhcp ipsec core