Re: nf_conntrack_max

[zrm <zrm@trustiosity.com>]

The default conntrack timeout for UDP streams is 180 seconds, which is 
within that range. The protocols that need that are streams rather than 
transactional protocols like DNS. (Although the other suggestion to 
remove DNS immediately on reply would even cause trouble for DNS, 
because some clients send multiple DNS queries at the same time using 
the same ports, e.g. IPv6 (AAAA) and IPv4 (A) queries, and immediate 
removal would cause the other replies to be lost. One second timeouts 
could do the same.)

The main problem with very short global UDP stream timeouts is for IPsec 
tunnel mode, OpenVPN, or anything else that encapsulates traffic in UDP 
or otherwise needs the UDP entry to continue to exist indefinitely. If 
the app's keepalive interval is shorter than the timeout then packets 
that arrive between the timeout and the keepalive packet go to the bit 
bucket.

Some applications will try to detect that and then shorten the keepalive 
interval (but not all, and generally only after several packets are lost 
with user-visible consequences). And even then the result is more 
deadweight keepalive packets consuming network resources and requiring 
power-expensive radio wakeups on battery-powered user devices.

On 09/05/2016 04:40 AM, André Paulsberg-Csibi (IBM Consultant) wrote:
> I have yet to see any implementation of any FW in 2014 - 2016 that has UDP timeouts in the 2-5 minutes range , as described in RFC 4787 .
>
> IF I remember UDP implementations from a lot of todays firewalls is typically set default timeout to about 30-40 seconds ,
> and despite RFC4787 I would rather recommend having lower timeouts for UDP and higher ones for just those
> protocols that require this than to have 2-5 minutes for UDP which in most cases never last more then 2-4 seconds .
>
> That seems like an unreasonable reverse logic and use of resources , looking at today vs 10-20 years ago's most common UDP traffic patterns .
>
> But yes , I agree on increasing connection table in either case as this was clearly low for such current level of sessions
> and find the root cause for the high amounts of sessions and fix that if possible ...
>
>
>
> Best regards
> André Paulsberg-Csibi
> Senior Network Engineer
> Fault Handling
> IBM Services AS
> andre.paulsberg-csibi@evry.com
> M +47 9070 5988
>
>
>
>
> -----Original Message-----
> From: netfilter-owner@vger.kernel.org [mailto:netfilter-owner@vger.kernel.org] On Behalf Of zrm
> Sent: 2. september 2016 16:48
> To: André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@evry.com>; John Ratliff <jratliff@bluemarble.net>; netfilter@vger.kernel.org
> Subject: Re: nf_conntrack_max
>
>
>
> On 09/02/2016 02:27 AM, André Paulsberg-Csibi (IBM Consultant) wrote:
>
>> In the meantime there is no real issues increasing you the connection table while you figure that out ,
>> and you can also GLOBALY fix the UDP timeouts if you so desire as most likely this can be lowered significantly from
>> the defaults , here you can see one example from a smaller FW then yours ( but still applicable ) :
>>
>> zotac:~ # grep netfilter /etc/sysctl.conf
>> net.netfilter.nf_conntrack_max = 10000
>> net.netfilter.nf_conntrack_tcp_timeout_established = 3600
>> net.netfilter.nf_conntrack_tcp_timeout_close_wait = 40
>> net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 40
>> net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 40
>> net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 40
>> net.netfilter.nf_conntrack_tcp_timeout_time_wait = 40
>> net.netfilter.nf_conntrack_udp_timeout_stream = 60
>> net.netfilter.nf_conntrack_udp_timeout = 10
>
> Global timeouts that short can cause other trouble though. See RFC4787
> Section 4.3 and RFC5382 Section 5. Outside of reducing the timeout only
> for DNS, the best choice is probably just increasing the maximum number
> of conntrack entries (and buying more memory if necessary).
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>