Messages

Moin,

auch wenns schon etwas her ist:

Jedes vLAN Interface hat auf beiden Nodes eine Separate IP
Node1 10.x.x.251
Node2 10.x.x.252
CARP IP 10.x.x.1

Ist bei jedem Netz etwas anders da die Netze mal kleiner mal größer als /24 sind.

Ich würde bei CARP versuchen alle Netze gleich aufzusetzen. Also vllt. .1 als GW, .2/.3 als Nodes. Dann entfällt die Sucherei, welche IP in welchem Netz das jetzt ist und die Größe ist egal. Weniger fehleranfällig. Vor allem wäre das Arbeiten auf dem primary fix immer auf bspw. der .2.

Config sync getestet, und festgestellt das nicht alles übertragen wird. Einige Setting´s müssen manuell auf der Backup Node gemacht werden.
Ok nicht schön aber ist halt so.

Das ist aber korrekt. Vielleicht nicht ganz User-friendly aber Faustregel: alles was "Hardware" ist (also Interfaces, IF Gruppen, IP Konfiguration etc.) ist pro Node zu konfigurieren. Alles was Regelwerk, PF und Co. sowie diverse Services betrifft ist sync-bar. Aber besser nachschauen, ob der Service XY da nicht spezifische Einstellungen für hat oder eben nicht gesynct wird. Bei Zusatzpaketen ist das zB nicht immer der Fall.

Jetzt ist mir beim weiteren einrichten und nach 3 Monaten betrieb aufgefallen.
Wenn die Backup Node übernimmt, wird die Session Tabelle nicht mehr auf die Master Node übertragen.
Sie schaltet einfach zurück.
Und die Master Node blockt dann erst mal jeglichen Taffic da sie keine Sitzung dazu kennt.

Sync nicht korrekt konfiguriert? Auf dem Backup Node nicht den "General Settings" part ausgefüllt? Ohne wird kein State Sync zurück gemacht.

IPSec Tunnels die eingerichtet sind, werden sowohl auf der Master Node als auch auf der Backup Node aktiviert.

Wenn IPsec tatsächlich auf der VIP konfiguriert ist, wäre das ein Fehlverhalten. Wie ist IPsec eingerichtet? Mit der neuen Connections Methode oder eine alte Service-Konfiguration? Eventuell könnte das beim neuen Connections-Setup dann ein Fehler sein, müsste man einmal nachstellen.

Eventuell Verbanne ich die Subnet Routing Funktion ganz von der Firewall auf eine VM irgendwo

Das wäre tatsächlich bei einem Cluster praktischer. Nicht nur wegen der NAT Thematik, sondern auch wegen der Regelerstellung. Bei zwei Nodes auf Firewalls die aktiv sind, wäre es sonst fürs Routing sehr verwirrend, über welchen Node die IPs gehen und von der aktiven FW und Routing Node dann auf die passive kommen - ohne die Tailscale eigene IP zu nutzen - wäre dann ähnlich wie bei OpenVPN/WG Einwahl problematisch und bräuchte wieder einen NAT Workaround.
Darum wäre es vermutlich die geschickteste Idee die zusätzlich noch den Nutzen hätte, dass die Regeln einfacher und geschickter definiert werden können wenn man ein extra VLAN mit ein/zwei Tailscale Nodes dahinter macht (betrifft 1:1 auch das Netbird Setup BTW, funktioniert dort ja sehr ähnlich).

Als ich jetzt die Obigen HA Tests wieder gemacht hatte. War das verhalten extrem anders

Frage vorab: Hast du denn den Config Sync aktiv bzw. als Cronjob eingerichtet? Ansonsten WICHTIG: OPNsense macht KEINEN aktiven sofortigen Sync mehr. Seit längerem. Ich fände es zwar nach wie vor schön, wenn sie das als Option wieder einbauen würden, aber der Config Sync findet IMHO aktuell NICHT automatisch statt. Du brauchst also entweder nen zyklischen Cronjob der das übernimmt oder du musst manuell nach Änderungen wieder syncen, sonst passiert da nichts.

Dass dann im Betrieb die Firewalls auseinander driften in der Config und dann bei einem Failover sich vllt. sehr schräg verhalten ist leider dann kein Wunder. Das hat auch schon viele Kunden von uns getroffen, die von der Beschreibung "Sync" her einfach nicht erwarten, dass das was "Manuelles" ist oder man das nochmal extra als Cron einrichten muss, sondern dass Änderungen eben sofort gesynct und übertragen werden.

Ansonsten ist CARP/HA immer ein wenig komplex und durch die Beschreibung weiß ich jetzt spontan auch noch nicht alles, was schief gehen könnte, daher waren das nur die Punkte, die ich denke man recht schnell sehen kann. Ansonsten bräuchte man da mehr Details oder - wenn du eh schon drüber nachdenkst was anderes einzusetzen - wäre es vielleicht sinnvoll, das im Sinne von Support-Einkauf sich komplett anzusehen.

