OPNsense incoming

Barungar

Barungar

Well-known member
Hallo zusammen,

da meine aktuelle Haupt-Firewall (eine Hardware Appliance) gerade etwas muckt, und @tiermutter mich mit OPNsense "angefixt" hat, werde ich mir als Ersatz ein OPNsense HA-Cluster aufbauen. Aktuell trage ich die notwendigen Teile zusammen. ;) OPNsense scheint mir recht gut und brauchbar zu sein; und da meine aktuelle Firewall als Einzelgerät ein SPoF (Single Point of Failure) ist, wie sich auch jetzt wieder mal zeigt, baue ich mir gleich zwei OPNsenses in Hardware. ;)

Auf einer Test-VM habe ich mit OPNsense schon was rumgespielt und ich denke, dass ich meine Anforderungen damit sehr gut abdecken kann.

Ich werde von meinem kleinen Projekt berichten.
 
Zuletzt bearbeitet:
Ich freu mich drauf :)
HA habe ich auch mal überlegt, ist es mir aber nicht wert, da wieder drei zusätzliche Geräte (Router für Glas, Switch für LTE Modem, 2. Sense) laufen müssten, daher begnüge ich mich mit einer zweiten Sense als Fallback :)
 
Ja, die Hardware ist schon incoming. ;)
Es werden zwei Barebone "NUCs", also diese kleinen, lüfterlosen Würfelchen.
  • Gigabyte BACE-3000 (Intel Celeron N3000)
  • 8 GB RAM
  • 250 GB 2,5" SDD
  • 1 GBit/s on-board (Realtek 8111H)
  • 2x UGREEN 1 GBit/s (Asix AX88179) USB 3.0 Adapter
Ich habe mich bewusst für zwei günstige NUCs entschieden.
 
Fein :)
Da wird dann sicherlich auch ein IPS drauf laufen?!
Ich hatte hierzu die ET Pro Telemetry Edition abonniert und in Suricata verwendet, nutze IPS aber nicht mehr, da es seit dem Glasfaseranschluss meine Hardware an die Grenzen bringt :(

Bei den USB Ethernet hätte ich Sorge, dass FBSD damit nicht ordentlich zurechtkommt.
 
Ich habe gerade kein FreeBSD verfügbar....
Aber ich habe schon zwei der NUCs, da läuft mein DNS-Cluster drauf. ;) Allerdings unter Unbuntu 20.04 LTS. Ich habe gerade eine der neuen Ugreen USB-Netzwerkkarten an den USB3-Port eines der NUCs angeschlossen.

Das Test-Feld sind der primärer DNS-Server (eigentlich 172.22.172.251) mit der Ugreen (auf 172.22.172.244) als iperf-Server und der sekundäre DNS-Server (172.22.172.252) als iperf-Client. Vom iperf-Client (on-Board Realtek) wurden zwei Messungen zum Server durchgeführt, einmal auf die on-board (.251) und die USB3 (.244).

Hier das Messergebnis...

Code: 
root@lskoe402:/root# iperf --format M -c 172.22.172.244
------------------------------------------------------------
Client connecting to 172.22.172.244, TCP port 5001
------------------------------------------------------------
[  3] local 172.22.172.252 port 51076 connected with 172.22.172.244 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1095 MBytes   109 MBytes/sec

root@lskoe402:/root# iperf --format M -c 172.22.172.251
------------------------------------------------------------
Client connecting to 172.22.172.251, TCP port 5001
------------------------------------------------------------
[  3] local 172.22.172.252 port 35018 connected with 172.22.172.251 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1110 MBytes   111 MBytes/sec

Unter Ubuntu 20.04 LTS bin ich mit der Performance der UB3-Netzwerkkarte voll zu frieden, der Switch-Port zeigt auch keine Auffälligkeiten (Fehlerzähler, usw.). Ich gehe einfach mal davon aus, dass die Karte unter FreeBSD auch funktioniert. Anstonst muss ich mir was überlegen. ;)
 
Ich melde mal Interesse bzgl. der Erfahrungen an :)

