s.k. 11 Geschrieben 6. Mai 2010 Melden Teilen Geschrieben 6. Mai 2010 Hallo EvoIT, mein Statement bezog sich lediglich auf die sehr generalisierte Aussage von Gulp. In Deinem Fall ist die Konstellation eine etwas andere: Die VPN-Tunnel terminieren am Windows-Server - nicht am Lancom-Router. Demzufolge kann der Lancom - genau wie die Router im Internet - nicht das Problem sein, weil er ohnehin nur Unicast-Pakete mit verschlüsseltem Payload sieht. Auch der Windows-Server fungiert hier - bezogen auf die Kommunikation zwischen LAN und VPN-Clients - nicht als Router, denn die VPN-Clients erhalten ja eine IP-Adresse aus dem LAN-Subnetz zugewiesen. Er verhält sich aber auch nicht wie eine normale Bridge. Ich hatte das vor Jahren mal mit einem Win2000 Server näher untersucht: Die VPN-Clients werden im LAN auf Layer 2 mit der Mac-Adresse des VPN-Servers angesprochen - der Server macht also für die VPN-Clients ProxyARP. Lange Rede, kurzer Sinn - konkret bedeutet dies, dass es nur 2 denkbare Fehlerquellen gibt: 1. das WOL-Paket geht Client-seitig nicht den Weg in den Tunnel 2. der Server leitet das WOL-Paket nicht wie gewünscht weiter Um ersteres auszuschließen, habe ich soeben von meinem Notebook mit XPpro einen L2TPoverIPSec-Tunnel zur Firewall in meinem HomeOffice aufgebaut und testweise mit verschiedenen Tools Magic Pakets durchgeschickt. Im Firewall-Log konnte ich alle erzeugten Pakete sehen - und zwar sowohl limited als auch directed brodcasts. Demzufolge kann es nur am Windows-Server liegen! Nun müsste nur noch geklärt werden, ob und ggf. wie man dessen diesbezügliches Verhalten abweichend steuern kann. Auf die Schnelle hab ich leider nichts ergoogeln können... Gruß Steffen Zitieren Link zu diesem Kommentar
EvoIT 10 Geschrieben 8. Mai 2010 Autor Melden Teilen Geschrieben 8. Mai 2010 Hallo EvoIT, mein Statement bezog sich lediglich auf die sehr generalisierte Aussage von Gulp. In Deinem Fall ist die Konstellation eine etwas andere: Die VPN-Tunnel terminieren am Windows-Server - nicht am Lancom-Router. Demzufolge kann der Lancom - genau wie die Router im Internet - nicht das Problem sein, weil er ohnehin nur Unicast-Pakete mit verschlüsseltem Payload sieht. Auch der Windows-Server fungiert hier - bezogen auf die Kommunikation zwischen LAN und VPN-Clients - nicht als Router, denn die VPN-Clients erhalten ja eine IP-Adresse aus dem LAN-Subnetz zugewiesen. Er verhält sich aber auch nicht wie eine normale Bridge. Ich hatte das vor Jahren mal mit einem Win2000 Server näher untersucht: Die VPN-Clients werden im LAN auf Layer 2 mit der Mac-Adresse des VPN-Servers angesprochen - der Server macht also für die VPN-Clients ProxyARP. Lange Rede, kurzer Sinn - konkret bedeutet dies, dass es nur 2 denkbare Fehlerquellen gibt: 1. das WOL-Paket geht Client-seitig nicht den Weg in den Tunnel 2. der Server leitet das WOL-Paket nicht wie gewünscht weiter Um ersteres auszuschließen, habe ich soeben von meinem Notebook mit XPpro einen L2TPoverIPSec-Tunnel zur Firewall in meinem HomeOffice aufgebaut und testweise mit verschiedenen Tools Magic Pakets durchgeschickt. Im Firewall-Log konnte ich alle erzeugten Pakete sehen - und zwar sowohl limited als auch directed brodcasts. Demzufolge kann es nur am Windows-Server liegen! Nun müsste nur noch geklärt werden, ob und ggf. wie man dessen diesbezügliches Verhalten abweichend steuern kann. Auf die Schnelle hab ich leider nichts ergoogeln können... Gruß Steffen Hallo Steffen, erst mal DANKE das Du dich da so reinhängst! :) Ich hänge da genau wie Du in der Luft weis auch nicht mehr weiter aber vielleicht finden wir ja eine Lösung. Wünsche erst mal ein schönes WE .... am Montag geht dann das Testen weiter. ;) Zitieren Link zu diesem Kommentar
sguru 10 Geschrieben 14. Juni 2010 Melden Teilen Geschrieben 14. Juni 2010 Grüße an die Mitstreiter! Ich stehe derzeit vor dem gleichen Problem. Meine Umgebung ist folgendermaßen aufgebaut. Hauptsitz: WOL wurde auf den Core ProcurveSwitche für die anzusprechenden VLANs eingerichtet ip udp-bcast-forward vlan 100 ip forward-protocol udp 192.168.189.255 10 vlan 100 ip forward-protocol udp 10.0.10.255 10 vlan 100 ip forward-protocol udp 10.0.50.255 10 ... HauptsitzCiscoPIX 515E interneIP= 192.168.189.248 (ich bin davon ausgegangen das bei einer wol Anfrage das Log auf der PIX einen Eintrag bringt. Sehe aber nichts dergleichen. ip directed broadcast ist nicht aktiviert.) VPN nach Zweitsitz ZweitsitzCiscoPIX 515E interneIP= 192.168.188.1 Clients am Zweitsitz befinden sich im gleichen Subnetzt wie die interneIP der ZweitsitzCiscoPIX 515E. Bei der PIX gehe ich davon aus das WOL mit einem VPN Tunnel geht. Da hat man sicher was integriert. Die config Befehle müsste man halt wissen! Zitieren Link zu diesem Kommentar
s.k. 11 Geschrieben 14. Juni 2010 Melden Teilen Geschrieben 14. Juni 2010 Hallo, Ich stehe derzeit vor dem gleichen Problem.Meine Umgebung ist folgendermaßen aufgebaut ... Da Deine Tolopogie offenbar gänzlich verschieden ist, erscheint es mir wenig hilfreich, diesen Thread zu kapern! ip directed broadcast ist nicht aktiviert.Ohne wirst Du nicht weit kommen.Zu Fragen der Cisco-Konfiguration solltest Du besser einen Thread im Cisco-Subforum erstellen. Gruß s.k. Zitieren Link zu diesem Kommentar
sguru 10 Geschrieben 14. Juni 2010 Melden Teilen Geschrieben 14. Juni 2010 Ok, ist mir auch recht. Ich werde mein Ding ins Cisco Subforum stellen. :wink2: Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.