Problem isolated and solved Working with a hosting provider and not having access to the underlying configuration layer means things get lost in translation. The problem is/was Forged Transmits in the ESX environment that needed to be disabled so the CARP IP on the PFSense can create multiple MAC addresses and send/receive on these. First paragraph here says it, but not having access and poor communication with hosting provider makes it difficult to debug by one self. https://docs.netgate.com/pfsense/en/latest/troubleshooting/high-availability-virtual.html?highlight=vmware

@pirateparley last bump before giving up!

A bug for the issue has been raised.

@derelict said in Upgrade to 2.5.0, now seeing 224.0.0.18 CARP blocks: @defunct78 It is your virtual environment improperly echoing back the CARP advertisements. They are being properly blocked by that rule. https://kb.vmware.com/s/article/59235 https://docs.netgate.com/pfsense/en/latest/troubleshooting/high-availability-virtual.html#changing-net-reversepathfwdcheckpromisc That was it. Fixed the problem perfectly. Thanks.

Hello, realize this is an older thread but looking to gain insight on the subject as well. I have a /26 public IP block, and currently use ProxyARP and 1:1 NAT to route traffic to Hyper-V VMs/web servers. I'll be adding subnets using VLANs to further isolate some new VMs. Is there any reason I should be using IP Aliases instead, or is ProxyARP fine for this application? Thanks for any enlightenment!

@mmangiante You may simply do that. VIPs are basically independent from interface IPs. They may moreover cohere with the WAN gateway. @mmangiante said in How safely change vip and their interface ip: If I simply change the ip on the interfaces and then update the vip ip I have done all or I have to change every NAT rule, every page that use that ips, the ipsec vpn? This depends on how you've configured your rules and services. If you used a variable as destination, for instance "WAN VIP", there is nothing to do. You only have to change the WAN VIP and you're ready. However, if you entered the IP explicitly, you will have to change it now as well.

Issue fixed, I juste forgot to check this on my backup node... [image: 1617028828744-90fd1a45-7445-470d-b737-83c90cf19d05-image.png] Also make sure all the pfsense are not on persistent CARP maintenance mode.

@derelict I may have found the problem. Possibly a corrupt or failing disk. I replaced the disk on the backup node today, rebuilt and and restored configs from a previous (recent) backup file. Everything looks fine now. I will keep monitoring in case the problem reoccurs, but it may be something as simple as this. A really strange symptom if it is in fact a failing disk. SMART status was OK, so perhaps some corruption from the recent power outage that took out my primary firewall disk. For anyone else who may experience this issue, try rebooting with the disk repair option, and/or change out the disk and rebuild/restore. Thanks for your help and guidance.

I Just wanted to update, came in today and just reset both machines to factory and started again, all seems to be working, fine. So I must have done something wrong or out of order. But thanks to all who commented.

@bennyc Thank you

@zerodeux You could have a single transit link to a layer 3 switch and have it route your 250 VLANs. All in all, an HA firewall with 250 interfaces is going to be work. It is also going to generate heartbeat traffic for all the first-hop redundancy VIPs. That is true for CARP, VRRP, or HSRP.

This seems to be identical to: https://forum.netgate.com/topic/161152/strange-problem-dhcp-failover-after-upgrade-to-2-5-0-xmlrpc-bug Solution: https://redmine.pfsense.org/issues/11519

@viragomann Thanks for your reply. Currently, I can't reach CARP IPs, I don't know where I'm wrong, CARP IPs of LAN is 172.16.100.4. I only can ping CARP IPs of WAN 10.84.100.4 and if I create master 10.84.3.2, slave 10.84.3.3 with VLAN 3. After set up that you can add 10.84.3.1 as CARP VIP on the master. I cannot ping as well.