Centos iptables causing 'No route to host' message

This had me going for a while...

Two machines on the same subnet, client machine pings server machine fine, I can ssh from client to server, but when trying to connect to any other TCP service I get a 'No route to host' message!

I'm staring at the screen thinking "How can the TCP layer possibly have a bearing on routing at the IP layer below?.... that's bonkers". For a minute the long held belief that I had understood the core fundamentals of TCP/IP wavered. Thankfully I spotted a sentence on a blog stating that on some Linux distro's iptables erroneously reported 'No route to host' when dropping packets. Sure enough I checked my iptables rules and all ports were blocked except 22.... phew, sane again :-) 

Solaris TCP Monitoring

netstat -sP tcp - Show TCP stats 
tcpListenDrop and tcpListenDropQ0 should be zero

If either are above zero you need to increase  tcp_conn_req_max_q and tcp_conn_req_max_q0 respectively, for example ... /usr/sbin/ndd -set /dev/tcp tcp_conn_req_max_q = 1200

ndd -get /dev/tcp \? - Tells you what TCP params are available

/usr/sbin/ndd -get /dev/tcp tcp_conn_req_max_q - Gets the value of tcp tcp_conn_req_max_q

Below is an extract from a good Oracle blog (https://blogs.oracle.com/terrygardner/entry/solaris_tcp_ip_parameters_tcp)

tcp_conn_req_max_q and tcp_conn_req_max_q0 are associated with the maximum number of requests that can be accepted per IP address per port. tcp_conn_req_max_q is the maximum number of incoming connections that can be accepted on a port. tcp_conn_req_max_q0 is the maximum number of “half-open” TCP connections that can exist for a port. The parameters are separated in order to allow the administrator to have a mechanism to block SYN segment denial of service attacks on Solaris.
The default value for tcp_conn_req_max_q on Solaris 8 and Solaris 9 is 128, the default value for tcp_conn_req_max_q0 on Solaris 8 and Solaris 9 is 4096. These defaults may be too low for a non-trivial web server, messaging server or directory server installation or any server that expects more than 128 concurrent accepts or 4096 concurrent half-opens. There is only one way to determine appropriate values, though. Read on!
It is pretty simple really: never change these parameters unless connections are refused because the values are too low. The only way to determine this empirically is to use ‘netstat –s | fgrep –i listendrop’. If tcpListenDrop is non-zero, increase tcp_conn_req_max_q. If tcpListenDropQ0 is non-zero, increase tcp_conn_req_max_q0.
Hang on a moment: maybe it is not quite that simple. Increasing tcp_conn_req_max_q to a value that is too high can result in a system that is vulnerable to SYN segment denial of service attacks. Solaris IP is brilliantly executed in this respect due to the separation of these parameters. Increase tcp_conn_req_max_q in increments of 256. Use tcp_conn_req_max_q0 to increase the number of “half-open” TCP connections that are available. If a software cannot service connections quick enough, increasing tcp_conn_req_max_q0 can prevent clients from not being able to connect at all. Connections from clients remain in the “half-open” state until the server software can process them.
The defaults on Solaris 8 and Solaris 9 are too low for a system that processes more than 128 incoming TCP connections or 4096 “half-open” TCP connection at a time. Change these parameters with great care. Do not change them unless tcpListenDrop or tcpListenDropQ0 are non-zero, or you expect the number of connections to change