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

David Mansfield swan at dm.cobite.com
Thu Mar 5 16:46:37 EET 2015

On 03/04/2015 08:38 PM, Paul Wouters wrote:
> 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)

Got it.  Makes sense.  I'm using aggrmode=no, so no problems there 
(that's probably the default, right?).

>> 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.

So local ip as opposed to public ip... which only matters with NAT, so I 
understand your point above. Fortunately, NAT is not involved is this 
configuration (at least, not for the tunnel).

The other end is using Juniper, and in that world there's something 
called "proxy id" . Maybe I'm confusing that with Id/Peer Id.  Looking 
more closely, it may be that the "proxy id" is the equivalent of the 
"leftsubnet" and "rightsubnet" settings. Any experience with 
interoperability with Juniper's IPSEC?

> 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.

I had that set up and working fine, by the way - no issues.  The other 
end requires PSK so I was investigating the quirks of that configuration.

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

Why do we care about security when we're setting up a VPN? (sarcastic)

David Mansfield
Cobite, INC.

More information about the Swan mailing list