hansdampf06
Goto Top

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

Hallochen Gemeinde!

Zwei Standorte sind über einen OpenVPN-site-to-site-Tunnel (beide auf OPNsense in aktueller Version) miteinander verbunden. Seite A (LanA) ist der OpenVPN-Server und Seite B (LanB) der OpenVPN-Client. Zu den erreichbaren Netzwerken gehört jeweils auch das Netzwerk des WAN-Interfaces (also WanA und WanB =/= StS-Tunnel-Interfaces). Die Verbindung wird mit dem Konfigurationsmodus "Gemeinsamer Schlüssel" aufgebaut. Alle erforderlichen Routen werden auf beiden Seiten automatisch beim Verbindungsaufbau generiert und sind zutreffend. Ebenso generiert OPNsense mit der Konfiguration des OpenVPN-Servers/-Clients das zugehörige Gateway und ergänzt beim Verbindungsaufbau die IP des gegenüberliegenden Tunnelendpunktes als Gateway-Adresse.
Beide OPNsense sind zugleich das jeweilige generelle Gateway für diese beiden Netzwerke. Der gesamte nach außen gerichtete Traffic verhält sich auf beiden Gateways ordnungs- und erwartungsgemäß.

Von Seite B aus kann auf alle Clients/Server im LanA zugegriffen werden - z.B. Client B1 ruft eine von Server A1 bereitgestellte Webseite auf. traceroute (oder tracert) und ping funktionieren gleichfalls in dieser Richtung prompt und erwartungsgemäß; dabei ist sehr schön zu sehen, dass das Routing über den entfernten Tunnelendpunkt auf Seite A läuft.

Hingegen funktioniert das in der entgegen Richtung nicht. Wird mittels traceroute (oder tracert) beispielsweise von Server A1 aus der Client B1 aufgerufen, ist in der Ausgabe als erster Hop die interne Adresse des Gateways angegeben. Bei den anderen 29 Hop sind es nur Sternchen als Ausgabe. Laut "Livestatus" gibt es keine Blockierungen - das dürfte auch nicht sein, weil der gesamte relevante Verkehr für die Tunnelverbindung mit entsprechenden Rules freigegeben ist. Bei "Status" bzw. "Sitzung" finden sich als korrespondierende Einträge zum Ping etc. "NO_TRAFFIC:SINGLE" für den Eingang und "SINGLE:NO_TRAFFIC" für den Ausgang. Laut "Livestatus" / "Status" / "Sitzung" auf der OPNsense Seite B ist dort kein korrespondierender Traffic ersichtlich, was in der Gesamtschau, dass der zweite Hop nur mit Sternchen angegeben wird, plausibel und erwartungsgemäß erscheint.
Das Kuriose ist aber, wenn in der WebUI der OPNsense auf Seite A eine Diagnose mit "Ping" oder "Routenverfolgung" gestartet wird, dann ist alles von Seite B ordnungsgemäß erreichbar. Unter anderem wird dann auch der Tunnelendpunkt von Seite B als erster Hop angegeben. So soll es ja aus dem Inneren der OPNsense heraus auch sein. Zu der Kuriosität gehört auch, dass ich über deren WAN-IP die OPNsense WebUI der Seite B von Seite A aus aufrufen bzw. per ping / traceroute erreichen kann.

Somit scheint das Gateway von Seite A irgendwie nicht (immer) den "Ausgang" in Richtung Tunnel zu finden, wenn der Datenverkehr seinen Ursprung im LanA hat. Das ändert sich auch dann nicht, wenn eine Rule in der Firewall eingetragen wird, die ausdrücklich den ein- und/oder ausgehenden Verkehr von LanA nach LanB freigibt. An den Routing- und Firewall-Regeln kann es daher eigentlich nicht liegen, weil der Verkehr von LanA nach LanB grundsätzlich funktioniert, wie die Kuriosität zeigt.

Wie kann ich die OPNsense Seite A animieren die Kommunikation aus LanA ins LanB zu routen, wenn ein Ziel in LanB angesprochen werden soll?

Vielen Dank für Euren Input im Voraus und viele Grüße
HansDampf06

Content-Key: 52368529860

Url: https://administrator.de/contentid/52368529860

Printed on: February 25, 2024 at 11:02 o'clock

Member: aqui
Solution aqui Oct 06, 2023 updated at 07:29:10 (UTC)
Goto Top
Nur mal nebenbei OT gefragt: Gibt es einen tieferen Grund warum du heutzutage noch das wenig performante und wenig skalierende OpenVPN verwendest und nicht IPsec oder Wireguard?
Damit erreichst du nicht nur eine deutlich bessere VPN Performance sondern es würde auch deinen o.a. Thread obsolet machen. Es wäre die intelligentere VPN Wahl gewesen.

