System log message kernel: arp: 43:05:43:05:00:00 is multicast
-
Since upgrading a customer from 2.1.5 to 2.2.1 I ran into an issue in my system log. I thought I should share the solution with the community.
This customer has several open mesh OMP2 wireless access points. Since I upgraded their firewall, replacing their soekris net 6501-30 with an RCC-VE 2440 (which went VERY smoothly…kudos the development team), my system logs have been overrun with this message:
kernel: arp: 43:05:43:05:00:00 is multicast
The fix, is to add a system tunable:
net.link.ether.inet.allow_multicast=1I don't know if there are any security ramifications to adding this tunable, or if it just suppresses the messages.
-
yeah open mesh seems to use those.. A google found this article
-
That's where I initially found the info when I first experienced the problem with one of my customers' firewalls. I just thought it might be a good idea to have it noted in the pfSense forum, too.
-
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.
-
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.
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
