since upgrading to the latest version I’m getting a load of inbound blocks of IGMP from my router IP address. I’ve never had any before!! These are being blocked by my general inbound block rule, which is further down the list than my allow IP in/out rules for my wireless trusted zone. The IP in / allow rule includes “any” in IP protocol.
Now, I’m not an expert at this, and dont understand all of what i’ve written above… e.g. I have no idea what IGMP is…!!
inbound policy violation (access denied, Protocol IGMP)
Protocol IGMP incoming
source: 192:168:2:1 (which is my router IP, which is in my trusted zone)
reason: network control rule ID = 3
BTW I noticed in your example that the destination is 224:0:0:1, not 220.127.116.11. What’s that about?
Anyway, 18.104.22.168 (and the whole range 22.214.171.124 - 126.96.36.199 for that matter) is reserved for RFC 3171 & that’s used for IPv4 Multicast. Hmm… Cisco’s IOS uses this. So, it’s router or something else on your system is using IPv4 Multicast. And I guess you should be able to find an initial broadcast for this (if you were logging all allowed packets or using a packet sniffer). It’s unlikely they’re contacting you unsolicited.
What you do is open Paint, minimize. Then make sure you click on window to bring to foreground, hit the alt+prtscrn buttons, bring up Paint, on the edit tab, click paste, and there you go. Save as jpeg\jpg though as png or bmp will be a bit large for posting. you then go to additional options on your post\preview screen, browse for attachment open, post, you are done. You can get free screen capture utilities like screenprint32, or fastone capture, you hit one button it saves to file.
Here was a capture using Windows +Paint, of my first answer I accidentally closed…
Hmmm. Since router IP is in your trusted zone, it should not block these requests. Can you check for your trusted zone ip range and make sure it is correct? Security->Tasks->Add/Remove/Modify Zone should do so.
Ok. According to your rules, this is an expected behavior. If everything is fine, there is nothing to worry about. But if these logs are bothering you, you can always use Add a trusted zone wizard to create automatic rules which will accept such requests.
It doesn’t seem to be causing any connection problems. Well additional problems anyway…
I’ve had a long running issue : when one PC (call it “A”) is disconnected from my wireless network, it wont re-connect if the other PC “B” that was online when “A” was disconnected, isnt connected to the network. When “A” tries to reconnect, it can not get an IP address. However, as soon as “B” reconnects, “A” will then reconnect. (Donno if that makes sense!!!).
This happens with DHCP assigned addresses and static IPs. Weirdly, with a static IP PC “A” will appear to connect, but will not connect to the internet until PC “B” is re-connected to the network…!! I have a Belkin wireless router connected via a cable to a ADSL modem.
Anyway, back to the topic … I’ve just updated the other PC on my network to the new version, and i’m getting the same IGMP issue logged on that PC aswell !! Oh well,…
It´s a multicast address and I always get also a connection with it after the system boot.
There are many host connections to/from our computers and I recommend the use of a freeware program to be aware of them. I use Tesseract and DNS Eye, and 188.8.131.52 is one of the firts connections you may see there. (:KWL)
Thanks for the info…I’ve now worked out why I’m geting the alert…! It is because I have “allowed” traffic in my zone with both the source and destination being in the zone, rather than the source being in the zone and the destination being “any”. Since the destination in this case is 184.108.40.206 this is outside my router zone ! Doh !!!
Anyway, I’ve switched it to source in my zone and destination any, and the alerts have now gone. What is wierd is the fact that I didnt get these alerts before upgrading to V220.127.116.11, despite my rules being the same.
Still getting the wireless connection issues that I described in one of my posts though… (:SAD).
Well, I know I’m late to this party, but for anyone reading this I wanted to add a thought.
A number of people have inquired as to a similar recurring log event for IGMP outgoing to 18.104.22.168 (I’m also getting this). I believe that this is your computer indicating which multicast groups it wants to “subscribe” to.
The default for your rule two above is to allow ip out only for GRE protocol. Since you have it set to “Any,” you would be allowing this IGMP out connection. I suspect that your IGMP inbound attempts are a response. Consequently I would predict that if you change the above rule to GRE only, your IGMP incoming logs would be replaced by IGMP outbound attempts to 22.214.171.124.
If you should choose to try this, please let us know if this is indeed the result.