Am Sa, den 10.01.2004 schrieb Bevan C. Bennett um 02:22: > Alexander Dalloz wrote: > > > Just for the archives: though it is seen so often - just google for > > iptables scripts and you will find it - to use rules for protocol type > > UDP with -m state makes no sense. UDP is, in opposition to TCP, a > > stateless protocoll and this way does not know anything about NEW or > > ESTABLISHED or what else. Hi Bevan! > Untrue! > Well, untrue that using -m state makes no sense with udp. > > It's completely true that UDP is a 'stateless' protocol, but > netfilter/iptables tracks your UDP traffic and assigns state to it. > > See also the following wonderful reference for much more detail: > http://iptables-tutorial.frozentux.net/iptables-tutorial.html#STATEMACHINE >From close reading - you are right! "UDP connections are in them selves not stateful connections, but rather stateless. There are several reasons why, mainly because they don't contain any connection establishment or connection closing; most of all they lack sequencing. Receiving two UDP datagrams in a specific order does not say anything about which order in which they where sent. It is, however, still possible to set states on the connections within the kernel." > As a concrete example, I turned off firewall_mods for ntp (a udp based > protocol) and restarted with an ntp.conf file of only "server > servername". The client -does- recieve the return udp packets, which > means that they must be considered 'ESTABLISHED' by iptables (no other > rule could match them). > > 17:20:34.273828 wallace.ntp > verdandi.internal.avlsi.com.ntp: [udp sum > ok] v4 > client strat 0 poll 6 prec -16 dist 0.000000 disp 0.002944 ref > (unspec)@0.000000000 orig 3282686371.280867010 rec -0.006823999 xmt > +62.992918014 (DF) [tos 0x10] (ttl 64, id 0, len 76) > > 17:20:34.273992 verdandi.internal.avlsi.com.ntp > wallace.ntp: [udp sum > ok] v4 > server strat 2 poll 6 prec -17 dist 0.005920 disp 0.057449 ref > montpelier.ilan.caltech.edu@xxxxxxxxxxxxxxxxxxxx orig > 3282686434.273784995 rec +0.010362999 xmt +0.010373000 (DF) [tos 0x10] > (ttl 64, id 0, len 76) So it's worth to read the documents better. Thanks Bevan. Alexander -- Alexander Dalloz | Enger, Germany PGP key valid: made 13.07.1999 PGP fingerprint: 2307 88FD 2D41 038E 7416 14CD E197 6E88 ED69 5653