[rhn-users] possible problem with ip_conntrack_ftp ESTABLISHED state in 2.6.9-22 kernel

[Jared Marcum]

I'm new to rhn and RHEL, so I'm not sure if I should ask this question 
on this list or submit a bug, or both. I'm doing both just in case.

I have a problem which appears to be related to the ip_conntrack_ftp
module in iptables for the 2.6.9-22 kernel. I have *no* problems with 
RHEL3U7 and the 2.4.21-40 kernel.

Here's my setup:
RHEL4U2
kernel-2.6.9-22.EL
Contents of /etc/sysconfig/iptables
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -s 10.2.119.0/24 -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp --dport 5353 -d 224.0.0.251 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j
ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j
ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 21 -j
ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 21 -j
ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j
ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 22 -j
ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 53 -j
ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j
ACCEPT
-A RH-Firewall-1-INPUT -i eth1 -j LOG --log-level debug
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

Problem description:
When I ftp data off of my server with the firewall on, it always hangs 
at around 450K of data transferred. It works fine with the firewall off. 
Like I mentioned before, I have no problems with the 2.4.21-40 kernel 
with RHEL3. I tried updating the kernel to 2.6.9-34 and I see the same 
behavior.
I turned on ethereal. The problem always happens when the client starts 
sending duplicate ACKs and the server tries to retransmit the lost 
packets. Another further client communication does not get accepted by 
the firewall and is rejected with the "host administratively down" 
message given by the firewall. /proc/net/ipv4/ip_conntrack still show 
the connection as ESTABLISHED, but the firewall logging shows that the 
same connection is being blocked.
I do not have the same problems http or https traffic. Again, it works 
fine with the same setup on RHEL3 with the 2.4.21-40 kernel.

Any help/guidance would be greatly appreciated.

Thanks,

-- 
Jared Marcum
Brigham Young University
Microwave Earth Remote Sensing
Computer Systems Administrator
marcum at mers.byu.edu
801-422-1105