[Swan] IKEv2 connection from Android drops after a few minutes

[Beat Zahnd]

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... 

> 
>> Mar 11 20:34:23 core pluto[29856]: "ikev2-cp"[13] 178.197.x.x #10: switched from "ikev2-cp"[13] 178.197.x.x to "ikev2-cp"
>> Mar 11 20:34:23 core pluto[29856]: "ikev2-cp"[13] 178.197.x.x #10: X509: connection allows unmatched IKE ID and certificate SAN
>> Mar 11 20:34:23 core pluto[29856]: "ikev2-cp"[14] 178.197.x.x #10: deleting connection "ikev2-cp"[13] 178.197.x.x instance with peer 178.197.x.x {isakmp=#0/ipsec=#0}
>> Mar 11 20:34:23 core pluto[29856]: "ikev2-cp"[14] 178.197.x.x #10: IKEv2 mode peer ID is ID_DER_ASN1_DN: 'CN=bz'
>> 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
    require-id-on-certificate=no
    left=%defaultroute
    leftcert="test VPN"
    leftid=@test.dyn.ch
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    leftrsasigkey=%cert
    mobike=yes
    right=%any
    rightaddresspool=192.168.1.100-192.168.1.200
    rightca=%same
    rightrsasigkey=%cert
    modecfgdns=10.76.1.1
    narrowing=yes
    dpddelay=12h
    dpdtimeout=13h
    dpdaction=clear
    auto=add
    ikev2=insist
    rekey=no
    fragmentation=yes


But still not a single nat-t keepalive from the server...