Cheers
\jegr

Für "allow" ja. Für "deny" nein. Du willst ja auch das gehackte System blocken, das mit einer falschen Absender-Adresse als Teil eines Botnets versucht, irgendeinen Dritten zu DDoSen.

Bisschen her aber: nein will ich nicht. Denn was ich nicht erlaube wird geblockt. Allows werden nur vom <IF_net> Alias erlaubt. Deny gibts auf LAN nicht, da arbeiten wir mit Reject denn da will man dem Client sofort Feedback geben damit er die Eingabe abbrechen kann und nicht auf Timeout wartet. Und geblockt werden da eh nur interne IPs (VLAN separieren), Firewall (hat außer Mgmt keiner was drauf zu suchen) und Blocklisten extern. Das muss ich dann ggf. auch nicht loggen. Soweit die eigenen Regeln also sauber das Netzalias verwenden wäre dein Beispiel mit irgendwelchen falsch-Absendern oder Bots -> gegen default block any und deshalb eh schon geblockt. Gibt keinen Grund die mit meiner eigenen Reject Regel zu loggen, denn die will ich (Blockliste bspw.) ja als Auswertung nehmen. Die Default Blocks fallen dadurch umso mehr auf, weil es keinen Grund geben dürfte, DASS es welche gibt ;) Das hatte also schon seinen Grund.

Cheers :)

Das war auch mein Gedanke. Wenn du was "erbst" und musst es schön machen, dann kann man das ja temporär erstmal irgendwo hochfahren, dass es wieder läuft. Und wenn der Kram schon in Proxmox ist oder war und sogar in Containerform (LXC) statt VM, dann kann man das recht unspektakulär wirklich in nem VPS aufsetzen. Hatte ich selbst für ne Übergangszeit laufen, das geht. Man muss dem Proxmox selbst nur ordentlich Routing aktivieren, dann kann der das an LXCs weitergeben. Und den Container kann ich dann schön via Proxmox Backup o.ä. dann final auf einen sauber aufgesetzten neuen Dedi (z.B.) packen und migrieren, DAS geht dann eben super fix. Hab das genauso für meine eigene Spielwiese gemacht, und das war an einem Samstag mittag mit DNS umstellen und Container migrieren erledigt.

Darum vllt. in dem Fall ein veritabler Workaround?

Cheers :)

Die OutboundNAT Regel dann auf das IPSec Interface oder WAN?

Meinem Verständnis nach outbound auf IPsec Interface, denn da geht der Traffic "raus" aus deinem Netz. Also Source dein internes LAN, Destination das Remote Netz und als Translation IP dann die bspw. .100.97/32 damit alles abgehend auf die IP umgeschrieben wird. Wenn kein eingehender Traffic geplant ist, sollte es das eigentlich tun.

Cheers

Klappt aber nicht. Muss die /32 IP zusätzlich als virtuelle IP auf das jeweilige Interface, falls ja welches?

Nein aber die 184 in eine zusätzliche Policy. Du definierst den Tunnel nicht mit Quelle 184.0/24 sondern mit der /32er IP weil sonst der Tunnel in P2 nicht hoch kommt. Du sagst ja dass nur das /28er erlaubt bzw. remote eingetragen ist. Dann muss das auch bei dir als lokal drinstehen. Dann muss es outbound NAT geben auf die /32er IP und das lokale Netz /24 muss dann als zusätzliche Security Policy für die Verbindung eingetragen werden, damit der IPsec Prozess die Pakete aufsammelt und übers VPN schickt.

Cheers

Geht mir ähnlich wie das was Lucas und Bob schrieben. Die Seite sieht für mich auch nach maximalem Crypto-Bro-Level Telegram-Gruppe aus. Wer heute ernsthaft noch bei Security Themen Werbung macht, dass er 81k Leute bei TWITTER hat, ist schon hart an der Realität vorbeigeschlittert. Sich mit der Plattform noch zu profilieren ist hart daneben. Top 21 Security Twitter Accounts? Ernsthaft? Top 100 Cybersecurity Brands weltweit von irgendeinem Label was ich noch nie wirklich gehört habe?
Das sieht alles so aus wie diese Baukasten Seiten für die Mindset Coaches um richtig Kohle zu machen. Dazu Erfolgslabels von Firmen oder Gruppierungen, die man kaum kennt oder dies in der Form nicht mal mehr gibt. Sentinel ist AI, Onalytica und CISO sind B2B Influence BS Plattformen und Techbeacon gibts nicht mal mehr (leitet weiter zu Opentext).

