14
VPN via IPSec - IKEv1 Verständnisfrage
Hallo zusammen,
ich bin diese Woche zum ersten Mal in der Verlegenheit, eine VPN-Verbindung mit IPSec/IKEv1 (PSK) aufbauen zu müssen.
VPN-Server: Fortigate mit öffentlicher fester IP, habe ich keinen Einfluss drauf
VPN-Clients: 3 Windows 10-Rechner in 3 verschiedenen Netzen, je hinter einem Router (Fritzbox / Lancom / Bintec-Elmeg alias Telekom Digitalisierungbox)
Mögliches Problem: Hinter jedem clientseitigen Router gibt einen Windows 2016-Server, der einen VPN-Server via L2TP anbietet. Entsprechend sind die IPSec-Ports etc. alle im Router zum Windows-Server geforwarded.
Wird das ein Problem? Sprich: Müsste ich für das neue IKEv1-VPN clientseitig ein Port Forwarding vom Router zu besagten Client-PCs einrichten oder ist das nicht notwendig?
Benötige ich NAT Traversal, wegen der Clients?
Mir fehlt da leider ein bisschen Grundlagenwissen. Danke für alle Hilfe!
ich bin diese Woche zum ersten Mal in der Verlegenheit, eine VPN-Verbindung mit IPSec/IKEv1 (PSK) aufbauen zu müssen.
VPN-Server: Fortigate mit öffentlicher fester IP, habe ich keinen Einfluss drauf
VPN-Clients: 3 Windows 10-Rechner in 3 verschiedenen Netzen, je hinter einem Router (Fritzbox / Lancom / Bintec-Elmeg alias Telekom Digitalisierungbox)
Mögliches Problem: Hinter jedem clientseitigen Router gibt einen Windows 2016-Server, der einen VPN-Server via L2TP anbietet. Entsprechend sind die IPSec-Ports etc. alle im Router zum Windows-Server geforwarded.
Wird das ein Problem? Sprich: Müsste ich für das neue IKEv1-VPN clientseitig ein Port Forwarding vom Router zu besagten Client-PCs einrichten oder ist das nicht notwendig?
Benötige ich NAT Traversal, wegen der Clients?
Mir fehlt da leider ein bisschen Grundlagenwissen. Danke für alle Hilfe!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 638210
Url: https://administrator.de/contentid/638210
Printed on: April 25, 2024 at 08:04 o'clock
14 Comments
Latest comment
Port 4500 und 500 zeigen auf die Server durch das NAT?
Genau, außerdem 1701 für L2TP.
Benötige ich NAT Traversal, wegen der Clients?
Ja aber nicht wegen der Clients sondern wegen dem Server der hinter einer NAT Barriere steht!Genau, außerdem 1701 für L2TP.
Da muss aber genau genommen nicht nach außen hin offen sein sondern nur über die IPSec SA am Server freigegeben sein, denn wie der Name ja schon sagt L2TP over IPSec.Zusätzlich habt ihr das ESP Protokoll Nr. 50 vergessen zu erwähnen was an den Server geforwardet werden muss (Nicht verwechseln mit einem Port das muss schon das entsprechende Protokoll sein!
Aber da du hier nichts über die Richtung der Devices erwähnst nur entsprechende Server-Gegenstellen brauchen das Port-Forwarding also nur die Responder nicht die Initiator.
Mir fehlt da leider ein bisschen Grundlagenwissen. Danke für alle Hilfe!
Grundlagen dazu finden sich hier im Forum genügend, das muss man hier nicht zum xten mal runter beten...Also lesen ist hier erst mal angesagt, bei IPSec ist das sowieso generell anzuraten:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Hallo bluewonder, danke für die Antwort!
Meine Frage bezieht sich allerdings nicht auf die bestehenden VPNs (mit dem Windows Server hinter dem Router), sondern auf das neue IKEv1-VPN. Die existierenden L2TP-VPNs laufen alle (selbstverständlich mit NAT-T, ESP Prot 50, etc).
Der neue IKEv1-VPN-Server (also der externe, den ich nicht kontrolliere) steht ja nicht hinter einer NAT-Barriere, soweit ich das verstehe. Der hat ein eigenes WAN Interface.
Meine Frage ist: funktioniert die Kommunikation zwischen Client --> Router --> IKEv1-VPN-Server problemlos, obwohl die IPSec Ports im Router vor dem Client in Richtung Windows-Server weitergeleitet sind? Nach meinem naiven Verständnis sollte das funktionieren, aber ich hätte das gerne von einem Fachkundigen bestätigt...
Danke!
Meine Frage bezieht sich allerdings nicht auf die bestehenden VPNs (mit dem Windows Server hinter dem Router), sondern auf das neue IKEv1-VPN. Die existierenden L2TP-VPNs laufen alle (selbstverständlich mit NAT-T, ESP Prot 50, etc).
Der neue IKEv1-VPN-Server (also der externe, den ich nicht kontrolliere) steht ja nicht hinter einer NAT-Barriere, soweit ich das verstehe. Der hat ein eigenes WAN Interface.
Meine Frage ist: funktioniert die Kommunikation zwischen Client --> Router --> IKEv1-VPN-Server problemlos, obwohl die IPSec Ports im Router vor dem Client in Richtung Windows-Server weitergeleitet sind? Nach meinem naiven Verständnis sollte das funktionieren, aber ich hätte das gerne von einem Fachkundigen bestätigt...
Danke!
habe ich keinen Einfluss drauf
Mal ehrlich...WIE willst du ein funktionierendes IPsec VPN konfigurieren wenn du auf die wichtigste Komponente keinen Einfluß hast. Da kannst du zu 90% davon ausgehen das das in die Hose gehen wird. Als Admin benötigst du zwingend auf den Server Zugriff, wie sollte das sonst gehen ?! Unter den Voraussetzungen solltest du lieber schnell wegrennen und einen anderen scheitern lassen !Zudem wirst du mit IKEv1 ohne einen sonst eigentlich überflüssigen VPN Client scheitern, denn Win 10 supportet mit dem bordeigenen Client nur noch IKEv2. Mit IKEv1 bruachst du in jedem Falle einen extra Client wie z.B. den kostenlosen Shrew VPN Client. Eigentlich sinnfrei, denn Windows 10 hat einen fertigen Client an Bord aber eben IKEv2.
Da würde es doch absolut Sinn machen eine IKEv2 Konfig auf der Fortinet aufzusetzen. Solltest du mal drüber nachdenken. Aber hast recht wie ohne Zugriff...und wenn sie schon falsch eingerichtet ist.
NAT Traversal macht aktuelle HW alles automatisch sofern erforderlich. Du brauchst es in jedem Falle da du ja niemals sicherstellen kannst das die Clients sich nicht in DS-Lite Netzen oder Netzen mit CGN befinden in denen dann NAT zwingend ist.
Wie man das mit einer Firewall sehr einfach im Handumdrehen umsetzt erklärt dir als Beispiel dieses Tutorial:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Bzw. hier die L2TP Variante:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Scheitern am IPsec VPN mit MikroTik
Zitat von @ennvee:
Hallo bluewonder, danke für die Antwort!
Meine Frage bezieht sich allerdings nicht auf die bestehenden VPNs (mit dem Windows Server hinter dem Router), sondern auf das neue IKEv1-VPN. Die existierenden L2TP-VPNs laufen alle (selbstverständlich mit NAT-T, ESP Prot 50, etc).
Das war leider durch deine Beschreibung nicht herauszulesen da Schema fehlt ...Hallo bluewonder, danke für die Antwort!
Meine Frage bezieht sich allerdings nicht auf die bestehenden VPNs (mit dem Windows Server hinter dem Router), sondern auf das neue IKEv1-VPN. Die existierenden L2TP-VPNs laufen alle (selbstverständlich mit NAT-T, ESP Prot 50, etc).
Der neue IKEv1-VPN-Server (also der externe, den ich nicht kontrolliere) steht ja nicht hinter einer NAT-Barriere, soweit ich das verstehe. Der hat ein eigenes WAN Interface.
OK.Meine Frage ist: funktioniert die Kommunikation zwischen Client --> Router --> IKEv1-VPN-Server problemlos, obwohl die IPSec Ports im Router vor dem Client in Richtung Windows-Server weitergeleitet sind? Nach meinem naiven Verständnis sollte das funktionieren, aber ich hätte das gerne von einem Fachkundigen bestätigt...
Ja das geht. Im Router muss aber kontrolliert werden ob das für die internen Clients auch freigeschaltet wurde. Aber ich würde hier das VPN hier immer am Perimeter terminieren statt das über multiple interne Clients abzufackeln, außerdem würde ich hier eher auf IKEv2 setzen das ist da wesentlich flexibler.Zitat von @aqui:
Moin,habe ich keinen Einfluss drauf
Mal ehrlich...WIE willst du ein funktionierendes IPsec VPN konfigurieren wenn du auf die wichtigste Komponente keinen Einfluß hast. Da kannst du zu 90% davon ausgehen das das in die Hose gehen wird. Als Admin benötigst du zwingend auf den Server Zugriff, wie sollte das sonst gehen ?! Unter den Voraussetzungen solltest du lieber schnell wegrennen und einen anderen scheitern lassen !ist Dir mal in den Sinn gekommen, dass der TO vom Betreiber der Fortinet die VPN-Daten gestellt bekommt, die er in seine Clients eintragen soll? Schon mal daran gedacht, dass die Fortinet evtl. bei einer anderen Firma / einem Dienstleister steht und der TO daher selbstverständlich keinen Zugriff drauf hat?
Gibst Du jedem Admin, der eine VPN-Verbindung zu einem von Dir betreuten System herstellen muss auch gleich immer den vollen Zugriff auf die von Dir betreuten Firewalls, damit jener Admin nicht schreiend weglaufen muss?
Manchmal sind die Antworten hier echt zum Kopfschütteln...
Grüße,
Torsten
Genau so ist es, wir kriegen nur die Zugangsdaten für das IKEv1-VPN, das ein externer Dienstleister betreibt. Deshalb leider auch v1, ohne dass ich was daran ändern könnte. An diesem VPN hängen nach meinem Kenntnisstand eine ganze Reihe von medizinischen Einrichtungen, deshalb sind die Konfigurationsmöglichkeiten extrem limitiert.
Das VPN wird nur unregelmäßig von jeweils genau einem unserer Clients benötigt, weshalb ich das lieber direkt auf dem Client zB mit Shrew Soft machen würde.
DS-Lite und CGN können wir verhindern, da wir die drei "Client-Sites" selber betreiben.
NAT-T ist auf dem IKEv1 VPN-Server ausgeschaltet, nach aktuellen Stand können wir das auch nicht aktivieren lassen.
Ich versuche das die Tage mal zu testen und melde mich dann wieder. Danke für die hilfreichen Antworten bis hierher!
@147069: Was genau meinst du mit "Im Router muss aber kontrolliert werden ob das für die internen Clients auch freigeschaltet wurde"?
Das VPN wird nur unregelmäßig von jeweils genau einem unserer Clients benötigt, weshalb ich das lieber direkt auf dem Client zB mit Shrew Soft machen würde.
DS-Lite und CGN können wir verhindern, da wir die drei "Client-Sites" selber betreiben.
NAT-T ist auf dem IKEv1 VPN-Server ausgeschaltet, nach aktuellen Stand können wir das auch nicht aktivieren lassen.
Ich versuche das die Tage mal zu testen und melde mich dann wieder. Danke für die hilfreichen Antworten bis hierher!
@147069: Was genau meinst du mit "Im Router muss aber kontrolliert werden ob das für die internen Clients auch freigeschaltet wurde"?
das ein externer Dienstleister betreibt.
Ein "externer" betreibt solch kritische Infrastruktur wie ein VPN ??! Dann kann man nur hoffen ihr wisst wirklich was ihr da tut. In einer Firmenumgebung normalerweise ein absolutes NoGo.Zumal dieser "Dienstleister" die Firewall auch noch vollkommen falsch vorbereitet hat für diesen Einsatzzweck...aber egal.
Ein Schelm wer Böses dabei denkt ...!
NAT-T ist auf dem IKEv1 VPN-Server ausgeschaltet,
Dann wirst du so oder so sofort scheitern...nach aktuellen Stand können wir das auch nicht aktivieren lassen.
Dann kannst du das Projekt gleich vergessen. Da hilft dann auch das tollste Administrator Forum nicht. Wasch mich aber mach mich nicht nass....Zitat von @aqui:
Entweder hast Du es nicht verstanden oder Du bist schon lange nicht mehr vor der Haustür in der realen Welt gewesen.das ein externer Dienstleister betreibt.
Ein "externer" betreibt solch kritische Infrastruktur wie ein VPN ??! Dann kann man nur hoffen ihr wisst wirklich was ihr da tut. In einer Firmenumgebung normalerweise ein absolutes NoGo.TO hat hier eine Dienstleistung aus dem medizinischen Bereich eingekauft, die bei diesem Dienstleister gehostet wird. Um diese Dienstleistung nutzen zu können, stellt dieser Dienstleister eine VPN-Einwahl in sein Rechenzentrum bereit. Den VPN-Endpunkt in seinem Rechenzentrum betreibt und konfiguriert natürlich der Dienstleister und ausschliesslich er. Wäre jawohl fatal, wenn da jeder Kunde dran rumfummeln könnte und dürfte.
Das ist Realität und absolut üblich.
Zumal dieser "Dienstleister" die Firewall auch noch vollkommen falsch vorbereitet hat für diesen Einsatzzweck...aber egal.
Ein Schelm wer Böses dabei denkt ...!
So so. Du kennst also ohne weitere Informationen komplett die Konfiguration der Firewall beim Dienstleister, so dass Du so eine polemische Aussage treffen kannst. Respekt. Ich gehe laut der Aussage des TO mal davon aus, dass der Dienstleister im medizinischen Bereich schon mehrere Kunden hat, die sich über VPN in dessen Rechenzentrum einwählen und bei denen das funktioniert. Kann dann wohl nicht "vollkommen falsch" sein.Ein Schelm wer Böses dabei denkt ...!
Eigentlich bin ich hier nur Mitleser im Forum... Einige Aussagen kann man aber einfach nicht umkommentiert stehen lassen.
@ennvee
An Deiner Stelle würde ich den Support des Dienstleisters mit ins Boot holen und alles weitere mit dem besprechen.
Zitat von @ennvee:
NAT-T ist auf dem IKEv1 VPN-Server ausgeschaltet, nach aktuellen Stand können wir das auch nicht aktivieren lassen.
Dann bist du leider gefi..t, und musst das VPN zwingend am Perimeter terminieren und evt. an der Firewall die Nutzung des Zielnetzes auf die jeweiligen internen Endgeräte beschränken.NAT-T ist auf dem IKEv1 VPN-Server ausgeschaltet, nach aktuellen Stand können wir das auch nicht aktivieren lassen.
@147069: Was genau meinst du mit "Im Router muss aber kontrolliert werden ob das für die internen Clients auch freigeschaltet wurde"?
Damit meine ich VPN Passthrough
@aqui: Ich bin nicht sicher, womit ich solche unfreundlichen Antworten verdient habe. Ich wollte einfach nur wissen, ob wir mit dem Port Forwarding der IPSec-Ports zu einem anderen PC (Windows Server) oder mit fehlendem NAT-T in unserem Setup ein Problem kriegen werden. Das hat nichts mit "wasch mich aber mach mich nicht nass" zu tun, sondern damit, die Anforderungen zu kennen und darauf reagieren zu können. Eine Dienstleistung einzukaufen, für die mir ein VPN-Tunnel bereitgestellt wird, sehe ich erst mal nicht als Sicherheitsrisiko oder als "NoGo". Und wie der Dienstleister seine Firewalls konfiguriert hat, geht mich ebenfalls wenig an - wenn er nen Einbruch hat, hat er auch die Verantwortung.
@PappaBaer2002: Ja, sind wir dran - aber die sind aktuell schwer erreichbar und haben sonst "einfache" Fälle mit Site-to-Site VPN über den Router.
@147069: Danke für die Rückmeldung, wir schauen nächste Woche, ob wir NAT-T aktivieren lassen können - sonst muss ich mir was einfallen lassen.
@PappaBaer2002: Ja, sind wir dran - aber die sind aktuell schwer erreichbar und haben sonst "einfache" Fälle mit Site-to-Site VPN über den Router.
@147069: Danke für die Rückmeldung, wir schauen nächste Woche, ob wir NAT-T aktivieren lassen können - sonst muss ich mir was einfallen lassen.
Ich würde das ganze ja anders aufziehen und die interne Windows Server VPN Seuche abschaffen und die VPNs alle auf den Routern terminieren und über ACLs Zugriffsrechte zuweisen dann ist das auch ordentlich.
und die VPNs alle auf den Routern terminieren und über ACLs Zugriffsrechte zuweisen dann ist das auch ordentlich.
Und so lösen es verantwortungsvolle Netzwerker auch immer. VPN Server gehören in die Peripherie und niemals in interne Netzwerk weil man so immer ungeschützten Internet Traffic per Port Forwarding ins lokale LAN lassen müsste. Normal ein NoGo im Design aus Sicherheitsgründen. Aber egal...vermutlich ist das eh wieder zu "unfreundlich". 😉
