On Mar 11, 2020, at 16:56, Beat Zahnd <[email protected]> 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 _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
