Messages

Now I am totally perplexed. After your answer I did some more research and found the info that onifconsole only works when in /boot/loader.conf comconsole is set before vidconsole in the console parameter. So I changed it, also set /etc/ttys back to onifconsole and rebooted but after the reboot loader.conf was back to the old sequence, onifconsole was still set but now the serial console worked !?! I promise I tried dozens of times before and it definitely did not work with these very settings.

But since it now works with onifconsole I will not write a feature request. Whatever happend in my instace I don't think OPNsense is at fault.

Thanks for your responsiveness and sorry for the noise
Silke

For VMs one mostly starts with a VGA image which doesn't have serial enabled.

That's why I enabled it after installation. The standard VGA based console in Proxmox has a few disadvantages, e.g. it doesn't support cut & paste (at least not easily), that is why I used the serial based xterm.js console. As I said, it works, but only after I changed 'onifconsole' to 'on'. Is there any reason not to always set it to 'on' when enabled?
If there are good reasons it is fine with me since I found a solution, it is just one more thing to remember for a possible new install. (And if I miss it, a web search will hopefully lead me to this post to remind me)

Thanks for all your great work!
Silke

Then perhaps it is because I do not use a USB based serial console. My guess is that Proxmox emulates a physical serial console without USB and the original fix solved only part of the problem?
But since not everyone has problems connecting perhaps it is USB based after all and I just didn't know and have to select the USB checkbox. But then a hint in the documentation would be helpful: Either mention Proxmox explicitly or give a more general advice to try the checkbox in case of connection problems.

I really don't know what is happening, only that the change to "on" solved the problem and perhaps it helps others.

Was the solution removed in the meantime? I also had the problem that I could not connect via serial console and in /etc/ttys there was again "onifconsole" instead of "on". After changing it to "on" and a "kill -HUP 1" it worked as it should.

This is using xterm.js as Proxmox console, I don't know how it behaves with a physical console, I have everything virtualized.

Ich hatte bei meinen Versuchen in dem bei der Installation automatisch angelegten WAN_DHCP Gateway die IP der Fritzbox eingetragen. Ok, wahr wohl ein Fehler, kann passieren, sollte sich aber korrigieren lassen aber genau das gelang mir nicht. Ich konnte die IP nach Klick auf "Edit" scheinbar entfernen, doch nach "Save" war sie in der Gateway-Übersicht immer noch zu sehen. Auch ein Neustart half nicht.

Das sollte eigentlich so gehen, ansonsten wäre es ja ein Bug...? Ich meine mich aber zu erinnern, daß die Gateway-Einträge an mehreren Stellen angelegt werden und dann auch jeweils einmal gelöscht werden müssen.

Nun, eingetragen hatte ich die IP nur an einer Stelle und erwarte eigentlich auch, daß ich sie an derselben Stelle auch wieder löschen kann. Daß das nicht (vollständig) gelingt, halte ich tatsächlich für einen Bug, mag mich da aber mangels Kenntnis der Interna auch täuschen.

Doch die pass-Regel unter 3. hat weder mit "This Firewall" noch mit 192.168.99.0/24 als Destination funktioniert. Erst als ich als Destination 192.168.99.1/32 eingetragen habe, hat es geklappt.

Auch hier, wenn die Pass-Regel mit der konkreten Adresse funktioniert, steht sie ja an der richtigen Stelle und sollte doch dann eigentlich auch mit "This Firewall" und auch mit dem ganzen /24 Subnetz greifen....? Zuerst dachte ich, daß es evtl. an der falschen Auswahl "host vs. network" liegen könnte, aber es gibt ja nur "single host or network", da muß die /24 also eigentlich gehen, da die OPN box ja mitr im Netz ist, oder schottet die sich nochmal extra ab, daß nur eine explizite Adresse greift?

Ich hatte genau dieselbe Überlegung. Mich würde wirklich die Erklärung aus eingeweihtem Munde interessieren, warum nur die eine Variante funktioniert.

@silke61: Wie ich hier bereits erläuterte:

- Man muss die Prinzipien selbst verstehen, anderenfalls kann man die kleinen Ungenauigkeiten, die sich 100%ig einschleichen, nicht erkennen und auch nicht heilen.
- Dazu hilft es, die offiziellen Dokumentation zu lesen und die zugrunde liegenden Prinzipien zu verinnerlichen.
- Dann gibt es den READ ME FIRST-Artikel, der die häufigsten Fallen behandelt. Ich empfehle, ihn von vorne bis hinten zu lesen - irgendwann auf der Reise kommt man wohl an jedem Punkt einmal vorbei (ein paar hast Du ja schon durch).
- Darüber hinaus gibt es für bestimmte Spezialthemen, die immer wieder vorkommen, HOWTOs in der Tutorial-Sektion des Forums, darunter die zum Spezialthema Proxmox, Fritzbox oder IPv6 u.v.a.m.

