James Stephens

Because it lacks sequence numbers, UDP is known as a “stateless” protocol. However, this does not mean we can’t track UDP connections. There is still other useful information we can utilize. Here is an example state table entry for a newly formed udp connection:

udp       17 19 src=192.168.1.2dst=192.168.1.50 sport=1032 dport=53 [UNREPLIED] src=192.168.1.50 dst=192.168.1.2 sport=53 dport=1032 use=1

For a ruleset built on top of a deny-based configuration, this state table entry can only be made if there is an iptables filter rule specifying NEW connections, something like the following rule, which allows NEW connections outbound only (as is often wise):

iptables -A INPUT-p udp -m state –state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -p udp -m state –state NEW,ESTABLISHED -j ACCEPT

Things we can tell from the state table entry are as follows:

• The protocol is udp (IP protocol number 17).
• The state table entry has 19 seconds until it expires.
• Source and destination addresses and ports of original query.
• Source and destination addresses and ports of expected reply. The connection is marked UNREPLIED so this has not been received yet.

Udp timeouts are set in /usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_udp.c at compile time. Here is the relevant section of code:

#define UDP_TIMEOUT (30*HZ)
#define UDP_STREAM_TIMEOUT (180*HZ)

A single request will enter into the state for 30*HZ (generally 30 seconds). In the example above, where we have 19 seconds left, 11 seconds have already elapsed without a reply being received. Once a reply is received, and allowed by a rule permitting ESTABLISHED connections, the timeout is reset to 30 seconds and the UNREPLIED mark is removed. Here we see the connection a couple of seconds after this has taken place:

udp       17 28 src=192.168.1.2
dst=192.168.1.50 sport=1032 dport=53 src=192.168.1.50 dst=192.168.1.2
dport=1032 use=1

If multiple requests and replies occur between the same socket pairs, the entry is considered to be a stream and the timeout changes to 180 seconds. Here we see the connection a few of seconds after this has taken place:

udp       17 177 src=192.168.1.2
dst=192.168.1.50 sport=1032 dport=53 src=192.168.1.50 dst=192.168.1.2 sport=53
dport=1032 [ASSURED] use=1

We can see that the entry is now marked ASSURED. Once connections become ASSURED they are not dropped under heavy load. If the state table is full for example and new connections arrive, entries marked UNREPLIED are preferentially dropped.

There is no absolute timeout for a udp connection (or a tcp connection for that matter), provided traffic keeps flowing.

Recommended Reading