Re: conntrack, idle TCP connection and keep-alives

[Patrick McHardy <kaber@trash.net>]

On Sun, Oct 27, 2013 at 08:14:19PM +0100, Jozsef Kadlecsik wrote:
> On Sun, 27 Oct 2013, Patrick McHardy wrote:
> 
> > 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.
> 
> I think a single flag could be sufficient: if the timer in conntrack goes 
> off and the entry is in the ESTABLISHED state and this flag is not set, 
> then send a TCP keepalive packet and start the timer with a short timeout. 
> If we receive the reply packet, then the long ESTABLISHED timeout value 
> can be restored and the flag cleared.

Sure, I think we wouldn't even need that flag, we can just send the keepalive
and set a short timeout. If a RST is received, the connection is killed
anyway, otherwise it will be refreshed with the ESTABLISHED timeout.

But we do need a timestamp value to pass PAWS.