System log message kernel: arp: 43:05:43:05:00:00 is multicast
-
Might want to mention that open mesh does it on purpose, etc. You can see from the mac that it is a multicast mac because of the 43, that ends in 1 - so it is a multicast mac
43 = 00101011
Ends in 1 = multicast.
-
Yes. The open mesh devices do it on purpose. Something about helping with maintaining a loop free network and bandwidth testing. I haven't been able to find anything useful in their knowledge base at help.open-mesh.com about multicast ARP. Just the info at Duck Tech's blog. I was hoping one of the ESF guys might comment on the security ramifications of enabling multicast ARP on the firewall (if their are any).
BTW: pfSense and open mesh access points are quite the powerful combination IMHO.
-
you could also just not log it.. Vs allowing it.
-
I had thought of that initially, but didn't see any option in the GUI to suppress logging only that message.
-
you disable logging bogon..
-
This is not bogons logging it at all. Also, not a bug.
https://redmine.pfsense.org/issues/4284
-
You are right dok as normal – I was confusing this thread with the other ones about bogon noise in the log.. This is in the system log not the firewall log.. Thanks for the info and link.
-
This is not bogons logging it at all. Also, not a bug.
https://redmine.pfsense.org/issues/4284
I don't know how pervasive the issue might be, but in the redmine ticket someone suggested adding a checkbox in the GUI to turn multicast arp off or on in violation of RFC 1812, instead of adding it as a tunable. It looks like it also affects folks using Windows load balancing behind pfSense, in addition to those using open mesh devices.
I agree with the suggestion of adding a checkbox in the GUI, provided the issue affects enough of us.
-
Given that it requires violating an RFC, the tunable is likely the only place this will be handled.
I added Open Mesh to the upgrade guide section that mentions this behavior change:
https://doc.pfsense.org/index.php/Upgrade_Guide#Microsoft_Load_Balancing_.2F_Open_Mesh_Traffic -
Jim,
I read what you wrote in the upgrade guide. There is no mention in what you wrote WHY one would want to add the tunable to their firewall configuration. What specific symptoms would lead you to needing this tunable?
With respect to the open mesh access points, the traffic doesn't need to be handled by the firewall at all. The main issue was messages filling up the system log, making it basically unusable. Windows NLB is another animal altogether.
Also, my question of the security ramifications of adding this tunable, thereby reverting the kernel back to its previous behavior, has yet to be answered. Just for the sake of completeness, I think we should have a discussion of how this impacts security. Was the behavior changed from FreeBSD 8 to FreeBSD 10 just for the sake of being RFC 1812 compliant, or is there a good sense security reason for the change?
Is there a possibility that logging this kernel message could be suppressed (in a future version of pfSense), instead of enabling a behavior that violates the RFC?
Thanks for all you guys do,
Anthony
