a lof of ICMP blocks

I get a lot of ICMP blocks and all the time its only from a SourceIP to a DestinationIP and type(3) to code(4) and I have this problem since changing my ADSL although connection speed is more but
I have Internet disconnections and not stable internet
what should I do?

ICMP type (3) code (4) is “Fragmentation required, and DF flag set” .

I think that means that the Maximum Transmission Unit (MTU) size is not set properly. IP packages will get fragmented and that will make the transmission slower.

What OS are you on?

You want to allow ICMP IN type 3 code 4 messages. This is useful for determining max MTU path. That should be the first global rule. The second global rule should be block ALL other ICMP types IN. NO logging of ANY inbound ICMP is useful.

For outbound ICMP, I have set up the following global rules block & log outbound ICMP:
TYPE 13.0
TYPE 15.0
TYPE 17.0
TYPE 11.1
TYPE 14.0
TYPE 18.0

Only ONE host on your internal network that ABSOLUTELY NEEDS to regularly usie ping or tracerout should have alternative ICMP rules. Furthermore, no incoming unsolicited ICMP to such management host should be permitted.

Edit: changed “Type 11.0” to read “Type 11.1”

-Time Exceeded is the same as 11.0:
-What’s the need of blocking out echo request? Shouldn’t it rather be echo reply (type 0, code0)?
-How do you manage in a single rule to block several codes (e.g. code 3, types 5-15)?

My bad, I meant ICMP type 11 code 1 (Fragment reassembly timeout).

ICMP Time-To-Live Exceeded in Transit (Type 11 Code 0) is blocked to eliminate the possibility of using traceroutes and Inverse Mapping techniques against a network. However, an advanced host detection method exists whereby only a few fragments of a fragmented datagram a sent (not all of the fragments), i.e., the fragmnted datagram is incomplete. This forces the targeted host to issue an ICMP type 11 code 1 error message back to the offending packet’s source IP address and thereby illuminating the existance of the host to a malicious attacker.

In order to allow ICMP Type 8 (Echo request) out (and be confident of receipt of only corresponding ICMP Echo replies), it is essential that a true stateful filtering device be present that performs stateful inspection of the ICMP protocol explicitly. One must be absolutely certain of this; the inspection can NOT be implied, inferred, psuedo-statefull or any other sort of condition.

The question is irrespective of statefull inspection capabiities concerning any other IP protocol. Given that ICMP Echo replies within a protected network is very dangerous, permitting them simply not worth the risk. Therefor, unless one is absolutely certain concerning the true stateful filtering functionality with regards to the ICMP protocol in general for any filtering device in operation don’t let ICMP Echo replies into your protected network.
Since ICMP requests inherently become useless: block them as well.

Unless one desires to be held categorically liable - either ethically or morally - for an attack generated from within a network that is under their purvue by an abusive internal-user (or a malicious attacker using a compromised host(s) from within the network), it is suggested that in addition to the aforementioned outbound ICMP blocks the following types of ICMP traffic be blocked outbound from the protected network:

Destination Unreachable: ICMP Destination Unreachable error messages codes 2-4 (“Port Unreachable”, “Protocol Unreachable” and “Fragmentation Needed and DF Flag was Set”) are a group of messages that are hard error conditions and when received should terminate a connection.

  • This allow a malicious computer attacker to send fake ICMP Destination
    Unreachable codes 2-4 error messages to terminate valid connections
    between the attacked target and other hosts on the Internet.

  • Old TCP/IP implementations terminate TCP connections when receiving
    these error messages. Modern TCP/IP implementations no longer
    terminate a TCP connection when receiving these error messages

Source Quench messages

  • Since hosts still react to ICMP Source Quenches by slowing communication, they can be used as a Denial-of-Service measure.

A close examination of the immediate foregoing in conjunction with the aforementioned outbound ICMP blocks is that essentially it boils down to: all outbound ICMP traffic should be disallowed - except that necessary for MTU path discovery.

And so the global rules essentially distill to:

  • Allow ICMP In From IP Any to NIC Where ICMP Message is FRAG NEEDED
  • Block ICMP In From IP Any To IP ANy Where ICMP Message is Any
  • Allow ICMP Out from NIC to Modem where ICMP Message is Frag NEEDED
  • Block and Log ICMP OUT from ANY to ANY Where ICMP is Any

But echo request is not supposed to go out: echo reply does.

And you did not answer for multiple codes settings in the same rule.

A little confusing I’ll admit. I began with what I initially posted. As far as type 3 codes 5-15, I had one rule for each type 3 code. However, when one takes my initial post with my second one, all those rules essential boil down to the last four stated. That’s what I’ve changed everything to after I wrote that. The only ICMP I allow in is FRAG NEEDED (from anywhere), and FRAG NEEDED out to the modem only.

The issue about ECHO request/reply is addressed at the very end of my second post: since ECHO REPLY is prohibited then ECHO requests are a moot point. No?

And since ALL rules essentially distill to 4, the whole issue of ECHO anything and how to specify the entire type 3 family is also moot. No?

My OS is Vista home premium 32-bit

do these messages have anything to do with connections problems I have ?

and what should I do at last ?
change MTU size or allow ICMP IN type 3 code 4 messages or …?

You’ll always need type 3 code 4’s IN. The largest MTU allowed (unless explicitly otherwise allowed) is 576.

