Hello All, We've a problem here with a couple of errant security-gateways when trying to connect our strongswan-using software to them.
Originally, we specified a connection to use the following params: ike=aes-sha-modp1024! esp=aes-sha1 The first segw was *unhappy* with this, because the CHILD_SA creation included a LIST of proposals (of all of the possible combinations PREPENDED by the one we specified, above). The first segw did not like the fact that we were sending a list instead of just the combination we had agreed. So, we changed the esp= line: esp=aes-sha1! This forced the local end to only propose the specified combination. The first segw became happy. Next, the second segw was unhappy. Eventually, they managed to tell us it was because we were not specifying the diffie-hellman group in the CHILD_SA creation proposal. So, we changed the esp= line again: esp=aes-sha1-modp1024! The second segw became happy. We could set up a tunnel and rekeying proceeded smoothly. Unfortunately, the first segw became unhappy again :-( Initial tunnel setup went okay, rekeying of the IKE_SA went okay, but rekeying of the CHILD_SA failed. Looking at the strongswan trace, it seemed that we were proposing to use "AES_CBC_128/HMAC_SHA1_96/MODP_1024" (as expected) and the segw was responding with a smaller proposal of "AES_CBC_128/HMAC_SHA1_96". The local end's strongswan code received this proposal, looked for it in the list of configured proposals, could not find it and failed the rekey operation. I've tried: esp=aes-sha1-modp1024 but this then failed because we ended up proposing a list of choices, again. I've also tried: esp=aes-sha1-modp1024,aes-sha1! but this seems to confuse the SECOND segw (after successful initial tunnel setup, the second segw goes into an infinite immediate rekeying loop). I haven't even tried this configuration on the first segw. The operator of the first segw does not think there is a problem with their segw and insists that the previous version of our software (using a different IPsec stack not strongswan) worked fine and that we should make our latest version of our software compatible with the old version. Looking at the old version, it made the same proposal as the new one ("AES_CBC_128/HMAC_SHA1_96/MODP_1024") and when it received the same responding proposal ("AES_CBC_128/HMAC_SHA1_96") warned that the remote end had not specified the diffie-hellman group BUT it would carry on anyway and set up the new CHILD_SA. Any ideas, anyone ? I'm tempted to try and argue that the problem is with their segw, because it specifies the diffie-hellman group during the initial setup of the CHILD_SA and it is only during the rekeying of the CHILD_SA that they do not specify the diffie-hellman group. However, I'm sure they will: (a) state that they are not breaking any standards by doing so (b) it is more efficient to NOT specify a new diffie-hellman exchange during a rekey of the CHILD_SA (or something) (c) play the old "your new software breaks compatibility with your old software" card Is this a problem with strongswan ? Or, have I configured it wrong ? Or, will I have to give in with trying to stick to the same connection configuration for both security-gateways ? Or, will I have to hack the strongswan code to work around this ? Any suggestions gratefully received ! Regards, Graham.
_______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users