Messages

Hallo

auch wenn es evtl. nur bedingt direkt mit der OPNsense zu tun hat hoffe ich, das mir jemand helfen kann.

Ich habe hier folgende Konstellation:
Ich habe 2 Proxmox Hypervisoren. Auf jedem Hypervisor laufen 2 OPNsense VMs.
Hypervisor PMFW1: 

• FW1
• FWInternBackup

Hypervisor PMFW2:

• FW2
• FWIntern

Die FW1 ist mit der FW2 eine Hochverfügbare Firewall.
Die FWIntern mit der FWInternBackup.

Eine kleine Gemeinsamkeit haben alle OPNsense. Sie habe alle im VLAN1 eine Netzwerkverbindung. VLAN 1 ist das allgemeine VLAN in welchem Server (aber auch Clients, Drucker etc.) laufen. 
Ansonsten sind sie in unterschiedlichen Netzwerkbereichen / VLANs / Broadcast Domänen unterwegs.

Ich habe auf allen OPNsense Maschinen CARP am laufen. Durch CARP werden die Netzwerkkarten in den Promiscuous Mode versetzt. (Nachher noch wichtig?) 
Auf der FW1 läuft OpenVPN als Server.
Die jeweiligen CARP IDs (aktuell 1-22) vergebe ich absolut einzigartig. So kann ich mir sicher sein, dass es auch wirklich keine doppelten MAC-Adressen gibt.

Nun haben wir folgendes Problem:
Wenn man im OpenVPN Netz unterwegs ist und Telefonate via Softphone führen möchte so muss man vom VPN Netzwerk (10.20.253.0/24) zum Server Netzwerk (10.20.16.0/21) bzw. zum Server 10.20.20.52.

Die Pakete werden erstmal sauber geroutet eine Verbindung kommt zu Stande und es sieht alles gut aus.
Nach einer Bestimmten Zeit X (dies kann eine Minute oder aber auch über 40 Minuten betragen) bricht das Telefonat ab.
Wenn ich die FWInternBackup ausschalte kann ich so lange ich möchte telefonieren.

Ich habe nun mit Wireshark das ganze soweit eingegrenzt, dass es daran liegt, dass die FWInternBackup irgendwann ein ICMP "Time-to-live exceeded" sendet und daher dann das Telefon abbricht. Ist vielleicht etwas unglücklich in der Software umgesetzt aber leider nicht änderbar.
In dem ICMP Paket steht, dass es von Server zu Client gehen sollte.
Wenn ich die Details von dem Paket anschaue, dann sehe ich, dass das Paket aber auf dem Client angekommen ist.

Nun wundert es mich, dass dieses ICMP Paket überhaupt existiert.

Meine aktuelle Vermutung ist, dass die FWInternBackup das Paket dank Promiscuous Mode mitbekommt, denkt es wäre was für die FWInternBackup, es versucht zuzustellen (indem sie das Paket erst an ein anderes Gateway 10.46.23.2 und dieses dann an die FW1 weiterleitet) , es sich dann wieder im Proxmox Host "im Kreis dreht" und dann irgendwann der TTL zuschlägt und die FWInternBackup den Client via ICMP informiert.


Jemand eine Idee wie man das verhindern kann?

Alles was mir einfällt wäre mit mehr Hardware zu schießen indem ich jeder OPNsense eigene Hardware kaufe. Hier bin ich mir jedoch nicht 100% sicher ob dies dann wirklich hilft wegen Promiscuous Mode wenn die dann einfach an einem physikalischem Switch hängen statt einem virtuellen?

Danke schonmals und Viele Grüße

Hallo

ich habe ein Script geschrieben mit welchem ich auf die API für die Firewall Aliase zugreife.

Das ganze funktioniert auch einwandfrei wenn ich einen Nutzer habe welcher die Berechtigung "All pages" hat.
Meinem Verständnis nach wäre würden die Berechtigungen 