Mag sein, dass der Mann was drauf hat. Aber die Page und die ganze Aufmachung gibt mir hart andere Vibes.

Mit einem vServer wird das wohl eher schwierig... Virtualisierung per Proxmox auf einem Virtualisierungshost? Ich meinte schon einen echten Root-Server.

Geht recht problemlos. Natürlich nur mit LXCs innerhalb von Proxmox dann, aber kann man machen, wenn man bspw. VM-Handling, Backup & Co vereinfachen möchte. Ist eben etwas limitert. Aber für ein temporäres Setup jetzt nicht das wildeste was ich je gesehen habe :D

Oder bekommst Du wirklich 10GbE WAN Uplink? Wo ist das? Kann ich umziehen ;)
 

Überall in der Schweiz, wo Init7 liefern ;) Weiß nicht ob @bsch da her kommt, aber da bekommst dus garantiert und in super Qualität :)

Gerade, wenn Du sowieso einen externen ONT hast und nur Gast-WiFi brauchst, wäre doch "Fritzbox hinter OpnSense" die perfekte Lösung - offen gesagt, kann ich nicht verstehen, warum Du es nicht so machst, aber, wie Patrick oft sagt: you do you.
 

Weil das Leben oft auch aus Teilen neben der Technik besteht. Wenn mans technisch vllt. am Besten machen will, kann man sich die IP auf die Sense holen. Gerade bei Kabel oder Glas ist das aber je nach Anbieter, Qualität und Support ein Krampf. Wenn man sich dann jedes Mal mit dem Support rumschlagen muss, weil es heißt "das Endgerät wird nicht unterstützt, das Problem liegt an ihnen!" kann man das mit Fritz hinter Sense machen. Ich hatte das bei zu vielen Kunden und privaten Setups schon, dass es jedem Beteiligten einfach nur noch auf die Nerven ging. Hängt dann die Provider Fritte wieder dran ist alles plötzlich "kein Problem" und "ja wir sehen, dass da Probleme auf der Leitung sind". Ach echt?

Ja das macht ein paar Randerscheinungen kaputt. Und ja das macht v6 schwierig oder kaputt. Ist es aber eh, wenn man bei DG gern wechselnde Prefixe bekommt und sich jedes Mal das Netz komplett neu durchkonfigurieren muss weil sich mal wieder das Prefix geändert hat. Ja ist ein harter Krampf. Sich aber sinnlose Lebenszeit opfern mit stundenlangen Support Calls weil was nicht geht was klar auf ISP Seite liegt man aber nicht Recht bekommt, weil ja eigenes Gerät macht es nicht besser.

Probleme mit IPv4 zumindest kann ich seit Jahr(zehnt)en nicht nachvollziehen. IP6 ist ein totaler Krampf, ja.

Cheers :)

So ganz versteh ich es noch nicht, wie ich in der OPNsense die zweite WAN-Schnittstelle reinkrieg. Wo genau kommt die zweite MAC in der OPNsense rein? Hab ja derzeit nur zwei Schnittstellen WAN und LAN.

Ich versteh nichtmal wo du ne 2. WAN Schnittstelle siehst oder hinbauen willst. Irgendwie macht das Setup für mich vor Augen ohne Netzplan gerade 0-Sinn *grübel*

Du meinst, es ist nicht offensichtlich, dass "meinedomain.lan" ein Platzhalter ist? 🤯

leider nicht :/ Darum dachte ich lieber, ich "korrigier" es mal bevor sich das jemand beim Drüberlesen ins Gehirn meißelt und denkt, es wäre ne gute Idee ".lan" als TLD zu nutzen, weil das jemand so geschrieben hatte. Ich weiß, es nervt, ich fühle es :)

Und um das Raten mal zu beginnen: Hatte die alten Installation eventuell bereits die Tuneables für neuere Intel-CPUs (Alder Lake oder Nxxx) installiert, die bei der frischen Installation fehlen und Probleme bereiten - insbesondere, wenn man nicht, wie empfohlen, auf ZFS, sondern auf UFS installiert?

Auch noch ein guter Punkt. Wurde UFS oder ZFS installiert. Alles relevant!

Verstehe das Drama in der Benennung trotzdem nicht. Im Gegensatz zu manch anderer Firewall ist ja bei den Sensen das Alias an vielen Stellen trotzdem einsehbar oder über Tooltips der Inhalt erkennbar. Selbst bei großen DC Setups hab ich jetzt noch keinen Kunden gehabt der Hände über dem Kopf schlagend sich über Limitationen von Alias oder Gruppen Interfaces beschwert hat. Vor allem wenn man schonmal bei Juniper und Co da saß und wegen einer Namens/IP Änderung einer MIB ALLES bei dem die MIB eingebaut ist rückbauen musste nur damit man das Ding löschen und neu anlegen kann. In den Sensen geht man hin und ändert das Alias oder die IP und fertig.

