Hi,
On 12/26/2020 3:51 AM, Alex wrote:
Hi,
I've also added the "NegotiateDH2048_AES256" DWORD as per this doc:
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2
Instead of tweaking the registry, you might rather use the Windows
Powershell, and specifically Set-VpnConnectionIPsecConfiguration:
https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps
Fair warning: do not use ECP curves for DH group and PfsGroup, because
you won't be able to connect from Win10 to libreswan with those.
Also, do not use elliptic curves (ECDSA) certificates, because you won't
be able to connect from Win10 to libreswan either.
As a side note, Windows will reject its own certificate if it uses ECDSA
and the DH group does /not/ use EC ciphers, raising the (possibly
confusing) error 13806.
I've read over your comments multiple times and I'm really not sure I
understand.
That is probably because my comment assumes some familiarity with IKE
encryption and authentication methods.
This is the command I've now tried to use, unsuccessfully:
Set-VpnConnectionIPsecConfiguration -ConnectionName "ikev2-cp"
-AuthenticationTransformConstants SHA256128 -CipherTransformConstants
AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -PfsGroup
ECP384 -DHGroup ECP384 -PassThru -Force
This command uses ECP curves for DH group and PfsGroup, which is what I
said libreswan is *not* able to accept in this scenario.
One hint might be:
Set-VpnConnectionIPsecConfiguration -ConnectionName "ikev2-cp"
-AuthenticationTransformConstants SHA256128 -CipherTransformConstants
AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -PfsGroup
PFS2048 -DHGroup Group14 -PassThru -Force
DH Group14 means MODP2048:
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8
I also changed -IntegrityCheckMethod SHA384 to SHA256 because SHA384 is
not part of the libreswan default set shown below. You may use ike=...
and esp=... to configure that. See the ipsec.conf manpage for details
about how to configure those. You may want to start with the default set
though.
This is clearly wrong because now it's prompting for a username and
password instead of trying to use the cert I've imported.
At least the command /is/ doing something ;)
I assume you mean Windows is asking for username and password.
My guess (beware, just a guess): you configured DHGroup=ECP384, and you
don't have an ECDSA certificate, therefore Windows is discarding the
machine certificate and falling back to some other authentication method.
Here's some instruction on how to configure the windows connection to
use machine certificates.
https://wiki.strongswan.org/projects/strongswan/wiki/Win7Config
Is it possible you have some "auto" property setting somewhere?
I'm at a complete loss now, and don't understand why there isn't
well-documented win10 instructions by this point.
That's not a big surprise. Microsoft has a tradition of doing things
their own way, while *nix systems tend to follow the official standards.
Specifically for VPN implementations, though, Microsoft made the choice
to implement IKEv2 according to IETF standards (which is a good thing),
but to me it seems that the details of such implementation have changed
in the evolution from initial Win7 release candidates to latest Win10
systems.
What specifically is wrong with the instructions outlined for win10 in
the wiki? What more must be done there to make it work?
I don't know if there is anything wrong with the instructions; as far as
I am concerned I discarded MODP1024 immediately because it is known to
be unsafe, and in order to use a safer cipher in Windows, I didn't touch
the registry, I used Set-VpnConnectionIPsecConfiguration instead.
As far as I can see from your logs it looks like your change of the
registry to use MODP2048 is ineffective.
I'm also seeing the following in pluto.log:
Dec 23 22:31:29.242048: "ikev2-cp"[4] 192.168.1.35 #7: no local
proposal matches remote proposals
1:IKE:ENCR=3DES;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
3:IKE:ENCR=3DES;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
4:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
5:IKE:ENCR=3DES;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
6:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
Dec 23 22:31:29.242065: "ikev2-cp"[4] 192.168.1.35 #7: responding to
IKE_SA_INIT message (ID 0) from 192.168.1.35:500 with unencrypted
notification NO_PROPOSAL_CHOSEN
Indeed this is the denial that results in "Policy match error" on Windows.
If these are the proposals offered by the Windows peer, they all use
MODP1024, which is not allowed by libreswan.
Somewhere around this log the local proposals should be listed; compare
them with the Windows proposals and adjust accordingly.
I'd say Set-VpnConnectionIPsecConfiguration is the more complete tool to
configure the Windows side.
On the libreswan side you may use ike=... and esp=...
I think this might be it:
Dec 24 10:22:38.203378: "ikev2-cp"[2] 192.168.1.35: local IKE
proposals (IKE SA responder matching remote proposals):
Dec 24 10:22:38.203412: "ikev2-cp"[2] 192.168.1.35:
1:IKE=AES_GCM_C_256-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 24 10:22:38.203428: "ikev2-cp"[2] 192.168.1.35:
2:IKE=AES_GCM_C_128-HMAC_SHA2_512+HMAC_SHA2_256-NONE-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 24 10:22:38.203433: "ikev2-cp"[2] 192.168.1.35:
3:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 24 10:22:38.203442: "ikev2-cp"[2] 192.168.1.35:
4:IKE=AES_CBC_128-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-MODP2048+MODP3072+MODP4096+MODP8192+ECP_256+ECP_384+ECP_521+CURVE25519
Dec 24 10:22:38.203457: "ikev2-cp"[2] 192.168.1.35 #7: no local
proposal matches remote proposals
1:IKE:ENCR=3DES;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
2:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA1_96;PRF=HMAC_SHA1;DH=MODP1024
3:IKE:ENCR=3DES;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
4:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP1024
5:IKE:ENCR=3DES;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
6:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_384_192;PRF=HMAC_SHA2_384;DH=MODP1024
I don't know under what circumstances those messages were produced,
though, because I can't get it to do it again.
These logs indeed show that Windows keeps proposing MODP1024, which is
nowhere in the libreswan local proposals.
Maybe your current windows configuration is falling back to some method
other than IKEv2? Just guessing.
Also, in my logs I see that Windows sends a single proposal instead of
6. I understand this is because after using
Set-VpnConnectionIPsecConfiguration only the configured cipher set is
proposed.
I've also located this mini-howto that does a great job of explaining
the steps as well as providing a registry file to enable stronger
ciphers in win10.
https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/ikev2-howto.md
I've found that too, which gave the (useful) links on how to configure
the windows client. As said, I didn't use the regfile though.
https://wiki.strongswan.org/projects/strongswan/wiki/Win7Certs
https://wiki.strongswan.org/projects/strongswan/wiki/Win7Config
(this is the same I mentioned above)
I'm really hoping you have some further ideas.
I'd suggest you check thoroughly the VPN connection properties on the
windows side, and fix the Set-VpnConnectionIPsecConfiguration command.
Thanks,
alex
Good luck!
The win10 laptop I am using is connected to our internal network on
192.168.1.35. The libreswan server has a public IP (which I've
specified as the endpoint for the win10 client), but also is the
Internet gateway for the win10 client as 192.168.1.1. Is it possible
to connect to the libreswan server while being on the same internal
network?
I'd guess it is possible to set up the entire connection locally, using
local IP's everywhere. Watch out for address clashes, and set up
rightaddresspool to a separate subnet.
The network looks like this:
68.195.111.42 <--> 192.168.1.1 <--> internal network with win10 client
192.168.1.35
If not, is there another way to test this without having to go outside
the local network?
Here is my windows.conf config file:
conn ikev2-cp
left=68.195.111.42
From the ipsec.conf manpage:
"If using IP addresses in combination with NAT, always use the actual
local machine's (NATed) IP address, and if the remote (eg right=) is
NATed as well, the remote's public (not NATed) IP address. Note that
this makes the configuration no longer symmetrical on both sides, so you
cannot use an identical configuration file on both hosts"
This means you should use:
left=your.local.ip (e.g. 192.168.xxx.xxx)
An alternative is also %defaultroute (from the manpage as well)
leftcert=vpn.mycompany.com
leftid=@vpn.mycompany.com
Better use example.com for examples.
If you use leftid=@fqdn then:
- your server certificate's subject should have CN=the.same.fqdn
- your server certificate should have subjectAltName=the.same.fqdn
- your Windows client should connect to the.same.fqdn; you may set up a
proper DNS entry or use C:\windows\system32\drivers\etc\hosts to map to
the corresponding IP address (this is the windows counterpart of
/etc/hosts).
As an alternative, you may use leftid=your.public.ip.address, and use
that IP address everyehere in place of the fqdn (unless you set up the
entire connection locally and then use the local address everywhere as
said above)
The rationale is that the Win10 peer will validate the server
certificate name against the destination it is trying to connect to:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd941612(v=ws.10)
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,8.8.4.4
narrowing=yes
dpddelay=30
dpdtimeout=120
dpdaction=clear
auto=add
ikev2=insist
rekey=no
fragmentation=yes
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
