17.7.6 CARP-Pakete werden gefiltert

[Andreas_]

Nach einem Update eines Firewall-Paars von 17.1.2 über 17.1.11 auf 17.7.6 funktioniert CARP auf dem WAN-Interface nicht mehr, da der Master zwar seine CARP-Announcements wie erwartet erzeugt, diese die Firewall aber nicht verlassen und der Backup daher meint übernehmen zu müssen.
Im Filterlog ist von CARP nichts zu sehen, die Pakete gehen aber sofort raus wenn die Firewall per pfctl -d abgeschaltet ist. ACCEPT-Rules helfen nicht.

Irgendein Hinweis wo das hängenbleiben kann?

[mimugmail]

Bogon Interface Filter aktiv?

[Andreas_]

Hab Bogon Filter testweise abgeschaltet. Hatte den unschönen Effekt daß nach Config neuladen auf dem Master alle VIFs wegwaren, ich mußte CARP disablen und enablen um ihn wieder zum Laufen zu bringen. Backup steht dauerhaft auf disabled, da CARP ja nicht funktionstüchtig ist....

Bogon Filter abschalten macht keinen Unterschied, weiterhin CARP Announcements nur bei pfctl -d auf dem Master.

[mimugmail]

Screenshot von den wan rules bitte

[Andreas_]

Floating Rules sind leer, anhängend die WAN-Rules mit meinen Versuchen CARP-Verkehr zu sehen.

[Andreas_]

Ich muß diesen Thread noch mal bumpen.
Auch nach Upgrade auf 18.1.2 immer noch das gleiche Problem: Am Backup kommen die CARP-Announcements am WAN-Interface nur an, wenn ich am Master die Firewall disable.

[mimugmail]

Wenn du magst kann ich mal per Teamviewer drauf schauen, vielleicht fällt ja was auf.
Falls ja -> PN

[Andreas_]

Ich habe inzwischen weitere Versuche gemacht, zT unfreiwillig:
- Hardwaretausch, Neuinstallation 18.7.9, restore der 18.1-Config mit angepaßten Interfacenamen. Das problematische WAN-Interface (kein lagg, kein vlan) hat jetzt einen ix-Treiber statt igb: weiterhin keine CARP-Pakete, daran lag es also nicht.
- Installation in einer Xen-DomU, wieder angepaßte Interfaces. Hier funktioniert der CARP Broadcast wie erwartet...

Ich hab mir die Config rauf und runter angesehen. thermal_hardware coretemp und Dashboard Widget hab ich entfernt (sonst Kernel crash), sonst sehe ich nichts auffälliges (sysctl weitgehend default, bis auf carp demotion). Die Hardware ist trotz Virtualisierung nahe am Original (C2558/2 Kerne statt C2758/C3758 8 Kerne), incl aesni hardware_crypto.

Ich bin reichlich ratlos. Eigentlich sieht es ja so aus als ob es am Switch liegt der die beiden Router verbindet, Filterung der Broadcasts. Ich kann nur per tcpdump auf dem Slave-Router testen weil das Routerpaar in einem RZ steht. Dann dürfte das Problem aber nicht über pfctl -d bzw -e ab-/anstellbar sein.

[mimugmail]

Am Switch liegt es nicht, du sagst ja wenn du pfctl -d machst geht es sofort.
Nein, installiere 18.7.9 neu und mach KEINEN restore .. dann setzt du erst den CARP auf, ohne besondere Firewallregeln (bis auf all-accept auf sync Interface).

Es muss dann eigentlich funktionieren.

[Andreas_]

Die Config hat 380k mit Tonnen von FW-Rules, ist eine CA etc., das wird kaum fehlerfrei wieder einzugeben sein.
Und der Router muß auch noch 24/7 verfügbar sein...
Ich hoffe demnächst einen physischen Router aufsetzen zu können.

[mimugmail]

Ja, aber wie schon im Ticket geschrieben ist das sicherlich ein Fehler der von upgade zu upgrade mitgezogen wurde. Wenn möglich, neu aufsetzen, dann den HA und schauen obs geht, wenn ja, restore, wenns dann wieder nicht geht => alter config Fehler.

Und dann kann man immer noch nen diff auf ne live config.xml machen. Ich hab so setups auch im 40G Betrieb .. das Zeug funktioniert eigentlich stabil.

[ppmathis]

Ich hatte auf meinem Cluster das gleiche Problem und konnte ebenfalls keinerlei ausgehenden IPv6 CARP Traffic feststellen. In pftop war dieser zwar ersichtlich als SINGLE:NO_TRAFFIC, jedoch verliessen keine Pakete das Interface. Nur ein Deaktivieren von pf hatte jeweils die benötigten Multicast-Pakete übermittelt, alle anderen Ansätze (pass-any-ruleset, keine Scrubbing-Rules, keine Antispoof-Rules, ...) waren erfolglos.

Auf GitHub ging nun vor Kurzem ein ähnlicher Issue auf, zu welchem Zeitpunkt ich auch gerade mit der Fehlersuche beschäftigt war. Ich weiss noch nicht, ob der GH Issue sich auf die selbe Thematik wie bei mir bezieht, aber ich konnte den Fehler bei mir beheben durch das Deaktivieren von Shared Forwarding.

Siehe dazu: https://github.com/opnsense/core/issues/3411#issuecomment-484717752

[Andreas_]

Vor kurzem hatte ich einen neuen Anlauf genommen das Problem zu diagnostizieren, war aber noch nicht dazu gekommen diesen Thread zu ergänzen.
Da ich nicht im Produktivsystem testen konnte, hab ich schlußendlich eine weitere identische Firewall gebaut und die Originalkonfiguration eingespielt. Sofort konnte ich die abgehenden CARP-Pakete sehen. 
Daraufhin habe ich im Produktivsystem einen zusätzlichen Switch zwischen Firewall und Upstream (Provider Switch) geschaltet, und konnte auch dort meine Pakete sehen.
Eine längere Konsultation mit dem RZ-Personal führte dann dazu daß dort IGMP Snooping im Coreswitch für uns disabled wurde, und siehe da schon gingen auch die CARP Multicastpakete wieder durch. Ich vermute, daß seinerzeit ein SW-Update im Coreswitch eingespielt wurde was IGMP Snooping falsch umsetzt, nämlich auch ALL-NODES Multicast behandelt.

Warum pfctl -d funktionierte hab ich dann nicht mehr ausprobiert, ich war froh endlich wieder funktionstüchtige Standbyredundanz zu haben.

[Andreas_]

Ich denke ich weiß jetzt woran es liegt, siehe https://github.com/opnsense/core/issues/3468