Hi All, Up till recently, we have been setting up tunnels between client and server using DH Group 2 (aka MODP_1024). We are starting to transition over to DH Group 14 (aka MODP_2048) and are coming up against problems. I'm hoping someone can please shed some light ?
The clients are using a hacked version of strongSwan 4.3.6, the server a hacked version of strongSwan 4.3.2. We want to support a mixed set of clients, some using 1024-bit DH and the rest using 2048-bit DH. The initial tunnels come up fine. If we set the clients to perform periodic rekeying, everything stays fine. However, those clients that do NOT perform periodic rekeying are kicking back when the server eventually lifetime rekeys. So, when the client sets up the tunnel, it sets: ike=aes-sha-modp1024! esp=aes-sha1-modp1024,aes-sha1! The server config is set up thus: conn %default ikelifetime=24h keylife=8h rekeymargin=3m keyingtries=1 keyexchange=ikev2 dpdaction=clear dpddelay=270 left=foo.bar.com left...@foo.bar.com leftsubnet=0.0.0.0/0 esp=aes-sha1-modp2048,aes-sha1-modp1024 mobike=no auto=add conn certs-only authby=rsasig leftcert=sgw.pem right...@*.bar.com rightsourceip=10.13.0.0/24 As the initial tunnel comes up, the client logs: 16[CFG] received proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 16[CFG] configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 16[CFG] selected proposal: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 and: 12[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ 12[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ 12[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ Eight hours later, the server decides to rekey and we see the client log: 08[ENC] parsed CREATE_CHILD_SA request 0 [ N(REKEY_SA) SA No KE TSi TSr ] 08[LIB] size of DH secret exponent: 2047 bits 08[CFG] looking for a child config for 10.13.0.98/32 === 0.0.0.0/0 08[CFG] proposing traffic selectors for us: 08[CFG] 10.13.0.98/32 (derived from dynamic) 08[CFG] proposing traffic selectors for other: 08[CFG] 0.0.0.0/0 (derived from 0.0.0.0/0) 08[CFG] candidate "conn_1" with prio 5+5 08[CFG] found matching child config "conn_1" with prio 10 08[CFG] selecting proposal: 08[CFG] no acceptable DIFFIE_HELLMAN_GROUP found 08[CFG] selecting proposal: 08[CFG] proposal matches 08[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/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 08[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ 08[CFG] selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ 08[KNL] getting SPI for reqid {3} 08[KNL] got SPI c4beec6b for reqid {3} 08[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024 08[ENC] added payload of type NOTIFY to message As far as I can make out, the server has proposed "aes-sha1-modp2048" and "aes-sha1-modp1024" (and extra ones), the client has recognised that it can accept "aes-sha1-modp1024" and "aes-sha1" and chosen from the proposals to accept "aes-sha1-modp1024" but then barfed. The client sends back N(INVAL_KE) to the server and we then get into an endless cycle of trying to renegotiate the tunnel rekey. Is this because I have made the client specify "esp=aes-sha1-modp1024,aes-sha1!" whereas the server is using "esp=aes-sha1-modp2048,aes-sha1-modp1024" ? It will be hard to change the "esp" line used by the client, but it is easy (and desirable) to change the server config. Is there any way I can configure the server to allow clients to renegotiate their DH during a rekey and support a mix of clients that want either 1024-bit or 2048-bit DH ? Or will I have to turn off DH renegotiation during a rekey (by getting the server to use plain "esp=aes-sha1") until I have managed to get all of the clients to transition to using 2048-bit DH only ? Or (and I doubt this) is this a bug in strongSwan ? Regards, Graham.
_______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users