• Firewall: Alias: Edit
• Firewall: Aliases

für meinen Zweck ausreichend.

Ich nutze die URLs:

• /api/firewall/alias/searchItem
• /api/firewall/alias/setItem
• /api/firewall/alias/reconfigure
• /api/firewall/alias/addItem

Weiß jemand warum dem so ist?
Ist die API nur für "All pages" Benutzer zugelassen?


Danke und Gruß

[OPNsense Business Edition:]

Danke erstmal für alle Antworten und Vorschläge.

OPNsense Business Edition:
Ja wäre für einen (Arbeits-)Standort die Möglichkeit. Da wäre auch das Thema Geld (600€) nicht das große Problem.
Jedoch habe ich die gleiche Konstellation auch bei 2 weiteren Standorten welche kein Geld machen (Non-Profit) oder haben (ich zuhause  ::) [size=78%]).[/size]
Daher fliegt das leider raus.


XLMRPC Sync über mehrere Maschinen:
Wie bereits festgestellt, geht dies leider nur mit einem Peer. Nicht mehreren.
Zudem wird auch nur nach unten synchronisiert.


Sync Kette aufbauen:
Theoretisch technisch möglich, jedoch habe ich hier 2 Gedenkpunkte:
Es wird nur "nach unten" synchronisiert. Wenn sich auf Knoten C etwas ändert ist dies nicht mit A synchron.
Aus Sicherheitsgründen möchte ich zudem nicht, dass die eine Master OPNsense direkt auf die andere Master OPNsense zugreift mit Benutzerdaten etc.




Somit werde ich mich wohl in einer freien Minute irgend ein Skript basteln welches dafür sorgt das dies so passiert wie ich möchte.
Immerhin kann man keine Aliase mehr löschen welche in Verwendung sind. Das war ganz früher mal anders  :)

Hallo zusammen


ich habe hier insgesamt 4 OPNsense am laufen.
- FW Extern Master
- FW Extern Slave
- FW Intern Master
- FW Intern Slave


Ein Master bildet mit einem Slave ein "Cluster".


Nun möchte ich gerne bei beiden Mastern die Aliase vereinigen.


Meine einzige Idee bisher ist dies über ein externes Script und über die API abzubilden.

Hat jemand noch eine andere Idee?
Oder stand evtl. jemand bereits vor dem gleichen Problem und hat schon eine Lösung?


Alles zusammen zu einem Cluster zu legen ist leider keine Option.


Danke und Gruß

Hallo Shanks


vielleicht schreibst du eher mal was du genau vorhast...

5 VPN Server

Wirklich 5 Verschiedene Server? Oder nur ein VPN Server mit 5 verschiedenen IPs / Interfaces?

alle Lan-Geräte den selben VPN Server

Warum sollen sich LAN-Geräte auf einen VPN Server (der auf der OPNsense?) verbinden?


Gruß

@ Ronny1978

Oh an die Aliase habe ich gar nicht mehr gedacht. Jedoch sind diese bei mir bereits im Einsatz. Und helfen bereits ein wenig bei der Übersichtlichkeit. Was gruppiert werden konnte ist gruppiert.

