[Swan] Ike v2 negotiation

[Renzo Dani]

Thanks for replay.

Here some more information on my side:

libreswan version:  3.17   (I'll try to update soon, I was waiting for a 
stable release on gentoo portage)

On other side they are using a Cisco ASA5545 running on 9.4(2)11 .



Also I think I found where the problem comes from.


Here the log when we first receive the package:

Oct 18 10:45:24 lofw pluto[1411]: packet from a.a.a.a:500: ignoring 
unknown Vendor ID payload 
[434953434f28434f505952494748542926436f70797269676874202863292032...]
Oct 18 10:45:24 lofw pluto[1411]: packet from a.a.a.a:500: user_reda IKE 
proposals: 
1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-256;INTEG=HMAC_SHA2_256_128;DH=MODP2048
Oct 18 10:45:24 lofw pluto[1411]: packet from a.a.a.a:500: proposal 
2:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-256;INTEG=HMAC_SHA2_256_128;DH=MODP2048 
chosen from: 
1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-512;INTEG=HMAC_SHA2_512_256;DH=MODP2048 
2:IKE:ENCR=AES_CBC_256;PRF=HMA
Oct 18 10:45:24 lofw pluto[1411]: "user_reda"[7] a.a.a.a #576: switched 
from "user_reda"[7] a.a.a.a to "myName"

we have configured other vpn, one of them is a roadwarrior config like:

conn roadwarriors_rsa
     authby=rsasig
     left=...
     leftid=...
     leftsubnet=...
     leftrsasigkey=%cert
     leftcert=serverCert
     #
     right=%any
     rightrsasigkey=%cert
     # PHASE 1
     # negothiation mode
     aggrmode=no
     ike=aes256-sha2_256;modp2048
     ...

conn user_reda
     also=roadwarriors_rsa
     rightid=@reda.logobject.ch
     rightcert=redaCert
     ...


So it actually switch from configuration "user_reda" to the other after 
the proposal is chosen, for config "user_reda" proposal 2 is the best 
match of course.

Any hint how can we solve the problem?
There is a way to specify/allow road warriors vpns for any ips except 
the ones for which we have other tunnel configured? (or give any 
priority in the initial choose of configuration)
Or maybe is something can be solved after switching the configuration? 
In any case from our side we don't want to allow that proposal for that 
specific config?


Sorry that I didn't notice immediately but I was first checking by 
searching the peer ip and I miss switch config.


Thanks a lot
Renzo






On 26.10.2016 18:14, Andrew Cagney wrote:
> On 26 October 2016 at 11:02, Paul Wouters <paul at nohats.ca> wrote:
>> On Tue, 18 Oct 2016, Renzo Dani wrote:
>>
>>>          ike=aes256-sha2_512;modp2048
>>>          phase2alg=aes256-sha2_512;modp2048
>>
>>> If we start the tunnel everything works and the tunnel is correctly
>>> established:
>>>
>>> Oct 18 10:46:16 lofw pluto[1411]:  #579: initiating v2 parent SA
>>> Oct 18 10:46:16 lofw pluto[1411]:  #579: myName IKE proposals:
>>> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-512;INTEG=HMAC_SHA2_512_256;DH=MODP2048
>>> Oct 18 10:46:16 lofw pluto[1411]:  #579: STATE_PARENT_I1: sent v2I1,
>>> expected v2R1
>>> Oct 18 10:46:16 lofw pluto[1411]:  #579: myName ESP/AH proposals:
>>> 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256;ESN=DISABLED
>>> Oct 18 10:46:16 lofw pluto[1411]:  #580: STATE_PARENT_I2: sent v2I2,
>>> expected v2R2 {auth=IKEv2 cipher=aes_256 integ=sha512_256
>>> prf=OAKLEY_SHA2_512 group=MODP2048}
>>> Oct 18 10:46:16 lofw pluto[1411]:  #580: IKEv2 mode peer ID is
>>> ID_IPV4_ADDR: 'a.a.a.a'
>>> Oct 18 10:46:16 lofw pluto[1411]:  #580: negotiated connection [......] ->
>>> [....]
>>> Oct 18 10:46:16 lofw pluto[1411]:  #580: STATE_PARENT_I3: PARENT SA
>>> established tunnel mode {ESP.....
>>>
>>>
>>> Instead if the process is started from the other side they send us
>>> different proposals:
> Does a line like:
>
> packet from 192.1.2.45:500: westnet-eastnet-ipv4-psk-ikev2 IKE
> proposals for initial responder: 1:IKE:ENCR=AES_GCM_C_256;...
>
> or similar (the exact format has evolved so it might be the below)
> showing the local (libreswan) proposal list appear in the logs
> somewhere?
>
> myName IKE proposals:
>   1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-512;INTEG=HMAC_SHA2_512_256;DH=MODP2048
>
>>> Oct 18 10:45:24 lofw pluto[1411]: packet from a.a.a.a:500: proposal
>>> 2:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-256;INTEG=HMAC_SHA2_256_128;DH=MODP2048
>>>    chosen from:
>>>
>>> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-512;INTEG=HMAC_SHA2_512_256;DH=MODP2048
>>> 2:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2-256;INTEG=HMAC_SHA2_256_128;DH=MODP2048[first-match]
>>> 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP2048
>>>
>>> and we end up choosing the option 2 instead of option 1 and the tunnel is
>>> not working.
>>
>> If they send you a proposal list, and you pick one, they MUST honour
>> that proposal. The fact that they are rejecting your proposal is a bug
>> in their code. Can you tell me the vendor/model/type of device that is
>> used, so I can relay this back to that vendor?
>>
>> But perhaps the bug is on our end, since we should never have picked up
>> HMAC_SHA2_256_128 as we do not have that configured. Andrew, did this
>> code get changed/fixed recently?
> It was rewritten a while back.
>
> I'm not sure where the problem is - it should have matched the first
> IKE proposal.
> In both cases, the same code is used to construct a local proposal.
>
> All I've noticed is:
>
> - ike=...-sha2_256 would result in the IKEv2 proposal
> PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128
>
> - our default accepts AES_256 with either SHA2_256 or SHA2_512 but we
> should prefer SHA2_512 given the option
>
>> Perhaps what is happening is that we pick the wrong proposal and send
>> that back, but actually use the one we have configured?
>>
>> I know we changed the order recently to prefer sha2_512 over sha2_256,
>> so I assume this is an older version of libreswan? But we should double
>> check this scenario cannot happen anymore with the latest code.
>>
>>> I think option 1 is the only matching the configuration or I think it
>>> wrong?
>>
>> Yes you are right. Can you tell us which version of libreswan this was?
>>
>> Paul
>>