Aktuell lasse ich die OPNSense jeweils als VM auf den 3 Nodes meines Promox-Clusters laufen.
Ich war schon überlegen mir so etwas hier zu holen, kann mich aber noch nicht durchringen...
 
Erster Zwischenbericht
Die Hardware ist komplett und zusammengeschraubt, das habe ich gestern Abend noch gemacht.

Heute Morgen habe ich mich dann damit befasst OPNsense auf die beiden NUCs zu installieren. Das war die erste kleine Herausforderung. Ich habe verschiedene Variationen ausprobiert, das OPNsense ISO-Image per USB-Boot zu installieren. Aber die FreeBSD-Installation ist immer wieder an der gleichen Stelle hängen geblieben. Die betreffende Stelle war, laut letzter Ausgabe auf der Konsole, der Versuch das Entropy-Kernelmodul zu laden.

Zwischenzeitlich habe ich, nur um zu prüfen, ob der NUC einen Fehler hat oder nicht, Ubtuntu 20.04 LTS installiert. Das Ubuntu-Image ließ sich allerdings ohne jegliche Schwierigkeiten anstandlos von USB booten und installieren.

Letztlich habe ich Lösung gefunden, im BIOS der NUCs. FreeBSD scheint da ein wenig rigide zu sein. Bei den NUCs war der UEFI mit Legacy Support aktiv. Nachdem ich den UEFI Legacy Support abgeschaltet habe, und somit einen reinen UEFI-Betrieb erzwungen habe, war auch FreeBSD glücklich.

Aktuell habe ich zwei NUCs mit installiertem OPNsense 22.1.4_1 und mache mich nun an die weitere Einrichtung.
 
Kannst dann ja mal berichten, ob anderweitige Pakete (z.B. HAproxy - falls Du sowas überhaupt darauf laufen lässt) auch vernünftig via HA funktionieren, oder ob sich HA rein auf die Standard-Dienste der OPNsense bezieht. Hab derzeit was anderes laufen, bin allerdings nicht so ganz zufrieden und die KEMP-Kisten sind preislich ja nicht grade günstig... ☺️ Bei traefik und Co. gibt es so eine Funktionalität dann meist auch nur in der Enterprise-Edition...

Wünsche weiterhin gutes Gelingen! ☺️
 
Gute Wahl. Ich verwende es ja erst seit die Möglichkeit direkt im installer enthalten ist, hauptsächlich war die Intention BE zu verwenden.
Gibt es eigentlich noch Pros für UFS?
 
Naja, auf so einem kleinen NUC dürfte UFS performanter sein... aber mir ist die Datenkonsistenz eines ZFS mit copy-on-write sowie "Selbstheilung" lieber.
 
Zweiter Zwischenbericht
Nachdem die Grundinstallation schließlich erfolgreich war, habe ich damit begonnen die ersten Konfigurationen im System vorzunehmen.

Bei diesen ersten Konfigurationen ist dann doch, wie von @tiermutter prophezeit, ein Problem mit den USB3-Netzwerkadaptern auf Basis der AX88179-Chips zu Tage getreten. Grundsätzlich erkennt das FreeBSD 13 stable die AX88179-Adapter sauber und erstmal ohne erkennbare Probleme. Auch die mit iPerf gemessenen Durchsatzraten, sind wie unter Ubuntu 20.04 LTS, absolut in Ordnung. Anfangs ist mir auch kein Problem mit den Adaptern aufgefallen. Als ich dann aber angefangen habe die ersten HA-Funktionen, wie z.B. die CARP-Gateways in den Subnetzen oder die State Sync HA-Funktion der OPNsense selbst, zu aktivieren, mehrten sich die seltsamen Vorfälle.

Im CARP sind ständige Warnung aufgetretten und der HA State Sync ist mehr nicht sauber durchgelaufen.

