Multicast Traffic from LAN blocked

JJ5588

Hey all, I'm in the process of setting up a new system. I have a LAN interface and a IoT interface and I see this in the logs:
Blocked Logs

As I'm setting up this new system, slowly, all I have on the LAN side is a phone and a laptop. On the IoT side I just have a robot vacuum.

What is the source 0.0.0.0 here? Is that pfsense? Not entirely sure how to address this whether that be a rule (so it doesn't show up in the logs) or change some setting in pfsense itself?

NogBadTheBad

@jimbowasthere do a packet capture, then pop the mac address into the wire shark oui page.

That should return the vendor.

JKnott

@jimbowasthere

0.0.0.0 is the system you're running pfsense on. With routing that address is often used as the internal default route.

JJ5588

Thank you for the responses. I tried a packet capture both within the PFSense GUI (on localhost, LAN, and IOT interfaces) and using wireshark connected to the two interfaces mentioned. I was not able to see any requests going to that address.

I'll be honest that I don't understand multicast.

@JKnott , do you know why PFSense might be making those requests, but then also blocking them? I dont' see any issues with the functionality of the three devices connected to this system at this point.

It might be some basic "networking thing" I need to attempt to understand. If that's the case what should I look up?

Thank ya!

JKnott

@jimbowasthere

While I don't know what's causing those, the 0.0.0.0 address has 2 uses I'm aware of. One, as I mentioned is the default route and the other is the address a device uses while obtaining a DHCP address.

As for multicast, they're fairly easy to understand. Multicast addresses are used to send traffic to multiple destinations. 224.0.0.1 is the all hosts multicast address, which means any packet to that address will be received by all devices and is preferred to using broadcasts. Also, a firewall will not block any packet from itself, unless specifically configured to do that. So, what I see is IGMP packets sent from pfsense to all devices on the local LAN. Because of the default deny rule, no other device can send those through pfsense. IGMP is used to manage a gateway, perhaps for passing multicasts.

johnpoz

@jknott said in Multicast Traffic from LAN blocked:

a firewall will not block any packet from itself,

Its pretty difficult to block pfsense from sending something from itself. There are hidden rules that allow pfsense.

Why would pfsense be sending multicast? Anyway.

While off the top the 0.0.0.0 source seems odd - that is coming from the network and not pfsense. The default block would never log traffic coming from pfsense.

The advice of sniffing to get the mac address is the best way to track down what is sending it.

JKnott

@johnpoz said in Multicast Traffic from LAN blocked:

While off the top the 0.0.0.0 source seems odd - that is coming from the network and not pfsense.

0.0.0.0 is used for a few things. I mentioned a couple. One instance when pfsense will use it as a source address is when it's initially getting a DHCP address. It is also used in routing. However, I don't know if pfsense would use it as a source for other purposes.

JKnott

@johnpoz said in Multicast Traffic from LAN blocked:

Its pretty difficult to block pfsense from sending something from itself. There are hidden rules that allow pfsense.

Actually, we were in another thread recently about someone filtering pfsense on the WAN side, IIRC. The solution was to use floating rules.
So, yes you can block pfsense from sending something on an interface, but it's not typical, other than to prevent private addresses from escaping, as was the case in that thread.

johnpoz

Even floating rules don't work from blocking pfsense itself.. Yes you can create blocking outbound rules. But look at the rule orders.. For outbound from pfsense.

Internal automatic rules (pass and block for various items like lockout, snort, DHCP, etc.)

User-defined rules:
    Rules defined on the floating tab
    Rules defined on interface group tabs (Including IPsec and OpenVPN)
    Rules defined on interface tabs (WAN, LAN, OPTx, etc)

https://docs.netgate.com/pfsense/en/latest/nat/process-order.html

JKnott

@johnpoz

From the docs:

"Similarly, they can be used to prevent traffic destined for private networks from leaving a WAN interface, to prevent VPN traffic from leaking."

A Former User

@johnpoz said in Multicast Traffic from LAN blocked:

Even floating rules don't work from blocking pfsense itself.. Yes you can create blocking outbound rules. But look at the rule orders.. For outbound from pfsense.

pfSense has for every IP Interface an internal rule labeled "let out anything from firewall host itself". This rules are indeed placed before any floating rules, but have no quick statement and only applies if no further rule matches. A floating Deny-Rule with a Quick-Option will definitely supersede the internal allow rule.

@jimbowasthere

The IGMP Traffic is coming from some device on your network, maybe from a switch you are using behind your firewall (my guts tell me IOT is a vlan trunk on the physical LAN interface). If you click on the red cross under the action column in the firewall logs you get some further details about the rule which blocked the traffic. A rule has usually a direction statement (in or out). I'm pretty sure it is an "in" direction rule filtering the IGMP Messages, so this traffic cannot origin from your pfSense. (Assuming LAN and IOT are ethernet interfaces and not of a special kind like IPsec where other weird shit may happen during rule processing)
Traffic to 224.0.0.1 is flooded to every port on your switch, so just connect a notebook and let wireshark in promiscuous mode run for a while to figure out the source mac. With this information you can lookup the vendor by the OUI (first three octets of the mac).

AKEGEC

Well both @johnpoz and @JKnott are right. There are some system rules are hidden, but because of the bugs, it doesn't work and as a result you can blocked egress with floating rule.
The rule orders:

System rules
Floating rules
Interface rules

JJ5588

Thank you all for the information! I tabled this issue for a while, but have since come back to it.

The LAN has a vlan tag and that is connected to pfsense over a trunk from a Netgear switch. I was eventually able to determine (via wireshark) that on this LAN side, the requests were coming from the LAN wireless access point based on the MAC address.

The IOT side connects to pfsense directly from its own access point. Again, once using wireshark I was able to see the multicast packets. They were coming from the IOT access point.

johnpoz

@jimbowasthere said in Multicast Traffic from LAN blocked:

the requests were coming from the LAN wireless access point based on the MAC address.

Well if you don't want those hitting pfsense, then you would block them at your switch.. I have some multicast acls setup for this very purpose. Not so much not hitting pfsense, but for not flooding the rest of the network with just noise. So I block them on the switch port where they enter the switch from the noise maker..

But pfsense really isn't going to do anything with them anyway - unless you have pimd setup to forward them.. So if they are noisy in your logs - just setup a rule to not log them. Or if possible keep the noise maker from making the noise in the first place ;)

stephenw10

I would guess that you are seeing the access point sending some sort of auto discovery packets before it has an IP itself. Probably to allow it to be configured from a phone app for example.

I would not expect to see that blocked if it was traffic coming from pfSense because, as has been stated, traffic from the firewall is allowed out by default.
However you can block it using custom floating rules and that's not a bug.
The rules are above the user rules in the ruleset but they are not set QUICK:

# let out anything from the firewall host itself and decrypted IPsec traffic
pass out  inet all keep state allow-opts tracker 1000110245 label "let out anything IPv4 from firewall host itself"
pass out  inet6 all keep state allow-opts tracker 1000110246 label "let out anything IPv6 from firewall host itself"

So user rules below it will also be parsed.
Note also they are set with 'allow-opts' so multicast should also be allowed out.

Steve

JJ5588

@johnpoz said in Multicast Traffic from LAN blocked:

So if they are noisy in your logs - just setup a rule to not log them. Or if possible keep the noise maker from making the noise in the first place ;)

