On Tue, 2015-05-19 at 17:56 +0200, Larsen wrote:
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.
Yes, the client may still trigger creating a new child sa. I just wouldn't trust the client to do that.
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.
Of course the usability would be worse. But I am sure that security is coming first.
IPsec has always had these woes. That is the main reason why those awful SSL VPN solutions exist.
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