Re: [strongSwan] Windows gives error 13868: Policy match error but Linux connect works

Fri, 04 May 2018 00:35:35 -0700 

Wow !
You are right. I opened the file in a text editor now and I saw the entire folder (or whatever they call this branch in the windoze world). 


Thanks for the warning. I didn't know windows could be that stupid when 
I explicitly clicked on only one key.



On 2018-05-04 18:43, Christian Salway wrote:

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

























					Reply via email to