<br>Thank you so much Martin for the quick response.<br> Now I understood. The IP address look up came into picture to address main mode issue. <br><br>Best,<br>Jordan.<br><br><br><div class="gmail_quote">On Tue, Dec 11, 2012 at 12:53 AM, Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@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 Jordan,<br>
<div class="im"><br>
> Is this expected? Can any one please explain to me whether there is<br>
> dependency between PSK selector and connection leftid/rightid?<br>
<br>
</div>The problem is that with IKEv1 in Main Mode, you need the PSK before you<br>
even get the remote identity or could look up an associated<br>
configuration. Therefore, we use the following to get a PSK:<br>
<br>
     1. Try to find a PSK by the remote and local IP address. This will<br>
        yield the PSK in your configuration.<br>
     2. If no PSK is found, but we are using aggressive mode or act as<br>
        initiator, we can lookup the PSK using the peer identities.<br>
     3. If no PSK is found, the daemon tries to find a configuration by<br>
        the local and remote IP address, and then uses the<br>
        configurations peer identities to find a PSK.<br>
<br>
In practice, using different PSKs for clients without a static IP is<br>
difficult, IKEv1 just doesn't allow that. You could use aggressive mode<br>
where the identity is transferred in plain, but this makes you<br>
vulnerable to dictionary attacks against your PSK.<br>
<br>
So the recommendation is: Don't use PSKs for IKEv1 clients not having a<br>
static IP.<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888">Martin<br>
<br>
</font></span></blockquote></div><br>