orcape
Goto Top

PfSense Routing von separaten OpenVPN-Tunneln

Hi Leute,
ich habe auf einer pfSense (OpenVPN Interface) 3 OVPN-Tunnel mit Port 1194, 1195, 1196
und unterschiedlichem IP-Range am laufen.
2 davon laufen im peer-to-peer Modus und verbinden die beiden remoten Netze
jeweils mit dem Server-LAN und der DMZ.
Der dritte Tunnel dient einem Client als Zugriff zum Server-LAN und läuft als Remote Access.
Zugriffe funktionieren in jeweils beide Richtungen problemlos.
Der Zugriff der remoten Standorte untereinander war und ist nicht geplant, sonst hätte ich
nur einen Tunnel im Multi-Client-Modus laufen.
Nun bin ich aber kurzfristig gezwungen vom Remoten-Client über Tunnel 3 auf
die pfSense und mein LAN zuzugreifen, was auch problemlos funktioniert.
Die Erreichbarkeit der 2 remoten Standorte ist aber leider eingeschränkt,
sie funktioniert nicht direkt vom Client aus.
Mit dem "Umweg" über die pfSense komme ich auch per ssh auf die remoten Clients der anderen Tunnel,
leider eben nicht direkt von Tunnel zu Tunnel.
Hat hier einer von Euch Erfahrung, ob und wie ein Routing mehrerer Tunnel über ein Interface
auf der pfSense hier überhaupt funktioniert.
Da ich in den nächsten Wochen aber nur über diesen Weg auf die pfSense komme,
kann ich mir keine großen, nicht fundierten Experimente erlauben, die mir dann zu guter letzt
meine Verbindung zur pfSense kappen.
Gruß & Danke orcape

Content-Key: 228913

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

Printed on: June 13, 2024 at 13:06 o'clock

Mitglied: 108012
108012 Feb 06, 2014 at 12:20:41 (UTC)
Goto Top
Hallo,

und unterschiedlichem IP-Range am laufen.
Ich glaube dort liegt der Fehler, für die nur teilweise
Erreichbarkeit Deiner VPN Verbindung zum Rest des Netzwerkes.

Richte doch einfach mal Routen in die anderen Netzwerke bzw.
auf die IP Ranges ein, damit Du dann auch dort hinein kommst.


Gruß
Dobby
Member: orcape
orcape Feb 06, 2014 at 12:44:00 (UTC)
Goto Top
Hi D.o.b.b.y,
Ich glaube dort liegt der Fehler, für die nur teilweise
Erreichbarkeit Deiner VPN Verbindung zum Rest des Netzwerkes.
Ich glaub Du interpretierst Da was verkehrt.
Das sind 3 verschiedene Tunnel, die das pfSense interne LAN erreichen.
Es geht mir nur um die Verbindung vom VPN 3 zu den anderen beiden.
Da diese aber auf einem Interface liegen...
Eine Route hatte ich schon definiert, hat aber nicht den gewünschten Effekt.
Gruß orcape
Mitglied: 108012
108012 Feb 06, 2014 at 12:50:42 (UTC)
Goto Top
Das sind 3 verschiedene Tunnel, die das pfSense interne LAN erreichen.
Ja aber jedes mit einem anderen IP Bereich, oder?

Es geht mir nur um die Verbindung vom VPN 3 zu den anderen beiden.
Dann sollte die Route von eben diesem auf die anderen beiden abzielen
oder aber man regelt (erlaubt den Zugriff) das mittels der Firewallregeln.

#grey| Gruß
Dobby##
Member: orcape
orcape Feb 06, 2014 at 15:18:40 (UTC)
Goto Top
Dann sollte die Route von eben diesem auf die anderen beiden abzielen
Zum erstellen einer Route müsste ich aber einen neuen Gateway festlegen.
Für das virtuelle Interface "OpenVPN" lässt sich aber kein Gateway manuell erstellen.
Wenn ich hierzu die Tunnel-IP als Gateway verwende, bin ich mir nicht sicher, ob ich mir das WAN irgendwie blocke.
Mit dem WAN als Gateway und einer erstellten Rule funktioniert es definitiv nicht.
Wie gesagt, ein falscher Handgriff und das kann es für ein paar Wochen gewesen sein.
Wäre schön, wenn das so auf der pfSense schon mal jemand praktiziert hätte...face-wink
Gruß orcape
Mitglied: 108012
108012 Feb 06, 2014 at 19:17:23 (UTC)
Goto Top
Wäre schön, wenn das so auf der pfSense schon mal jemand praktiziert hätte
Dann solltest Du lieber warten bis @aqui sich dazu äußert face-wink