Da arbeite ich mich nach und nach durch, habe als Anfängerin aber nicht gleich alles schon im Kopf.

- Jede Abweichung oder "Vergessen" eines Schritts oder wie hier die falsche Reihenfolge bei Firewall-Regeln würde die Funktion verhindern (übrigens: by design).

Die Reihenfolge war nicht falsch. Das Prinzip, wie die aufeinander folgen müssen habe ich bereits verstanden. Bei gleicher Reihenfolge hat allein die Änderung bei der "Destination" den Unterschied gemacht.

- Auch die "Entwickler" können das nicht für Dich vereinfachen, weil man nicht jede Verästelung voraussehen oder abbilden kann. Der Gedanke daran wird also "wishful thinking" bleiben.

Ich erwarte auch nicht, daß jede Verästelung vorausgesehen wird. Die von mir angesprochenen Punkte könnten aber meiner Meinung nach durchaus verbessert werden (Gateway-IP wirklich vollständig löschbar machen, korrekter "This Firewall"-Alias, Hinweis auf schon laufenden Dienst, der mit dem gerade aktivierten kollidiert, hier DHCP). Daß nicht immer alles schon gestern eingebaut ist, ist mir klar aber für die Zukunft erwägenswert halte ich solche Änderungen durchaus. Dann bleiben immer noch genügende mögliche Fallstricke über...

Zum Thema mögliche Freiheitsgrade: Nimm Dich selbst als Beispiel - Du hast Dir quasi den "GAU" ausgesucht, nämlich nicht nur OpnSense "pur", was an sich schon nicht so einfach ist, wie viele sich das vorstellen, nachdem sie ein Youtube-Video gesehen haben, sondern "router-behind-router" plus VLANs plus "Virtualisierung" (a: Haben wir schon über die Hardware gesprochen? b: Dass man "niemals nicht" UFS nimmt, steht übrigens auch im Proxmox-Guide. c: IPv6 läuft?). Jedes dieser Themen ist ein Minenfeld für sich.

Die Komplexität ist mir durchaus bewußt. Ich möchte mich da nach und nach durcharbeiten. Es gibt Gründe für meine Entscheidung für die einzelnen Minenfelder. OPNsense ist zwar sehr neu für mich, ich bilde mir aber ein, in 40 Jahren Arbeit mit Computern und Netzen ein wenig Erfahrung gesammelt zu haben, bin also kein absolutes Greenhorn.

Evtl. werde ich die für UFS revidieren, ich hatte gerade bei den aktuellen Preisen einfach Angst, mir die SSD durch ZFS auf ZFS zu schnell zu verschleißen. Der Vorteil der Virtualisierung ist ja gerade, daß ich es recht einfach ausprobieren kann (einfach zweite VM, wear genau beobachten, bei Problemen zuück zur ersten).

Die Entscheidung für "router hinter router" werde ich sicher revisieren, sobald ich mich sicher im Minenfeld bewegen kann. Ich plane einen sanften Umstieg, indem ich ein System nach dem anderen aus dem alten Fritzbox-Netz hinter die Firewall schiebe. Wenn alles migriert ist, soll OPNsense direkt hinter das Glasfaser-Modem kommen.

Der erfahrene Handwerker weiß: Eine zöllige Schraube passt nicht in eine metrische Mutter.

Ich denke, OPNsense paßt sehr gut zu meiner Anforderung, d.h. das Maßsystem sollte stimmen. Was mir noch fehlt ist auf den ersten Blick zu erkennen, ob es sich um eine 1¼-zöllige oder um eine 1½-zöllige Schraube handelt.

Zusammengefasst: NICHTS an OpnSense ist wirklich einfach. Sorry, aber isso...

Deshalb ja mein Post. Damit andere, die ähnliche Probleme haben, es ein ganz, ganz klein wenig einfacher haben.

Ich verstehe allerdings nicht wirklich, was du mit deinen - aus meiner Sicht maximal umständlichen - Standard-Regeln 1. und 2. erreichen willst.

