Ich verbinde mich mittels meines SSL-Clients auf unsere ASG 320. Die Verbindung wird auch einwandfrei aufgebaut, jedoch wird vom SSL-Client der Standard-Gateway nicht geändert, sodass ich nicht ins lokale Netz komme.
Dieses Problem tritt allerdings nicht bei allen Clients auf. Bei einigen funktioniert es auch.
Ich hatte das Problem vor einiger Zeit schon einmal mit einem Windows-Vista-Client, bei dem ich dem Astaro-SSL-Client erst Admin-Rechte geben musste, damit er den Standard-Gateway ändern durfte. Nach Änderung der Rechte funktioniert die Verbindung dann auch, aber das ist diesmal nicht das Problem.
Ich habe es inzwischen auf 2 Windows XP, einem Windows Vista und einem Windows 7 Client versucht und auf allen das gleiche Problem. Der Standard-Gateway wird nicht geändert.
Dann habe ich aber noch 2 Windows XP und einen Vista Client auf dem funktioniert es einwandfrei.
Hier ist einmal der Auszug aus dem Log des Client von einem XP-Client auf dem es funktioniert:
Mon Oct 26 12:14:47 2009 route ADD ***.**.**.216 MASK 255.255.255.255 **.**.***.43
Mon Oct 26 12:14:47 2009 Route addition via IPAPI succeeded [adaptive]
Mon Oct 26 12:14:47 2009 route DELETE 0.0.0.0 MASK 0.0.0.0 **.**.***.43
Mon Oct 26 12:14:47 2009 Route deletion via IPAPI succeeded [adaptive]
Mon Oct 26 12:14:47 2009 route ADD 0.0.0.0 MASK 0.0.0.0 10.242.20.5
Mon Oct 26 12:14:47 2009 Route addition via IPAPI succeeded [adaptive]
Mon Oct 26 12:14:47 2009 route ADD 10.242.20.1 MASK 255.255.255.255 10.242.20.5
Mon Oct 26 12:14:47 2009 Route addition via IPAPI succeeded [adaptive]
Mon Oct 26 12:14:47 2009 Initialization Sequence Completed
So sieht es auf einem der Clients aus, auf denen es logischerweise nicht funktioniert:
Mon Oct 26 13:02:58 2009 Successful ARP Flush on interface [16] {9C6AFF8E-6BBC-4697-9235-06F157EC850E}
Mon Oct 26 13:03:03 2009 TEST ROUTES: 2/2 succeeded len=1 ret=1 a=0 u/d=up
Mon Oct 26 13:03:03 2009 C:\WINDOWS\system32\route.exe ADD ***.**.**.216 MASK 255.255.255.255 ***.***.*.1
Mon Oct 26 13:03:03 2009 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=10 and dwForwardType=4
Mon Oct 26 13:03:03 2009 Route addition via IPAPI succeeded [adaptive]
Mon Oct 26 13:03:03 2009 C:\WINDOWS\system32\route.exe ADD 10.242.20.1 MASK 255.255.255.255 **.***.**.5
Mon Oct 26 13:03:03 2009 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Mon Oct 26 13:03:03 2009 Route addition via IPAPI succeeded [adaptive]
Mon Oct 26 13:03:03 2009 Initialization Sequence Completed
Wie man sehen kann, versucht der Client auf den Maschinen auf denen es nicht läuft es gar nicht den Standard-Gateway zu setzten und trägt nur eine einzige Route zwischen dem Client und der Firewall ein, sodass diese zwar erreichbar ist, aber alle anderen Anfragen ins Inet gesendet werden, statt an die ASG.
Das Problem ist somit eigentlich klar, ich verstehe nur nicht, warum der SSL-Client das tut, bzw. warum er bei einigen Rechnern funktioniert und bei anderen nicht.
Erwähnen sollte ich noch, das auf meinem Notebook z.B. der Client letzte Woche noch funktionierte, nun aber das gleiche Problem hat, ohne das eine Änderung am Client, der Firewall oder sonst etwas statt gefunden hat.
Wenn ich den Gateway übrigends über route delete/add ändere funktioniert danach die Verbindung tadellos, aber das ist ja keine dauerhafte Lösung.
Mit freundlichen Grüßen!
-mordy
This thread was automatically locked due to age.
