Hi,

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 [i]iii.jjj.kkk.lll[/i] --dport 9005 -j ACCEPT

[i]iii.jjj.kkk.lll[/i] 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 like:

-A RH-Firewall-1-INPUT -s [i]iii.jjj.kkk.lll[/i] -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:

1) Remove the 'state match' test in the ACCEPT rule so the new rule looks like:

-A RH-Firewall-1-INPUT -m tcp -p tcp -s [i]iii.jjj.kkk.lll[/i] --dport 9005 -j ACCEPT

2) 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 like:

-m tcp -p tcp -s [i]iii.jjj.kkk.lll[/i] --dport 9005 -j REJECT --reject-with tcp-reset

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.

Paul