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
[email protected]
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
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
