> If I get some time next week, I'll try and set up a separate server
> and point one of the clients at it.
I'll try to reproduce it on 4.5.0. If it is possible, we probably can
write a patch that should work with 4.3.2, too.
Regards
Martin
___
Use
Martin,
Thanks for the swift reply.
On 1 December 2010 13:11, Martin Willi wrote:
> Hi Graham,
>
> > selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
> > DH group MODP_2048 inacceptable, requesting MODP_1024
>
> > The client sends back N(INVAL_KE) to the server and we then g
Hi Graham,
> selected proposal: ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
> DH group MODP_2048 inacceptable, requesting MODP_1024
> 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.
The procedure looks corre
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 hacke
