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. 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 is clearly wrong because now it's prompting for a username and password instead of trying to use the cert I've imported. I'm at a complete loss now, and don't understand why there isn't well-documented win10 instructions by this point. What specifically is wrong with the instructions outlined for win10 in the wiki? What more must be done there to make it work? > > 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. 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'm really hoping you have some further ideas. Thanks, alex > > > > > 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 _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
