[Openswan Users] [Bulk] Re: %defaultroute equivalent for ipsec.secrets

[Andy Gay]

On Mon, 2006-09-18 at 12:51 -0400, Jonathan Coles wrote:
> I used "Reply All" so that the list is CC'd. Thanks for the 
> reminder.
> 
> I reloaded the secrets each time I changed the secrets file.
> 
> Andy Gay wrote:
> > Here's a thing though - I just read the ipsec.secrets manpage again, and
> > actually it's working as documented. Here's the relevant section:
> > 
> >        To  authenticate  a connection between two hosts, the entry that most specifically matches the host and peer IDs is
> >        used.  An entry with no index will match any host and peer.  More specifically, an entry with one index will  match
> >        a  host and peer if the index matches the host's ID (the peer isn't considered).
> > 
> > Which is what seems to be happening here - it's not looking at the
> > gateway's address. So perhaps this isn't a bug but a (mis-)feature....
> 
> I found that section unclear. I have yet to find a clear 
> distinction between "host" and "peer". Which am I?

It is unclear. Generally the peer should be the other guy, I would
think.
> 
> If the "host" is the VPN gateway, and the peer (my end) 
> isn't considered, there should be no problem. The error 
> message, though, shows that Openswan is looking for a PSK 
> definition that includes my specific IP address. But I can 
> define a PSK definition with information about either end 
> and it works just fine. That doesn't make sense to me.
> 
> That man page also mentions the %any value, which doesn't 
> solve the problem either.
> 
> As my original question said, all I really need is a magic 
> value like %defaultroute so that I can insert my current IP 
> into the ipsec.secrets definition. Perhaps this is a feature 
> request more than a bug.

You only *need* this "enhancement" if you really need to connect to
multiple servers using PSK. Is that the case? Otherwise, just use the
ipsec.secrets entry with no addresses and you'll be fine.

If you need to connect to multiple gateways, you should consider using
X.509.

> 
> Thanks for your help.
>