1. Von jedem VLAN ins Internet und 2. In kein anderes VLAN (die haben alle private Adressen, fallen also unter rfc1918). Leider kenne ich keine Definition, die sagt "192.168.0.0/16 ausser mein aktuelles 192.168.99.0/24". Wenn ich die nicht voneinander trenne, brauche ich keine VLANs und alle VLANs einzeln als Block-Regel zu definieren ist fehleranfällig, da man immer daran denken muß, die Block-Regel zu erweitern, wenn man ein neues VLAN einrichtet. So wie es jetzt ist, ist der Zugang zum Internet erlaubt aber der Zugang zu allen anderen VLANs (auch zukünftigen) geblockt, solange nicht ausdrücklich durch zus. Regeln erlaubt.
Ich wüßte nicht, wie ich dieses Ziel durch eine weniger "umständliche" Regel erreichen könnte.

Die OpnSense stellt bei der Installation die Regeln automatisch so ein, das du aus jedem lokalen Netz ohne weiteres Zutun ins Internet und natürlich in jedes lokale Netz kommst. 

Genau das ist natürlich nicht gewollt. Sonst brauche ich keine VLANs. Außerdem stimmt das für VLANs nicht. Ich brauche erst die "any"-Regel, sonst geht gar nichts. Mit der Regel komme ich ins Internet aber eben auch dahin, wo ich nicht soll. Deshalb die 2. Regel.

Was das Blocken der Zugriffe zwischen den (V)Lans und dem Internet betrifft, musst du erst mal festlegen WAS du erreichen willst.
1. Entweder Zugang für jedes LAN nach irgendwohin zu und nur erlaubte Protokolle etc. einzeln aufmachen. Dann ist eine eingehende Sperre nach Any auf jeden Lan der Ansatz.
2. Oder du erlaubst allen LANS den ungehinderten Zugriff ins Internet, sperrst aber dafür jedes einzelne LAN mittels Sperr-Regel ausgehend, damit die Lans voneinander getrennt sind.

Das wäre mir nun wieder zu umständlich. Mit meiner Regel habe ich erst einmal alles sicher und gleichzeitig Internet und muß nicht jedes VLAN einzeln blocken -- immer mit der Gefahr, eines zu vergessen.

Und wenn du "This Firewall" erreichen willst, musst du selbstverständlich die IP-Adresse des Interfaces verwenden, nicht das Netz selbst. Du erreichst doch jeden anderen Host auch mit seiner IP, nicht mit der seines Subnetzes. Und bei allen FW-Regeln kannst du als Quelle oder Ziel natürlich ein Netz oder einen Host angeben. Die Regel greift dann aber natürlich auch völlig unterschiedlich.

"This Firewall" sollte ein Alias für die Interface-Adresse sein und damit genau denselben Zweck erfüllen aber dabei sprechend sein. Tut es nur nicht.
Die Interface-Adresse ist Teil des Netzes, das ich in dem anderen Versuch angegeben habe und selbstverständlich kann ich im Prinzip bei pass-Regeln auch ein Netz als Destination angeben und wenn dieses die geünschte Interface-Adresse enthält, sollte es nach den Gesetzen der Logik auch den Zugriff erlauben, tut es aber nicht. Dafür gibt es bestimmt irgendwelche Gründe, die aber zumindest dem Anfänger nicht direkt einleuchten.

Noch zur Einwahl per OPNsense: ist durchaus geplant, solange ich aber solche schwer verständlichen Details noch nicht verinnerlicht habe, ist es mir schlicht zu risikoreich, mir durch Fehlkonfiguration selbst ins Knie zu schießen. Aktuell habe ich immer noch das alte Fritzbox-Netz, über das ich im Zweifel ins Internet komme.

Ich habe jetzt einige Tage daran gesessen, eine wie ich finde recht einfache und Grundlegende Installation von OPNsense hinzubekommen. Die Installation ist auf Proxmox virtualisiert, doch soweit ich es beurteilen kann, hatte keines der Probleme, auf die ich gestoßen bin mit der Virtualisierung zu tun. Sie machte es aber einfacher, einen neuen Versuch zu starten.

Was ich erreichen wollte:
- Installation hinter einer Fritzbox
- LAN-seitig zunächst ein VLAN
- DHCP für Rechner im VLAN
- Zugang vom VLAN ins Internet
- Abschottung gegen andere VLANs
- da das erste VLAN als Management-VLAN gedacht ist, Zugang zur OPNsense-Oberfläche

Diese Ziele schienen mir plausibel und sollten hoffentlich nicht allzu schwer erreichbar sein. Plan ist nach wie vor, zunächst weitere VLANs einzurichten und wenn ich mich sicherer in der Administration und Konfiguration fühle, die Fritzbox später auch durch OPNsense zu ersetzen.
Doch erst einmal wollte ich die oben beschriebene Grundkonfiguration hinbekommen, was sich schon als schwierig genug herausstellte. Hier die konkreten Probleme, die mir zu schaffen gemacht haben.

