[SOLVED] CARP Probleme nach Neuinstallation

Started by Wayne Train, September 10, 2018, 09:58:54 AM

Previous topic - Next topic
September 10, 2018, 09:58:54 AM Last Edit: September 28, 2018, 08:55:26 AM by Wayne Train
Hallo,

mir ist mein Master-Node mitten im Upgrade abgestürzt und war danach im Eimer. Anschliessend habe ich OPNsense komplett neu installiert. Nachdem ich die Config aus dem Backup eingespielt habe, habe ich Probleme mit CARP.
Nun ist meine Frage: Kann es sein, dass CARP abgesehen vom Usernamen in den HA-Einstellungen und den jeweiligen Virutal-IPs und deren Passwörtern intern noch andere Parameter verwendet, wie zum Beispiel den SSH-Fingerprint o.ä? 
Dieser hat sich nach der Neuinstallation ja geändert...
MFG Wayne

Schau mal in Interfaces : Overview ob die Assignments korrekt sind, also z.B. DMZ2 = opt4.
Wenn das durcheinander ist geht nix mehr.

Hi,
die Assignements sind korrekt. Auch stimmen alle VHIDS überein. Sonst noch eine Idee ?
Wie hast du CARP auf dem WAN firewallmäßig definiert ? MAster <-> Slave CARP ANY und ICMP ANY ?
MFG

Kann ich irgendwie auf der Commanline checken ob Multicast richtig funktioniert ?

Mit tcpdump sehe ich nur auf dem Slave-Node Multicast. Der kommt von  meinem Master-Node nach 224.0.0.18. Ist das korrekt so ? Ich dachte bei CARP senden beide Nodes und der mit der höheren Prio macht das Rennen...
MFG

Quote from: Wayne Train on September 10, 2018, 01:52:45 PM
Hi,
die Assignements sind korrekt. Auch stimmen alle VHIDS überein. Sonst noch eine Idee ?
Wie hast du CARP auf dem WAN firewallmäßig definiert ? MAster <-> Slave CARP ANY und ICMP ANY ?
MFG

Das sollte eigentlich per default aktiv sein:

pass in log quick proto carp from {any} to {any}

Quote from: Wayne Train on September 10, 2018, 04:26:34 PM
Mit tcpdump sehe ich nur auf dem Slave-Node Multicast. Der kommt von  meinem Master-Node nach 224.0.0.18. Ist das korrekt so ? Ich dachte bei CARP senden beide Nodes und der mit der höheren Prio macht das Rennen...
MFG

Ne, der Slave hält die Klappe solange er Pakete von jemanden mit besserer Prio bekommt :)

Thx,
dann ist das ja schonmal ok, dachte die senden beide. Aber meine Rules sehen dann doch was anders aus.

pfctl -s rules | grep carp
pass in log quick proto carp all keep state
pass in quick on igb3 reply-to (igb3 11.22.33.44) inet proto carp from <CARP_WAN> to <CARP_WAN> keep state label "USER_RULE: Allow CARP"


Mein Alias CARP_WAN enthält 11.22.33.45 (MASTER) und 11.22.33.46 (SLAVE) und die 11.22.33.44 ist der GW.

Liegt da vielleicht die Ursache ?

Die Regel erlaubt eh alles was CARP betrifft, du brauchst die Userregel eigentlich nicht.

Wie ist denn jetzt der Zustand von beiden Systemen und was passiert wenn du den wiederhergestellten Master rebootest?

Hi,
mit einem weiteren Upgrade (warum auch immer) hat sich das Problem erledigt. CARP funktioniert wieder wie es soll.
Danke