Keeps blocking
-
that is multicast traffic and pfsense is not going to route that traffic.
They are not the same as above.. you can tell from simple looking at the dest addres that its multicast traffic. The first traffic was RA on the flags, which RST,ACK - which screams out of state traffic.
If you do not want to see such noise in your logs, then allow it so its not logged via a rule with that dest. Turn off default logging.. Create a rule that blocks it and doesn't log it.
If you turn off default logging, then you can create rules that only log what you want, etc.
Thee are many ways to skin the cat of not seeing multicast noise in your default deny rule.
-
that is multicast traffic and pfsense is not going to route that traffic.
They are not the same as above.. you can tell from simple looking at the dest addres that its multicast traffic. The first traffic was RA on the flags, which RST,ACK - which screams out of state traffic.
If you do not want to see such noise in your logs, then allow it so its not logged via a rule with that dest. Turn off default logging.. Create a rule that blocks it and doesn't log it.
If you turn off default logging, then you can create rules that only log what you want, etc.
Thee are many ways to skin the cat of not seeing multicast noise in your default deny rule.
I don't understand everything you are saying yet, I understand that it's Multicast traffic. I thought that with the ip options enabled in a pass rule they would not appear in the logs as they are not blocked anymore, what am I missing (hope it's not a lot ;) )
…and why am I seeing it (multicast traffic) even on subnets (only when I enable the IGMP proxy) that are not in the config of the IGMP proxy? Does pfsense do this, because I enabled the IGMP proxy? below is a ipv4 multicast address from a subnet that's not in the IGMP proxy?
Apr 14 15:10 P2P 192.168.2.20 224.0.0.22 -
<off-topic>When I start the IGMP proxy between WLAN interface and WLANGuest, I get
Apr 14 13:10:04 WLAN Default deny rule IPv6 (1000000105) [fe80::144e:9527:a03d:293]:5353 [ff02::fb]:5353 UDPApr 14 13:09:22 LAN Default deny rule IPv6 (1000000105) [fe80::3126:68f3:b35:9966]:1900 [ff02::c]:1900 UDPare they the same as above as I don't understand why they are because the rules allow to any and there is even a block on the LAN interface, Yet, it's not in the IGMP proxy config?</off-topic>
fe80:: != WLAN net address even if it originates from the WLAN net, thats why its hitting the default block rule and logging.
-
that is multicast traffic and pfsense is not going to route that traffic.
They are not the same as above.. you can tell from simple looking at the dest addres that its multicast traffic. The first traffic was RA on the flags, which RST,ACK - which screams out of state traffic.
If you do not want to see such noise in your logs, then allow it so its not logged via a rule with that dest. Turn off default logging.. Create a rule that blocks it and doesn't log it.
If you turn off default logging, then you can create rules that only log what you want, etc.
Thee are many ways to skin the cat of not seeing multicast noise in your default deny rule.
What would be an example of and allow rule, as they are hogging up the logs or would you advise otherwise?
-
Are you using ipv6.
The default allow ipv6 rule would prevent the logging if changed to any as source. I think NogBad is correct in that the fe80 link local is what is flagging it to be dropped because it does not = the ipv6 net on your wlan interface?
Comes down to are you using ipv6 or not to the best way to remove this sort of noise from the logs.
-
Are you using ipv6.
The default allow ipv6 rule would prevent the logging if changed to any as source. I think NogBad is correct in that the fe80 link local is what is flagging it to be dropped because it does not = the ipv6 net on your wlan interface?
Comes down to are you using ipv6 or not to the best way to remove this sort of noise from the logs.
Apr 15 15:28:13 WLAN Default deny rule IPv6 (1000000105) [fe80::1885:465b:bf10:40b6]:5353 [ff02::fb]:5353 UDPI tried adding it to the allow but it still keeps hammering the logs (pulling my hairs out :( ).
I don't quit understand what you and @NogBad mean to say. Could you give and example or point out what I am not doing or doing wrong in my firewall rules to get rid of it.
-
your rule to dest ff02:fb should work other than your source is set o wlan net.. which is not what the source is fe80 is not wlan net. Set the source to any ipv6 on that rule and it should stop your log spam..
If you don't want to set any for the source, set it to the link local prefix FE80::/10
-
your rule to dest ff02:fb should work other than your source is set o wlan net.. which is not what the source is fe80 is not wlan net. Set the source to any ipv6 on that rule and it should stop your log spam..
If you don't want to set any for the source, set it to the link local prefix FE80::/10
That worked, your a lifesaver jhonpoz 2 thumbs up ;)
Apr 15 16:57:33 WLAN Default deny rule IPv6 (1000000105) [fe80::5c94:2cc1:5329:99c4]:546 [ff02::1:2]:547 UDPI looked at Wireshark and saw the mac address, looked at the DHCP server (as it serves IP on mac address) and found it to be a Labtop. Is there any other way I could have looked it up an easier way, preferably using pfSense and not Wireshark?
I still don't understand why WLAN as source did not work, could you point that out to me?
-
Because your wlan net is say 192.168.1/24 or whatever your IPv6 global network is you got from your ISP or HE tunnel you setup, etc.. say 2001:470:xxxx::/64
fe80::XXXX is not your IPv4 or your IPv6 network, its a link local address that does not fall under your "net" listings for your different interfaces.
You could of just done your sniff on pfsense for that dest port if you wanted to find the mac of what was sending it.. Just set the level to FULL and it would show you the mac in the output.
-
Because your wlan net is say 192.168.1/24 or whatever your IPv6 global network is you got from your ISP or HE tunnel you setup, etc.. say 2001:470:xxxx::/64
fe80::XXXX is not your IPv4 or your IPv6 network, its a link local address that does not fall under your "net" listings for your different interfaces.
You could of just done your sniff on pfsense for that dest port if you wanted to find the mac of what was sending it.. Just set the level to FULL and it would show you the mac in the output.
I'd missed that setting, were can I set it to Full?
-
In the packet capture settings when you do the capture… Its right there next to the start but - kind of have to be blind to miss it.
-
In the packet capture settings when you do the capture… Its right there next to the start but - kind of have to be blind to miss it.
LOL ;) Maybe Yesterday, I was not the sharpest knife in the drawer, but getting sharper by every post!
Could you advise on my rule-set, as I already have 3 rules now for multicast, I would like to catch all multicast ipv6 and ip4 addresses or is that not wise?
btw under advanced options should not be enabling Allow IP options not be a thing?
-
pfsense is not going to do anything with multicast unless your running the igmp proxy?
If you do not want to see the log of such noise its almost easier to just turn off default logging and create the rules to log the traffic you want to see. Say tcp syn only packets.
You could combine those 3 rules into one by just using ff02::/16
-
pfsense is not going to do anything with multicast unless your running the igmp proxy?
If you do not want to see the log of such noise its almost easier to just turn off default logging and create the rules to log the traffic you want to see. Say tcp syn only packets.
You could combine those 3 rules into one by just using ff02::/16
I'm quit lost when it comes to CIDR (but there are calculators enough around) and Multicast is not really my thing, but as I need to give phones and tablets control over Sonos devices that are in different VLAN's, I have a IGMP proxy setup (don't want IGMP snooping using a switch). I also have the Avahi service running as Bonjour printers are also in a different VLAN. So suddenly, I am confronted with IPv6 and Multicast…
If I would like to follow your advise are there examples "better a good copy, than a bad original"
