Tried to add IP to certificate, now the line about it disappeared from logs, although, nothing else happened. Logs from connecting Android or Linux devices are pretty similar:
packet from 188.233.186.70:56030: roadwarriors IKE proposals for initial responder: 1:IKE:ENCR=AES_GCM_C_256,AES_GCM_C_128;PRF=HMAC_SHA2_256;INTEG=NONE;DH= ECP_256 2:IKE:ENCR=AES_CBC_256,AES_CBC_128;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_25 6_128;DH=ECP_256 3:IKE:ENCR=SERPENT_CBC_256,SERPENT_CBC_128;PRF=HMAC_SHA2_256;INTEG=HMAC _SHA2_256_128;DH=ECP_256 4:IKE:ENCR=AES_CBC_256,AES_CBC_128;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_25 6_128;DH=MODP1024 packet from 188.233.186.70:56030: proposal 2:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;DH=ECP_256 chosen from: 1:IKE:ENCR=AES_CBC_128;ENCR=AES_CBC_192;ENCR=AES_CBC_256;ENCR=AES_CTR_1 28;ENCR=AES_CTR_192;ENCR=AES_CTR_256;ENCR=CAMELLIA_CBC_128;ENCR=CAMELLI A_CBC_192;ENCR=CAMELLIA_CBC_256;ENCR=3DES;INTEG=HMAC_SHA2_256_128;INTEG =HMAC_SHA2_384_192;INTEG=HMAC_SHA2_512_256;INTEG=AES_XCBC_96;INTEG=AES_ CMAC_96;INTEG=HMAC_SHA1_96;PRF=AES128_XCBC;PRF=AES128_CMAC;PRF=HMAC_SHA 2_256;PRF=HMAC_SHA2_384;PRF=HMAC_SHA2_512;PRF=HMAC_SHA1;DH=ECP_256;DH=E CP_384;DH=ECP_521;DH=BRAINPOOL_P256R1;DH=BRAINPOOL_P384R1;DH=BRAINPOOL_ P512R1;DH=CURVE25519;DH=OAKLEY_GROUP__1031??;DH=OAKLEY_GROUP__1032??;DH =OAKLEY_GROUP__1033??;DH=OAKLEY_GROUP__1040??;DH=MODP3072;DH=MODP4096;D H=MODP6144;DH=MODP8192;DH=MODP2048[first-match] 2:IKE:ENCR=AES_CCM_C_128;ENCR=AES_CCM_C_192;ENCR=AES_CCM_C_256;ENCR=AES _GCM_C_128;ENCR=AES_GCM_C_192;ENCR=AES_GCM_C_256;ENCR=CHACHA20_POLY1305 _256;ENCR=AES_CCM_A_128;ENCR=AES_CCM_A_192;ENCR=AES_CCM_A_256;ENCR=AES_ CCM_B_128... "roadwarriors"[3] 188.233.186.70 #2: STATE_PARENT_R1: received v2I1, sent v2R1 {auth=IKEv2 cipher=aes_gcm_16_256 integ=n/a prf=sha2_256 group=DH19} "roadwarriors"[3] 188.233.186.70 #2: certificate verified OK: C=RU,ST=Volgograd oblast,L=Volgograd,O=eQueo IPSec,OU=IT Dept.,CN=188.233.186.70 "roadwarriors"[3] 188.233.186.70 #2: switched from "roadwarriors"[3] 188.233.186.70 to "roadwarriors" "roadwarriors"[4] 188.233.186.70 #2: deleting connection "roadwarriors"[3] 188.233.186.70 instance with peer 188.233.186.70 {isakmp=#0/ipsec=#0} "roadwarriors"[4] 188.233.186.70 #2: certificate verified OK: C=RU,ST=Volgograd oblast,L=Volgograd,O=eQueo IPSec,OU=IT Dept.,CN=188.233.186.70 "roadwarriors"[4] 188.233.186.70 #2: IKEv2 mode peer ID is ID_DER_ASN1_DN: 'CN=188.233.186.70, OU=IT Dept., O=eQueo IPSec, L=Volgograd, ST=Volgograd oblast, C=RU' "roadwarriors"[4] 188.233.186.70 #2: DigSig: no compatible DigSig hash algo | ikev2_parent_inI2outR2_tail returned STF_FAIL with v2N_NO_PROPOSAL_CHOSEN "roadwarriors"[4] 188.233.186.70 #2: sending unencrypted notification v2N_NO_PROPOSAL_CHOSEN to 188.233.186.70:45642 packet from 188.233.186.70:45642: sending unencrypted notification v2N_INVALID_IKE_SPI to 188.233.186.70:45642 packet from 188.233.186.70:45642: sending unencrypted notification v2N_INVALID_IKE_SPI to 188.233.186.70:45642 packet from 188.233.186.70:45642: sending unencrypted notification v2N_INVALID_IKE_SPI to 188.233.186.70:45642 On Wed, 2018-04-25 at 12:43 -0400, Paul Wouters wrote: > You need to change the configuration of strongswan to send the proper > ID, either ID_FQDN or ID_DN > > Eg In their ipsec.conf syntax, set leftid= properly. I don’t know > their equivalent swanctl syntax. > > Sent from my iPhone > > On Apr 25, 2018, at 12:30, Виктор Бессонов <bessonov.vic...@e-queo.co > m> wrote: > > > Thanks! Any way to fix it for roadwarrior-like setup? All the > > clients would have changing IPs. I thought it's possible to > > distinguish between peers by their e-mail in certificate. > > > > 2018-04-25 18:27 GMT+03:00 Paul Wouters <p...@nohats.ca>: > > > On Wed, 25 Apr 2018, bessonov.vic...@e-queo.com wrote: > > > > > > > Hello! It looks like there are some problems with StronSwan > > > > connectivity. (I've tried both on Android and Linux) Or I'm > > > > doing > > > > something wrong. I've set up everything as per instructions, I > > > > am able > > > > to connect from Windows 10 native client, but connecting from > > > > StrongSwan fails with logs like: > > > > > > > > > > > "roadwarriors"[1] 188.233.186.70 #1: certificate verified OK: > > > > C=RU,ST=Volgograd oblast,L=Volgograd,O=eQueo IPSec,OU=IT > > > > Dept.,CN=j.doe > > > > "roadwarriors"[1] 188.233.186.70 #1: No matching subjectAltName > > > > found > > > > "roadwarriors"[1] 188.233.186.70 #1: certificate does not > > > > contain ID_IP > > > > subjectAltName=188.233.186.70 > > > > > > > > > > It looks like you configured strongswan to use an ID kind of IP, > > > but are > > > missing the SubjectAltName for that IP inside the certificate. > > > > > > You should be using the CN= or one of the DNS based > > > SubjectAltName > > > entries of your certificate as the configured ID on strongswan. > > > > > > Paul
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan