[strongSwan] IKEv2 cisco anyconnect app

[Atri Basu (atbasu)]

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: 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:

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20140424/212690f1/attachment.html>