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
