6
VPN über UMTS schlägt fehl
Ich nutze die Sonicwall Virtualadapter VPN Client Version "18-001457-00_revAGVCSetup64" und will mich per UMTS USB Stick in den VPN Tunnel einwählen. Das Klappt aber nicht.
Guten Abend,
Wie oben schon beschrieben kommt der VPN Tunnel nicht zu stande. Doch bevor ich weiter schreibe hier ein paar backgrounds:
- Notebook Win 7 64Bit SP1 + aktuelle Patches
- Sonicwall Virtualadapter VPN Client Version "18-001457-00_revAGVCSetup64
- Vodafone Mobile Broeadband Model: K3765 Usb Stick
- Vodafone Mobile Broadband v10.2
- Firmware des Stick = 11.126.03.09.00
Was geht ist folgendes:
- VPN over LAN
- VPN over WLAN
- Inet over WLAN
- Inet over LAN
- INET over USB UMTS Modem
(Folgendes Problem existiert auch bei ausgeschaltener Antvirensoftware und ausgeschaltener Windows Firewall)
Der VPN Handshake klappt wie folgt:
1) Einrichtung der Verbindung
2) anwählen und Preshared Key eingeben
3) Benutzer Login ausführen
4) Nutzer wird korrekt erkannt, erhällt Erlaubnis
5) DHCP wird kontaktiert um die IP ab zu rufen
und hier bleibt er hängen..
..aquireing ip...
Folgendes ist seltsam - wenn ich dem Virtual Adapter aber eine IP zuweise, entfällt die IP zuweisung und
die VPN Verbindung steht als Established / Connected da. IST ES ABER NICHT... der Ping auf das Gerät klappt
nicht und vom Gerät aus nach innen auf einen unserer PCs oder Server geht auch nicht durch.
An der Authentifizierung kann es nicht liegen.
Ein Merkmal das mir spanisch vorkommt ist das bei der manuellen Konfiguration des Sonicwall Virtual adapter zwar
IP und Subnet bleiben - er schmeisst aber jedesmal das Standardgateway aus der Konfiguration. warum begreife ich nicht.
Ich habe auch schon bei der Sonicwall Verbindung in den Eigenschaften die automatische Suche auf "LAN ONLY" umgestellt.
mit dem Erfolg das die Dial IN Meldung weg blieb. Und ich den Benutzer login zu Gesicht bekomme.
Der Versuch eine Dial In Verbindung über folgenden Weg ein zu richten führte auch zu keiner Lösung:
How To:
Systemsteuerung/ Telefon und Modem/ Modems/
Doppelklick auf das UMTS Modem und bei \"Erweitert\" folgenden Eintrag machen: +CGDCONT=1,"IP","web.vodafone.de" bei web.vodafone.de den entsprechenden APN Eintrag deines Providers verwenden. Alle Fenster bestätigen und schließen Netzwerk und Freigabecenter öffnen
"Neue Verbindung oder neues Netzwerk einrichten" \ "Wählverbindung einrichten" / weiter / UMTS Modem auswählen - bei Einwahl Rufnummer: *99# eintragen und unter Verbindungsname dem Kind einen Namen geben z.B. UMTSVPN - Verbinden anklicken Die neu erstellte Verbindung erscheint nun im Phonebook und kann vom Global VPN Client verwendet werden.
Inzwischen weis ich nicht mehr weiter. Hat wer noch ne Idee was ich noch ausprobieren kann?? Denn Dummerweise ist die UMTS
Verbindung die für das Notebook am wichtigste Verbindung.
Gruss TechnoX
Guten Abend,
Wie oben schon beschrieben kommt der VPN Tunnel nicht zu stande. Doch bevor ich weiter schreibe hier ein paar backgrounds:
- Notebook Win 7 64Bit SP1 + aktuelle Patches
- Sonicwall Virtualadapter VPN Client Version "18-001457-00_revAGVCSetup64
- Vodafone Mobile Broeadband Model: K3765 Usb Stick
- Vodafone Mobile Broadband v10.2
- Firmware des Stick = 11.126.03.09.00
Was geht ist folgendes:
- VPN over LAN
- VPN over WLAN
- Inet over WLAN
- Inet over LAN
- INET over USB UMTS Modem
(Folgendes Problem existiert auch bei ausgeschaltener Antvirensoftware und ausgeschaltener Windows Firewall)
Der VPN Handshake klappt wie folgt:
1) Einrichtung der Verbindung
2) anwählen und Preshared Key eingeben
3) Benutzer Login ausführen
4) Nutzer wird korrekt erkannt, erhällt Erlaubnis
5) DHCP wird kontaktiert um die IP ab zu rufen
und hier bleibt er hängen..
..aquireing ip...
Folgendes ist seltsam - wenn ich dem Virtual Adapter aber eine IP zuweise, entfällt die IP zuweisung und
die VPN Verbindung steht als Established / Connected da. IST ES ABER NICHT... der Ping auf das Gerät klappt
nicht und vom Gerät aus nach innen auf einen unserer PCs oder Server geht auch nicht durch.
An der Authentifizierung kann es nicht liegen.
Ein Merkmal das mir spanisch vorkommt ist das bei der manuellen Konfiguration des Sonicwall Virtual adapter zwar
IP und Subnet bleiben - er schmeisst aber jedesmal das Standardgateway aus der Konfiguration. warum begreife ich nicht.
Ich habe auch schon bei der Sonicwall Verbindung in den Eigenschaften die automatische Suche auf "LAN ONLY" umgestellt.
mit dem Erfolg das die Dial IN Meldung weg blieb. Und ich den Benutzer login zu Gesicht bekomme.
Der Versuch eine Dial In Verbindung über folgenden Weg ein zu richten führte auch zu keiner Lösung:
How To:
Systemsteuerung/ Telefon und Modem/ Modems/
Doppelklick auf das UMTS Modem und bei \"Erweitert\" folgenden Eintrag machen: +CGDCONT=1,"IP","web.vodafone.de" bei web.vodafone.de den entsprechenden APN Eintrag deines Providers verwenden. Alle Fenster bestätigen und schließen Netzwerk und Freigabecenter öffnen
"Neue Verbindung oder neues Netzwerk einrichten" \ "Wählverbindung einrichten" / weiter / UMTS Modem auswählen - bei Einwahl Rufnummer: *99# eintragen und unter Verbindungsname dem Kind einen Namen geben z.B. UMTSVPN - Verbinden anklicken Die neu erstellte Verbindung erscheint nun im Phonebook und kann vom Global VPN Client verwendet werden.
Inzwischen weis ich nicht mehr weiter. Hat wer noch ne Idee was ich noch ausprobieren kann?? Denn Dummerweise ist die UMTS
Verbindung die für das Notebook am wichtigste Verbindung.
Gruss TechnoX
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 182800
Url: https://administrator.de/forum/vpn-ueber-umts-schlaegt-fehl-182800.html
Ausgedruckt am: 06.04.2025 um 22:04 Uhr
6 Kommentare
Neuester Kommentar
Das hier hast du geprüft ?
VPN per UMTS Karte - Tunnel steht - aber Netz dahinter nicht anpingbar !?
Von dir kommt weder eine Information WELCHES VPN Protokoll du verwendest noch ob überhaupt ein funktionierender VPN Tunnel zustandekommt.
Vermutlich scheitert es schon daran. Ganz sicher scheitert es wenn du eine RFC 1918 IP Adresse auf dem UMTS Netz bekommst, denn dann filtern Provider so gut wie immer alle VPN Protokolle die nur mit teureren Business Accounts zu haben sind.
Ist das der Fall hilft dir nur ein neuer Account oder ein SSL basiertes VPN:
SSL-VPNs im Enterprise Umfeld
Du solltest erstmal diese grundsätzlichen Dinge klären bevor wir hier ins Eingemachte gehen, denn sonst mussen wir alles andere raten was wenig hilfreich ist...
VPN per UMTS Karte - Tunnel steht - aber Netz dahinter nicht anpingbar !?
Von dir kommt weder eine Information WELCHES VPN Protokoll du verwendest noch ob überhaupt ein funktionierender VPN Tunnel zustandekommt.
Vermutlich scheitert es schon daran. Ganz sicher scheitert es wenn du eine RFC 1918 IP Adresse auf dem UMTS Netz bekommst, denn dann filtern Provider so gut wie immer alle VPN Protokolle die nur mit teureren Business Accounts zu haben sind.
Ist das der Fall hilft dir nur ein neuer Account oder ein SSL basiertes VPN:
SSL-VPNs im Enterprise Umfeld
Du solltest erstmal diese grundsätzlichen Dinge klären bevor wir hier ins Eingemachte gehen, denn sonst mussen wir alles andere raten was wenig hilfreich ist...
Guten morgen 
Das ist doch schon mal was wo ich weiter nachforschen kann. Danke.
Habe nun mal etwas nachgeforscht - der VPN tunnel kommt tatsächlich nicht zu stande. Wird auch in der Mobile Boradband als inaktiv mit rotem X unter der Mobile-Verbindung angezeigt. (allerdings nur wenn man sich in i net verbunden hat)
Wie ich die Vodafone Mobile Software dazu bringe sich über deren VPN bereich zu verbinden.. uff... ich vermute mal das die SSL-VPN hier nutzen. Da ich keine großen Konfigurations möglichkeiten finde. Sonicwall stell hier ja nen eigenen Client und der stellt die Verbindung her. Welches Protokoll die verwenden - weis ich ehrlich gesagt gar nicht. Bisher war es noch nicht notwendig so in die Tiefe vor zu dringen. Wir haben kaum UMTS im Einsatz und beim anderen UMTS klappts ja. Is aber auch ein anderer Stick und ein anderer Vetrag..
Der Stick ist Eigentum des Aussendienstlers so wie ich das weis & es wäre durch aus denkbar das er hier Vertragsseitig gar nicht die freischaltung für VPN bekommen hat weil kein Business Vertag gewählt wurde.
Wenn ich die Frage nach dem VPN Protokoll richtig verstehe dann lautet sie IPSEC oder VPN-SSL. 100%ig bin ich mir nun ned sicher aber wenn ich die Prozedur mir so anschaue würde ich sagen IPSEC ist die verwendete variante, oder ich nenn es mal die klassische VPN Einwahl Prozedur. Denn es ght um einen vollwertigen VPN Access mit Profil und Qualifiziertem Zugriff auf das Firmen interne Netz was wenn ich das richtig herauslesen konnte per VPN-SSL nur als Mogelpackung bis gar nicht zu haben ist.
Ich werde jetzt mal mit dem Mitarbeiter sprechen und ihn fragen ob er bisher überhaupt schon mal VPN über UMTS verwendet hat. Dummerweise ist er zur zeit im Urlaub. Wenn er sagt er verwendet den UMTS Stick nur fürs surfen weil er bei sich im Kaff kein internet besitzt um so per Webaccess aufs Outlook zu greifen zu können. Dann is es mit ziemlicher Sicherheit so das er den günstigeren Tarif gewählt hat & somit kein VPN durchgereicht wird.
Um sicher zu gehen müsste ich wissen - woran genau erkenne ich eine RFC 1918 IP Adresse=? Der Stick zieht sich in der momentanen Session folgende Werte das ist wenn ich es richtig sehe keine RFC 1918 IP:
IP 2.205.67.167 (bevorzugt)
Subnet 255.255.255.240
Gateway 2.205.67.161
Private Adressbereiche wären laut wiki
Netzadressbereich CIDR-Notation Verkürzte CIDR-Notation Anzahl Adressen Anzahl Netze gemäß Netzklasse (historisch)
10.0.0.0 bis 10.255.255.255 10.0.0.0/8 10/8 224 = 16.777.216 Klasse A: 1 privates Netz mit 16.777.216 Adressen:
10.0.0.0/8
172.16.0.0 bis 172.31.255.255 172.16.0.0/12 172.16/12 220 = 1.048.576 Klasse B: 16 private Netze mit jeweils 65.536 Adressen;
172.16.0.0/16 bis 172.31.0.0/16
192.168.0.0 bis 192.168.255.255 192.168.0.0/16 192.168/16 216 = 65.536 Klasse C: 256 private Netze mit jeweils 256 Adressen;
192.168.0.0/24 bis 192.168.255.0/24
--------------------------------------------
Wobei ich den 192.168.er Bereich als solches bewusst kannte. Die beiden anderen sind mir zugegeben neu.
Wohin gegen der VPN Adapter sich mit einer Privaten Adresse (100.100.x.x) verbinden sollte... Theoretisch sollte das ja kein Problem sein die Adresse des Tunneling Adapters so zu verwenden. Ich weis das es klappt... hab es schon bei einem unserer Anderen Notebooks so am laufen udn da klappts. Sei es drum - egal ob fest eingetragen oder von unserem DHCP zugewiesen - die Adresse wird nicht an den Virtual adapter durchgereicht. Was zur Folge hat das die Verbindung nicht wirklich aufgebaut wird - auch wenn die Authentifizierung an der Firewall korrekt stattfindet.
Wenn ich die IP manuell eingebe gibt der Virtual Adapter ja an das alles verbunden ist - was ja möglich wäre da die Firewall den VPN Zugang ja korrekt authentifiziert hat. Nach der korrekten eingabe des Benutzerzugangs ist der firewall ja pups egal was passiert. Wenn der DHCP die IP durchreichen müsste - bleibts hängen, ist sie eingetragen fällt das weg und die Firewall bekomtm gar nicht mit das keine Verbindung aufgebaut wurde. > worauf hin sich der Adapter auf connected stellt.
Dies wäre die logische und auch warscheinlichste Ursache für das gesammte verhalten. Nun heist es erstmal abwarten bis Monatg.. denn dann weis ich mehr
Das ist doch schon mal was wo ich weiter nachforschen kann. Danke.
Habe nun mal etwas nachgeforscht - der VPN tunnel kommt tatsächlich nicht zu stande. Wird auch in der Mobile Boradband als inaktiv mit rotem X unter der Mobile-Verbindung angezeigt. (allerdings nur wenn man sich in i net verbunden hat)
Wie ich die Vodafone Mobile Software dazu bringe sich über deren VPN bereich zu verbinden.. uff... ich vermute mal das die SSL-VPN hier nutzen. Da ich keine großen Konfigurations möglichkeiten finde. Sonicwall stell hier ja nen eigenen Client und der stellt die Verbindung her. Welches Protokoll die verwenden - weis ich ehrlich gesagt gar nicht. Bisher war es noch nicht notwendig so in die Tiefe vor zu dringen. Wir haben kaum UMTS im Einsatz und beim anderen UMTS klappts ja. Is aber auch ein anderer Stick und ein anderer Vetrag..
Der Stick ist Eigentum des Aussendienstlers so wie ich das weis & es wäre durch aus denkbar das er hier Vertragsseitig gar nicht die freischaltung für VPN bekommen hat weil kein Business Vertag gewählt wurde.
Wenn ich die Frage nach dem VPN Protokoll richtig verstehe dann lautet sie IPSEC oder VPN-SSL. 100%ig bin ich mir nun ned sicher aber wenn ich die Prozedur mir so anschaue würde ich sagen IPSEC ist die verwendete variante, oder ich nenn es mal die klassische VPN Einwahl Prozedur. Denn es ght um einen vollwertigen VPN Access mit Profil und Qualifiziertem Zugriff auf das Firmen interne Netz was wenn ich das richtig herauslesen konnte per VPN-SSL nur als Mogelpackung bis gar nicht zu haben ist.
Ich werde jetzt mal mit dem Mitarbeiter sprechen und ihn fragen ob er bisher überhaupt schon mal VPN über UMTS verwendet hat. Dummerweise ist er zur zeit im Urlaub. Wenn er sagt er verwendet den UMTS Stick nur fürs surfen weil er bei sich im Kaff kein internet besitzt um so per Webaccess aufs Outlook zu greifen zu können. Dann is es mit ziemlicher Sicherheit so das er den günstigeren Tarif gewählt hat & somit kein VPN durchgereicht wird.
Um sicher zu gehen müsste ich wissen - woran genau erkenne ich eine RFC 1918 IP Adresse=? Der Stick zieht sich in der momentanen Session folgende Werte das ist wenn ich es richtig sehe keine RFC 1918 IP:
IP 2.205.67.167 (bevorzugt)
Subnet 255.255.255.240
Gateway 2.205.67.161
Private Adressbereiche wären laut wiki
Netzadressbereich CIDR-Notation Verkürzte CIDR-Notation Anzahl Adressen Anzahl Netze gemäß Netzklasse (historisch)
10.0.0.0 bis 10.255.255.255 10.0.0.0/8 10/8 224 = 16.777.216 Klasse A: 1 privates Netz mit 16.777.216 Adressen:
10.0.0.0/8
172.16.0.0 bis 172.31.255.255 172.16.0.0/12 172.16/12 220 = 1.048.576 Klasse B: 16 private Netze mit jeweils 65.536 Adressen;
172.16.0.0/16 bis 172.31.0.0/16
192.168.0.0 bis 192.168.255.255 192.168.0.0/16 192.168/16 216 = 65.536 Klasse C: 256 private Netze mit jeweils 256 Adressen;
192.168.0.0/24 bis 192.168.255.0/24
--------------------------------------------
Wobei ich den 192.168.er Bereich als solches bewusst kannte. Die beiden anderen sind mir zugegeben neu.
Wohin gegen der VPN Adapter sich mit einer Privaten Adresse (100.100.x.x) verbinden sollte... Theoretisch sollte das ja kein Problem sein die Adresse des Tunneling Adapters so zu verwenden. Ich weis das es klappt... hab es schon bei einem unserer Anderen Notebooks so am laufen udn da klappts. Sei es drum - egal ob fest eingetragen oder von unserem DHCP zugewiesen - die Adresse wird nicht an den Virtual adapter durchgereicht. Was zur Folge hat das die Verbindung nicht wirklich aufgebaut wird - auch wenn die Authentifizierung an der Firewall korrekt stattfindet.
Wenn ich die IP manuell eingebe gibt der Virtual Adapter ja an das alles verbunden ist - was ja möglich wäre da die Firewall den VPN Zugang ja korrekt authentifiziert hat. Nach der korrekten eingabe des Benutzerzugangs ist der firewall ja pups egal was passiert. Wenn der DHCP die IP durchreichen müsste - bleibts hängen, ist sie eingetragen fällt das weg und die Firewall bekomtm gar nicht mit das keine Verbindung aufgebaut wurde. > worauf hin sich der Adapter auf connected stellt.
Dies wäre die logische und auch warscheinlichste Ursache für das gesammte verhalten. Nun heist es erstmal abwarten bis Monatg.. denn dann weis ich mehr
Die 2er IP Adresse ist einen öffentliche und gehört zur Vodafone GmbH wie du hier:
http://www.heise.de/netze/tools/whois/
selber sehen kannst.
Das du die privaten RFC 1918 IP Adressen nicht kennst als Netzwerker ist eher peinlich aber ok...kann passieren.
Daher solltest du auch wissen (wo du sie nun oben alle fein säuberlich und richtig aufgezählt hast) das die von dir angesprochene 100.100.x.x KEINE private IP Adresse ist mit der sich der VPN Client verbinden sollte !! Eine Verbindung funktioniert da weder praktisch noch theoretisch !!
Das 100.100.x.x Netzwerk ist ein auf die IANA registrietes IP Netz was für deren internen Betrieb verwendet wird. Tabu also für dich !
Unmöglich also das du dort einen VPN Server betreibst !!
Ebenso unmöglich ist es wenn du einen Dreckfuhler gemacht hast und eine Null zuviel drin hättest 10.100.x.x, denn dann wäre es ja ein Privates IP Netz und private IP Adressen werden im Internet NICHT geroutet sind also somit nie erreichbar wie jedermann weiss !
Eine Verbindungsversuch dahin ist also technisch schon völlig unmöglich.
Auch lässt du uns nun weiter raten ob due IPsec oder SSL basiertes VPN benutzt. 2 völlig verschiedenen und nicht kompatible Verfahren !!
Fazit: Weiterhin kann dir hier niemand helfen dein Problem zu lösen solange du es nicht schaffst klar zu sagen zu welcher IP Adresse der Client sich verbinden muss !!
Mit der 2.205.67er IP hat er ja wenigstens schon mal eine öffentliche Absender IP...was aber ja nur die halbe Miete ist ?!
Kläre als die VPN Ziel IP und ob der Provider dir einen Business Account gegeben hat. Bei billigen UMTS Surf Accounts wird auch trotz öffentlicher IP sämtlicher VPN Traffic gefiltert !
Ohne eine klare Antwort auf die 2 Punkte kommen wir hier nicht weiter...! Es sei den raten reicht dir....
http://www.heise.de/netze/tools/whois/
selber sehen kannst.
Das du die privaten RFC 1918 IP Adressen nicht kennst als Netzwerker ist eher peinlich aber ok...kann passieren.
Daher solltest du auch wissen (wo du sie nun oben alle fein säuberlich und richtig aufgezählt hast) das die von dir angesprochene 100.100.x.x KEINE private IP Adresse ist mit der sich der VPN Client verbinden sollte !! Eine Verbindung funktioniert da weder praktisch noch theoretisch !!
Das 100.100.x.x Netzwerk ist ein auf die IANA registrietes IP Netz was für deren internen Betrieb verwendet wird. Tabu also für dich !
Unmöglich also das du dort einen VPN Server betreibst !!
Ebenso unmöglich ist es wenn du einen Dreckfuhler gemacht hast und eine Null zuviel drin hättest 10.100.x.x, denn dann wäre es ja ein Privates IP Netz und private IP Adressen werden im Internet NICHT geroutet sind also somit nie erreichbar wie jedermann weiss !
Eine Verbindungsversuch dahin ist also technisch schon völlig unmöglich.
Auch lässt du uns nun weiter raten ob due IPsec oder SSL basiertes VPN benutzt. 2 völlig verschiedenen und nicht kompatible Verfahren !!
Fazit: Weiterhin kann dir hier niemand helfen dein Problem zu lösen solange du es nicht schaffst klar zu sagen zu welcher IP Adresse der Client sich verbinden muss !!
Mit der 2.205.67er IP hat er ja wenigstens schon mal eine öffentliche Absender IP...was aber ja nur die halbe Miete ist ?!
Kläre als die VPN Ziel IP und ob der Provider dir einen Business Account gegeben hat. Bei billigen UMTS Surf Accounts wird auch trotz öffentlicher IP sämtlicher VPN Traffic gefiltert !
Ohne eine klare Antwort auf die 2 Punkte kommen wir hier nicht weiter...! Es sei den raten reicht dir....
Das is so ned ganz richtig weil es sich um interne IP Adressiung per Nat handelt. Wir haben ein abgegrenztes Domänen Netz. Welches durch die IP Benennung entsprechend einer Struktur klare und logische Adressbereiche aufweist.
Die Firewall authentifiziert den Nutzer für VPN Zugang und hebt diesen dann so zu sagen in das interne Netz. Weist ihm dann eine IP per DHCP zu - oder aber nicht, wenn der Sonicwall virtual adapter eine entsprechend verwaltete IP vor ab eingestellt fest bekommen hat. Somit kann eine 100.100.x.x nummer problemlos genutzt werden.
Das ganze problem was auftritt is das der Virtual Adapter sich die IP nicht zieht. Trotz korrekter Authentifizierung. Was bedeutet das irgendwas verhindet das der Tunnel aufgebaut werden kann. Und hier kommt der Vetrag ins spiel. Wenn User X Vertragseitig keine berechtigung auf die Nutzung von VPN Diensten besitzt klappt zwar die Authentifizierung aber die verbindung schlägt fehlt weil der Dienst ja nicht erlaubt ist.
Wie schon gesagt - per Wlan klappts und auch per Lan problemlos. Ob nun ein Router mit Öffentlicher adresse dazwischen hängt oder ein WLan Stick mit öffentlicher adresse sollte keine Rolle spielen. Und ja da haste danna uch recht das ich hier die 100.100.x.x als ÖFFENTLICHE Netzanbindung nicht nutzen kann/darf und sollte
Was aber eine Rolle spielt ist eben ob die Ports für den VPN Tunnel im UMTS Stick Vertraglich freigeschaltet sind. Was ja wie du sagst bei Billigen Surfsticks gerne gefiltert wird. Von daher war dein Posting oben hilfreich.
Das mit den RFC 1918 IP und der Peinlichekeit - lass das mal meine Sache sein. Ich habe das ganze schließlich ned Studiert sondern bin Quereinsteiger. Die IP-Netz und Subnet Struktur is mir jedoch durchaus bekannt. Doch wenn man sich ned oft damit auseinander setzt weil man es schlicht im alltag nicht oft braucht, ist das keine schande den RFC 1918 Standard nicht herunter beten zu können! Doch solange man kein IP v6 verwendet ist es nunmal recht gang und gebe das die IP Vergabe auf Grund des inzwischen aufgebrauchten IPv4 Adressbereichs HINTER dem Router und der Firewall meist per nat stattfindet. Da bekommt der Router vom Provider die öffentliche, dient also als Gateway/Firewall/DHCP rundum glücklich paket. Und dahinter zieht man halt das Private netz hoch. Selbst die HeimrouterDHCPs verteilen doch nicht immer die 192.168.x.x nummern im privaten Netzbereich.
Der Client muss sich über den Virtual Adapter mit der intern zu gewiesenen IP verbinden denn sonst befindet er sich ja ausserhalb des Netzes. Dieser Vorgang klappt ja auch wie gesagt per Wlan und per Kabel. Aber nicht per UMTS. Und somit sind wir am Punkt mit der Frage - kann der Stick Vertraglich überhaupt die VPN Verbindung aufbauen??? Und die Frage nach dem Verfahren habe ich doch schon geklärt.. Da SSL nicht in der lage ist den Tunnel vollwärtig auf zu bauen ist es IPSec welches zum Einsatz kommt.
Und neben bei - die aussage "wie jeder man weis" is mal sowas von typisch.. frag mal meinen Nachbar, oder meine Mutter meine Freundin oder oder. Des klingt zwar hart aber es weis eigentlich KEINE SAU die sich ned ausgibig mit PCs auseinander setzt.
Die Firewall authentifiziert den Nutzer für VPN Zugang und hebt diesen dann so zu sagen in das interne Netz. Weist ihm dann eine IP per DHCP zu - oder aber nicht, wenn der Sonicwall virtual adapter eine entsprechend verwaltete IP vor ab eingestellt fest bekommen hat. Somit kann eine 100.100.x.x nummer problemlos genutzt werden.
Das ganze problem was auftritt is das der Virtual Adapter sich die IP nicht zieht. Trotz korrekter Authentifizierung. Was bedeutet das irgendwas verhindet das der Tunnel aufgebaut werden kann. Und hier kommt der Vetrag ins spiel. Wenn User X Vertragseitig keine berechtigung auf die Nutzung von VPN Diensten besitzt klappt zwar die Authentifizierung aber die verbindung schlägt fehlt weil der Dienst ja nicht erlaubt ist.
Wie schon gesagt - per Wlan klappts und auch per Lan problemlos. Ob nun ein Router mit Öffentlicher adresse dazwischen hängt oder ein WLan Stick mit öffentlicher adresse sollte keine Rolle spielen. Und ja da haste danna uch recht das ich hier die 100.100.x.x als ÖFFENTLICHE Netzanbindung nicht nutzen kann/darf und sollte
Was aber eine Rolle spielt ist eben ob die Ports für den VPN Tunnel im UMTS Stick Vertraglich freigeschaltet sind. Was ja wie du sagst bei Billigen Surfsticks gerne gefiltert wird. Von daher war dein Posting oben hilfreich.
Das mit den RFC 1918 IP und der Peinlichekeit - lass das mal meine Sache sein. Ich habe das ganze schließlich ned Studiert sondern bin Quereinsteiger. Die IP-Netz und Subnet Struktur is mir jedoch durchaus bekannt. Doch wenn man sich ned oft damit auseinander setzt weil man es schlicht im alltag nicht oft braucht, ist das keine schande den RFC 1918 Standard nicht herunter beten zu können! Doch solange man kein IP v6 verwendet ist es nunmal recht gang und gebe das die IP Vergabe auf Grund des inzwischen aufgebrauchten IPv4 Adressbereichs HINTER dem Router und der Firewall meist per nat stattfindet. Da bekommt der Router vom Provider die öffentliche, dient also als Gateway/Firewall/DHCP rundum glücklich paket. Und dahinter zieht man halt das Private netz hoch. Selbst die HeimrouterDHCPs verteilen doch nicht immer die 192.168.x.x nummern im privaten Netzbereich.
Der Client muss sich über den Virtual Adapter mit der intern zu gewiesenen IP verbinden denn sonst befindet er sich ja ausserhalb des Netzes. Dieser Vorgang klappt ja auch wie gesagt per Wlan und per Kabel. Aber nicht per UMTS. Und somit sind wir am Punkt mit der Frage - kann der Stick Vertraglich überhaupt die VPN Verbindung aufbauen??? Und die Frage nach dem Verfahren habe ich doch schon geklärt.. Da SSL nicht in der lage ist den Tunnel vollwärtig auf zu bauen ist es IPSec welches zum Einsatz kommt.
Und neben bei - die aussage "wie jeder man weis" is mal sowas von typisch.. frag mal meinen Nachbar, oder meine Mutter meine Freundin oder oder. Des klingt zwar hart aber es weis eigentlich KEINE SAU die sich ned ausgibig mit PCs auseinander setzt.
Mein Nachbar kann das....aber egal !
NAT ist bei VPN protokollen wie IPsec generell problembehaftet. Besser ist dann immer man benutzt ein SSL VPN, denn dann kann einem sowas wie bei dir oben nie passieren, egal wie oft geNATet wird und welche IP Adressen man verwendet...
OK, wenn es wirklich so ist wie du beschreibst bleibt nur die Tatsache das der Provider VPN Protokolle filtert weil du eben einen billigen Surf Account hast und keinen Business Account. In der Regel lassen sich alle Provider das extra bezahlen.
Umgehen kannst du das dann nur mit einem anderen APN im UMTS und erhöhten Kosten.....oder eben mit einem SSL VPN
SSL-VPNs im Enterprise Umfeld
NAT ist bei VPN protokollen wie IPsec generell problembehaftet. Besser ist dann immer man benutzt ein SSL VPN, denn dann kann einem sowas wie bei dir oben nie passieren, egal wie oft geNATet wird und welche IP Adressen man verwendet...
OK, wenn es wirklich so ist wie du beschreibst bleibt nur die Tatsache das der Provider VPN Protokolle filtert weil du eben einen billigen Surf Account hast und keinen Business Account. In der Regel lassen sich alle Provider das extra bezahlen.
Umgehen kannst du das dann nur mit einem anderen APN im UMTS und erhöhten Kosten.....oder eben mit einem SSL VPN
SSL-VPNs im Enterprise Umfeld
hehehe SIEEEEG
Also - nach dem ich nun schwer gekämpft habe war ich gezwungen den Support von Vodafone zu nerven^^
Die Lösung in dem konkreten Fall besteht darin doch eine DFÜ verbindung einzurichten. JEDOCH ist dies etwas tricky und ned so
ohne weiteres mit den oben beschriebenen APN Eintragungen zu erreichen!
Ich darf keine konkreten Zugangsdaten nennen aber glaube ich kann das Dokument nennen in dem die Lösung genannt wird.
Die Lösung ist in der intern bei Vodafone vorliegenden Lösungs PDF zufinden: 6054.pdf
Der APN ist ein anderer... dieser ist bitte bei vodafone nach zu fragen!
Das Problem so teilte mir der etwas geforderte Support Mitarbeiter mit, kann u.a in der Datenkomprimierung des UMTS liegen, oder aber
in einer Antiviren Schutz Software oder oder oder. Um alles ausschließen zu können rät er gleich zu der DFÜ Verbindung - da hier der Mobile Broadband Connector umgangen wird. Er wird aber trotzdem benötigt wegen den Treibern - also nicht deinstallieren.
Die Version der Software welche ich verwendet habe: Setup_VMB_10.2.103.31248 diese läuft mit Windows7 64 Bit und für jene die kein VPN brauchen auch super um zu surfen..
Die Zugangskenung incl. APN (at+cgdcount... etz) wird im Gerätemanager, unter Modem (eigenschaften\extras) eingetragen. Und was wichtig ist, der Zugang darf keine aktive Pinabfrage haben. Was man im Mobile Broadband (erweiterte Ansicht) unter Geräte, hier den Stick auswählen, und oben unter PIN ABFRAGEN - ausschalten muss!!! Ist das aktiv - verbindet sich die DFÜ nämlich nicht.
Verbindung eingerichtet - VPN verbunden, IP wird gezogen - evoila ich bin im Internen Firmen Netz.
Dieser Fall scheint selbst bei Vodafone extrem selten auf zu treten. Wer aber den Verdacht hat das es sich um den selben Fall handelt und
wirklich alles andere schon ausschließen konnte der sollte bei Vodafone mal nach der oben genannten Lösungs PDF fragen und die APN erbitten. Der Verstoß oder die Weitergabe des Dokumentes kann aber mit hohen Geldstrafen belegt werden!!! Darum werd ich mich hüten hier genauere Daten preis zu geben.
Ihr kennt nun die interne Fall nummer der PDF - damit kommt ihr sicher auch beim Support weiter!
Also - nach dem ich nun schwer gekämpft habe war ich gezwungen den Support von Vodafone zu nerven^^
Die Lösung in dem konkreten Fall besteht darin doch eine DFÜ verbindung einzurichten. JEDOCH ist dies etwas tricky und ned so
ohne weiteres mit den oben beschriebenen APN Eintragungen zu erreichen!
Ich darf keine konkreten Zugangsdaten nennen aber glaube ich kann das Dokument nennen in dem die Lösung genannt wird.
Die Lösung ist in der intern bei Vodafone vorliegenden Lösungs PDF zufinden: 6054.pdf
Der APN ist ein anderer... dieser ist bitte bei vodafone nach zu fragen!
Das Problem so teilte mir der etwas geforderte Support Mitarbeiter mit, kann u.a in der Datenkomprimierung des UMTS liegen, oder aber
in einer Antiviren Schutz Software oder oder oder. Um alles ausschließen zu können rät er gleich zu der DFÜ Verbindung - da hier der Mobile Broadband Connector umgangen wird. Er wird aber trotzdem benötigt wegen den Treibern - also nicht deinstallieren.
Die Version der Software welche ich verwendet habe: Setup_VMB_10.2.103.31248 diese läuft mit Windows7 64 Bit und für jene die kein VPN brauchen auch super um zu surfen..
Die Zugangskenung incl. APN (at+cgdcount... etz) wird im Gerätemanager, unter Modem (eigenschaften\extras) eingetragen. Und was wichtig ist, der Zugang darf keine aktive Pinabfrage haben. Was man im Mobile Broadband (erweiterte Ansicht) unter Geräte, hier den Stick auswählen, und oben unter PIN ABFRAGEN - ausschalten muss!!! Ist das aktiv - verbindet sich die DFÜ nämlich nicht.
Verbindung eingerichtet - VPN verbunden, IP wird gezogen - evoila ich bin im Internen Firmen Netz.
Dieser Fall scheint selbst bei Vodafone extrem selten auf zu treten. Wer aber den Verdacht hat das es sich um den selben Fall handelt und
wirklich alles andere schon ausschließen konnte der sollte bei Vodafone mal nach der oben genannten Lösungs PDF fragen und die APN erbitten. Der Verstoß oder die Weitergabe des Dokumentes kann aber mit hohen Geldstrafen belegt werden!!! Darum werd ich mich hüten hier genauere Daten preis zu geben.
Ihr kennt nun die interne Fall nummer der PDF - damit kommt ihr sicher auch beim Support weiter!
