Project

General

Profile

Bug #9476

pfSense 2.4.x sending ARP replies with non-CARP source MAC address

Added by Michael Reygers over 1 year ago. Updated 4 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
CARP
Target version:
Start date:
04/15/2019
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.x
Affected Architecture:
All

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

History

#1 Updated by Renato Botelho about 1 year ago

  • Assignee set to Luiz Souza

#2 Updated by Marc Hodgins 5 months 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).

#3 Updated by Viktor Gurov 4 months 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.

#4 Updated by Marc Hodgins 4 months 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.

#5 Updated by Luiz Souza 4 months 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.

Also available in: Atom PDF