Messages

Wenn Datenschutz/Compliance nicht dagegen spricht, dann schau doch mal nächsten Freitag zum virtuellen Stammtisch rein und wir schauen live drauf?

Wann genau findet am kommenden Freitag dieser Stammtisch statt? Und wie erfolgt dann die Live-Betrachtung?

Ich bin privater Nutzer. Ich habe mal einen Failover gemacht, um zu sehen, ob der Fehler zum primären Knoten wandert, wenn der Backup-Knoten der CARP-VIP-Master ist. Das ist nicht der Fall. Ich kann auf dem primären Knoten Aktualisierungen durchführen, während dieser nur als CARP-VIP-Backup läuft - so wie es auch sein soll.

Jetzt habe ich nur den primären, aktiven Cluster-Knoten heruntergefahren und dann funktioniert die Internet-Verbindung des eigentlichen Standby-Knoten.

Starte ich den primären Knoten wieder, geht die Internet-Verbindung des Standby-Knotens nicht mehr.

Das hat offenbar mit der Master-Rolle der CARP-IPs zu tun. Das war anfangs nicht so und sollte vermutlich auch nicht so sein, damit auch der Standby-Knoten Aktualisierungen durchführen kann (Firmware, Erweiterungen, ClamAV-Pattern usw.).

Ping geht nicht, das habe ich ja schon geschrieben.

ifconfig: Ich habe die Netzwerk-Einstellungen in der Schnittstellen-Übersicht der OPNsense im WebUI geprüft und finde keinen Fehler.

netstat -r: Hilft mir da nicht weiter.

Wie ich bereits geschrieben habe, hat das bis vor kurzem noch funktioniert. Ich weiß aber nicht, was ich möglichweise geändert habe, das zu dem Problem führt. Ich hatte das Captive Portal im Verdacht, aber wenn ich das deaktiviere, ändert sich nichts.

Und seltsam ist, dass die OPNsense in den Nachbarn alle Geräte im WAN-Segment sieht.

Ich starte jetzt mal beide Knoten durch, vielliecht hilft das ja...

Ich suche den Fehler, warum diese OPNsense nicht ins Internet kommt. Aber ich komme da nicht weiter. Das hat definitiv schon funktioniert, denn ich konnte bereits Anfang März erfolgreich ein Update des Systems durchführen.

Die beiden OPNsense-Knoten sind identisch konfiguriert, laufen auf separaten ESXi-Hosts und auch dort sind die Netzwerkeinstellungen (Portgruppen, vSwitches, Netzwerkkarten) identisch.

Aber die OPNsense mit den Problemen kann nicht einmal die Geräte im WAN-Segment pingen. Sie sieht aber diese Geräte als Nachbarn. Irgendetwas unterbindet die Netzwerk-Verbindung.

Interessant: Im Firewall-Log taucht die CARP-VIP auf, wenn ich ein Gerät im WAN-Segment anpinge. Aber die CARP-VIP läuft auf dem aktiven Knoten und wird als Backup auf dem Standby-Knoten angezeigt. Ich habe erwartet, dass der Ping vom Standby-Knoten über die IP-Adresse der Netzwerkkarte erfolgt. Das würde auch erklären, warum ein Traceroute aus dem LAN zu www.heise.de die OPNsense zeigt, obwohl diese noch gar nicht produktiv ist, sondern parallel zum Sophos UTM Cluster läuft, da sich die OPNsense noch im Aufbau befindet.

Gibt es eine Idee, wie ich das lösen kann?

Hier nun das Ergebnis des Audits:

Code Select Expand

***GOT REQUEST TO AUDIT CONNECTIVITY***
Currently running OPNsense 26.1.2_5 (amd64) at Fri Mar 13 09:05:51 CET 2026
Checking connectivity for host: pkg.opnsense.org -> 89.149.222.99
PING 89.149.222.99 (89.149.222.99): 1500 data bytes

