You need three addresses.

Thanks, not sure what that CARP event would mean in practice. If WAN is down I don't really care if pfsense would switch between the units as long as it is restored when WAN is up again. But I'm getting the feeling that I'm introducing more ways things can fail rather than mitigating actual risks, I'll see if I can get into the network some other way and restore functionality manually when something have happened.

The configuration versions of pfSense must be identical on both units. It can't synchronize from 2.3.4 to 2.3.2 because they have different configuration formats https://doc.pfsense.org/index.php/Versions_of_pfSense_and_FreeBSD 2.3.4 is revision 15.8, 2.3.2 is 15.5. Attempting to synchronize that could cause a bad configuration to be loaded on the backup unit. Upgrade both to 2.3.5-p1 (or preferably 2.4.2-p1) and try again.

Hello, again! I managed to resolve this problem myself, when I found that Snort package, which I had installed and configured on WAN, was dropping the state on the slave (the box that is becoming the master on failover), because of the ongoing download for which the initialization was only seen by the snort on the previous master. Hence Snort thought it was an intrusive packet and denied the connection. That also explains, why it was all good again on the master box after failing back. Hope this helps someone, and sorry for the wasted time!

Yes. Being in a virtual environment might cause an unplugged cable to NOT result in an actual interface DOWN to the virtual machines because they are still connected to the vswitch. If your virtual environment supports simulating an unplugged interface there you should try that. In short, it is up to your hypervisor to actually take an interface down from the VM's perspective. I use XenServer and that is pretty hard to simulate there - at least in the 2 minutes I devoted to trying to figure out how to do it. You might also try just taking the interface down in software ifconfig xn0 down Dec 15 20:21:39 kernel carp: 236@xn0: MASTER -> INIT (hardware interface down) Dec 15 20:21:39 kernel carp: demoted by 240 to 240 (interface down) Dec 15 20:21:39 kernel carp: 239@xn0: MASTER -> INIT (hardware interface down) Dec 15 20:21:39 kernel carp: demoted by 240 to 480 (interface down) Dec 15 20:21:39 kernel xn0: link state changed to DOWN Dec 15 20:21:39 kernel carp: 240@xn2: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn2: 3 Dec 15 20:21:39 kernel carp: 237@xn2: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn2: 3 Dec 15 20:21:39 kernel carp: 241@xn4: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn4: 3 Dec 15 20:21:39 kernel carp: 243@xn5: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn5: 3 Dec 15 20:21:39 kernel carp: 238@xn1: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn1: 3 Dec 15 20:21:39 kernel carp: 242@xn5: MASTER -> BACKUP (more frequent advertisement received) Dec 15 20:21:39 kernel ifa_maintain_loopback_route: deletion failed for interface xn5: 3 Dec 15 20:21:39 kernel carp: 228@xn1: MASTER -> BACKUP (more frequent advertisement received) Secondary takes over for all VIPS. All VIPs on primary are either INIT (the two on xn0) or BACKUP (everything else.) ifconfig xn0 up Dec 15 20:23:44 kernel carp: 236@xn0: INIT -> BACKUP (initialization complete) Dec 15 20:23:44 kernel carp: demoted by -240 to 240 (interface up) Dec 15 20:23:44 kernel carp: 239@xn0: INIT -> BACKUP (initialization complete) Dec 15 20:23:44 kernel carp: demoted by -240 to 0 (interface up) Dec 15 20:23:44 kernel xn0: link state changed to UP Dec 15 20:23:44 kernel carp: 236@xn0: BACKUP -> INIT (hardware interface up) Dec 15 20:23:44 kernel carp: 236@xn0: INIT -> BACKUP (initialization complete) Dec 15 20:23:44 kernel carp: 239@xn0: BACKUP -> INIT (hardware interface up) Dec 15 20:23:44 kernel carp: 239@xn0: INIT -> BACKUP (initialization complete) Dec 15 20:23:44 check_reload_status Linkup starting xn0 Dec 15 20:23:44 kernel carp: 239@xn0: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 236@xn0: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 241@xn4: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 240@xn2: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 237@xn2: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 243@xn5: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 242@xn5: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 238@xn1: BACKUP -> MASTER (preempting a slower master) Dec 15 20:23:44 kernel carp: 228@xn1: BACKUP -> MASTER (preempting a slower master)

I have the very same issue, but there's no apply button to fix. Need to change the VIP from IP Alias to CARP and then back to get it to work.

They need to be enabled and set to use the CARP VIP.

Hi, So the simplest question is: in a carp setup how what can I do to be sure that also slave can reach internet? In your MASTER, Firewall/NAT/Outbound, make your Mappings similar to the attached pic, 2nd entry. In your case all references to WAN1 should just be WAN. If as you say your CARP is properly configured, the MASTER settings should replicate to the SLAVE via the SYNC interfaces. You do have SYNC interfaces, properly configured & connected, right? What does this 2nd entry do? It ensures that internet access for the pfSense machines (MASTER/SLAVE) themselves (127.0.0.0/8), goes thru their respective WAN IP addresses. As for your "several" LANs, LAN2 in particular, create rule(s) similar to the 4th entry. This ensures the allowed LAN machines can access the internet via the designated WAN CARP VIP. Anyway if you followed the CARP setup docs, all those entries should have been more or less taken cared of already. Cheers. Edwin [image: pfs-nat-outbound.jpg_thumb] [image: pfs-nat-outbound.jpg]

Like I said, you will probably need to pcap to see what is really going on. Are you using your own switch or the ISP device?

Same here. I'm using WAN CARP as "GRE Remote Address" on two pfSense boxes but it doesn't work. If I change to WAN addresses, all is OK.

Hi, in my case (v 2.4.2-RELEASE (amd64) ), I solved it with the following settings: Outbound NAT Mode = Hybrid Outbound NAT rule generation Putting below as the 1st rule in Firewall/NAT/Outbound (in primary, will replicate to backup), see pic below Iface=WAN - src=This Firewall - dst=* - NAT=WAN Address P.S. been using pfSense since 2006 but this is my 1st post. edit: oops my 2nd post actually, the 1st was way back 2015  :D so I beg you tolerance if I woke up a sleeping thread or broke some forum rules just wanted to help Ed

Found my answer.  Of course it took an entire post to go back and ask myself "did you check the fundamentals".. I'm running on ESXi 6.5 .. While I had enabled the LAN vSwitch for promiscuous/forged/mac, I had not done the same for the WAN vSwitch. Once I made that change, this worked.  Let that be a lesson.  It's not always the firewall, but it's almost always the user.  :)

Yes. Me. I have tried to duplicate several of these reports and the only case I can find where there might be a problem is described here: https://redmine.pfsense.org/issues/8100

Yeah, kinda weird. It's the only box where we have a vip on the WAN interface, so it slipped through the cracks when we tested it on another box.