[strongSwan] configuring android StrongSwan VPN Client 2.2.1

[Noel Kuntze]

Hello David,

Do the following:

Build the ike and esp cipher list with the more secure ciphers occuring first, then the weaker ones.
The first match will be preferred.
Then you can migrate your clients one by one - or not bother doing it. Your choice.

Kind regards

Noel

Am 07.01.20 um 19:51 schrieb 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
> 
>