Date: Wed, 08 Aug 2018 19:23:49 +0200 From: Andreas Longwitz <longwitz@incore.de> To: freebsd-net@freebsd.org Subject: natd sends wrong sequence number when a retransmitted PASV packet comes in Message-ID: <5B6B2725.9030306@incore.de>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5B6B2725.9030306>