Re: [Swan] Ike v2 negotiation
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 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
Re: [Swan] Ike v2 negotiation
On 26 October 2016 at 11:02, Paul Wouters 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
>
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] Ike v2 negotiation
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:
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?
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
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
[Swan] Ike v2 negotiation
Dear All,
we are recently add a new vpn to a customer using ikev2.
Here the config:
conn myName
authby=secret
disablearrivalcheck=no
# Local
left=%defaultroute
leftid=x.x.x.x
leftsubnet=
# Remote
right=a.a.a.a
rightid=a.a.a.a
rightsubnet=
# PHASE 1
# negothiation mode
aggrmode=no
ikev2=insist
narrowing=no
ike=aes256-sha2_512;modp2048
ikelifetime=24h
# PHASE 2
type=tunnel
phase2=esp
phase2alg=aes256-sha2_512;modp2048
salifetime=1h
pfs=yes
auto=start
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:
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.
Any idea why is that happening?
I think option 1 is the only matching the configuration or I think it wrong?
Thanks
Renzo
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
