@Sperber said in Dual OpenVPN-Setting, CARP & Failover (HA, MultiWAN):

(Vorkbaard hat das bereits beschrieben: https://vorkbaard.nl/openvpn-in-a-pfsense-carp-cluster/ )

Die Info ist aber relativ alt und nicht zutreffen. Wir haben da sehr verschiedene und komplexe Services laufen und keiner braucht irgendwelche seltsamen Settings mit "local <extIP>" o.ä. - das sollte heute überhaupt nicht mehr nötig sein. Macht im CARP Setup auch keinen Sinn, da die CARP VIPs alle auf dem Master laufen und man diese so nicht ansprechen kann. Split CARP mit Master/Backup auf dem selben Node ist in der FreeBSD Variante von CARP/pf nicht enthalten, das ist leider nur in OpenBSD enthalten.

Mich interessiert allerdings auch wie @viragomann wie man überhaupt auf der 2. pfSense im CARP die Annahme von OpenVPN erlauben will. Der Traffic kommt ja nicht bei ihr an, weil der via CARP IMMER zur primären läuft, nicht auf den sekundären Node. Und wenn man das forwarden sollte auf Node 2, würde der Node versuchen asymmetrisch zu antworten (oder es läuft alles wieder über Node1), was auch wieder nicht sehr schön ist.

Wie ist das also realisiert, dass die Clients sich auf Node2 connecten und das auch funktioniert, wenn Node2 mal aktiv wird und Node1 passiv weil vlt. gerade gewartet wird o.ä.?

Ansonsten wäre mir schleierhaft wie das im Redundanzfall wirklich sauber funktionieren sollte ohne dass manuell eingegriffen wird?

Cheers
\jens

Wanted to add a bit more info here as this issue remains even after upgrading to 2.6.0 today.

My tunnels are IKEv2 in VTI mode.

Under Phase 1 Advanced Options, I set "Child SA Start Action" to "Initiate at start (VTI or Tunnel Mode)"
and
"Child SA Close Action" to "Restart/Reconnect"

Under Phase 2 > Keep Alive, I use a host on the other side of the tunnel with Keep Alive "Enable periodic keep alive check".

The tunnels do not establish if I shut down the MASTER CARP node or "Enter Persistent CARP Maintenance Mode" on the MASTER CARP node. I have to click Connect to manually establish the tunnels.

Seeing these messages in the IPsec System Log
charon[43289]: 04[CFG] trap not found, unable to acquire reqid 5002

Have anyone else seen this issue?

@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