I am posting a screen shot of my recent firewall log after I enabled logging of all outbound activity. I am still in a quandry over these inbound ICMP 3,0 events. I created a firewall rule to allow it from my router since IE8 hangs and sputters when I don’t allow it.
The inbound ICMP appears to occur either as a prelude to a DNS resolution or as a result of uPnP port 1900 activity. Hard to tell from the log.
There are a variety of reasons why a home router may return an ICMP Type 3 Code 0 (Network Unreachable) but to find out the specific reason, you’d need to do some protocol analysis. However, as the message type implies, for whatever reason, the destination network in an IP datagram, received by the router, could not be reached. This may be due to a number or factors:
a. The router does not have a route to the destination network. (possibly an ARP failure)
b. Failure of the router to forward multicast packets
c. The router is configured to block TCP port 139 (NetBIOS Session Service)
There are others.
These messages are purely informational, although they can and often do provide useful troubleshooting information.
I checked my router logs and was surprised to see that for the last two days, I have received blocked port scans from my assigned ISP DNS servers. I have never seen this before.
Everything is pointing to Avast’s web sharing and/or network processing. Web sharing creates a localhost proxy on TCP port 12080 using Avastsvc.exe and funnels everything from IE8 through that port to the Internet. My router, Netopia 3347, has a firewall that is set to stealth mode. Both NAT and statefull inspection are set on for the router. The router also has a DNS server.
My gut is telling me that this issue here is NAT on the router? Another possiblity is the way Comodo is handling those localhost communications from Avastsvc.exe to my router. Are Comodo special firewall rules for localhost needed here?
The DNS and Avast items may or may not be related to the Network unreachable messages. It’s certainly not uncommon for an ISP to periodically check the on-line status of their users via ICMP. The fact the ICMP messages appear to be coming from the DNS servers, could be coincidental. Out of curiosity, what type of ICMP messages are they? As for avast, you could take a look at this http://support.avast.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=25
As I said earlier, the the ICMP messages reported in your earlier screen-shot, are network unreachable. These are simply letting you know that a packet received by the router, could not be forwarded, because the network to which the packet was addressed could not be reached.
If you want to understand why the router is failing to forward these packets, download Wireshark and take a look. If you need some help understanding the data, I’m sure someone here will be able to help.
That link is for Avast 4. The .ini referenced doesn’t even exist in ver. 6.
I tried a couple of rule changes and they didn’t make any difference. As long as I allow destination unreachable from the router, IE8 works fine except that connects to https sites do have a noticeable lag. That could be due to MBAM Pro realtime scanner - not sure of that.
I did come across an interesting article written by Avast’s chief developer where he has verified that MBAM’s Pro IP blocking causes huge latency issues when used in conjunction with Avast 6 web shield. So I turned off MBAM’s IP blocking since it appeared to offer minimal blocking usefullness. I use SpywareBlaster that populates IE block web site list plus WOT. This factor alone could have led to my increased surfing speed.
So I won’t worry about this further unless something crops up.
Apologies for the Avast link being old, I’ve never used Avast or any similar product, so I had no way of knowing whether they still use the same method to determine connectivity.
Well, what I discovered is I have to allow all Destination Unreachable ICMP commands inbound. The NIS 2011 firewall has a rule that does the same of my XP installation. Once I allowed all Destination Unreachable inbound, my mallformed IP addresses sent outbound from UDP port 137 stopped. Also all the corresponding DNS Client time-out warning events in my WIN 7 event log disappeared.
For additional security I created a Global rule for UDP ports 137 - 138 inbound from/to LAN only and block all other [Edit] UDP [End Edit] inbound activity to those ports.