Be careful when you do the export as it exports all the other values in the same key. You should keep just the NegotiateDH2048_AES256
The contents of the exported key should look as follows Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters] "NegotiateDH2048_AES256"=dword:00000002 > On 4 May 2018, at 05:53, flyingrhino <[email protected]> wrote: > > Hi, > > Just to keep a complete record of this for other people who may search the > list archive for this solution: > > The solution was to create a windows registry key: > Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters > Key: NegotiateDH2048_AES256 > Type: DWORD 32bit > Value: 1 > > If you need to roll this out across multiple machines as I did - once you do > the first machine, you can select the new key you just edited and do: > File -> Export , select type reg. > Then on subsequent machines the user simply double clicks the file and it > gets imported automatically. > > Hope this helps other people who find this post. > > > > On Fri, 4 May 2018 11:47:21 +1200 > flyingrhino <[email protected]> wrote: > >> Hi Jafar and Chrisitan, >> >> You guys are the best! >> Works like a charm. >> >> I decided to upgrade windows rather than degrade security. So I used the >> registry hack. >> >> Ken >> >> On Thu, 3 May 2018 14:40:56 +0100 >> Christian Salway <[email protected]> wrote: >> >>> or add the registry key <http://www.naimuri.com/> >>> >>> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters >>> [DWORD 32bit] NegotiateDH2048_AES256 1 >>> >>> https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#Bugs-amp-Features >>> >>> <https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#Bugs-amp-Features> >>> >>> >>>> On 3 May 2018, at 14:39, Jafar A-Gharaibeh <[email protected]> wrote: >>>> >>>> The responder is configured to accept DH group modp2048 and up. Windows >>>> can only do modp1024 by default as you can see in the received proposals. >>>> >>>> Append modp1024 to your strongswan ike proposals and it should work. >>>> >>>> Regards, >>>> Jafar >>>> >>>> >>>> On 2018-05-03 04:34, flyingrhino wrote: >>>>> Hi fellow swan'ers, >>>>> Can anyone point me in the right direction to understand why I get the >>>>> message "error 13868: Policy match error" when I connect using windows >>>>> 8.1 & p12 cert to strongswan responder (5.6.2-2~local9.1 on debian >>>>> stretch)? >>>>> When I connect to the same responder from a linux initiator running >>>>> linux mint 18.3 with the cert components configured manually into >>>>> ipsec.conf , ipsec.secrets, strongswan.conf (ipsec up CONN_NAME) - it >>>>> works perfectly! >>>>> Here's the log from the responder with find/replace on private fields: >>>>> May 3 18:08:30 my_server charon: 02[NET] received packet: from >>>>> 1.1.1.1[43473] to 2.2.2.2[500] >>>>> May 3 18:08:30 my_server charon: 12[NET] received packet: from >>>>> 1.1.1.1[43473] to 2.2.2.2[500] (616 bytes) >>>>> May 3 18:08:30 my_server charon: 12[ENC] parsed IKE_SA_INIT request 0 >>>>> [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ] >>>>> May 3 18:08:30 my_server charon: 12[CFG] looking for an ike config >>>>> for 2.2.2.2...1.1.1.1 >>>>> May 3 18:08:30 my_server charon: 12[CFG] candidate: 2.2.2.2...%any, >>>>> prio 1052 >>>>> May 3 18:08:30 my_server charon: 12[CFG] found matching ike config: >>>>> 2.2.2.2...%any with prio 1052 >>>>> May 3 18:08:30 my_server charon: 12[IKE] received MS NT5 ISAKMPOAKLEY >>>>> v9 vendor ID >>>>> May 3 18:08:30 my_server charon: 12[IKE] received MS-Negotiation >>>>> Discovery Capable vendor ID >>>>> May 3 18:08:30 my_server charon: 12[IKE] received Vid-Initial-Contact >>>>> vendor ID >>>>> May 3 18:08:30 my_server charon: 12[ENC] received unknown vendor ID: >>>>> 01:MORE HEX HERE:00:00:02 >>>>> May 3 18:08:30 my_server charon: 12[IKE] 1.1.1.1 is initiating an IKE_SA >>>>> May 3 18:08:30 my_server charon: 12[IKE] IKE_SA (unnamed)[2] state >>>>> change: CREATED => CONNECTING >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> DIFFIE_HELLMAN_GROUP found >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> DIFFIE_HELLMAN_GROUP found >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> DIFFIE_HELLMAN_GROUP found >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> DIFFIE_HELLMAN_GROUP found >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> DIFFIE_HELLMAN_GROUP found >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> DIFFIE_HELLMAN_GROUP found >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> ENCRYPTION_ALGORITHM found >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> ENCRYPTION_ALGORITHM found >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> ENCRYPTION_ALGORITHM found >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> ENCRYPTION_ALGORITHM found >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> ENCRYPTION_ALGORITHM found >>>>> May 3 18:08:30 my_server charon: 12[CFG] selecting proposal: >>>>> May 3 18:08:30 my_server charon: 12[CFG] no acceptable >>>>> ENCRYPTION_ALGORITHM found >>>>> May 3 18:08:30 my_server charon: 12[CFG] received proposals: >>>>> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, >>>>> IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, >>>>> IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, >>>>> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, >>>>> IKE:3DES_CBC/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024, >>>>> IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024 >>>>> May 3 18:08:30 my_server charon: 12[CFG] configured proposals: >>>>> IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_HMAC_SHA1/CURVE_25519/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048, >>>>> IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_HMAC_SHA1/CURVE_25519/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048 >>>>> May 3 18:08:30 my_server charon: 12[IKE] remote host is behind NAT >>>>> May 3 18:08:30 my_server charon: 12[IKE] received proposals inacceptable >>>>> May 3 18:08:30 my_server charon: 12[ENC] generating IKE_SA_INIT >>>>> response 0 [ N(NO_PROP) ] >>>>> May 3 18:08:30 my_server charon: 12[NET] sending packet: from >>>>> 2.2.2.2[500] to 1.1.1.1[43473] (36 bytes) >>>>> May 3 18:08:30 my_server charon: 12[IKE] IKE_SA (unnamed)[2] state >>>>> change: CONNECTING => DESTROYING >>>>> May 3 18:08:30 my_server charon: 02[NET] waiting for data on sockets >>>>> May 3 18:08:30 my_server charon: 08[NET] sending packet: from >>>>> 2.2.2.2[500] to 1.1.1.1[ >>>>> Could it be something to do with how the client key is built - the CN, >>>>> or san fields, or the IP addresses? >>>>> Here's how I made the keys. Again fields have been sanitized: >>>>> Responder >>>>> ========= >>>>> ipsec pki --gen --type rsa --size 4096 --outform pem > >>>>> /etc/ipsec.d/private/my_strongswanKey.pem >>>>> ipsec pki --self --ca --lifetime 720 --in >>>>> /etc/ipsec.d/private/my_strongswanKey.pem --type rsa --dn "C=US, >>>>> O=company, CN=myrootCA" --outform pem > >>>>> /etc/ipsec.d/cacerts/my_strongswanCert.pem >>>>> ipsec pki --gen --type rsa --size 2048 --outform pem > >>>>> /etc/ipsec.d/private/my_vpnHostKey.pem >>>>> ipsec pki --pub --in /etc/ipsec.d/private/my_vpnHostKey.pem --type rsa >>>>> | ipsec pki --issue --lifetime 710 --cacert >>>>> /etc/ipsec.d/cacerts/my_strongswanCert.pem --cakey >>>>> /etc/ipsec.d/private/my_strongswanKey.pem --dn "C=US, O=company, >>>>> CN=2.2.2.2" --san 2.2.2.2 --san @2.2.2.2 --san 10.10.10.10 --san >>>>> @10.10.10.10 --san servername --flag serverAuth --flag ikeIntermediate >>>>> --outform pem > /etc/ipsec.d/certs/my_vpnHostCert.pem >>>>> Initiator certs >>>>> =============== >>>>> ipsec pki --gen --type rsa --size 2048 --outform pem > >>>>> /etc/ipsec.d/private/my_MynameKey.pem >>>>> ipsec pki --pub --in /etc/ipsec.d/private/my_MynameKey.pem --type rsa >>>>> | ipsec pki --issue --lifetime 710 --cacert >>>>> /etc/ipsec.d/cacerts/my_strongswanCert.pem --cakey >>>>> /etc/ipsec.d/private/my_strongswanKey.pem --dn "C=US, O=company, >>>>> [email protected]" --san [email protected] --san [email protected] >>>>> --san [email protected] --outform pem > >>>>> /etc/ipsec.d/certs/my_MynameCert.pem >>>>> openssl pkcs12 -export -inkey /etc/ipsec.d/private/my_MynameKey.pem >>>>> -in /etc/ipsec.d/certs/my_MynameCert.pem -name "my_MynameCert" >>>>> -certfile /etc/ipsec.d/cacerts/my_strongswanCert.pem -caname >>>>> "myrootCA" -out /etc/ipsec.d/p12/my_Myname.p12 >>>>> Thanks. >>> >> >> >> > > > > -- > Rhinos can fly, > > It's just a case of mind over matter ... > ... And you need a lot of mind to control that much matter ... >
