On 16.03.2010 18:15, pushakk@xxxxxxxxxxxx wrote: > Hello everyone, > > I have a extrange issue with a conntrack entry. There is a nat server > configure in this way > > DMZ 194.139.30.0/23 --- 194.139.30.16 nat 192.168.12.100 ---- > 192.168.12.0/24 private network > > The nat machine does postrouting in all traffic from the private network > to DMZ, and there is no problem but in one server in the DMZ with > windows 2008 server the traffic doesn't return to the origin, I can see > the traffic with tcpdump like this > > 17:19:23.971978 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: > ICMP (1), length: 84) 192.168.12.91 > 194.139.30.62: ICMP echo request, > id 12075, seq 1, length 64 <----- The echo request original OK > > 17:19:23.972094 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: > ICMP (1), length: 84) 194.139.30.16 > 194.139.30.62: ICMP echo request, > id 12075, seq 1, length 64 <------ Masquerade the source IP OK > > 17:19:23.972164 IP (tos 0x0, ttl 128, id 25050, offset 0, flags [none], > proto: ICMP (1), length: 84) 194.139.30.62 > 194.139.30.16: ICMP echo > reply, id 12075, seq 1, length 64 <------- The echo reply OK > > ¿?¿?¿? <----------- Lost echo reply not OK > > There isn't the packet from 194.139.30.16 to 192.168.12.91 despite off > the conntrack table show > > cat /proc/net/ip_conntrack | grep '30.62' > icmp 1 29 src=192.168.12.91 dst=194.139.30.62 type=8 code=0 id=12075 > packets=11 bytes=924 [UNREPLIED] src=194.139.30.62 dst=194.139.30.16 > type=0 code=0 id=12075 packets=0 bytes=0 mark=0 use=1 > > The packet in tcpdump match on the conntrack entry. "id 12075" in both > cases, but if I LOG the traffic with the LOG iptables target I see the > reply in INPUT table not in the FORWARD. > > Thank you and sorry for me bad english. > This behaviour indicates, that conntrack classifies the traffic into state INVALID. Thus it is not natted, as stateful nat needs traffic to be valid for conntrack. I don't know why it happens in that particular case, but you can try to debug it a little more. If your kernel supports it, you can set /proc/sys/net/netfilter/nf_conntrack_log_invalid to 1. -m state --state INVALID -j LOG --log-level debug .... in INPUT/FORWARD. Also providing iptables-save output, kernel version, etc.. is helpful. As this only happens with win2008, you might try to find some IP settings there? Best regards Mart -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
