Netfilter conntrack problem...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hi folks,

I have the following in my firewall (condensed version)
[CentOS 4.2: 2.6.9-11.EL.i686 kernel]:

INPUT:
--state ESTABLISHED,RELATED -j ACCEPT
-p tcp -j REJECT --reject-with tcp-reset
-j REJECT

OUTPUT: ACCEPT

The connection is over a wireless link so packets _do_ get dropped even 
though throughput is around 100-400 kB/s (depending on 
atmospheric conditions, etc.)

Now I've noticed that sometimes connections are broken, I've narrowed the 
problem down to _this_ firewall (as in it's not the only one, but I'm 
pretty sure that it's at fault here...)

Tcpdumping a "ssh somewhere cat /dev/zero > /dev/null" session on the 
firewall to an external host (a few hops away, reliable links, except for 
the single wireless link) on a prematurely terminated connection reveals 
the following (near the very end):

# tcpdump -i eth1 host $TARGET -n -nn
SRC=$FIREWALL:38945
DST=$TARGET:22
(all stream counts (acks) where 1728xxxxx so 1728 has been replaced with 
nil to gain on readability...)

034006 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026606 
838569311,nop,nop,sack sack 3 {11403:12851}{07059:09955}
068320 IP DST > SRC: . 12851:14299(1448) ack 85975 win 8576 
<nop,nop,timestamp 838569322 603026606>
068421 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026641 
838569311,nop,nop,sack sack 3 {11403:14299}{07059:09955}
101781 IP DST > SRC: P 14299:15747(1448) ack 85975 win 8576 
<nop,nop,timestamp 838569325 603026641>
101879 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026674 
838569311,nop,nop,sack sack 2 {11403:18643}{07059:09955}
133870 IP DST > SRC: . 18643:20091(1448) ack 85975 win 8576 
<nop,nop,timestamp 838569328 603026674>
133969 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026706 
838569311,nop,nop,sack sack 2 {11403:20091}{07059:09955}
164262 IP DST > SRC: . 20091:21539(1448) ack 85975 win 8576 
<nop,nop,timestamp 838569332 603026706>
164358 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026737 
838569311,nop,nop,sack sack 2 {11403:21539}{07059:09955}
198287 IP DST > SRC: . 21539:22987(1448) ack 85975 win 8576 
<nop,nop,timestamp 838569335 603026737>
198386 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026771 
838569311,nop,nop,sack sack 2 {11403:22987}{07059:09955}
230168 IP DST > SRC: . 22987:24435(1448) ack 85975 win 8576 
<nop,nop,timestamp 838569338 603026771>
230285 IP SRC > DST: . ack 05611 win 23688 <nop,nop,timestamp 603026803 
838569311,nop,nop,sack sack 2 {11403:24435}{07059:09955}
252786 IP DST > SRC: . 05611:07059(1448) ack 85975 win 8576 
<nop,nop,timestamp 838569340 603026771>
252857 IP SRC > DST: R 1475625677:1475625677(0) win 0


As far as I can tell, the second to last packet is perfectly valid - it is 
a valid retransmit of a missing/dropped piece.  For some reason it results 
in a reset being sent from the tcp-reset rule (counter increases).  Thus 
it would seem the packet is not matching the ESTABLISHED rule.  Any ideas?

Is this a bug?  Has this been fixed in a/the newer kernel (I've got 156 
days of uptime and a lot of junk on the box so I don't really want to 
reset it... :( )

Is the firewall configuration above correct - ie. is that a valid spot to 
generate TCP Resets?  I doubt DROP'ing the packets will help since it'll 
just cause a stall, with future retransmits not getting through due to not 
matching as ESTABLISHED anyway...

Cheers,
MaZe.


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux