Insight into repeating ICMP = PORT UNREACHABLE log entries

Help for v2
1

Hi there,

A lot of people seem to get the following log file entries over and over again:

Severity :Medium Reporter :Network Monitor Description:Outbound Policy Violation (Access Denied, ICMP = PORT UNREACHABLE) ... Reason: Network Control Rule ID = 5

grue and jasper seem to have it tied up on this thread:

https://forums.comodo.com/empty-t14030.0.html

but I just wanted to share my experience with this problem. It certainly is BitTorrent related (or perhaps P2P in general). To prove this to yourself:

  • First thing to do, if you can, is to disconnect and reconnect to the internet (this is assuming you get your IP dynamically assigned by your ISP) - if behind a router, then you will need to log in there and disconnect the internet connection (“WAN Interface”)

  • Now, into Comodo and Activity > Log. See how there are no ICMP = PORT UNREACHABLE entries accumulating in there?

  • Run your torrent client for a while, let it get a few connections.

  • Close it down. Wait for a little while for it to truly close.

  • Look in your Comodo log again - the number of ICMP = PORT UNREACHABLE entries is rocketing, yes?

  • Go into the network monitor. Now, if you have your BitTorrent app running successfully then you will have previously put a rule in here that unblocks the port it is using. Find this rule (it is usually 5 digit between 10000 and 70000 - check in BitTorrent app config if needed).

  • Now, highlight this rule and, using ‘Move down’ in the top left, move it to below the standard ‘Block & Log’, ‘IPPROTO IS ANY’ rule.

  • Now jump back to Activity > Logs.

  • Notice how the ICMP = PORT UNREACHABLE entries have stopped, and you are now getting a load of ‘Inbound Policy Violation, Access Denied’ entries to the port number you have just blocked (the BitTorrent port)?


http://img229.imageshack.us/img229/7336/92112404tr1.th.jpg

This shows I think that the original log entries where caused by left over BT clients, that have connected to your machine, still thinking they can connect but haven’t received the signal to from your machine (the problem is lessened if you stop your torrents before you close the app). This is why we disconnected and reconnected at the start - so we will get a new IP address, and the left over clients will not bug you anymore.
Also, on your side of things, the IMCP requests are your machine trying to close said connections. I wonder if there’s a way to configure uTorrent (or other client) to wait a bit longer before disconnecting?

Of course, it’s not too much of a problem, except all those log entries cause some CPU usage. Setting a rule to allow the ICMP Port Unreachable as detailed here works ok:

https://forums.comodo.com/empty-t5391.0.html
(second post, by Kail)…

Don’t forget to put your open BitTorrent client rule above ‘IPPROTO’ again in network monitor … your music downloads won’t work without it :slight_smile: