Been scratching my head over this for a couple of hours now. Time for the experts to take a look ;-)
Everything was working fine with Ubuntu 10.04 (Strongswan 4.3.2). A colleague has updated to Ubuntu 10.10 (Strongswan 4.4.0) and now we get: [IKE] DH group MODP_2048 inacceptable, requesting MODP_1024 Here's the setup: initiator: Strongswan 4.4.0 (Ubuntu 10.10) responder: Strongswan 4.4.1 (Centos 5.5) responder config: config setup # plutodebug=all # crlcheckinterval=600 # strictcrlpolicy=yes # cachecrls=yes nat_traversal=yes charonstart=yes plutostart=yes #conn %default # left=aaa.bbb.ccc.ddd # leftsubnet=111.222.333.444/24 # leftid=@aaa.bbb.ccc.ddd # leftcert=aaa.bbb.ccc.ddd.crt # leftfirewall=yes conn rw-linux-kclark left=aaa.bbb.ccc.ddd leftsubnet=111.222.333.444/24 leftid=@aaa.bbb.ccc.ddd leftcert=aaa.bbb.ccc.ddd.crt leftfirewall=yes right=%any rightsourceip=192.168.100.0/24 rightcert=initiator.crt auto=add The Strongswan documentation indicates that MODP_2048 is supported through the GMP plugin, which is loaded: [root@responder ~]# ipsec listalgs ---<snip>--- Status of IKEv2 charon daemon (strongSwan 4.4.1): uptime: 88 days, since Oct 22 18:56:34 2010 malloc: sbrk 385024, mmap 0, used 229096, free 155928 worker threads: 9 idle of 16, job queue load: 0, scheduled events: 0 loaded plugins: aes des sha1 sha2 md4 md5 random x509 revocation pubkey pkcs1 pgp dnskey pem fips-prf xcbc hmac gmp attr resolve kernel-netlink socket-raw stroke updown eap-identity eap-mschapv2 And the MODP_2048 algorithm is registered: [root@responder ~]# ipsec listalgs ---<snip>--- List of registered IKEv2 Algorithms: encryption: AES_CBC 3DES_CBC DES_CBC DES_ECB integrity: AES_XCBC_96 HMAC_SHA1_96 HMAC_SHA1_128 HMAC_SHA1_160 HMAC_SHA2_256_128 HMAC_MD5_96 HMAC_MD5_128 HMAC_SHA2_384_192 HMAC_SHA2_512_256 hasher: HASH_SHA1 HASH_SHA224 HASH_SHA256 HASH_SHA384 HASH_SHA512 HASH_MD4 HASH_MD5 prf: PRF_KEYED_SHA1 PRF_FIPS_SHA1_160 PRF_AES128_XCBC PRF_HMAC_SHA2_256 PRF_HMAC_SHA1 PRF_HMAC_MD5 PRF_HMAC_SHA2_384 PRF_HMAC_SHA2_512 dh-group: MODP_2048 MODP_2048_224 MODP_2048_256 MODP_1536 MODP_3072 MODP_4096 MODP_6144 MODP_8192 MODP_1024 MODP_1024_160 MODP_768 So why does the responder reject MODP_2048 when it is a supported algorithm? Kevin _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users