What Is Nf_conntrack_udp_timeout?

nf_conntrack_udp_timeout is a Linux kernel parameter that specifies the timeout, in seconds, for connection tracking entries of non-streaming User Datagram Protocol (UDP) traffic. The value of this parameter determines how long the kernel will "remember" a UDP communication flow after the last packet has been seen. This tracking is critical for stateful firewalls (like iptables and nftables) and Network Address Translation (NAT) to function correctly.

Connection tracking and UDP

Connection tracking, or conntrack, is a core component of the Linux kernel's Netfilter framework. It maintains a table of all active network connections and is used by various networking functions, such as firewalls and NAT.

For connection-oriented protocols like TCP, tracking is based on the protocol's state machine (e.g., SYN, SYN-ACK, ESTABLISHED). UDP, however, is a connectionless protocol. This means there is no explicit handshake to start or end a communication. Therefore, the conntrack module must use a timeout-based approach to determine when a UDP flow is no longer active. This prevents the connection tracking table from filling up with stale entries.

The conntrack module uses two separate timeouts for UDP traffic:

• nf_conntrack_udp_timeout: The timeout for "unanswered" UDP packets. This applies to a new UDP flow where a packet has been sent out but no reply has yet been received. The default value is typically 30 seconds.
• nf_conntrack_udp_timeout_stream: The timeout for "established" UDP streams. Once a request-and-reply exchange has been detected, indicating an active flow, this extended timeout is used. The default value is typically 120 seconds.

How UDP timeouts work in practice

To illustrate how these timeouts work, consider a client and a server communicating over UDP:

1. Initial packet (unanswered state): A client sends a UDP packet to a server.
2. nf_conntrack_udp_timeout starts: The kernel creates a new conntrack entry for this flow and starts the nf_conntrack_udp_timeout timer (default 30 seconds). The firewall will allow the server's reply packet, as it is expected based on this entry.
3. Reply packet (stream state): If the server replies within 30 seconds, the kernel recognizes the two-way communication.
4. nf_conntrack_udp_timeout_stream starts: The flow is now considered an "established stream," and the kernel switches to the longer nf_conntrack_udp_timeout_stream timer (default 120 seconds).
5. Subsequent packets (reset timer): Any new packet in either direction for this flow resets the nf_conntrack_udp_timeout_stream timer.
6. Expiration: If no packets for the flow are seen for the duration of the timeout, the conntrack entry is removed, and future packets for that flow are treated as new connections.

Configuration and tuning

The values for nf_conntrack_udp_timeout and nf_conntrack_udp_timeout_stream can be adjusted using the sysctl command. This is often necessary for servers that handle a large volume of concurrent connections or specific types of UDP traffic, such as Voice over IP (VoIP).

Viewing current settings

To view the current values, use sysctl:

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream

Use code with caution.

Changing settings temporarily

To change a value until the next reboot, use sysctl -w:

# Set UDP timeout to 60 seconds
sysctl -w net.netfilter.nf_conntrack_udp_timeout=60
# Set UDP stream timeout to 180 seconds
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=180

Use code with caution.

Making changes persistent

To make the changes permanent, edit the /etc/sysctl.conf file or a file in /etc/sysctl.d/:

echo "net.netfilter.nf_conntrack_udp_timeout = 60" >> /etc/sysctl.conf
echo "net.netfilter.nf_conntrack_udp_timeout_stream = 180" >> /etc/sysctl.conf
sysctl -p

Use code with caution.

Implications of tuning

Adjusting these timeout values has several important implications:

• Higher timeouts:
  • Pros: Improves reliability for applications with long pauses in UDP communication, such as some VoIP or gaming. It prevents legitimate packets from being dropped.
  • Cons: Keeps connections in the conntrack table longer. This increases memory usage and can lead to the table filling up, especially on busy systems, which can cause connection drops for new traffic. Longer timeouts can also make a system more vulnerable to denial-of-service (DoS) attacks.
• Lower timeouts:
  • Pros: Reduces memory consumption and makes the conntrack table more resistant to flooding. This can be beneficial for high-traffic servers.
  • Cons: Can cause legitimate, but idle, UDP flows to be prematurely terminated by the firewall. This may break applications that rely on persistent, though infrequent, communication.

Common use cases for tuning

• VoIP and media streaming: Many UDP-based media applications can experience pauses. Increasing the udp_timeout_stream can prevent audio or video sessions from being prematurely dropped.
• High-traffic NAT gateways: On routers or firewalls with a large number of clients, reducing UDP timeouts can prevent the conntrack table from overflowing, which improves overall network performance.
• DoS mitigation: Lowering timeouts can limit the impact of UDP flood attacks, as stale entries from attack traffic are cleared more quickly.
• Game servers: Some multiplayer games use UDP for real-time communication. Increasing timeouts can prevent connectivity issues when a player is momentarily inactive.