Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

let's look at these two iptables rules which are often used to allow outgoing DNS:

iptables -A OUTPUT -p udp --sport 1024:65535 --dport 53 
   -m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A INPUT -p udp --sport 53 --dport 1024:65535
   -m state --state ESTABLISHED -j ACCEPT

My question is: How exactly should I understand the ESTABLISHED state in UDP? UDP is stateless.

Here is my intuition - I'd like to know, if or where this is incorrect:

The man page tells me this:


This module, when combined with connection tracking, allows access to the
connection tracking state for this packet.

  --state ...

So, iptables basically remembers the port number that was used for the outgoing packet (what else could it remember for a UDP packet?), and then allows the first incoming packet that is sent back within a short timeframe? An attacker would have to guess the port number (would that really be too hard?)

About avoiding conflicts:

The kernel keeps track of which ports are blocked (either by other services, or by previous outgoing UDP packets), so that these ports will not be used for new outgoing DNS packets within the timeframe? (What would happen, if I accidentally tried to start a service on that port within the timeframe - would that attempt be denied/blocked?)

Please find all errors in the above text :-) Thanks,


share|improve this question

2 Answers 2

up vote 6 down vote accepted

So, iptables basically remembers the port number that was used for the outgoing packet (what else could it remember for a UDP packet?),

I am pretty sure for UDP the source and destination ports and addresses are stored.

If you want to inspect the state tables install conntrack and/or netstat-nat.

(What would happen, if I accidentally tried to start a service on that port within the timeframe - would that attempt be denied/blocked?)

Since you are using OUTPUT and INPUT your are talking about local services. The port is already used I don't believe your system will allow you to start up another service since something is already listening on that port. I guess you could stop the first service and start another if you really wanted to though, in that case the response would probably get to your service. What the service does with the packet depends on what the contents of the packet is, and what service it is.

share|improve this answer
So if I started say a Tomcat instance on port 8080, I'll have a 1:(65535-1023) chance that the startup will fail, if accidentally a DNS query is running on the same port? Or will it just wait until the timeframe expired? How long is the timeframe by default? –  Chris Lercher Mar 17 '10 at 0:14
On Linux I believe the ephemeral port range is commonly 32768-61000 (see /proc/sys/net/ipv4/ip_local_port_range) this wouldn't include your example port of 8080. It tends to be very uncommon to setup services to listen on ports within the ephemeral range. The time a UDP entry states in the table is typically 30 seconds (see /proc/sys/net/netfilter/nf_conntrack_udp_timeout) –  Zoredache Mar 17 '10 at 1:08
+1 Thanks, especially for the /proc paths! –  Chris Lercher Mar 17 '10 at 1:32

NB: This answer has been edited.

Despite what the man pages say, ESTABLISHED appears to mean "stateful". For UDP that simply means (as you suggest) remembering each outbound UDP packet (the "src ip, src port dst ip, dst port" tuple) for a while and recognising its responses.

FWIW, my normal rules for DNS traffic would be something like this:

# permit any outbound DNS request (NB: TCP required too)
iptables -A OUTPUT -p udp --sport 1024:65535 --dport 53  -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024:65535 --dport 53  -j ACCEPT

# accept any packet that's a response to anything we sent
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

i.e. control traffic on the OUTPUT chain, and then let the iptables state modules handle everything else on the INPUT chain.

See also this related question.

share|improve this answer
I'm aware that I should allow TCP, too. But what would RELATED mean for UDP? Manpage: "RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, ..." Connections for UDP? Maybe it really makes more sense than ESTABLISHED, but that's what I'd like to find out. –  Chris Lercher Mar 17 '10 at 11:46
When I use your rules, but restrict udp INPUT to RELATED, my DNS queries don't work. Seems that I have to allow ESTABLISHED. Is there any reason to also allow RELATED (for UDP)? –  Chris Lercher Mar 17 '10 at 12:39
ok, it seems that ESTABLISHED means more than the man page says. In any event, if you use OUTPUT filters like mine and don't accept inbonud traffic then that INPUT rule is the only one you'll ever need. –  Alnitak Mar 17 '10 at 13:47
Yeah, the man page is really unclear about these things. But as long as I don't know, if there's any way for an attacker to create a RELATED udp packet (if anything like that exists?) more easily than an ESTABLISHED one, I'd rather be careful with allowing that. My guess is, that RELATED udp packets simply don't exist - in which case your rules are absolutely ok. But I'm not sure. –  Chris Lercher Mar 17 '10 at 13:59
Given what we've found, RELATED udp packets don't exist AFAIK. However (for example) if you ever do outbound FTP from that box you need a RELATED state rule for the data channel. The single "ESTABLISHED,RELATED" rule is AFAIK the most optimal single rule for ingress traffic. –  Alnitak Mar 17 '10 at 14:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.