Hi Mart,
thank you very much for your reply, I will look for INVALID STATE doc
and try LOG this traffic. I suposse the issue is related with the
windows 2008 server because if I config the same public ip to another
server this reply the echoes corectly so I think it's not a intrinsic
netfilter issue.
I suposse the problem is in some special config in the 2008 server, this
is a client machine so I have no access to the system.
Thank you.
El 17/03/10 16:33, Mart Frauenlob escribió:
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.http://www.google.com/firefox
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
--
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