90 Regeln pro Interface?
Relativ easy in meinem Umfeld. Habe die OPNsense im Geschäftseinsatz und wie bereits geschrieben nicht gerade wenig Netze zu verwalten.
Früher (vor einem Jahr) hatten wir nur einen Layer 3 Switch im Einsatz welcher einfach wie ein offenes Scheunentor geroutet hat. Ganz ohne Regelwerk.
Vor einem Jahr gab es dann mal einen Pentest und natürlich wird hier gerne mal das Thema Netzwerksegmentierung angesprochen. Also versucht man ein paar Gruppen zu finden welche man Segmentieren kann.
-> Clients, Server, Drucker, VoIP, DMZ, Gast, Elektriker, Lager, Management, PR1 (Produktionsnetzwerk), PR2, PR3 bis aktuell geplant hin zu PR15.
Dann nun noch genug einzelne Mitarbeiter bzw. Computer welche eben nicht einfach überall hin sollten aus Sicht der Sicherheit. Da macht es mal ganz schnell schwapp.
Alleine zwischen Clients und Server habe ich aktuell 55 Regeln. Und diese sind oftmals noch nicht mal mit Ports bestückt. Sondern nur "der darf auf den Server mit allen Ports".
Beispiel: Alle Elektiker Laptops dürfen zu den PRxx Netzwerken. (Die Verkaufsabteilung benötigt beispielsweise keinen Zugriff auf die Produktionsmaschinen)
Zudem ein paar allgemeine Regeln wie "Clients dürfen zu DomänenController mit entsprechenden Ports (als Alias)" um das alles zu kurz wie möglich zu halten.

@ mooh:
Das habe ich tatsächlich auch mal getestet...
Jedoch bringt dies auch nicht den erhofften Vorteil da es hier viel zu individuell ist.

Hallo zusammen

ich verwalte inzwischen ein Netzwerk mit 30+ Netzbereichen. Clients, Server, Drucker, mehrere Produktionsbereiche und viele kleinere Bereiche.

So langsam bin ich an meiner Grenze der Übersichtlichkeit angekommen. Und das bei ~90 Regeln pro Interface.
Ich hatte mal eine Firewall im Einsatz (weiß den Namen leider nicht mehr) bei welcher ich aufklappbare "Bereiche" (mit freier Namenswahl) machen konnte.
So gab es einen Bereich mit "Clients -> Server".
Einen weiteren Bereich mit "Clients -> Drucker" und so weiter...

Wie macht ihr das wenn ihr bei viele Regeln die Übersicht behalten möchtet? Über kurz oder lang vermute ich, dass ich bei mindestens 300+ Regeln in manchen Interfaces landen werde.
Nutzt ihr die Kategorisierung? Nach was Kategorisiert ihr?

Was ich aktuell mache:
Ich "denke" mir auch solche Blöcke und sortiere die Regeln entsprechend.
So geht erst ein Block mit "Clients zu Server" los. Dann "Clients zu Drucker" etc....
Diesen Block zu erkennen ist meistens relativ schwer und manchmal eine Kunst für sich.
Vor allem wenn man wie ich oder Kollegen nicht täglich damit arbeiten.


Daher die Frage ob es hier andere Ideen gibt auf die ich bisher nicht gekommen bin :)

Danke!

Hallo


wie sieht es eigentlich aus wenn man mehrere Wireguard Site-to-Side Verbindungen aufbauen möchte?
Reicht hier eine Instanz mit mehreren Peers?
Oder muss man für jede Verbindung eine extra Instanz anlegen?


Gibt es hierfür ein Best Practice?


Danke und Gruß

Hallo zusammen


ich habe hier ein Cluster laufen bei welchem die Master FW sporadisch (alle Tage mal) kein Routing mehr zulässt.
Internet etc. hinter der FW ist alles stabil. Habe sogar 2 WAN Leitungen dran.


Ich selbst komme auf die Weboberfläche, sehe keine ungewöhnlichen Ausschläge oder sonstiges.
Ich schalte dann das CARP händisch auf die Backup um. (Temp. Disable CARP)
Danach funktioniert wieder alles wie gewohnt. Habe testweise auch schon tagelang die Backup FW als CARP Master laufen lassen.
Hier gab es keine Ausfälle.

Hat jemand eine Idee woran das liegen könnte?


Danke und Gruß

Hallo

ich habe ein Hochverfügbares FW Cluster bei welchem eine WAN Schnittstelle via PPPoE  angeschlossen ist.
Dies funktioniert auch problemlos. Ich kann händisch aussuchen welche FW sich damit verbinden soll.
Nun gibt es unter "System: High Availability: Settings" ja die Einstellung mit "Disconnect dialup interfacces".
Leider funktioniert dies bei mir nicht anständig.

