Hi Martin, Yes indeed, i was. Thanks for your response. I think I understand better what you meant. So the question is: Why does Anyconnect send a configuration payload in IKE_SA_INIT? Even if it might not be explicitly disallowed, the configuration payload is certainly not used here as intended in RFC5996.
Actually RFC 5996 states: "Unrecognized or unsupported attributes MUST be ignored in both requests and responses." 3.15.1<https://tools.ietf.org/html/rfc5996#section-3.15.1>. Configuration Attributes .........................110<https://tools.ietf.org/html/rfc5996#page-110> So, my understanding is an RFC compliant devices would just ignore this particular instance, instead of rejecting the connection. As said, working around this issue might be possible, but I don't think it makes much sense given the mentioned Cisco EULA restrictions. You're right, I was just doing some research on my end regarding some other things when I came across your post and I was curious about it. Thanks for the clarification. :) Regards, -- Atri Basu Cisco Systems TAC - VPN Group Mon - Fri : 8AM - 4PM Eastern (US) Direct Phone: +1 (919) 991-9531 E-mail: [email protected]<mailto:[email protected]> On Apr 22, 2014, at 3:19 AM, Martin Willi <[email protected]<mailto:[email protected]>> wrote: Atri, I notice you mention in your response that strongswan is rejecting an unencrypted payload that it expects to be encrypted. I assume you are referring to the one-and-a-half year old discussion at [1]? However, this particular attribute is included in Message 1 which can't be encrypted. So why is strongswan expecting the payload to be encrypted? While this is true, strongSwan still rejects an unencrypted configuration payload message. It just does not expect a configuration payload in IKE_SA_INIT. So the question is: Why does Anyconnect send a configuration payload in IKE_SA_INIT? Even if it might not be explicitly disallowed, the configuration payload is certainly not used here as intended in RFC5996. As said, working around this issue might be possible, but I don't think it makes much sense given the mentioned Cisco EULA restrictions. Regards Martin [1]https://lists.strongswan.org/pipermail/users/2012-December/004064.html
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
