Wie wäre es mit einer nachvollziehbaren Beschreibung der Konfiguration? Wenn der VPN-Zugang auf einen LAN-Port beschränkt ist, ist ja dort der Zugriff auf andere Geräte im LAN dieser Box gar nicht möglich, damit auch kein "Aufwecken". Wenn sich das schlafende Gerät allerdings im entfernten Netz befindet, dann könnte das funktionieren ... das kann man aber in #1 nicht ablesen, wo sich nun der schlafende Leu befindet (die Frage, ob man den wecken sollte, stelle ich mal nicht).
Ansonsten gibt es ein generelles WOL-Problem in einigen Versionen. Da Du ja betonst, daß es nur beim VPN-Zugriff nicht funktioniert ... darf/soll man daraus schließen, daß es beim direkten Internetzugriff mit dem Wecken funktioniert? Wenn nicht, erübrigt sich sicherlich die "Fehlersuche" in der Richtung, daß/warum es am VPN liegt - wobei auch das sein kann. M.W. ist es (außerhalb von AVM) weitgehend unbekannt, an welcher Stelle auf dem IP-(WAN-)Stack von AVM diese Funktion nun implementiert wurde und wenn das
vor der Entschlüsselung der IPSec-Pakete ist, dann "sieht" der "kdsld" wohl gar nicht, daß da ein Gerät anzusprechen ist, das erst noch zu erwecken wäre.
Ansonsten sollte man sich das auch tatsächlich selbst bauen können, wenn der betreffende PC auch mit Paketen erweckt werden kann, die auf L2 eine Unicast-Adresse (also die MAC-Adresse des zu weckenden PC) enthalten. Ist das nicht der Fall, klappt das mit der LAN-LAN-Variante nicht, weil man keine Broadcast-Pakete (auf L2) aus der Ferne in das LAN kriegt. Reagiert der Rechner aber auch auf Unicast-Pakete (normalerweise sollte er das tun), muß man nur dafür sorgen, daß die richtigen Inhalte für ein "magic packet" halt auf L3 übermittelt werden ... die können sich auch in jedem beliebigen IP-Paket "verbergen". Allerdings setzt das wieder voraus, daß der (VPN-)Router auch dann Pakete für einen LAN-Client annimmt und mit dessen (fester) MAC-Adresse ins LAN sendet, wenn der im Moment gar nicht auf ARP-Anfragen reagiert (weil er ja schlummert).
Wenn an dem separierten LAN-Port tatsächlich nur ein einziger LAN-Client hängt, dann ist es hier vielleicht sogar besser, mit einer anderen VPN-Verbindung (Device-LAN-Kopplung) zu arbeiten, weil dabei das gekoppelte Gerät eine IP-Adresse aus dem LAN-Segment der Gegenseite erhält und damit auch das Aussenden von L2-Broadcasts ins LAN möglich ist (bzw. sein sollte, denn das, was da in den VPN-Tunnel gesendet wird, liegt ja im Ermessen des Peers).
Was soll eigentlich
Und ein WOL-Paket aus einem anderen Subnet ignoriert der Rechner leider ...
genau heißen? Ist das "verbürgt" (sprich: getestet und mitgeschnitten), daß das Paket im entfernten LAN ankommt und tatsächlich ignoriert wird (woher weiß der PC dann eigentlich, welches Subnetz er ignorieren soll/darf und welches nicht?) oder ist das nur reines Schlußfolgern aufgrund der Beobachtung, daß es halt nicht funktioniert? Wenn letzteres, was wurde denn genau "probiert"?