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.70
Danach 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.191
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:
=============================================================================
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 343208
Url: https://administrator.de/forum/gsm-dial-up-vpn-erreichbarkeit-10er-ip-343208.html
Ausgedruckt am: 25.12.2024 um 06:12 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.
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...
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.
.
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 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 !
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...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.
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...