If I understand it corretly, adding "rekey=no" only disables the server trying to rekey, so this is left to the client and should not be a security problem therefore. If this is not added, clients behind a NAT will experience an interruption in their vpn connection. I think this depends on the lifetime of something (ikelifetime? keylifetime?). Anyhow, as long as the server tries to rekey, the connection will be disturbed. In the end, the user might not use IPsec anymore because of that. Lars On Tue, 19 May 2015 17:45:52 +0200, Michael Tremer wrote: > Hi, > > obviously we cannot make this as a default option for anything. The > rekeying is a very important process in the security of a VPN. Without > that brute-force attacks are getting much more feasible and if they > succeed all the data that has been transferred in this session can be > decrypted afterwards. > > The link that you provided does at no point say that disabling rekeying > is a recommended strategy to do that. It just points out some issues and > incompatibilities with the Windows client. > > I CCed Wolfgang Apolinarski who recently worked on this whole matter. He > seems to use the rekey=no option, too. Maybe he can contribute some > insight why this is needed from his point of view. > > Best, > -Michael > > On Tue, 2015-05-19 at 17:19 +0200, Larsen wrote: >> Hi, >> >> we noticed interruptions with our IPsec roadwarrriors. The problem >> turned >> out to be caused by the server trying to rekey with the client that is >> sitting behind a NAT (Windows 7 client at colleague's home). See >> https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#Rekeying-behavior >> >> This was solved by adding "rekey=no" to "/etc/ipsec.user.conf" for each >> connection. >> I wonder if this should be added by IPFire by default as I guess that >> all >> roadwarriors behind a NAT (probably the majority) might have this >> problem. >> >> So, adding >> print CONF "\trekey=no\n"; >> to >> /srv/web/ipfire/cgi-bin/vpnmain.cgi >> >> >> Lars >> _______________________________________________ >> Development mailing list >> Development(a)lists.ipfire.org >> http://lists.ipfire.org/mailman/listinfo/development