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
