Hi Tobias,<br>    I compared the IKE_AUTH messages of the following topology<br>"strongswan(Client) - strongswan(server)" and "strongswan(client) - Netgear(server)" in order to narrow down the problem.<br>
<br>I  could see in "strongswan - strongswan" scenario , server is sending IDr<br>payload in IKE_AUTH message , so Authenticating is success when we have strongswan as peer with identification as DN.<br><br>But in Netgear, its not sending IDr payload, so Authentication fails with strongswan in case of DN identification.<br>
<br>But according to RFC 4306, IDr payload is optional<br><br><pre class="newpage"><font>" The initiator asserts its identity with the IDi payload, proves<br>   knowledge of the secret corresponding to IDi and integrity protects<br>
   the contents of the first message using the AUTH payload (see section<br>   2.15).  It might also send its certificate(s) in CERT payload(s) and<br>   a list of its trust anchors in CERTREQ payload(s).  If any CERT<br>
   payloads are included, the first certificate provided MUST contain<br>   the public key used to verify the AUTH field. <span style="color:rgb(255,0,0)"> The optional payload</span><br style="color:rgb(255,0,0)"><span style="color:rgb(255,0,0)">   IDr enables the initiator to specify which of the responder's</span><br style="color:rgb(255,0,0)">
<span style="color:rgb(255,0,0)">   identities it wants to talk to</span>.  This is useful when the machine on<br>   which the responder is running is hosting multiple identities at the<br>   same IP address.  The initiator begins negotiation of a CHILD_SA"<br>
   using the SAi2 payload"<br><br><br><br></font></pre> So, I guess negotiation should not fail based on this in Strongswan.<br>Please provide your inputs on this.<br><br>Regards,<br>Saravanan N<br><br><br><div class="gmail_quote">
On Thu, Nov 1, 2012 at 3:55 AM, SaRaVanAn <span dir="ltr"><<a href="mailto:saravanan.nagarajan87@gmail.com" target="_blank">saravanan.nagarajan87@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Hi Tobias,<br>   I have attached decoded IKEV2 AUTH packet for your reference. It seems ,Client is sending a valid identity payload with identification data to strongswan.<br>But Strongswan is showing client identification information as NULL in the logs and sending authentication failure payload.<div>

<br>
<br>Please help me to solve this problem.<br><br></div>Regards,<br>Saravanan N<br><div class="gmail_quote"><div>On Thu, Oct 4, 2012 at 5:33 PM, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">tobias@strongswan.org</a>></span> wrote:<br>


</div><div><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<div><br>
> Oct  1 14:42:26 localhost charon: 13[ENC] parsed IKE_AUTH request 1 [<br>
> IDi CERT CERTREQ AUTH SA TSi TSr ]<br>
</div>> ...<br>
<div>> Oct  1 14:42:26 localhost charon: 13[CFG] looking for peer configs<br>
> matching 35.0.0.2[%any]...35.0.0.1[]<br>
<br>
</div>Your client seemed have sent an empty IDi payload (seen as [] above),<br>
which will not match with the config where you configured<br>
<br>
> conn site-site<br>
>     ...<br>
>     rightid="C=CH, O=strongswan, CN=iss"<br>
>     ...<br>
<br>
What did you configure on the client?<br>
<br>
Regards,<br>
Tobias<br>
</blockquote></div></div></div><br>
</blockquote></div><br>