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 michael.tremer@ipfire.org 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-behav...
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@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development