This was definitely not caused by too many connections or the conntrack table being full. In my test setup there were only five people trying to connect... two people who were having the problem and three of us that it worked fine for. Still the strange thing is the exact same iptables setup works fine for everyone involved connecting directly to the Apache server but not going through HAProxy. I also tried a couple other load balancing solutions and got the same result (Apache fine, load balancing solution fail). The only load balancing solution that worked was Apache mod_balancer, but it is too basic for my needs.
Anyway, on the load balancer I don't need a very sophisticated iptables. As long as I can do basic protection and run HAProxy everything will be fine.
-- Joe Torsitano -----Original Message----- From: Willy Tarreau [mailto:w#1wt.eu] Sent: Saturday, December 19, 2009 9:58 PM To: John Lauro Cc: 'Joe Torsitano'; haproxy#formilux.org Subject: Re: Doesn't work for a very few visitors On Sat, Dec 19, 2009 at 05:14:42PM -0500, John Lauro wrote:Received on 2009/12/20 19:38
> Are you using connection tracking with iptables? If so, you might want to
> consider using a more basic configuration without connection tracking.
Indeed! most likely you have a rule somewhere which does a REJECT on INVALID packets and those poor users are running a buggy TCP stack which breaks window scaling, SACKs or things like this, regularly causing some INVALID packets to be detected by the conntrack code. Once I even found a user who was doing all of his browsing using the same TCP source port ! You bet the conntrack has good reasons to complain. The other common issue with conntrack as shipped in common distros is that it's tuned for a desktop system (ie not tuned). And the table fills very fast when you use that on a server. You can easily detect this by messages in kernel logs : "Conntrack table is full". Regards, Willy __________ Information from ESET Smart Security, version of virus signature database 4702 (20091219) __________ The message was checked by ESET Smart Security. http://www.eset.com
This archive was generated by hypermail 2.2.0 : 2009/12/20 19:45 CET