The default Windows MTU is 1500, but if using PPoE its 1492. So right off the bat there’s MTU path discovery going on between modem & host. And there may be routers along the path that have smaller MTU size. If no size is explicitely stated by any arbitrary device, RFC dictates MTU can be no larger than 576.

The Don’t Fragment Bit Flag in the IP header is set to dynamically discover the Path MTU of a given route. The source host assumes that the PMTU of a path is the known MTU of its first hop. He will send all datagrams with that size, and set the Don’t Fragment Bit. If along the path to the destination host, there is a router that needs to fragment the datagram in order to pass it to the next hop, an ICMP error message (Type 3 Code 4 “Fragmentation Needed and DF set”) will be generated, since the Don’t Fragment bit was set. When the sending host receives the ICMP error message he should reduce his assumed PMTU for the path.

The process can end when the estimated PMTU is low enough for the datagrams not to be fragmented. The source host itself can stop the process if he is willing to have the datagrams fragmented in some circumstances.
Usually the DF bit would be set in all datagrams, so if a route changes to the destination host, and the PMTU is lowered, than we would discover it.

The PMTU of a path might be increased over time, again because of a change in the routing topology. To detect it, a host should periodically increase its assumed PMTU for that link.

The link MTU field in the ICMP “Fragmentation Needed and DF set” error message, carries the MTU of the constricting hop, enabling the source host to know the exact value he needs to set the PMTU for that path to allow the voyage of the datagrams beyond that point (router) without fragmentation.

A host using the PMTU Discovery process must detect decreases in Path MTU as fast as possible. A host may detect increases in Path MTU, by sending datagrams larger than the current estimated PMTU, which will usually be rejected by some router on the path to a destination since the PMTU usually will not increase. Since this would generate traffic back to the host, the check for the increases must be done at infrequent intervals. The RFC specify that an attempt for detecting an increasment must not be done less than 10 minutes after a datagram “too big” has been received for the given destination, or less than 2 minute after a previously successful attempt to increase.

If internal routers have a Path-MTU that is smaller than the Path-MTU for a path going through the border router, those routers would elicit an ICMP “Fragmentation Needed and Don’t Fragment Bit was Set” error message back to an initiating host if receiving a packet too big to process (but small enough to path through the border router) that has the Don’t Fragment Bit set with the IP Header, discovering internal architecture of the router deployment of the attacked network.

If you want to maintain strong ICMP filtering rules with your Firewall/Filtering Device I suggest you block all incoming ICMP traffic except for Type 3 Code 4 (“Fragmentation Needed but the Don’t Fragment Bit was Set”), which is being used by the Path MTU Discovery process. ICMP Type 3 Code 4 should be allowed from the Internet to your DMZ at least. Opening your Internal segmentation to this kind of traffic is questionable and depends on the facilities / activities / usage of the site and the level of filtering you wish to maintain.

If you block incoming ICMP “Fragmentation Needed but the Don’t Fragment Bit was Set” error messages, your network performance will suffer from degradation. The same if you disallow the same outbound (your system can begin dropping packets) resulting in mucho re-Xmits. If this is your choice: disable MTU path dkiscovery. Then you’ll be set on fixed MTU size (the tradeoff is potential large latency). Since its plausible MTU’s can dynamically on any arbitrary route go as low as 68, and if your fixed MTU is largerit has to be routed on a path that’ll accomodate that (woe be you if a re-Xmit occurs durring that time and your RWIN is too small).

I already have Allow ICMP In From IP Any to IP Any Where ICMP Message is FRAGMENTATION NEEDED in my Global Rules
I added all the Global Rules in WxMan1 first reply to my Global Rules but I still ge a lot of blocked ICMPs Type(3) Code(4) !

After doing all the suggestions above and having the problem again I reinstalled COMODO Internet Security and configured the settings like they were before uninstall and now I dont get any ICMP Type(3) Code(4)blocks !!!
although all settings are the same !

I’m glad its working. I ALWAYS like “works NOW”.

Sounds like from your second to last reply that you ADDED the rules to what you had. There must’ve been a rule existing that blocked & logged; anything AFTER that rulle will never get executed. Other than that I don’t know, mabye you had a rule direction IN/OUT with src & dest IP’s specified. That might work OUT for src to dest, but won’t for dest to src; the IP’s are switched. The IN/OUT direction rule will only work if the same IP range, mask or zone is in both src & dest fields.

You’ve got to keep an eye on where rules you add go (they usually get added to the bottom). You have to drag the rules to where you want them; first rule encountered (top to bottom) that fits gets executed.

Anyways, the rule OUT for Type 3 code 4 to the modem is only valid if you’re not sitting behind a router. In that case the OUT rule should go to router (not modem); if you’re behind a router your system doesn’t even see the modem.

Are you still having connection problems? None of the ICMP messages blocking or allowing should have any bearing on the connection itself; you block ICMP because its a security risk, i.e., scanning and / or covert channel useage. You said you “switched ADSL”, does that mean changed modm or ISP? Are you behind a router?

Hello WxMan1 and thanks for your good advices
I had a 2 Mbit connection with a simple dsl modem I changed it to 8 Mbit and a Modem with wireless and after that these ICMP blocks type 3 code 4 began
and about the Global rules,I done everything with caution and managed the order of rules very carefully but after that I still had ICMP blocks so I reinstalled and everything is OK now !
again thanks for your advices

Glad to hear “works now”. I’ve ALWAYS liked “works now”. I believe that Comodo detected the change to your network by you replacing your modem. As such, without any additional info, your existing rules became ineffective.