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:
[email protected]
[email protected]
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)
--
Thanks,
David Mansfield
Cobite, INC.
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