Ich habe die Adapter dann schließlich genauer auf der Shell beobachtet, in dem ich mir dort sekündlich einen ifconfig habe anzeigen lassen. Dabei ist zu Tage getreten, dass die Adapter ab und zu ganz kurz die Ethernet-Verbindung verlieren. Man könnte also sagen, die Netzwerk-Verbindung flattert. Leider ist es mir nicht gelungen, dieses Flatterverhalten einzudämmen. Ich habe versucht den Link statisch auf 1000M FDX zu setzen, dynamisch auf Autokonfig bzw. auf default; aber es war keine wirkliche Besserung zu erzielen.

Die AX88179-Adapter sind also erstmal aus meiner Installation rausgeflogen und gehen zurück mangels stabiler Verbindung. Als Ersatz habe ich, für den nächsten Versuch, zwei USB3-Netzwerkadapter auf der Basis des Realtek RTL8156b-Chips geordert und werde die dann ausprobieren. Die Kosten pro Stück allerdings auch das Doppelte. --> Bericht zur Erfahrung folgt...

Damit ich die allgemeine Funktionalität weiter testen und konfigurien kann, habe ich als Workaround erst einmal alle Interfaces der OPNsense auf IEEE 802.1Q umgestellt und lasse diese über den einen internen Realtek onbord Adapter laufen.

Was bleibst sonst so zu berichten? Das HA State Sync & Config Sync klappt sehr gut. Ich ändere Einstellungen grundsätzlich nur an der "Master-FW" und die "Backup-FW" erhält diese Änderungen übermittelt. Dabei wird auch direkt die "Logik" beachtet. Beispiel: Ich lege ein neues CARP-Gateway für der VLAN 8 auf dem Master an. Auf dem Master gebe ich ein: die virtuelle IP, die VHID-Gruppe, das CARP-PW sowie das Base & Skew; das Ganze wird noch dem physischen Interface mit der statischen IP des Masters zugeordnet. Auf dem Backup kommt dann an: virtuelle IP, VHID, PW, Base sowie eine Skew+100 und das passende Interface mit der korrekten statischen IP des Backups.
 
Realtek NICs sind bei OPNsense/ FBSD aber auch eher verpönt :)
Mittlerweile gibt es extra ein Plugin (os-realtek-re) mit den offiziellen re Treibern, allerdings ist der von Dir genannte Chip nicht dabei:
https://www.realtek.com/en/componen...0-1000m-gigabit-ethernet-pci-express-software
Auf meiner alten Sense hatte ich auch re NICs und keine Probleme damit, hatte aber auch kein CARP Setup.

Bis auf das lästige Treiberproblem scheint es aber soweit ganz fein zu klappen alles, oder?!

Wie sieht es abseits von CARP aus? Läuft da auch alles zufriedenstellend?
 
tiermutter schrieb:
Bis auf das lästige Treiberproblem scheint es aber soweit ganz fein zu klappen alles, oder?!
Zum Vergrößern anklicken....
Ja, bis auf die Treiber- bzw. Netzwerkkarten-Sache ist habe ich bis jetzt noch keine anderen Schwierigkeiten.


tiermutter schrieb:
Wie sieht es abseits von CARP aus? Läuft da auch alles zufriedenstellend?
Zum Vergrößern anklicken....
Ich gehe eher sequentiell vor. Im Moment ändere ich gerade die VLAN-Zuordnungen. Die hatte ich aus der Shell herausgemacht, aber dann sind die in der GUI nicht sauber bearbeitbar. Daher lege ich die VLAN-Definitionen gerade aus der GUI nochmal an.
 
Zuletzt bearbeitet:
Freut mich zu hören... Vor allem dass sich eine weitere Netzwerk- und IT-Koryphäe für OPNsense entschieden hat :)
 
Also bei den meisten Systemen hat man die wenigsten Probleme mit Intel-NICs. Direkt an Platz 2 kommt dann eigentlich Realtek. Weiss aber grade auch garnicht, ob es überhaupt so USB-Dinger mit Intel-Chips gibt, ist nicht so mein Gebiet ☺️
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Zurzeit aktive Besucher

Gesamt: 103 (Mitglieder: 7, Gäste: 96)

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
5.218
Beiträge
52.094
Mitglieder
4.956
Neuestes Mitglied
Joshua26

Teilen

Zurück
Oben