Thank you for the help guys! One of the instances is physical, the other is virtual. We were holding up moving to 100% virtualized because of this problem, but we're going to move forward since the interfaces will be named the same after the upgrade.
Thanks for this, I would have never figured it out.
I've kind of got there with this, the problem I currently have is that outbound traffic is still going through the dynamic IP rather than one of the statics. could anyone advise me on how to make it use the static please.
I have 3 clusters of pfSense running on a nework and they all co-exist well.
You absolutely need to ensure that the VHID is different between each cluster set, and also that it does not overlap any other CARP or VRRP instances running on the same L2.
If you are using IPv4 and IPv6, you also need different VHID for each protocol.
It works well when I use a real public ip rather than a private ip (I used for test).
When I use a private ip as wan ip,it's not work,even though I unchecked "Block private networks" option.
That's not an answer for what you're looking to accomplish. Can only sync the entirety of that portion of the config (which almost certainly won't be identical across everything), and can only do so to one other host.
Some have hacked up their own solutions to accomplish parts of that, specific to their general config management usage. We'll have a solution for centralized management in the future.
I'm assuming I'd just configure my virtual ips (from my ripe range) as carp in the vip table?
Use type Other VIPs if you're just using for NAT. If public IPs directly assigned on an internal interface, then you want a CARP VIP on that subnet on the internal interface.
The interfaces should, ideally, be identical for pfsync to function properly since the states are bound to interfaces and they use the physical interface names when doing so.
That can be worked around by using single NIC LAGG entries but that can be tricky/cumbersome.
Morning,
Thank you for the reply, i solved it yesterday, i was just testing in the interim to make sure.
Turns out it was a "school boy error" that i only noticed when i was setting up the test lab….i missed enabling mac spoofing on the LAN NIC on one of the PFs' :P ha ha.
The solution to this problem was a caffeine increase. ;)
Depends on how your routing works. Generally speaking, no, not without source NAT to one side or the other (which is bad for anti-spam appliances), and not in a way that's geographically redundant, where using a single public IP. Multiple MXes with separate IPs is the best if not only option for redundancy. There are options, tends to get complex though. Probably more than you'll find reasonable help with on a forum because of the complexity. Would be a good fit for professional services.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.