Hi,
On 12/31/2020 1:18 AM, Alex wrote:
Hi,
Referring to that example:
leftcert=vpn.example.com
Here "vpn.example.com" must match the nickname of the server certificate
in the NSS database, which you created with certutil. This is how
libreswan knows which certificate to send to the client for server
authentication.
[email protected]
Here "vpn.example.com" is the VPN server ID that is advertised by
libreswan. "If preceded by @, the value is used as a literal string and
will not be resolved" (man ipsec.conf), however I don't know how Windows
uses this value or if tries to match it to the server name.
What is actually documented is that the server name that is configured
in the Windows connection properties must match the CN and
subjectAltName of the server certificate. Windows will verify that they
match, or refuse to connect (there appears to be some details about
whether to use CN, SAN or both - since you are creating the certificate
yourself, just set both matching for best compliance).
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd941612(v=ws.10)
http://www.carbonwind.net/blog/post/VPN-Reconnect-in-Windows-7-RC-redux.aspx
So I want to do something like this with certutil?
--extSAN type:name[,type:name]...
Create a Subject Alt Name extension with one or multiple names.
-type: directory, dn, dns, edi, ediparty, email, ip,
ipaddr, other, registerid, rfc822, uri, x400, x400addr
I always use openssl to generate my certs, so I'm not that familiar with
certutil for this, however, checking the certutil manpage, I'd say yes,
this is the more general option than -8 that you show below: --extSAN
lets you specify any type of subjectAltName, -8 is specific to set a DNS
subjectAltName.
Since you use a hostname, you need to specify type as DNS and the two
are equivalent.
Also, I believe it was mentioned that /var/lib/ipsec/nss was the new
default location, but certutil still requires -d to explicitly define
that location. ipsec does not.
As Paul said, certutil has no default you need to specify the database
location in every command.
ipsec uses the default location unless instructed otherwise (it used to
be /etc/ipsec.d/, recent versions use /var/lib/ipsec/nss).
As I wrote in one of my previous replies, either you provide Windows
access to a proper DNS record, or you may configure the corresponding IP
address in C:\Windows\system32\drivers\etc\hosts
The process of creating the win10 cert on the libreswan page doesn't
specify anything about the server in the certutil process. Here is my
certutil:
certutil -S -c "Example CA" -n "win10client.example.com" \
-s "O=Example,CN=win10client.example.com" -k rsa \
-g 4096 -v 36 -d sql:/etc/ipsec.d -t ",," -1 -6 -8
"win10client.example.com"
I see that the options -1 and -6 have no argument. Apparently this
triggers an interactive loop to specify the respective properties.
I think the client options should be:
-1 "digitalSignature,keyEncipherment"
-6 "clientAuth"
For the server:
-1 "digitalSignature,keyEncipherment"
-6 "serverAuth,ipsecIKEIntermediate"
That hostname doesn't resolve to anything. There's no way of knowing
what its IP will be at the time it connects, of course. Should I
instead be using the VPN server hostname for CN there instead?
"The process of creating the win10 cert" creates the client certificate,
so it doesn't use server info. It should set CN as the client hostname,
as it is correctly in the example.
"win10client.example.com" is not resolved, it doesn't need to have an
actual DNS entry. You will find it in the log as part of the client
identity.
As an alternative, it is also possible to use the server public IP
address as leftid, cert CN and SAN, and servername in the Windows
connection properties (with some caveats on how to specifically set the
IP address in SAN).
I think this was my problem previously when I received the
NO_PROPOSAL_GIVEN messages. I've since recreated the certs using the
orion.example.com which maps to the 68.192.111.42.
# ipsec auto --up ikev2-cp
029 "ikev2-cp": cannot initiate connection without knowing peer IP
address (kind=CK_TEMPLATE narrowing=yes)
036 "ikev2-cp": failed to initiate connection
Looking at your conn configuration below I think libreswan can't match
the local peer with left=68.195.111.42, and then complains that matching
it with right=%any is not allowed (if you want to specify a dynamic
address for the local peer you need to use %defaultroute)
Unless you intend your local peer to be "right", I still don't
understand why you don't use
left=your.local.ip
Do you mean the internal 192.168.1.1 address, so it's on the same
network as the Windows PC at 192.168.1.35? Eventually I'll need to do
this over the Internet, of course...
If 192.168.1.1 is the local IP address of the libreswan host[*], I'd say
yes, assuming it is behind the router's NAT. This is to tell libreswan
to identify itself as the "left" peer (because it will match that
address against the interface that is receiving the initiator's request
(from the win10 laptop)).
While you have both peers on the same network I think you may use the
same local address on the win10 laptop as well and see if it connects -
i.e. the connection configuration is OK and certs are OK too.
In order to do this over the Internet you'll need to configure the
router's NAT, and use the public address of the router from the win10
laptop.
As the ipsec.conf manpage says, when using NAT this configuration is
asymmetric: one peer is identified by its private address on the local
side, and by its public address on the remote side.
As Paul mentioned, -Pfsgroup ECP384 defines an EC cipher, which would
instruct Windows to look for an ECDSA certificate (and fail)
-Pfsgroup and -DHGroup define ciphers that belong to the same family.
They should both accept values from the DH group:
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8
For some reason Set-VpnConnectionipsecconfiguration uses different value
identifiers for -Pfsgroup and -DHGroup.
"-Pfsgroup PFS2048" and "-DHGroup Group14" both mean MODP2048
Got it. I've updated it to reflect that now.
Set-VpnConnectionIPsecConfiguration -ConnectionName ikev2-cp
-EncryptionMethod AES256 -DHGroup Group14 -IntegrityCheckMethod SHA384
-PfsGroup PFS2048 -AuthenticationTransformConstants SHA256128
-CipherTransformConstants AES256
Windows probably stops because of the issue above, or because it doesn't
recognize the reply from libreswan because of the issue below.
Is there any chance it produced some kind of error that more precisely
defined the problem that maybe I missed?
I don't know.
authby=ecdsa
Avoid ecdsa with Windows as they seem to only support the old method that
libreswan doesn’t implement. Also if you use this, you cannot have RSA based
certificates as those cannot produce ECDSA signatures.
I was experimenting based on your previous comment. Did I misinterpret it?
If you use authby=ecdsa libreswan will authenticate according to
RFC7427, but for this type of authentication (EC digital signatures)
Windows uses RFC4754:
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12
I'm pretty sure my set-vpnconnection command is correct now, given
I've created it avoiding ECDSA altogether, which basically leaves SHA
or AES for everything else.
It also recognizes the "server name or address" as the VPN hostname in
the "connection properties".
- uses authby=ecdsa or authby=rsa or authby=secret (or a combination thereof,
or it is not set in which case
the defaults would include rsa and/or rsa+ecdsa depending on the version of
libreswan)
Shouldn't I be able to choose the algorithms and key sizes during the
certutil cert creation process that we know will work with Windows in
the first place?
With libreswan you need to specify the authentication method with authby=
As Paul said, you can specify multiple methods.
For use with Windows stick to the rsa methods specified in "man ipsec.conf"
I've now experimented with rsasig and rsa-sha2. I somehow previously
had been experimenting with just "rsa" (based on Paul's comment
above), but noticed "skipping because mismatched authby" in the logs.
[*] I might be wrong, but 192.168.1.1 sounds more like the local
(private) address of the /router/. You need to use the local address of
the /libreswan host/.
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
