ICMP

Destination unreachable

Další nepříjemností pro uživatele sítě, které postihne příliš horlivý admin zakazující ICMP je, že se nedozví o chybách, které nastávají, když se pokouší navázat spojení, resp. obecně komunikovat s různými protistranami. Pokud například klient pokusí navázat TCP spojení na IP adresu, která je v subnetu, na který nevede žádná cesta ve směrovací tabulce, tak první router, který zjistí, že neví, co má s prvním datagramem daného spojení (červená šipka ve schématu níže) dělat, daný datagram zahodí a pošle o tom odesílateli ICMP zprávu (Destination Unreachable - no route to destination) - ta je reprezentována zelenou šipkou.

Pokud ICMP zpráva dorazí odesílateli zahozeného datagramu, je hned jasné, že snaha o spojení je marná, a že jí nemá smysl ani opakovat, ani čekat na odpověď od serveru, na který se připojujeme. Jinými slovy, pokus o spojení z aplikace může být rovnou ukončen a chybové hlášení, které aplikace a snad i uživatel dostane, říká, jaký byl důvod, že spojení selhalo.

Filtered Destination Unreachable

Když naopak ICMP zpráva nepřijde, protože je ICMP zahazováno firewallem našeho horlivého admina, tak klient se opakovaně pokouší spojení navázat a čeká na dlouhý timeout (v Linuxu to je v defaultním nastavení TCP stacku 6 pokusů a dohromady přes 2 minuty času). A nakonec aplikace dostane zcela nevypovídající hlášení: Timeout exceeded. O důvodu pak může uživatel jen spekulovat.

Obdobná situace nastává, pokud se klient pokouší komunikovat s adresou, která je sice součástí existující sítě, ale žádný počítač neodpoví routeru, který má do daného subnetu connected route na ARP / NDP (to pak vede na Destination Unreachable - destination host unreachable). Nebo pokud se aplikace pokouší komunikovat protokolem UDP na port, který je zavřený (nikdo na něm neposlouchá). (V případě TCP server reaguje na pokus o navázání TCP spojení na zavřený port segmentem s flagem RST=1.)