Why would you want to run multiple layer 3 on the same layer 2? Its a Borked Config right out of the gate - are you in the middle of migration from that Huge /16 that makes zero sense to the more reasonable /24?

I found a work around rewriting the client dhclient.conf file, but this is not satisfying. I guess we will have to externalize our DHCP service from PFsense, probably some dedicated isc dhcpd server with the capacity of understanding that a FQDN shouldn't get forwarded a duplicated domain name... :-(

@vigorfac said in High Avail. Sync broken: Nov 7 12:40:18 php-fpm 51646 /status_logs_settings.php: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1510054818] unbound[90624:0] error: bind: address already in use [1510054818] unbound[90624:0] fatal error: could not open ports' The above error sounds similar to this bug in pfSense, which was since resolved: https://redmine.pfsense.org/issues/7326#note-2 (the code didn't wait long enough for unbound to stop before trying to start it again...in our case the master server was unaffected but the backup router would end up with unbound not running) re: HA sync, we have "DNS Forwarder and DNS Resolver configurations" checked in our setup and have no sync issues. So I don't think that by itself is an issue.

Forget it, Jake. It's OVH.

Hey The reason for the NAT is because its part of a DNS failover. I got it working like this: WAN1 IP: 1.2.3.4 NAT'ed to 172.10.0.1 WAN2 IP: 4.3.2.1 NAT'ed to 172.10.0.1 That way i got a WAN failover to the same server.

Hi, yes I had the interfaces restricted - I did not want the ntpd to LISTEN on the WAN interface. Reseting state did not help- same issue. But attaching ntpd to the WAN interface did the trick. Now having hybrid NAT and proper ntpd source IP. Thanks& Greetings

Thank you, I wanted to get confirmation. I will troubleshoot the XMLRPC sync !

I highly doubt the built-in load balancer (relayd) is going to adequately handle a handoff with Exchange. You should install the haproxy package and use that instead.

I finally found the solution YaY On Cisco ME3400E the default port-type is UNI and it has to be set to NNI. From official Cisco config guide: Traffic is not switched between these ports, and all arriving traffic at UNIs or ENIs must leave on NNIs to prevent a user from gaining access to another user's private network.

@f-meunier Seems better ! I'll let you know [EDIT] That works. Thanks for the help. Have a nice day

Hi Jimp. Thank you, that worked perfectly. Indeed i reverted from 2.4.4 to 2.4.3 and recovered the last configuration, which causes this version mismatch.

Is the primary node actually seeing the interface go down? That is what is necessary to trigger a failover. It will fail over just fine with an actual interface failure. Even only one of many. CARP does not protect against a failure at Layer 2. That is up to you to provide Layer 2 redundancy in addition to Layer 3. It has zero to do with NAT.

@derelict said in DHCP from Backup Node?: If you view Status > DHCP Leases you should see normal/normal on both nodes. If not, something is wrong. Yes, I got it working so far, and yes I gave both gateway and DNs the CARP Virtual IP. After figuring out I have to add the slave IP there it started working. Unfortunately only on two of the interfaces, but not on the third. There it says "My state: recover" and "Peer State: unknown state" This is obvious not "normal", but how do I troubleshoot? I alread stopped both services and removed the dhcp-leases files on both servers, but no change. I can ping both addresses vice-versa. How can I troubleshoot? After re-configuring the dhcp service again and again it went finally to "normal/normal". So it is working now and I am fine.

I personally really like the IP Alias VIPs stacked on the CARP VIP. You only have one "stream" of CARP heartbeats and you can move dozens of VIPs at a time from primary to secondary and back. The only time I generally make multiple CARP VIPs is for cleanliness in cases where you have VIPs in multiple subnets. I generally make one VIP per subnet and stack the IP Aliases that are also in that subnet on that VIP. This is a personal preference. If you make all of them CARP, then you need a VHID for each of them and any missed advertisement will result in that VIP swinging to the other node while the rest remain. This is never what you want. The stacked IP Alias technique reduces the advertisement traffic to that of just the one VIP.

What you possibly can do: Make 2 VPN tunnel. On from the first pfsense and one from the second pfsense. Then you can still make CARP but you configure to NOT sync the IPSec conig. When the failover takes place, the vpn tunnel will already be up. depending on your setup you may run ospf or another routing protocoll with the two vpn tunnel to make changes that are nessessary due to topology change. Best Regars, blex

Hi, thanks for reply. No, it's a dedicated interface and there is no captive portal in it. It's on a different Interface and also VLAN.