--- 89.149.222.99 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
Checking connectivity for repository (IPv4): https://pkg.opnsense.org/FreeBSD:14:amd64/26.1
Updating OPNsense repository catalogue...
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
repository OPNsense has no meta file, using default settings
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
Unable to update repository OPNsense
Error updating repositories!
Checking connectivity for host: pkg.opnsense.org -> 2001:1af8:5300:a010:1::1
ping: UDP connect: No route to host
Checking connectivity for repository (IPv6): https://pkg.opnsense.org/FreeBSD:14:amd64/26.1
Updating OPNsense repository catalogue...
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
repository OPNsense has no meta file, using default settings
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
Unable to update repository OPNsense
Error updating repositories!
Checking server certificate for host: pkg.opnsense.org
0810A528E43B0000:error:8000003C:system library:BIO_connect:Operation timed out:/usr/src/crypto/openssl/crypto/bio/bio_sock2.c:125:calling connect()
0810A528E43B0000:error:10000067:BIO routines:BIO_connect:connect error:/usr/src/crypto/openssl/crypto/bio/bio_sock2.c:127:
connect:errno=60
***DONE***

Auf der Konsole sieht man ständig Meldungen der Art "lighttpd stopped" und "lighttpd started". Ist das normal? Kommt das evtl. durch die regelmäßigen Updates im HA-Cluster - die OPNsense mit dem Problem ist das Standby-System.

OK, diese Option sieht man erst, wenn die Daten eingelesen sind und angezeigt werden, was bei dieser OPNsense recht lange dauert.

Ich bin mir jetzt nicht sicher, ob das die Audit-Ausgaben sind. Ich habe neben dem Audit noch "Plugin-Konflikte beheben" gesehen und da den automatischen Resolver gestartet. Vermutlich sind das die Ausgaben vom Versuch, die Konflikte zu beheben:

Code Select Expand

***GOT REQUEST TO SYNC***
Currently running OPNsense 26.1.2_5 (amd64) at Fri Mar 13 08:12:25 CET 2026
Updating OPNsense repository catalogue...
Waiting for another process to update repository OPNsense
All repositories are up to date.
pkg: Repository OPNsense cannot be opened. 'pkg update' required
pkg: No packages available to install matching 'os-acme-client' have been found in the repositories
Updating OPNsense repository catalogue...
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
repository OPNsense has no meta file, using default settings
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
Unable to update repository OPNsense
Error updating repositories!
Updating OPNsense repository catalogue...
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
repository OPNsense has no meta file, using default settings
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
Unable to update repository OPNsense
Error updating repositories!
Updating OPNsense repository catalogue...
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
repository OPNsense has no meta file, using default settings
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
Unable to update repository OPNsense
Error updating repositories!
Updating OPNsense repository catalogue...
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
repository OPNsense has no meta file, using default settings
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
Unable to update repository OPNsense
Error updating repositories!
Updating OPNsense repository catalogue...
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
repository OPNsense has no meta file, using default settings
Da hängt das System jetzt wohl in einer Schleife. Ich starte jetzt erst einmal neu und versuche dann, den Audit zu starten.

Wie erstelle ich ein solches Audit?

Guten Abend zusammen,

ich habe ein Problem mit dem Standby-Knoten meines OPNsense-HA-Clusters: Seit einiger Zeit kann dieser keine Updates mehr erhalten, zeigt keine Pakete an und auch die Anzeige der Firmware-Statusinformationen dauert sehr lange. Wenn ich dann auf "Auf Aktualisierungen prüfen" klicke, dann sehe ich im Protokoll folgendes:

