Hi,
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…!!
Any thoughts?
Thanks
Roy
Can you paste us some of your logs pls?
Thanks egemen
Here is my guess:
The source address field should be outside of your trusted zone addresses. Thats why it is not being allowed.
IGMP stands for Internet Group Management Protocol. IF everything is working fine i.e. if you dont have connectivity problems, you dont need to modify anything. Let CPF block them.
Egemen
Hi,
they all say the same…
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)
destination: 224:0:0:1
reason: network control rule ID = 3
they are happening every couple of minutes…
Thanks
Roy
Hi Roy
You’ll need to post a screen shot of your Network Monitor rules. The above rule is ID 3. But, in a default set-up CPF’s rule 3 is to Allow ICMP Time Exceeded in. Not, a block rule.
BTW I noticed in your example that the destination is 224:0:0:1, not 224.0.0.1. What’s that about?
Anyway, 224.0.0.1 (and the whole range 224.0.0.0 - 239.255.255.255 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.
rule 3 is… IP block & log in any / any
rules 0,1 are allow IP out zone/zone, IP in zone/zone (i.e. allow traffic in my wireless network - belkin router)
2 IP out any/any (so I can contact the internet)
My wireless acccess to the internet seems to be working fine, so what ever it is blocking isnt causing a connection problem there…
Thanks
Roy
PS> sorry, no screenshot, donno how to do that…
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…
[attachment deleted by admin]
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.
Thx,
Egemen
My zone is…
192.168.2.0 - 192.168.2.255
the blocked incoming is from 192.168.2.1
Roy
(ps thanks for the screen shot capture stuff!!)
Here are screen shots of my network rules and log.
Ta
Roy
[attachment deleted by admin]
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.
Egemen
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,…
Thanks anyway!!!
Roy
I´ve made a little research on the net and found that:
"Port 224.0.0.1 everybody
This address means “all hosts” on the network. "
Ref: http://www.iss.net/security_center/advice/Exploits/Ports/Multicast/224.0.0.1/default.htm
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 224.0.0.1 is one of the firts connections you may see there. (:KWL)
Regards,
A.M.
Hi,
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 224.0.0.1 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 V2.3.6.81, despite my rules being the same.
Still getting the wireless connection issues that I described in one of my posts though… (:SAD).
Cheers
Roy
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 224.0.0.22 (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 224.0.0.22.
If you should choose to try this, please let us know if this is indeed the result.