Can't ping carp lan VIP

xuio

Hi,
I have two pfSense boxes with carp. I created a LAN carp VIP (192.168.1.3) but can't ping it.
Here is my setup:

grahambmtw

Can you provide some more info, ie a screenshot of the virtual ip and carp configuration pages since the diagram looks okay to me.

xuio

Hi,
here are my configuration screenshots
VIPs: (same on both machines)

CARP config:

Master:

Backup:

grahambmtw

Can you show the settings for each VIP on both firewalls?
Firewall>Virtual IPs>Edit (on the private one)

Noticed a misconfiguration issue on both the master and the backup system. Please untick "Synchronize Users and groups" and "Synchronize Certificates". Ticking those is like playing with fire and military grade explosives. Bad, very bad, extremely bad. Don't do it. Ever. Even when "they" bust your kneecaps and force you to do it.
The reason is that if you change the password on the master, the change gets replicated to the slave. So far everything works as expected. The problem is that password on that CARP tab. That does NOT get changed. I'll let you guess what happens next time the master tries to replicate a change to the slave. I'll even give you a hint:wrong password. Another hint if none still gets it: numerous calls from angry clients because "zomg the internet is DOWN!!!". Those clients should be educated with the help of a baseball bat that the internet was designed to NEVER be down. Their connection to the internet is down. Not the entire internet. ;D

Tick DHCPD on master. Tick all on the backup system (except users/groups and certificates).

Have you checked firewall rules to make sure that the CARP IP actually gets assigned to a single host? Maybe they cannot communicate with each other and both think they are masters, which confuses your switch (sees 2 macs for 1 ip). Although to be honest the entire network would crap itself by now since CARP will take over and failover all interfaces to the second box (can be changed in tunables,not recommended) and back and forth. Do a packet capture on the interface affected. You should see this:
17:29:53.514286 IP 192.168.xxx.xxx > 224.0.0.18: VRRPv2, Advertisement, vrid 5, prio 0, authtype none, intvl 1s, length 36
17:29:54.514975 IP 192.168.xxx.xxx > 224.0.0.18: VRRPv2, Advertisement, vrid 5, prio 0, authtype none, intvl 1s, length 36

That's the master telling the backup that "hey I haven't passed out yet"
Change tab to the slave. Do a packet capture there. To help you, put the master's ip in the capture's host address on both the master and the slave. If you see that same traffic reaching the slave, it's time to bust out the hammer and start with the switch first ;). If you don't see the traffic on the slave, post and we'll try to figure it out.

jimp

You should have pfsync setup on master and slave pointing to each other.

You want to check the boxes for all to sync master -> slave.

Do not enter any values or check ANYTHING in the XMLRPC section of the slave's settings.

And yes, you want to synchronize users and certs. Just remember to fix your passwords if you ever change them. If you don't sync your users and certs, having a remote access VPN on your cluster is a giant pain since you'd have to manually export+import the certs and then re-add users manually.

It's much easier to just remember to change your password appropriately. ;D

There wouldn't have been any downtime for someone in a normal scenario unless the change that didn't replicate directly affected connectivity.

I stand corrected on the backup sync settings then. If syncing certificates, wouldn't this also affect the webgui cert? (hostname on backup system is different than the master)

jimp

@jflsakfja:

I stand corrected on the backup sync settings then. If syncing certificates, wouldn't this also affect the webgui cert? (hostname on backup system is different than the master)

Yes but that is easily solved by either using the same GUI cert for both, or by importing the cert from the secondary to the master before setting up the sync. Then re-select the correct GUI cert after the sync.