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
[email protected]
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 <[email protected]> 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
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
