On Mar 11, 2020, at 16:56, Beat Zahnd <beat.zahnd at gmail.com> wrote:
>> ﻿Mar 11 20:34:23 core pluto[29856]: "ikev2-cp"[13] 178.197.x.x #10: Peer CERT payload SubjectAltName does not match peer ID for this connection
>>>> You do not have a subjectAltName=178.197.x.x in our certificate as a valid ID.
>> The IKE ID has to match a subjectAltName= to prevent another certificate
>> that is valid, but or a different ID, to spood this IKE ID. Since many
>> people have generated bad certificates, we provide the override option.
>> This is intentional since it is a roadwarrior client. The client public IP is never the same...
Then the client should not use its IP address as IKE ID, but use the certificate DN.
>>> Mar 11 20:34:23 core pluto[29856]: "ikev2-cp"[14] 178.197.x.x #10: No acceptable ECDSA/RSA-PSS ASN.1 signature hash proposal included for rsasig in I2 Auth Payload
>>>> What is your authby= line? Perhaps try authby=rsa-sha1 ? It looks like
>> it is trying rsa-sha1 but the remote peer does not support that and is
>> (against RFC 8472) trying to use rsa-sha1 with the RFC 7427 method.
>> authby is not set, as in https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2>> OK 2.31 is now connecting with the following settings:
>> conn ikev2-cp
> authby=rsa-sha1
So that looks like the strongswan bug doing SHA1 for RFC7427 connections that RFC 8472 says should never use SHA1 and which libreswan didn’t advertise 😕
> But still not a single nat-t keepalive from the server...
That is very strange.....
Paul