Well, I did more testing/research today... 1. I've found some posts telling about the bug in the kernel prior to 2.6.13 about ip_conntack and UNREPLIED connections probably related to my problem. Later I've found some posts telling that the bug still appear in most modern kernels. 2. I tryed to reproduce this problem in other inveronment. I've written program that sends udp packets (source and destination ports 4000) similar to those produced by HW pingers. And I felt no problem DNAT'ing packets sent from 2 machines on both 2.6.8 and 2.6.17 kernels. While doing that I've mentioned one strange thing. The output of "tcpdump -v -v" in reproduced case always show different UDP ID for each packet, while in real case it show the same UDP ID for all HW pingers for all packets. Does somebody know that is UDP ID and should it be related to this problem? Just in case: # tcpdump -i br0 port 4000 -v -n tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes 20:58:21.636684 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.22.4000 > 192.168.1.2.4000: UDP, length: 74 20:58:22.888548 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.21.4000 > 192.168.1.2.4000: UDP, length: 74 20:58:23.065247 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.22.4000 > 192.168.1.2.4000: UDP, length: 74 20:58:23.351091 IP (tos 0x0, ttl 64, id 6552, offset 0, flags [none], length: 102) 10.10.100.23.4000 > 192.168.1.2.4000: UDP, length: 74 3. I've played with the router in real case and found out that the problem not always appear. Having the rule: iptables -t nat -A PREROUTING -d 10.10.100.1 -p udp -m udp --dport 4000 -j DNAT --to-destination 192.168.1.2 and doing ifdown br0, then ifup br0, and looking in /proc/net/ip_conntrack: One time I got: udp 17 29 src=10.10.100.23 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.23 sport=4000 dport=4000 use=1 udp 17 28 src=10.10.100.21 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=10.10.100.1 dst=10.10.100.21 sport=4000 dport=4000 use=2 udp 17 29 src=10.10.100.22 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.22 sport=4000 dport=4000 use=1 (note this "src=10.10.100.1" for second rule). 10.10.100.23 and 10.10.100.22 got through. Several next times I got 2 others to work. And finally I got all of them to work: udp 17 29 src=10.10.100.23 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.23 sport=4000 dport=4000 use=1 udp 17 28 src=10.10.100.21 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.21 sport=4000 dport=4000 use=1 udp 17 29 src=10.10.100.22 dst=10.10.100.1 sport=4000 dport=4000 [UNREPLIED] src=192.168.1.2 dst=10.10.100.22 sport=4000 dport=4000 use=1 To conclude, right now I have all packets being DNAT'd like I want, but I guess this is until next reboot :/ -- Покотиленко Костик <casper@xxxxxxxxxxxx> _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
