Bridge + CARP crashes/freezes pfSense
Same behavior as the linked bug below: running CARP on a bridge interface and sending any non-trivial amount of traffic to the CARP IP results in freezing pfSense.
Older issue: https://redmine.pfsense.org/issues/4607
On a VirtualBox VM the VM just freezes, whereas on real hardware the hardware did not completely freeze (e.g. the serial console was somewhat usable), but various processes ended up in locked state, as per the symptoms drescribed in https://forum.pfsense.org/index.php?topic=139030.0
The problem is mitigated when traffic is sent to the pfSense interface IP instead of the CARP IP.
#1 Updated by Anonymous almost 2 years ago
More context: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200319
This configuration works well on 2.3.3+ (didn't test any previous releases), but fails on 2.4.1.
#4 Updated by Harry Coin almost 2 years ago
PF deadlocks once every 3 hours or so. There's a process holding a lock (carp lock, bridge lock)? which then I think fires off an ifconfig which in part wants to display carp status and there it sits. Interestingly VGA/keyboard ops are locked, but it is still possible to run any non-network related thread via the serial connection. There's lots of detail on the above referenced report.
#7 Updated by James Freeman over 1 year ago
Confirmed - I can also replicate this easily. CARP on a bridged interface, tested on 2.4.2 and 2.4.2_1 with no change. pfSense running on VMware ESXi 6.5 and VMware Workstation 14, e1000 emulated NIC's, fully repeatable on both platforms. Happy to help with any testing required on this.
#8 Updated by Adam Boyhan over 1 year ago
Confirmed - We have 2 Netgate 8860 1u appliances setup with CARP + Bridge and when upgrading from 2.3.4 to 2.4.2_1 we hit this bug on both firewall's. Sometimes we would be ok for 10-15 minutes, other times we would make it past a hour of uptime. Ended up having to go back to 2.3.4 which is simply rock solid.
#9 Updated by Jim Pingle over 1 year ago
- Category set to CARP
- Priority changed from High to Normal
- Affected Version changed from 2.4.1 to 2.4.x
- Affected Architecture set to All
The underlying FreeBSD bug is still open:
The previous patch that was on 2.2.x and 2.3.x had some issues and was not accepted by FreeBSD: