Hi,
> There seems to be a problem with tcp-sack and linux nat. I see the same
> behavior as Christian Schwarz (Oct16 2008). Perhaps somebody can help
> to find this bug. :-)
> 13:12:13.121112 IP (tos 0x0, ttl 54, id 10813, offset 0, flags [DF], proto: TCP (6), length: 52) 83.65.185.102.25 > 193.154.214.98.13732: ., cksum 0x96a5 (correct), 3179921459:3179921459(0) ack 62162579 win 32767 <nop,nop,sack 1 {343255345:343256725}>
> 13:12:13.121143 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: TCP (6), length: 40) 193.154.214.98.13732 > 83.65.185.102.25: R, cksum 0x4b37 (correct), 62162579:62162579(0) win 0
> After the first packet from the outside server with "sack" set, the firewall sends a RESET packet.
> This packet is sent by the firewall and not the server behind.
I found the bug myself, and I think I should post the result for the archive.
The linux tcp stack did perfectly right, because the sack sequence number was wrong
and thus the firewall didn't nat the packet but responded with RESET. The kernel
is quite strict with checking sequence numbers, if nf_ct_tcp_be_liberal is not set.
The opposit server had the bug:
Der Server (outside firewall) sent a packet with correct sack.
The firewall on the server side did "seq randomizing", but forgot to change the sack accordingly.
This is a bug of Cisco PIX/ASA from version 7.0(4) till 7.0(6) (see release notes for 7.0(7)).
thanks
AlexT
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
