Carlos Pastorino wrote:
Now, commenting on this message: I actually didn't know that the
conntrack table had a limit. Learning something every day. I will
check its value on Monday, during peak time.
A related thought to this, I wonder how many connections are not being closed nicely and then have to hang around in the conntrack table. If you find that you are approaching the limits then you might want to look into the various connection tracking timings.
Another thought: if the ACKs that are being blocked are for some
reason malformed, wouldn't they be blocked as well by the last rule?
The last rule is a log-only rule:
$IPTABLES -A FORWARD -j LOG --log-prefix "FORWARD blocked: "
It's the one generating the log messages we see, therefore we are actually falling off the table and taking the default policy which is 'DROP' ($IPTABLES -P FORWARD DROP)
Also, there really isn't that much to the syn-ack packets, kinda hard to malform them too much.
One other thought to this, if I were to presume the ${variables} and ...ip's then I would presume that the RELATED rules should allow these ack's to go through. The only reason I know of for them not do (again, assuming all the addressing is really ok) would be that the conntrack table has filled up.
To see the maximum connnections that can be tracked:
# cat /proc/sys/net/ipv4/ip_conntrack_max
32760
To see how many you are using at a given moment
# wc -l /proc/net/ip_conntrack
16 /proc/net/ip_conntrack
This from my house and there really isn't all that much going on, I would expect far larger counts, you may need to up ip_conntrack_max. This really out in the SWAG arena because I can't see the details of your installation.
