OPNsense HA: Fritzbox von einer Instanz nicht erreichbar

Ich habe heute beide Instanzen auf OPNsense 22.7_4 aktualisiert und seitdem kann meine Hauptinstanz die Fritzbox nicht mehr selbst erreichen. Alle anderen Host's aus dem FB-Netzwerk sind pingbar, nur die FB selbst nicht. Beide Instanzen laufen in VM's auf Proxmox-Hosts - beide Proxmox-Hosts können die Fritzbox anpingen.

Auf beiden OPNsense Instanzen läuft Unbound. Die Geräte in den Subnetzen verwenden als Gateway und Nameserver jeweils die entsprechende CARP-IP.
Das Routing der Geräte aus den Subnetzen ist nicht betroffen - diese können sowohl die Fritzbox pingen, als auch Ziele im Internet via IP erreichen.

Wenn die erste OPNsense der Master ist, funktioniert die Namensauflösung über Unbound nicht. Ich vermute mal, dass hat etwas damit zu tun, dass die diese Instanz die Fritzbox nicht erreichen kann.
Wenn die zweite OPNsense der Master ist, funktioniert die Namensauflösung über Unbound.

Beide Konfigurationen wurden backuped und dann mit VSCode vergleichen: die Konfigurationen sind bis auf instanzspezifische-Einstellungen (hostname, mac, ip, ha credentials, ha revision, advertise skew bei den CARP-IP's) identisch. Darüber hinaus gibt es in der zweiten Instanz noch Konfigurationsparameter als Leeres XML-Elemente, die in der Ersten fehlen (was vermutlich durch den HA-Sync kommt). Die erst Instanz hat zusätzlich noch einen "lldpd" block, der aber auch nicht enabled ist.

Das Problem ergibt für mich keinen Sinn... Wie kann es sein, dass die erste OPNsense alle Geräte, bis auf die Fritzbox selbst, im Fritzbox-Netz erreichen kann?
Hat jemand eine Idee wie man sich der Identifikation des Problems nähert? Oder besser gleich die VM wegwerfen, neu aufsetzen und Config importieren?
 
Zuletzt bearbeitet:

blurrrr

Well-known member
Fritzbox mal neugestartet? War ja schon mal Trouble bzgl. Fritzbox und ARP (bei den Portfreigaben), nicht, dass es ebenfalls in diese Richtung geht (trotz virtueller MAC beim FW-Cluster).
 
Nope, unverändert. Beide VM's spinnen. Ich hab VM1 auch schon wieder neu aufgesetzt mit der alten Config: selbst mist.
Wobei ich mir jetzt mal gespart haben die FB stromlos zu machen - einfach nur reboot über die UI.
 
Zuletzt bearbeitet:

blurrrr

Well-known member
Hört sich aber schon strange an, besonders dann, wenn die Internetverbindung funktioniert (also das Routing über die Fritzbox) und Du auch alle anderen Hosts im Fritzbox-Netz erreichst... schwer beleidigte Fritzbox... 😁 Ansonsten würden mir dazu noch Firewall-Regeln einfallen, aber das dürfte es ja nicht sein... Was sagen denn die *sense-Logs dazu, wenn Du von einem Client hinter der Firewall versucht die Website der Fritzbox aufzurufen?
 
... schön das sowas ausgerechnet passiert, wenn mein 3 Wochen Urlaub vorbei ist...
Ich werde morgen Abend mal draufschauen. Morgen geht's wieder früh hoch.
 

Barungar

Active member
Ich hatte mal sowas ähnliches. Da hatte sich der Link Aggregat zwischen den Switch und der Firewall aufgehangen, mit dem Ergebnis, dass genau eine MAC falsch gelernt wurde. Somit war alles erreichbar nur nicht das eine Gerät, dessen MAC krummstand.

Das ist aber wilde Spekulation. Bei solchen Phänomen hat es sich aber bei mir eingebürgert die MAC-Tabelle aller Layer 2-Geräte, die zwischen Ziel und Quelle liegen zu prüfen.
 

blurrrr

Well-known member
Das ist aber wilde Spekulation.
Naja, so wild finde ich das garnicht. Switch hatte ich jetzt erstmal aussen vor gelassen (Routing funktioniert ja anscheinend) und wenn es "nur" um den webbasierten Zugriff auf die Fritzbox geht, muss ja schon irgendwas ziemlich komisch sein (daher auch erstmal Fritzbox neustarten). Da die FWs virtualisiert sind, kann es u.U. natürlich auch noch am PVE liegen (ist da etwas durcheinander, hilft es meist, wenn man die Firewall nicht "nur" neustartet, sondern wirklich einmal komplett "aus" macht und dann wieder einschaltet).

Bei mir war auch sofort der Verdacht bzgl. MAC-Adressen vorhanden, aber wenn "alles" funktioniert (nur der Zugriff auf die FB selbst nicht), bin ich mir da bzgl. der MAC-Kausalität nicht so sicher, da das Routing ja weiterhin funktioniert. Entweder irgendein Gemurks in den oberen Layern, oder es ist vielleicht wieder so eine AVM-spezifische Sonderlocke, wer weiss...
 
Naja, so wild finde ich das garnicht. Switch hatte ich jetzt erstmal aussen vor gelassen (Routing funktioniert ja anscheinend) und wenn es "nur" um den webbasierten Zugriff auf die Fritzbox geht, muss ja schon irgendwas ziemlich komisch sein (daher auch erstmal Fritzbox neustarten). Da die FWs virtualisiert sind, kann es u.U. natürlich auch noch am PVE liegen (ist da etwas durcheinander, hilft es meist, wenn man die Firewall nicht "nur" neustartet, sondern wirklich einmal komplett "aus" macht und dann wieder einschaltet).
Nene, die OPNense-Büchsen selbst können die Fritzbox selbst nicht - und somit auch den DNS der FB - nicht erreichen. Geräte aus den Subnetzen können durch die OPNsense-Büchsen darauf zugreifen. Ich versehe überhaupt nicht warum letzeres geht.

Gestern Abend lief eine von beiden dann auch wieder - wäre nur schön wenn es nicht einfach nur zufällig geht/nicht geht - lieber ehrlich kaputt/heil als dieser esotherische Mist!

Ich hab gestern Fritzbox und Switch neu gestartet, die OPNsense hängt mit der WAN-Nic auf einer Proxmox-Bridge ins Fritzbox-Netzwerk. Bei den Proxmox-Kisten hab ich den Arp-Cache geleert. Bei den beiden Geräten hätte ich gedacht, dass ein Neustart (ohne Stecker ziehen) reichen sollte damit der ARP-Cache geleert ist.

Wenn nix mehr geht kann ich auch alles mal stromlos machen - ist mir lieber als planloses rumprobieren.
 
Im Switch ist in der ARP-Table die MAC der FB dem richtigen Port zugeordnet. Wäre es anders könnten die Geräte aus den Subnetzen sicherlich auch nicht auf die FB zugreifen. Bleibt doch eigentlich nur noch die FB oder OPN als verweigerer. Das spannende ist ja, dass aus Sicht der Fritzbox die Geräte in den Subnetzen als Zusatz-IPs der OPNsense gelten (kann man im Support-Dump gut sehen) und die wiederum können ja problemlos mit der FB kommunizieren.

In den Firewall-Logs versendet die Anfrage übrigens an der Stelle, wo Unbound den lokalen Resolver der OPNsense auf 127.0.0.1 anspricht. Dieser meldet dann ein SRVFAIL. Der lokale Resolver müsste eigentlich die FB anfragen (wo die OPNsense aber nicht hinkommt..).
 
Zuletzt bearbeitet:
Ich hatte jetzt die zweite OPNsense jetzt mal länger ausgestelt.. und sie da nach einem Neustart geht es auch dort. :oops:

Und was war es jetzt? Keine Ahnung!
Was hat konkret geholfen? Keine Ahnung!
Hat das Ausschalten, Warten, Neustarten zum Ablaufen der Einträge in den ARP-Tables die Lösung war? Denkbar.

Der Mist hat mich jetzt in Summe 6h meines Lebens gekostet und ich hab im Gegenzug nicht mal was dazu gelernt. Bescheidene Bilanz... Immerhin läuft jetzt alles wieder.
 

blurrrr

Well-known member
Jo, sowas nervt mich auch immer total und das schlimmste ist, dass sich die meisten auch mit solchen Umständen "abgefunden" haben... "Geht nicht? Hm.... och, geht wieder? Na dann ist ja gut..." und niemanden kümmert es noch, woran es eigentlich lag (ausser natürlich, das Problem tritt erneut auf) :rolleyes:
 
Ich glaube ich habe die Funktion gefunden die die Ursache ist:
1659376771323.png
Es war beim letzten Vergleich der Haupt/Zweit OPN der einzige Unterschied. Was mir bis eben nicht klar war: die Änderung greift erst nach einem Reboot.

Das Problem tritt reproduzierbar auf, wenn der Haken gesetzt ist und danach neu gestartet wird.
Das Problem verschwindet reproduzierbar, wenn der Haken nicht gesetzt ist und danach neu gestartet wird.

Hab ich doch was dazu gelernt: manche Änderungen greifen erst bei einem Reboot && Bewahre alte Konfig-Backups für forensische Analysen auf && Selbstsabotage tut weh :ROFLMAO:
 

blurrrr

Well-known member
Mhm... Wenn man das jetzt rein routingtechnisch betrachtet, hätten die Clients hinter der Firewall aber auch keinen Zugriff auf's Internet haben dürfen (wie auch, wenn das Default-Gateway nicht passt)... macht für mich jetzt nicht wirklich Sinn, aber ich lasse mich auch gern eines besseren belehren... :unsure:

Wenn man eine Änderung vornimmt, welche erst nach einem Reboot wirksam wird und dann ewig nicht neustartet... Klar ist die Verwunderung dann nach dem Neustart groß... am besten finde ich das noch immer bei Switchen, wenn die Config nicht geschrieben wird... Reboot, zack, nicht geschriebene Änderungen -> weg 😁
 
Mhm... Wenn man das jetzt rein routingtechnisch betrachtet, hätten die Clients hinter der Firewall aber auch keinen Zugriff auf's Internet haben dürfen (wie auch, wenn das Default-Gateway nicht passt)... macht für mich jetzt nicht wirklich Sinn, aber ich lasse mich auch gern eines besseren belehren... :unsure:
Allerdings - hat mich ja auch die ganze Zeit gewundert, warum die Geräte aus dem Subnet trotzdem da hin kommen...

Noch wundersamer finde ich aber, warum es bis vorm Update lief, entweder muss die Konfiguration da auch schon gewesen sein und wurde ignoriert, oder in der neuen Implementierung ist ein Bug, oder beim Update muss das irgendwie reingeraten sein. Nach dem Update trat der Fehler ohne irgendelche Konfigurationsänderung auf.

Ich verbuche das mal als "Wunderwelt Technik!".
 
Ich bin mal gespannt, wann ich frieden mit dem Thema schließen kann. Auch wenn es gelöst ist, so richtig akzeptiert habe ich das alles noch nicht. Noch brennt es wie ein "Rostiger Nagel im Hintern"
 

Zurzeit aktive Besucher

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
750
Beiträge
11.128
Mitglieder
310
Neuestes Mitglied
DirkHH
Oben