Das o.a. Verhalten sieht danach aus als ob irgendwo eine entsprechende Regel fehlt. Vermutlich auf dem Tunnel Interface. Wegen fehlender Daten aber leider nur geraten. face-sad
Bedenke auch wenn du Winblows Endgeräte im remoten B Netz pingst das deren lokale Firewall per Default ICMP (Ping) immer blockt. Auch generell den Zugriff aus fremden IP Netzen. Hier muss also die lokale Firewall immer entsprechend angepasst werden.
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Member: aqui
aqui Oct 24, 2023 at 14:02:53 (UTC)
Goto Top
Wenn es das war bitte nicht vergessen deinen Thread hier als erledigt zu markieren!
Member: HansDampf06
Solution HansDampf06 Nov 15, 2023 at 18:37:57 (UTC)
Goto Top
Zitat von @aqui:
Das o.a. Verhalten sieht danach aus als ob irgendwo eine entsprechende Regel fehlt.

Deine Schlussfolgerung bestärkte meine Vermutung, dass nur die Firewall-Regeln der Grund sein konnten. Immerhin hatte ich zuvor die Firewall-Regeln der alten FortiGate nach OPNsense portiert. Indes weicht das Firewall-Konzept von OPNsense erheblich von dem sonst üblichen ab. Hieraus ergeben sich einige Fallstricke bei OPNsense, die die gezielte Erreichung der gewünschten Regelungsziele erschweren ...

Nachdem alle diese portierten Regeln deaktiviert waren, funktionierte die Kommunikation für beide Seiten unproblematisch. Folglich müssen die portierten Firewall-Regeln noch weiter überarbeitet werden, damit unter den Besonderheiten von OPNsense alles so funktioniert wie gewollt.

Nur mal nebenbei OT gefragt: Gibt es einen tieferen Grund warum du heutzutage noch das wenig performante und wenig skalierende OpenVPN verwendest und nicht IPsec oder Wireguard?

Das ist relativ einfach. Grundsätzlich wähle ich IPsec. Jedoch konnte ich als OPNsense-Neuling in der Test-Simulation zunächst keine Verbindung zwischen den beiden IPsec-Endpunkten aufbauen. OpenVPN brachte als zweite standardmäßig installierte VPN-Variante sofort eine Verbindung. Es war zuerst wichtiger, eine stabile Verbindung aufzubauen, als sich zu verbeißen. Insoweit ist IPsec nur aufgeschoben, aber nicht aufgehoben. Wireshark ist gewiss zum gegebenen Zeitpunkt einen Seitenblick wert.

es würde auch deinen o.a. Thread obsolet machen.

Da bin ich mir wegen der Besonderheiten des Firewall-Konzepts von OPNsense nicht so sicher. Denn würde dieses Firewall-Konzept dem üblicherweise bei Firewalls anzutreffenden entsprechen, dann hätte nicht schon die Portierung einiges Kopfzerbrechen bereitet, sondern wäre eher ein Kinderspiel. Gerade das Wechselspiel zwischen unterschiedlichen Regeln wäre schlichtweg leicht nachzuvollziehen.

Zur Illustration ein kleines Beispiel: In eine Schnittstellengruppe kann die Loopback-Schnittstelle (lp0) nicht aufgenommen werden (wird schlicht von OPNsense nicht angeboten). Würdest Du dann erwarten, dass eine blockierende Ausgangsregel für diese Schnittstellengruppe zugleich auf die Loopback-Schnittstelle einwirkt, nur weil die in die Schnittstellengruppe aufgenommene LAN-Schnittstelle die Loopback-Schnittstelle "hostet"? Wohl eher nicht! Und weil sich die Firewall-Regeln bei OPNsense auf mehrere eigenständige Wirkungsstränge verteilen, ist es durchaus nicht trivial, eine solche Seitenwirkung wieder sinnvoll einzufangen. OPNsense hält hier also ein paar nette Überraschungen bereit, die auch böse sein können ...

Viele Grüße
HansDampf06
Member: aqui
aqui Nov 16, 2023 updated at 12:22:09 (UTC)
Goto Top
keine Verbindung zwischen den beiden IPsec-Endpunkten aufbauen.
Mmmmhhh..klappt immer auf Mausklick und deutlich einfacher als OpenVPN.
Guckst du hier für diverse Beispiele:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Wireshark ist gewiss zum gegebenen Zeitpunkt einen Seitenblick wert.
Nur einen kalten "Seitenblick" für den besten Freund des Netzwerk Admins...?! Wie gemein! face-wink
dem üblicherweise bei Firewalls anzutreffenden entsprechen
Was wäre denn für dich "üblicherweise"?? Du kannst hier natürlich keine Äpfel (Zonen basierte FW Konfigs) mit Birnen (Interface basierte FW Konfigs) vergleichen geschweige denn portieren.
Da die "Sensen" Interface basierende Rulesets haben kann man die in der Regel immer auch mit entsprechend gleichen Rulesets vergleichen und auch portieren.
dass eine blockierende Ausgangsregel...
Kein verantwortungsvoller Netzwerk Admin konfiguriert Outbound Regeln. Die pfSense hat sowas z.B. gar nicht. Nur wenn es partout nicht anders geht und das kommt so gut wie nie vor. Man will ja ungewollten oder bösen Traffic niemals schon IN einer Firewall haben. Ggf. stimmt hier etwas grundsätzlich mit deiner Regel Logik nicht was jetzt nicht böse gemeint ist?!
Member: HansDampf06
HansDampf06 Nov 16, 2023 at 22:51:04 (UTC)
Goto Top
@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 ...