To get around the hassle of this setup, much like my own you can always do the following: Virtual side make the vNICS MAC for both boxes the same for the WAN interface. I use a termination box in front of mine for VDSL and a switch before it goes into the virtual environment. That's pritty much it. Will work, but note it will show as up on both boxes for WAN interface and the WAN graph will look a little odd on the standby box as expected.

pfSense HA/CARP is a Layer 3 failover system designed to failover in most router failure scenarios. Your vSwitch not passing traffic but having link up would be a layer 2 failure. You would need to build in redundancy at layer 2 for that.

Both the master and the slave send a lifetime of 30 seconds, which is in accordance with the value set for the AdvDefaultLifetime parameter in the automatically-generated /var/etc/radvd.conf on both boxes. However, I have set the Router Priority to Normal on the master and Low on the slave, so traffic normally always goes to the master. It's just the 30 second delay between the time the master goes down and the route disappears from the client PC that bugs me. At least with a setup where you can point to a CARP VIP (like in IPv4) and the VIP can move from the master to the slave in a split second that's a much faster failover time.

Thank You for your reply, I wasnt shure whether CARP should set VRRP MAC in ARP packagess outside FW/LAN context. Thank You for clarifying this, so we have to discuss the issue with our ISP.

You need a rule like that on the secondary for the initial sync. When that sync happens the rule on the sync interface on the Primary will sync to that interface so it also needs to be in place. If the rule is on the sync interface on the primary and you end up with nothing on the sync interface on the secondary you likely have an interface mismatch. Use Status > Interfaces on both to be sure they match. Everything on every interface has to match exactly Example: WAN Interface (wan, igb0) LAN Interface (lan, igb1.223) MGMT Interface (opt1, igb1.999) All three elements must match (WAN, wan, igb0) (MGMT, opt1, igb1.999) in the same order.

You should be able to access it on its interface address(es) instead of the CARP VIP(s).

Yeah. Make a host-only network switch for each one and a pfSense interface. Make a pfSense interface for each subnet. Put the firewall rules on each so they pass the traffic. If you don't want to make a bunch of vmware interfaces, then "tag" VLAN 4095 to a pfSense interface and the VLAN tags will be there so you can make pfSense interfaces on them. Beware that vmware scrambles your interface order after you add your 6th interface or something. Bottom line is putting all those subnets on one broadcast domain and expecting them to communicate is simply not the way to go. Each one should be on separate router interfaces so those networks can, you know, be routed to each other. Regarding the intermittent behavior, you are probably running into issues with different behaviors regarding ICMP redirects which is one of the main problems with that sort of design. I would never expect that to work 100%.

Yea im not sure, coulda swore i set them the same on both. I went ahead and changed the user back to the one i wanted on the primary node. Did a force sync and it works now...heh. hey it works. Thanks for the help!!

@umademelosemyusernamepfsense said in Assigning uplinks to VIPs: can you still take single out an address from the lot and masquerade it? Or do all have to be 1:1? I'm not sure I understand your question. Like I said earlier, I have 13 VIPs. One of them is our gateway. I could specify any of the others as gateways. I use NAT port forwards to connect some of those VIPs to internal servers such as our web server, Nextcloud server etc. I used to also run mail and DNS via NATs but I've scaled back lately and just have the one gateway and two web servers. Maybe if you described the Big Picture of what you really want to accomplish from a high-level view. A lot of times, we get people who have dreamed up a half-baked solution and then they want specific help with each step when the better course would have been to ask for guidance about the project as a whole. I'm an intermediate-level brain here so maybe one of the bigger brains can see what you're trying to do.

Oh - Derelict, Thanks for pointing me in the right direction and warning me about the reaction I might get if I ask about CARP. reberhar

@derelict correct.

Hi, Any idea please ?

Outbound NAT must also be set to use the CARP VIPs. It is perfectly normal for a traceroute response to appear to come from the interface address not the CARP VIP. You'll probably need to perform troubleshooting steps to determine what is actually failing and we can go from there. https://www.netgate.com/docs/pfsense/routing/connectivity-troubleshooting.html

Yes. Just like you would with an rfc1918 network. If they routed 1.1.1.0/25 to you: Interface: 1.1.1.1 /25 Usable: 1.1.1.2 - 1.1.1.126 They'd set 1.1.1.1 as the gateway. Or you could configure DHCP to hand out the addresses if you wanted. You could also just use a /26, /27, /28, /29, /30, /31 on the inside interface and use the rest of the space for other purposes.

@derelict You know what, your right, sometimes the simplistic idea is the best one. Thank you

As long as you are not using it with an HA cluster, you could add an IP alias or CARP VIP inside the proxy ARP range without (many) issues. I would use IP alias only, not CARP VIP. With a CARP VIP there is a potential that equipment on the segment would get different ARP responses for the address. IP alias would be the same as Proxy ARP. If it's for HA, then toss out proxy ARP entirely.