hfs and iptables work with different levels, and thus different protocol.
HFS could also not give reply, but at its level. The level below, the tcp, already answered, so the peer knows you have an open port.
Thanks for the explanation of TCP/IP layers.
(HFS can only control the "
Application Layer" at the top highest level), but one of the other 3 lower layers are answering first (spoiling the purpose of hiding our server). That's easy to understand (and to solve this, we would need to involve the system firewall, and it would get too-complicated). But, keep reading....
» Workaround: I've investigated about this, and I've found
here a very smart idea to artificially create a connection timeout error:
HFS could make a redirect to a no-nexisting IP or a no-nexisting port. For example, you could forward to a non-used random port, or a non-routable IP address (which is the best option), such to any IP on those ranges: 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255, or 192.168.0.0-192.168.255.255, or point it to an external domain for that purpose (not the best idea), like is said
here, like:
http://example.com:81/
http://httpstat.us/504?sleep=60000
The best is using some random IP on this range: 172.16.0.0-172.31.255.255. You could name this macro as {.fakedrop.} or any other name you want. What do you think?...