WOL über VPN ohne Funktion

[HamBam]

Ich möchte gern PCs in einem Außenstandort mittels WOL aufwecken. Die PCs am Außenstandort befinden sich hinter einem lancomrouter, dieser ist mittels VPN mit dem Hauptstandort verbunden.

Die Firewall schickt das WOL Paket in den VPN Tunnel, der lancom router verwirft dieses jedoch scheinbar.
Im Firewalllogfile des lancomrouters habe ich dazu nichts gefunden. Das Paket wird da nicht aufgeführt.

Ich habe im Forum diverse Posts gefunden mit Firewallregeln, diese haben nicht gegriffen. Die verlinkten Anleitungen im Wiki sind offensichtlich nicht mehr vorhanden.

Wie bekomme ich das zum laufen?

[Fully]

Hallo HamBam,

ohne einen Trace, was wo reingeht und was dann wo rauskommt und dann nicht ankommt, wird Dir leider kaum einer helfen können.
Kannst Du denn den PC direkt vom Lancom am Standort aus aufwecken?

Also von der Konsole aus, mit dem Befehl wakeup (anbei wakeup -?):

Code: Alles auswählen

Usage: wakeup [-d <destination>[%<scope>][%%<ifc>]] [-u <udp-port>] <mac-addr>
                  e.g.: wakeup -d 192.168.1.255 -u 23 00A057010203
-d <destination>  destination ip address or host name
                       (usually a broad- or multicast address)
%scope            name of local interface to reach destination
%%ifc             name of target-interface
-u <udp-port>     UDP port (default = 9)
mac-addr          mac address of the remote device you want to wake up

Vielleicht gibt der Hilfetext schon Hinweise, wo es beim Routing oder der Firewall scheitert.
Gruß Fully

[backslash]

Hi HamBam,

damit lokale Broadcasts von der Firewall nicht verworfen werden, muß es eine Regel geben, die den Broadcast explizit zuläßt, in deinem Fall also

Code: Alles auswählen

Name:     WOL
Aktion:   übertragen
Quelle:   VPN-Gegestelle
Ziel:     Broadcast-Adresse deine LANs, z.B. 192.168.0.255, wenn dein LAN 192.178.0x ist
Dienste:  UDP, Zielports Port 9, 2304

Diese Regel muß alleine stehen und darf in der Zielspalte keine weiteren Netze oder Adressen enthalten.

BTW: der Port 2304 steht nur drin, weil es immer noch WOL-Implementierunfgen gibt, die mit Little-Endian nicht umgehen kommen und die beiden Bytes vertauschen.

Gruß
Backslash

[HamBam]

Der Wakeup vom Lancom aus mittels ssh funktioniert.
Im Logfile der Firewall sieht man auch das das Paket an der VPN Schnittstelle rausgeht.

In der Plastikrouterapokalypse kommt lauf Trace kein WOL Paket an. Wobei ich da eher dem Logfile der Firewall glaube als dem der Plastikkiste.
Das Paket sollte ja im Trace "VPN-Packet" ersichtlich sein oder?

[backslash]

Hi HamBam,

mit diesem Paket hast da das Problem, daß du den Rechner damit nicht aufwecken kannst... Ein WOL-Paket MUSS als Broadcast gesendet werden - in deinem Beispel muß die Ziel-Adresse also (vermutlich) 172.19.8.255 sein.
Auf die 172.19.8.101 kann der Rechner erst reagieren, wenn er aufgewacht ist - denn damit der Router das Paket zustellt, muß der Rechner einen ARP-Request für die Adresse beantworten, was er nicht macht, wenn er schläft. Das einzige, was in so einem Rechner noch halbwegs "lebt" ist die Netzwerkkarte, die das "Magic-Paket" aber auch nur annehmen kann, wenn es als Etnernet-Broadcast gesendet wurde...

Gruß
Backslash

[HamBam]

Das hat mich auch gewundert. Aber inerhalb der Netzte die direkt an der fortigate hängen funktioniert das Netzübergreifend mit diesem Paket.

Dioe Fortigate routet das Paket durch und die PCs wachen auf.

[backslash]

Hi HamBam,

dann hat die Fortigate entweder irgendeine Sonderbehandlung für WOL-Pakete eingebaut oder sie hält die ARP-Auflösung entgegen der gängigen RFCs dauerhaft oder du hast dort eine statische ARP-Auflösung für den Rechner hinterlegt.

