Duplicate (DUP!) ping replies with CARP in virtualized environment

Started by nothingtou, February 25, 2026, 08:03:48 AM

Previous topic - Next topic
Hello, I am relatively new to OPNSense, so I would greatly appreciate any guidance and constructive feedback.

I am running OPNsense HA with CARP (2 nodes) in a cloud provider VM environment.

CARP state is correct and verified:

MASTER:
carp: MASTER vhid X

BACKUP:
carp: BACKUP vhid X

There is no split-brain situation. The LAN VIP status is correctly shown as MASTER on one node and BACKUP on the other.

I created VMs that run behind OPNsense. However, I am consistently receiving duplicate ICMP replies (DUP!) in the following cases:

- Ping to the LAN CARP VIP (gateway)

- Ping to external IP addresses (e.g. 8.8.8.8)

- Ping to google.com

Important observations:

- When pinging the individual LAN IP addresses of each firewall node (not the VIP), there are no duplicate replies.

- The duplication only occurs when traffic involves the LAN CARP VIP.

- If I disable packet filtering on the BACKUP node using "pfctl -d", the duplicate replies immediately stop.

Packet capture on the BACKUP node using "tcpdump -eni LAN" shows:

- The BACKUP node receives ICMP requests destined to the CARP VIP.

- The BACKUP node sends ICMP echo replies.

- The source MAC of those replies matches the BACKUP LAN MAC address.

So even though the node is in BACKUP state, it still processes and replies to traffic involving the CARP VIP.

Specifically:

- What would be the proper troubleshooting steps to determine whether this is expected behavior or misconfiguration?

Thank you.

Under Interfaces -> LAN do you have Prevent Interface Removal checked? I saw what you're describing when testing failover. Shutting down the primary the VIP would move to the secondary as expected, and it would return to the primary when that host came back up. CARP status in the GUI looked correct in both states, but my ping check to the VIP started showing DUP messages as you describe. Unchecking the Prevent Interface Removal on the LAN interface solved it.

So wild guess that preventing removal is also preventing some kinds of reconfiguration.