From owner-freebsd-net@freebsd.org Wed Aug 8 17:23:59 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 794D710637D1 for ; Wed, 8 Aug 2018 17:23:59 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1956B88437 for ; Wed, 8 Aug 2018 17:23:58 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id DA460EE1 for ; Wed, 8 Aug 2018 19:23:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id Lb3NKdCkYQZx for ; Wed, 8 Aug 2018 19:23:49 +0200 (CEST) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 9FACCEC1 for ; Wed, 8 Aug 2018 19:23:49 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id 858C7330 for ; Wed, 8 Aug 2018 19:23:49 +0200 (CEST) Message-ID: <5B6B2725.9030306@incore.de> Date: Wed, 08 Aug 2018 19:23:49 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: natd sends wrong sequence number when a retransmitted PASV packet comes in Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 17:23:59 -0000 On a firewall machine I use FreeBSD 10.4-STABLE #0 r331239. I run ipfw/natd as a security guard for my production FTP server. That works fine for many years. But now one of my customers runs his ftp clients in a not very stable environment, so sometimes a few packets are lost. Thats ok and TCP handles this nconspicuous. But there is one exception caused by a possible bug in natd: On in incoming "PASV" my FTP server answers with 227 Entering Passive Mode (195,145,1,138,175,174)\r\n wirshark gives Seq: 415 (4a4a5ed0), Ack: 83, Len: 51 and natd returns this message to the ftp client. If this answer is dropped for what reason ever the client repeats his "PASV" and my FTP server repeats his 227 answer too. Now natd finds that he has the port (175,174) already in his tables and sends a new random port number to the client: 227 Entering Passive Mode (195,145,1,138,195,71)\r\b wirshark gives Seq: 415 (4a4a5ed0), Ack: 83, Len: 50 The bug occurs when natd sends the next packet to the ftp client. This packet must have sequence number 455, but it has 466 and TCP cannot handle this situation, the connection breaks because the client sends RST after some retries. In the example above next packet going out was only an ACK wireshark gives Seq: 466 (4a4a5f03), Ack: 83, Len: 0 I have extended the PrintPacket() function of natd to see the value of th_seq in the verbose output: Out [TCP] 10.2.0.3:21 -> 44.222.180.186:35512 seq:4a4a5ecb aliased to [TCP] 195.145.1.138:21 -> 44.222.180.186:35512 seq:4a4a5ed0 Out [TCP] 10.2.0.3:21 -> 44.222.180.186:35512 seq:4a4a5ecb aliased to [TCP] 195.145.1.138:21 -> 44.222.180.186:35512 seq:4a4a5ed0 Out [TCP] 10.2.0.3:21 -> 44.222.180.186:35512 seq:4a4a5ef9 aliased to [TCP] 195.145.1.138:21 -> 44.222.180.186:35512 seq:4a4a5f03 >From these debug information I can conclude that natd is responsible for the wrong sequence number, the kernel does not change this. This bug occurs every time, when an outgoing 227 packet gets dropped, but only if the length of the second outgoing 227 packet is not equal to the length of the first 227 dropped packet. In the example the length changed form 50 to 51. I also can give some information from alias_ftp.c: First 227 message: ParseFtp227Reply: dlen=46, Entering Passive Mode (10,2,0,3,175,174)\r\n NewFtpMessage: dlen=46, 227 Entering Passive Mode (195,145,1,138,175,174)\r\n slen=51, delta=5, seq=4a4a5ecb, ip_len=98, new_len=103, index=1 Second 227 message: ParseFtp227Reply: dlen=46, Entering Passive Mode (10,2,0,3,175,174)\r\n NewFtpMessage: dlen=46, 227 Entering Passive Mode (195,145,1,138,195,71)\r\n slen=50, delta=5, seq=4a4a5ecb, ip_len=98, new_len=102, index=2 Andreas Longwitz