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.