Don't trust default timeouts

Re:Don't trust default timeouts by faebi on Saturday August 29, 2020 @06:55PM (#24319996)

Timeouts start to get really funny once you start to create lots of UDP Connections while using NAT somewhere in between. Since UDP is connectionless the NAT has no idea whether it will receive any packets anymore and therefore has to keep the port mapping for a certain amount of time. At some point UDP packets will be dropped since these mapping tables can‘t be of unlimited size.

[ Parent | on HN ]

Re:Don't trust default timeouts by herpderperator on Saturday August 29, 2020 @07:18PM (#24320099)

conntrack timeouts don't just apply to UDP:

  net.netfilter.nf_conntrack_dccp_timeout_timewait = 240
  net.netfilter.nf_conntrack_frag6_timeout = 60
  net.netfilter.nf_conntrack_generic_timeout = 600
  net.netfilter.nf_conntrack_gre_timeout = 30
  net.netfilter.nf_conntrack_gre_timeout_stream = 180
  net.netfilter.nf_conntrack_icmp_timeout = 30
  net.netfilter.nf_conntrack_icmpv6_timeout = 30

and even for TCP, there is a timeout after the connection is closed. The fact that UDP has no state and therefore no 'connection' doesn't mean that just because TCP does, that conntrack only tracks it while the connection is open. Besides, you could sever a cable and TCP wouldn't know that anything happened. So you do need timeouts for anything in a NAT table.

[ Parent | on HN ]