strange iptables behavior

[Robert Nichols]

Mike McGrath wrote:
> -- sorry bout the last post, this one's got better formatting.
> 
> I've got an odd iptables issue going on.  Here's the setup.  Host A is
> using mod_jk to connect to host B running a tomcat instance on port
> 9009.  It will work fine for a while and then I start getting denies for
> no reason.  When the denies start happening, the website I'm trying to
> bring up freezes in the middle of the page.  If I click stop and reload
> the page sometimes it will come up, sometimes it will not and I will
> continue getting denies.  Also when its in the middle of loading a page
> and it freezes, if I flush all the iptables rules out the page will
> load.  I'm running Fedora Core 3 on both machines, Here are my iptables
> rules:
> 
> ------------------------------------------
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> :RH-Firewall-1-INPUT - [0:0]
> -A INPUT -j RH-Firewall-1-INPUT
> -A FORWARD -j RH-Firewall-1-INPUT
> -A RH-Firewall-1-INPUT -i lo -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 9009
> -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 tcp -p tcp --dport 8009
> -j ACCEPT 
> -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 9080
> -j ACCEPT 
> -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 161 -j
> ACCEPT 
> -A RH-Firewall-1-INPUT -p icmp --icmp-type echo-request -j ACCEPT 
> -A RH-Firewall-1-INPUT -p icmp --icmp-type echo-reply -j ACCEPT 
> -A RH-Firewall-1-INPUT -j LOG --log-level info --log-prefix "IPTABLES --
> DENY "
> -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
> COMMIT
> ------------------------------------------
> 
> 
> These are the Denies:
> 
> 
> ------------------------------------------
> Mar 30 09:27:10 mel kernel: IPTABLES -- DENY IN=eth1 OUT=
> MAC=00:09:6b:ff:45:08:00:07:e9:23:e0:88:08:00 SRC=10.10.0.28
> DST=10.10.0.10 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7193 DF PROTO=TCP
> SPT=41149 DPT=9009 WINDOW=10872 RES=0x00 ACK URGP=0 
> Mar 30 09:27:10 mel kernel: IPTABLES -- DENY IN=eth1 OUT=
> MAC=00:09:6b:ff:45:08:00:07:e9:23:e0:88:08:00 SRC=10.10.0.28
> DST=10.10.0.10 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7195 DF PROTO=TCP
> SPT=41149 DPT=9009 WINDOW=10872 RES=0x00 ACK URGP=0 
> Mar 30 09:27:10 mel kernel: IPTABLES -- DENY IN=eth1 OUT=
> MAC=00:09:6b:ff:45:08:00:07:e9:23:e0:88:08:00 SRC=10.10.0.28
> DST=10.10.0.10 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7197 DF PROTO=TCP
> SPT=41149 DPT=9009 WINDOW=10872 RES=0x00 ACK URGP=0 
> Mar 30 09:27:10 mel kernel: IPTABLES -- DENY IN=eth1 OUT=
> MAC=00:09:6b:ff:45:08:00:07:e9:23:e0:88:08:00 SRC=10.10.0.28
> DST=10.10.0.10 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7199 DF PROTO=TCP
> SPT=41149 DPT=9009 WINDOW=10872 RES=0x00 ACK URGP=0 
> Mar 30 09:27:10 mel kernel: IPTABLES -- DENY IN=eth1 OUT=
> MAC=00:09:6b:ff:45:08:00:07:e9:23:e0:88:08:00 SRC=10.10.0.28
> DST=10.10.0.10 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=7201 DF PROTO=TCP
> SPT=41149 DPT=9009 WINDOW=10872 RES=0x00 ACK
> URGP=0------------------------------------------
> 
> I can't imagine what on earth would be causing this.  Anyone out there
> ever seen this or have any ideas?

Doesn't make a lot of sense to me, either.  Is there any chance you
just have too many connections for the tracker to handle (the limit
is in /proc/sys/net/ipv4/ip_conntrack_max)?

-- 
Bob Nichols         rnichols42 at comcast.net