Namenskonventionen kann man viele finden oder sich bauen. Dass man da zwingend ein Prefix/Subnet in den Namen einbauen muss halte ich für vermessen. Das klingt eher nach "soll jemand bedienen der so gar keinen Bezug zur Firewall hat und sonst nichts versteht". Und wenn das der Punkt ist, ist es vllt. doch sinnvoller, wenn man die API nutzt.

Ansonsten bin ich echt überrascht sowas zu lesen. Noch nie vorgekommen in zig Jahren in denen wir *sensen machen.

Cheers :)

Hi,

ohne irgendwelche weiteren Details oder Logs oder Fehlermeldungen wäre das lediglich munteres Probleme-raten. Das wird vermutlich eher weniger hilfreiche Antworten produzieren.

Was heißt denn z.B. auch "bleiben hängen und werden nicht abgeschlossen"? Von der neuen SSD mal einen kompletten SMART Test oder Disk Check gemacht?

Ansonsten kann ich da leider wenig helfen ohne mehr Details.

Cheers :)

Was ist denn die eingestellte Domain der OPNsense? Da solltest du nicht .local benutzen sondern z.B. meinedomain.lan oder so etwas. Unter dieser Domain werden die Hostnamen Test1 und Test2 dann ins DNS eingetragen.

Patrick, sag doch sowas nicht, das bleibt ewig online ;) und dann heißt es wieder "das hat aber jemand gesagt ich soll das so machen". Bitte nicht irgendwelche ausgedachten TLDs für internen Betrieb nehmen.

Für zu DNS/Domains sollte man entweder:

* eine echte Domain/TLD verwenden - dann klappt auch der ganze Geraffel rund um DNS, Zertifikate und Co gut und ist problemlos zu automatisieren
* wenn schon eine "ausgedachte" Domain, dann bitte entweder mit der TLD/Endung:
  - .test       was explizit dafür gedacht ist zu testen/ein Labor zu sein
  - .home.arpa  was explizit reserviert wurde für interne/home Domains
  - .internal   was seit Anfang des Jahres jetzt auch offiziell ratifiziert wurde, dass das ein geschützter Domain TLD Suffix ist, der NICHT öffentlich reserviert werden darf.

Gut es gibt noch .example und Co, aber das ist nicht für halbwegs produktive Home/Lab/Spielumgebungen gedacht.

Du zitierst die Theorie der RFC und hast damit teils auch recht geht aber an dem vorbei was ich als Problem bezeichne.
In der sollte natürlich der DNS genommen werden der schneller antwortet. WILL ich aber nicht. Ich will das der Lancache die erste anfrage bekommt und sollte der nicht erreichbar sein soll die Anfrage an die OpnSense gehen.
Fakt ist das es mit ISC tadelos funktioniert hat die reihenfolge festzulegen!
Und das die Windows Clients das ALLE in meinem Netz auch so übernommen haben. DAS IST FAKT.
Es geht also nur mit KEA NICHT.

Das stimmt so leider nicht. Das mag jetzt aktuell genau für dein Windows der Fall sein. Die Auslieferung von 2 DNS Servern ist aber trotzdem Client-abhängig, wie die Auflösungs-Reihenfolge ist. Windows macht SEHR oft genau das was du denkst - es nimmt den ersten DNS und ansonten den zweiten wenn der zu lange braucht. Das ist aber Windows jetzt. Alte Windosen oder andere Systeme handeln NICHT zwingend so, denn was die tun liegt an der Art und dem Typ der DNS Konfig, die sie nutzen. Linux damals anders als Linux heute, SYSVINIT anders als SystemD und selbst bei heutigen Systemen kann man es anpassen oder anders einstellen bzw. ein Windows-Update und dann ist es plötzlich eben nicht mehr "nacheinander", sondern parallel wie es viel andere Systeme auch handeln. Du kannst dich eben genau NICHT darauf verlassen, dass die 2 DNSe in einer spezifischen Reihenfolge abgearbeitet werden, darum geht man auch immer davon aus, dass beide gleichberechtigt sind und entsprechend abgefragt werden können. Wenn man das nicht möchte, wird nur ein DNS gepusht - dann aber eben mit Risiko dass der dann tot sein kann, wenn was schief läuft.

Die einzige Art das gezielt und definiert zu 100% sicherzustellen ist es über DNS Loadbalancing zu realisieren, bei der der entsprechende LB dann prüft, welche DNSe verfügbar sind und diese dann in gezielter Reihenfolge befragt. Alles andere ist einfach ein "ja passt schon, kann klappen oder eben auch nicht". Was du als Fakt ansiehst, ist lediglich Zufall.

Cheers :)