Hallo,
ich habe folgendes Problem, wo mir echt die Idee fehlt wie ich weiterkomme.
IPSEC-Client für Zugriff vom Roadwarrior auf das interne LAN eingerichtet.
Client bekommt im Tunnel die IP 172.16.1.1
Im Regelwerk ist eingerichtet:
IPSEC-Client -> Internes LAN -> Accept ANY
Internes LAN -> IPSEC-Client -> Accept ANY
Der Aufbau der IPSEC-Verbindung vom Roadwarrior zur Firewall und der Zugriff aufs LAN funktioniert einwandfrei. Die Interneteinwahl am Roadwarrior läuft über MSN und eine ISDN-Karte (geht leider nicht anders).
Mit Hilfe der Securepoint-Hotline kann ich den Client 172.16.1.1 auch anpingen (hier muss das HIDE-NAT für die Client-IP ausgenommen werden).
Nur kann ich nicht für den Webserver (IIS) und den Freigabedienst des Clients zugreifen (Diese Sachen sind in XP-Firewall und in der MSN-Verbindung freigeschalten).
Ist der Roadwarrior ganz normal im LAN funktioniert es.
Ich brauche diese Funktion aber für eine IP-Telefonsoftware (SwyxIT).
Hat ihr irgendjemand eine Idee, wo ich noch suchen soll.
mfg
Stefan Zach
Zugriff auf IPSEC-Roadwarrior aus internem LAN
Moderator: Securepoint
-
StefanZach
- Beiträge: 11
- Registriert: Fr 23.03.2007, 16:46
Hallo,
ich kenne das System persoenlich nicht, aber habe mal schnell einen Blick auf die Software geworfen.
So wie das ausschaut, wir die Anfrage ueber RPC-Aufrufe (tcp 135) abgehandelt, die wenn es um WAN-Strecken und dementsprechende Bandbreiten-Einbrueche geht, nur mit Glueck bis gar nicht funktionieren.
Im Log wird dementsprechend kein DROP angezeigt, aber die Antwortzeit fuer den RPC-Aufruf ist einfach zu lange, was den Zustand erklaeren wuerde, dass es im LAN ohne Probleme funktioniert.
Hat die Software evtl. eine Logging/Debugging-Funktion, ueber die man das Problem noch weiter eingrenzen kann?
Gruss
M.Goeres
ich kenne das System persoenlich nicht, aber habe mal schnell einen Blick auf die Software geworfen.
So wie das ausschaut, wir die Anfrage ueber RPC-Aufrufe (tcp 135) abgehandelt, die wenn es um WAN-Strecken und dementsprechende Bandbreiten-Einbrueche geht, nur mit Glueck bis gar nicht funktionieren.
Im Log wird dementsprechend kein DROP angezeigt, aber die Antwortzeit fuer den RPC-Aufruf ist einfach zu lange, was den Zustand erklaeren wuerde, dass es im LAN ohne Probleme funktioniert.
Hat die Software evtl. eine Logging/Debugging-Funktion, ueber die man das Problem noch weiter eingrenzen kann?
Gruss
M.Goeres
Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen
- Albert Einstein -
- Albert Einstein -
-
StefanZach
- Beiträge: 11
- Registriert: Fr 23.03.2007, 16:46
Hallo,
erst einmal danke für die Antwort. Irgend eine Logging-Funktion wird es sicherlich gebe, ich mache mich da einmal schlau.
Etwas ist mir auch aufgefallen. Auf dem Client gibt es auch eine Windows-Dateifreigabe und eine kleine Web-Anwendung, welche über IIS verfügbar ist.
Hier nun das seltsame, was ich nicht verstehe (aber vielleicht fehlt es mir da auch irgendwie).
Über den Tunnel (IP-Adresse im Tunnel) kann ich weder die Freigabe noch die IIS-Seite ansprechen. Über die öffentliche IP der ISDN-einwahl errreiche ich nur die IIS-Seite aber nicht die Freigabe.
Also vermutlich doch ein Geschwindigkeitsproblem?
mfg
Stefan Zach
erst einmal danke für die Antwort. Irgend eine Logging-Funktion wird es sicherlich gebe, ich mache mich da einmal schlau.
Etwas ist mir auch aufgefallen. Auf dem Client gibt es auch eine Windows-Dateifreigabe und eine kleine Web-Anwendung, welche über IIS verfügbar ist.
Hier nun das seltsame, was ich nicht verstehe (aber vielleicht fehlt es mir da auch irgendwie).
Über den Tunnel (IP-Adresse im Tunnel) kann ich weder die Freigabe noch die IIS-Seite ansprechen. Über die öffentliche IP der ISDN-einwahl errreiche ich nur die IIS-Seite aber nicht die Freigabe.
Also vermutlich doch ein Geschwindigkeitsproblem?
mfg
Stefan Zach
-
StefanZach
- Beiträge: 11
- Registriert: Fr 23.03.2007, 16:46
Ich habe noch etwas getestet und kann folgendes feststellen:
Wenn ich mit ISDN-Interneteinwahl und Greenbow-VPN-Client zugreifen, kann ich wunderbar auf die Freigaben im LAN zugreifen. Nur aus dem LAN kann ich nicht auf die Freigabe des Clients über den Tunnel zugreifen. Also könnte man ein Zeitproblem sicherlich ausschließen.
Dann noch etwas seltsames. Wenn ich mich mit dem IPSec-Client verbinde und mich im LAN an einem Terminalserver anmelde, kann man am Terminalserver die Quelladresse der Anfrage anzeigen.
Hier wird jedoch die IP der MSN-Einwahl antgezeigt und nicht die IP im Tunnel. Das ist noch seltsamer. Wie kann so etwas funktionieren. Da verstehe ich die VPN-Sache nicht mehr.
Bei einer Einwahl mit PPTP erscheint hier die IP-Adresse im Tunnel und nicht die öffentliche IP der MSN-Einwahl.
mfg
Stefan Zach
Wenn ich mit ISDN-Interneteinwahl und Greenbow-VPN-Client zugreifen, kann ich wunderbar auf die Freigaben im LAN zugreifen. Nur aus dem LAN kann ich nicht auf die Freigabe des Clients über den Tunnel zugreifen. Also könnte man ein Zeitproblem sicherlich ausschließen.
Dann noch etwas seltsames. Wenn ich mich mit dem IPSec-Client verbinde und mich im LAN an einem Terminalserver anmelde, kann man am Terminalserver die Quelladresse der Anfrage anzeigen.
Hier wird jedoch die IP der MSN-Einwahl antgezeigt und nicht die IP im Tunnel. Das ist noch seltsamer. Wie kann so etwas funktionieren. Da verstehe ich die VPN-Sache nicht mehr.
Bei einer Einwahl mit PPTP erscheint hier die IP-Adresse im Tunnel und nicht die öffentliche IP der MSN-Einwahl.
mfg
Stefan Zach
-
StefanZach
- Beiträge: 11
- Registriert: Fr 23.03.2007, 16:46
So ich habe es jetzt hinbekommen, dass alles so funktioniert wie es soll. Hat mich zwar fast einen Tag gekostet aber es funktioniert nun (auch über schmalle Leitungen).
Hier kurz mein Vorgehen, falls jemand ähnliche Problem haben sollte:
- Nachdem mir das Verhalten des Greenbow-Client immer rätselhafter wurde, habe ich diesen kurzerhand entfernt
- Danach habe ich Watchguard Mobile User VPN von Safenet installiert (kenne ich von anderen Installationen) und die Verbindung konfiguriert -> Verbindung klappte auf Anhieb. Der Zugriff aus dem LAN auf den Roadwarrior und die Telefonsoftware lief erst mal nicht.
- Dann habe ich die Firewall vom XP deaktiviert und schon funktionierte es. Aber warum geht es dann im LAN auch mit XP-Firewall. Kurz (bzw. länger) nachgedacht. Lösung - Auch bei dieser Firewall kann man die Bereich konfigurieren. also habe ich die Freischaltungen für alle PCS aktiviert
Und schon geht es über den IPSEC-Tunnel problemlos
Also Watchguard wieder runter und Greenbow drauf. Es geht wieder nicht. Warum? Keine Ahnung. Greenbow runter, Watchguard drauf. Es geht!
Ich vermute es liegt daran, dass der Watchguard-Client einen Virtuellen Adapter mit der IPSEC-Verbindung startet, welche die IP im Tunnel bekommt. Scheinbar wird dies benötigt um dann auf den Client zu kommen.
Ich werde für diesen Fall also in Zukunft den Watchguard-Client einsetzen. Dann weiß ich das es funktioniert.
So und nun kann ich von überall auf der Welt so tun, als ob auch vom Büro aus anrufe.
mfg
Stefan Zach
Hier kurz mein Vorgehen, falls jemand ähnliche Problem haben sollte:
- Nachdem mir das Verhalten des Greenbow-Client immer rätselhafter wurde, habe ich diesen kurzerhand entfernt
- Danach habe ich Watchguard Mobile User VPN von Safenet installiert (kenne ich von anderen Installationen) und die Verbindung konfiguriert -> Verbindung klappte auf Anhieb. Der Zugriff aus dem LAN auf den Roadwarrior und die Telefonsoftware lief erst mal nicht.
- Dann habe ich die Firewall vom XP deaktiviert und schon funktionierte es. Aber warum geht es dann im LAN auch mit XP-Firewall. Kurz (bzw. länger) nachgedacht. Lösung - Auch bei dieser Firewall kann man die Bereich konfigurieren. also habe ich die Freischaltungen für alle PCS aktiviert
Und schon geht es über den IPSEC-Tunnel problemlos
Also Watchguard wieder runter und Greenbow drauf. Es geht wieder nicht. Warum? Keine Ahnung. Greenbow runter, Watchguard drauf. Es geht!
Ich vermute es liegt daran, dass der Watchguard-Client einen Virtuellen Adapter mit der IPSEC-Verbindung startet, welche die IP im Tunnel bekommt. Scheinbar wird dies benötigt um dann auf den Client zu kommen.
Ich werde für diesen Fall also in Zukunft den Watchguard-Client einsetzen. Dann weiß ich das es funktioniert.
So und nun kann ich von überall auf der Welt so tun, als ob auch vom Büro aus anrufe.
mfg
Stefan Zach