Silly question.  Glad no one answered.  Removed that NAT and it's working great! Thanks again for your help! Dino

IP Alias

This can be added to the growing list of "Realtek sucks" threads. I have had zero problems with a pair of APUs, however.

Answering my own question, the "moved permanently" error was caused by protocol mismatches.  I had HTTP enabled on my primary and HTTPS on the backup. From: https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_%28CARP%29 Before proceeding, set the same admin user password and webConfigurator protocol (e.g. HTTPS) on each cluster node. This protocol is set at:  System/Advanced/Admin Access/Protocol

Not sure if it will help much, but I feel like I had a similar issue that with one of our VIPs and CARP. I was able to resolve the issue by rebooting the backup firewall followed by rebooting the master after the backup is back online. Something with failing over all of the VIPs to both firewalls during the reboots fixed the issue.

I am in a similar situation.  I have a number of firewalls that I have upgraded and need the limiters working.  I really don't want to revert back to 2.1.5

Ok so I got to the datacenter and restarted the webconfigurator on the slave which seemed to sort things out for a short period of time. However this morning, the web UI on the slave has failed again and I am getting sync errors again. I will go and do a full restart of the slave today but failing that, what else can I look at or do without having to do a full rebuild?

Why would you do that and why do you consider it a problem?

It and will not allow you to detect when one member of the LAGG goes down Well you could look for traps from the switch/stack doing the LACP for LACP issues but it really seems like overkill but it depends on the application. Everything always comes down to the endpoints. Unless you are going to LACP to two NICs in every endpoint to two different switches (You can LACP a group across stack members or sometimes with multi-chassis trunking), when the switch that the endpoints are connected to has a problem, those endpoints lose connectivity. On all of your LANs: X.X.X.1 CARP X.X.X.2 Master interface X.X.X.3 Backup interface All clients pointed to .1 for routing, DNS, etc.

Yup… [image: j6E1C1b.png]

Manually input DNS as you did, and upgrade to 2.2.6. There were CARP issues with captive portal in 2.2.2 fixed in newer versions.

I know this is an old topic but it has just taken me 4 hours but I had this same problem and have resolved it so if it helps someone else i thought it would be worth it! You have to enable Mac spoofing on the advanced settings of the NICs in Hyper-V & also set a static MAC address on the adapters. simple as that but frustrating if you didn't know & I spent hours searching!

@KenBeanNet: I added the virtual IPs under WAN I'm curious what VIP type you chose for this- are you using "Other" or Proxy ARP?

@Atlantisman: Nevermind, i think i figured it out. I just setup an outbound NAT rule that applies to the firewall (self) and NATs it to each of the CARP VIPs (1 rule for each WAN interface) Mind sharing the details of your OB NAT rule? I've tried this in the past with something like WAN, This firewall, ,,,CARP VIP,,NO And my gateway still shows as down… EDIT- Nevermind... It does work, you just have to start and stop apinger after adding the NAT rule.

Actually Wireshark undersands CARP just fine, the problem stems from the fact that both VRRP and CARP use IP Protocol number 112. That means you have to TELL Wireshark, tcpdump, etc, that you want to decode IP Protocol as CARP, not VRRP. In wireshark, select the packet, right click and select Decode As…  Then choose CARP in the list. If you are using tcpdump from command line pfSense, add -T carp flag.

Not CARP, pfsync. Disable pfsync under System>HA Sync on both systems and you'll be fine. CARP can still work fine, just won't have states synced.

See this thread: https://forum.pfsense.org/index.php?topic=102740.0

Great! (& tnx!) I would have done it otherwise, but credits go to you…