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

Christian Salway christian.salway at naimuri.com
Thu May 3 15:40:56 CEST 2018 

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 <jafar at atcorp.com> 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,
>> CN=Myname at company.com" --san Myname at company.com --san Myname at 2.2.2.2
>> --san Myname at 10.10.10.10 --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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180503/dc07384b/attachment-0001.html>

More information about the Users mailing list