@rubinho: das hat doch mit den Kisten nichts zu tun. Für VRRP oder HSRP - was das gleiche ist wie CARP - müssen die Kisten sich auch gegenseitig sehen.
Ein Standard Failover Setup sieht man am Einfachsten unter
https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_(CARP)
Da sollte auch klar werden was gemeint ist: auf dem WAN wie auf dem LAN wird das jeweils GLEICHE Netz konfiguriert und jede Kiste bekommt eine eigene Adresse dazu gibts dann in jedem Segment noch eine VIP, die von Gerät A auf B wechselt.
Failover-Fall wird festgestellt wenn sich auf dem konfigurierten Interface (WAN oder LAN) die Geräte nicht mehr sehen (Ping sowie Multicast). Das Sync Interface ist nur für pfSync da um States und Konfiguration abzugleichen. Bricht Sync weg, hat man einen Async Zustand was die States angeht, aber noch KEINEN Failover Fall. Erst wenn die Master Firewall ein Fail auf einem der Interfaces bemerkt und die Failover Kiste sie daher nicht mehr erreichen kann, dann schwenkt alles auf den anderen Knoten, wenn bei dem noch alles funktioniert.
Was in deinem Fall nicht funktioniert morphmax ist genau das Setup von CARP auf dem WAN, weil deine beiden Firewalls, wenn du sie einfach nur an die WAN Uplinks dranhängst, in völlig anderen Netzen sind (nicht im gleichen Subnetz) und du darauf dann keine CARP Adresse konfigurieren kannst, da sich die Kisten per Multicast auch nicht sehen und austauschen können. Klar können die sich Pingen (externe IP1 zu 2) aber Multicast kannst du nicht über Netzgrenzen hinweg problemlos sprechen, das wird fast immer vom Provider gefiltert. Und sobald du kein CARP Interface auf dem WAN hast, kannst du kein Failover auf den Slave machen wenn WAN wegbricht. Du hättest dann nur den manuellen Weg das in der UI manuell zu machen.
Wie lösen Firmen das Problem? Diese habe doch im Normalfall Leitungen bei mehreren Anbietern und von unterschiedlichen Standorten aus. Sitzt da dann den ganzen Tag einer im Keller und wartet darauf, dass die Internetverbindung tot ist und steckt dann den Stecker um?
Das siehst du falsch an mehreren Punkten.
a) Die meisten Firmen haben da einen HSRP/VRRP/CARP Cluster stehen an der Anbindung und haben 2 Leitungen vom gleichen Provider, der auf seiner Seite auch irgendeine Redundanz spricht. Also ein "H" vom Aufbau (2 Geräte Provider bringen 2 Leitungen die in 2 Geräte von dir gehen, alle Geräte untereinander als Cluster konfiguriert und mit zwei Switchen vornedran - der Querstrich - verbunden).
b) Eine Firma betreibt ggf. mehrere Standorte, aber nutzt diese Leitungen (meistens) nicht für nen Failover von intern. Vor allem ist bei Firmen NIEMALS der State entbehrlich oder Verbindungen entbehrlich und egal. Wenn mein Kunde bspw. ein Video streamt ist der nicht begeistert wenn ihm ständig der Stream abreißt. Mehrere Standorte sind meist aus Gründen wie Geo-Location, Nähe zum Kunden wegen Latenz und Laufzeit etc. aufgesetzt und nicht als Failover für ein internes LAN.
c) Firmen haben dann ggf. andere Verträge und routen IPs via BGP + OSPF je nach Größe. Alleine damit ergibt sich nochmals ein völlig anderes Setup und Möglichkeiten, denn dann hast du ggf. an den Standorten die gleichen IPs, die du dann rüber routen kannst.
Zumindest habe ich im Datacenter Einsatz bislang noch kein Setup gesehen, bei dem ein Kunde FWL1 in Location 1 und FWL2 in Location 2 versucht als "Cluster" miteinander zu verbinden, schon allein weil die Laufzeiten zwischen den Standorten ggf. recht groß sind. Von dem Problem des Routings mal ganz zu schweigen :)
Ich supporte ein ähnliches Setup, dort stehen aber JE ein Cluster in DC1 und DC2 und die sind wiederum mit einem Link zwischen den beiden DCs "verbunden", allerdings ist bei denen BGP eingerichtet: Wenn der Kunde seinen Uplink schwenken will auf DC2, dann schalten die BGP auf Cluster 1 ab und auf 2 an. Und prompt läuft alles in DC2 auf. Für sowas gibts Monitoring und semi-autonome Prozesse die das triggern, aber ein DC Failover machen die meisten nur händisch, da ggf. noch andere Dinge vorbereitet werden müssen oder Hand in Hand gehen.
Und 2 Leitungen für ein LAN zu haben - das machen die meisten Firmen eben nicht an unterschiedlichen Standorten, sondern holen sich beides an einen Cluster/eine Firewall ran und nutzen GW Gruppen und MultiWAN.
Grüße
