How to filter / pass multicast !?
-
@louis2 here I validated that seeing igmp traffic via tcpdump on my wlan interface - mine and my wifes phones see to be sending out that noise.
So created a rule, and there you go its logged..
Again - do you have anything in floating? Just at a loss to some of those rules to be honest.. in what scenario for example would non interface network traffic be seen your block-if-outside-address rule..
Why are you not using net as source? You understand there default deny right, if you do not allow the traffic then it would be denied..
So if you didn't have !locIPv4 any any rule set to virtualmachine net as source, it would be impossible for non virtiualmachine net wouldn't be able to get anywhere, etc.
Maybe setting that option for IP options is causing the rule not to trigger.. If IP options is not set, that would be my take. Let me sniff and see if the traffic my devices are creating to 224.0.0.22 have options set..
-
John, to answer some questions:
- I have floating rules, however not related to this vlan, further on note that floating rules have either the highest or the lowest priority, they are not related to something half way a rule set. I use them e.g. to generic forbid things.
- I use !VIRTUAL machines as source to be extra sure that there are no frames on the vlan, from IP-sources which should not be there (e.g. traffic routed via the wrong default route)
- there is a principal fault in the way firewalls work IMHO,
- firewall describe where you are allowed to go and NOT
- who is allowed to enter the door (it is you who determs if he/she is allowed to enter your home, that is not up to the person who wants to enter your home.
So I have to take measures that ^no one^ is allowed to go from that vlan to one of my other vlan's
- I did all ready test the 'not working rule' with and without the IP-option clause. I did test that again. Both situations do not work!
-
@louis2 said in How to filter / pass multicast !?:
, from IP-sources which should not be there (e.g. traffic routed via the wrong default route)
Routed where? You have some downstream router and your using this as a transit network.. Rules are inbound only, floating can do outbound rules.
Again the default is deny, If you don have a specific allow rule then the traffic would be blocked.. So lets say something was "mis routed" or somehow non virtual machine source traffic ended up hitting this interface. If you correctly limited your source of your rules to the network, or specific IPs those would all be dropped by your default deny..
I would get rid of whatever advanced thing you did on that rule to 224.0.0.22 and make sure you have no states to that IP.. Is your 224.0.0.22 not being logged
I see a bunch of IPs going to 224.0.0.22 not just 100.15, there is 100.18, .6 and there is traffic to 224.0.0.1 as well which your rule wouldn't pick up and your allow would, etc.
-
John,
- I know the rule should be broader the .15 but I need to fix / understand this first
- I have been trying to set up VM's and ..... I stopped with those try's up to a couple of weeks ago, since the vlan handling of those vm-systems, did route traffic related to vlan-a, vlan-b, vlan-c via one and the same gateway. Not acceptable at all. I think that TrueNas scale in its latest version does do it correct, but to be sure I check if the source really belongs to the expected vlan
-
@louis2 said in How to filter / pass multicast !?:
but to be sure I check if the source really belongs to the expected vlan
That is not really what your doing.. And proper rules with the source set as the network the interface is attached to automatically makes that check moot..
Also looking at your rules another one that just jumped out at me as why.. your dns,ntp and dhcp rule - you understand when you enable dhcp server on an interface - hidden rules are created to make sure dhcp works. There is zero reason to create any rules that have anything to do with dhcp at all..
if was mean and wanting to troubleshoot why something isn't working like your igmp rule that should not log, and traffic being allowed by some other rules - is just clean up my rule base to very basic.
Like you saw in my setup.. 2 rules.. Simple order, etc.. easy to check state table by just looking for any states with 224.0.0.22 etc..
Other than what you have set in advanced (the little gear) from what you show logged and that rule - that rule for pass multicast should be what is allowing the 224.0.0.22 traffic and no it shouldn't be logged by your allow ipv4 internet rule.. So its either something you have in the advanced?
-
You have a point ... those hidden rules
If I check as first rules if the source is OK, I do not need to do that / place any in the other rules, unless I want to filter a special source
-
@louis2 said in How to filter / pass multicast !?:
If I check as first rules if the source is OK
Sure rules are done in order, if you block any source other than your network, then no traffic with source other than your network would ever be able to be seen by rules below.
But again better practice is to set the source on all your allows, the only possible source should be your virtualmachine net, if you set that on all of your allow rules, then anything that is not then when not allowed would be blocked by the default deny anyway..
the only time source should really be any in your interface rules would be if your using this interface as a transit, and you have no idea what the downstream networks might be, which is kind of impossible anyway - because how would you nat them, so they should be something in rfc1918 so if creating rules on your transit interface vs using any for source, should use either alias or cidr that limits the scope to the networks you might see that you want to allow.
You might also not use source of "yournetwork net" when you want to allow a specific IP or IP(s) etc.. But I really can not think of when you would want to use any "*" as the source network to be honest on any rule, other than say the public internet for your wan rules - because there is no good way to say "public ip space" ;) But on your network you for sure should be able to know what address space your traffic into an interface would be coming from.. If not that, then it would be blocked by the default deny.
-
One thing related to source and than I would like to go back to the original issue / still the issue:
- IPV6 is ...... a drama ..... in regard to source, in fact given the many routing address types it is impossible to filter IPV6 source. That is the reason that that rule is disabled, it simply does not work
- I did ask for mac-based rules many times to compensate for the IPV6-routing drama
- .... Yes I know its another network layer and
- Yes I know you can manipulate mac's (just like, perhaps even simpler IP's)
- many firewalls can
Whats ever, lets go back to the multicast rule issue ....
-
@louis2 said in How to filter / pass multicast !?:
in fact given the many routing address types it is impossible to filter IPV6 source
huh? Not sure what you mean there.. The devices I have that I let use IPv6, I hand them a IPv6 address that I can firewall on..
As to the multicast rule - I am not having any issue with the rule I created for 224.0.0.22 being seen by that rule, and logged by that rule, etc..
-
John, the ^multicast rule problem^ seems to be the state table.
And that does not seems OK to me. I never / noticed a situation before that a rule did not work.
Now nothing!! else even restarting the interface or dis and enable the rule etc was enough to make the rule work!!
Seems a bug to me!
A few not related remarks:
- the rule related to the router functions, is required despite the invisible
default rules, because some applications do not use the gateway as DNS etc.
(which I do not like, for which reason I sometimes redirect force those functions to the GW) - related to IPV6, yep if you use e.g. netplan you van force the server to use a specific IPV6-IP (and you can filter that one). However:
- fixing IP via DHCP6 + RA is a drama (It does hardly work see my tests https://forum.netgate.com/topic/178423/some-doubts-about-router-advertisements/6)
- host generates IPV6 it-self e.g. for security purposes etc
And I should try again, but in the past (not too long ago), the pfSense filtering on 'vlan-net' was a drama / did not work. As said I should perhaps retest ..
What ever returning to the issue ^How to filter / pass multicast !??^, to put it mild I would not be surprised if there is a bug !
- the rule related to the router functions, is required despite the invisible
