Hello,
I've run into a problem with ipfilter's FTP NAT proxy (all versions
seem to be affected, v3 and v4): when an FTP client is connected
through the proxy to a server on the Internet and then closes the
control connection by sending a FIN to the server, it never gets the
server's ACK/FINACK response. The socket on the client is then stuck
in the FIN-WAIT-1 state. This only happens with active mode FTP (and
at least one PORT command issued during the lifetime of the control
connection that required adjustment of the IP address/port string
with one of different length).
My attempts at tracing the problem showed that the FTP proxy somehow
incorrectly adjusted its internal sequence number counters after
having seen a segment with the FIN flag set, and from that point
rejected further packets because it deemed their sequence number wrong.
While I have to admit that I don't understand 100% of all the seq/ack
number juggling in ip_ftp_pxy.c, the patch below has fixed the
problem for me. Maybe someone with an in-depth knowledge of the FTP
proxy could take a look at it?
Regards,
Manuel
--- ip_fil4.1.28/ip_ftp_pxy.c.orig 2007-05-10 11:30:39.000000000 +0200
+++ ip_fil4.1.28/ip_ftp_pxy.c 2007-12-15 10:18:38.000000000 +0100
@@ -1111,8 +1111,8 @@
if (tcp->th_flags & TH_FIN) {
if (thseq == f->ftps_seq[1]) {
- f->ftps_seq[0] = f->ftps_seq[1] - seqoff;
- f->ftps_seq[1] = thseq + 1 - seqoff;
+ f->ftps_seq[0] = f->ftps_seq[1];
+ f->ftps_seq[1] = thseq + 1;
} else {
if (ippr_ftp_debug > 1) {
printf("FIN: thseq %x seqoff %d ftps_seq %x
%x\n",
