LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] Iptables find invalid packets

To: "LinuxVirtualServer.org users mailing list." <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [lvs-users] Iptables find invalid packets
From: Dimitri GOURDON <dgourdon@xxxxxxxxx>
Date: Tue, 22 Jul 2008 10:19:19 +0200
Dimitri GOURDON a écrit :
> Dimitri GOURDON a écrit :
>   
>> Siim Põder a écrit :
>>   
>>     
>>> Hi!
>>>
>>> Dimitri GOURDON wrote:
>>>   
>>>     
>>>       
>>>> A lot of TCP packets with FIN or RST flags (all I think) are dropped by 
>>>> Iptables as state INVALID. The consequence is that I have a lot of 
>>>> connection in FIN_WAIT state (shown by netstat) on the 2 web servers...
>>>>     
>>>>       
>>>>         
>>> I had a similar problem, so I first tried to use the nfct patches to
>>> export IPVS state to netfilter for accurate stateful matching, but that
>>> required tuning conntrack timers, so I wrote an iptables module to match
>>> ipvs packets directly instead (You'd have to recompile kernel/iptables
>>> to use it though):
>>>
>>> http://p6drad-teel.net/~windo/release/pom-ipvs_match.tar.gz
>>>
>>> It seems to work rather well - still some IVALID packets, but I think
>>> those are mainly casued by long and lossy connections (retransmissions).
>>>
>>>   
>>>     
>>>       
>>>> I have reproduced this on my lab...
>>>> I have sniff packets with tcpdump to see flags, ACK number,... I've 
>>>> found nothing bad.
>>>>     
>>>>       
>>>>         
>>> Are all FINs (and RSTs) blocked or only the first ones? To close a
>>> connection, both client and server must send a FIN - does neither of
>>> them get through?
Sorry I've made a mistake...
Here you can see a typically connection :

18:06:09.965832 IP (tos 0x0, ttl 116, id 7416, offset 0, flags [DF], 
proto: TCP (6), length: 48) client.4088 > server.443: S, cksum 0xb9f2 
(correct), 3972343792:3972343792(0) win 65535 <mss 1452,nop,nop,sackOK>
18:06:09.965946 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto: 
TCP (6), length: 48) server.443 > client.4088: S, cksum 0x036f 
(correct), 627997228:627997228(0) ack 3972343793 win 5840 <mss 
1460,nop,nop,sackOK>
18:06:10.000680 IP (tos 0x0, ttl 116, id 7418, offset 0, flags [DF], 
proto: TCP (6), length: 40) client.4088 > server.443: ., cksum 0x4703 
(correct), 1:1(0) ack 1 win 65535
18:06:10.011594 IP (tos 0x0, ttl 116, id 7419, offset 0, flags [DF], 
proto: TCP (6), length: 142) client.4088 > server.443: P 1:103(102) ack 
1 win 65535
18:06:10.011708 IP (tos 0x0, ttl 63, id 24975, offset 0, flags [DF], 
proto: TCP (6), length: 40) server.443 > client.4088: ., cksum 0x2fcd 
(correct), 1:1(0) ack 103 win 5840
18:06:10.012003 IP (tos 0x0, ttl 63, id 24976, offset 0, flags [DF], 
proto: TCP (6), length: 1492) server.443 > client.4088: . 1:1453(1452) 
ack 103 win 5840
18:06:10.012015 IP (tos 0x0, ttl 63, id 24977, offset 0, flags [DF], 
proto: TCP (6), length: 1285) server.443 > client.4088: P 
1453:2698(1245) ack 103 win 5840
18:06:10.087726 IP (tos 0x0, ttl 116, id 7422, offset 0, flags [DF], 
proto: TCP (6), length: 40) client.4088 > server.443: ., cksum 0x3c14 
(correct), 103:103(0) ack 2698 win 65535
18:06:10.103721 IP (tos 0x0, ttl 116, id 7423, offset 0, flags [DF], 
proto: TCP (6), length: 222) client.4088 > server.443: P 103:285(182) 
ack 2698 win 65535
18:06:10.107298 IP (tos 0x0, ttl 63, id 24978, offset 0, flags [DF], 
proto: TCP (6), length: 83) server.443 > client.4088: P 2698:2741(43) 
ack 285 win 6432
18:06:10.167696 IP (tos 0x0, ttl 116, id 7425, offset 0, flags [DF], 
proto: TCP (6), length: 465) client.4088 > server.443: P 285:710(425) 
ack 2741 win 65492
18:06:10.205559 IP (tos 0x0, ttl 63, id 24979, offset 0, flags [DF], 
proto: TCP (6), length: 40) server.443 > client.4088: ., cksum 0x1c3a 
(correct), 2741:2741(0) ack 710 win 7504
18:06:10.226247 IP (tos 0x0, ttl 63, id 24980, offset 0, flags [DF], 
proto: TCP (6), length: 297) server.443 > client.4088: P 2741:2998(257) 
ack 710 win 7504
18:06:10.226330 IP (tos 0x0, ttl 63, id 24981, offset 0, flags [DF], 
proto: TCP (6), length: 40) server.443 > client.4088: F, cksum 0x1b38 
(correct), 2998:2998(0) ack 710 win 7504

*Only this packet is INVALID:
18:06:10.265225 IP (tos 0x0, ttl 116, id 7427, offset 0, flags [DF], proto: TCP 
(6), length: 40) client.4088 > server.443: F, cksum 0x39b4 (correct), 
710:710(0) ack 2998 win 65235

18:06:10.265373 IP (tos 0x0, ttl 63, id 24982, offset 0, flags [DF],
proto: TCP (6), length: 40) server.443 > client.4088: ., cksum 0x1b37
(correct), 2999:2999(0) ack 711 win 7504*
18:06:10.270735 IP (tos 0x0, ttl 116, id 7428, offset 0, flags [DF],
proto: TCP (6), length: 40) client.4088 > server.443: ., cksum 0x39b3
(correct), 711:711(0) ack 2999 win 65235
>>>> I have tried to accept these packets with Iptables and then, all my 
>>>> connections are terminated in a normal way (only 1-2 connection(s) stay 
>>>> in FIN_WAIT on web servers).
>>>>     
>>>>       
>>>>         
>>> The problem (sort of) is that LVS code isn't really very well integrated
>>> with netfilter code. This allows for IPVS to work faster, but causes
>>> these kinds of problems as well.
>>>
>>> Siim
>>>
>>> _______________________________________________
>>> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>>> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
>>> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>>>   
>>>     
>>>       
>> _______________________________________________
>> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
>> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>>   
>>     
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://lists.graemef.net/mailman/listinfo/lvs-users
>   



<Prev in Thread] Current Thread [Next in Thread>