possible problem with iptables/ip_conntrack in 2.6.9-22 kernel

[redhat at buglecreek.com]

On Thu, 16 Mar 2006 12:05:18 -0700, "Jared Marcum" <marcum at mers.byu.edu>
said:
> 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 have a problem which appears to be related to iptables, more 
> specifically, maybe ip_conntrack in 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 the same problems with http, https, and ssh. 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
> 
> 
> -- 
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list

I assume that you omited part of your iptables script.  I don't see any
referance to the output chain or the establishment of the user chain
"RH-Firewall-1-INPUT".  If all is good with those items, you can try
iptables -vnL to make sure that the rules that are currently loaded are
what you expect to see.  Also, it looks like you have a log target
before packets are dropped.  Take a look to see what is being logged
right before the packet is dropped.  I think that will give you a pretty
good indication of what the ruleset is seeing and why the packet is not
being accepted before it is dropped.  As you know, you are logging
packets coming into eth1.  You may need to insert another logging rule
if clients are connecting via another interface to really see anything
useful.
Hope it helps.