OPNsense OpenVPN-site-to-site-Tunnel - Serverseite kann auf Clientseite nicht zugreifen

@aqui:
Ich weiß nicht, ob Du FortiGate kennst. Bei FortiGate ist es jedenfalls so, dass für IPv4 und IPv6 jeweils eine einzige Firewall-Regel-Liste vorhanden ist. Dort kann ganz klar und eindeutig der Verkehr von einer Quell-Schnittstelle zu einer Ziel-Schnittstelle definiert werden. Diesen Zusammenhang von Quelle-Ziel gibt es bei der OPNsense nicht und er kann mit Schnittstellen-Listen sowie mit Regeln, die entweder IN oder OUT definieren, nicht hergestellt werden.

Immerhin ist nicht jeder Verkehr, der auf einer Schnittstelle eingeht, vollumfänglich ein böser Verkehr. Vielmehr kann ein solcher Verkehr (z.B. DNS-Anfrage, SSH-Zugriff, Http-Zugriff) durchaus zulässig sein, wobei er die OPNsense nur über eine bestimmte Schnittstelle (z.B. WAN) nicht verlassen darf, über andere (z.B. IPsec, OpenVPN, lokales Interface) schon. Wie willst Du das mit nur IN-Regeln sinnvoll abdecken? Eine einzige OUT-Regel auf der betreffenden Ziel-Schnittstelle erschlägt das Problem zielgenau und ist auch nach Jahr und Tag leicht nachzuvollziehen. Das gilt umso mehr, wenn bestimmte Verkehre generalisierend (z.B. nur nach den Ports) gefiltert werden sollen. Stehen nur IN-Regeln zur Verfügung, müssen diese in vielfältiger Hinsicht nach den Ziel-Adressen/-Ports unterscheiden, sofern eine Differenzierung praktisch überhaupt möglich ist. Sind solche Ziel-Adressen/-Ports je nach OUT-Schnittstelle zulässig oder unzulässig, kann das mit nur IN-Regeln nicht gelöst werden.

Denn beachte (!!!):
Laut Funktionsbeschreibung von OPNsense darf jeder Verkehr, der eine IN-Regeln erfolgreich als zulässig absolviert hat, die OPNsense über jede andere Schnittstelle verlassen. Der Verkehr wird dann schlichtweg nicht mehr reguliert. Will ich diesen Verkehr nur für eine Schnittstelle sperren, muss ich folglich den Verkehr insgesamt sperren - dann aber wird "das Kind mit dem Bade ausgegossen". Erst eine OUT-Regel kann das wieder einfangen und den Verkehr hinsichtlich der erlaubten OUT-Schnittstelle(n) regulieren. Ein solches Einfangen würde aber dann scheitern, wenn für die OUT-Regel nach den IN-Schnittstellen differenziert werden müsste.
Soll ein bestimmter Verkehr die OPNsense über keine einzige (/ über alle) verlassen dürfen, dann genügt freilich bereits eine IN-Verbot(/Erlaubnis)-Regel. Aber eben nur dann.

Der Ansatz der OPNsense und wohl auch Dein gedanklicher ist im Übrigen wohl, für Firewall-Regeln allein auf die Quell- und Ziel-Adressen/-Ports abzustellen. Dabei mag in der Tat das Hantieren mit ausschließlich IN-Regeln restlos funktionieren. Aus meiner Sicht ist das aber nur die halbe Miete, weil für mich zur Definition eines zu regulierenden Verkehrs jedenfalls auch die beteiligten Schnittstellen von Bedeutung sind. Meiner Erfahrung nach und auch bei theoretischem Durchdenken der Logik von Regeln komme ich ganz schnell zu dem Bedürfnis, einen (gleichzeitigen) IN-OUT-Zusammenhang in Bezug auf die Schnittstellen zu implementieren.

Der Regelungsansatz der FortiGate verknüpft IN- und OUT-Bedingung in einer einzigen Regel. Das macht noch leichter steuer- und erkennbar, welchem Verkehr welche Wege durch die FortiGate erlaubt oder verboten sind. Hinzukommt, dass bei FortiGate alle Regeln in einer einzigen Rangfolge abgearbeitet werden, so dass darüber eine eindeutige logische Abfolge sichergestellt wird. Das ist bei OPNsense nicht vollständig möglich. Lediglich die vorrangigen Fließend- und Gruppen-Regeln können das - aber nur eingeschränkt - abdecken. Im Übrigen sind die Schnittstellenlisten unabhängig voneinander, so dass logische Zusammenhänge nicht aufgebaut werden können.

