[strongSwan] IKEv2 cisco anyconnect app
Atri Basu (atbasu)
atbasu at cisco.com
Thu Apr 24 19:27:32 CEST 2014
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. :)
Cisco Systems TAC - VPN Group
Mon - Fri : 8AM - 4PM Eastern (US)
Direct Phone: +1 (919) 991-9531
E-mail: atbasu at cisco.com<mailto:atbasu at cisco.com>
On Apr 22, 2014, at 3:19 AM, Martin Willi <martin at strongswan.org<mailto:martin at strongswan.org>> wrote:
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
However, this particular attribute is included in Message 1 which can't
be encrypted. So why is strongswan expecting the payload to be
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users