Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Ron Lai]

Hi all,
My 2.6.22.6 Linux box is acting as a NAT device. I found that a NATted FTP 
client is having problem using active mode to connect to a outside FTP 
server. (Passive mode works fine.)

From the trace I could see that the PORT command from the FTP client is 
correctly modified by the Linux box to use the converted NAT address. 
However, the confirmation from the server never makes it to the client and 
the client just keeps retransmitting the PORT command packet.

The interesting part is that active mode can work if the length of the 
actual IP address of the client is the same as the length of the converted 
NAT address. It looks like if there is no TCP sequence number modification 
by the Linux box, the FTP connection can work properly in active mode. I am 
suspecting that there may a problem in the TCP sequence number tracking in 
the kernel modules.

The same settings work fine when I try with Linux 2.6.15 loading 
ip_nat_ftp.ko and ip_conntrack_ftp.ko. Did I miss anything in configuring 
the Linux 2.6.22.6 box?

Regards,
Ron 

Re: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

Please send bugreports to netfilter-devel.

Ron Lai wrote:
> Hi all,
> My 2.6.22.6 Linux box is acting as a NAT device. I found that a NATted 
> FTP client is having problem using active mode to connect to a outside 
> FTP server. (Passive mode works fine.)
> 
>> From the trace I could see that the PORT command from the FTP client is 
> correctly modified by the Linux box to use the converted NAT address. 
> However, the confirmation from the server never makes it to the client 
> and the client just keeps retransmitting the PORT command packet.


Do you mean it never makes it to the FTP client or to the machine
where the client is running?

> The interesting part is that active mode can work if the length of the 
> actual IP address of the client is the same as the length of the 
> converted NAT address. It looks like if there is no TCP sequence number 
> modification by the Linux box, the FTP connection can work properly in 
> active mode. I am suspecting that there may a problem in the TCP 
> sequence number tracking in the kernel modules.
> 
> The same settings work fine when I try with Linux 2.6.15 loading 
> ip_nat_ftp.ko and ip_conntrack_ftp.ko. Did I miss anything in 
> configuring the Linux 2.6.22.6 box?


Works fine here. Please post the dump, ideally from a box in the
middle.

Re: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Ron Lai]

[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]

The packet dump from the 2.6.22.6 box in the middle is attached. In the 
trace 172.16.119.91 is the original IP address of the FTP client and 
172.16.255.123 is the NATted address. The FTP server's address is 
172.16.118.1.

The problem happens between packet 31 and packet 34. Packet 31 indicates 
that the client expects ACK number 0x64b4dda9 for the PORT command it sends. 
However, the ACK number it actually gets is 0x64b4dda8.

Ron
----- Original Message ----- 
From: "Patrick McHardy" <kaber@trash.net>
To: "Ron Lai" <ronlai@cs.stanford.edu>
Cc: <netfilter@vger.kernel.org>; "Netfilter Development Mailinglist" 
<netfilter-devel@vger.kernel.org>
Sent: Tuesday, October 23, 2007 6:17 AM
Subject: Re: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6


> Please send bugreports to netfilter-devel.
>
> Ron Lai wrote:
>> Hi all,
>> My 2.6.22.6 Linux box is acting as a NAT device. I found that a NATted 
>> FTP client is having problem using active mode to connect to a outside 
>> FTP server. (Passive mode works fine.)
>>
>>> From the trace I could see that the PORT command from the FTP client is
>> correctly modified by the Linux box to use the converted NAT address. 
>> However, the confirmation from the server never makes it to the client 
>> and the client just keeps retransmitting the PORT command packet.
>
>
> Do you mean it never makes it to the FTP client or to the machine
> where the client is running?
>
>> The interesting part is that active mode can work if the length of the 
>> actual IP address of the client is the same as the length of the 
>> converted NAT address. It looks like if there is no TCP sequence number 
>> modification by the Linux box, the FTP connection can work properly in 
>> active mode. I am suspecting that there may a problem in the TCP sequence 
>> number tracking in the kernel modules.
>>
>> The same settings work fine when I try with Linux 2.6.15 loading 
>> ip_nat_ftp.ko and ip_conntrack_ftp.ko. Did I miss anything in configuring 
>> the Linux 2.6.22.6 box?
>
>
> Works fine here. Please post the dump, ideally from a box in the
> middle.
> -
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html 

[-- Attachment #2: ftp_test.pcap --]
[-- Type: application/octet-stream, Size: 5737 bytes --]

Re: Problems with nf_nat_ftp.ko and nf_conntrack_ftp.ko in 2.6.22.6

[Patrick McHardy]

Ron Lai wrote:
> The packet dump from the 2.6.22.6 box in the middle is attached. In the 
> trace 172.16.119.91 is the original IP address of the FTP client and 
> 172.16.255.123 is the NATted address. The FTP server's address is 
> 172.16.118.1.
> 
> The problem happens between packet 31 and packet 34. Packet 31 indicates 
> that the client expects ACK number 0x64b4dda9 for the PORT command it 
> sends. However, the ACK number it actually gets is 0x64b4dda8.


Thats really odd. It properly adjusts the sequence number in the
original direction by +1, but incorrectly adjusts the acknowledgement
in the reply direction by -2. I don't see how this could happen with
the vanilla 2.6.22 kernel, are you using any additional patches?

Otherwise please edit net/ipv4/netfilter/nf_nat_helper.c and add
a #define DEBUG at the first line, recompile and post the output
of the failed session (ideally two failed sessions). Thanks.