From: Larsen <larsen007@web.de>
To: development@lists.ipfire.org
Subject: Re: IPsec: Default to rekey=no
Date: Tue, 19 May 2015 17:56:58 +0200 [thread overview]
Message-ID: <op.xyv3w8bncahio0@atl-uetersen.atlantisgmbh.local> (raw)
In-Reply-To: <1432050352.16602.54.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]
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(a)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-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
next prev parent reply other threads:[~2015-05-19 15:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-19 15:19 Larsen
2015-05-19 15:45 ` Michael Tremer
2015-05-19 15:56 ` Larsen [this message]
2015-05-19 16:06 ` Michael Tremer
2015-05-20 8:54 ` Wolfgang Apolinarski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=op.xyv3w8bncahio0@atl-uetersen.atlantisgmbh.local \
--to=larsen007@web.de \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox