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")
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
