Erfahrungen bei ersten Gehversuchen

[silke61]

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 ;-)

[kruemelmonster]

Ich bin selbst auch nicht der große Crack, was die OpnSense betrifft. Ich verfahre nach dem Prinzip, minimaler Aufwand zur Erreichung meines gewünschten Ziels.  Zur Virtualisierung kann ich nichts beitragen. Das mache ich aus Prinzip nicht bei wichtigen Basisdiensten. Und Internet ist für mich ein wichtiger Basisdienst.

Was hast du für eine Fritte? Bei Kabel ist es klar, geht nicht anders. Ansonsten ersetze die Fritte durch ein Modem und lass OpnSense die pppoe-Einwahl machen. Funktioniert tadellos.

Ich verstehe allerdings nicht wirklich, was du mit deinen - aus meiner Sicht maximal umständlichen - Standard-Regeln 1. und 2. erreichen willst. 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. 
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.

Ersteres ist mir persönlich für Zuhause schlicht zu aufwendig. Da bin ich alle Nase lang am Nachjustieren der FW-Regeln weil irgend etwas nicht geht. Auch nicht ins Internet!
Also Letzteres. Da brauche ich nur noch auf jedem LAN die notwendigen Regeln ausgehend erstellen, für das was gehen soll. Ist erheblich einfacher zu überschauen und vor allem wesentlich weniger fehleranfällig.

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.

[silke61]

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.

[Monviech (Cedrik)]

Als Tangente ich bin extra von eigenem Modem auf Fritzbox zurück umgestiegen weil ich zu viele Probleme mit Providersupport im Fehlerfall hatte. Mit einem üblichem Endgerät als Terminierung hat man es grundsätzlich leichter.

[bimbar]

This Firewall hat bei mir immer funktioniert - vielleicht mal mit pfctl -s auf der CLI nachschauen, was da genau wie konfiguriert wurde.

[Tuxtom007]

Was hast du für eine Fritte? Bei Kabel ist es klar, geht nicht anders. Ansonsten ersetze die Fritte durch ein Modem und lass OpnSense die pppoe-Einwahl machen. Funktioniert tadellos.

Geht auch beim Kabel-Internet, ich nutze auch ein reines Kabelmodem vor der OPNSense ( Arris ), bringt es natürlich nur, wenn man keine anderen Dienste der Fritzbox nutzen will, wie z.b. Telefonie

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,

Diese beiden Regeln sind bei mir in jedem VLAN, die erste erlaubt den Zugang zum Internet zu IP, die NICHT in dem Alias vermekrt sind, die zweite blockt dann alles.
Im Alias stehen die IP-Ranges der privaten Netze, also
172.16.0.0/12
192.168.0.0/16
10.0.0.0/8

Alle weiteren Erlaubt Regel kommen dann davor, also z.b. Zugang für Dienste in anderen VLAN.

[mooh]

Ich bin immer wieder erstaunt, in welche Probleme man laufen kann, denn nach meiner Erfahrung macht eine OPNsense nach der Grundinstallation erstmal genau das, was man braucht, um mit ihr zu arbeiten, sprich WAN per DHCP und ein LAN mit DHCP und einer "allow all" Regel.

Wenn man weitere Netzwerke hinzufügt, egal ob LAN oder VLAN, muss man alle(!) Regeln selbst schreiben, weil per Voreinstellung nichts erlaubt ist. Dabei kommt es natürlich auf die Reihenfolge an und darauf, ob es "Quick" Regeln sind oder nicht.. Wenn also Hilfe zu Regeln gewünscht wird, ist ein Screenshot immer sehr hilfreich.

Auch sehr hilfreich ist es, Regeln erstmal mit Logging einzurichten, damit man im Firewall: Logging: Live View den Effekt sehen kann.

[Patrick M. Hausen]

Kleine Falle im "Router hinter Router" Szenario: "block private networks" auf WAN und die Tatsache, dass "reply-to" per default an ist. Firewall: Settings: Advanced, dort "disable reply-to" aktivieren, wenn WAN ein Broadcastnetzwerk (aka Ethernet) ist.

Außerdem helfen Uwes wirklich großartige Einführungsbeiträge:

https://forum.opnsense.org/index.php?topic=42985.0
https://forum.opnsense.org/index.php?topic=39556.0

[viragomann]

- Installation der aktuellen Version mit UFS.

Warum will man das heute noch? Es gibt dafür keinen Grund, auch nicht in einer VM.

Laut ChatGPT vermutliche Ursache: Ich hatte bei meinen Versuchen in dem bei der Installation automatisch angelegten WAN_DHCP Gateway die IP der Fritzbox eingetragen.

Ist das Interface als DHCP-Client konfiguriert, bekommt es die Gateway-IP vom DHCP und konfiguriert es automatisch.
Dass die Fritzbox das Gateway ist, ist ja in deinem Fall okay.

Ein Fehler der oft passiert und für Kommunikationsprobleme sorgt, ist ein Gateway auf den internen Interfaces einzutragen. Da darf nichts eingetragen werden.

OPNsense auf Geräte

- 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ß.

Ähnliches ist mir auch schon passiert. Da war es allerdings der ISC DHCP, der gelaufen ist und den KEA Start verhinderte.

Tipp: System: Diagnostics: Services zeigt, welche Services laufen. Die rasche Kenntnis, dass ein Service nicht läuft, hilft schon mal weiter. Das System-Log sollte dann mehr dazu verraten.

- 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.

Die Reihenfolge der Regel ist entscheidend. Die Regeln werden von oben nach unten abgearbeitet, trifft eine zu, wird sie angewandt.
Für das zutreffen sind verantwortlich: Interface, Richtung, Protokoll, IP-Version, Qull-IP u. -Port, Ziel-IP u. -Port.

D.h. wenn du RFC 1918 blockieren möchtest, muss diese Regel oberhalb der allow-any stehen.
Zugriff auf die FW sowie auch andere lokale Ressourcen musst du per Regel oberhalb der Block-RFC1918 erlauben, da diese sonst jeglichen Zugriff schon blockiert.

[meyergru]

@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.
- Schritt-für-Schritt Tutorials "from the ground up" helfen nur sehr bedingt, denn jeder Jeck ist anders...
- Jede Abweichung oder "Vergessen" eines Schritts oder wie hier die falsche Reihenfolge bei Firewall-Regeln würde die Funktion verhindern (übrigens: by design).
- 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.

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.

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

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