19
GSM Dial UP + VPN, Erreichbarkeit 10er IP
Hallo,
folgendes Szenario:
Ich habe ein mobiles Endgerät, dass über RAS eine IP-Verbindung ins Netzwerk von T-Mobile herstellt (alternativ auch O2, gleiches Verhalten).
Diese Einwahlverbindung erhält eine IP-Adresse aus dem 10.x.x.x Adressraum:
Verbindung funktioniert soweit
Danach baue ich eine VPN-Verbindung in unser Firmennetzwerk auf. Dort erhalte ich eine IP aus dem 172er Bereich des VPN-Routers:
Dies sieht soweit erstmal gut aus.
Problem ist nun, dass wir innerhalb der Firma auch ein 10er Netz verwenden und alle Anfragen meines Endgerätes auf das 10er Netz, nicht durch den Tunnel gehen.
Meine Routing-Tabelle sieht am Endgerät so aus:
Wenn ich das richtig verstehe ist der Eintrag 10.0.0.0/8 ursächlich dafür verantwortlich , dass dieser Traffic nicht über das VPn läuft.
Was kann ich jetzt tun, dass sämtlicher Verkehr durch den Tunnel geroutet wird und nicht dran vorbei?
Danke+Gruß,
Andreas
folgendes Szenario:
Ich habe ein mobiles Endgerät, dass über RAS eine IP-Verbindung ins Netzwerk von T-Mobile herstellt (alternativ auch O2, gleiches Verhalten).
Diese Einwahlverbindung erhält eine IP-Adresse aus dem 10.x.x.x Adressraum:
Ethernet adapter [GSM PORT]:
IP Address ........ : 10.68.191.70
Subnet Mask ....... : 255.0.0.0
Default Gateway ... : 10.68.191.70Danach baue ich eine VPN-Verbindung in unser Firmennetzwerk auf. Dort erhalte ich eine IP aus dem 172er Bereich des VPN-Routers:
Ethernet adapter [RAS VPN LINE 0]:
IP Address ........ : 172.20.204.191
Subnet Mask ....... : 255.255.255.255
Default Gateway ... : 172.20.204.191Problem ist nun, dass wir innerhalb der Firma auch ein 10er Netz verwenden und alle Anfragen meines Endgerätes auf das 10er Netz, nicht durch den Tunnel gehen.
Meine Routing-Tabelle sieht am Endgerät so aus:
=============================================================================
Interface List
0x200002 20 52 41 53 4c 63 GSM Port
0x210003 20 52 41 53 4c 63 RAS VPN Line 0
=============================================================================
=============================================================================
Active Routes
The no. of entries is ::: 13
Destination Netmask GatewayAddress Interface Metric
----------------------------------------------------------------------------
0.0.0.0 0.0.0.0 172.20.204.191 172.20.204.191 1
0.0.0.0 0.0.0.0 10.68.191.70 10.68.191.70 50
10.0.0.0 255.0.0.0 10.68.191.70 10.68.191.70 50
10.68.191.70 255.255.255.255 127.0.0.1 127.0.0.1 50
10.255.255.255 255.255.255.255 10.68.191.70 10.68.191.70 50
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
172.20.204.191 255.255.255.255 127.0.0.1 127.0.0.1 50
172.20.255.255 255.255.255.255 172.20.204.191 172.20.204.191 50
195.234.133.210 255.255.255.255 10.68.191.70 10.68.191.70 1
224.0.0.0 240.0.0.0 10.68.191.70 10.68.191.70 50
224.0.0.0 240.0.0.0 172.20.204.191 172.20.204.191 50
255.255.255.255 255.255.255.255 10.68.191.70 10.68.191.70 1
255.255.255.255 255.255.255.255 172.20.204.191 172.20.204.191 1
=============================================================================Wenn ich das richtig verstehe ist der Eintrag 10.0.0.0/8 ursächlich dafür verantwortlich , dass dieser Traffic nicht über das VPn läuft.
Was kann ich jetzt tun, dass sämtlicher Verkehr durch den Tunnel geroutet wird und nicht dran vorbei?
Danke+Gruß,
Andreas
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: 343208
Url: https://administrator.de/contentid/343208
Ausgedruckt am: 23.11.2024 um 10:11 Uhr
19 Kommentare
Neuester Kommentar
Diese Einwahlverbindung erhält eine IP-Adresse aus dem 10.x.x.x Adressraum:
Sehr schlecht !! 
Das bedeutet das ist ein Billig nur Surf Account und der Provider macht ein sog. Carrier Grade NAT (CGN) sprich also ein zentralisiertes IP Adress Translation auf eine öffentliche Internet IP in dessen RZ.
Grund ist die IPv4 Adressknappheit.
Dadurch hast du eine NAT Firewall auf Provider Seite dazwischen die jegliches VPN zunichte macht....mit einer einzigen Ausnahme und das ist ein SSL basiertes VPN weil das nicht aus mehreren Protokollkomponenten besteht wie PPTP, IPsec oder L2TP.
WAS für ein VPN Protokoll nutzt du ??
Letztlich aber auch egal, denn das ist nicht dein Hauptproblem !! Das ist das was danach kommt...
Problem ist nun, dass wir innerhalb der Firma auch ein 10er Netz verwenden und alle Anfragen meines Endgerätes auf das 10er Netz, nicht durch den Tunnel gehen.
DAS ist dein eigentliches Problem...!! Damit ist ein eindeutiges L3 Forwarding (Routing) im Netz wie es sein müsste zur Wegefindung durch die doppelten IP Netze nicht mehr möglich.Siehe auch HIER.
Wenn ich das richtig verstehe ist der Eintrag 10.0.0.0/8 ursächlich dafür verantwortlich , dass dieser Traffic nicht über das VPN läuft.
Ja ! Thema eindeutige Wegefindung und die allgemeine Regel die jeder kennt das IP Adressen einzigartig sein müssen in einem Netzwerk.Da gibt es nur eine Lösung nämlich bidirektionales NAT oder PAT auf der lokalen Server Seite.
Du musst die VPN Clients mit ihren 10er IPs fest umsetzen auf z.B. die 172er IPs des VPN Dialin Netzes.
Damit ist dann ein internes Routing wieder möglich, da die Client IPs in eurem Netz mit 172er Absender IPs auftauchen
Das ist kein einfaches Unterfangen da mit Konfigurationsaufwand verbunden und zudem muss deine HW das auch supporten. Mit einem Cisco Router kein Problem, mit einer billigen FritzBox schon...
Einfacher ist es, wenn überhaupt möglich, ggf. die Client APN zu ändern damit man am Mobilclient eine öffentliche IP bekommt. Das geht aber meist nur mit den teureren Business Tarifen. Ggf. gar nicht wenn der Provider kein Kontingent hat um seine Mobilnetze damit zu betreiben.
Das oder 1:1 NAT / PAT ist deine einzige Chance.
Danke für die schnelle Antwort.
Ich hatte eigentlich die Hoffnung, an anderer Stelle hebeln zu können.
Ich muss direkt vorweg schicken, dass ich kein Indeep-Crack zum Routing Thema bin, leider.
Von meinem Verständnis her, wird nach der VPN Einwahl eine IP aus dem VPN-Adressraum verwendet (172.x.x.x). Gleichzeitig wird jeglicher IP-Verkehr in den Tunnel gesendet (quasi /32 aufs Gateway?).
Diese Zeilen geben das aber scheinbar nicht wirklich her, oder ?
Leider gewinnt wohl immer die 10.0.0.0/8...obwohl sie gleiche Metriken hat.
Ich hatte Hoffnung, dass irgendwas in der Bildung der Tabellen falsch ist, oder ich ggf. durch andere Prios das Gerät dazu bringen kann, immer alles in den Tunnel zu senden.
Ich frag mich gerade, ob ich denn der Einzige bin, der VPN über T-Mobile in ein 10er Netz betreiben möchte. Das dürfte ja dann bei niemandem funktionieren ? Oder habe ich da einen Denkfehler ?
WAS für ein VPN Protokoll nutzt du ??
Wir verwenden aktuell PPTP (wissentlich, dass es Teufelszeug ist, daran wird gearbeitet aber dauert und andere Baustelle).Ich hatte eigentlich die Hoffnung, an anderer Stelle hebeln zu können.
Ich muss direkt vorweg schicken, dass ich kein Indeep-Crack zum Routing Thema bin, leider.
Von meinem Verständnis her, wird nach der VPN Einwahl eine IP aus dem VPN-Adressraum verwendet (172.x.x.x). Gleichzeitig wird jeglicher IP-Verkehr in den Tunnel gesendet (quasi /32 aufs Gateway?).
Diese Zeilen geben das aber scheinbar nicht wirklich her, oder ?
Destination Netmask GatewayAddress Interface Metric
...
172.20.204.191 255.255.255.255 127.0.0.1 127.0.0.1 50
172.20.255.255 255.255.255.255 172.20.204.191 172.20.204.191 50 Leider gewinnt wohl immer die 10.0.0.0/8...obwohl sie gleiche Metriken hat.
Ich hatte Hoffnung, dass irgendwas in der Bildung der Tabellen falsch ist, oder ich ggf. durch andere Prios das Gerät dazu bringen kann, immer alles in den Tunnel zu senden.
Das ist kein einfaches Unterfangen da mit Konfigurationsaufwand verbunden und zudem muss deine HW das auch supporten. Mit einem Cisco Router kein Problem, mit einer billigen FritzBox schon...
Soweit ich weiß haben wir Mikrotik Router auf der Firmenseite im Einsatz.Einfacher ist es, wenn überhaupt möglich, ggf. die Client APN zu ändern damit man am Mobilclient eine öffentliche IP bekommt. Das geht aber meist nur mit den teureren Business Tarifen. Ggf. gar nicht wenn der Provider kein Kontingent hat um seine Mobilnetze damit zu betreiben.
Das oder 1:1 NAT / PAT ist deine einzige Chance.
Letztlich muss ich also einen Provider finden, der keine Adresse aus dem 10er Bereich anbietet. Ich hab hier T-Mobile und O2 Karten liegen, die beide 10er Netze bekommen Das oder 1:1 NAT / PAT ist deine einzige Chance.
Ich frag mich gerade, ob ich denn der Einzige bin, der VPN über T-Mobile in ein 10er Netz betreiben möchte. Das dürfte ja dann bei niemandem funktionieren ? Oder habe ich da einen Denkfehler ?
Hallo,
hab gerade mal bei Vodafone geschaut.
100.x.x.x/32 als UMTS-IP bekommen.
Fred
hab gerade mal bei Vodafone geschaut.
100.x.x.x/32 als UMTS-IP bekommen.
Fred
Mich stört an deiner Routingtabelle, dass da überhaupt keine Route für das 10er-Netz eingetragen ist, die zu eurem VPN führt.
Womit wird denn der Tunnel aufgebaut? Werden da auch die Routen korrekt gesetzt?
Die Telekom beispielsweise arbeitet mit einer Präfixlänge von 30 Bit, da werden schlechtestenfalls nur vier IP-Adressen "gestört".
Du solltest aber definitv erstmal probieren, ob diese Route für 10.0.0.0/8 wirklich so sein muss oder ob die evtl. durch irgendwelche Fehler entstanden ist. Denn wenn man von der Metrik ausgeht scheinen die Routen ins VPN hinein generell immer mit einer Metrik von 1 gesetzt zu werden, die Route für 10.0.0.0/8 ist aber mit einer Metrik von 50 vorhanden (scheint also nicht von irgendeinem VPN-Client gesetzt zu sein).
Und: Nutz ihr in eurem Unternehmen wirklich das Präfix 10.0.0.0/8 oder habt ihr kleinere Subnetze? Denn wenn du kleinere Subnetze hast, kannst du natürlich kleinere und damit More-Specific-Routen setzen (z.B. 10.5.5.0/24) oder nötigenfalls zwei 10.x/9.
Vorher solltest du aber definitiv den Client einmal rebooten und dir angucken, welche Routen durch die Mobilfunkverbindung entstehen und welche danach mit der VPN-Einwahl entstehen.
Womit wird denn der Tunnel aufgebaut? Werden da auch die Routen korrekt gesetzt?
Die Telekom beispielsweise arbeitet mit einer Präfixlänge von 30 Bit, da werden schlechtestenfalls nur vier IP-Adressen "gestört".
Du solltest aber definitv erstmal probieren, ob diese Route für 10.0.0.0/8 wirklich so sein muss oder ob die evtl. durch irgendwelche Fehler entstanden ist. Denn wenn man von der Metrik ausgeht scheinen die Routen ins VPN hinein generell immer mit einer Metrik von 1 gesetzt zu werden, die Route für 10.0.0.0/8 ist aber mit einer Metrik von 50 vorhanden (scheint also nicht von irgendeinem VPN-Client gesetzt zu sein).
Und: Nutz ihr in eurem Unternehmen wirklich das Präfix 10.0.0.0/8 oder habt ihr kleinere Subnetze? Denn wenn du kleinere Subnetze hast, kannst du natürlich kleinere und damit More-Specific-Routen setzen (z.B. 10.5.5.0/24) oder nötigenfalls zwei 10.x/9.
Vorher solltest du aber definitiv den Client einmal rebooten und dir angucken, welche Routen durch die Mobilfunkverbindung entstehen und welche danach mit der VPN-Einwahl entstehen.
Die "Route" ist ja da: 10.255.255.255 also das 10er Netz mit einem /8 Prefix liegt ja auf dem Interface 10.68.191.70. Das gesamte 10er Netz wird also in den Tunnel geroutet wenn man so will.
Das ist vermutlich das Provider Netzwerk was dynamisch mit dem /8 Prefix injiziert wird auf dem Dialin Interface ?!
Man könnte jetzt statisch natürlich mit einer besser spezifizierten Route nur die wirklich intern genutzten 10er Subnetze auf die Tunnel Gateway IP routen wie Kollege LordG das schon richtig beschreibt.
Das müsste aber manuell an allen Clients passieren was aber nicht wirklich effizient ist und auch ein quick and dirty Workaround. Würde aber funktionieren...
Das ist vermutlich das Provider Netzwerk was dynamisch mit dem /8 Prefix injiziert wird auf dem Dialin Interface ?!
Man könnte jetzt statisch natürlich mit einer besser spezifizierten Route nur die wirklich intern genutzten 10er Subnetze auf die Tunnel Gateway IP routen wie Kollege LordG das schon richtig beschreibt.
Das müsste aber manuell an allen Clients passieren was aber nicht wirklich effizient ist und auch ein quick and dirty Workaround. Würde aber funktionieren...
Laut Routingtabelle wird das 10.0.0.0/8 auf das GSM-Interface geroutet, nicht in den Tunnel.
Jedoch besteht die Route mit Metrik 50, die VPN-Routen mit Metrik 1 — deshalb glaube ich, dass die Route einfach falsch angelegt wurde oder garnicht
Jedoch besteht die Route mit Metrik 50, die VPN-Routen mit Metrik 1 — deshalb glaube ich, dass die Route einfach falsch angelegt wurde oder garnicht
Ja, das 10er Netz ist ja vermutlich hier das Provider Mobilnetz was mit einem /8er Prefix kommt.
Das VPN Netz 172.20.255.255 wird mit einem /16 Prefix injiziert. Nicht besonders intelligent und der Sysadmin hat vermutlich wenig Ahnung von IP Adressierung aber immerhin fürs Erste nicht falsch.
Wenn er jetzt hoffentlich die internen 10er Netze mit einem Prefix > /8 betreibt könnte er diese ja statisch mit besserer Metrik auf das Tunnel Gateway 172.20.204.191 routen.
Sinnvoller wäre natürlich diese > /8 10er Routen kämen dynamisch. Das ist vermutlich ein zusätzlicher Fehler des VPN Admins das diese Routen vom VPN Server nicht beim Dialin propagiert werden.
So gewinnt natürlich immer das Provider Interface mit /8 und tötet damit jede Connectivity in die internen 10er Subnetze sofern diese dann > /8 sind.
Ein simpler Traceroute hätte das dem PM auch sofort gezeigt.
.
Das VPN Netz 172.20.255.255 wird mit einem /16 Prefix injiziert. Nicht besonders intelligent und der Sysadmin hat vermutlich wenig Ahnung von IP Adressierung aber immerhin fürs Erste nicht falsch.
Wenn er jetzt hoffentlich die internen 10er Netze mit einem Prefix > /8 betreibt könnte er diese ja statisch mit besserer Metrik auf das Tunnel Gateway 172.20.204.191 routen.
Sinnvoller wäre natürlich diese > /8 10er Routen kämen dynamisch. Das ist vermutlich ein zusätzlicher Fehler des VPN Admins das diese Routen vom VPN Server nicht beim Dialin propagiert werden.
So gewinnt natürlich immer das Provider Interface mit /8 und tötet damit jede Connectivity in die internen 10er Subnetze sofern diese dann > /8 sind.
Ein simpler Traceroute hätte das dem PM auch sofort gezeigt.
.
Ja, das 10er Netz ist ja vermutlich hier das Provider Mobilnetz was mit einem /8er Prefix kommt.
JupWenn er jetzt hoffentlich die internen 10er Netze mit einem Prefix > /8 betreibt könnte er diese ja statisch mit besserer Metrik auf das Tunnel Gateway 172.20.204.191 routen.
Da ich eigentlich nur auf zwei 10er Subnetze muss (10.1.x.x und 10.2.x.x) wäre das evtl. ein Workaround.Sinnvoller wäre natürlich diese > /8 10er Routen kämen dynamisch. Das ist vermutlich ein zusätzlicher Fehler des VPN Admins das diese Routen vom VPN Server nicht beim Dialin propagiert werden.
Unser Admin hat auf meine Anfrage ob man an meinem Problem was ändern könnte gemeint, das wäre nicht möglich. Begründet mit "administrativer Distanz" und das deshalb immer die Direktverbindung (GSM) gewinnen würde, egal was er einstellen würde ?So gewinnt natürlich immer das Provider Interface mit /8 und tötet damit jede Connectivity in die internen 10er Subnetze sofern diese dann > /8 sind.
Was ziemlich genau mein Problem ist...Ein simpler Traceroute hätte das dem PM auch sofort gezeigt.
Der lieferte mir leider nur Einträge mit * ....Ich habe nochein wenig weiter probiert und komme zu einer etwas unschönen Erkenntnis.
Aber der Reihe nach:
Die Subnetzmaske 255.0.0.0 und damit die 10.0.0.0/8 Route erscheint, sobald ich den RAS-Dial In via GSM-Modul ins T-Mobile (oder auch O2) Netz mache. Zu diesem Zeitpunkt habe ich noch gar keine VPN-Einwahl gestartet.
D.h. die kommt eigentlich von T-Mobile, oder ?
Da ich nicht ganz glauben konnte, dass das ein normales Verhalten sein soll, habe ich mal ein anderes Endgerät genommen (Tablet mit Windows 10 anstelle PDA mit WINCE6) , und die selbe (!) SIM-Karte benutzt. Hier erfolgt die Einwahl allerdings nicht mehr manuell per RAS sonder mehr oder minder automatisch vom OS.
Ergebnis ist zwar ebenfalls eine 10er IP-Adresse, allerdings mit einer anderen Subnetzmaske: 255.255.255.0. Dadurch gibt es auch nicht die unschöne 10/8 Route.
Ich dachte bisher immer, die Subnetzmaske käme vom DHCP des Providers...aber offensichtlich scheint das Betriebssystem hier irgendwas anders zu interpretieren...
Nachtrag: Kann Die VPN-Route nicht irgendwie höher priorisiert werden, dass die immer gewinnt ?
Ja, über die Metrik.
Aber dafür müsste die Route erstmal da sein
Und wenn du die Routen als 2x /24 anlegst, gewinnen sie so oder so.
Aber dafür müsste die Route erstmal da sein
Und wenn du die Routen als 2x /24 anlegst, gewinnen sie so oder so.
das deshalb immer die Direktverbindung (GSM) gewinnen würde, egal was er einstellen würde ?
Ist natürlich Quatsch, denn zusätzliche 10er Routen mit einem 16er Prefix machen die Route ja granularer (most specific route). Der Router oder das Endgerät wird dann immer nach dem longest match gehen und eine präzisere Maske bevorzugen.Die Metrik oder administrative Distance greift ausschliesslich nur bei parallelen Pfaden in gleiche Netze wobei gleich auch den gleichen Prefix meint !
Dein Admin hat also seine Hausaufgaben im Bereich Netzwerk nicht gemacht oder ist eher ein Windows Admin Knecht.
Der lieferte mir leider nur Einträge mit * ....
Vermutlich Firewall die ICMP filtert die 10.0.0.0/8 Route erscheint, sobald ich den RAS-Dial In via GSM-Modul ins T-Mobile (oder auch O2) Netz mache.
Klar und logisch, denn die Telekom injiziert diese Route dynmaisch mit dem PPP Dialin ins Mobilnetz. Genauso wie bei xDSL, DHCP usw.D.h. die kommt eigentlich von T-Mobile, oder ?
Ja ! Per PPP.Ich dachte bisher immer, die Subnetzmaske käme vom DHCP des Providers
Nicht denken sondern nachdenken ! Hier ist PPP am Werk und kein DHCP. Das Ergebnis ist aber dasselbe.Das ist allerdings bedenklich wenn der RAS Stack nicht richtig mit Subnetzmasken umgehen kann. Vermutlich "erkennt" der noch nach dem steinzeitlichen Klassen Modell eine Class A Adresse und impliziert dann einen /8er Prefix. Sollte einen bei MS nicht groß wundern. Apple macht es dann vermeintlich richtig.
Dann ist das aber ein Software oder Treiber Problem in dem betreffenden Client wenn der die Route falsch annimmt.
Fakt ist aber das du mit /16er Routen auf das Firmennetz das fixen könntest wenn denn der VPN Server diese Netze richtig announcen würde. Aber das macht er ja scheinbar nicht oder auch hier macht der Client das falsch.
Also dann doch eher ein Client Problem.
Was sagt denn das iPad wenn du dort die VPN Verbindung startest ??? Das wäre ja nochmal interessant !
Die VPN-Route nicht irgendwie höher priorisiert werden, dass die immer gewinnt ?
Nein ! Was beim Routing gewinnt ist oben beschrieben.Das ist allerdings bedenklich wenn der RAS Stack nicht richtig mit Subnetzmasken umgehen kann. Vermutlich "erkennt" der noch nach dem steinzeitlichen Klassen Modell eine Class A Adresse und impliziert dann einen /8er Prefix. Sollte einen bei MS nicht groß wundern. Apple macht es dann vermeintlich richtig.
Das Gerät auf dem das passiert ist mit Windows CE 6.0 bestückt. Das ist schon ziemlich betagt, insofern würde mich das tatsächlich nicht wundern, wenn das der Grund wäre.Fakt ist aber das du mit /16er Routen auf das Firmennetz das fixen könntest wenn denn der VPN Server diese Netze richtig announcen würde. Aber das macht er ja scheinbar nicht oder auch hier macht der Client das falsch.
Wenn ich das richtig verstehe, müsste der VPN-Server (Mikrotik) rausgeben, dass 10.1.x.x/16 und 10.2.x.x/16 über Gateway-VPN erreichbar ist, und mein Problem wäre gelöst ? Sollte der VPN nicht sowieso eine "Alles zu mir" Route besitzen ?Was sagt denn das iPad wenn du dort die VPN Verbindung startest ??? Das wäre ja nochmal interessant !
Das iPad war ein W10 Tablet. GSM Einwahl und VPN Einwahl funktionierten und meine internen 10er Adressen waren erreichbar.Bin jetzt leider schon aus dem Office raus und hab vergessen, die Routing Tabelle nach VPN Einwahl zu speichern, so dass ich sie nicht posten kann.
Das Gerät auf dem das passiert ist mit Windows CE 6.0 bestückt.
Uuaaahrg...böses Faul. Das so ein antiker Mist da nicht richtig performt war abzusehen...Mal was moderneres Winblows artiges versucht als Client ?
Was für ein VPN ist das PPTP, IPsec, L2TP, SSL ???
müsste der VPN-Server (Mikrotik) rausgeben, dass 10.1.x.x/16 und 10.2.x.x/16 über Gateway-VPN erreichbar ist,
Ja, wenn er richtig cutomized ist ?!VPNs einrichten mit PPTP
Sollte der VPN nicht sowieso eine "Alles zu mir" Route besitzen ?
Ja, kann er machen wenn man es richtig customized. Stichwort Default Gateway redirect:VPNs einrichten mit PPTP
Das iPad war ein W10 Tablet.
Igitt....! Aber wenigstens das Routing hat es richtig gemacht.Da kannst du schon sehen: CE und Win10, gleiche Rahmenbedingungen...das sagt doch schon alles !
Mal was moderneres Winblows artiges versucht als Client ?
Ist in Arbeit, aber mit dem aktuellen HW-Bestand müssen wir erstmal leben.Sollte der VPN nicht sowieso eine "Alles zu mir" Route besitzen ?
Ja, kann er machen wenn man es richtig customized. Stichwort Default Gateway redirect:VPNs einrichten mit PPTP
Wenn ich mir jetzt die Routingtabelle von oben ansehe, dann ist die DefaultRoute doch eigentlich schon da, allerdings mit einer Metrik von 1, Die Metrik der Defaultroute vom GSM besitzt aber eine 50?
Active Routes
Destination Netmask GatewayAddress Interface Metric
----------------------------------------------------------------------------
0.0.0.0 0.0.0.0 172.20.204.191 172.20.204.191 1
0.0.0.0 0.0.0.0 10.68.191.70 10.68.191.70 50 Da kannst du schon sehen: CE und Win10, gleiche Rahmenbedingungen...das sagt doch schon alles !
Das CE ist ja auch schon ein paar Jahre alt... ;)Soweit ich weiß wird da ein Mikrotik Router als VPN_Server eingesetzt.
Das ist egal was da als VPN Server werkelt. Das Protokoll ist weltweiter Standard.In den Tutorials finde ich eine Einstellung "Add Default Route", die im Standard als "NO" gesetzt sein soll. Meinst du das ?
Ja, wenn wir von PPTP reden.Bei IPsec und SSL VPN Protokollen injiziert der VPN Server die default Route auf den Client und es wird dort customized.
Es ist also etwas protokollabhängig was für ein VPN Protokoll verwendet wird.
Am PPTP-Client des WinCE kann ich leider gar nichts dazu einstellen.
Das ist dann leider CE spezifisch. Normal ist das man es einstellen kann.dann ist die DefaultRoute doch eigentlich schon da,
Das stimmt. Die wird also injiziert. Der geringere Metrik Wert gewinnt. Ist dein Client also eingeloggt ins VPN wird der gesamte zu routende Traffic an die Gateway IP 172.20.204.191 gesendet.Das kannst du auch selber verifizieren z.B. mit einem Traceroute auf die 8.8.8.8 !!
Die Metrik der Defaultroute vom GSM besitzt aber eine 50?
Gilt dann also nur für den Traffic über lokale Interfaces...
Der tracert auf 8.8.8.8 routet in den Tunnel (Anzeige Gateway als erster Hop).. check
Ich habe jetzt manuell am Client folgendes hinzugefügt.
Nachdem ich die IndexNummer des VPN-Adapters verwendet habe, hat der Befehl auch funktioniert.
Damit kann ich nun meine gewünschtes 10.1er Subnetz erreichen.
Jetzt müssen nur noch unsere Netzer diese Einträge über den VPN-Server/Router verteilt bekommen. Aber das ist ein anderes Thema.
Als Fallback kann ich das hinzufügen der Routen in unsere Client-Applikation packen.
Vielen Herzlichen Dank !
Ich habe jetzt manuell am Client folgendes hinzugefügt.
route ADD 10.1.0.0 MASK 255.255.0.0 172.20.204.191 IF 327684Damit kann ich nun meine gewünschtes 10.1er Subnetz erreichen.
Jetzt müssen nur noch unsere Netzer diese Einträge über den VPN-Server/Router verteilt bekommen. Aber das ist ein anderes Thema.
Als Fallback kann ich das hinzufügen der Routen in unsere Client-Applikation packen.
Vielen Herzlichen Dank !
hat der Befehl auch funktioniert.
Dann solltest du noch ein "-p" anhängen damit er nach dem nächsten Reboot auch noch da ist Jetzt müssen nur noch unsere Netzer diese Einträge über den VPN-Server/Router verteilt bekommen.
Das wäre dann die Ideallösung, dann erspart man sich die statische Frickelei von oben !!Ist aber ganz einfach zu machen in den IPsec Settings. Sollten die "Netzer" schnell hinbekommen.
Sorry, war im Urlaub ;)
Wir haben jetzt in unserer Anwendung ein wenig Logik eingebaut, die bei der obigen Situation die Route automatisch hinzufügt.
Zitat von @aqui:
Das wäre dann die Ideallösung, dann erspart man sich die statische Frickelei von oben !!
Ist aber ganz einfach zu machen in den IPsec Settings. Sollten die "Netzer" schnell hinbekommen.
Also die Netzer haben die Flügel gestreckt und können über PPTP keine Routen verteilen.Das wäre dann die Ideallösung, dann erspart man sich die statische Frickelei von oben !!
Ist aber ganz einfach zu machen in den IPsec Settings. Sollten die "Netzer" schnell hinbekommen.
Wir haben jetzt in unserer Anwendung ein wenig Logik eingebaut, die bei der obigen Situation die Route automatisch hinzufügt.
Das kann man mit PPTP auch nicht. PPTP ist "Point to Point" wied er Name schon sagt.
Deine Netzer können es abe rmit einem Trick machen indem sie dynmaische Routing Protokolle über PPTP nutzen, damit klappt es dann wieder.
Also einfach mal RIPv2 oder OSPF einschalten
Aber mit Steinzeit "Logik" gehts natürlich auch als Workaround...
Deine Netzer können es abe rmit einem Trick machen indem sie dynmaische Routing Protokolle über PPTP nutzen, damit klappt es dann wieder.
Also einfach mal RIPv2 oder OSPF einschalten
Aber mit Steinzeit "Logik" gehts natürlich auch als Workaround...
