GCM and CTR ciphers broken in 6.41?

RouterOS General
1

After upgrading two HAP-AC units to the latest 6.41 my site-to-site tunnel refused to come back up.
I’ve spent several days debugging the problem and it turned out that the previously working proposal or AES-GCM started to fail in phase 2 negotiations

The only way to make the tunnel work again was to revert to AES-CBC ciphers witch is quite unfortunate.

Originally the proposals were configured as:

add auth-algorithms=sha256,null enc-algorithms=aes-128-gcm lifetime=20m name=GCM-proposal pfs-group=ec2n185

ipsec logging was reporting

 ipsec invalid encryption algorithm 20.

followed by

 ipsec pfkey update failed.

switching from CGM to CTR resulted in the same error
switching to CBC immediately established phase 2

also during the debug I’ve noticed another strange thing in phase 2 in the logs:

21:49:03 ipsec,debug   (trns_id=AES-GCM-ICV16 encklen=128 authtype=254) 
21:49:03 ipsec,debug   (trns_id=AES-GCM-ICV16 encklen=160 authtype=254)

my proposals were only for GCM-128, bit somehow both routers were attempting to negotiate 160-bit keys

Can anybody help with setting up GCM ciphers in 6.41+ software or advise on bug fixes timeframes?

Regards,
Alex

2

Update:

GCM ciphers are broken only between version 6.41
I’ve downgraded one of my HAPac to 6.39 (bugfix branch) and reverted the proposals back to GCM. Amazingly the SAs kicked in.

So for those using GCM for IPSec please be aware that if your router and the remote peer are on 6.41 GCM will fail
If one of the endpoints is NOT 6.41 it will work

A very talented bug…

3

Unfortunately, yes - AES-GCM and AES-CTR are not working properly for IKEv1 in RouterOS 6.41. The fix is already available in the release candidate branch and will be included in the next bugfix version.

*) ike1 - fixed “aes-ctr” and “aes-gcm” encryption algorithms (introduced v6.41);