DH group MODP_2048 inacceptable, requesting MODP_1024

[Kevin Clark]

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:

[***@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:

[***@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

[Martin Willi]

Hi Kevin,

Post by Kevin Clark
[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024
So why does the responder reject MODP_2048 when it is a supported algorithm?

MODP_2048 must not only be supported, it also must be contained in the
configured IKE proposal. As you didn't specify any ike= keyword in
ipsec.conf, it actually should, and I don't see why the responder
doesn't accept it.

Could you increase the log level of "cfg" to 2 (see [1]) and send us the
responder log?

Regards
Martin

[1]http://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration

[Kevin Clark]

Post by Martin Willi
MODP_2048 must not only be supported, it also must be contained in the
configured IKE proposal. As you didn't specify any ike= keyword in
ipsec.conf, it actually should, and I don't see why the responder
doesn't accept it.
Could you increase the log level of "cfg" to 2 (see [1]) and send us the
responder log?

Thank you Martin. Here is the log:

Jan 20 23:51:40 responder charon: 09[NET] received packet: from iii.iii.iii.iii[33396] to aaa.bbb.ccc.ddd[500]
Jan 20 23:51:40 responder charon: 09[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Jan 20 23:51:40 responder charon: 09[CFG] looking for an ike config for aaa.bbb.ccc.ddd...iii.iii.iii.iii
Jan 20 23:51:40 responder charon: 09[CFG] candidate: aaa.bbb.ccc.ddd...%any, prio 5
Jan 20 23:51:40 responder last message repeated 2 times
Jan 20 23:51:40 responder charon: 09[CFG] candidate: aaa.bbb.ccc.ddd...%any, prio 5
Jan 20 23:51:40 responder charon: 09[CFG] candidate: aaa.bbb.ccc.ddd...%any, prio 5
Jan 20 23:51:41 responder charon: 09[CFG] found matching ike config: aaa.bbb.ccc.ddd...%any with prio 5
Jan 20 23:51:41 responder charon: 09[IKE] iii.iii.iii.iii is initiating an IKE_SA
Jan 20 23:51:41 responder charon: 09[CFG] selecting proposal:
Jan 20 23:51:41 responder charon: 09[CFG] proposal matches
Jan 20 23:51:41 responder charon: 09[CFG] received proposals: IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/AES_XCBC_96/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_MD5_96/HMAC_SHA2_384_192/HMAC_SHA2_512_256/PRF_AES128_XCBC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/PRF_HMAC_MD5/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/ECP_256/ECP_384/ECP_521/ECP_224/ECP_192/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160
Jan 20 23:51:41 responder charon: 09[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Jan 20 23:51:41 responder charon: 09[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Jan 20 23:51:41 responder charon: 09[IKE] remote host is behind NAT
Jan 20 23:51:41 responder charon: 09[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024
Jan 20 23:51:41 responder charon: 09[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ]
Jan 20 23:51:41 responder charon: 09[NET] sending packet: from aaa.bbb.ccc.ddd[500] to iii.iii.iii.iii[33396]
Jan 20 23:51:44 responder charon: 13[NET] received packet: from iii.iii.iii.iii[33396] to aaa.bbb.ccc.ddd[500]
Jan 20 23:51:44 responder charon: 13[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Jan 20 23:51:44 responder charon: 13[CFG] looking for an ike config for aaa.bbb.ccc.ddd...iii.iii.iii.iii
Jan 20 23:51:44 responder charon: 13[CFG] candidate: aaa.bbb.ccc.ddd...%any, prio 5
Jan 20 23:51:44 responder last message repeated 2 times
Jan 20 23:51:44 responder charon: 13[CFG] candidate: aaa.bbb.ccc.ddd...%any, prio 5
Jan 20 23:51:44 responder charon: 13[CFG] candidate: aaa.bbb.ccc.ddd...%any, prio 5
Jan 20 23:51:44 responder charon: 13[CFG] found matching ike config: aaa.bbb.ccc.ddd...%any with prio 5
Jan 20 23:51:44 responder charon: 13[IKE] iii.iii.iii.iii is initiating an IKE_SA
Jan 20 23:51:44 responder charon: 13[CFG] selecting proposal:
Jan 20 23:51:45 responder charon: 13[CFG] proposal matches
Jan 20 23:51:45 responder charon: 13[CFG] received proposals: IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/AES_XCBC_96/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_MD5_96/HMAC_SHA2_384_192/HMAC_SHA2_512_256/PRF_AES128_XCBC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA1/PRF_HMAC_MD5/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/ECP_256/ECP_384/ECP_521/ECP_224/ECP_192/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160
Jan 20 23:51:45 responder charon: 13[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Jan 20 23:51:45 responder charon: 13[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Jan 20 23:51:45 responder charon: 13[IKE] remote host is behind NAT
Jan 20 23:51:45 responder charon: 13[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024
Jan 20 23:51:45 responder charon: 13[ENC] generating IKE_SA_INIT response 0 [ N(INVAL_KE) ]
Jan 20 23:51:45 responder charon: 13[NET] sending packet: from aaa.bbb.ccc.ddd[500] to iii.iii.iii.iii[33396]
Jan 20 23:51:52 responder charon: 14[NET] received packet: from iii.iii.iii.iii[33396] to aaa.bbb.ccc.ddd[500]
Jan 20 23:51:52 responder charon: 14[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Jan 20 23:51:52 responder charon: 14[CFG] looking for an ike config for aaa.bbb.ccc.ddd...iii.iii.iii.iii
Jan 20 23:51:52 responder charon: 14[CFG] candidate: aaa.bbb.ccc.ddd...%any, prio 5
Jan 20 23:51:52 responder last message repeated 2 times

On a side note, I succeeded in getting a VPN established between the initiator and responder by using a workaround to overcome a broken Ubuntu 10.10 Strongswan default configuration. The *bug* causes multiple charon socket plugins to be registered. The solution was given in your list in the following post:

https://lists.strongswan.org/pipermail/users/2010-October/005384.html

After implementing the workaround the responder logs the following dialog:

Jan 21 08:45:46 responder charon: 13[NET] received packet: from iii.iii.iii.iii[4500] to aaa.bbb.ccc.ddd
[4500]
Jan 21 08:45:46 responder charon: 13[ENC] parsed INFORMATIONAL response 16 [ ]
Jan 21 08:51:25 responder charon: 02[KNL] creating rekey job for ESP CHILD_SA with SPI cf3eef44 and r
eqid {27}
Jan 21 08:51:25 responder charon: 08[IKE] establishing CHILD_SA rw-ubuntu1010{27}
Jan 21 08:51:25 responder charon: 08[CFG] proposing traffic selectors for us:
Jan 21 08:51:25 responder charon: 08[CFG] 10.10.10.0/24 (derived from 10.10.10.0/24)
Jan 21 08:51:25 responder charon: 08[CFG] proposing traffic selectors for other:
Jan 21 08:51:25 responder charon: 08[CFG] 192.168.1.1/32 (derived from dynamic)
Jan 21 08:51:25 responder charon: 08[ENC] generating CREATE_CHILD_SA request 17 [ N(REKEY_SA) SA No T
Si TSr ]
Jan 21 08:51:25 responder charon: 08[NET] sending packet: from aaa.bbb.ccc.ddd[4500] to iii.iii.iii.iii[
4500]
Jan 21 08:51:26 responder charon: 12[NET] received packet: from iii.iii.iii.iii[4500] to aaa.bbb.ccc.ddd
[4500]
Jan 21 08:51:26 responder charon: 12[ENC] parsed CREATE_CHILD_SA response 17 [ SA No TSi TSr ]
Jan 21 08:51:26 responder charon: 12[CFG] selecting proposal:
Jan 21 08:51:26 responder charon: 12[CFG] proposal matches
Jan 21 08:51:26 responder charon: 12[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ

Jan 21 08:51:26 responder charon: 12[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_S
EQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_
CBC_256/HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ
Jan 21 08:51:26 responder charon: 12[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ
Jan 21 08:51:26 responder charon: 12[CFG] selecting traffic selectors for us:
Jan 21 08:51:26 responder charon: 12[CFG] config: 10.10.10.0/24, received: 10.10.10.0/24 => match: 10.0.
0.0/24
Jan 21 08:51:26 responder charon: 12[CFG] selecting traffic selectors for other:
Jan 21 08:51:26 responder charon: 12[CFG] config: 192.168.1.1/32, received: 192.168.1.1/32 => match:
192.168.1.1/32
Jan 21 08:51:26 responder charon: 12[IKE] CHILD_SA rw-ubuntu1010{27} established with SPIs c4ba2d1f
_i cdf2fcf8_o and TS 10.10.10.0/24 === 192.168.1.1/32
Jan 21 08:51:26 responder charon: 12[IKE] closing CHILD_SA rw-ubuntu1010{27} with SPIs c97bc7fb_i (
100079 bytes) cf3eef44_o (1117568 bytes) and TS 10.10.10.0/24 === 192.168.1.1/32

Regards,

Kevin

[Martin Willi]

Post by Kevin Clark
configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
DH group MODP_2048 inacceptable, requesting MODP_1024
generating IKE_SA_INIT response 0 [ N(INVAL_KE) ]

Your responder configuration uses the IKE proposal
ike=aes256-sha1-modp1024!
making modp2048 unacceptable. Please double check ipsec.conf and update
your proposal configuration.

Regards
Martin

[Kevin Clark]

Post by Martin Willi
Your responder configuration uses the IKE proposal
ike=aes256-sha1-modp1024!
making modp2048 unacceptable. Please double check ipsec.conf and update
your proposal configuration.

I have double-checked ipsec.conf and can confirm that an ike configuration is not defined in either a default or specific connection.

In the absence of an ike configuration in ipsec.conf I would have expected all registered algorithms to be supported, but this does not seem to be the case here.