[Swan] Options for Windows clients

Alex mysqlstudent at gmail.com
Thu Dec 31 00:18:13 UTC 2020


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

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

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?

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

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

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


More information about the Swan mailing list