[strongSwan] configuring android StrongSwan VPN Client 2.2.1

[David H. Durgee]

Ok, if I understand you correctly I would need to take two actions:

1) create the Windows registry entry you linked to with a value of 1 or
2 to enable or require modp2048 on Windows.

2) modify my ipsec.conf on the linux server replacing all "modp1024"
with "modp2048" as the recipe is out of date.

This should allow the Windows clients to connect securely and allow my
android phone client to connect as well.

I would need to have the Windows client fix installed first, as once I
change the ipsec.conf script any of them without the fix would be unable
to connect.  Until the ipsec.conf is modified any Windows client
connections are not secured properly.

Do I have this correct?

Dave

> Andreas Steffen wrote:  Hi Dave,
>
> the Diffie-Hellman group modp1024 is totally weak and is therefore
> deprecated by NIST. Please add modp2048 to your server's configuration.
> Actually Windows Clients be made secure by enabling modp2048 via the
> Windows registry:
>
> https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#AES-256-CBC-and-MODP2048
>
> Best regards
>
> Andreas
>
> On 07.01.20 17:31, David H. Durgee wrote:
>> I followed this recipe to install StrongSwan on my linux server:
>>
>> How to Set Up an IKEv2 VPN Server with StrongSwan on Ubuntu 16.04
>> <https://www.digitalocean.com/community/tutorials/how-to-set-up-an-ikev2-vpn-server-with-strongswan-on-ubuntu-16-04>
>>
>> This is working fine with a Windows client, so I know it is configured
>> properly.
>>
>> After this success I attempted to install the above client on my android
>> Nougat phone.  Unfortunately this is not working with the default
>> options on the client.  Here is the log entries from the linux server
>> attempting to open the VPN connection:
>>
>> Dec 26 18:07:11 DG41TY charon: 09[NET] received packet: from
>> 108.31.28.59[1024] to 192.168.80.11[500] (716 bytes)
>> Dec 26 18:07:11 DG41TY charon: 09[ENC] parsed IKE_SA_INIT request 0 [ SA
>> KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
>> Dec 26 18:07:11 DG41TY charon: 09[CFG] looking for an ike config for
>> 192.168.80.11...108.31.28.59
>> Dec 26 18:07:11 DG41TY charon: 09[CFG]   candidate: %any...%any, prio 28
>> Dec 26 18:07:11 DG41TY charon: 09[CFG] found matching ike config:
>> %any...%any with prio 28
>> Dec 26 18:07:11 DG41TY charon: 09[IKE] 108.31.28.59 is initiating an IKE_SA
>> Dec 26 18:07:11 DG41TY charon: 09[IKE] IKE_SA (unnamed)[15] state
>> change: CREATED => CONNECTING
>> Dec 26 18:07:11 DG41TY charon: 09[CFG] selecting proposal:
>> Dec 26 18:07:11 DG41TY charon: 09[CFG]   no acceptable
>> DIFFIE_HELLMAN_GROUP found
>> Dec 26 18:07:11 DG41TY charon: 09[CFG] selecting proposal:
>> Dec 26 18:07:11 DG41TY charon: 09[CFG]   no acceptable
>> ENCRYPTION_ALGORITHM found
>> Dec 26 18:07:11 DG41TY charon: 09[CFG] selecting proposal:
>> Dec 26 18:07:11 DG41TY charon: 09[CFG]   no acceptable
>> DIFFIE_HELLMAN_GROUP found
>> Dec 26 18:07:11 DG41TY charon: 09[CFG] selecting proposal:
>> Dec 26 18:07:11 DG41TY charon: 09[CFG]   no acceptable
>> ENCRYPTION_ALGORITHM found
>> Dec 26 18:07:11 DG41TY charon: 09[CFG] received proposals:
>> IKE:AES_CBC_128/AES_CBC_192/AES_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/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/(31)/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048,
>> IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/CHACHA20_POLY1305/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/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/(31)/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048
>> Dec 26 18:07:11 DG41TY charon: 09[CFG] configured proposals:
>> IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
>> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>> Dec 26 18:07:11 DG41TY charon: 09[IKE] local host is behind NAT, sending
>> keep alives
>> Dec 26 18:07:11 DG41TY charon: 09[IKE] remote host is behind NAT
>> Dec 26 18:07:11 DG41TY charon: 09[IKE] received proposals inacceptable
>> Dec 26 18:07:11 DG41TY charon: 09[ENC] generating IKE_SA_INIT response 0
>> [ N(NO_PROP) ]
>> Dec 26 18:07:11 DG41TY charon: 09[NET] sending packet: from
>> 192.168.80.11[500] to 108.31.28.59[1024] (36 bytes)
>> Dec 26 18:07:11 DG41TY charon: 09[IKE] IKE_SA (unnamed)[15] state
>> change: CONNECTING => DESTROYING
>>
>> What do I need to change in the android client configuration?  I would
>> prefer not to touch the linux server as it is working with windows
>> clients, but will do so if absolutely necessary.  Thank you for your
>> assistance in this matter.
>>
>> Dave


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4056 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200107/7afa22fe/attachment-0001.bin>