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

2018-04-26 Thread bessonov . victor
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, Виктор Бессонов  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 :
> > > 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://list

Re: [Swan] left/rightsubnets option

2018-04-26 Thread Erik Andersson

Great! Thanks.

/Erik

On 2018-04-26 05:10, Paul Wouters wrote:

On Tue, 24 Apr 2018, Erik Andersson wrote:


 (have also tried rightsubnets={192.168.110.0/24 50.50.50.0/24})

 Yields the following error in the pluto.log file:

 Apr 23 12:42:48.546899: address family inconsistency in this/that
 connection
 Apr 23 12:42:48.546970: Failed to load connection "remote/1x1": 
attempt

 to load incomplete connection


Fixed and will be in 3.24.

https://github.com/libreswan/libreswan/commit/9fb388212d4b9c74a62fd6bcdea25f888d553bbd 



Paul

___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan


[Swan] Is it possible to not be strict with rightid?

2018-04-26 Thread Xinwei Hong
Hi,

Currently, 'rightid' is default to 'left'. However, a lot of time the
remote peer software cannot send out correct rightid (e.g. internal private
IP was used). When we were using racoon, racoon seems to be more tolerant
and works OK when rightid mismatches. With pluto, we would have to specific
rightid= whatever the other end sends. Is there a global switch that we can
turn libreswan to have similar behavior as racoon, i.e. be more tolerant
with rightid?


Thank,
Xinwei
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan


Re: [Swan] Is it possible to not be strict with rightid?

2018-04-26 Thread Paul Wouters

On Thu, 26 Apr 2018, Xinwei Hong wrote:


Currently, 'rightid' is default to 'left'. However, a lot of time the remote 
peer software cannot send out correct rightid (e.g. internal private IP
was used). When we were using racoon, racoon seems to be more tolerant and 
works OK when rightid mismatches. With pluto, we would have to specific
rightid= whatever the other end sends. Is there a global switch that we can 
turn libreswan to have similar behavior as racoon, i.e. be more tolerant
with rightid?


We already did that when specifying right=%any and authby=secret. We
know this really means a "group PSK" where ID of IP makes no sense.

But that code is post 3.23 so please try either a pre-release from
download.libreswan.org/development/ or wait a couple of days for 3.24 ?

Paul
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan


Re: [Swan] Is it possible to not be strict with rightid?

2018-04-26 Thread Xinwei Hong
Thank you Paul.
So, seems it cannot be more tolerant if right !=%any. Right?
In our case, we do provide both left and right with specific IP.

Thanks,
Xinwei


On Thu, Apr 26, 2018 at 2:01 PM, Paul Wouters  wrote:

> On Thu, 26 Apr 2018, Xinwei Hong wrote:
>
> Currently, 'rightid' is default to 'left'. However, a lot of time the
>> remote peer software cannot send out correct rightid (e.g. internal private
>> IP
>> was used). When we were using racoon, racoon seems to be more tolerant
>> and works OK when rightid mismatches. With pluto, we would have to specific
>> rightid= whatever the other end sends. Is there a global switch that we
>> can turn libreswan to have similar behavior as racoon, i.e. be more tolerant
>> with rightid?
>>
>
> We already did that when specifying right=%any and authby=secret. We
> know this really means a "group PSK" where ID of IP makes no sense.
>
> But that code is post 3.23 so please try either a pre-release from
> download.libreswan.org/development/ or wait a couple of days for 3.24 ?
>
> Paul
>
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan