{"id":77,"date":"2026-08-06T18:49:21","date_gmt":"2026-08-06T18:49:21","guid":{"rendered":"https:\/\/mrnetwork.nl\/index.php\/you-don-t-have-to-block-icmp-completely\/"},"modified":"2026-08-06T19:59:59","modified_gmt":"2026-08-06T19:59:59","slug":"you-don-t-have-to-block-icmp-completely","status":"publish","type":"page","link":"https:\/\/mrnetwork.nl\/index.php\/you-don-t-have-to-block-icmp-completely\/","title":{"rendered":"You don’t have to block ICMP completely"},"content":{"rendered":"

Terug naar home<\/a><\/p>\n

You don’t have to block ICMP completely<\/h1>\n
This is something that I typically see all over the place, security administrators blocking the ICMP (Ping) protocol completely. Normally I am ok with that, after all ping is a troubleshooting tool and in some cases not the best troubleshooting tool to rely on. However, it’s when people think their network is more secure when they have blocked ICMP. The truth is you can actually allow the ICMP types that are required for troubleshooting purposes without compromising security. So let’s first consider what ICMP messages we typically use for troubleshooting:<\/div>\n
\n
    \n
  1. Echo Request – ICMP Type 8 Code 0<\/li>\n
  2. Echo Replies – ICMP Type 0 Code 0<\/li>\n
  3. Time Exceeded – ICMP Type 11 Code 0<\/li>\n
  4. Fragment needed but DF bit set – ICMP Type 3 Code 4<\/li>\n<\/ol>\n<\/div>\n
    Now we all know the echo request is the icmp packet from the host to the target, and the echo reply is response from target back to the host. The time exceeded packet is returned to the host  when performing a traceroute. The fragment needed but DF bit set packet is used for path MTU discovery and can used to troubleshoot MTU issues, it basically replies back telling you the packet was dropped because it needed to be fragment but the DF (Do not fragment) bit was set on the packet so it could not be fragmented.<\/div>\n
    One ICMP parameter that should be blocked are ICMP fragments, fragmented ICMP packets can be used to cause DoS attacks. Remember ICMP packets typically send 64 bytes of data, so you should only see larger ICMP packets or expect fragments when testing MTU. (Other then that I can’t think of any other legit reason to see large ICMP packets). RFC 1858<\/a> goes pretty in depth concerning the danger of IP Fragments, it’s definitely worth a read.<\/div>\n
    Now here is a configuration snippet that accomplishes everything I discussed here:<\/div>\n
    \n
    \n

    TERMINAL<\/p>\n