Code Select Expand

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 26.1.2_5 (amd64) at Thu Mar 12 21:25:44 CET 2026
Fetching changelog information, please wait... fetch: transfer timed out
Updating OPNsense repository catalogue...
Waiting for another process to update repository OPNsense
All repositories are up to date.
Upgrading package manager from version '2.3.1_1' to ''
Updating OPNsense repository catalogue...
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error
repository OPNsense has no meta file, using default settings
pkg: An error occurred while fetching package: No error
pkg: An error occurred while fetching package: No error... (den Rest zeigt es mir nicht mehr an, weil ich zwischendurch noch etwas geprüft habe.

Immerhin kam jetzt mal "Upgrading package manager from version '2.3.1_1' to ''" usw., aber irgendetwas stimmt nicht. Ich habe schon einiges ausprobiert:

• opnsense-bootstrap
• Umstellung des Spiegelservers, Reboot und wieder zurück zum ursprünglichen Spiegelserver "(default)"
• Reset to Factory defaults
• Neuinstallation und Wiederherstellung der letzten Konfiguration

Keiner dieser Maßnahmen hat geholfen.

Der aktive Knoten hat überhaupt keine Probleme, Aktualisierungen usw. herunterzuladen.

Hat irgendjemand eine Idee, was ich noch machen kann?

Vielen Dank und viele Grüße

Was meinst du, was ich wo einsetze? Beim Hostnamen?

Ich meinte welches Produkt Du verwendest. Das hat Du aber im Satz zuvor beantwortet. Wenn ich Dich richtig verstehe, dann hast Du eine weitere OPNsense für das Captive Portal am laufen.

Ich nutze CP und HA nur getrennt. Kann daher nicht sagen, ob Vouchers synchronisiert werden. Ich hätte angenommen, dass es so wäre, vorausgesetzt die Synchronisation dafür ist aktiviert.

Interessant. Du hast also ein externes Captive Portal? Was setzt Du ein? Ich wollte ja eigentlich auch beim Captive Portal meiner Grandstream Access Points bleiben, aber die Access Points funktionieren nicht ganz so, wie es sein soll und jetzt muss ich sie wg. einem angeblichen Defekt (gleich zwei Access Points mit dem gleichen Defekt lt. Support?) wieder zurückgeben und wahrscheinlich werde ich mir andere Access Points besorgen. Die haben aber meistens kein Captive Portal mit Voucher. Deshalb habe ich mir das Captive Portal der OPNsense angesehen.

Es ruft aber doch niemand das CP direkt auf. Jemand gibt www.heise.de in den Browser ein und wird auf das CP umgeleitet. Ist der Primary aktiv, auf den Primary, ist der Standby aktiv, auf den Standby. Oder verstehe ich das CP falsch?

Ja, das Captive Portal sollte automatisch erscheinen, wenn man eine URL aufruft und noch nicht authentifiziert ist. Mir ist nur nicht klar wie das im HA-Cluster funktioniert, wenn nicht die CARP-IP des Clusters aus dem VLAN für das Captive Portal verwendet wird.

Ich bin noch im parallelen Aufbau der OPNsense, migriere von der Sophos UTM. Das ist recht zeitaufwendig, so dass ich noch nicht sagen kann, wie das funktioniert, wenn alles mal produktiv ist.

Wenn das aber ein Schreibfehler ist

Nein, das ist kein Schreibfehler.

Ich verstehe aber immer noch nicht, weswegen es die CARP IP sein muss. Ebenso gut kannst du die IP der Backup-Node in den URL reinsetzen und die Webseite sollte auch aufgehen.

Weil ich einen HA-Cluster habe! Und ja, der Aufruf funktioniert auch mit der IP-Adresse des Backup-Knotens - deshalb hatte ja auch allgemein geschrieben: Wenn man http://<IP-Adresse des HA-Knotens>:8000/ aufruft, dann erscheint das Captive Portal.

Wenn du es aber dennoch auf der CARP VIP haben möchtest, dann leite die Anfragen eben auf die Interface-Adresse weiter.
Also eine Destination NAT Regel am jeweiligen Interface erstellen mit der CARP VIP als Destination und Port 8000 (f. Zone 0) und als Redirect Target die Interface Adresse (die vordefinierte Variable, damit die Regel auch auf der Backup funktioniert) und Port 8000.
Dies ist für https. Für http wäre noch eine Regel mit Zielport 9000 nötig.

OK. Aber das macht natürlich nur Sinn, wenn auch die Voucher im Cluster synchronisiert würden.

Port 8000.
Dies ist für https. Für http wäre noch eine Regel mit Zielport 9000 nötig.

Ich habe HTTPS für das Captive Portal noch nicht aktiviert. Wenn ich http://<IP-Adresse des HA-Knotens>:9000/ aufrufe, wird auf http://<IP-Adresse des HA-Knotens>:8000/ umgeleitet.

Aber das CARP Service selbst wird ja nicht an eine IP gebunden.

Du meinst vermutlich das Captive Portal und nicht CARP Service, oder? Denn CARP ist an Schnittstellen und IP-Adressen gebunden. Ich lege lediglich fest, für welche Netzwerke, aber in der Tat nicht, über welche IP-Adresse das Captive Portal erreichbar sein soll.

Ich frag mich daher, was da nicht funktioniert.

Wenn man die URL des Captive Portal mit http://<CARP-IP-Adresse>:8000/ aufruft, kommt ein Timeout. Wenn man http://<IP-Adresse des HA-Knotens>:8000/ aufruft, dann erscheint das Captive Portal.