OPEN VP will nicht auf VM-orientierter EFW

1. offizieller Beitrag

    Wir haben unsere EFW 2.5.2 weg von exklusiver Hardware hinzu einer VM-Orientierten Lösung überführt.
    Sie läuft nun unter VitualPC (Microsoft).
    Bewerkstelligung: Installation auf VM, dann Backup retur in die VM-Lösung. Jedes Netz hat eine eigene echte Netzwerkkarte.
    Das haben wir der eleganteren Redundanz wegen.

    Alles läuft gut, bis auf:
    OPEN VPN
    Der Client baut die Verbindung auf, IP wird aus der Range bereitgestellt und ein ping auf die EFW ist möglich, auch kann ich die EFW via GUI erreichen (x.x.10.254), allerdings ist das Erreichen aller anderen Rechner im entfernten Netz x.x.10.x weder per ping noch per RDP möglich. In der Verwion mit exklusiver Hardware läuft das.

    Fehlermeldung in der Clientanmeldung lautet:
    Fehler in Verbindung VPN:
    Mon Jul 27 10:44:13 2015 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=11]
    Mon Jul 27 10:44:13 2015 ERROR: Windows route add command failed [adaptive]: returned error code 1
    Mon Jul 27 10:44:13 2015 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=16]
    Mon Jul 27 10:44:13 2015 ERROR: Windows route add command failed [adaptive]: returned error code 1
    Mon Jul 27 10:44:13 2015 ROUTE: route addition failed using CreateIpForwardEntry: Zugriff verweigert [status=5 if_index=16]
    Mon Jul 27 10:44:13 2015 ERROR: Windows route add command failed [adaptive]: returned error code 1

    Kann jemand helfen?
    Nur ungerne möchten wir die Eleganz der Redundanz via VM aufgeben.

    Hallo,
    da es sich um eine VM handelt tippe ich mal zu erst auf den "promiscuous mode" das dieser vielleicht das Problem ist.
    Hier im Forum gibts dazu schon ein paar Lösungen, wobei der Hypervisor in dem Fall VMWare war.

    Gruß

    Mein Computer kann alles, wegen seiner 32 Bit!
    Wenn ich 32 Bit intus habe, kann ich auch alles!

    Danke für Eure Response.

    Wir haben zunächst auf unsere "alte" EFW umgestellt, dort läuft ja alles.

    Bezüglich Client: Ja, auch im Administratormodus Scheitern, ebenso bei Clienstart im XP-Kompatibilitätsmodus.

    Bezüglich "promiscuous mode":
    Hier im Forum gibt es ja diesbezügliche posts.
    Sollte jemand diesbezüglich konkret zur WIN-VM etwas wissen, würde und das freuen.
    Wir werden dieses Thema als nächstes anpacken. Dafür haben wir nur derzeit keine Zeit.

    Ich ergänze:
    In der Vergangenheit hatten wir unsere EFW mal auf einer ESX unter VM-Ware 5 erfolgreich etabliert. Die Maschine steht aber nicht mehr zur Verfügung. Der VM-Ware-Player bietet aus unserer Erfahrung heraus nicht die konkreten Möglichkeiten der Zuweisung der 4 (rot/grün/blau/orange) erforderlichen Netzwerkkarten. Gleiches meinen wir zur VirtualBox. Da hat sich der VirtuellePc am freundlichsten/eindeutigsten dargestellt . . .

    Bei Erfolg werden wir berichten.

    Noch mal: Danke

    • Offizieller Beitrag

    Hallo,
    was wird den genau als Hypervisor verwendet?
    VirtualPC, Hyper-V oder VMWare ?

    Würde da die VMWare Variante vorziehen.


    Hyper V geht das wohl bei dein Einstellungen Optionen
    <allow_promiscuous_mode type="boolean">FALSE</allow_promiscuous_mode>

    Fehlermeldung von oben sieht aber dennoch seltsam aus wenn da Zugriff verweigert kommt für die Route

    Edit: Ist ein ausschließen eines Problem mit dem OpenVPN von der Rücksicherung auszuschließen?
    Parallel vielleicht mal zum Testen ein System aufsetzen in der VM Ohne Rücksicherung und den OpenVPN Server grob einrichten.
    Würde gern vermeiden das vielleicht der OpenVPN Server mit der Rücksicherung ein Problem hat

    Edit2:
    Gibt das OpenVPN am Server was interessantes im Log aus ?

    noch einmal DANKE für die rasche Response . . .

    Aus Zeitgründen meinerseits heute nur 2 Informationen (wir haben ja akut kein Problem durch den Einsatz unserer Redundanz)
    a) Die VM basiert auf VirtualPC
    b) Protokollauswertung und den Ansatz mit "<allow_promiscuous_mode type="boolean">FALSE</allow_promiscuous_mode>" müssen wir auf einen späteren Zeitpunkt verschieben . . .

    BG
    Friedrich Paulsen