IOT-LAN; How to handle multicast !?
-
Some updates, important, but only limmited changing the original question / problem
-
I did make an error in the Multicast rules. I MDNS and SSDP in port field should be the other way around. That stopped the log those messages. However the question why oh why are the messages there stays
-
There is another alarm to be fixed see below
I tried to stop that alarm with a third multicast rule. But it did not work. Note that the alarm tells me that the package is not UDP or TCP but of type "Options". But I can not select that one when defining a rule. The rule as defined does not work.
For clarification the here the destination alias defs:
- mDNS_MulticastAddr Host(s) ff02::fb, 224.0.0.251 Multicast Address Range (link-local addressing)
- WSD_MultiCast Host(s) ff02::c, 239.255.255.250 When an UPnP device is added to the network it multicasts an advertisement for each of its provided services
- IPV6_MLDv2_RPL Host(s) ff02::16 MLDv2-capable routers & Routing Protocol for Low-Power
Here picture of the actual rule set
-
-
@louis2 Not exactly sure what your asking. multicast out of the box would not go to any other vlans.. It would be limited to its local network.. But that doesn't mean that pfsense having an interface in that network wouldn't see it.
if your not going to pass on mdns for example with avahi - you prob want to create a rule that doesn't log the noise. Place a rule above you last rule there that is logging everything. Which btw the default deny does anyway, so really little reason for such a rule unless you turned off the logging of the default deny. That doesn't log the noise your seeing.
-
John,
I always have that final rule. I simply want to know what I did not block, but is still there.
So that I can decide, if that I should blocked/passed (in a controlled ^on purpose^ way)And I discovered another ^uncontrollable^ alarm, which needs filtering.
Multicast should IMHO never pass unless explicitly defined (Avahi etc). I hope that that is really so. Hard to check (especially IPV6).
Multicast, especially IPV6-multicast, has multiple variants
- Local (lan / vlan)
- Site-Local
- Global
And I think that the used address ranges here are ^Local^, if so according to the defs, they should never pass. So they are not blocked. It feels weird.
-
@louis2 multicast doesn't pass a L3 boundary - by its very nature multicast has a TTL of 1, so no router would route it..
You can route multicast, but no normally multicast would never get past your typical router.
I always have that final rule. I simply want to know what I did not block, but is still there.
Again - out of the box the default deny is logged. you can for sure have your own rule, but the default deny logs out of the box..
Whatever you do not want logged by either the default deny or last rule - create a rule that either allows it or blocks it - but does not log..
-
John,
One thing is for sure a default allow rule at the end is ..... completely the opposite from what is secure IMHO. I think you will agree.
Related to the default logging being active. That is I think dependend op this setting
I have never enabled that setting. For two reasons:
- it is global (which is probably ok, but less flexibility)
- I can imagine that there are more blocks than I am aware of. And I do not know If I want to see all of them
By defining the log rule at the end of interface-rule-set, I know that that is what I want. As said, I do not know to which extend that differs from "Log firewall default blocks"
Still have to find a way to suppress
-
@louis2 said in IOT-LAN; How to handle multicast !?:
One thing is for sure a default allow rule at the end is
there is no default allow at the end, the default deny is just not shown in the gui.. every interface has a default deny rule. They are just not shown in the gui.
But if you disabled logging of the default deny, and want your own that logs that is fine too.. I do sim sort of setup, where I only log what I want to see and have default deny not logging as well.
But if you don't want stuff logged that is caught by your rule, place a rule above it that doesn't log.
If you do not want that logged, then create a rule just above your last block log everything rule that would trigger on that, say destination ff02::16 that is set to not log.
None of your rules above your block rule at the end that don't log would trigger on that traffic, which is why your last rule is logging it.
-
John, you did sugest the option for a allow rule, which caused my reaction
However related to the creation of an [ff02:::16; option rule ......
The suggestion is OK, I just do not know how to create such a rule !!! The problem is that I have no idea what protocol type to use in that rule. "Type" option is not available as far as I can see !
-
@louis2 I just meant you could use an allow or deny rule that doesn't log above your deny.. pfsense not going to do anything with that traffic anyway.. So allow or deny for that specific traffic not really going to matter.
-
Yep, it does matter! It prevents the message to be logged!
Weird because there are packages:
- to be passed to internet or vlans which can be passed given a global address
- messages not allowed to reach all or some destinations outside the (v)lan having a global address
- packages with a local address, to be passed to internal applications (DNS, Avahi, etc),
- messages to be blocked to internal applications, having a local or global (ipv6) address
Whatever, there are sometimes reasons to block packages to reach internal applications, and it is also clear that you do want to limmit logging to things you would like to see
Still not know how to block a package from type options
-
@louis2 not sure you understanding the those terms... Rules on pfsense have nothing to do with other devices on the network seeing the multicast.
block packages to reach internal application
Pfsense has no way to block other devices on the same L2 from seeing any multicast or broadcast traffic, nor unicast traffic if sent to another host on the network.
Pfsense would not route or forward any multicast traffic without the use of some specific addon IGMP proxy, PIMD
Did you set either of those up?
You could use Avahi as another one for specific mdns which is sent to a multicast address. None of those are setup or enabled out of the box.
But sure depending on your rules, you might need a specific rule to allow pfsense to see the multicast that you want it to router/forward. your block rules for mdns/ssdp - you understand pfsense not going to do anything with that traffic out of the box. Even if it saw it, but those rules don't stop other devices on this network from seeing that traffic.
-
John,
I think you did not understand my last question. I just wanted to get rid of the message.
Selecting protocol type UDP does not match IGMP also no match.
I just defined a rule with ^all protocol types^ and that one seems to work. However I would expect that there should be a protocol type which matched.
I still have to find out what for the hell the purpose of the package is
Will do some searching -
@louis2 That is IPv6 https://en.wikipedia.org/wiki/Multicast_Listener_Discovery
Would be MLDv2 , but ffx2:/16 is not routable anyway.. I believe it is part of ICMPv6, so you could try using that protocol vs any.. But what does it matter? Your just not logging anything that goes to ff02::16, there is nothing else that would use that address, on any other protocol, etc.. So blocking just the destination with the destination address is not going to block anything else that you might want to use on a different protocol..
Its not like you want to block udp to 192.168.x.x but allow tcp..
A rule for that specific traffic would be under the icmpv6 protocol - you could look to see specifics, could be multicast listener report, or query.. not sure off the top of my head..
-
John, it is a complex story.
But my actual impression(!) is that ^FF02:0:0:0:0:0:0:16^ is the address of the routerpart handling multicast.
Reports comming from multicast clients should be send to that destination.
Intention seems to be:- to take care that the router is yes no listening to multicast messages
- not to flood the whole network with unnecessary packages
The whole thing is described in https://www.rfc-editor.org/rfc/rfc3810 Multicast Listener Discovery Version 2 (MLDv2) for IPv6 (2004)
I think there is also a version 3I did not study the document. I just scanned the complex document briefly.
My actual fleeling(!!) are:
- that I should never block that address if there can be multicast clients on the particular (v)lan.
- and that I can block if if there are no multicast clients on that network part
However ..... I see the ffmessages ariving ff02::16 message arriving (in the logs) from vlans, which do not have any multicast clients imho. ...... So that does not match .... !!??
Below two small pieces of text extracted from the document
Destination Addresses for Reports
Version 2 Multicast Listener Reports are sent with an IP destination
address of FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast
routers listen (see section 11 for IANA considerations related to
this special destination address). A node that operates in version 1
compatibility mode (see details in section 8) sends version 1 Reports
to the multicast address specified in the Multicast Address field of
the Report. In addition, a node MUST accept and process any version
1 Report whose IP Destination Address field contains any of the
IPv6 addresses (unicast or multicast) assigned to the interface on
which the Report arrives. This might be useful, e.g., for debugging
purposes.IANA Considerations
IANA has assigned the IPv6 link-local multicast address
FF02:0:0:0:0:0:0:16, called "all MLDv2-capable routers", as described
in section 5.2.14. Version 2 Multicast Listener Reports will be sent
to this special address.In addition, IANA has assigned the ICMPv6 message type value of 143
for Version 2 Multicast Listener Report messages, as specified in
section 4. -
@louis2 said in IOT-LAN; How to handle multicast !?:
that I should never block that address if there can be multicast clients on the particular (v)lan.
Pfsense has ZERO to do with blocking that from any other clients on that network.. Pfsense is a router/firewall - it routes traffic to other networks.. Pfsense has no way to block multicast, broadcast or unicast between devices on the same network..
to take care that the router is yes no listening to multicast messages
Pfsense is in no way going to do anything with traffic sent to ff02::16.. out of the box.. sure it will log it with your block all rule.. But out of the box pfsense has zero use or anything to do with traffic sent to that address itself.
-
John,
The address is probably handed over to applications like avahi and pimd etc.
So probably not handled by the pfSense core but applications in the background.Just a feeling
Note that my feeling is that the address is probably, also used for protocols related to automatic network discovery protocols.
perhaps does stephan knows more -
@louis2 said in IOT-LAN; How to handle multicast !?:
The address is probably handed over to applications like avahi and pimd etc.
As I already pointed out - are you running any of those? Avahi has zero to do with that for sure, it only handles mdns, that is not sent to that address..
Yes you could route multicast with pimd, but that ff02::/16 is not a routable multicast address..
If you think pfsense needs to see that traffic, then allow - doesn't matter pfsense isn't going to do anything with it.. Like I said from the get go and you got all nuts about allowing.. If you want not see that traffic in your log everything rule at the end - then either deny or allow whatever traffic and don't log it.
But you allowing it or denying it at pfsense has ZERO to do with any other clients seeing or not seeing that traffic.. Pfsense can not stop multicast or broadcast or even unicast between devices on the same network.
But pfsense isn't going to do anything with that traffic anyway - so you deny it or allow it doesn't matter as long as it triggers a rule before it gets to your log everything rule at the end.
-
John,
I am going
- to allow it for vlan's using music streams etc, and
- deny it for vlan's from which I am sure they do not need it and
- block it for vlan's which should not be accesable for data network discovery
Other vlans I will probably pass it, with logging to get better understanding.
(and decide later on pass or block) -
@louis2 said in IOT-LAN; How to handle multicast !?:
Other vlans I will probably pass it, with logging to get better understanding.
Pass it to what?? Pfsense - what is pfsense going to do with it?? Nothing!!
what you do on pfsense has nothing to do with other clients on that network seeing or not seeing the traffic.. Pfsense routes traffic off the network.. It is not involved with traffic be it unicast, multicast or broadcast traffic between devices on the same network.. What you do with it on pfsense is not going to have any effect on if some other device on that network..
But create any rules you want so its not logged, which was what you were asking about.. But pfsense is not going to actually do anything with traffic sent to a ff02:16 address, it sure isn't going to route it anywhere else.
