VPN über UMTS

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.

IPsec ist sicher genug wenn man IKEv2 nutzt für die Aushandlung der Verschlüsselungsprotokolle.

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...

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.

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...

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.

Ich habe doch aber auch gesagt, dass das mit Websessions auch passiert, oder?
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.

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.

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...

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...

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).

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...

@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
How can I mark a post as solved?
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,

Cool, dann sollte Dein Konzept inzwischen stehen.

Viele Grüsse...