Gruß
Backslash

[HamBam]

An der Schnittstelle vom Servervlan sehe ich grundsätzlich 2 ankommende WOL Pakete. Absender ist ein Igelserver.

Das erste Paket ist ein Broadcast im Servervlan, welches erst mal nicht weitergeleitet wird. Weitergeleitet wird scheinbar das zweite Paket welches an die letzte bekannte Hostadresse des Igelclients gesendet wird, damit landet es zumindestens innerhalb des Hauses schon mal im richtigen VLAN und der PC geht an. Womit auch klar ist das nicht die Fortigate hier die Sonderlösung mit ARP hat, sondern die Igelkonsole die letzte bekannte Adresse einsetzt und da die Informationen vorhält.

Außerhalb des Servervlans wird es für die Außenstanbdorte in den VPN Tunnel geschickt und dann verliesen Sie ihn.

[backslash]

Hi HamBam,

nochmal: Du mußt einen gerichteten Broadcast verschicken, der zu dem Zielnetz paßt. Und in der Firewall des LANCOMs im Zielnetz muß du die Regel passend zu dieser Broadcast-Adresse erstellen. Das kann aber nicht die die 172.16.255.255 sein, denn dein Zielrechner hat ja die 172.19.8.101. Wie die Broadcastadresse aussieht, das kannst nur du wissen. Möglichkeiten sind 172.19.8.255, 172,19.255.255 oder 172.31.255.255 jenachdem ob das Zielnetz ein /24, /16 oder /12 Netz ist (bei anderen Netzmasken mu0t du dir das selbst ausrechnen)

Sobald du das Paket an die richtige Adresse schickst und im Ziel-LANCOM die richtige Regel erstellt hast, wird es auch funktionieren - zumindest solange das Paket auf der Quell-Seite in den VPN-Tunnel gelassen wird - zur Fortigate kann ich nunmal nichts sagen

Was aber garantiert nicht funktioniert ist das Paket an die IP des Rechners zu schicken

Gruß
Backlslash

[HamBam]

Du hast Recht. Manchmal sieht man einfach den Wald vor lauter Bäumen nicht wenn man sich zu sehr auf etwas eingeschossen hat.
Ich habe noch einmal eine Nacht darüber geschlafen und dann ist es mir auch direkt aufgefallen...

Ich habe mir die Igel UMS genauer angeschaut wie diese die WOL Pakete zusammensetzt. Hier kann man die Optionen an welche Adressen die Pakete geschickt werden verwalten. Eingestellt war Broadcastadresse und letzte bekannte IP des Hostes. Was soweit auch gemacht wurde, ersichtlich aus dem letzten wiresharklog.
Die Option "Netzadresse der letzten bekannten IP" ist die Option welche man benötigt, wobei man sagen muss das die Option etwas irreführend beschrieben ist (Netzadresse ungleich Broadcastadresse). Ich habe das mit wireshark ausgelesen, diese Option bewirkt ein WOL Paket an die Broadcastadresse der letzten bekannten IP-Adresse. Man hinterlegt in dieser Option einfach alle Subnetzmasken der Netzwerke in denen sich Clients befinden könnten. In meinem fall /16 und /24. Somit werden zwei Broadcasts erzeugt, einer wird verworfen da es das Netzt nicht gibt, der andere wird in das Zielnetz geroutet.

In der Firewall vom Lancom habe ich dann noch die Firewallregel für Broadcasts auf UDB Port 9 angelegt und siehe da: Der Client erwacht zum Leben!
Danke für alle die mitgeholfen haben.

[HamBam]

FW Regel Lancom

[Twincharger]

Wir lösen das mit einem Windows-Dienst Aquilatech WOL Agent. Der Vorteil ist, dass dies mit jeder Firewall bzw. VPN ohne besondere Anpassung funktioniert. Man sendet das WOL-Packet mit der MAC des Zielrechners einfach an die IP des Servers mit dem Dienst. Der macht dann einen lokalen Broadcast draus. Siehe auch https://github.com/basildane/WakeOnLAN/issues/153

[HamBam]

Diese Funktion haben die Igel-Clients direkt integriert, nennt sich da WOL-Proxy oder so ähnlich. Dabei übernimmt ein Igel-Client aus dem Zielnetz die Funktion des WOL-Proxys, bringt uns aber eben nichts, da wir recht viele Standorte mit nur einem Igel-Client haben...