[Swan] Options for Windows clients

Manfred mx2927 at gmail.com
Wed Dec 30 21:31:12 UTC 2020


Hi,

On 12/30/2020 3:25 AM, Alex wrote:
> Hi,
> 
[...]
> 
> I've gotten past that NO_PROPOSAL_CHOSEN error, or at least it's not
> producing it anymore.
> 
> Are the references to 'vpn.example.com' just labels, or is it a host
> that has to resolve to an IP?
> https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2

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

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

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 I screwed up the leftid setting in the config. It couldn't
> even find the config when I ran the following. Now it just reports it
> can't connect (presumably because it's a mobile worker with a dynamic
> IP).
> 
> # 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

> 
> Now Windows is saying "IKE failed to find valid machine certificate.
> .... install a valid certificate" but I've rebuilt the entire thing,
> deleted the old certs and inserted a new pk12 cert as I've done
> before. This strongswan post appears to indicate that "Maybe Windows
> wants to do ECDSA and searches for such a certificate". Could that be
> the case here?
> https://wiki.strongswan.org/issues/3021 >
> I've used the following two commands on the Windows side to build the
> connection:
> 
> Add-VpnConnection -Name "ikev2-cp" -ServerAddress orion.example.com
> -TunnelType "Ikev2" -PassThru -Force -EncryptionLevel "Required"
> -AllUserConnection -AuthenticationMethod MachineCertificate
> 
> Set-VpnConnectionipsecconfiguration -connectionname "ikev2-cp"
> -authenticationtransformconstants SHA256128 -ciphertransformconstants
> AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -Pfsgroup
> ECP384 -DHGroup Group14 -PassThru -Force

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

> 
>> Using ECP384 might cause it to not accept RSA certificates
> 
> Is that just for PFSGroup or all settings? The great thing about
> standards is that there's so many to choose from 
> 
This is for -Pfsgroup and -DHGroup

> How can I be sure I'm generating the proper cert with certutil in the
> first place?

When you generate a certificate the command defines the type of key, or 
uses a default that is documented in "man certutil".
After the fact you can inspect the certificate with the command I posted 
earlier (using the right path ofc). The output will tell a.o. the type 
of key used.

> 
> How much of the strongswan docs are applicable to libreswan? Was
> libreswan formed from strongswan or openswan?

They are both forks of a common ancestor project, but they diverge along 
different paths.

> 
> Now trying to connect produces the following:
> 
> Dec 29 21:08:37.408754: | found policy =
> ECDSA+ENCRYPT+TUNNEL+PFS+DONT_REKEY+IKEV2_ALLOW+IKEV2_ALLOW_NARROWING+IKE_FRAG_ALLOW+ESN_NO
> (ikev2-cp)
> Dec 29 21:08:37.409050: | found connection: "ikev2-cp"[1] 192.168.1.35
> with policy ECDSA+IKEV2_ALLOW
> Dec 29 21:12:44.610613: "ikev2-cp"[5] 192.168.1.35 #16: proposal
> 2:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from
> remote proposals
> 1:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP2048
> 2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP2048[first-match]
> 3:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP2048
> 
> Dec 29 21:12:44.613300: "ikev2-cp"[5] 192.168.1.35 #16: sent
> IKE_SA_INIT reply {auth=IKEv2 cipher=AES_CBC_256
> integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
> 
> Then that's it.
> 

Windows probably stops because of the issue above, or because it doesn't 
recognize the reply from libreswan because of the issue below.

>>> - uses right=192.168.1.35 or right=%any
>>> - 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)
>>> - an ike= line that matches the remote client proposal list (or the
>>>     client uses something that is not a default ike parameter when no ike=
>>>     line is specified)
> 
> I've tried combinations of all of those. Here's what I have now. Left
> is my libreswan server and right is my Win10 laptop.
> 
> conn ikev2-cp
>      left=68.195.111.42
>      leftcert=orion.example.com
>      leftid=@orion.example.com
>      leftsendcert=always
>      leftsubnet=0.0.0.0/0
>      leftrsasigkey=%cert
>      right=%any
>      rightaddresspool=192.168.6.2-192.168.6.254
>      rightca=%same
>      rightrsasigkey=%cert
>      modecfgdns=8.8.8.8,193.100.157.123
>      narrowing=yes
>      dpddelay=30
>      dpdtimeout=120
>      dpdaction=clear
>      auto=add
>      ikev2=insist
>      rekey=no
>      authby=ecdsa
>      fragmentation=yes
> 

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

They are both valid standard proposals, the one used by libreswan 
(RFC7427) is more recent and is meant to be a common standard that 
generalizes different authentication methods including ECDSA.
But apparently RFC7427 is not backwards compatible to RFC4754, so 
Windows and libreswan can't exchange ECDSA digital signatures.
RFC4754 is not obsoleted by RFC7427, so it is likely that Windows will 
keep using it until they have reason not to.

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

(As a side note, strongswan uses "pubkey" to indicate "public key 
authentication", which includes RSA and ECDSA, "using a private key 
associated to a usable certificate")


More information about the Swan mailing list