packet filter rules updating

This is my problem.
I have configured iptables for modifying ip source
of syslog packets outgoing from one of my router interfaces. I have used these commands:
iptables -t mangle -A OUTPUT -p udp --dport 514 -j MARK --set-mark 13 iptables -t nat -A POSTROUTING -m mark --mark 13 -j SNAT --to-source 2.2.2.2

With the commands
iptables -t nat -L
iptables -t mangle -L
I can see that the previous rules have been correctly inserted and the syslog
packets have the right ip source.
If I delete the previuos rules, I have no effect on syslog traffic and also if I
give new iptables command with different ip source
(Es. iptables -t nat -A POSTROUTING -m mark --mark 13 -j SNAT --to- source 3.3.3.3)
syslog pkt maintains the previous ip source (2.2.2.2) while no rule is configured
with this ip.
Is there some iptables options that I have to give to force the rules updating?
Thanks a lot for your collaboration!
Monia Cheli

La gara più entusiasmante dell'anno!

Gioca e corri alla velocità della luce sui 18 circuiti di Intel Speed Contest 2006!

I più bravi vincono Notebook Sony VAIO, iPod da 60 GB e altro ancora...

Sfida gli amici!

http://intelspeedcontest2006.tiscali.it/

Hello,

[...]

The reason of this apparently (but only apparently) unexpected behaviour is explained in chapter 5 of the NAT-HOWTO http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-5.html :

"At each of the points above, when a packet passes we look up what connection it is associated with. If it's a new connection, we look up the corresponding chain in the NAT table to see what to do with it. The answer it gives will apply to all future packets on that connection."

So, once a NAT operation has been associated to a connection and as long as the connection exists (or, at least, as long as Netfilter connection tracking keeps track of that connection), the same NAT operation applies to every packet belonging to that connection. This is independant of any subsequent iptables rule modification.

No, iptables cannot help you on this. All you can do is close the affected connection to delete the entry in the conntrack table and the NAT operation associated to it. When a new connection is established, the new NAT rule will apply to it.

No, the problem is that NAT rules are only used for the first packet in a connection, and the conntrack table entry hasn't timed out.

You can delete the entry using the conntrack tool (requires a recent kernel and you may need to get the conntrack tool source from svn.)