Bug 1457904

Paul, isn't it worth mentioning in documentation that certificates requirements changed (Subject Alternative Name is needed)? Well, I am not sure how many customers are using certs without SAN but such certificates will be rejected with latest libreswan (with clear explanation in the logs though).

yes that must be part of the release notes

Paul, during Common Criteria testing we noticed the following issue:

conn test
        auto=route
        authby=secret
        type=transport
        left=%defaultroute
        right=<CLIENT>
        ikev2=yes
        ike=aes_gcm_a128-sha1;dh24
        phase2=esp
        phase2alg=aes_cbc128-sha1;dh24
        labeled_ipsec=no
        connaddrfamily=ipv4
        leftprotoport=tcp/4301
        rightprotoport=tcp
        policy_label=""

# service ipsec restart
Redirecting to /bin/systemctl restart ipsec.service

# journalctl -u ipsec
...
pluto[28226]: Failed to add connection "10.37.150.135-to-10.37.150.59": ike string error: IKE encryption algorithm 'aes_gcm_a' is not supported by IKEv1, enc_alg="aes_gcm_a"(128), auth_alg="sha1", modp="dh24"to-10.37.150.59":
...

So pluto thinks we want IKEv1 despite ikev2=yes setting! This is tested with both 3.22 and 3.23 with the same results. It works as expected with 3.20. What's wrong with that configuration?

BTW: Ah, I pasted incorrect journal message, it should be:

Failed to add connection "test": ike string error: IKE encryption algorithm 'aes_gcm_a' is not supported by IKEv1, enc_alg="aes_gcm_a"(128), auth_alg="sha1", modp="dh24"

(In reply to Ondrej Moriš from comment #5)

> So pluto thinks we want IKEv1 despite ikev2=yes setting! This is tested with
> both 3.22 and 3.23 with the same results. It works as expected with 3.20.
> What's wrong with that configuration?

OK, let me add one more detail - it depends how ike and ikev2 options are ordered. If ikev2 is first, it works. If ikev2 is after ike, it fails as mentioned in the previous comments.

(In reply to Ondrej Moriš from comment #7)
> (In reply to Ondrej Moriš from comment #5)
> 
> > So pluto thinks we want IKEv1 despite ikev2=yes setting! This is tested with
> > both 3.22 and 3.23 with the same results. It works as expected with 3.20.
> > What's wrong with that configuration?
> 
> OK, let me add one more detail - it depends how ike and ikev2 options are
> ordered. If ikev2 is first, it works. If ikev2 is after ike, it fails as
> mentioned in the previous comments.

Well, let me correct this :). It not true. Ordering obviously does not matter. But  with ikev2=insist it works. Therefore with ikev2=yes/propose it fails. With ikev2=insist it works.

AES_GCM is only valid for ESP (phase2alg= or esp) and IKEv2. IKEv1 does not support AES_GCM - there is no IANA Code Point in the IKEv1 Encryption Algorithms for AES_GCM. So using ike=aes_gcm means you MUST have ikev2=insist.

ikev2=yes means allow ikev2 (but also allow ikev1)

Note that aes_gcm_a is not recommended as perf RFC 8247:

   The reason for promotion from MAY to
   SHOULD is to promote the slightly more secure AEAD method over the
   traditional encrypt+auth method.  Its status is expected to be raised
   once widely implemented.  As the advantage of the shorter (and
   weaker) Integrity Check Values (ICVs) is minimal, the 8- and 12-octet
   ICVs remain at the MAY level.

Thanks Paul, it makes sense, I knew that aes_gcm is IKEv2-only. What confused me was that previously it worked. Anyway, as you pointed out - with ikev2=yes/propose it makes sense to assume that communication might use IKEv1 and use only IKEv1-compatible ciphers. 

Unfortunately, I am experiencing another issue with 3.23, this one is even more confusing. Suppose I have both client and server configured with type=transport. Now when I start connection from client I got:

Jan 18 14:38:33.891787: "test-rsasig" #2: local policy requires Transport Mode but peer requires required Tunnel Mode

Despite the fact that IPsec SA on server is established:

Jan 18 14:38:33.887348: "test-rsasig" #2: STATE_V2_IPSEC_R: IPsec SA established transport mode {ESP=>0xbe49035d <0x7a4d546a xfrm=AES_GCM_16_256-NONE NATOA=none NATD=none DPD=passive}

It looks like some message from server to client telling that transport mode is used by server is missing!

this was bug fixed two days ago, and was due to not all NOTIFY payloads being sent properly. will be fixed in next respin

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0932

note the comment above incorrectly mentions GSSAPI support in libreswan 3.22. This is not the case.