Kaskadierung der OpenVPN Verbindung
-
Ohne ein konkretes Beispiel ist das etwas schwierig zu beschreiben.
Ein typischer Anwendungsfall: 2 Standorte: Hauptniederlassung (A), Zweigstelle (B)
Die beiden Standorte werden per Site-to-Site VPN verbunden. Auf dem Router in der Hauptniederlassung läuft zudem ein Access-Server mit dem sich die Roadwarrior verbinden, diese benötigen auch Zugriff aufs LAN in der Zweigstelle.Simples Beispiel:
A Headquarter B Zweigstelle LAN 192.168.1.0/24 LAN 192.168.10.0/24 Site-to-site VPN 10.0.8.0/29 Site-to-site VPN 10.0.8.0/29 Access-VPN 10.0.10.0/24
Site-to-Site (SSL)
Site A: Server
In den Server-Settings:
IPv4 Local network(s): 192.168.1.0/24
IPv4 Remote network(s): 192.168.10.0/24Site B: Client
In den Client-Settings:
IPv4 Remote network(s): 192.168.1.0/24,10.0.10.0/24Access Server (SSL) (Roadwarrior)
In den Server-Settings:
IPv4 Local network(s): 192.168.1.0/24,192.168.10.0/24Das sollte es das Routing betreffend schon gewesen sein. Damit bekommen die Roadwarrior die Routen für beide LANs gepusht, Site A weiß anhand der Remote network(s), welche Zieladressen über die Site-to-site VPN zu routen sind und gleiches gilt für Site B. Hier werden auch Pakete für die Roadwarrior über die Site-to-site VPN geroutet.
-
Ich verstehe seine frage anders, nämlich:
pfSense LAN => VPN-Server1 => VPNServer2 => Internet -
Hatte ich auch schon vermutet, allerdings nennt sich so etwas doch verschachtelte (oder nested) VPN.
-
Nein nein, das war auch so gemeint, wie ich es dargestellt habe (ok, Pippin hat es etwas verständlicher gemacht): pfSense LAN => VPN-Server1 => VPN-Server2 => Internet
Wie gesagt, ich bin über den Begriff "VPN Kaskadierung" gestolpert und habe ihn dann einfach hier verwendet. Wenn's nicht ganz stimmt bzw. ein anderer Begriff üblich ist, tut mir Leid.
Kann man also verschachtelte (oder auch Multi-HOP) OpenVPN Verbindungen in der pfSense anlegen und wenn ja, wie geht das?
-
Na ja, die Darstellung war für mich auch nicht verständlicher, ich hatte nur bereits die Vermutung, dass das von mir beschrieben nicht wirklich das Problem sein sollte.
Also so etwas:
[code] Site A VPN1 |--------------------------------| B C VPN2 -------|--------------------------------|--------- VPN2 |--------------------------------| [/code] VPN 2 geht durch VPN1 hindurch. (Mit diesem kurzen Satz wäre es gleich verständlich ;) ) Okay, aber da bin ich auch überfragt, auch was den Sinn einer solchen Lösung betrifft. Aber ich hatte mal solch ein Konstrukt beschrieben gesehen, weiß aber nicht mehr, ob das für pfSense gegolten hat. Aber theoretisch sollte das schon machbar sein, ist ja nichts anderes als dass die VPN2 anstatt übers WAN-Gateway über die VPN1 geschickt wird. Wie da das Routing genau aussieht, hängt vom Ziel des Ganzen ab, wie sollen beide VPN Verbindungen Site-to-Site sein, soll auf ein Netzwerk auf C zugegriffen werden, oder auch von C auf A. Jedenfalls scheint dies um einiges komplizierter zu sein.
-
Es gibt eine zweite Möglichkeit neben dem die von @viragomann beschrieben wurde und das ist was un1que mochte vermute ich mal.
Einige VPN Anbieter bieten diese Möglichkeit.Site A VPNclient <–> Site B VPNserver-Site B VPNclient <--> Site C VPNserver <--> Internet
Die Performance wird in beide falle einbüßten weil die Pakete viel Overhead drin haben.
-
Naja, ich stelle es mir halt folgendermaßen vor: die pfSense baut eine VPN Verbindung zum Server A auf, der Traffic wird getunnelt und mit der externen IP vom Server A aus dem Tunnel heraus, wird eine 2. VPN Verbindung zum Server B aufgebaut. Am Ende hat man eben die durch den VPN-Tunnel_1 getunnelte VPN-Tunnel_2 Verbindung mit der externen IP vom Server B.
Jetzt hört sich das noch komplizierter an :o
–-
Mal ganz blöd in den Raum gefragt, würde da vllt. schon folgendes ausreichen?
1. Ich erstelle in der pfSense 2 VPN Client Verbindungen und baue somit VPN-Verbindungen zu 2 externen Servern auf (Tunnel_1 entspricht Server_A, Tunnel_2 entspricht Server_B).
2. Nun sind mir zum jeweiligen Tunnel die öffentliche IP, die interne IP und die interne Gateway IP des jeweiligen VPN-Servers bekannt.
3. Letztendlich im Tunnel_1 unter "Advanced Configuration" => "Custom options" einen Befehl "route add" (wäre es der richtige?) mit der [öffentlichen IP des Server_A] via [internen Gateway IP des Server_B] eingebe?
4. Der letzte Schritt wäre unter Rules als Gateway den Tunnel_1 auszuwählen.Oder muss man da schon etwas mehr machen als nur eine einzige Route zu erstellen?
-
Ich fürchte, wir verstehen hier alle was anderes. Für mich widersprechen sich schon deine ersten beiden Sätze.
@un1que:Naja, ich stelle es mir halt folgendermaßen vor: die pfSense baut eine VPN Verbindung zum Server A auf, der Traffic wird getunnelt und mit der externen IP vom Server A aus dem Tunnel heraus, wird eine 2. VPN Verbindung zum Server B aufgebaut. Am Ende hat man eben die durch den VPN-Tunnel_1 getunnelte VPN-Tunnel_2 Verbindung mit der externen IP vom Server B.
Jetzt hört sich das noch komplizierter an :o
Das kann man wohl sagen! ;)
Mit dem erste Satz verstehe ich so etwas wie in der Grafik unten.
Das ist vom Prinzip her das, was ich anfangs beschrieben habe, jedoch werden hier zwei Site-to-site VPN aufgebaut und du möchtest am Ender der Tunnelkette noch zum Internet raus, während in meinem Beispiel die VPN eine eine Roadwarrior war.
In diesem Beispiel wird die VPN1 auf der Site A terminiert und von da eine weitere zu B aufgebaut.Deinen zweiten Satz verstehe ich aber so wie in Reply #9 beschrieben, so dass VPN2 durch VPN1 hindurch gehen soll. :-\
Eine Skizze und eine Beschreibung, was über die VPN drüber soll, würde das Anliegen vielleicht besser zum Ausdruck bringen.
Grüße
-
Hmm, vllt. drücke ich mich etwas missverständlich aus, liegt wohl an dem Halbwissen :-[
Aber ich bin mir so ziemlich sicher, du hast es mit der Skizze auf den Punkt gebracht, nur das es halt am Ende vom Server B zum Internet rausgeht. Das aus Reply #9 ist wirklich nicht das, was ich möchte.
Also nochmal zusammengefasst: pfSense baut eine Verbindung zum Server_A auf, von dort wird eine Verbindung zum Server_B aufgebaut und am Ende geht's zum Internet raus, sodass das entsprechende Endgerät hinter pfSense die öffentliche IP Adresse des Server_B hat.Wenn das nun geklärt wäre, was meinst du zum Vorschlag aus Reply #11 mit dem Eintragen der Route, könnte das schon klappen?
-
So wie du das beschreibst ist das ein simpler Internet Zugang über mehrere Hops, nur das die Verbindung zwischen den Routern eben über VPN hergestellt wird.
Um das zu bewerkstelligen musst du Zugriff auf die jeweiligen Router haben, denn sie brauchen sowohl die richtige Route ins Internet als auch die richtige Route in dein Ausgangsnetz zurück.
Mal angenommen der aufbau sieht folgendermaßen aus
Netz 1 –> Router 1 --> OpenVPN 1 --> Router 2 --> OpenVPN 2 --> Router 3 --> InternetRouter 1 Default Gateway ist Router 2 bzw. der VPN Tunnel dahin
Router 2 Default Gateway ist Router 3 bzw. der VPN Tunnel dahin, zusätzlich wird eine Route ins Netz 1 benötigt
Router 3 Default Gateway ist dessen WAN Interface, zusätzlich wird eine Route ins Netz 1 benötigt.Ein Datenpaket mit Source IP aus Netz eins und Destination IP im Internet würde erst in den Tunnel 1(Default GW) geschickt, am Router 2 ausgepackt, dann anhand der Destination ans nächtste Default Gateway weitergeleitet. Der Router 3 macht wahrscheinlich NAT, das heißt aber nur, das er die Source IP übersetzt in eine die im Internet weitergeroutet wird. Er wartet dann bis er vom Provider die angefragten Daten bekommt und leitet sie dann an die ihm bekannte Source IP zurück. Heißt also, jeder Hop muss wissen wo sich das Netz befindet das die Anfrage erstellt hat, sofern du kein NAT aktiviert hast.
-
Fast perfekt. :)
Einziger Einwand:
Die Routen zurück zum Ausgangspunkt sind nicht zwingend, wenn jeder Router am VPN-Eingang NAT macht. Ist das von Haus aus so konfiguriert, ist auch kein Zugriff auf die Remote-Router nötig.Dass der Router 3 an der Paketübergabe ins Internet NAT macht, ist nicht nur wahrscheinlich, das ist bei IPv4 unumgänglich, ansonsten würden Antwortpaket nicht zurückfinden.
Grüße
-
Ok, genau so meinte ich das in Reply #11 (glaube ich zumindest). Also…
-pfSense Rule mit default Gateway [[i]Interface vom OpenVPN-Client_A]
-im pfSense's OpenVPN-Client_A erstelle ich eine Route [[i]öffentliche IP vom Server_A] via [[i]Gateway IP vom Server_B]-Der Server_B dürfte seine Gateway IP ja kennen, von daher brauche ich im OpenVPN-Client_B dafür keine extra Route anzulegen?
-Wenn ich nun nicht zwingend eine Route zum Ausgangspunkt brauche, dann sollte das doch alles gewesen sein?Bin ich denn richtig mit der Annahme, dass ich die o.g. Route unter OpenVPN Client's "Advanced Configuration" => "Custom options" einzutragen habe und dann im Format "route add [IP] via [IP]"?
-
In der ersten Aussage würde ich das "default" streichen.
Wenn du Policy Routing verwendest, kannst du dir, meines Wissen, Routen in den VPN-Verbindungen ganz sparen.
Wichtig dabei, dem Client ein Interface zuweisen, aber ansonsten gibt es ja auch keine Gateway fürs Policy Routing. Das Gateway, zu welchem du damit die Pakete hinroutest, ist der Server am anderen Ende. Damit sind die Pakete ohnehin schon an ihrem Ziel, jedenfalls für den Router vor der VPN.Ansonsten, ein "route add" gibt es in OpenVPN nicht, hier wäre eher iroute angebracht. Andere Routing-Befehle finden sich auf der Manpage.
Aber wenn du keine besonderen Gründe für solche hast, würde ich generell von Routing Optionen in den Advanced Options abraten. Viele Empfehlungen, die man im Netz für solche Optionen findet, sind veraltet.
Alles was normalerweise bei OpenVPN-Verbindungen benötigt wird, lässt sich mit "Remote Networks" und "Local Networks" in den Server- und Client-Einstellungen bzw. in den Client Specific Overrides (bei Access- od. Multipurpose-Server) setzen.Die Route für den Rückweg kannst du dir, wie erwähnt, nur ersparen, wenn du die Pakete nattest. D.h. jeweils am Client eine Outbound NAT Regel am jeweiligen OpenVPN Interface einrichten, alle anderen Wert könne default bleiben, wichtig Translation address = Interface address.
Grüße
-
Sorry für die späte Rückmeldung, bin aufgrund der Feiertage nicht zum Schreiben gekommen…
Ja stimmt, "default" kann man streichen, danke.
Ähm, verstehe ich das richtig? Ich richte für jeden VPN-Client ein Interface ein, dann lege ich unter Interface_A eine "any"-Regel mit Gateway des VPN-Client_B ein oder wie?
Ok, "route add" gibt es nicht, ist aber "route [Gateway IP]" oder "route-nopull" noch aktuell? Hat jetzt nichts mit diesem Thema zu tun, wollte es aber mal fragen, wo du dieOpenVPN Befehle angesprochen hast.
Zum NAT: ok, danke nochmal für den Hinweis.
-
Am besten ein Interface für jede VPN Instanz einrichten. Also in Bezug auf obiges Beispiel, an der pfSense 1 Interface für den Client, am Router A je 1 für Server und Client und am Router B 1 für den Server.
Und das Gateway in der Firewall Regel ist immer dann nötig, wenn der Traffic über ein anderes als das Default Gateway soll.
https://doc.pfsense.org/index.php/What_is_policy_routingRouting-Befehle für OpenVPN finden sich in der Doc: https://openvpn.net/index.php/open-source/documentation/howto.html
Wie gesagt, ich habe mit den Möglichkeiten der WebGUI hier nahezu das Auslangen. Auch "route-nopull" lässt sich über die GUI setzen.Grüße
-
Ja, danke, hilft mir schon mal weiter.
Auch danke für die Verlinkung der Befehle (nopull habe ich heute tatsächlich aber auch gefunden, hätte gar nicht danach fragen brauchen, wenn ich mir die Einstellungen angeschaut hätte :-[).