<div dir="ltr">Hi Tobias,<div><br></div><div>Thanks for the answer.</div><div><br></div><div>I thought that somehow the peer identity is stored internally in the client after the peer responds...</div><div>Considering what you said, why then if I use a rightid parameter like this:</div><div><br></div><div>rightid="C=*, ST=*, O=*, OU=*, CN=*"</div><div><br></div><div>using wildcards does indeed result in sending the INIT_CONTACT in the IKE_AUTH request...</div><div><br></div><div>Shouldn't the same apply when you use wildcards then ? Because in this case also is not determined on what the exact peer identity is, but still the INIT_CONTACT is being sent...?</div><div><br></div><div>Regards,</div><div>Marko.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 14, 2016 at 11:40 AM Tobias Brunner <<a href="mailto:tobias@strongswan.org">tobias@strongswan.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marko,<br class="gmail_msg">
<br class="gmail_msg">
> What is the reason for this ? Is it the expected behaviour ?<br class="gmail_msg">
<br class="gmail_msg">
Yes, how could the client know that this is the first IKE_SA with the<br class="gmail_msg">
peer if it doesn't know the peer's identity (rightid=%any)?<br class="gmail_msg">
<br class="gmail_msg">
Regards,<br class="gmail_msg">
Tobias<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>