[Swan] Options for Windows clients

Manfred mx2927 at gmail.com
Thu Dec 24 18:22:06 UTC 2020


Hi,

Based on my recent experience:

On 12/24/2020 4:41 AM, Alex wrote:
> Hi,
> 
>>> Is there documentation available on how to configure
>>> it with libreswan?
>>
>> Yes, see our libreswan examples on the website.
> 
> I followed the examples outlined on this page, including importing the
> pkcs12 file with ipsec and building an ipsec.conf for the VPN server.
> https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2
> 
> I was able to import the cert successfully on win10. When I try to
> connect, I receive a "Policy match error". How do I troubleshoot this?
> I have made the registry changes for "Windows Certificate
> requirements" and "L2TP / IPsec with the server behind NAT" as per
> this doc:
> https://libreswan.org/wiki/Interoperability#Windows_Certificate_requirements
> 
> 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'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=...

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


More information about the Swan mailing list