In diesem Sinne meine ich mit Portierung:
- Die auf der FortiGate bisher verwendeten Regeln werden aufgelöst in IN- und/oder OUT-Regeln. Wurde auf der FortiGate für die Quell-(/Ziel-)Schnittstelle der Parameter any verwendete, genügt eine einzige OUT-(/IN-)Regel auf der OPNsense. Ansonsten muss das irgendwie sowohl in eine IN- als auch in eine OUT-Regel aufgelöst werden, sofern dadurch das gewollte Regelergebnis überhaupt erreicht werden kann. Andernfalls muss die Regel gemäß den OPNsense-Gegebenheiten neu entworfen werden; das kann schon einiges Kopfzerbrechen bereiten.
- OPNsense kennt keine Mehrfachauswahl für die Schnittstellen, Adressen (IP, FQDN etc.) und Ports. Eine Bündelung ist nur über Schnittelstellengruppen und Aliase möglich. Das ist bei den Schnittstellengruppen schon deshalb schwierig, weil OPNsense keine freie Kombination der Schnittstellen in einer Gruppe zulässt. Überdies führen Schnittstellengruppen zur eigenständigen Regel-Listen, die keinen logischen Zusammenhang zueinander kennen. Mit den Aliase geht das, wenngleich die Lesbarkeit und Nachvollziehbarkeit der Regeln nicht so einfach ist.
- Die Schnittstellen-Listen erfordern gegebenenfalls die redundante Erstellung von Regeln. Das erschwert die Lesbarkeit, Nachvollziehbarkeit und Wartung des gesamten Regel-Konvoluts. Überdies besteht dadurch die Gefahr von ungewollten Lücken im Regel-Konvolut.

Ein weiterer Minuspunkt der OPNsense gegenüber der FortiGate ist aus meiner Sicht das Logging bzw. die schnelle Nachvollziehbarkeit der Logs. Da es nicht nur eine Regel-Liste gibt, ist das Auffinden der Regel zu einer geloggten Filterung wesentlich aufwendiger. Das wird noch dadurch erschwert, dass bei OPNsense für die Darstellung der Regeln in einer Liste keine eigene Spalte für die Regel-ID genutzt werden kann. Vielmehr muss immer oben im Spaltenkopf auf einen Button geklickt werden, um die Regel-ID ein-/auszublenden. Die Spaltenköpfe bleiben aber nicht stets sichtbar, so dass ein ständiges Scrollen angesagt ist. Beim Wechsel zu einer anderen Liste geht das ganze Spiel von vorne los. Erschwerend kommt die Länge der kryptischen Regel-ID. [Bei FortiGate sind es fortlaufende Nummern in historisch aufsteigender Reihenfolge der Erstellung, was leichter / schneller erfass- und lesbar ist.]

Schließlich ist für mich nicht nachvollziehbar, wenn Regeln, die sich explizit nur auf bestimmte Schnittstellen beziehen, unerwartet auf anderen Schnittstellen ihr Unwesen treiben. Das ist mir bei FortiGate nicht untergekommen. Dort hat eine Regel immer nur dort gewirkt, worauf sie eingestellt ist.

Was mir aber an der OPNsense richtig gut im Verhältnis zur (alten) FortiGate gefällt, ist, dass eine Regel zugleich sowohl für IPv4 als auch für IPv6 erstellt werden kann und dass nunmehr auch eine FQDN-Benennung für aufzulösende IPv6-Adressen möglich ist. Zudem können IPv4- und IPv6-Adressen in einem Alias zusammengefasst werden. Insgesamt ergibt sich daraus eine vielfältige Vereinfachung.

Am Ende:
Der erste Wurf der Portierung hatte jedenfalls eine ungewünschte Behinderung des Site-to-Site-Tunnels bewirkt. Deswegen werden die portierten Regeln nunmehr sukzessive in Betrieb genommen. Die mittlerweile absolvierte Lern- und Erkenntniskurve beim Einsatz von OPNsense erleichtert das zunehmend. Freilich wird in diesem Zusammenhang die von der FortiGate her "gewöhnte" Regel-Logik weitergehend zu überdenken und anzupassen sein - aber das ist selbstredend beim Wechsel von einem zum anderen Regelungsansatz und bei der dazu erforderlichen Einarbeitung. Gewiss soll dabei auch der Vorrang der Verwendung von IN-Regeln vor OUT-Regeln hinreichend berücksichtigt werden ...

Viele Grüße
HansDampf06

PS1: Vor FortiGate waren unterschiedliche Router von bintec im Einsatz. Der Erinnerung nach entsprach der dortige Regelungsansatz im Kern dem von FortiGate. Dasselbe kann ich für den ehemaligen ISA-Server konstatieren. Mithin ist dieser Regelungsansatz ganz gewiss ein allgemein verwendeter. Aus meiner Sicht ist er zudem im Gegensatz zu dem der OPNsense intuitiv.

PS2: Ohne es an dieser Stelle oder nachfolgend in diesem Beitragsstrang vertiefen zu wollen: Der direkte IPsec-Tunnel zwischen den WAN-Schnittstellen der beiden OPNsense-Router hat durchaus funktioniert. Nur diese WAN-Schnittstellen hängen nicht direkt am Internet. Und genau dort im Zwischenbereich liegt die Baustelle / das Problem. Ich habe vorerst keine Zeit dafür ...