These netgear routers functioning as access points with the default firmware don't seem to have that option sadly.

@stephenw10 said in Multicast Traffic from LAN blocked:

I would guess that you are seeing the access point sending some sort of auto discovery packets before it has an IP itself. Probably to allow it to be configured from a phone app for example.

This tracks. The Netgear Orbis do allow you to connect with a phone and when I did have the app installed it "found" the access point.

I put a rule in place so I don't these in the logs, but will definitely look into blocking it at the switch level at least for the LAN side. Thank you!

johnpoz

@jimbowasthere said in Multicast Traffic from LAN blocked:

definitely look into blocking it at the switch level at least for the LAN side

Here is my ACLs that block some noise makers from putting their noise on the network..

What switch(es) do you have?

3 of those ports are where my AP are connected, another is uplink between switches. And then another is my plex running on nas - can't seem to turn off its noise maker, spewing a multicast discovery every 10 seconds. Even though it should be turned off in the settings.. Put in a bug report about it - never got a response.. So I just block it from entering the network.

In the big picture its not all that noisy - but bugs the shit of me seeing such noise when doing sniffs on the network ;)

JJ5588

@johnpoz said in Multicast Traffic from LAN blocked:

@jimbowasthere said in Multicast Traffic from LAN blocked:

definitely look into blocking it at the switch level at least for the LAN side

Here is my ACLs that block some noise makers from putting their noise on the network..

What switch(es) do you have?

3 of those ports are where my AP are connected, another is uplink between switches. And then another is my plex running on nas - can't seem to turn off its noise maker, spewing a multicast discovery every 10 seconds. Even though it should be turned off in the settings.. Put in a bug report about it - never got a response.. So I just block it from entering the network.

In the big picture its not all that noisy - but bugs the shit of me seeing such noise when doing sniffs on the network ;)

The switch that would see this traffic is the Netgear GS305E which does not appear to have the ACL functionality you see outside of just controlling access to the switch itself. What do you have there?

johnpoz

I have 2 cisco sg300's, 28 and 10 ports..

Yeah such features are a bit above your entry level smart switch.. But more full featured switches can be had for reasonable prices..

The 28 port is pretty much my core switch in what is my office/computer room ;) while the 10 port sits in my av cabinet in the living room.