winmadness 79 Geschrieben 2. April 2023 Melden Teilen Geschrieben 2. April 2023 (bearbeitet) Folgende Konfiguration: Windows Server 2016 mit allen Patches – eine VM als DC und eine VM mit Exchange Server 2016 mit allen Patches Client Windows 10 mit allen Patches MS Office 2016 mit allen Patches VPN Verbindung über OpenVPN mit SSL (als UTM einmal WatchGuard VM) Anmeldung an der UTM über einen VPN Benutzer da WatchGuard für VPN Verbindungen kein IPv6 unterstützt, muss IPv4 verwendet werden In der Registry gemäß MS Empfehlung den Parameter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents auf Hex-Wert 20 für "Prefer IPv4 over IPv6" gesetzt Es tritt nun einem Laptop das Problem auf, dass z.B. ping auf einen Intranet-Server (z.B. exchange.intern.de) mit einer IPv6 Adresse versucht wird, der natürlich fehl schlägt. Ein "ping -4 exchange.intern.de" funktioniert. Auch Outlook versucht zuerst eine Verbindung über IPv6 aufzubauen - dies verzögert den Verbindungsaufbau beim Start merklich. Auch das Öffnen von z.B. freigegebenen Kalendern dauert sehr lange, da zuerst auf den Timeout der IPv6 Verbindung gewartet wird. Als Bypass habe ich in der Registry über den Hex-Wert 0xFF das IPv6 Protokoll deaktiviet. Jetzt funktionert der ping und Outlook ohne Probleme. Das Problem tritt nur auf einem Laptop auf, alle anderen Computer mit der gleichen Konfiguration laufen ohne Probleme. bearbeitet 2. April 2023 von winmadness falschen Hex-Wert korrigiert Zitieren Link zu diesem Kommentar
Beste Lösung winmadness 79 Geschrieben 2. April 2023 Autor Beste Lösung Melden Teilen Geschrieben 2. April 2023 Lösung gefunden! Die Lösung liegt in folgender Einstellung im OpenVPN Client: • Über das Menü „Settings“ aufrufen • „Advanced Settings“ einblenden • Die Option „IP4-Only Tunnel“ im Bereich „IPv6“ aktivieren Seltsam dass die anderen Clients ohne diese Einstellung funktionieren. 1 Zitieren Link zu diesem Kommentar
Weingeist 159 Geschrieben 18. April 2023 Melden Teilen Geschrieben 18. April 2023 (bearbeitet) Ist halt die Frage ob man die Tunnel wirklich zulassen möchte oder ob man nicht besser auf Sie verzichtet. Sicherheitstechnisch ist die Technik zumindest etwas fragwürdig (EDIT: Zumindest war sie es, ob das heute noch gilt, weiss ich ehrlich gesagt nicht). Schiessen ja eigentlich ein Loch durch die Firewall. Klar bei Standardkonfig spielt das nicht so eine Rolle, gehört man aber zu jenen die tatsächlich die Firewall anpassen und sonstige Massnahmen technisch, wird es undurchsichtig mit den Tunnels. Wie viel das tatsächlich ausmacht, kann ich nicht so gut beurteilen, aber hilfreich ist es kaum. Am Ende muss man Firewall-seitig aber drei Techniken im Auge haben statt eine oder zwei. Hat man Probleme wie Dein geschildertes Verhalten mit den Verzögerungen und ist diese App auf dem Laptop Standard, müsste man korrekterweise Windows zwingen, erst IPv4 zu verwenden und IPv6 nur, wenn IPv4 nicht vorhanden ist. Also das Standardverhalten umdrehen. Das ereicht man indem man die Priorität in der Prefix-Policy von IPv4 gegenüber IPv6 erhöht. Insbesondere vom Loopback. Ich persönlich fände das sauberer als IPv4 einfach durch den IPv6 Tunnel zu schicken. IPv6 wird dadurch nicht verhindert, sondern es wird einfach erst IPv4 versurcht. Dazu müsste man die Prefixpolicy anpassen. Möchte man die Tunnels loswerden und nur IPv4 und/oder IPv6 nativ zu verwenden, ist meine Erfahrung, dass es in heterogen Umgebungen schmerzfreier ist, IPv4 die höhere Priorität einzuräumen. Entweder mit deaktiviertem IPv6 oder eben aktiviert. Dazu muss man die Prefixpolicy anpassen. bearbeitet 18. April 2023 von Weingeist Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.