Gruß
Dobby
Member: orcape
orcape Feb 06, 2014 at 19:52:17 (UTC)
Goto Top
Dann solltest Du lieber warten bis @aqui sich dazu äußert face-wink
...das waren auch schon so meine Gedanken...face-wink
Gruß orcape
Member: gresser
gresser Feb 06, 2014 at 19:56:46 (UTC)
Goto Top
Hey,

für den Zugriff vom 3 Tunnel auf die Tunnel 1 und 2 musst du im Normalfall eine Route für die Clients (also Gegenseite der pfSense) pushen.

Für den Tunnel 3 sollte dies so aussehen (VPN --> OpenVPN --> Server --> Tunnel 3

push "route 172.168.1.0 255.255.255.0";
push "route 172.168.2.0 255.255.255.0";

Nun findet aber nur der Client im Tunnel 3 den Weg zum Tunnel 1 und 2, diese kenne aber keinen Rückweg.
Deshalb sind in Tunnel 1 und 2 noch folgende Einträge notwendig

push "route 172.168.3.0 255.255.255.0";

Dies kann auch unter Umständen direkt auf dem Client erfolgen, sollte dann aber nur wie folgt aussehen.
route 172.168.3.0 255.255.255.0

PS: Die Befehle gehören in den unteren Bereich Advanced configuration

Gruß
Member: aqui
aqui Feb 06, 2014 updated at 21:45:41 (UTC)
Goto Top
Hi Orcape
Hast du die OVPN Routing Dok dazu mal gelesen:
http://community.openvpn.net/openvpn/wiki/RoutedLans
Ggf. hilft das..
Member: orcape
orcape Feb 07, 2014 updated at 09:56:18 (UTC)
Goto Top
@ gresser
für den Zugriff vom 3 Tunnel auf die Tunnel 1 und 2 musst du im Normalfall eine Route für die Clients (also Gegenseite der pfSense) pushen.
Wenn das nur so einfach wäre.
Die einzelnen OpenVPN-Server kennen ja die Route zu Ihrem Client-LAN bereits.
Das pushen der Routen ist für ein Netzwerk hinter dem Server kein Problem.
Ein Eintrag wie von Dir vorgeschlagen, führt zu keiner Änderung in der Routing-Tabelle.
Die pfSense müsste auf dem OpenVPN-Interface von einem Tunnel in den anderen routen, dann wären die remoten Clients sofort erreichbar.
Der "push route" Befehl funktioniert da nicht.
@ Aqui
...hab mir das mal reingezogen. So ein Fall ist aber nicht beschrieben.
Also wohl doch erst mal weiter die "Notlösung" mit dem Umweg über den Router und später einen Multi-Client Modus mit den entsprechenden Regeln.
Es sei denn, hier hat noch jemand eine "zündende " Idee, die dann schon getestet und auch funktioniert...face-wink
Gruß orcape
Member: aqui
aqui Feb 07, 2014 at 18:22:38 (UTC)
Goto Top
Die Frage ist generell warum du 3 unterschiedliche OVPN Instanzen hast ? Gibt es einen Grund dafür ?
Member: orcape
orcape Feb 08, 2014 at 06:07:16 (UTC)
Goto Top
Hi,
Die Frage ist generell warum du 3 unterschiedliche OVPN Instanzen hast ? Gibt es einen Grund dafür ?
Gute Frage...face-wink
Irgendwann war da mal ein erster Tunnel mit der entsprechenden CA, *.crt, und Key für einen Client.
Später kam dann ein zweiter hinzu, mit neuer CA, *.crt, und Key..usw.
Die Tunnel brauchten bis Dato keine Verbindung untereinander und das kann und soll auch so bleiben.
Sicher kann man einen einzelnen Tunnel draus machen und den im Multi-Client Modus laufen lassen.
Entsprechend konfigurieren und gut iss es.
Das müsste aber dann passieren, wenn ich direkten Zugriff auf die pfSense habe.
Die Tunnel laufen alle auf einem Interface, wäre es eine Möglichkeit für jeden Tunnel
ein Interface zu machen und dann entsprechend zu routen ?
Gruß orcape
Member: aqui
aqui Feb 08, 2014 at 12:29:41 (UTC)
Goto Top
Das ast du ja jetzt mit den separaten Prozessen. Vermutlich ist das auch das grundlegende Problem, denn normalerweise hat man nur einen Prozess und steuert den Zugriff über die Firewall.
Langfristig wäre es also besser wenn man die Konfig im Hinblick darauf optimiert.
Member: orcape
orcape Feb 08, 2014 at 15:58:56 (UTC)
Goto Top
Das ast du ja jetzt mit den separaten Prozessen. Vermutlich ist das auch das grundlegende Problem, denn normalerweise hat man nur einen Prozess und
steuert den Zugriff über die Firewall.
Ist eigentlich kein Problem 3 Tunnel auf einem Interface, so lange man nicht zwischen den Tunneln routen muss.
Eigentlich müssten sich doch 3 Virtuelle Interfaces für die Tunnel definieren lassen, die dann bei Bedarf entsprechend geroutet werden können.
Nur ist das für mich von remote zur Zeit ein zu hohes Risiko, wenn das Szenario noch keiner am laufen hat.
Langfristig wäre es also besser wenn man die Konfig im Hinblick darauf optimiert.
Das wird dann wohl irgendwann so werden, wenn ich denn hier in 3 Wochen aus dem Funkloch mit GPRS <10Kbit/s wieder raus bin...face-wink
Gruß orcape
Member: orcape
orcape Mar 02, 2014, updated at Mar 04, 2014 at 17:38:36 (UTC)
Goto Top
Hi,
hab das ganze Routing auf der pfSense eben hinbekommen ohne einen Multiclienttunnel zu machen.
Hier mal eine Beispiel-conf....
OpenVPN-Server3
Advanced Configuration
push "route 10.7.8.0 255.255.255.0"; # zu OVPN-Netz 1
push "route 192.168.65.0 255.255.255.0"; # zu LAN hinter OVPN 1
route 192.168.65.0 255.255.255.0; # zu LAN hinter OVPN 1
push "route 10.14.8.0 255.255.255.0"; # zu OVPN-Netz 2
push "route 192.168.187.0 255.255.255.0";# zu LAN hinter OVPN 2
route 192.168.187.0 255.255.255.0; # zu LAN hinter OVPN 2

OpenVPN-Server2
Advanced Configuration
push "route 10.13.6.0 255.255.255.0"; # zu Tunnel3
route 10.13.6.0 255.255.255.0; # zu Tunnel3

OpenVPN-Server1
Advanced Configuration
push "route 10.13.6.0 255.255.255.0"; # zu Tunnel3
route 10.13.6.0 255.255.255.0; # zu Tunnel3

Für das OpenVPN-Interface noch ein paar Regeln erstellen und bei Bedarf modifizieren...
pass Tunnel3-Tunnel1
pass Tunnel3- LAN 1
pass Tunnel1-Tunnel3
pass LAN1 -Tunnel3

pass Tunnel3-Tunnel2
pass Tunnel3- LAN 2
pass Tunnel2-Tunnel3
pass LAN 2 -Tunnel3
...und schon klappt die Verbindung in die remoten LAN´s.
Vom Aufwand her nicht mehr wie ein Multiclienttunnel, wenn man´s weiß.face-wink
Leider habe ich dazu nichts in den Manuals finden können.
Gruß orcape
Member: aqui
aqui Mar 03, 2014 updated at 09:21:40 (UTC)
Goto Top
Vom Aufwand her nicht mehr wie ein Multiclienttunnel, wenn man´s weiß.
Das meins du im Hinblick auf die zahllosen Konfig Parameter oben nicht wirklich Ernst, oder ?
Es bleibt immer noch die Frage warum der ganze Frickelkram mit den 3 separaten Instanzen ? Das ist von der grundsätzlichen Konfig her falsch und müsste so nicht sein und erzwingt in letzter Konsequenz auch diese überflüssig aufwendige Konfig.
Gut wenns nun klappt und für dich alles rennt ists ok aber es mpüsste nicht so sein.
Hört sich so ein bischen nach " Warum einfach machen wenns umständlich auch geht ?!" an.
Member: orcape
orcape Mar 03, 2014 at 16:08:27 (UTC)
Goto Top
Hört sich so ein bischen nach " Warum einfach machen wenns umständlich auch geht ?!" an.
Ja gut irgend eine Ausrede braucht man ja...face-wink
Aber beim Multiclienttunnel muss ich auch genügend Regeln definieren um auf Nummer sicher zu gehen, wenn die Oma mir nicht
"in die Suppe spucken soll".
Also was soll´s Aqui, Du weist vielleicht schon das Aufgeben nicht mein Ding ist und nun wissen wir wenigstens das es auch anders geht.face-wink
Gruß orcape
Mitglied: 117471
117471 Apr 26, 2018 at 14:27:21 (UTC)
Goto Top
Hallo,

Zitat von @aqui:

Es bleibt immer noch die Frage warum der ganze Frickelkram mit den 3 separaten Instanzen ?

Ich habe genau das Gleiche Problem, stolpere gerade über diesen uralten Thread und möchte diese Frage gerne beantworten: "Man hat sich als Dienstleister an den vorgelagerten Systemen" zu orientieren. Dort gelten z.B. unterschiedliche Firewallregeln für unterschiedliche Ports bzw. die "Ports an sich" werden aus unterschiedlichen Netzen angesprochen, liegen auf separaten Gateways usw. usf.

Und vielleicht möchte man die Instanzen ja auch separat konfigurieren und neu starten können. Für den OpenVPN-Server für die Administratoren oder Netzkopplungen gelten ganz andere Spielregeln wie für die RoadWarrior.

Ich nehme für mich mal mit, dass das nicht so "ohne Weiteres" möglich ist - was ich sehr schade finde.

Gruß,
Jörg
Member: aqui
aqui Apr 26, 2018 at 14:29:44 (UTC)
Goto Top
Na ja mit 3 VMs hat man ja 3 separate Instanzen und damit ist das dann wieder ein Kinderspiel...
Oder...man nimmt einem kleinen Cisco und arbeitet mit VRFs face-wink
Mitglied: 117471
117471 Apr 26, 2018 at 14:32:51 (UTC)
Goto Top
Hallo,

Zitat von @aqui:

Na ja mit 3 VMs hat man ja 3 separate Instanzen

Es gibt gute Gründe, Firewalls nicht in einer VM zu installieren.

Oder...man nimmt einem kleinen Cisco und arbeitet mit VRFs face-wink

Da hast Du sicherlich auch Recht. Aber ich bin nun mal Freund von OpenSource und immer geneigt, derartige Projekte zu unterstützen und schaue grundsätzlich zuerst in diese Richtung - gerade weil ich es auch wichtig finde, die Communities monetär zu unterstützen. Aber in diesem Falle geht es halt nicht (gut) - wie Du ja selber festgestellt hast.

Gruß,
Jörg
Member: orcape
orcape Apr 27, 2018 at 10:28:46 (UTC)
Goto Top
Hi,
weil das wieder so schön "aufgewärmt" wurde, hier 4 Jahre später auch noch meinen Senf dazu.
Ich muss im nachhinein feststellen, das die 3 Instanzen (nicht in einer VM), sehr wohl eine Berechtigung gegenüber einem Multiclienttunnel haben und das Handling bei eventuellen remoten Ausfällen einfacher ist.
Und vielleicht möchte man die Instanzen ja auch separat konfigurieren und neu starten können.
Genau hier liegt der Vorteil des Constructs, bei mehreren anzubindenden remoten Netzen.
Wobei ich im reinen Road-Warrior Betrieb, um remote EInzelclients ins Firmennetz einzubinden, wohl auch den Multiclienttunnel bevorzugen würde.
Gruß orcape
Mitglied: 117471
117471 Apr 27, 2018 updated at 10:45:01 (UTC)
Goto Top
Hallo,

Zitat von @orcape:

Wobei ich im reinen Road-Warrior Betrieb, um remote EInzelclients ins Firmennetz einzubinden, wohl auch den Multiclienttunnel bevorzugen würde.

Genau das habe ich mir nämlich auch gedacht. Gerade am Vortag habe ich einen Kollegen bei einem Szenario unterstützt, wo eine zusätzliche Netz-zu-Netz Kopplung etabliert wurde. Die "Gegenseite" hat es tatsächlich geschafft, derart unförmige Pakete zu schicken, dass das openswan mit Kernelfehlern ausgestiegen ist.

Und auf einmal waren auch die ganzen RoadWarrior weg und wir standen zudem vor einen Szenario, wo wir den VPN-Dienst mehrfach neu starten mussten. Die (leistungsorientiert bezahlten bzw. scheinselbstständigen) Außendienstler, die von Kundentermin zu Kundentermin flitzen, haben sich wohlwollend bedankt.

Man kann durchaus darüber diskutieren, mehrere Firewalls an den Start zu bringen. Aber dann habe ich letztendlich auch 3 Netzteile, 3 Gehäuse, 3 CPUs und baue direkt daneben noch mal 3 Redundanzen für meine Ausfallsicherheit auf.

Mit anderen Worten: Genau so, wie eine Virtualisierung bei Betriebssystemen Sinn macht, macht auch eine Verteilung von einzelnen Diensten auf ein- und derselben Hardware Sinn.

Gruß,
Jörg