Jump to content

Magic Packet durch einen VPN-Tunnel senden


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar
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. ;)

Link zu diesem Kommentar
  • 1 Monat später...

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!

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...