Messages

Habe den Fehler inzwischen gefunden.
In der config.xml Datei gab es noch alte Einträge welche von einem alten VPN Server kamen.
Habe diese gelöscht und nun sind ach die Fehler weg.

Hallo ich erhalte beim Update der OPNsense immer folgende Meldungen:

Code Select Expand

***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.1.4 (amd64) at Wed Mar 25 19:06:34 CET 2026
[....]
>>> Invoking update script 'refresh.sh'
Migrated OPNsense\Dnsmasq\Dnsmasq from 1.0.8 to 1.0.9
Migrated OPNsense\Kea\KeaDdns from 0.0.0 to 1.0.0
[OPNsense\OpenVPN\OpenVPN:Overwrites.Overwrite.ccbd4c7e-2ad5-4543-a330-da4033cb25d9.servers] Option [2] not in list.{2}
Model OPNsense\OpenVPN\OpenVPN can't be saved, skip ( OPNsense\Base\ValidationException: [OPNsense\OpenVPN\OpenVPN:Overwrites.Overwrite.ccbd4c7e-2ad5-4543-a330-da4033cb25d9.servers] Option [2] not in list.{2}
 in /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php:822
Stack trace:
#0 /usr/local/opnsense/mvc/app/models/OPNsense/Base/BaseModel.php(947): OPNsense\Base\BaseModel->serializeToConfig()
#1 /usr/local/opnsense/mvc/script/run_migrations.php(69): OPNsense\Base\BaseModel->runMigrations()
#2 {main} )
*** OPNsense\OpenVPN\OpenVPN migration failed from 0.0.0 to 1.0.1, check log for details
Flushing all caches...done.
Writing firmware settings: FreeBSD OPNsense
Writing trust files...done.
[.....]
Flushing temporary package files... done
Starting web GUI...done.
***DONE***



Was sind das für Fehler?
Irgendwas mit OpenVPN kann ich herauslesen.

Daher habe ich gedacht ich schaue im FileSystem mal nach ob es dort irgendwas mit Openvpn und dem Instanznamen gibt.
Leider bin ich hier nicht fündig geworden.
Die Instanz 7f5c5a52-c2b4-4e95-9043-41efd883a950 ist meine aktuell einzige Instanz welche bei mir läuft.

Code Select Expand

root@OPNsense1:~ # find / |grep openvpn
/usr/local/include/openvpn-plugin.h
/usr/local/include/openvpn-msg.h
/usr/local/sbin/openvpn
/usr/local/sbin/openvpn-client
/usr/local/lib/openvpn
/usr/local/lib/openvpn/plugins
/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.so
/usr/local/lib/openvpn/plugins/openvpn-plugin-auth-pam.so
/usr/local/share/licenses/openvpn-2.6.19
/usr/local/share/licenses/openvpn-2.6.19/GPLv2
/usr/local/share/licenses/openvpn-2.6.19/LICENSE
/usr/local/share/licenses/openvpn-2.6.19/catalog.mk
/usr/local/share/man/man5/openvpn-examples.5.gz
/usr/local/share/man/man8/openvpn.8.gz
/usr/local/libexec/openvpn-client.down
/usr/local/libexec/openvpn-client.up
/usr/local/etc/rc.syshook.d/carp/20-openvpn
/usr/local/etc/rc.syshook.d/carp/20-openvpn-instances
/usr/local/etc/rc.syshook.d/start/90-openvpn
/usr/local/etc/inc/plugins.inc.d/openvpn.inc
/usr/local/etc/inc/plugins.inc.d/openvpn
/usr/local/etc/inc/plugins.inc.d/openvpn/dh.rfc7919
/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkdown
/usr/local/etc/inc/plugins.inc.d/openvpn/ovpn-linkup
/usr/local/etc/inc/plugins.inc.d/openvpn/tunnel_endpoint.php
/usr/local/etc/rc.d/openvpn
/usr/local/opnsense/scripts/openvpn
/usr/local/opnsense/scripts/openvpn/client_connect.php
/usr/local/opnsense/scripts/openvpn/client_disconnect.sh
/usr/local/opnsense/scripts/openvpn/kill_session.py
/usr/local/opnsense/scripts/openvpn/ovpn_event.py
/usr/local/opnsense/scripts/openvpn/ovpn_service_control.php
/usr/local/opnsense/scripts/openvpn/ovpn_status.py
/usr/local/opnsense/scripts/openvpn/tls_verify.php
/usr/local/opnsense/scripts/openvpn/user_pass_verify.php
/usr/local/opnsense/service/templates/OPNsense/Syslog/local/openvpn.conf
/usr/local/opnsense/service/conf/actions.d/actions_openvpn.conf
/var/mail/openvpn
/var/etc/openvpn
/var/etc/openvpn/server-7f5c5a52-c2b4-4e95-9043-41efd883a950.crl-verify
/var/etc/openvpn/instance-7f5c5a52-c2b4-4e95-9043-41efd883a950.conf
/var/etc/openvpn/instance-7f5c5a52-c2b4-4e95-9043-41efd883a950.stat
/var/etc/openvpn/instance-7f5c5a52-c2b4-4e95-9043-41efd883a950.sock
/var/etc/openvpn-csc
/var/etc/openvpn-csc/4
/var/db/rrd/openvpn-packets.rrd
/var/db/rrd/openvpn-traffic.rrd
/var/log/openvpn
/var/log/openvpn/latest.log
/var/log/openvpn/openvpn_20260325.log
/var/log/openvpn/openvpn_20260324.log
/var/lib/php/cache/_usr_local_opnsense_mvc_app_views_opnsense_openvpn_cso.volt.php


