Bug #6957


CARP arp reply with wrong src mac

Added by zhiwu shan over 5 years ago. Updated almost 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


The problem is same as
I find a patch on pfsense/FreeBSD-src to solve this problem.
But,I set value to 1, still wrong src mac, not the virtal carp-mac as the src.

I test VRRP from other system. that's ok. vrrp arp reply right carp-mac as src.

Actions #1

Updated by Jim Thompson over 5 years ago

  • Assignee set to Luiz Souza
Actions #2

Updated by Tobias Wigand over 5 years ago

This also seems to have a negative effect on switches the pfSense gateway is not directly connected to. I.e. pfSense lives on my "core" switch. I have 2 other switches connected to that switch. The switches have problems locating 00:00:5e:00:01:01 and flood every frame destined to that address to all switchports. That also applies to WLAN APs connected to those switches and this is where it gets problematic for WLAN performance.
The fix does not seem to have made it to 2.4 beta yet it seems, would be great if it could be implemented to beta test it.

Actions #3

Updated by Marc L. about 5 years ago

We have the same problems in our setup.

A switch is connected to two pfsense firewalls with a CARP setup. Since the pfsense sends the packets with the wrong (imho) MAC src, the switch never updates his source address table for the virtual MAC of the CARP IP. Therefore, all packets with destination Firewall (CARP IP/CARP MAC) are always flooded on the network!

We're using pfsense in version 2.3.3. The option is set to 1, but the src mac is still wrong.

Update: What I forgot to mention is that it doesn't only affect ARP requests/replies, but all traffic.

Actions #4

Updated by Jim Pingle almost 3 years ago

  • Category set to CARP
  • Status changed from New to Closed

That patch was removed long ago, and is not included in pfSense 2.4.x or 2.5.x. Doubtful there is anything to do here since the problem is in the third-party equipment (read the last few notes on the FreeBSD bug report above)


Also available in: Atom PDF