[Swan] regarding PSK lookup in secrets file and the Peer ID

Paul Wouters paul at nohats.ca
Thu Mar 5 03:38:05 EET 2015

On Wed, 4 Mar 2015, David Mansfield wrote:

> I'm fairly new to libreswan and I have a working tunnel where I control both 
> ends, both ends are libreswan.  I'm about to set up a tunnel with a partner 
> and I'm looking to understand how secrets are matched against indices in the 
> secret file for PSK.

> According to the man page:
>   An additional complexity arises in the case of authentication by
>   preshared secret: the responder will need to look up the secret
>   before the Peer´s ID payload has been decoded, so the ID used
>   will be the IP address.

This refers to IKEv1 Aggresive Mod (which is not the default and should
NOT be used between two libreswan peers - in fact it should not be used
at all because the NSA does a backhaul of this negotiation and attempts
bruce force attacks against the PSK)

> However, in my test tunnel, the secret is not found unless I use the "id" I 
> have specified in leftid/rightid, and not by using the IP address.  My Id are 
> defined like:
> leftid=@somename.mydomain.com
> rightid=@othername.mydomain.com
> And my secrets file has to have:
> @somename.mydomain.com @othername.mydomain.com: PSK "blahblahblah"

That's exactly how it should be. You can leave out the leftid/rightid
and then the IP will be used and you can use IPs in the secrets file.
However, if NAT is involved it gets tricky again because you need
to specify leftid=publicip with left=localip.

> Also, in reading about "id" it seems a large area of configuration pain. In 
> my case, it looks like the partner will be deriving the ID from IP and 
> Netmask. Are they expecting my id to be "a.b.c.d/nnn"? I think the default 
> (ie. omitting the leftid) would just be "a.b.c.d", no?

The netmask has no relationship whatsoever to the ID.

> Is there any way to determine what the Peer ID is without being told 
> explicitly by their system administrator (ie. is a peer id completely 
> arbitrary based on the ipsec implementation used and configuration on the 
> remote end?)

The IKE negotiation always has to send an ID payload, consisting of an
ID type (USER_FQDN, IPV4, IPV6, ID_DER_ASN1_DN, etc) and an ID value.
Most IKE implementations default to the IPV4 ID of the local IP when an
ID is not explicitely configured.

Note that if you are using two libreswans, you should really NOT use PSK
and use RSA instead. Simply run ipsec newhostkey on each node (and give
it a few minutes if low on entropy). When completed, on the host that
you call "left", run: ipsec showhostkey --left and do the same for
right. Then put the output in your config line and set authby=rsasig
You can leave the ID's to their current @values.

That will be a much more secure VPN than one based on PSK.


More information about the Swan mailing list