- Installation der aktuellen Version mit UFS.
Gab Fehler bei der Einrichtung der Partition. Lösung: ältere Version installieren und dann Update. Sollte kein Problem mehr sein, sobald es ein aktualisiertes Installations-Image gibt.

- Für mich unerklärliche Blockierung des Fritzbox-Netzes
Bei meinem ersten Versuch habe ich wohl irgendetwas falsch gemacht doch selbst mit umfangreichsten Checklisten aus dem Netz und ChatGPT konnte ich es nicht beheben. Phänomen: Ich kam aus dem VLAN ins Internet aber nicht ins Fritzbox-Netz, nicht einmal auf die WAN-IP von OPNsense, egal was ich alles über Firewall-Regeln erlaubt habe. Laut ChatGPT vermutliche Ursache: Ich hatte bei meinen Versuchen in dem bei der Installation automatisch angelegten WAN_DHCP Gateway die IP der Fritzbox eingetragen. Ok, wahr wohl ein Fehler, kann passieren, sollte sich aber korrigieren lassen aber genau das gelang mir nicht. Ich konnte die IP nach Klick auf "Edit" scheinbar entfernen, doch nach "Save" war sie in der Gateway-Übersicht immer noch zu sehen. Auch ein Neustart half nicht.

Als es mir nach zwei Tagen mit allem was ich an Fix-Versuchen finden konnte immer noch nicht gelang die IP aus dem Gateway zu entfernen oder sonstwie Zugriff aufs Fritzbox-Netz 192.168.178.0/24 zu bekommen habe ich einen neuen Versuch gestartet. Alte VM heruntergefahren, neue mit identischer Konfiguration erstellt. Bei dieser habe ich natürlich die o.g. Probleme gleich vermieden: Sofort mit älterer Version gestartet und Gateway in Ruhe gelassen. Daraufhin war die Installation auf UFS und der Zugriff ins Fritzbox-Netz auch kein Problem mehr. Doch ich war noch nicht am Ziel...

- kein DHCP
Ich habe Kea DHCP mit einem Pool für das VLAN eingerichtet, bekam aber keine IP in meinem Client. Manuelle IP-Vergabe auf dem Client hat funktioniert. Als Ursache stellte sich heraus, daß ich (vermutlich beim Durchgehen des Wizard) den dnsmasq DHCP-Server gestartet haben muß. Da konnte ich den Kea DHCP so korrekt konfigurieren wie ich wollte, er startete einfach nicht. Hat mich einige Zeit gekostet, bis ich herausgefunden hatte, daß es an dem schon laufenden dnsmasq lag. Hier hätte ich mir beim enablen des zweiten DHCP-Servers eine Warnung gewünscht oder eine automatische Deaktivierung des anderen, was auch immer jedenfalls irgendwas, was mich nicht einfach in die Falle laufen läßt. Nach Deaktivierung des anderen funktionierte DHCP dann problemlos.

- Kein Zugriff auf die Admin-Oberfläche nach Erstellung der "Standard"-Regeln
Nachdem soweit alles lief, wollte ich für das VLAN-Interface die Regeln erstellen, die ich für grundlegend halte (von unten nach oben):
1. any-Regel, um ins Internet zu kommen
2. rfc1918-Regel (block), um die anzulegenden weiteren VLANs abzuschotten
3. pass-Regel vom VLAN-Netz auf "This Firewall"
(4. pass-Regel für das Fritz-Netz war unproblematisch deshalb in Klammern)

Was ich wirklich nervig fand war, daß 3. so nicht funktioniert hat. Erst einmal war ich schon irritiert, daß innerhalb desselben Netzes (vom Client auf 192.168.99.5 zur OPNsense auf 192.168.99.1) überhaupt die block-Regel greift aber ok. Doch die pass-Regel unter 3. hat weder mit "This Firewall" noch mit 192.168.99.0/24 als Destination funktioniert. Erst als ich als Destination 192.168.99.1/32 eingetragen habe, hat es geklappt. Vielleicht bin ich ja einfach nur zu unwissend aber ich halte das für einen Bug. Wenn ich eine pass-Regel zu "This Firewall" erstelle, möchte ich diese Firewall auch erreichen können.

