28
VPN über UMTS
Moin,
ich habe folgendes Problem und möchte deshalb mal ein paar Tipps von erfahrenen Leuten haben:
Unser Unternehmen möchte einen Messrechner und Kameras bei einem Kunden betreiben und auf diese von unserem Standort via VPN zugreifen. Beim Kunden ist jedoch kein Internetanschluss verfügbar (Sachen gibts...), weshalb eine Internetverbindung via UMTS aufgebaut und mit VPN abgesichert werden soll. Nun hab ich schon recherchiert, dass ich um eine feste, öffentliche IP zu erhalten den Service von mDex (http://www.mdex.de/start/produkte/mdex-fixedip/) in Anspruch nehmen muss und das ganze dann nur mit Vodafone- und Telekom-Netzen funktioniert. Als Router würde ich wahrscheinlich den DrayTek Vigor 2820 (http://www.draytek.de/Produkt_Vigor2820.htm) verwenden. Nun zu meinen Fragen:
1. Sobald die UMTS-Verbindung unterbrochen wird, bricht auch die VPN Verbindung ab, dadurch kann ich ja kein neues Verbinden von Außen mehr anregen. Wie verhindere ich dies bestmöglich?
2. Mir stehen nur Prepaid-Tarife zur Verfügung, deshalb würde ich mich für Vodafone websessions entscheiden. Funktioniert hier eine VPN-Verbindung über IpSec?
3. Gibt es sonst Dinge, die ich beachten muss?
ich habe folgendes Problem und möchte deshalb mal ein paar Tipps von erfahrenen Leuten haben:
Unser Unternehmen möchte einen Messrechner und Kameras bei einem Kunden betreiben und auf diese von unserem Standort via VPN zugreifen. Beim Kunden ist jedoch kein Internetanschluss verfügbar (Sachen gibts...), weshalb eine Internetverbindung via UMTS aufgebaut und mit VPN abgesichert werden soll. Nun hab ich schon recherchiert, dass ich um eine feste, öffentliche IP zu erhalten den Service von mDex (http://www.mdex.de/start/produkte/mdex-fixedip/) in Anspruch nehmen muss und das ganze dann nur mit Vodafone- und Telekom-Netzen funktioniert. Als Router würde ich wahrscheinlich den DrayTek Vigor 2820 (http://www.draytek.de/Produkt_Vigor2820.htm) verwenden. Nun zu meinen Fragen:
1. Sobald die UMTS-Verbindung unterbrochen wird, bricht auch die VPN Verbindung ab, dadurch kann ich ja kein neues Verbinden von Außen mehr anregen. Wie verhindere ich dies bestmöglich?
2. Mir stehen nur Prepaid-Tarife zur Verfügung, deshalb würde ich mich für Vodafone websessions entscheiden. Funktioniert hier eine VPN-Verbindung über IpSec?
3. Gibt es sonst Dinge, die ich beachten muss?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 149615
Url: https://administrator.de/contentid/149615
Ausgedruckt am: 06.11.2024 um 04:11 Uhr
28 Kommentare
Neuester Kommentar
Auch Moin,
warum unbedingt eine feste IP-Adresse nötig ist hat sich mir noch nicht erschlossen.
Welche VPN-Technologie soll verwendet werden (meine Empehlung geht Richtung IPSec)?
Ist ein Site-to-Site- oder ein Remote-Access-VPN gewünscht?
Welche Devices stehen auf beiden Gegenstellen?
zu 1.)
Es gibt Kontroll-Mechanismen bei bestimmten VPN-Technolgien, die eine VPN-Unterbrechung ohne viele Probleme verkraften. Die Möglichkeit des Wieder-Neuaufbaus eines VPN's wird i. d. R. am VPN-Server realisiert (und damit auch dem Client mitgegeben).
zu 2.)
Vodafone muss die jeweils zu nutzenden VPN-Protokolle durchleiten. Dann sollte alles funktionieren.
zu 3.)
Das VPN sollte korrekt konfiguriert und ggf. in einzeln Bestandteilen etwas getunt werden.
Viele Gruesse...
warum unbedingt eine feste IP-Adresse nötig ist hat sich mir noch nicht erschlossen.
Welche VPN-Technologie soll verwendet werden (meine Empehlung geht Richtung IPSec)?
Ist ein Site-to-Site- oder ein Remote-Access-VPN gewünscht?
Welche Devices stehen auf beiden Gegenstellen?
zu 1.)
Es gibt Kontroll-Mechanismen bei bestimmten VPN-Technolgien, die eine VPN-Unterbrechung ohne viele Probleme verkraften. Die Möglichkeit des Wieder-Neuaufbaus eines VPN's wird i. d. R. am VPN-Server realisiert (und damit auch dem Client mitgegeben).
zu 2.)
Vodafone muss die jeweils zu nutzenden VPN-Protokolle durchleiten. Dann sollte alles funktionieren.
zu 3.)
Das VPN sollte korrekt konfiguriert und ggf. in einzeln Bestandteilen etwas getunt werden.
Viele Gruesse...
Vielen dank für die schnelle Antwort.
Ich hatte mir vorgestellt eine Site-to-End-Verbindung aufzubauen und den Router als VPN-Server zu benutzen, sprich beim Kunden steht der Router mitsamt den Kameras und dem Messrechner und unser Mitarbeiter kann sich mit seinem PC und einer entsprechenden Client-Software zum Router verbinden. Der Kunde hat übrigens keinen Zugriff aufs Netz, das ganze soll der Fernwartung dienen.
Joa, IPSec hatte ich ja auch gedacht.
Ich hatte mir vorgestellt eine Site-to-End-Verbindung aufzubauen und den Router als VPN-Server zu benutzen, sprich beim Kunden steht der Router mitsamt den Kameras und dem Messrechner und unser Mitarbeiter kann sich mit seinem PC und einer entsprechenden Client-Software zum Router verbinden. Der Kunde hat übrigens keinen Zugriff aufs Netz, das ganze soll der Fernwartung dienen.
Joa, IPSec hatte ich ja auch gedacht.
Ich empfehle eine UMTS Verbindung mit dem Partner Virprinet (www.viprinet.de). Hier ist Bundeling verschiedener UMTS-Verbindungen in einem Router möglich. Zur Ausfallsicherheit können Sie dann hier auch z.B. 2-4 verschiedenen Provider kombinieren. Beachten Sie bitte, dass alle Anbieter in Deutschland den Traffic über HSDPA auf 5 GB / pro Monat beschränken. Viprinet bietet hier eine Exklusivlösung mit Vodafone an, die auf 30 GB für 79 Euro im Monat beschränkt ist. Als Backup würde ich diese Verbindung mit einer T-Mobile (dayflat) kombinieren, die nur bezahlt werden muss wenn die Leitung, (bei Ausfall von Vodafone) , genutzt wird kostet dann 4,95 Euro pro Backuptag.
Vorteil ist hier dass ein Ausfall beider Anbieter unwahrscheinlich ist, so ist der VPN-Tunnel auch jederzeit verfügbar. Sie können hier auch mehrere Module kombinieren, die aktiv genutzt werden um die Bandbreite entsprechend zu erhöhen. Der Router bündelt diese dann zu einer Verbindung.
IPsec verwendet einen 256bit Standardschlüssel, welcher keine ausreichende Sicherheit bietet. Also nicht zu empfehlen.
Vorteil ist hier dass ein Ausfall beider Anbieter unwahrscheinlich ist, so ist der VPN-Tunnel auch jederzeit verfügbar. Sie können hier auch mehrere Module kombinieren, die aktiv genutzt werden um die Bandbreite entsprechend zu erhöhen. Der Router bündelt diese dann zu einer Verbindung.
IPsec verwendet einen 256bit Standardschlüssel, welcher keine ausreichende Sicherheit bietet. Also nicht zu empfehlen.
IPsec ist sicher genug wenn man IKEv2 nutzt für die Aushandlung der Verschlüsselungsprotokolle.
Mein zentrales Problem ist doch, dass ich die Wiedereinwahl des Routers nur über VPN ausführen kann, da ich ja nicht beim Kunden sitze. Das VPN aber nicht funktioniert wenn ioch nicht eingewählt bin. Man könnte es auch als Teufelskreis bezeichnen. Dabei rede ich noch nicht einmal von der allgemeinen Ausfallsicherheit, da ich wie eben geschildert einne Prepaid-Tarif (mit Monatsflat) nutzen muss/soll reicht es ja schon aus, dass ein Mitarbeiter vergisst vor Ablauf des Monats einen neuen Monat zu buchen und schon haben wir uns selbst ausgesperrt.
Fuer genau dieses Problem gibt es DPD (RFC 3706), den man aktivieren sollte auf ein Minimum (Anhängig von der Geschwindigkeit der Leitung) tunen kann, sofern der Router das Feature mit einigen Konfigurationsmöglichkeiten in vollem Umfang bietet. Die ggf. durch einen anderen UMTS-Provider bedingte andere IP-Adresse kann als Backup-Peer im IPSec-Client eingetragen werden.
IPSec ist derzeit der sicherste Standard, der übrigens auch vom BSI empfohlen wird, sofern man Verschlüsselung und Hashing nutzt. Dabei ist IKEv2 als Protokoll nur etwas getunt im Vergleich zu IKEv1, nutzt jedoch die gleichen Verschlüsselungs- und Hashing-Algorithmen. Somit macht es keinen Unterschied. Die letztendlichen Daten-Tunnel innerhalb der IPSec-Protokoll-Suite (also 2x ESP-Tunnel) sind dann nach den gleichen Methoden geschützt.
Trotzdem habe ich den geplanten Aufbau ggf. noch nicht ganz verstanden:
- UMTS-VPN-Router (Vigor 2820) als VPN-Endpunkt steht beim Kunden und fungiert als VPN-Server fuer Remote-VPN-Einwahl mit VPN-Client-Software.
- hat der Router sonst noch eine Site-to-Site-VPN-Kopplung zum eigenen Unternehmen? Dann könnte dieses bereits vom Mitarbeiter genutzt werden.
- wird dann noch aus dem freien Internet eine Remote-VPN-Einwahl benötigt?
Schöne Grüsse...
IPSec ist derzeit der sicherste Standard, der übrigens auch vom BSI empfohlen wird, sofern man Verschlüsselung und Hashing nutzt. Dabei ist IKEv2 als Protokoll nur etwas getunt im Vergleich zu IKEv1, nutzt jedoch die gleichen Verschlüsselungs- und Hashing-Algorithmen. Somit macht es keinen Unterschied. Die letztendlichen Daten-Tunnel innerhalb der IPSec-Protokoll-Suite (also 2x ESP-Tunnel) sind dann nach den gleichen Methoden geschützt.
Trotzdem habe ich den geplanten Aufbau ggf. noch nicht ganz verstanden:
- UMTS-VPN-Router (Vigor 2820) als VPN-Endpunkt steht beim Kunden und fungiert als VPN-Server fuer Remote-VPN-Einwahl mit VPN-Client-Software.
- hat der Router sonst noch eine Site-to-Site-VPN-Kopplung zum eigenen Unternehmen? Dann könnte dieses bereits vom Mitarbeiter genutzt werden.
- wird dann noch aus dem freien Internet eine Remote-VPN-Einwahl benötigt?
Schöne Grüsse...
Bei reinen, billigen Consumer Surf only Tarifen droht dir noch das hier:
VPN per UMTS Karte - Tunnel steht - aber Netz dahinter nicht anpingbar !?
Dann kannst du ohne NAT-Traversal Funktion kein IPsec VPN aufbauen wenn du private RFC 1918 IP Adressen im UMTS Netz vom Provider bekommst. Besser ist also immer ein Tarif mit einer öffentlichen IP.
Was deine VPN Einwahl anbetrifft machst du vermutlich einen Denkfehler da dir die Funktion vermutlich nicht bekannt ist. Auch wenn du den Prepaid Tarif einmal nicht bedienst verliert der Router die Möglichkeit sich ins UMTS Netz einzubuchen und damit bricht natürlich dann auch der VPN Tunnel ab, das ist logisch !
Sobald du aber per Geldautomat, Internetbanking usw. das Prepaid Konto wieder auflädst bucht sich der Router sofort automatisch wieder ins UMTS Netz ein und du kannst dann auch sofort wieder einen VPN Tunnel zu ihm aufbauen !!
Wo ist da also dein Problem... ??
Auch eine feste IP ist nicht vonnöten. Der o.a. Draytek oder z.B. das 2910er Modell
http://www.draytek.de/Beispiele_html/Anwendungen/V2910_3G.htm
supporten DynDNS. Damit hast du trotz wechselnder IP immer einen festen Hostnamen wie z.B. messrechner.dnsalias.com
http://www.dyndns.com/services/dns/dyndns/domains.html
Ansonsten ist das Konzept mit dem Router richtig und OK.
VPN per UMTS Karte - Tunnel steht - aber Netz dahinter nicht anpingbar !?
Dann kannst du ohne NAT-Traversal Funktion kein IPsec VPN aufbauen wenn du private RFC 1918 IP Adressen im UMTS Netz vom Provider bekommst. Besser ist also immer ein Tarif mit einer öffentlichen IP.
Was deine VPN Einwahl anbetrifft machst du vermutlich einen Denkfehler da dir die Funktion vermutlich nicht bekannt ist. Auch wenn du den Prepaid Tarif einmal nicht bedienst verliert der Router die Möglichkeit sich ins UMTS Netz einzubuchen und damit bricht natürlich dann auch der VPN Tunnel ab, das ist logisch !
Sobald du aber per Geldautomat, Internetbanking usw. das Prepaid Konto wieder auflädst bucht sich der Router sofort automatisch wieder ins UMTS Netz ein und du kannst dann auch sofort wieder einen VPN Tunnel zu ihm aufbauen !!
Wo ist da also dein Problem... ??
Auch eine feste IP ist nicht vonnöten. Der o.a. Draytek oder z.B. das 2910er Modell
http://www.draytek.de/Beispiele_html/Anwendungen/V2910_3G.htm
supporten DynDNS. Damit hast du trotz wechselnder IP immer einen festen Hostnamen wie z.B. messrechner.dnsalias.com
http://www.dyndns.com/services/dns/dyndns/domains.html
Ansonsten ist das Konzept mit dem Router richtig und OK.
" UMTS-VPN-Router (Vigor 2820) als VPN-Endpunkt steht beim Kunden und fungiert als VPN-Server fuer Remote-VPN-Einwahl mit VPN-Client-Software."
Jupp
" hat der Router sonst noch eine Site-to-Site-VPN-Kopplung zum eigenen Unternehmen? Dann könnte dieses bereits vom Mitarbeiter genutzt werden"
Nein, die Remote-VPN-Einwahl ist die einzige Verbindung von unserem Unternehmen ins VPN
"wird dann noch aus dem freien Internet eine Remote-VPN-Einwahl benötigt"
Joa
Jupp
" hat der Router sonst noch eine Site-to-Site-VPN-Kopplung zum eigenen Unternehmen? Dann könnte dieses bereits vom Mitarbeiter genutzt werden"
Nein, die Remote-VPN-Einwahl ist die einzige Verbindung von unserem Unternehmen ins VPN
"wird dann noch aus dem freien Internet eine Remote-VPN-Einwahl benötigt"
Joa
Die Idee mit der festen IP-Adresse hab ich aus diesem Blog: http://m2m-blog.de/2009/03/10/dyndns-fur-m2m-anwendungen-mit-gprsedgeum ...
und wenn das mit dem automatischen Wiedereinwählen so funktioniert, dann müsste ich nurnoch die entsprechende Flatrate (Tagesflat/Monatsflat) von einem beliebigen Rechner aus buchen können, dann sollte es gehen.
Vielen dank
und wenn das mit dem automatischen Wiedereinwählen so funktioniert, dann müsste ich nurnoch die entsprechende Flatrate (Tagesflat/Monatsflat) von einem beliebigen Rechner aus buchen können, dann sollte es gehen.
Vielen dank
Hmm...
Dann ist eine private IP am UMTS-VPN-Router nicht möglich, sondern eine public IP (und ggf. DynDNS zwingend) erforderlich.
Wie soll das NAT-Gerät des Providers denn wissen, welche dahinterliegende private IP-Adresse gemeint ist. Port-Forwarding wird er dafür nicht einrichten, was für die IPSec-Protokoll-Suite auch schwierig (mit stateful Firewalls dennoch nicht unslösbar) ist.
Ein Site-to-Site-VPN (LAN-to-LAN-Kopplung) zum eigenen Unternehmen, während der UMTS-VPN-Router der VPN-Initiator mit ständigem Interesting-Traffic, liesse vieles einfacher werden. Gibt es im eigen Unternehmen eine IPSec-fähige Gegenstelle?
Viele Grüsse...
Dann ist eine private IP am UMTS-VPN-Router nicht möglich, sondern eine public IP (und ggf. DynDNS zwingend) erforderlich.
Wie soll das NAT-Gerät des Providers denn wissen, welche dahinterliegende private IP-Adresse gemeint ist. Port-Forwarding wird er dafür nicht einrichten, was für die IPSec-Protokoll-Suite auch schwierig (mit stateful Firewalls dennoch nicht unslösbar) ist.
Ein Site-to-Site-VPN (LAN-to-LAN-Kopplung) zum eigenen Unternehmen, während der UMTS-VPN-Router der VPN-Initiator mit ständigem Interesting-Traffic, liesse vieles einfacher werden. Gibt es im eigen Unternehmen eine IPSec-fähige Gegenstelle?
Viele Grüsse...
Hallo dave,
bitte beachte aber den Hinweis von aqui bzgl. der günstigen Tarife im Consumerumfeld.
VPN per UMTS Karte - Tunnel steht - aber Netz dahinter nicht anpingbar !?
So ich es in Erinnerung habe, passiert das auch bei Vodafone Websessions.
bitte beachte aber den Hinweis von aqui bzgl. der günstigen Tarife im Consumerumfeld.
VPN per UMTS Karte - Tunnel steht - aber Netz dahinter nicht anpingbar !?
So ich es in Erinnerung habe, passiert das auch bei Vodafone Websessions.
Jupp, dass passiert bei privaten Adressen. Ssoweit ich weiß, aber das muss ich dann nochmals explizit beim Provider nachfragen, sollte es im T-Mobile und Vodafone-Netz funzen.
Vielen Dank.
Vielen Dank.
Zitat von @dave-g86:
Jupp, dass passiert bei privaten Adressen. Ssoweit ich weiß, aber das muss ich dann nochmals explizit beim Provider
nachfragen, sollte es im T-Mobile und Vodafone-Netz funzen.
Ich habe doch aber auch gesagt, dass das mit Websessions auch passiert, oder?Jupp, dass passiert bei privaten Adressen. Ssoweit ich weiß, aber das muss ich dann nochmals explizit beim Provider
nachfragen, sollte es im T-Mobile und Vodafone-Netz funzen.
Und dieser Tarif ist von Vodafone.
BTW: Es gibt dutzende Reseller/Provider, die die Netze von Vodafone/T-Mobile nutzen und trotzdem private IPs verteilen.
Keine Angst ich hab deinen vorherigen Beitrag schon gelesen, ich werd das deswegen auch nochmals explizit beim Provider klären. Ich war nur der Meinung dass es mit Vodafone geht wegen http://www.mdex.de/start/produkte/mdex-fixedip/ und http://m2m-blog.de/2009/03/10/dyndns-fur-m2m-anwendungen-mit-gprsedgeum ...
Moin,
also ich habe damals auch die VPN Einwahl auf einen Server der über UMTS ans Netz angebunden war mit MDEx realisiert und das läuft soweit auch ganz gut.
Ob du Mdex auch mit der Vodafone Websession nutzen kannst, würde ich mit MDex klären. Die haben mir damals auch erstmal nur einen 30 Tage Testzugang geschaltet.
Ganz am Anfang brauchte ich bei MDex zwei Zugänge, was aber jetzt mit der MDexpublicIP nicht mehr notwendig ist und für unseren Kunden einfacher. Seit ungefähr 6 Monaten hat unser Kunde dieses Produkt im Einsatz. Er will mit verschiedenen mobilen Endgeräten auf einen Webserver zugreifen.
Vielleicht ist es bei dir aber besser, wenn du mdexfixedIP und einen mobilen Zugang via MDexOpenVPN dazu buchst. Dann brauchst du nämlich gar keinen VPN- Server mehr, weil MDex dann direkt den VPN- Tunnel zur Verfügung stellt.
also ich habe damals auch die VPN Einwahl auf einen Server der über UMTS ans Netz angebunden war mit MDEx realisiert und das läuft soweit auch ganz gut.
Ob du Mdex auch mit der Vodafone Websession nutzen kannst, würde ich mit MDex klären. Die haben mir damals auch erstmal nur einen 30 Tage Testzugang geschaltet.
Ganz am Anfang brauchte ich bei MDex zwei Zugänge, was aber jetzt mit der MDexpublicIP nicht mehr notwendig ist und für unseren Kunden einfacher. Seit ungefähr 6 Monaten hat unser Kunde dieses Produkt im Einsatz. Er will mit verschiedenen mobilen Endgeräten auf einen Webserver zugreifen.
Vielleicht ist es bei dir aber besser, wenn du mdexfixedIP und einen mobilen Zugang via MDexOpenVPN dazu buchst. Dann brauchst du nämlich gar keinen VPN- Server mehr, weil MDex dann direkt den VPN- Tunnel zur Verfügung stellt.
Eventuell gibt es diese, nur werd ich die dafür nicht benutzen können. Das ganze soll nach meinem Wissen erstmal zu Testzwecken dienen, die endgültige Lösung kann dann durchaus anders aussehen.
Nur mal rein interessehalber: Wenn ich mich für eine Site-To-Site-Verbindung entscheiden würde und wir in unserem Unternehmen einen VPN-Server mit fester IP hätten, bräuchte ich dann für den UMTS-Router trotzdem noch eine feste IP, oder würde das auch so gehen.
In dem Fall könnte es so sein:
- mit dem jeweiligen Provider immer vorher klaeren, ob er die IPSec-Protokoll-Suite (IKE, ESP) durchleitet
- mit dem jeweiligen Provider immer vorher klaeren, ob er bei privater IP am Router eine feste NAT-/PAT-IP vergibt oder nicht
- VPN-Server (Router/Firewall/etc.) steht im eigenen Unternehmen mit fester public IP
- UMTS-Router steht beim Kunden (als Site-to-Site-Router oder VPN-Hardware-Client)
- Site-to-Site bei ggf. privater IP am Router dann meines Wissens nur mit Cisco-Implementierung möglich (wegen NAT)
- bei Site-to-Site könnte statt IP die gegenseitige Identifikation per DNS (DynDNS bei variablem PAT) oder Geräte-Namen stattfinden
- Router mit redundanter UMTS-Provider-Anbindung liefern automatisches Umrouten im Fehlerfall (ggf. inkl. Rückschwenk)
- als VPN-Hardware-Client sollte die 'Netzwerkerweiterung' konfiguriert sein, um das gesamte Client-Netz erreichen zu können
- UMTS-Router ist in jedem Fall der Initiator des VPN's (feste Ziel-IP im eigenen Unternehmen)
- bestehender Tunnel kann rückwarts vom eigenen Unternehmen aus genutzt werden (Zugriff auf Kamera, etc.)
- der VPN im eigenen Unternehmen kann auch fuer Remote-Einwahl (Arbeiten von unterwegs/zu Hause) genutzt werden
- Syslog-Daten des UMTS-Routers zum eigenen Unternehmen liefern letzte public IP und ggf. letztes Problem im VPN
- Syslog-Daten des eigenen VPN-Servers liefern ggf. eindeutige Hinweise auf Problem im VPN
Hinweis: Ich kann nur aus Erfahrungen mit Cisco-Geräten sprechen, dies ist nie eine Garantie, dass auch andere Geräte diese Möglichkeiten (oder Teile davon) unterstützen.
Weitere Fragen? Gerne...
Schöne Grüsse...
- mit dem jeweiligen Provider immer vorher klaeren, ob er die IPSec-Protokoll-Suite (IKE, ESP) durchleitet
- mit dem jeweiligen Provider immer vorher klaeren, ob er bei privater IP am Router eine feste NAT-/PAT-IP vergibt oder nicht
- VPN-Server (Router/Firewall/etc.) steht im eigenen Unternehmen mit fester public IP
- UMTS-Router steht beim Kunden (als Site-to-Site-Router oder VPN-Hardware-Client)
- Site-to-Site bei ggf. privater IP am Router dann meines Wissens nur mit Cisco-Implementierung möglich (wegen NAT)
- bei Site-to-Site könnte statt IP die gegenseitige Identifikation per DNS (DynDNS bei variablem PAT) oder Geräte-Namen stattfinden
- Router mit redundanter UMTS-Provider-Anbindung liefern automatisches Umrouten im Fehlerfall (ggf. inkl. Rückschwenk)
- als VPN-Hardware-Client sollte die 'Netzwerkerweiterung' konfiguriert sein, um das gesamte Client-Netz erreichen zu können
- UMTS-Router ist in jedem Fall der Initiator des VPN's (feste Ziel-IP im eigenen Unternehmen)
- bestehender Tunnel kann rückwarts vom eigenen Unternehmen aus genutzt werden (Zugriff auf Kamera, etc.)
- der VPN im eigenen Unternehmen kann auch fuer Remote-Einwahl (Arbeiten von unterwegs/zu Hause) genutzt werden
- Syslog-Daten des UMTS-Routers zum eigenen Unternehmen liefern letzte public IP und ggf. letztes Problem im VPN
- Syslog-Daten des eigenen VPN-Servers liefern ggf. eindeutige Hinweise auf Problem im VPN
Hinweis: Ich kann nur aus Erfahrungen mit Cisco-Geräten sprechen, dies ist nie eine Garantie, dass auch andere Geräte diese Möglichkeiten (oder Teile davon) unterstützen.
Weitere Fragen? Gerne...
Schöne Grüsse...
Vielen Dank für eure Mühe,
Also versteh ich das richtig, dass der Provider für den UMTS-Router bei einer Site-to-Site-Verbindung entweder eine öffentliche Adresse, oder eine private mit fester NAT-/PAT-IP vergeben muss, damit das funktioniert?
" Site-to-Site bei ggf. privater IP am Router dann meines Wissens nur mit Cisco-Implementierung möglich (wegen NAT)"
Was meinst du mit Cisco-Implementierung?
Gruß
Also versteh ich das richtig, dass der Provider für den UMTS-Router bei einer Site-to-Site-Verbindung entweder eine öffentliche Adresse, oder eine private mit fester NAT-/PAT-IP vergeben muss, damit das funktioniert?
" Site-to-Site bei ggf. privater IP am Router dann meines Wissens nur mit Cisco-Implementierung möglich (wegen NAT)"
Was meinst du mit Cisco-Implementierung?
Gruß
Zur ersten Frage:
Bei der Fragestellung muss ich antworten: Nein, nicht zwingend.
Eine öffentliche IP am Router ist etwas einfacher als eine private IP zu handhaben.
Eine feste öffentliche IP (am Router oder NAT/PAT) ist etwas einfacher als eine dynamische öffentliche IP zu handhaben.
Möglich ist (fast) alles, jedoch nur mit der richtigen Hard- und Software, die das gewünschte eben auch kann.
Zur zweiten Frage:
Cisco-Implementierung bedeutet, dass die beiden Gegenstellen in Hard- bzw. Software aus dem Hause Cisco stammt.
Hier gehe ich oftmals von Cisco-eigenen Zusatz-Implementierungen im Umgang mit IPSec aus (DPD, NAT-T, usw.).
Ich weiss leider nicht, ob die Vigor-Router die gleichen Möglichkeiten bieten, da ich mit solchen Geräten keinerlei Erfahrung habe.
Viele Grüsse...
Bei der Fragestellung muss ich antworten: Nein, nicht zwingend.
Eine öffentliche IP am Router ist etwas einfacher als eine private IP zu handhaben.
Eine feste öffentliche IP (am Router oder NAT/PAT) ist etwas einfacher als eine dynamische öffentliche IP zu handhaben.
Möglich ist (fast) alles, jedoch nur mit der richtigen Hard- und Software, die das gewünschte eben auch kann.
Zur zweiten Frage:
Cisco-Implementierung bedeutet, dass die beiden Gegenstellen in Hard- bzw. Software aus dem Hause Cisco stammt.
Hier gehe ich oftmals von Cisco-eigenen Zusatz-Implementierungen im Umgang mit IPSec aus (DPD, NAT-T, usw.).
Ich weiss leider nicht, ob die Vigor-Router die gleichen Möglichkeiten bieten, da ich mit solchen Geräten keinerlei Erfahrung habe.
Viele Grüsse...
Das Problem bei privaten IPs ist das der Provider dann irgendwo NAT macht. Auf dieses NAT Gateway hast du aber logischerweise keinen Einfluss um dort z.B. ein zwindendes Port Forwarding für dein VPN Protokoll eintragen zu können. Fazit ist dann das daran so gut wie alle VPN Verbindungen scheitern.
Es gibt aber bei IPsec VPNs das feature NAT Traversal was Cisco supportet und z.B. auch Draytek.
Damit lassen sich dann IPsec VPN Verbindungen auch über ein NAT Gateway herstellen. In der Beziehung irrst du also gewaltig das nur Cisco das kann, denn NAT Traversal ist ein Standard weltweit. Auch billigen Consumer VPN Routern ist es aber oft einfach aus Kostengründen nicht implementiert !
Andere supporten es daher nicht und dann scheitert es.
Das solltest du also sicher vorher klären oder mit öffentlichen IPs auf Nummer sicher gehen.
Wenn du einen Cisco hast kannst du die Site to Site Kopplung auch vom Cisco auf den Draytek machen oder ein separates Draytek Pärchen benutzen.
Infos dazu findest du z.B. hier:
http://www.draytek.de/Beispiele_html/VPN/Autarkes_VPN_Netzwerk.htm
http://www.draytek.de/Beispiele_html/VPN/LAN-LAN-IPSec-Aggressive.htm
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Eine feste IP braucht man de facto nicht, es klappt auch mit DynDNS Hostadressen. Ein Site to Site Router wie der o.a. Draytek ist übrigens immer beides er kann VPN Sessions annehmen (Server) oder selber aufbauen (Client).
Es gibt aber bei IPsec VPNs das feature NAT Traversal was Cisco supportet und z.B. auch Draytek.
Damit lassen sich dann IPsec VPN Verbindungen auch über ein NAT Gateway herstellen. In der Beziehung irrst du also gewaltig das nur Cisco das kann, denn NAT Traversal ist ein Standard weltweit. Auch billigen Consumer VPN Routern ist es aber oft einfach aus Kostengründen nicht implementiert !
Andere supporten es daher nicht und dann scheitert es.
Das solltest du also sicher vorher klären oder mit öffentlichen IPs auf Nummer sicher gehen.
Wenn du einen Cisco hast kannst du die Site to Site Kopplung auch vom Cisco auf den Draytek machen oder ein separates Draytek Pärchen benutzen.
Infos dazu findest du z.B. hier:
http://www.draytek.de/Beispiele_html/VPN/Autarkes_VPN_Netzwerk.htm
http://www.draytek.de/Beispiele_html/VPN/LAN-LAN-IPSec-Aggressive.htm
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Eine feste IP braucht man de facto nicht, es klappt auch mit DynDNS Hostadressen. Ein Site to Site Router wie der o.a. Draytek ist übrigens immer beides er kann VPN Sessions annehmen (Server) oder selber aufbauen (Client).
In der Beziehung irrst du also gewaltig das nur Cisco das kann, denn NAT Traversal ist ein Standard weltweit.
Ja, grundsaetzlich hast Du Recht. Aber kann Draytek auch NAT-T in Site-to-Site-VPN's?
Ich kenne nur die Cisco-Implementierung. Dort ging es lange Zeit nicht für Site-to-Site-VPN's und wurde später nach-implementiert.
Sollte ich mich irren, lerne ich gerne stetig dazu.
Viele Grüsse...
Okay, Leute ihr habt mir sehr geholfen, jetzt weiß ich an welchen Stellen ich noch Infos einholen muss. Sollten weitere Fragen auftreten, weiß ich ja wo ich mich hinwenden muss 
Gruß
Gruß
@krachtor
Das ist eine gute Frage....da müsste man mal den Draytek Support kontaktieren. Da der Draytek auf den Cisco problemlos IPsec LAN to LAN VPN Sessions aufbauen kann und auch umgekehrt ist das fast anzunehmen. Freie Lösungen wie z.B. Pfsense oder Monowall können das entsprechend auch:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
NAT-T kann man dort in der Konfig explizit angeben so das zu vermuten ist das auch NAT-T auch bei Draytek supportet ist.
@dave-g86
Wenns das denn war bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
NICHT vergessen !!
Das ist eine gute Frage....da müsste man mal den Draytek Support kontaktieren. Da der Draytek auf den Cisco problemlos IPsec LAN to LAN VPN Sessions aufbauen kann und auch umgekehrt ist das fast anzunehmen. Freie Lösungen wie z.B. Pfsense oder Monowall können das entsprechend auch:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
NAT-T kann man dort in der Konfig explizit angeben so das zu vermuten ist das auch NAT-T auch bei Draytek supportet ist.
@dave-g86
Wenns das denn war bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
NICHT vergessen !!
Hi aqui,
vielen Dank fuer den Hinweis, der leider nicht auf die obigen Ausführungen passt:
Die oben angebene URL stellt nur dar, dass zwei private Netze (172.16.1.0/24 hinter Cisco und 172.32.1.0/24 hinter Monowall) hinter zwei VPN-Peers mit zwei VPN-Peers (Cisco und Monowall mit jeweils 192.168.100.x/32, noch dazu im gleichen Netzwerk-Segment ohne Routing) mit jeweils einer (sicher als public IP gemeinten) privaten 192.-er IP am jeweiligen Perimeter-Interface durch ein 'VPN' getunnelt werden.
Somit stellt die URL keinerlei Nachweis dafür dar, ob Monowall bzw. Draytek tatsächlich NAT-T via Site-to-Site-VPN unterstützt. Dann müsste nämlich ein Peer über ein NAT-Device laufen. Das ist in diesem Beispiel nicht gegeben. Auch die angegebene Cisco-Config sieht das nicht vor.
Weiterhin ist in der Config der Monowoll gar kein NAT-T aktiviert. Das ist in diesem Beispiel ja auch nicht nötig...
Viele Gruesse,
vielen Dank fuer den Hinweis, der leider nicht auf die obigen Ausführungen passt:
Die oben angebene URL stellt nur dar, dass zwei private Netze (172.16.1.0/24 hinter Cisco und 172.32.1.0/24 hinter Monowall) hinter zwei VPN-Peers mit zwei VPN-Peers (Cisco und Monowall mit jeweils 192.168.100.x/32, noch dazu im gleichen Netzwerk-Segment ohne Routing) mit jeweils einer (sicher als public IP gemeinten) privaten 192.-er IP am jeweiligen Perimeter-Interface durch ein 'VPN' getunnelt werden.
Somit stellt die URL keinerlei Nachweis dafür dar, ob Monowall bzw. Draytek tatsächlich NAT-T via Site-to-Site-VPN unterstützt. Dann müsste nämlich ein Peer über ein NAT-Device laufen. Das ist in diesem Beispiel nicht gegeben. Auch die angegebene Cisco-Config sieht das nicht vor.
Weiterhin ist in der Config der Monowoll gar kein NAT-T aktiviert. Das ist in diesem Beispiel ja auch nicht nötig...
Viele Gruesse,
Nur der Vollständigkeit halber, vom DrayTek-Support kam heute folgende Mail:
"[...] der Vigor2820 Serie unterstützt NAT- T. Dies gilt für LAN zu LAN und Host zu LAN [...]"
Gruß
"[...] der Vigor2820 Serie unterstützt NAT- T. Dies gilt für LAN zu LAN und Host zu LAN [...]"
Gruß
Cool, dann sollte Dein Konzept inzwischen stehen.
Viele Grüsse...
Viele Grüsse...
Kommentar gelöscht, da es sich um eine neue Frage handelt.
Sorry ...
Sorry ...
