istike2
Goto Top

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.

Content-Key: 7658066761

Url: https://administrator.de/contentid/7658066761

Printed on: April 27, 2024 at 08:04 o'clock

Member: Spirit-of-Eli
Spirit-of-Eli Jun 26, 2023 at 20:15:29 (UTC)
Goto Top
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
Member: istike2
istike2 Jun 26, 2023 at 20:23:11 (UTC)
Goto Top
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.
Member: Spirit-of-Eli
Solution Spirit-of-Eli Jun 26, 2023 at 21:02:04 (UTC)
Goto Top
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.

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.
Member: istike2
istike2 Jun 26, 2023 at 21:08:50 (UTC)
Goto Top
Vielen Dank!
Member: Dani
Dani Jun 26, 2023 at 21:08:57 (UTC)
Goto Top
@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.

@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
Member: Spirit-of-Eli
Spirit-of-Eli Jun 26, 2023 updated at 21:36:55 (UTC)
Goto Top
Zitat von @Dani:

@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.
Member: Dani
Dani Jun 26, 2023 at 21:41:00 (UTC)
Goto Top
@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
Member: Spirit-of-Eli
Spirit-of-Eli Jun 26, 2023 at 21:49:16 (UTC)
Goto Top
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

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.