Bug #9476
closed
pfSense 2.4.x sending ARP replies with non-CARP source MAC address
0%
Description
pfSense 2.4.x will send ARP replies for CARP interfaces with the local system's "real" source MAC address, instead of using the CARP source address.
Some switches will reject this constellation, and as a consequence, will not add the pfSense gateway MAC address (= CARP address) to their MAC address tables.
Such switches will then flush any traffic destined for the pfSense CARP address to all of its interfaces.
There are multiple reports on the forum about major throughput problems in HA CARP configurations, up to the order of a 90% traffic drop, which I believe may be caused by this problem.
Some switches do not seem to mind about the MAC address mismatch, some switches can be configured to explicitly discard or allow such packets, but some switches just silently drop such mismatched ARP replies and will cause throughput to plummet.
I suspect that some CARP MAC handling code (such as the "net.link.ether.inet.carp_mac" sysctl, which was present in 2.2 and 2.3), hasn't been ported over to pfSense 2.4:
SYSCTL_VNET_INT(_net_link_ether_inet, OID_AUTO, carp_mac, CTLFLAG_RW,
&VNET_NAME(arp_carp_mac), 0,
"Send CARP mac with replies to CARP ips");The patch may have been lost while synching up with FreeBSD, which apparently still doesn't include any mechanism to use the "proper" CARP source address for ARP replies.
I believe earlier pfSense versions even had a different (non-configurable) patch for this problem.
See also: bug #6957
Updated by
Updated by Marc H over 4 years ago
This is a problem for cable modem setups in particular. Many providers are willing to issue multiple IPs to allow CARP, but the cable modems are configured with a limit of one IP per MAC, so they drop the replies when they originate from an unexpected source MAC (the physical interface rather than the virtual CARP MAC).
Updated by Viktor Gurov over 4 years ago
See #6957 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=141023#c4:
According to RFC826, which is current standard for ARP implementations,
the hardware address in the transmission layer does not need to match
the hardware addrees in the ARP reply packet itself.
Updated by Marc H over 4 years ago
Viktor Gurov wrote:
See #6957 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=141023#c4:
According to RFC826, which is current standard for ARP implementations,
the hardware address in the transmission layer does not need to match
the hardware addrees in the ARP reply packet itself.
The objective should be to make CARP usable. Restoring the net.link.ether.inet.carp_mac switch (or similar) wouldn't violate the CARP standard and would improve compatibility. Just because the existing behavior doesn't violate the standard doesn't mean more can't be done to improve compatibility. Right now CARP is totally unusable in many cable modem setups due to this issue.
Updated by Luiz Souza over 4 years ago
- Status changed from New to Rejected
I'm closing this ticket because the requested functionality cannot be implemented with the current CARP support in FreeBSD.
The sysctl knob made sense in the past when CARP was a pseudo-interface, now CARP is just an IP alias and fixing the ARP source on packets would require tracking connection states.