Dabei gibt's im NCP-Client ein extra Häkchen, damit der auch Broadcasts tunnelt!
Ich kenne diesen Client gar nicht ... aber irgendwie verstehe ich auch nicht (ich habe schon verstanden, daß Du ihn an anderer Stelle wohl auch noch einsetzt), warum Du Dir - solange Du nicht auf positive Erfahrungsberichte zurückgreifen kannst - überhaupt diese Mühe machst.
Selbst wenn der Client Broadcasts von Dir an Omas Netz tunnelt, heißt das ja noch nicht, daß es umgekehrt genauso läuft, denn da entscheidet das AVM-IPSec, was in den Tunnel geht und was nicht und so wie die IPSec-Implemtierung bei AVM realisiert ist, klappt das eher nicht. Pakete für VPN-Verbindungen müssen - i.d.R. über die Default-Route beim LAN-LAN oder über eine explizite Route bei Host-LAN - am "dev dsl" der Box vorbeikommen, damit sie in IPSec gekapselt und auf die Reise geschickt werden. Da das bei BC-Paketen schon mal nicht so laufen kann (die werden gar nicht erst in das Routing "gelassen"), kriegst Du BC-Traffic aus dem Netz einer FRITZ!Box ohne zusätzliche Software auf der Box auch nicht auf die andere Seite, was bei Deinem UPnP-Szenario dann schon ein Problem werden kann. Also bleibt am Ende ohnehin nur die Lösung, anstatt des Broadcast-Traffic ganz gezielt mit Unicasts auf die Geräte bei Oma zuzugreifen und da spielt dann - immer nur nach meinem Verständnis, vielleicht sehe ich ja auch einen Aspekt nicht - die Broadcast-Fähigkeit des NCP-Clients einfach keine Rolle ... außer alle von Dir einzusetzenden Protokolle antworten auf eine per Broadcast empfangene Anfrage prinzipiell immer mit einer UC-Response, was bei einem einfachen "Huhu, ist da wer?" nicht automatisch der Fall sein muß, denn auch eine Broadcast-Response kann an so einer Stelle Sinn machen.
Bestätigte VPN-Clients für AVM-IPSec unter Windows-Betriebssystemen sind meines Wissens der FFZ und der Shrewsoft-Client, zumindest bei den kostenfrei verfügbaren ... gibt es für Deinen Client auch entsprechende Meldungen oder willst Du am Ende auch der Erste sein, der diesen erfolgreich mit einem AVM-IPSec in einer FRITZ!Box gekoppelt hat (wenn Du die notwendigen IPSec-Grundlagen hast, was Du selbst am besten einschätzen kannst) ? Das kann ich dann alles als Begründung nachvollziehen ... ansonsten würde ich den einfach links liegen lassen und mich (hoffentlich) erfolgsversprechenderen Aufgabenstellungen widmen.
Wenn ich mir dann Deine anderen Vorhaben vor Augen führe (permanenter Proxy für BJNP-Protokoll zu Oma, Zugriff auf UPnP-Devices bei Oma (wenn ich das mit der Ixus richtig verstehe)), bleibe ich am Ende dabei, daß Du mit einer VPN-Verbindung aus der Linux-VM (mit Bridge zum Windows-Netzwerk bei VMware) und einer von der Linux-VM aufgebauten Host-LAN-Verbindung (racoon oder StrongSwan, die Linux-VM ist am Ende "road warrior" und baut immer selbst die Verbindung zur FRITZ!Box bei Oma auf) einfach am besten fahren würdest, da Du sämtlichen Netzwerk-Verkehr von und zu Oma durch die VM leiten und dabei nach Herzenslust "manipulieren" kannst. Wenn dann im Windows-Routing die Linux-VM als Gateway in Richtung auf Omas IP-Subnetz eingetragen ist, spielt auch die Bridge (mit dem automatischen "Sniffen") keine Rolle mehr und Du hast eine richtig ordentliche Konfiguration.
Natürlich auf Kosten der zusätzlich notwendigen Linux-VM, aber mit VMware-Player ist die Software schon mal kein Kostenfaktor in finanzieller Hinsicht und wenn das erst einmal eingerichtet ist und läuft, kann man die VM als "Oma-Konnektor" ja auch auf andere Systeme übertragen und muß nicht unbedingt ein zu schwachbrüstiges Gerät verwenden, wo die VM eine echte Belastung für die Performance ist. Andererseits ... auch der Aspekt, daß Du ja sicherlich nicht permanent in Omas Netz unterwegs sein mußt und die VM dann nur bei Bedarf zu starten ist, ist ja zu beachten, da ist das Performance-Argument dann auch nur temporär zu bewerten.
Spätestens wenn man die von Dir gewünschten Manipulationen am Netzwerk-Verkehr noch in Betracht zieht (es sein denn, Du erhoffst Dir den Wegfall der Notwendigkeit solcher Manipulationen durch den NCP-Client), würde ich ohnehin nicht mehr auf die Windows-Netzwerkfähigkeiten oder auf Windows-Programme setzen. Das ist nun einmal nicht die Domäne dieses Systems und dafür ist ein Linux einfach wesentlich besser geeignet, schon alleine deshalb, weil es die ganzen dafür notwendigen Tools eigentlich in erster Linie für *nix-Systeme gibt.
The best tool for the job ... das heißt auch, lieber ein weiteres Betriebssystem in einer VM als unnötigen Aufwand im Windows-Netzwerkbereich. Windows hat seine Berechtigung, das muß man auch noch einmal feststellen, damit die Glaubenskrieger diesseits und jenseits der GUI-Demarkationslinie nicht auf die Barrikaden gehen ... im (kommunikativen) Netzwerkbereich würde ich diese Berechtigung aber eher nicht sehen.
EDIT: Ich habe jetzt erst die Fehlermeldung des NCP-Client in Deinem Beitrag so richtig zur Kenntnis genommen. Aus dem Bauch heraus würde ich sagen, da reden die beiden Partner aneinander vorbei. In Phase2 wird dann schon auf dem verschlüsselten Kanal kommuniziert (da wird das "logische" Netz eingerichtet), wenn da eine erwartete Nachricht ausbleibt, ist das i.d.R. ein Port- oder ein Verschlüsselungsproblem. Die FRITZ!Box führt in der Datei /var/tmp/ike.log ein Protokoll (per Telnet oder im Rahmen der Support-Daten zu erreichen), das kann man mit dem Log des Clients abgleichen. So kann man dann auch sehen, in welchem Status jede Seite ist und ob die erwartete Nachricht überhaupt nicht gesendet wurde oder nur nicht ankam. Vielleicht kriegst Du den NCP-Client ja doch noch ans Laufen, auch wenn ich (s.o.) nicht sehe, was das bringt ... aber ich sehe ja vielleicht auch nicht alles und Du hast u.U. gute Gründe dafür.
).
