From: Patrick McHardy <kaber@trash.net>
To: Phil Oester <kernel@linuxace.com>
Cc: WGH <wgh@torlan.ru>, netfilter-devel@vger.kernel.org
Subject: Re: conntrack, idle TCP connection and keep-alives
Date: Sun, 27 Oct 2013 18:38:26 +0000 [thread overview]
Message-ID: <20131027183825.GA17696@macbook.localnet> (raw)
In-Reply-To: <20131027180129.GC27597@macbook.localnet>
On Sun, Oct 27, 2013 at 06:01:30PM +0000, Patrick McHardy wrote:
> On Sun, Oct 27, 2013 at 08:34:09AM -0700, Phil Oester wrote:
> > On Sun, Oct 27, 2013 at 12:14:48AM +0400, WGH wrote:
> > > It seems that, when masquerading, conntrack silently drops idle
> > > connection after nf_conntrack_tcp_timeout_established seconds. This's
> > > pretty terrible, as application inside the network, if it never sends
> > > anything, will never know that connection was dropped.
> >
> > If this is a problem for you, then increase nf_conntrack_tcp_timeout_established
> > to an insanely high value. You do realize, of course, that the conntrack
> > table has a finite number of entries.
> >
> > > RFC 5382 gives us a solution to this:
> > > > A NAT can check if an endpoint for a session has crashed by sending a
> > > > TCP keep-alive packet and receiving a TCP RST packet in response.
> > >
> > > However, it I couldn't find such feature in netfilter. It would be
> > > pretty nice to have.
> >
> > Keepalives should be done in the application, not in the firewall.
>
> Actually I think its a pretty nice idea to reduce breakage introduced
> by NATs. There a millions of embedded devices that use very small timeout
> values to reduce memory usage, at the cost of frequently breaking idle
> connections.
The downside seems to be that we'd need to keep track of timestamp values
to send valid keepalives, which also costs extra memory. I don't think that
cost is justifiable for NAT keepalives alone.
next prev parent reply other threads:[~2013-10-27 18:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-26 20:14 conntrack, idle TCP connection and keep-alives WGH
2013-10-27 15:34 ` Phil Oester
2013-10-27 18:01 ` Patrick McHardy
2013-10-27 18:38 ` Patrick McHardy [this message]
2013-10-27 19:14 ` Jozsef Kadlecsik
2013-10-27 19:20 ` Patrick McHardy
2013-10-27 19:23 ` WGH
2013-10-27 19:32 ` Patrick McHardy
2013-10-27 19:34 ` Patrick McHardy
2013-10-27 19:50 ` Jozsef Kadlecsik
2013-10-27 20:49 ` Jozsef Kadlecsik
2013-10-28 9:29 ` Patrick McHardy
2013-10-27 18:22 ` WGH
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=20131027183825.GA17696@macbook.localnet \
--to=kaber@trash.net \
--cc=kernel@linuxace.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=wgh@torlan.ru \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.