VPN über VPN => routingproblem

Hallo Forum,

ich versuche, über ein VPN auf ein anderes VPN zuzugreifen:

Ich habe an der Uni Zugriff auf das Internet über einen VPN Zugang. Dieser VPN-Zugang wird mit dem meiner meinung nach sehr häßlich implementierten Cisco IPSec-Tool hergestellt. Danach habe ich also schon 2 Netzwerkinterfaces, meine WLAN-Karte und das VPN-Device.

Dann starte ich eine weitere VPN-Verbindung, nämlich die zu meinem privaten Netzwerk via PPTP. Wenn ich das von meinem WLAN zu Hause aus mache, läuft alles wunderbar, weil dort nichts über das andere VPN muss. Wenn ich allerdings über beide VPNs muss, kann ich nicht mal mehr die Gegenseite der PPP-Verbingung anpingen.

Es ist allerdings definitiv ein Routing-Problem: Ich kann in der Systray sehen, wie Pakete, die von meinem LAN ausgehen, am meinem VPN-Interface ankommen (der hintere PC von den beiden im Symbol leuchtet hellblau). Da es aber ein Ping ist, sollte ja im gleichen Zug auch der vordere leuchten und somit zurücksenden. Das eben tut er aber nicht.

Es scheint also, als habe der Windows-Rechner keine Route zu seinem Gegenüber der PPP-Verbindung. Das Gegenüber ist übrigens ein Linux-Server, dessen Routing ich in dem Fall ganz einfach anpassen konnte. Ich komme nur absolut nicht mit dem route-befehl unter Windows klar, denn wenn ich sehe, dass Windows erstmal alle Interfaces auf 127.0.0.1 zu leiten scheint, solange sie nichts raussenden, andere Verbindungen aber dann über die eben genannten als Gateway senden will, kriege ich als jemand, der das Netzwerken auf Linux gelernt hat, einen Schreikrampf.

Falls Ihr jetzt nicht wisst, was ich eigentlich von Euch will: Wie kann ich das unter ipconfig angezeigte Standardgateway einer PPP-Verbindung ändern?!? In den Netzwerkeinstellungen ist es nicht.

DANKE EUCH VIELMALS!

Hi schlot und Willkommen im Board !

Das ist definitiv kein Routing-Problem sondern ein Security-Feature des Cisco-VPN-Clients.

Standardmäßig sind die Rules der im Cisco-VPN-Clients enthaltenen Firewall so eingestellt, daß jeder Netzwerkverkehr parallel zur VPN-Verbindung geblockt wird - z.B. zu einem existierenden LAN und auf jeden Fall auch zu einer weiteren PPP-Verbindung.

Diese Einstellungen übernimmt der Client bei der Einwahl vom Server.

Wenn Dir die parallele Nutzung eines weiteren LAN´s nicht erlaubt ist, bekommst Du nicht mal eine Antwort auf einen Ping dorthin.

Die gesamte logische Client-Anbindung läuft an den üblichen MS-Protokollen vorbei. Mit ipconfig bekommst Du nicht mal die Daten der VPN-Verbindung angezeigt.

Absolute korrekte Antwort. :)

Dein Problem wäre nur lösbar, wenn das Rechenzentrum Spiltunneling zulassen würde. Sprich IP-Verkehr zu Zielen außerhalb des UNI-Netzes wären damit zugelassen. Ich denke aber mal, dass die das nicht machen.

Ich habe das Splittunneling bei uns auch deaktiviert.

Sorry, aber "that's life".

Gruß Data

vielen dank für eure antworten. ich bin aber noch nicht ganz überzeugt, dass es so ist, wie ihr geschrieben habt:

ich habe aus dem VPN der uni zugriff auf IPs ausserhalb der uni. ich kann im internet surfen und ich habe eine IP-verbindung zu meinem pc zu hause (via dyndns). ich kann zum beispiel ohne probleme mails von meinem POP3 abrufen. ich kann auch absolut problemlos meinen rechner zu hause anpingen. ABER: dann starte ich über diesen erreichbaren rechner meine (dann zweite) VPN-verbindung. ich bekomme dann vom rechner zu hause eine PPP-IP zugewiesen.

wenn ich dann an dem rechner zu hause einen ping laufen lasse, sehe ich an den icons in der systray den ICMP_ECHO_REQUEST ankommen: die icons sehen folgendermaßen aus:

wlan-karte: in/out aktivität

cisco: zeigt NIE aktivität (das interface scheint nie direkt verwendung zu finden)

mein VPN: incoming-aktivität. nur _keine_ outgoing-pakete

daraus schließe ich, dass der windows-rechner einfach nicht weiß, wohin mit den ICMP_ECHO_REPLYs. die verbindung steht aber IP-mäßig, da ja die auth und die eine richtung des PING klappen.

noch ein paar werte zu meiner config:

Notebook-Seite:

VPN endpunkt 1 (192.168.4.2) || wlan (dhcp) --- cisco (dhcp) --- {internet}

Server-Seite:

{internet} --- dsl (dhcp) --- VPN endpunkt 2 (192.168.4.1)

der server hat mehrere interfaces:

192.168.1.1/255.255.255.0 LAN

192.168.3.1/255.255.255.0 WLAN

192.168.4.1/255.255.255.0 VPN

zwischen diesen ist forwarding aktiv. und es funktioniert soweit in allen richtungen (ich kann die .4.1 aus jedem netzwerk anpingen usw.)

was mich nun noch wundert: das routing in der linux-kiste besagt: pakete an .4.2 gehen über .4.1 raus (eigentlich logisch, pakete an das remote peer müssen über das local interface geroutet werden). der gateway zu dem VPN-Netz ist aber .4.2, denn da sollen ja die pakete hin, die nicht auf der lokalen seite sind.

windows sagt mir am anderen ende der leitung:

lokales interface ist 192.168.4.2

standard-gateway ist 192.168.4.2

sollte dieses gateway nicht auf die 192.168.4.1 zeigen? nach allem was ich in hunderten von seiten über TCP/IP gelesen habe (und ich habe recht viel drüber gelesen) sollte es.

ich habe halt nur wie gesagt unter linux die erfahrung wie ich es einstelle, unter windows reagieren die einstellungen nicht so, wie ich es erwarte.

gruß schlot

Vergiss es, dein Admin hat das abgeschaltet und der einzige Weg es zubekommen ist mit ihm reden. Ich denke aber das die Wahrscheinlichkeit dass er für dich eine Ausnahme machr gagan null gehen dürfte.

Hi schlot,

vertraue uns einfach :D . Ich administriere selbst eine VPN-Umgebung auf Cisco-Basis.

In Deinem Einwahlprofil wurde hinterlegt, dass kein Verkehr außerhalb des Tunnelnetzes zugelassen ist. Das geschieht alles zentral auf der Peerseite, also dem Gateway zu dem Du die VPN-Verbindung aufbaust.

Im Klartext bedeuet dass z.B.:

Du bekommst eine Adresse zu gewiesen aus dem Bereich 192.168.20.0/24, Du kannst alles im diesem Netz erreichen aber nichts außerhalb. Versuchst Du jetzt Dein Rechner zu Hause zu erreichen werden alle IP-Packete zum VPN-Gateway geschickt, wird dort ICMP in das Internet zugelassen so kannst Du ohne weiteres diesen Rechner auch erreichen. Auch Mail über POP3 geht, da auch hier alle Packete an das Gateway geschickt werden. Du versuchst immer öffentliche IP-Adressen zu erreichen.

Wenn Du jetzt eine zweite VPN-Verbindung zu Deinem Heimnetz aufzubaust, bekommst Du eine Adresse aus einem privaten nicht routbaren Bereich. Dein Rechner kann zu diesem Berich keinen Kontakt aufnehmen, da das VPN-Gateway nicht weiss wohin damit und Verbindungen zu Netzen außerhalb des Tunnels nicht erlaubt sind (Splitunnel deaktiviert). Wenn man Splittunneling aktivieren würde, dann würde Deine NIC zwei virtuelle Gateways halten. Jeder Verkehr für das Uni-Netz geht auf das Cisco-Gateway, der Vehrkehr zu Deinem Heimnetz geht über das PPTP-Gateway.

Du könntest eine minimale Chance haben den Mechanismus zu umgehen. Wenn Die IP-Maske des VPN-UNI-Netzes großzügig gewählt ist, dann könnte man versuchen das Heimnetz in die gleiche IP-Range zu setzen wie das Uninetz. Du musst halt nur darauf achten, dass keine doppelten IP-Adressen auftauchen. Benutze für das PPTP-Netz ein sehr kleines Netz (28er Bitmaske). Auf diesem Wege könntest Du evtl. Dein privates Netz erreichen. Logisch betrachtet befindet es sich dann im IP-Bereich des VPN-Uni-Netzes und wird nicht mehr beblockt. Wie gesagt reine Theorie.