Wie gesagt, am Ende habe ich alles lösen können, soweit so gut aber da es mich doch sehr viel Zeit gekostet hat, wollte ich es aufschreiben, damit andere, die den Beitrag finden, die Fallstricke gleich umschiffen können. Es geht mir ausdrücklich nicht um Bashing! Mir ist bewußt, daß eine so leistungsfähige Firewall ein komplexes Produkt ist, das erst einmal beherrscht werden will und eine Lernkurve hat. Die Probleme, die mich gebissen haben, hätten meiner Meinung nach alle von der Software vermieden werden können (neues Install-Image, funktionierendes Löschen der Gateway-IP, Warnung bei doppeltem DHCP und funktionierendem "This Firewall"), aber klar, das muß auch erst einmal jemand machen und gerade bei einem Open Source Projekt gibt es vielleicht andere Prioritäten aber vielleicht erbarmt sich ja ein Entwickler und macht es künftigen Nutzern etwas leichter ;-)

Im Nachhinein kann ich das auch nachvollziehen. Ich hatte mir halt vorgestellt, daß ich nur die Firewall überwinden muß, also ins WAN kommen muß und der Rest dann schon irgendwie weiter geht. War halt eine falsche Vorstellung, über die man stolpern kann. Ist alles noch sehr neu für mich. Wie gesagt, bisher hatte ich an Firewall nur das, was die Fritzbox schon mitbringt. Dahinter war alles offen. Das zu ändern braucht neben neuer Hard- und Software auch einen gewissen Lernaufwand und da wühle ich mich gerade Schritt für Schritt durch.

Wie so oft: Habe es kurz nach meinem Post hinbekommen. Ich hatte die Firewall-Regel aus dem VLAN-Netz ins Internet falsch. Ich hatte als Destination das WAN-Netz und damit hat es nicht geklappt. Ich konnte mir nicht vorstellen, daß es "any" sein muß, was ja im Rahmen einer Firewall nicht sonderlich sinnvoll ist, schlißlich will man ja nicht alles offen haben. Lösung war dann eine zusätzliche Block-Regel für die anderen VLANs. Macht die Sache nicht unbedingt übersichtlicher aber es funktioniert erst einmal.

Ich möchte sanft von einem alten unmanaged reinen Fritzbox-Netz zu einem neuen Netz kommen, das über VLANs segmentiert ist. Den Zugriff soll OPNsense regeln.
Aus verschiedenen Gründen möchte ich OPNsense unter Proxmox virtualisieren.
Der neue managed Switch ist so konfiguriert: untagged Ports (VLAN 1) für Uplink zur Fritzbox, unmanged Legacy-Switch, primärer Proxmox Port=OPNsense WAN-Port. Für die VLANs ist ein Port als Trunk mit den VLANs 10, 20, 30 und 99 eingerichtet. Dieser Port ist mit einer zweiten NIC des Proxmox-Rechners verbunden (für OPNsense LAN/VLAN).

Also Proxmox installiert, zwei bridges für die zwei NICs eingerichtet, der zweite davon vlan-aware, OPNsense mit zwei NICs, je eine für die beiden Proxmox-bridges. In OPNsense VLAN-Devices und Interfaces definiert, um mit VLAN 99 besser experimentieren zu können für dessen Netz auch DHCP eingerichtet.

Nun Test-VM mit einer NIC, verbunden mit der vlan-aware bridge und VLAN tag 99. VM bekommt IP, kann auch die OPNsense pingen, kommt aber nicht weiter, weder auf den Proxmox host noch auf die Fritzbox oder ins Internet. NAT habe ich sowohl mit "automatsch" als auch mit "hybrid" und zus. Regel, die alles erlaubt versucht. Blockierung für private Netze ist ausgeschaltet. Langsam gehen mir die Ideen aus, was da noch fehlen könnte.

Hat jemand eine Idee? Hier zur Veranschaulichung noch meine Proxmox /etc/network/interfaces:

Code Select Expand

auto lo
iface lo inet loopback

iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.178.205/24
    gateway 192.168.178.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0

iface enp2s0 inet manual

auto vmbr1
iface vmbr1 inet manual
    bridge-ports enp2s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10 20 30 99


Thanks for all the anwers, I solved it by installing an older version and doing updates to get to the current version.

Since I have ZFS as my Proxmox file system, I wanted to use UFS for OPNsense. But no matter what I try I always get an error: "Partition destroy failed" during installation. I tried with BIOS and UEFI (where I had to disable secure boot). This is with OPNsense 26.1.2 on a fully patched Proxmox.
A test with OPNsense 25.7 which I still had around worked but I would like to have the most recent version, if possible.

Any ideas what is going wrong and how I can fix it?

Thanks
Silke