first of all, I had troubles with my font sizes when installing an older version from download.com, should be updated there but now I’m happy with COF, really a great product. Another switcher from ZA.
1.) Are these legimit packets?
2.) Is there a way to create a rule for specific packet types, like “allow all from ICMP Type 3” or “allow ICMP Type 3 Code range 0-15”?
Have a look at thread https://forums.comodo.com/index.php/topic,2236.0.html where we discussed this log entry.
I’ve created a network rule so it doesn’t get logged. Placed before the last rule:
Block ICMP Out, Source: Zone , Destination: Any, ICMP Details: Port Unreachable.
Mark, mjpm’s is different. It’s inbound, not outbound.
If it’s legitimate or not, probably depends on the source. Who sent it mjpm? Was it your DNS?
But, as Mark said, you can create a Network Rule to either allow or block it as you desire. In CPF, the code types are masked by their proper names. So, once you select ICMP as the protocol, all the different message types are available under the ICMP Details tab.
AFAIK, CPF recognizes only the most common ICMP Unreachable codes (NET, HOST, PROTOCOL, PORT) and those will be indicated in the log. That log entry does not specify, so it must be one of the other codes. Most likely your computer is trying to connect to an ip address that is rejected/filtered by a router.
You could get such log entries if your computer is trying to connect to an IP address reserved for private networks, these IP addresses are non-routable and will be rejected/filtered by routers on the internet. My ISP’s router will respond with a ICMP type 3 code 13 (Communication Administratively Prohibited) message in these cases and CPF will make a log entry similar to yours.
In that case, the ICMP messages are most likely sent by one of the routers closest to you (your router or your ISP’s router). You can verify that by running “tracert xxx.xxx.xxx.xxx” (where xxx.xxx.xxx.xxx is the ip from the source field in the log) from command prompt and see if the ip address is 1-2 hops from your ip, or see if the ip address resolves to your ISP’s domain.
If you determine that the source is your router or your ISP’s router you can safely make a rule that allows these messages (substitute xxx.xxx.xxx.xxx with the router’s ip):
ALLOW ICMP IN FROM IP [xxx.xxx.xxx.xxx] TO IP [Any] WHERE ICMP MESSAGES IS ANY
In my case, I have tried to make a custom ICMP rule for type 3 code 13, but that does not seem to work (a bug?). So I have to allow any ICMP messages from the router, which is probably the best thing to do anyway.
first, you were right, the message are Type 3 Code 13.
I tripple checked everything:
1.) made allow + log rules from ICMP Type 3 Code 0 to Code 15
=> no triggering for the events not namely known to CPF
2.) made block + log rules from ICMP Type 3 Code 0 to Code 15
=> still no triggering for the events not namely known to CPF
3.) used WireShark live ICMP scan to determine which Code the packets had (verified IP in WireShark with IP in CPF log)
=> result: all of the non triggering ICMP events are Type 3 Code 13
conclusion:
1.) as this events appear while being on bittorrent from different IPs there is no easy rule (allow ICMP all from IP x)
2.) CPF does not recognise this ICMP code and maybe others and so is unable to trigger rules for them => bug(?)
Has this so-called bug been fixed? I still receive those incoming ICMP = UNREACHABLE alerts in the log with uTorrent. Tested with Type 3 (all codes from 0 to 55!) allowed rules and still generates that one log entry.
At least we’re not alone in this issue! I still have not found success with CFP 2.4. It must not be Type 3 then…The only workaround is to allow all incoming ICMP, but there must be a better way.
I’ve noticed I get them after I’ve run uTorrent for a while and then exit it. Evidently other torrent clients are still attempting to connect to me, perhaps? After a while they stop, but I guess it takes some time for my IP address to get off their list.
You must be referring to a different kind of log: ICMP = Port Unreachable, which can be easily allowed by creating a network rule. I have four ICMP rules to handle uTorrent, but I cannot find one for the general ICMP = Unreachable log entry.
I already checked out that site among others. Sure, I could test out all the ICMP codes and types, but there are hundreds of combinations! WireShark looks complicated.
If only CFP would allow adding a range of Codes per Type or vice versa for ICMP. That’ll save time and allow to narrow down the one rule I need.
My knowledge in this area is a bit shady due to lack of use, so please bare with me a bit. I’ll try to do my best and reply as accurately as I can
ICMP Unreachable is sent by your PC or Router (or any other layer 3 capable device) when this request is being blocked/dropped as a reply to their ICMP queries. Assuming you have a rule in your firewall blocking any inbound ICMP, this is what would happen:
If someone would try to ping you, that individual would initiate and send an Echo Request, an ICMP Type 8 Code 0 (only code so far and will always be Code 0). The reply made by your PC would then be ICMP Destination Unreachable, Type 3 Code 3. This because the port itself is being blocked. A hacker could use this information to see whether the host is actually there, but is just dropping inbound ICMP. Requires skill and a packet sniffer
If someone would try to ping you again, but this time you deleted your default gateway entry, the response would come from the router instead and read ICMP Destination Unreachable, Type 3 Code 1. This means the network which the host is located on exists, but not the specific host you are trying to reach.
My last example is when someone tries to ping you, but you’re on a different network or a different subnet. If the router/default gateway doesn’t have a route entry to this network/subnet the response would then be ICMP Destination Unreachable Type 3 Code 7. Meaning the network is unknown and the router doesn’t have a route entry to it and no default route exist to attempt alternative routes.
Some firewalls read these ICMP rules rigidly, some not. CFP seems to me as a bit lenient with the ICMP rules as it allows Echo Reply to be returned to me when I explicitly deny all inbound ICMP
Anyways, hope I didn’t ramble on for too long and that this made any sense at all.
Cheers
:Beer
You have lost me, I am afraid. I wonder why the product does not just list the exact type and code received or generated in such cases. That way we would not have to speculate about it, but could just react to it by defining a rule. Seems straightforward enough to me.
I work for the “over-complicate things” dep. Making things straightforward would not be an option here, nosirree!
(:KWL)
Seriously though, I agree with you. Easy is better
As a longshot, I think it’s the P2P program thats making it’s connected peers to send you these ICMP Unreachables when they themselves are blocking inbound ICMP. I see these alot when I “Lime” around.
I already know that it’s from uTorrent, but the question still remains which ICMP allow rule will take care of specifically “ICMP = UNREACHABLE” alert?
My network rules are attached. I’ve allowed icmp port/host/net unreachables. These take care of the other icmp incoming alerts.
Yes. I recall seeing a specific log entry for that, but haven’t in a long time. If there’s a log entry for ICMP protocol unreachable, then it can’t be that rule. Like I stated, I’ve tried all the Type 3 (unreachables) from 1 to 55.
When it comes to ICMP Type 3 you only have 15 codes to choose from
If neither of these codes goes through, it’s something else or it’s a malformed ICMP packet. Maybe it’s a good idea to log this with the Comodo team and get them to investigate this further?
but now I’m happy with COF, really a great product. Another switcher from ZA.