Multiple Phase 1 Proposals required for Mobile IKEv2 Clients



  • Multiple phase 1 proposals required for Mobile IKEv2

    By design, pfSense 2.3+ restricts all Mobile Clients to the same Phase 1 configuration [VPN / IPsec / Mobile Clients / Edit Phase 1 / Phase 1 Proposal (Algorithms)].

    This implies knowing a “common denominator” for all the devices you intend to connect to your pfSense 2.3+ endpoint.

    Currently, a typical scenario with IOS 9.3.5/10.0.2 clients and Windows 10 clients  is restricted as follow:

    The IOS 9.3.5/10.0.2 Clients will offer the following proposals (as reported by StrongSwan):
      07[CFG] <5> received proposals:
      IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,
      IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256,
      IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536,
      IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
      IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

    The Windows 10 "Autodetect" Clients will offer the following proposals (as reported by StrongSwan)
      06[CFG] received proposals:
      IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
      IKE:3DES_CBC/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_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
      IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
      IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
      IKE:AES_CBC_192/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
      IKE:AES_CBC_192/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
      IKE:AES_CBC_192/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024,
      IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
      IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024,
      IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024

    This leaves exactly two possible configurations for the pfSense 2.3+ Phase 1:
    AES Encryption with SHA1 hash, Diffie-Hellman group 2 reported by StrongSwan as:
      11[CFG] configured proposals:
      IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    OR 3DES Encryption with SHA1 hash, Diffie-Hellman group 2 reported by StrongSwan as:
      11[CFG] configured proposals:
      IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

    If you add to this client base Windows 7 clients explicitly configured for "IKEv2", the choice will be reduced to a single configuration.

    The Windows 7 "IKEv2" Clients will offer the following proposals (as reported by StrongSwan)
      15[CFG] <11> 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

    This leaves 3DES Encryption with SHA1 hash, Diffie-Hellman group 2 as the only configuration that will accommodate all these clients.

    This is not a question of following any specific “HowTo” or configuration guide. If you are not in a position to control the configuration of each client (hotel guests, for example), then the addition of any device that cannot satisfy the common configuration becomes a serious problem.

    This is a pfSense 2.3+ design issue: StrongSwan is capable of offering multiple phase 1 proposals just as the client OS is.

    Can this be fixed?

    Regards,



  • Just for additional info, Android 8 appears to proffer the following:

    IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
    IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
    IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
    IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    IKE:AES_CBC_128/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1024
    IKE:AES_CBC_128/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_1024
    IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
    IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
    IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
    IKE:DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
    IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
    IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024

    Again, this leaves only 3DES/SHA1/MODP1024 as the common cypher which is less than ideal.


Log in to reply