[Swan] StrongSwan connectivity problems IKEv2 (Android/Linux)

bessonov.victor at e-queo.com bessonov.victor at e-queo.com
Thu Apr 26 07:23:55 UTC 2018


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.victor at 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 <paul at nohats.ca>:
> > > On Wed, 25 Apr 2018, bessonov.victor at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5246 bytes
Desc: not available
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180426/90ae8d10/attachment-0001.bin>


More information about the Swan mailing list