[strongSwan] Same config for strongSwan, different outcome between Android and iOS
Laurens Vets
laurens at daemon.be
Wed Jun 29 19:18:19 CEST 2016
Hello,
>> I've set up a strongSwan server for IKEv2. Connections with the
>> Android
>> strongSwan app fail, while using the iOS built-in IKEv2 client works
>> without issues. Any ideas on what might be going on?
>
> Looks like it could be an IP fragmentation issue.
There's definitely something strange going on.
>> Android strongSwan client server logs:
>>
>> Jun 29 01:33:15 irkalla charon: 04[NET] received packet: from
>> 1.1.1.1[40108] to 2.2.2.2[500] (732 bytes)
>> Jun 29 01:33:15 irkalla charon: 04[ENC] parsed IKE_SA_INIT request 0 [
>> SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N((16431)) N(REDIR_SUP)
>> ]
>> Jun 29 01:33:15 irkalla charon: 04[IKE] 1.1.1.1 is initiating an
>> IKE_SA
>> Jun 29 01:33:15 irkalla charon: 04[IKE] remote host is behind NAT
>> Jun 29 01:33:15 irkalla charon: 04[IKE] DH group ECP_256 inacceptable,
>> requesting MODP_2048
>> Jun 29 01:33:15 irkalla charon: 04[ENC] generating IKE_SA_INIT
>> response
>> 0 [ N(INVAL_KE) ]
>
> Since you don't have the openssl plugin loaded ECP-256 is not supported
> by the server so it requests a different DH group.
Any idea how I can resolve that particular error message? OpenSSL plugin
is loaded:
# ipsec listplugins:
...
openssl:
CUSTOM:openssl-threading
CRYPTER:AES_CBC-16
CRYPTER:AES_CBC-24
CRYPTER:AES_CBC-32
CRYPTER:CAMELLIA_CBC-16
CRYPTER:CAMELLIA_CBC-24
CRYPTER:CAMELLIA_CBC-32
CRYPTER:CAST_CBC-0
CRYPTER:BLOWFISH_CBC-0
CRYPTER:3DES_CBC-24
CRYPTER:DES_CBC-8
CRYPTER:DES_ECB-8
CRYPTER:NULL-0
HASHER:HASH_MD4
HASHER:HASH_MD5
HASHER:HASH_SHA1
HASHER:HASH_SHA224
HASHER:HASH_SHA256
HASHER:HASH_SHA384
HASHER:HASH_SHA512
PRF:PRF_KEYED_SHA1
PRF:PRF_HMAC_MD5
PRF:PRF_HMAC_SHA1
PRF:PRF_HMAC_SHA2_256
PRF:PRF_HMAC_SHA2_384
PRF:PRF_HMAC_SHA2_512
SIGNER:HMAC_MD5_96
SIGNER:HMAC_MD5_128
SIGNER:HMAC_SHA1_96
SIGNER:HMAC_SHA1_128
SIGNER:HMAC_SHA1_160
SIGNER:HMAC_SHA2_256_128
SIGNER:HMAC_SHA2_256_256
SIGNER:HMAC_SHA2_384_192
SIGNER:HMAC_SHA2_384_384
SIGNER:HMAC_SHA2_512_256
SIGNER:HMAC_SHA2_512_512
AEAD:AES_GCM_8-16
AEAD:AES_GCM_8-24
AEAD:AES_GCM_8-32
AEAD:AES_GCM_12-16
AEAD:AES_GCM_12-24
AEAD:AES_GCM_12-32
AEAD:AES_GCM_16-16
AEAD:AES_GCM_16-24
AEAD:AES_GCM_16-32
DH:MODP_2048
DH:MODP_2048_224
DH:MODP_2048_256
DH:MODP_1536
DH:MODP_3072
DH:MODP_4096
DH:MODP_6144
DH:MODP_8192
DH:MODP_1024
DH:MODP_1024_160
DH:MODP_768
DH:MODP_CUSTOM
PRIVKEY:RSA
PRIVKEY:ANY
PRIVKEY_GEN:RSA
PUBKEY:RSA
PUBKEY:ANY
PRIVKEY_SIGN:RSA_EMSA_PKCS1_NULL
PUBKEY_VERIFY:RSA_EMSA_PKCS1_NULL
PRIVKEY_SIGN:RSA_EMSA_PKCS1_SHA1
PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA1
PRIVKEY_SIGN:RSA_EMSA_PKCS1_SHA224
PRIVKEY_SIGN:RSA_EMSA_PKCS1_SHA256
PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA224
PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA256
PRIVKEY_SIGN:RSA_EMSA_PKCS1_SHA384
PRIVKEY_SIGN:RSA_EMSA_PKCS1_SHA512
PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA384
PUBKEY_VERIFY:RSA_EMSA_PKCS1_SHA512
PRIVKEY_SIGN:RSA_EMSA_PKCS1_MD5
PUBKEY_VERIFY:RSA_EMSA_PKCS1_MD5
PRIVKEY_DECRYPT:ENCRYPT_RSA_PKCS1
PUBKEY_ENCRYPT:ENCRYPT_RSA_PKCS1
CERT_DECODE:X509
PUBKEY:RSA (soft)
PUBKEY:ECDSA (soft)
PUBKEY:DSA (soft)
CERT_DECODE:X509_CRL
CONTAINER_DECODE:PKCS7
CONTAINER_DECODE:PKCS12
DH:ECP_256
DH:ECP_384
DH:ECP_521
DH:ECP_224
DH:ECP_192
DH:ECP_224_BP
DH:ECP_256_BP
DH:ECP_384_BP
DH:ECP_512_BP
PRIVKEY:ECDSA
PRIVKEY_GEN:ECDSA
PUBKEY:ECDSA
PRIVKEY_SIGN:ECDSA_WITH_NULL
PUBKEY_VERIFY:ECDSA_WITH_NULL
PRIVKEY_SIGN:ECDSA_WITH_SHA1_DER
PUBKEY_VERIFY:ECDSA_WITH_SHA1_DER
PRIVKEY_SIGN:ECDSA_WITH_SHA256_DER
PUBKEY_VERIFY:ECDSA_WITH_SHA256_DER
PRIVKEY_SIGN:ECDSA-256
PUBKEY_VERIFY:ECDSA-256
PRIVKEY_SIGN:ECDSA_WITH_SHA384_DER
PRIVKEY_SIGN:ECDSA_WITH_SHA512_DER
PUBKEY_VERIFY:ECDSA_WITH_SHA384_DER
PUBKEY_VERIFY:ECDSA_WITH_SHA512_DER
PRIVKEY_SIGN:ECDSA-384
PRIVKEY_SIGN:ECDSA-521
PUBKEY_VERIFY:ECDSA-384
PUBKEY_VERIFY:ECDSA-521
RNG:RNG_STRONG
RNG:RNG_WEAK
...
>> Jun 29 01:33:15 irkalla charon: 04[NET] sending packet: from
>> 2.2.2.2[500] to 1.1.1.1[40108] (38 bytes)
>> Jun 29 01:33:17 irkalla charon: 08[NET] received packet: from
>> 1.1.1.1[40108] to 2.2.2.2[500] (732 bytes)
>> Jun 29 01:33:17 irkalla charon: 08[ENC] parsed IKE_SA_INIT request 0 [
>> SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N((16431)) N(REDIR_SUP)
>> ]
>> Jun 29 01:33:17 irkalla charon: 06[NET] received packet: from
>
> This is a retransmit of the original IKE_SA_INIT request (handling this
> fails again).
>
>> 1.1.1.1[40108] to 2.2.2.2[500] (924 bytes)
>> Jun 29 01:33:17 irkalla charon: 06[ENC] parsed IKE_SA_INIT request 0 [
>> SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N((16431)) N(REDIR_SUP)
>> ]
>
> This is the request with the new DH group.
>
>> Jun 29 01:33:18 irkalla charon: 06[IKE] 1.1.1.1 is initiating an
>> IKE_SA
>> Jun 29 01:33:18 irkalla charon: 06[IKE] remote host is behind NAT
>> Jun 29 01:33:18 irkalla charon: 06[ENC] generating IKE_SA_INIT
>> response
>> 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
>> Jun 29 01:33:18 irkalla charon: 06[NET] sending packet: from
>> 2.2.2.2[500] to 1.1.1.1[40108] (440 bytes)
>
> After sending the IKE_SA_INIT response the client is expected to send
> an
> IKE_AUTH message. If it is too big it gets fragmented into several IP
> messages and some firewalls/routers might drop these. Since the server
> does not receive any IKE_AUTH messages it's likely that this happened.
>
> Try configuring `fragmentation=yes` on the server or select the correct
> CA certificate in the VPN profile on the client to avoid sending lots
> of
> certificate requests.
I've added 'fragmentation=yes' to the server, same issue. Note that both
the iPhone (which always works) and the Android phone (which almost
always fails) are using the same wifi connection behind the same home
internet connection.
How can I select the correct CA certificate in the strongSwan Android
client?
Thank you!
Regards,
Laurens
More information about the Users
mailing list