GELÖST: AVC ignoriert einzelne Split Tunneling-Einträge...

Anmeldungsdatum: 06.04.2010 Beiträge: 9

Hallo,

wir arbeiten derzeit mitder AVC Version 2.23 Build 18 unter WinXP SP3.

Das im Titel benannte Problem sieht wie folgt aus:

Wir wählen uns per AVC auf einen 1721 ein, um zwei dahinter liegende Subnetze zu erreichen, die auf 192.168.5.0/24 und 192.168.6.0/24 hören.

Der Client bekommt eine Adresse aus dem 192.168.5.0-Bereich zugewiesen. Da wir aus verschiedenen Gründen gleichzeitig in eines unserer Netze und in die entfernten Netze greifen müssen, habe ich die beiden entfernten Netze in die Split Tunneling-Tabelle gesetzt.

Nach Einwahl ist das 5-Netz immer zu erreichen, das 6-er Netz dagegen nur wenige Sekunden.
Anfangs sind Routing-Einträge für beide entfernten Netze in der Routing-Tabelle von Windows. Diese zeigen auf die gleichzeitig mit der Adresse übetragene (um 1 höhere) Gateway-Adresse:

(Hier haben wir die 192.168.5.180 zugewiesen bekommen)

Code:

===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
192.168.5.0 255.255.255.0 192.168.5.180 192.168.5.180 1
192.168.5.0 255.255.255.0 192.168.5.181 192.168.5.180 1
192.168.5.180 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.5.255 255.255.255.255 192.168.5.180 192.168.5.180 1
192.168.6.0 255.255.255.0 192.168.5.181 192.168.5.180 1
===========================================================================

Später ist nur noch ein Eintrag für das 5-er -Netz in der Routingtabelle, der zudem auch nur noch auf die virtuelle Schnittstelle zeigt:

Code:

===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
192.168.5.0 255.255.255.0 192.168.5.180 192.168.5.180 1
192.168.5.180 255.255.255.255 127.0.0.1 127.0.0.1 1
192.168.5.255 255.255.255.255 192.168.5.180 192.168.5.180 1
===========================================================================

Andere Netze und das I-Net werden (wie vom Split Tunneling bezweckt) korrekt über das Default-Gateway des jeweiligen Client-Rechners geroutet. Die Split Tunnelingfkt. an sich arbeitet also wie 'ne Eins, nur fehlt die korrekte Route zu einem der Zielnetze.

Wenn ich dagegen den Zugang mit dem Shrewsoft VPN Client 2.17 realisiere, werden nur Routen auf die zugewiesene Schnittstellenadresse gelegt, welche auch erhalten bleiben. Hier klappt dann das Split- Tunneling auch und es wird korrekt in beide Zielnetze geroutet:

(Diesmal wurde die 192.168.5.185 zugewiesen.)

Code:

===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Anzahl
192.168.5.0 255.255.255.0 192.168.5.185 192.168.5.185 1
192.168.5.185 255.255.255.255 127.0.0.1 127.0.0.1 30
192.168.5.255 255.255.255.255 192.168.5.185 192.168.5.185 30
192.168.6.0 255.255.255.0 192.168.5.185 192.168.5.185 1
===========================================================================

Der Tipp "Dann nimm doch den Shrewsoft" zieht leider nicht, da ich dort keine FW im Client habe und so der Client-Rechner ein offenes Tor des Kundennetzes hinter unserer (von mir toll konfigurierten FW des LANCOM 7100 VPN Wink

) darstellt. Zudem ist der ansonsten sehr gute AVC bei uns Standard-Lösung, das beschriebene Routing-Problem haben wir mit dem aber auch an anderer Stelle.

Ich muß noch folgendes dazu sagen:
das Lancom 1721 beim Kunden wird durch einen Zulieferer konfiguriert und gewartet. Wir haben demnach keinerlei Zugriff auf dessen Konfiguration. Auch überschneiden sich die zugewiesenen Einwahladressen nicht mit denen unserer eigenen Subnetze.

Ich bilde mir ein, das Problem vor einer ganzen Weile schon in einem anderen Thread gesehen zu haben, habe den aber nicht wieder gefunden.
Also wenn ich hier was aus Urzeiten wieder nach oben spüle, entschuldige ich mich vorab.

Danke schon mal, cambies

Anmeldungsdatum: 01.04.2007 Beiträge: 60

Hi,

das beschriebene Verhalten kommt mir doch irgendwo her bekannt vor:

http://de.watchguard-blog.com/2010/11/xtm-...ng-in.html

Watchguard benutzt auch NCP. Vielleicht hilfts ja was!?

Anmeldungsdatum: 06.04.2010 Beiträge: 9

Super, vielen Dank, abc987,

Auf die Schnelle die Lösung für Eilige, die nicht den Blog durchlesen wollen:

Wahrscheinliche Vorraussetzungen für die Fehler

Lösung (eher Behelf):

-------------------------------------------------------------------------
Bei uns treffen die Gegebenheiten genauso wie im Blog beschrieben zu.
Den Novell-Client samt eDirectory hab ich eh lieben gelernt: dieser ganze Mist mit den Multicasts bei der Anmeldung und den damit verbundenen Routing-Problemen hat nur Ärger gebracht und erfordert Krücken, die auch nur zu 75% funktionieren, aber das ist was anderes.

Bisher hat esbei 3 von 4 Rechnern geholfen: Wie im Tipp beschrieben, habe ich die 802.1x-Authentifizierung 'rausgenommen und siehe da: die Routen bleiben erhalten.

Nur mein eigener Läppi will nicht mehr: blöderweise musste ich zuvor den AVC neu installieren, da der Eintrag für den virtuellen Adapter in der Systemsteuerung fehlte, sodaß ich gar nicht an den Parameter 'rangekommen bin.

Hinterher gab's den virt. Adapter zwar wieder, Authent. habe ich auch abgestellt, jetzt fehlt dafür die Route ins o.g. 6er Netz sofort nach erfolgreichem Einloggen. Mist....aber bei meinem Läppi ist das erst einmal egal, wer weiß, was dem jetzt fehlt.

Also, vielen Dank nochmal,
Cambies