I've just seen your post, if still interested try this: 0) We are assuming that the first CARP VIP you have defined on both pfsense boxes is for the "master" (in normal condition) and the second VIP is for the "backup" (in normal condition). As a result, CARP interfaces are something like xxx_vip1 and xxx_vip2 1) Setup 2 dyndns names, respectively the master and the backup FQDNs (be careful, the order matters) on both the "master" and the "backup" pfsense boxes E.g.: pfbox1.dyndns.org (master pfsense) pfbox2.dyndns.org (backup pfsense) 2) Modify file rc.carpmaster adding the following at the end of it: /* Start DynDNS for CARP nodes */ $config['dyndnses']['dyndns'][strval((int)(SUBSTR($argv[1],-1)-1))]['enable'] = true; write_config(); shell_exec("/etc/rc.dyndns.update"); 3) Modify file rc.carpbackup adding the following at the end of it: /* Stop DynDNS for CARP nodes */ $config['dyndnses']['dyndns'][strval((int)SUBSTR($argv[1],-1)-1))]['enable'] = false; write_config(); shell_exec("/etc/rc.dyndns.update"); Explanation: The above mentioned scripts trim the VIP interface name extracting its interface number (e.g. "xxx_vip1"->1), that becomes an index to access every pfsense's DynDNS table, enabling/disabling the service update for the given box, so there should be a 1:1 relationship between overall VIPs and DynDNSes sequence, being them defined in the same way on all the CARP boxes. Due to current code, this trick can support up to 9 pfsense systems, with related VIPs and DynDNSes (tested on nanobsd 2.1.5-release i386).

Possibly obvious: The IP's are on different subnets and are unreachable from each other. Perhaps you have two subnets on the same wire, which is terrible, but I'm not here to judge. If so, did you create outbound NAT and firewall rules for the alias subnet? e.g. rules, lan: lan net>any 10.80.0.0/16>any nat, outbound: wan 10.50.0.0/16 * * * * * wan 10.80.0.0/16 * * * * *

All new stuff to me, could be how the ISP is doing it, they send us the /24 over a vlan (in the same building them), we used to have the /24 split between 2 offices and 3 routers, now thought the C Class is split between 2 separate router, no CARP or anything. With that though, and we were able to get them to do as you 2 have suggested, how do i do NAT rules for specific IP's then if the IP's are not entered into PFSense? i just put in the IP directly in the rule instead of first adding it into the Virtual IP area? Would that also not cause extra traffic to the routes so when someone goes to say www.mycompany.com it will broadcast to both Routers to see which responds? To add to that, incase i can not get them to set it up this way or could cause problems (they have had problems doing simple things before) is there a way to "re-order" the virtual IPs into order by IP address? (yes.. ocd)

Looks like my hoster (who is hosting us a vmware vCloud) is blocking the traffic from the virtual mac address. The traffic on the internal interfaces gets through because it is handled differently on the hypervisors site. Any advise on alternative settings which will achieve the same thing? I'm not after hardware redundancy by itself, I was looking for a way that would let me upgrade my pfsense without a downtime. Thanks for your help so far.

cmb, Thank you for the nudge!  :D In my frustration I forgot to troubleshoot the obvious, so far I bypassed the switch the boxes were connected to and hooked up straight to the edge router, so far for yesterday's evening and today's testing, it's going very well.  Speeds are being maintained and data transfers (FTP, HTTP, etc) are coming in at max rate.  Seems that intermediate switch was not playing nice when assigning the VIPs to the CARP interface.

Thank you for your reply. I am still not sure of the statement about having the distinctive interface - is there a way to bind a user to login only through specific interfaces, that I am unaware of?  As far as I see, a configured user can login through any allowed interface. HTTPS is good for encrypting the traffic, but exposing the system to yet another full admin user is what I need to secure. If a configured user can login through any interface, it would be nice to know what minimum privileges are needed for the CARP user. Thanks ahead of time for your replies.

Hi guys - you have exactly the problem I have! And you've found the same fix. Forcing failover / failback works as a work around. I'm using the latest 2.1.5 with the same results. Here's a "sort of" solution too. Don't use the main carp vip - use another ip (an alias ?) for your services? They don't have the same issue even when the issue occurs on the main IP. I think these articles are related: https://forum.pfsense.org/index.php?topic=81050.msg451115 https://forum.pfsense.org/index.php?topic=81709.msg451363

I would check that your firewall rules should allow the ping of course, but then try failing over (disable carp on primary to force a transfer) - pings might start working then - if so, you might be seeing the same problem secgeek and I are noticing.

This seems related to the other issues secgeek and I have seen. In my case, the working behaviour (when triggered by the problem we're noticing) can be restored by triggering carp failover (disabling on primary) - the setup will continue to work after failback. When I do static set ups, I don't use a single DNS - even if using carp - I use the DNS of each router. The GW does have to be the floating IP though. It might be helpful to those trying to help if you posted more info about the config? Or did you resolve already? Thanks!

I am presently using two separate physical machines. I believe they sync interface is connected by a cross over cable. The issue doesn't affect the alias ip's - only the main carp virtual IP. So that's my work around at the moment is to not put any services on the main floating IP. I've seen enough posts to suspect this is a real problem though - not one of our misconfiguration - what do you think?

Hi jimp, check your outbound NAT. You should be doing manual outbound NAT to a CARP VIP, or else you'll also get cut off like you see there. Thanks for your help, this one did it! I was NATing using the firewall IP instead of the virtual IP. Once I did a manual outbound NAT as suggested, the problem is fixed and the downloads continue through the failover with only a few packets dropped in between. Enjoy your weekend and thanks again! Kind Regards, Jason.

I am abandoning this question and forum, since I've gotten no feedback on how to resolve this. I decided to decommission the PFsense firewall and use an alternative product.

I feel a little dumb… I missed to get the correct Base advertising frequency on both nodes of one carp VIP config... Greets!

@Derelict: I'd probably start here.: https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense%3F Thats perfect.  thanks.

I've seen this behavior under several circumstances: when there is a carp misconfiguration; be very careful about the VHID, it must be unique for each virtual IP when there is something filtering CARP traffic between the nodes when there is leakage between the virtual IPs (eg: lan and dmz can see each other on layer 2).

@JeGr: @Rob Hate to disappoint you, while the main problem is indeed fixed (no aliases were created with 2.1.4 anymore), there still is a bug with deleting said aliases. They won't get deleted on the backup node, thus bringing chaos to the CARP stack on that interface leading to a split-brain (master/master) situation on that interface (can be resolved by rebooting the standby node or manually deleting the aliases on the VIP interface in a root shell on console). So my advice: be careful. Interesting! Do you know how long this bug has stood for, we've always had interesting behaviour with CARP + VIPs and failovers; we've always ended up rebooting the secondary for "random" problems like these.