Viele Grüße

Du bist ein sehr fortgeschrittener Benutzer

Ja bei mir ist manches ein bisschen spezieller.
Betreue aktuell über 10 OPNsense Instanzen.
Das mit dem Quick meinte ich nur, um zu verdeutlichen dass es mir bewusst ist, dass die Regeln von "oben nach unten" abgearbeitet werden und dabei noch auf die Quick Einstellung geachtet werden soll.
Und ich meinte auch weniger die GUI (wobei ich daran noch gar nicht gedacht habe) sondern eher die Abarbeitung der Regeln selbst.

Ich habe beispielsweise eine alte CNC Maschine die unbedingt versucht Server X zu erreichen. Den Server gibt's nicht mehr, daher blockiere ich den Mist bevor er den Server quer im Netzwerk sucht mit einer IP die es nicht gibt. Umkonfigurieren der CNC Maschine ist leider nicht möglich.
Daher habe ich eine "Block" Regel hierfür angelegt welche relativ oft getriggert wird. Extra Regel deswegen, damit das auch nicht geloggt wird.
Wäre es nun vorteilhaft

•  wenn man diese Block Regel eher Quick macht und weiter oben ansetzt? (Somit müssen die Regeln kaum kontrolliert werden)
•  gar keine Regel anlegt und die Default Deny übernehmen lässt (Es müssten dann ja alle Regeln kontrolliert werden und wird zudem geloggt)
•  irgendwo mitten rein eine Block Regel ohne Quick anlegt. (Hier lässt sich ein bissel was sparen bis die Default Deny kommt. Je nach Struktur)

Wenn meine Logik her passt dann müsste die Firewall bei erstem Punkt weniger überprüfen ob das Paket auf eine der "Allow und quick" Regeln passen würde und man somit durch die Logische Anordnung der Regeln Rechenkapazität sparen kann.

Bei meinen 159 Regeln auf einer Xeon CPU wird das sicher nicht wirklich ins Gewicht fallen. Aber ich habe auch eine Firewall mit "nur" einer Celeron CPU und dafür etwas mehr Regeln. Hier wäre dies vermutlich schneller zu spüren sein.

Hallo

ich beschäftige mich aktuell mit den neune Regeln (Rules [new]).
Wie sinnvoll ist es, hier auf die Reihenfolge zu achten um die Firewall möglichst wenig zu belasten?
Aktuell habe ich "nur" 159 Regeln. Ich vermute, dass meine Hardware dies einfach wegdampft. 

Gibt es eine grobe Abschätzung ab wie vielen Regeln man dort ein Auge drauf werfen sollte? 1000? 10000? gar nicht?
Wie auch in den alten Regeln ist mir bewusst, dass bei Mischung von Actions die Reihenfolge beachtet werden muss. (Erst allgemein blocken und dann zulassen wird halt einfach nicht klappen wenn alles auf "Quick" eingestellt ist.)


Gibt es irgend eine Art von "Best Practice"? Oder einfach nur "hauptsache es klappt"?

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ß