Ich habe bei beiden Firewalls unter Interfaces: [Telekom] die PPPoE Daten "Username" und "Password" eingegeben. Kann die Verbindung über "Interfaces: Overview" auch entsprechend herstellen und trennen.

Im Hilfetext von "Disconnect dialup interfacces" steht:
When this device is configured as CARP backup it will disconnect all PPP type interfaces and try to reconnect them when becoming master again.

Nur welches CARP ist hier gemeint? Muss ich für die Telekom IP ein weiteres CARP anlegen?
Dann muss ich (vermutlich) in den Interface Einstellungen einstellen, dass keine automatische IP über PPPoE gezogen wird? Falls ja: Wie mache ich das?

Auf den FWs laufen bereits 5 Weitere CARP Interfaces. Natürlich auf anderen Netzwerkadaptern und keines auf dem Telekom Interface.

Alle sind auf Master Status. Trotz allem ist die Leitung immer auf der Backup FW aktiv.
Ich glaube die Backup FW macht keinen Disconnect wenn alle CARP Interface auf "Backup" stehen.


Vielleicht bekomme ich hier den passenden Tipp damit es so funktioniert wie es sollte.

Danke schonmals

Hallo


mir ist aufgefallen, dass ich keinerlei CARP Pakete im Live Log der Firewall entdecke.
Wenn ich ein Packet Capture auf dem (beispielsweise) Interface opt5 durchführe so sehe ich jede Sekunde einen CARP/VRRP Eintrag:



x.y.90.11 ist die Firewall selbst


Wenn ich allerdings über die Live Log gehe sehe ich nur tcp,udp,icmp,esp. Mehr sind mir aktuell nicht aufgefallen.


Wird dies irgendwo vorher bereits herausgefiltert?


Danke und Gruß

Hallo

Ich habe auf GitHub den aufbau der Filterlogs entdeckt.
ports/opnsense/filterlog/files/description.txt at master · opnsense/ports (github.com)

Hier gibt es ja das Feld "label". Sollte dies dann der Regelname sein?
Wenn ich in meine Log Datei schaue so steht dort leider nichts drin.

Beispielzeile:

Code Select Expand

<134>1 2023-08-31T23:59:59+02:00 OPNsense1.domain.intern filterlog 44229 - [meta sequenceId="732913"] 73,,,fae559338f65e11c53669fc3642c93c2,vtnet2,match,pass,out,4,0x0,,63,2556,0,DF,17,udp,64,10.10.10.219,10.10.20.108,54268,53,44

Unter Label würde hier ja "fae559338f65e11c53669fc3642c93c2" stehen. Gibt es alternativ eine Möglichkeit dies "aufzulösen"?

Was genau habe ich vor:
Ich würde die Logs gerne in eine SQL Datenbank oder ähnliches werfen um diese etwas besser auswerten zu können.
Das Projekt von Frabianfrz kenne ich bereits. Bringt mich leider auch nicht so ganz an mein Ziel.
Excel macht ja nur bis 1 Mio. Zeilen mit. Da bin ich locker drüber.




Gibt es ansonsten ganz alternativ ein Programm dem ich die Filter.log füttere und diese ausgewertet zurückbekomme oder so?

Minimal Langsamer als bei 23.1.x aber vollkommen akzeptabel.

Oh hab das Update auf 23.7.2 gar nicht mitbekommen.

Damit geht's nun um einiges schneller.


Definition von ewig:
Länger als mein Geduldsfaden... Der ist leider ziemlich kurz.
Musste über 30-40 Sekunden warten bis die Liste aufgebaut war bei 56 aktiven Clients.


Danke und Gruß

Hallo


ist sonst schon jemandem aufgefallen, dass seit die DHCP Leases mit dem neuen Interface angezeigt werden ewig bis gar nicht laden?