So to answer my own question the only real difference I can see in practical terms is - /26 for WAN side and CARP VIPs ties you into using a /26 whether you end up using the IPs or not. If you end up not using them then you are wasting IPs and to get them back (assuming you could depending on how many had been used) you would need to change subnet mask of WAN side and upstream devices etc. /29 for WAN and /26 routed to the CARP VIP gives a lot more flexibility ie. you can reserve a /26 but actually route a /28 to the CARP VIP and if you run out of IPs you can simply change the route entries on the upstream devices to use a different subnet mask. You are still reserving the /26 but if it turns out the demand for IPs is not there then you can reuse for other purposes. In the environment I work in where public IPs are scarce this is quite useful because it means you never overcommit on IP address allocation.

@operations HA on dynamic WANs (DHCP, PPPoE) is generally unsupported.

@viragomann Thanks for your input! Issue solved! It was issue basically frame untagged on switch of particular VLAN, so after tagging it works and able to connect secondary and sync!

@hege Late reply on this topic, but relevant. Hyper-V SR-IOV implementation does NOT support mac spoofing with SR-IOV Technical; Mac spoofing is required for CARP because the mac address is changed on outbound packets, that's part of CARP. Hyper-V natively does not allow outbound packets through the virtual switch from a Hyper-V guest that does not have the exact same mac address as assigned to the virtual machine (unless you enable the "allow mac spoofing" checkbox. SR-IOV technically can allow mac spoofing, this is all there in the IEEE specification for for this is to work, but, quite simply Microsoft Hyper-V doesn't implement it. Therefore you need to enable "allow mac spoofing" and forego SR-IOV or VMQ network accelerate functions.

@derelict said in high availability w/ redundant layer 2 switches causing loop on my test network: People call all sorts of things a "lagg." Very true - its a kind of a catch all.. I was thinking lacp, which yeah you need a stack..

@viragomann Thanks for your help!

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.