@cmb: Likely from those IPs not working in general on the secondary, assuming they're CARP IPs or IP aliases with a CARP parent. While failed over if you go to Diag>Ping on the secondary, source from one of the affected IPs, and ping out to something on the Internet, does it work? Are these physical boxes, or VMs? Most common reason that comes to mind is VMware without appropriate vswitch config to allow the CARP virtual MACs to be used on the secondary system. These are physical boxes.  I haven't actually tried the Diag>Ping on the secondary when the failover occurs.  I'll do that next time it fails over.  But at least right now, I can ping from an external source both WANs of both pfsense boxes, in addition to the CARP VIP shared between them on each WAN.  If it were a problem from the IPs not working in general, would I not be able to ping the secondary's? For reference, the IPs are set up like so (and as of right now, I can ping all of them externally): BR network: pfsense01:  208.xxx.xxx.171  (NIC's actual address) pfsense02:  208.xxx.xxx.172  (NIC's actual address) BR VIP:        208.xxx.xxx.170  (CARP VIP shared between the two IPs above) CH network: pfsense01:  71.xxx.xxx.19  (NIC's actual address) pfsense02:  71.xxx.xxx.20  (NIC's actual address) BR VIP:        71.xxx.xxx.18  (CARP VIP shared between the two IPs above) @nikkon: @cmb: What type of VPNs? What traffic no longer works? Specific to certain NATed IPs, or? OpenVPN only. In our case, we don't use OpenVPN currently, our site-to-sites are IPSec.

Outbound NAT rule maps all LAN connections to the WAN CARP IP: 172.16.0.1

https://doc.pfsense.org/index.php/Upgrade_Guide#Upgrading_High_Availability_Deployments I've upgraded a CARP system from 2.1.4 as described there. No issue. However, in CARP mixed mode 2.1.x + 2.2 the states are not synced to slave, so connections are lost if the 2.1.x master take over CARP master again. E.g. if you restart the machine. If you don't want that pull out the WAN cable.

Dear All, I am still facing the issue that CARP is not working. The last interface coming up becomes master regardless of the skew setting. Could someone please be so kind as to write in a few words how the requirements for getting CARP to work in version 2.2 differs from what is written in the draft book on 2.1 in chapter 25, in particular the example redundant configuration on page 472ff ? From what I gather, CARP in 2.2 still generates an interface which reads like XXX.XXX.XXX.1 (LAN CARP VIP), i.e., the typical router IP on a typical LAN and XXX.XXX.XXX.2 (WAN CARP VIP), i.e. not the typical router IP on a typical WAN. Behind NAT, I suspect that one still has to create manual outbound rules translating to the WAN CARP VIP(s). Thank you very much, Michael

Thanks for the reply cmb! Yes, thats very likely the case. I finally RTFM and found that I need to setup these as CARP VIPs as well, which I did… then I brought the secondary pfSense box online and it decided to pick up some VPN connections that were already established on the master. The connections are listening on the CARP interfaces so Im not quite sure what happened this time. Looks like im going to be working on this over the weekend. I will check back and confirm as far as this particular issue goes.

You can accomplish that with the "Persistent CARP Maintenance Mode" on 2.2. Just click that button under Status>CARP and it'll bump the advskew on that system to 254, leaving it in backup status unless the secondary disappears.

Answered here https://forum.pfsense.org/index.php?topic=87813.msg483500#msg483500 This really should be in the upgrade notes.

@Guldil: https://doc.pfsense.org/index.php/UpgradeGuide#Upgrading_High_Availability_Deployments Nothing about 2.1.5 to 2.2 I'll try the procedure like i did before (slave first, carp off on master, then master). I've just finished upgrading my CARP set based on 2 DELL R220II as recommended there and at the end it works great. However, upgrading the backup box at first, messed my outbound NAT settings. Automatic mode was activated and therefore it used the WAN address instead of CARP VIP. In result, connections which were made from inside to web services secured by IP authorization were rejected. Upgrade of master worked as expected. I am happy now.  :)

It still works the same in regards to multicast. The fact it doesn't have an additional interface isn't really of any functional consequence from a user's perspective.

No difference on 2.2 Split DNS is the better fix.

Ok, I see uniqids got introduced in https://github.com/pfsense/pfsense/commit/89f171b052fbe72aed654d2a1c3d5a24e9bf9902 hmmm… Need to stop tinkering with this since its beyond my understanding. For sure I thought uniqid should show up in config.xml for CARP VIPs but maybe some sort of magic is going on behind the scenes someplace. -Shahid

That was the problem. However, it was actually a virtual IP address on the second pfSense box. CARP was not configured yet. Thank you.

@dark.fibre: The sync-NICs are connected with a bridge cable, they can ping each other, IP are 192.168.0.1 and 192.168.0.2. Second FW has a rule at Sync for TCP/UDP Port 443, Destination: WAN-ADRESS What is my mistake? If you have separated sync-NICs, why do you allow traffic to WAN address for syncing? Just add a rule on both boxes on sync interface to allow traffic from any to any and it will be done. The sync packets uses pfsync protocol, not TCP nor UDP!