I've set up replicating SANs before and I've always just used a crossover cable for the synchronization interface.  I don't trust another piece of electronic equipment in the mix for no reason, and I've never had a problem with direct-connected interfaces.

@doubledgedboard: So, I'm fine setting up the network aspects, but from my initial research it looks like single-wan-ip CARP doesn't work as well with DHCP WAN IPs. From what I've read, it can be done, but I have to manually assign the gateway on the slave when a failover occurs? Is this true, or is there a better way to handle DHCP WAN? As Jims said - https://forum.pfsense.org/index.php?topic=63319.msg342542#msg342542 so I don't think it would work out of box with DHCP WAN IP, but with single-wan-ip it should work.

Thanks -  if I curl the WAN IP it's returning the internal address, I don't have any rules setup to allow the webconfigurator on the WAN port. Port forwarding + NAT Proxy appears to have worked, I didn't realise there is a difference with 1:1 NAT Thanks for your help!

Then my setup will not work.hmm ugly

@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