@stephenw10
The AWS side will likely propagate whatever you advertise to it, because I manage both ends and that's just how the virtual private gateway works in AWS.
I guess there might be a slight risk here, but hopefully AWS won't make a change that reject these routes.

Of course, ideally I hope that pfSense will allow the source to be configured in a future release of the OS. As far as I know, other firewall vendors are able to do so.

/Thomas

The best way to do an HA deployment is it invest in the gear necessary to build it correctly. Bridging like that is generally incompatible with pfSense HA.

https://docs.netgate.com/pfsense/en/latest/highavailability/layer-2-redundancy.html

As it turned out there was a loop on an interface which caused that behavior, sad but true.

It can depend on the switch/router on the other end of the cable. For instance with Comcast routers often when replacing a router in an office (inside the Comcast router) I've found it's fastest to power off or reboot the Comcast router so it learns the IP has a new MAC. If you have the second router on, and are just plugging in cables, I would wonder if restarting the second router (or just leaving it off and powering it on) would help.

But overall CARP set up properly works basically instantly so that would be preferred. https://docs.netgate.com/pfsense/en/latest/book/highavailability/index.html

CARP/VRRP/etc. are using not only virtual IPs but also virtual MACs to make failover a smooth experience without clients or network equipment having to learn a new MAC address of a failover server like with only IP based configurations (early linux HA cluster for example).

The VHID setting is influencing which MAC is handed out for that CARP style VIP. All of them are (IMHO) using the failover MAC space of

00:00:5E:00:01:XX

so with changing the VHID you are also configuring the last "XX" segment of said MAC address. That's why it has to be unique on that network segment (L2) and you also have to watch out for other cluster/HA-grade setups, that are using VRRP or HSRP style VIP/MAC combinations. But if your pfSense cluster is the only cluster in that network segment, VHID 1 is commonly fine on all interfaces. We're using VHID 4 and 6 (for IP4 / IP6 VIPs on the same VLAN) over multiple VLANs just fine :)

@mannyjacobs73 said in Multi IGMP Proxy Behaviour:

lthough I understand there is a difference between IGMP Snooping and IGMP Proxy, I do not completely understand how the IGMP Proxy service should be behaving when configured correctly... and especially with multiple devices / additional Virtual IP assigned.

Hi,

I'll re-write my query and hopefully someone can put me in the right direction...

Basically I am wanting to know if there is any documentation or notes available regarding the behavior of the IGMP Proxy protocol which is found in pfsense (query timings, priority etc.) .

Specifically when two devices are running IGMP Proxy on the same LAN, but even any pointers to more in-depth documentation as to how this service runs on a stand alone box, would be appreciated.

Thank you

After running for the last week I haven't had any issues with not having a failover DHCP server defined.

Each firewall takes over their duties as expected when their partner isn't available.

I would like to get some final confirmation though; if anyone has been through this (CARP + DHCP server failover) please tell me if my setup seems strange.

Yes, you can use a CARP address as the IPSec endpoint. There is an option to sync IPSec configuration in the XMLRPC Sync options on the HA Sync page.

Sorry. I have no idea what you are even asking.

The basic things that need to be changed to run pfSense HA in VMware ESXi are described here:

https://docs.netgate.com/pfsense/en/latest/highavailability/troubleshooting-high-availability-clusters.html?highlight=esxi#hypervisor-users-especially-vmware-esx-esxi

@teamits yeah. It should just work. It doesn't tho... And it's really messing up my holiday giving spirit.

I should've just did it all myself. No outside vendor. Sigh.

i've solved the problem. its very similar to bridge behavior i encountered in another installation. I only have vlans defined for my LAGG. once i created another interface that would be untagged on the LAGG, it picked up my native vlan as expected. all of the VIPs for the tagged interfaces started working.

so just for my own curiosity i deleted the native interface i crated and rebooted. everything still works. all in all i must have just jiggled the handle