8
DirectAccess Verbindung wird durch 2. VPN Verbindung blockiert
Hallo,
wir haben zur zentralen RZ-Infrastruktur ein VPN-Tunnel auf DirectAccess-Basis.
Gleichzeitig benützen wir diverse Tunnels zu Kunden oder auf diverse Endsysteme.
Problem:
Wenn ein 2. Kanal aufgebaut wird, wird die DA-Verbindung blockiert.
In der Liste der Netzwerkadaptern steht dann bei DirectAccess
"Aktion erforderlich - Die Windows-Firewall muss eingeschaltet sein"
Hat jemand eine Idee, wie ich zwei gleichzeitige VPN-Verbindung ermögliche:
Z. B. ein DirectAcess und eine OpenVPN-Tunnel.
Vielen Dank für eure Meinungen.
Gr.
I.
wir haben zur zentralen RZ-Infrastruktur ein VPN-Tunnel auf DirectAccess-Basis.
Gleichzeitig benützen wir diverse Tunnels zu Kunden oder auf diverse Endsysteme.
Problem:
Wenn ein 2. Kanal aufgebaut wird, wird die DA-Verbindung blockiert.
In der Liste der Netzwerkadaptern steht dann bei DirectAccess
"Aktion erforderlich - Die Windows-Firewall muss eingeschaltet sein"
Hat jemand eine Idee, wie ich zwei gleichzeitige VPN-Verbindung ermögliche:
Z. B. ein DirectAcess und eine OpenVPN-Tunnel.
Vielen Dank für eure Meinungen.
Gr.
I.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7658066761
Url: https://administrator.de/contentid/7658066761
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
8 Kommentare
Neuester Kommentar
Moin,
DA sowie OVPN sollten ohne Probleme parallel laufen können. Es sei denn alles läuft über den selben Port.
Ansonsten ist es best pratice identische Tunnel über mehrere public IPs laufen zu lassen da die Ports sonst schon genutzt werden.
Gruß
Spirit
DA sowie OVPN sollten ohne Probleme parallel laufen können. Es sei denn alles läuft über den selben Port.
Ansonsten ist es best pratice identische Tunnel über mehrere public IPs laufen zu lassen da die Ports sonst schon genutzt werden.
Gruß
Spirit
Vielen Dank ...
So wie ich via NETSTAT prüfen kann, sind alle Verbindungen über 443 (HTTPS) aufgebaut ...
Für OpenVPN etwas komisch ... übereinstimmende Ports wären aber eine Erklärung fürs Problem.
So wie ich via NETSTAT prüfen kann, sind alle Verbindungen über 443 (HTTPS) aufgebaut ...
Für OpenVPN etwas komisch ... übereinstimmende Ports wären aber eine Erklärung fürs Problem.
Zitat von @istike2:
Vielen Dank ...
So wie ich via NETSTAT prüfen kann, sind alle Verbindungen über 443 (HTTPS) aufgebaut ...
Für OpenVPN etwas komisch ... übereinstimmende Ports wären aber eine Erklärung fürs Problem.
Vielen Dank ...
So wie ich via NETSTAT prüfen kann, sind alle Verbindungen über 443 (HTTPS) aufgebaut ...
Für OpenVPN etwas komisch ... übereinstimmende Ports wären aber eine Erklärung fürs Problem.
Ja, das kann definitiv nicht funktionieren. DA fällt auf die Nase weil die Verbindung versucht wird permanent zu halten. Wenn dann OVPN dazu kommt, wird die Session Bindung darauf geändert.
Daher unterschiedliche Ports für OVPN nutzen oder unterschiedliche public IPs.
Vielen Dank!
@Spirit-of-Eli
@istike2
Gruß,
Dani
oder unterschiedliche public IPs.
in weit löst dies das Problem mit dem Port? Bei CGNAT, welches die ISPs nutzen, ebenfalls nur eine Verbindung möglich sein.@istike2
Gleichzeitig benützen wir diverse Tunnels zu Kunden oder auf diverse Endsysteme.
erlauben das die Kunden explizit bzw. hast du das vorab geklärt? Weil oftmals solche Tunnels mit Verträgen abgesichert sind, welche sowas organisatorisch gar nicht erlauben. In Einzelfällen sogar kaufmännische Konsequenzen nach sich ziehen.wir haben zur zentralen RZ-Infrastruktur ein VPN-Tunnel auf DirectAccess-Basis.
Warum kein VPN S2S? Habe ich bis heute nicht verstanden, warum man sowas mit DA macht. Wobei DA auch noch ein Totes Pferd ist, dass in absehbarer Zeit ersetzt werden muss.Gruß,
Dani
Zitat von @Dani:
@Spirit-of-Eli
@Spirit-of-Eli
oder unterschiedliche public IPs.
in weit löst dies das Problem mit dem Port? Bei CGNAT, welches die ISPs nutzen, ebenfalls nur eine Verbindung möglich sein.Weil das Problem an seinem Gateway entsteht. Daher machen mehrere IPs Sinn um die Services zu verteilen. Unter einem Port kann schließlich, im normal Fall, nur ein Service laufen.
Und DA ist tatsächlich tot. State of the Art ist mittlerweile AlwaysOnVPN wenn du bei MS bleiben willst. Basiert im Endeffekt wieder auf IPsec.
@Spirit-of-Eli
Sehe ich nicht so. Der Source Port ist bei Verbindungsaufbau dynamisch und wird entsprechend der freien bzw. belegten Ports auf dem Client ausgewählt. Hingegen der Zielport ist fest definiert. Somit spielt doch das Gateway keine
Gruß,
Dani
Sehe ich nicht so. Der Source Port ist bei Verbindungsaufbau dynamisch und wird entsprechend der freien bzw. belegten Ports auf dem Client ausgewählt. Hingegen der Zielport ist fest definiert. Somit spielt doch das Gateway keine
Unter einem Port kann schließlich, im normal Fall, nur ein Service laufen.
In diesem Fall ist der Client aber Client und nicht Server. Sprich es wird von Endgerät X zwei VPN Verbindungen zu unterschiedlichen Zielen aufgebaut.Gruß,
Dani
Zitat von @Dani:
@Spirit-of-Eli
Sehe ich nicht so. Der Source Port ist bei Verbindungsaufbau dynamisch und wird entsprechend der freien bzw. belegten Ports auf dem Client ausgewählt. Hingegen der Zielport ist fest definiert. Somit spielt doch das Gateway keine
Gruß,
Dani
@Spirit-of-Eli
Sehe ich nicht so. Der Source Port ist bei Verbindungsaufbau dynamisch und wird entsprechend der freien bzw. belegten Ports auf dem Client ausgewählt. Hingegen der Zielport ist fest definiert. Somit spielt doch das Gateway keine
Unter einem Port kann schließlich, im normal Fall, nur ein Service laufen.
In diesem Fall ist der Client aber Client und nicht Server. Sprich es wird von Endgerät X zwei VPN Verbindungen zu unterschiedlichen Zielen aufgebaut.Gruß,
Dani
Okay, dann habe ich das falsch verstanden.
Für mich sah das so aus als wenn die Tunnel von den Kunden ebenfalls zum RZ hin aufgebaut werden.
Da gebe ich dir vollkommen Recht. Das Problem liegt hier Client seitig.
An der Stelle macht ein Jump Host mehr Sinn. Client Verbindungen zu den Kunden sind auch ein riesen Sicherheitsproblem.
