iptables and udp socket

Rakupathy_Somasundaram at McAfee.com Rakupathy_Somasundaram at McAfee.com
Wed Aug 10 13:37:29 CEST 2005

Hi Keserű Kornél ,

In your mail ( attached below ) you have said about setting udp conntrack timeout to 0.  I will be glad if you could tell me how to set that ?


I am talking abt this line in your mail ..

socket if I set ip_conntrack_udp_timeout to 0. But for me it seems, it 

iptables and udp socket 
Keserű Kornél keseruk at freemail.hu  <mailto:netfilter%40lists.netfilter.org?Subject=iptables%20and%20udp%20socket%20&In-Reply-To=> 
Mon Aug 1 17:10:48 CEST 2005 
*	Previous message: Fun with the mangle table + LARTC  <061904.html> 
*	Next message: iptables and udp socket  <061905.html> 
*	Messages sorted by: [ date ] <date.html>  [ thread ] <thread.html>  [ subject ] <subject.html>  [ author ] <author.html>  

Hi Krisztian,

thank you for your answer!

In the meantime I played with connection tracking and I found out that
my iptables rules usually work parallel with the UDP traffic on the local 
socket if I set ip_conntrack_udp_timeout to 0. But for me it seems, it 
doesn't really disable udp connection tracking, does it? I think, it only 
sets the timeout to a very low value but the connection is still tracked, 
therefore it may happen that sometimes iptables will fail in my scenario. 
My problem is that I cannot avoid using UDP socket and iptables rule 
installed on the same IP:port.

Is there a better way to "disable" UDP connection tracking and 
therefore to realize stateless behaviour of UDP in my scenario?

Kornel Keseru

  Hi Kornel,

2005-07-19, k keltezéssel 19.23-kor Keserű Kornél ezt írta:
> I'm quite new to netfilter/iptables, I have been using it for some 
> I would like to ask if it may lead to undeterministic behaviour of 
> when an udp socket is opened on an IP:port while in parallel iptables 
> rules (NAT) are setup that forward all incoming packets received on 
> that IP:port to a different destination. So I just want to use the 
> for sending out packets on it, while incoming packets should be 
> forwarded to other destination. But sometimes the packets are 
> received on the socket, sometimes they are forwarded. So iptables 
> don't have always the expected effect.

  This probably derives from the internals of Netfilter connection
tracking and NAT. In Netfilter, the NAT subsystem is completely based 
the conntrack subsystem. That is, when a packet belonging to a 
unknown connection is detected, the conntrack system creates a new
connection. Later the NAT subsystem determines the mapping to be 
onto that connection by looking up the appropriate iptables table/chain.
The final mapping is then stored in the conntrack entry.

  Now imagine the following scenario: you open your 'sending only'
socket (IP_A:PORT_A), and send a UDP packet to IP_B:PORT_B. 
no mapping will be done by the NAT subsystem, as you redirect 
packets only. Now let's see what happens when a packet from 
comes back to IP_A:PORT_A. Since that source-destination pair matches
the conntrack entry of the connection you've just created by sending 
first packet, the conntrack system thinks it simply belongs to that
connection. As there are no NAT mappings associated with that
connection, no address translation will happen.

  So IMHO this method is flawed, you won't be able to get consistent 
reliable operation this way...

  Krisztian Kovacs

[freemail] extra 1GB-os postafiókkal, Önnek már van? http://freemail.hu

More information about the netfilter mailing list