We have that problem for awhile at our site. During the last two days,
I investigated it and I pretty sure that it is cause by the netfilter
firewall. Our backend servers are running RHEL5 and the 'iptables, rule
that accept new connections from the proxy looks like:
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s
iii.jjj.kkk.lll --dport 9005 -j ACCEPT
iii.jjj.kkk.lll is the IP address of the proxy server.
And the last rule of the chain ‘RH-Firewall-1-INPUT’ is:
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
Yesterday I inserted a new rule in between in order to log incoming
packets from the proxy that are going to be rejected. The rule looks
-A RH-Firewall-1-INPUT -s iii.jjj.kkk.lll -j LOG
The result was that for each ‘No route to host’ error logged in the
error_log file on the proxy server, there is a corresponding rejected
packet logged on one of the backend servers. That means that our
‘iptables’ rules need a little bit of tuning.
I thought of two solutions:
- Remove the ‘state match’ test in the ACCEPT rule so the new rule
-A RH-Firewall-1-INPUT -m tcp -p tcp -s iii.jjj.kkk.lll --dport 9005 -j
- Add a new rule to ‘iptables’ which issues a REJECT with options
‘tcp-reset’ for the problematics packets. I hope that the proxy will
reissue the request while receiving the RST flag from the backend. The
rule should be inserted just before the last one and it should look
-m tcp -p tcp -s iii.jjj.kkk.lll --dport 9005 -j REJECT --reject-with
Tonight I will try the solution number 2. If the proxy react as I think
it will, That will be a better solution than the number 1 which I will
try eventually if the solution number 2 won’t work.
Hope that this message will help you.
Sorry for the poor english.
Posted at Nginx Forum: