Photogregor Geschrieben 5. Juli 2013 Teilen Geschrieben 5. Juli 2013 Hallo Forum, gibt es vielleicht einen Watchguard-Crack hier? Folgendes: Auf einem W7-Pc habe ich den Watchguard SSLVPN-Client installiert (Version 11.3.5), anschließend habe ich auf der Watchguard (x750e, Version 11.3.4) die SSLVPN-Konfiguration aktiviert und Routing als Standardverfahren eingestellt. Alle andere Einstellungen sind default. Der Client connected problemlos, die Authentifizierung (Radius, Server ist ein SBS 2011) funktioniert. Auf dem Client erhalte ich erwartungsgemäß nach dem Connect die IP-Adresse 192.168.113.3. Auf der Watchguard wurden beim SSLVPN-Setup 3 Rules erstellt, eine Any-Rule ("Allow SSLVPN-Users") und zwei weitere Rule ("WatchGuard SSLVPN" and "WatchGuard Authentication"). Soweit scheint alles prima. Aber ich kann das interne Subnetz des SBS (192.168.1.0/24) nicht pingen. Sogar die IP 192.168.113.254, die von ipconfig als DHCP-Server der Firebox genannt wird, antwortet nicht auf einen Ping. Im Traffic Monitor sehe ich, dass die eingehenden Pings geblockt werden - offensichtlich fehlt noch irgendeine Rule. Da ich nun schon viele Stunden ohne Erfolg recherchiert habe, meine Bitte: Kann mir vielleicht jemand einen kurzen Tip geben und mich in die richtige Richtung steuern? Zusatzinfo: Der Client hat die IP-Adresse 192.168.1.115 und ist Member der SBS-Domäne. Vielen Dank und Grüße, Stefano Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Gast Geschrieben 6. Juli 2013 Teilen Geschrieben 6. Juli 2013 Hallo! 1. Kann es sein, dass Du per se ICMP im Netzwerk verboten hast? Funktioniert eine RDP- oder HTTP-Verbindung zum SBS? Sieht so aus als würde die Watchguard den Client als external behandeln, insofern greifen auch die Regeln für external. 2. Probier doch mal bitte, anstatt des "Route VPN Traffic", "Bridge VPN Traffic" einzustellen. Außerdem sollt der gesamte Verkehr erst mal durch den Tunnel gehen, um Fehler dort auszuschließen. Denn nicht vergessen: Wenn nur der VPN-Traffic durch den Tunnel geht, wird natürlich auch deine lokale Routingtabelle auf dem Client beachtet. Gibt es dort keine Route in das 1er-Netz, sieht es düster aus. Wie sieht es überhaupt mit gesetzten Routen aus? Die Zusatzinfo "Mitglied der Domäne" ist für Deine Beschreibung erstmal irrelevant. Wichtiger finde ich, dass Du den kompletten Regelsatz aus dem Policy Manager postest. Außerdem wäre ein Auszug aus dem Log (SSL-Verhandlung UND ICMP-Filteraktion) nötig. Ansonsten wirds schwierig, den Fehler zu finden. Vertrauliche Stellen kannst Du ja ausgrauen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Photogregor Geschrieben 8. Juli 2013 Autor Teilen Geschrieben 8. Juli 2013 Hallo, vielen Dank für dein Feedback. ICMP funktioniert im Netz ansonsten problemlos. Alles was sonst funktioniert - Ping, RDP, HTTP - geht nur über die VPN-Verbindung nicht. Ein guter Tipp ist der bridged mode: Den habe ich testweise mal eingeschaltet und damit gibt es keinerlei Probleme: Ping, RDP, HTTP funktioniert einwandfrei (ich habe im traffic monitor geprüft, ob der HTTP-Traffic auch tatsächlich von der Watchguard geloggt wird, was der Fall war). Aber auch nur bei der Option "Force all client traffic through tunnel", wenn ich diese ausschalte, funktioniert's auch im bridged mode nicht. Zusammengefasst: Im Bridge-Modus funktioniert es nicht, wenn der Traffic gesplittet wird und funktioniert, wenn alles über die VPN-Verbindung geht, im Router-Modus funktioniert es in beiden Varianten nicht. Da das im Bridge-Modus funktioniert, würde ich ein Authentifizierungsproblem ausschließen. Ich vermute in der Tat, dass entweder eine weitere Rule erforderlich ist oder dass das Routing auf dem Client nicht stimmt. Die drei relevanten Rules, die der SSLVPN-Wizard anlegt, lauten: 1 WatchGuard SSLVPN SSL-VPN Any-External Any-Trusted Any-Optional Firebox tcp:444 2 WatchGuard Authentication WG-Auth Any-External Any-Trusted Any-Optional Firebox tcp:4100 88 Allow SSLVPN-Users Any SSLVPN-Users (RADIUS) Any Any In der ersten Spalte steht die Rangfolge ("Order"), dann Policy-Name, Policy-Type, "From", "To", und der TCP-Port. Hast du vielleicht noch eine Idee? Besten Dank und viele Grüße, Stefano Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.