Mikkel L. Ellertson:
>> Nope. You will get connection refused if the port is set to reject,
>> and a timeout message if it is set to drop. You get the No route to
>> host when there is a network configuration problem.
J. K. Cliburn:
> I disagree, but I won't be able to substantiate my disagreement until
> I get home this evening. Every time I see the "No route to host"
> message, my next step is to look for a filter in the way, and I almost
> always find a port blocked by netfilter.
It *is* possible for filter rules to send back error messages like this,
if you want to.
If you avoid the FUD advice of "stealthing" your network (marketing
terminology) by not responding to surprise connections (silently DROP
connection attempts), it *can* be better to respond to them with a
message more appropriate to the action (REJECT, with a reason why).
Taken from the iptables man file in FC4:
REJECT
This is used to send back an error packet in response to the matched
packet: otherwise it is equivalent to DROP so it is a terminating TAR-
GET, ending rule traversal. This target is only valid in the INPUT,
FORWARD and OUTPUT chains, and user-defined chains which are only
called from those chains. The following option controls the nature of
the error packet returned:
--reject-with type
The type given can be
icmp-net-unreachable
icmp-host-unreachable
icmp-port-unreachable
icmp-proto-unreachable
icmp-net-prohibited
icmp-host-prohibited or
icmp-admin-prohibited (*)
which return the appropriate ICMP error message (port-unreach-
able is the default). The option tcp-reset can be used on rules
which only match the TCP protocol: this causes a TCP RST packet
to be sent back. This is mainly useful for blocking ident
(113/tcp) probes which frequently occur when sending mail to
broken mail hosts (which wonʼt accept your mail otherwise).
--
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
