From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: IPsec: Default to rekey=no Date: Tue, 19 May 2015 17:45:52 +0200 Message-ID: <1432050352.16602.54.camel@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2153777161367726607==" List-Id: --===============2153777161367726607== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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=3Dno 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, >=20 > 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 =20 > sitting behind a NAT (Windows 7 client at colleague's home). See =20 > https://wiki.strongswan.org/projects/strongswan/wiki/Windows7#Rekeying-beha= vior >=20 > This was solved by adding "rekey=3Dno" 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. >=20 > So, adding > print CONF "\trekey=3Dno\n"; > to > /srv/web/ipfire/cgi-bin/vpnmain.cgi >=20 >=20 > Lars > _______________________________________________ > Development mailing list > Development(a)lists.ipfire.org > http://lists.ipfire.org/mailman/listinfo/development --===============2153777161367726607== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIKCmlRSWNCQUFC Q2dBR0JRSlZXMXF6QUFvSkVJQjU4UDl2a0FrSG44Z1AvajljaU5CZjcxMXVTN0o1eCtPK21UYXMK cUhPTVJyQjZEY01Zazk1d2diNWFBRWtTeDlMNDgxUGJaeXRjMStnVG0zbFl4aS9HS3VraThUb0E3 RDMxNnpmegppaXdwSm9idktUS0tRTnRlSEg5U3krbkZOMDR2VmFHWUtleUhZZnhzQm5WQ3FoQjlK QTBTK21NblVZNW03TktPCkw4anlIV2xnVVc2TCs2S1FXNjgyYjNYT2Ruek9YVFhWYVNJRVUxSVEr UFRRN2JScit6TjdxTFg1VitiVEMzU1gKQWpYT2FoUnFlR3dUaDdvV1FySmJjeGNTcWw4d0ZxWHFy b1JzQ1lsV2RVbE82ejgyWmk0WFR1WEhnc1V2MklDLwo1Y2JyblRsMUxaakcwYm9LajFId3NuZk5W ZTFack9aaS9pTjRRMFRMNDVVWmQ1UDB2anQxQVBDS1FpY1BmQWVHCkNXczh4b2VoM0tjaVRMdFRn elBPVGlrRnRJdEpTMUg0Nm1mVWp1Y0ExdEp1ZytxRUx5SHlHK2Z2SmtoWUdibG8KaytpZlIvcm9D UzFleDlpdy9jYjdVaXd5TjZyUlVwQVpxbHJuS25nQjdHbHJhcko3TmYxMHBRTi9PSHRqVnVTagpk ajhRV0V0VSthOGdEazBlWGYyTlJZQkhrQzFxZ1FXT0pEdm1qU09GczBFUS9oazNNaVlOS2J2YzNU WXl5Zlk5Ckd6YXJqQkVhNWwrSjErNVo3ME8vVFR3dGk1ZFZwamJMa1ZpSlV5VnV6allnL0RSUExp Y3I5bzR2Zzc0VnpLUEgKTHUrOGd0ekUzVysrVUtFU1dKVitBTHdmVkdTTmo4ZG1lSUtuSnVITWcz c3pETXErRzRJcmJMaXlaK0dGclZxMwpJTG5UbkV4Z2pxU3piTitTSUV1Ugo9VnFLcQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============2153777161367726607==--