[Swan] Options for Windows clients

Manfred mx2927 at gmail.com
Thu Dec 31 01:52:43 UTC 2020


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.
>>
>>       leftid=@vpn.example.com
>> 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/.


More information about the Swan mailing list