Re: Ugly issue with conntrack

[Juan Antonio <pushakk@limbo.ari.es>]

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@limbo.ari.es 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>