Re: Blocked incoming ICMP, getting outgoing ICMP [3] Destination Unreachable

On Sat, 25 Feb 2006, in the Usenet newsgroup, in article
<dtov45$48d$1@xxxxxxxxxxxxx>, Dubious Dude wrote:

I have a rule in Kerio Personal firewall to block incoming ICMP [8]
(Echo Request)


and [30] Traceroute.

Wrong. ICMP Type 30 was an experimental protocol - see RFC1393. If you
are trying to block windoze imitation version of traceroute, your block of
ICMP type 8 already does so. The real LBL traceroute uses UDP, defaulting
to ports 33434 and above. There is also a TCP version of traceroute which
defaults to probing port 80.

I am still getting outgoing ICMP [3] Destination Unreachable. Doesn't [3]
need an incoming ICMP to provoke it?

See RFC0792 - specifically the last paragraph on page 1. Then grab a copy
of RFC1122 and 1180, and learn how networking operates. BRIEFLY, when a
remote host tries to connect to a port that has no server running, the
network stack (part of the operating system kernel) will either return a
ACK/RST TCP packet (see my reply in the thread "Please help me interpret
a suspicious netstat SYN_SENT TCP port 1058 ?") which says "I heard you,
but go away", or it returns an ICMP Type 3 Code 3 error which says
"Nobody here at that port". Either one ends the conversation.

If you think that not responding to any Internet traffic is the way to
go (Gibson's so-called "stealth mode"), you really need to look at the
concept of traceroute again, to see why such action is a waste of your

Old guy