From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: AW: IPsec: Default to rekey=no Date: Wed, 20 May 2015 13:30:00 +0200 Message-ID: <1432121400.16602.78.camel@ipfire.org> In-Reply-To: <008801d0925e$d68ed390$83ac7ab0$@apolinarski.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2104507099151492807==" List-Id: --===============2104507099151492807== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, On Tue, 2015-05-19 at 20:08 +0200, Wolfgang Apolinarski wrote: > Hi! >=20 > I first want to say that I do not like the standard configuration of ipsec = in=20 > ipfire, because I am mainly using Windows and Android clients (phone/PC) an= d=20 > the standard configs just do not work with that. This is why I added some=20 > configuration templates to the ipfire wiki (which are mostly taken from the= =20 > Strongswan docu with some added information specific to ipfire). Indeed is it quite complicated to have one generic configuration for both, the net-to-net connections and all roadwarrior connections. We will get in inter-operability hell. Luckily this has become much better with strongswan. > When rekey is set to no, the server does not initiate any rekey, which is=20 > mandatory for Windows, because Windows does not like the server to take the= =20 > initiative. Windows clients are initiating the rekey every 58-59 minutes=20 > (according to the strongswan docu, I did not check that in the logs). >=20 > There is (at least one) other alternatives than rekey=3Dno: > Set the lifetime of the child SA to something like 90 minutes. Then Windows= =20 > clients initiate the rekey after 58-59 minutes and rekey can be set to yes. >=20 > One could also set rekey=3Dno, but fix the lifetime of the CHILD_SA. The=20 > CHILD_SA is then thrown away and the client needs to rekey (and apparently = > does so). If I understand the strongswan docu [1] correctly, the default is= =20 > set to 1h (attention to the margin!) and should also be used when rekey=3Dn= o. So=20 > rekey=3Dno is a safe setting, security wise (someone should test this behav= ior,=20 > though). I can live with either of those two options. If we find a way that we can kill the connection when the client does not rekey in a certain time that we get rid of the need to rely on the client to rekey. We cannot trust that the client will do this. There is also a related bug over here: https://wiki.strongswan.org/issues/945 This one points out that rekey=3Dno is different for IKEv1 and IKEv2. > If connecting two ipfire devices via ipsec is one of the user scenarios tha= t=20 > should be supported, a default setting of rekey=3Dno might not make sense s= ince=20 > both ipfire devices would not rekey, i.e., the connection would be dropped.= A=20 > longer CHILD_SA lifetime could be an alternative. There is no need to have rekey=3Dno for the net-to-net connections. > What is on my whish list: > An option menu when creating a new ipsec vpn connection that offers specifi= c=20 > configurations (Windows 7 (X.509 Machine Auth), Windows Phone (X.509 User A= uth=20 > over EAP-TLS), Android (IKEV1, X.509, xauth)). > I did not add this, because of a) time and b) my weird configuration that u= ses=20 > the ipfire DHCP and ends the tunnel directly in the green network (which - = > from what I understood while reading the old documentation - is not the nor= mal=20 > configuration). I too have a very long wishlist with IPsec features. More authentication methods to enhance compatibility with more mobile devices is definitely on the list, but also tough to realise if you do not have a central user management system. > > On Tue, 19 May 2015 18:06:06 +0200, Michael Tremer > > wrote: > (...) > > IPsec has always had these woes. That is the main reason why those awful > > SSL VPN solutions exist. >=20 > Yes! :-) >=20 > Cheers, > Wolfgang >=20 > [1] https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey -Michael --===============2104507099151492807== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIKCmlRSWNCQUFC Q2dBR0JRSlZYSEE0QUFvSkVJQjU4UDl2a0FrSHhDMFFBTEd4M3d6bkptaTNqbjB0TWVNR2FMZHQK bFZYNWVnaHpPQWlrelpmeDZYVEpsK0R5N29lS0RyRThMcU1pT09NMGt3MDFQSXZKWVBlTjVkQUU5 bS9MakdCVAo1d0hUT1M5TXNHa2ZiWjhyYUQvQm02ekdoT3JzV2psd0NUM1dHNm03dHZjSldyWmVs QitRSzNHeEVsZjlZR2M4CjhHTUlUeFN4Y0IyTWc3OEF1REUzUWl4bWJpK3hTZEdXbXdYckdtTjFF SE03d3U1UlJzTnNxR3NtWGVKUkdHOFUKVVk4T3JBbWpPbnM4czNxK2RGTnJGT1Z5VlJJOHdxdUhV eGpBQlZ4Z09ic2RwVDZzL3djYnRNb084ZFlzVmp6Kwp5Ylczc2ZuclMwMTQ1R0ZISmd3NU4xTCtJ UWh5S0xYbDRXc010TVZSL1ZzR2NwcERCUlZVSjFRUUNSYnh4QkdXCi9Wejl5VU9zVEx3amRINU1y RnFsbUJxRWkwWWhFZ1F2eDBPSEdGWSsxMEFDZWVGMTZrcmdVS1BhQldFWEliY04KMXJ1RnhtbXda KzgxdGlnZFI4Sklvb2dOTjZjdDFVU1o4bXlqQWxRMGVQaFV4U0NEdmRpc2IxMWtnblhGTXZvVQo3 TGM5ZjVnZ0pRblVMZFpvczFLV0hyMmdpK2xNVUI4ZzA4dkdsNUQvOERhZ0p3YkhhOW1SRzdwZTky bitRc2lxCk1JZVJocGo3YnhrSnRsMHhIeDAxdFVlSnVtRGprQnd3bldGVTJ2dHJYaGVsSGhsU3pO Y0x1NUxISS9VaGo1UDUKUXVGcEgxaHZnZHdubWRjNUtsYnFxbEprOUI3M2dqVzFkNEY4OHR0ZHU2 T3VsZlZIbmZzUk9DbVBibm1kc25FbApOaTFzSUxqNS90eU52SUlWYlFBawo9MW50TwotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============2104507099151492807==--