<div dir="ltr"><div><br></div>OK. I will use only same/symmetric PSK for these tunnels <div>(you are right, when you look at it, asymmetric-psk is not really required) <div><div><br></div><div>Thank you so much for your response and thank you for the info on this support in strongswan</div><div><br></div><div>regards</div><div>Rajiv</div><div> </div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 4, 2016 at 5:54 PM, Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">tobias@strongswan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rajiv,<br>
<br>
> Is this supported in Strongswan?<br>
<br>
No.  strongSwan will just use the best matching PSK as determined by<br>
matching their associated identities against the identities of the<br>
IKE_SA (PSKs that match the remote identity better are preferred, if<br>
both match it equally well, the one matching the local identity better<br>
is preferred).  Here both PSKs match one identity, but only one exactly<br>
matches the remote identity, so that's the one that gets used for both<br>
directions.<br>
<br>
Using two secrets like that doesn't really make much sense, though.<br>
Since a PSK, as the name implies, has to be shared you don't gain<br>
anything by using two of them between two peers.<br>
<br>
Regards,<br>
Tobias<br>
<br>
</blockquote></div><br></div></div></div></div>