[Swan] Options for Windows clients
Manfred
mx2927 at gmail.com
Sat Dec 26 19:28:24 UTC 2020
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 at lists.libreswan.org
>>> https://lists.libreswan.org/mailman/listinfo/swan
>>>
>> _______________________________________________
>> Swan mailing list
>> Swan at lists.libreswan.org
>> https://lists.libreswan.org/mailman/listinfo/swan
More information about the Swan
mailing list