Es funktioniert auf jeden Fall unter folgender Konstellation:

VPN-Netz: 192.169.20.0/23

zu Hause: 10.248.29.0/24

Bei bestehender VPN-Verbindung ist keine Kommunikation mit dem Heimnetz möglich. Stellt man das Heimnetz um, z.B. auf 192.168.21.0/28 dann kann man sowohl mit dem VPN-Netz als auch mit dem Heimnetz gleichzeitig arbeite.

Berichte mal ob es klappt.

Gruß Data

ok. du sagst der Cisco-VPN-Router ist so eingerichtet, dass er nur Traffic innerhalb des Uni-Netzwerks zulässt. Also kein Routing nach draussen... Ist aber nicht so, ich kann ja über das VPN im Internet surfen. Ich kann ALLE IPs im Internet erreichen. Und das über die VPN-Verbindung!!!

Und ich habe wie gesagt schon erfolgreich emails von MEINEM pop3 auf MEINEM pc zu hause abgerufen. analog zu der pop3-verbindung, die dann also vom VPN-Interface meines Notebooks (131.82.xxx.yyy) über den gateway zur IP meines pcs zu hause geht (z. b. 212.81.xxx.yyy, t-online halt), kann ich ja auch pakete an einen vpn-server zu hause schicken. ist dann halt nicht tcp-port 110, sondern das GRE-protokoll. soweit funktioniert ja auch alles, das lässt der cisco ohne weiteres zu.

und was in diesen paketen drin ist, interessiert ja den cisco nicht. (ob es POP3-daten oder ein paket im paket ist). private IP-adressen gibts ja erst, sobald die pakete, die übers internet laufen, wieder "ausgepackt" werden. also auf dem notebook und auf meinem pc zu hause. der cisco-router sieht ja nur das envelope-paket. Der Cisco-Router sieht also niemals ein Paket zu einem nicht routbaren bereich, sondern nur zu öffentlichen adressbereichen, wie die T-Online-IP meines PCs. So habe ich den Sinn von Tunneling verstanden...

ich bin davon so fest überzeugt, weil mir IP-Monitoring-Tools sagen, dass die ICMP-Echo-Requests, die ich von zu Hause (192.168.4.1/255.255.255.255) absende, am Notebook (192.168.4.2/255.255.255.255) ankommen! Und das geht ja auch über den Cisco-Gateway!

Nur schickt das Notebook wohl die Replies über das falsche Interface raus: Es nimmt scheinbar das Paket an 192.168.4.1 und sendet es über das 131.82.xxx.yyy-Interface raus. Und da weiß der cisco natürlich nichts mit anzufangen.

Ich will, dass das Notebook die Pakete mit den LAN-Adressen schön brav nimmt, in ein anderes Paket einpackt, als Absender 131.82.xxx.yyy draufschreibt und als Empfänger 212.82.xxx.yyy. So dass ein Paket über das Internet läuft, ohne dass jemand eine private IP sieht; das Paket an meinem Rechner zu Hause wieder ausgepackt wird, und erst da wieder eine private IP da ist.

Und dass die Pakete mit den priv. Adressen nicht verpackt werden, sondern direkt gesendet, ist doch ein lokales Routing-Problem auf dem Notebook...

Hi !

@Data1701: Find ich jetzt keine gute Idee, hier Tipps zu verteilen, wie man administrative Festlegungen umgehen könnte. Allerdings dürfte der Tipp nicht funktionieren, da der Verkehr weiterhin nur über die Cisco-VPN-Schnittstelle läuft.

@schlot: Solange der Cisco-VPN-Client aktiv ist, wird der Datenverkehr über weitere Netzwerkadapter (Deine PPTP-Verbindung ist auch ein solcher) geblockt von der FW.

Es geht dabei nicht darum, ob es private IP-Adressen sind oder nicht.

Der Sinn dieser Einstellung ist der Schutz des dahinter liegenden Netzwerkes.

Da es hier darum geht den von deinem Admin eingerichteten Schutzmechanismus zu umgehen ist der Beitrag geschlossen.

Kläre das mit deinem Admin, oder lebe damit.