[Swan] Options for Windows clients
Paul Wouters
paul at nohats.ca
Sat Dec 26 19:43:37 UTC 2020
On Dec 26, 2020, at 14:28, Manfred <mx2927 at gmail.com> wrote:
>
>
> 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.
It seems Windows only uses the old style ECDSA authentication and libreswan only supports the new style RFC 7924 ECDSA authentication. It seems Windows switches to this based on ECDH vs DH Groups.
> 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.
That is possible, yes.
Paul
> 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
> _______________________________________________
> Swan mailing list
> Swan at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan
More information about the Swan
mailing list