[rhn-users] possible problem with ip_conntrack_ftp ESTABLISHED

[Jared Marcum]

Jared Marcum wrote:
> 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.

Actually it appears to be more than just ftp. I'm also seeing the 
problem with http and ssh.

> 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