12
MS Always-ON VPN Client to Client connection
Hallo zusammen
wir evaluieren gerade die Always-ON VPN Technik von MS und stoßen dort auf eine Problem das ich so nicht nachvollziehen kann.
Der Tunnel ist als IKEv2 mit Zertifikat auf Gerätebasis eingerichtet. Das Split-Tunneling ist aktviert. Die Verbindung selbst funktioniert einwandfrei, ich kann mit verbundenen VPN Tunnel auf alle notwendigen Ressourcen zugreifen.
Wir haben aktuell ein "letztes" Problem: VoIP funktioniert in allen Richtungen wunderbar - außer von VPN-Client zu VPN-Client ôÔ, die intiale Verbindung wird aufgebaut aber danach ist Sense, es wird keine Sprache übertragen. Das VoIP nach dem eigentlichen Verbindungsaufgbau durch die TA eine Punkt zu Punkt Verbindung aufgbaut ist mir klar und ich schätze auch das dort das Problem liegt.
Schätzungsweise ist RRAS das Problem das aus irgendwelchen Gründen die Kommunkaiton der Clients unter sich im VPN Netzwerk unterbindet, aber ich finde keine Einstellung die das bewirkt, vielleicht hat hier jemand einen Rat wo ich noch suchen kann. Im Ereignisprotokoll tauchen keinerlei Fehler auf, weder am Client noch am Server.
Testumfeld: Server 2019, Stand 10-2020, Windows 10 Enterprise stand 1909 / 10-2020, VoIP: Cisco CallManager mit Jabber als SoftPhone.
Vielleicht hat ja jemand ein ähnliches Problem gehabt - oder bei gleicher Konstellation ist es gar nicht vorhanden (Neuinstallation wäre blod aber machbar).
Bei Fragen einfach melden
Grüße aus dem warmen (ja echt!) und windigen Münsterland
@clSchak
wir evaluieren gerade die Always-ON VPN Technik von MS und stoßen dort auf eine Problem das ich so nicht nachvollziehen kann.
Der Tunnel ist als IKEv2 mit Zertifikat auf Gerätebasis eingerichtet. Das Split-Tunneling ist aktviert. Die Verbindung selbst funktioniert einwandfrei, ich kann mit verbundenen VPN Tunnel auf alle notwendigen Ressourcen zugreifen.
Wir haben aktuell ein "letztes" Problem: VoIP funktioniert in allen Richtungen wunderbar - außer von VPN-Client zu VPN-Client ôÔ, die intiale Verbindung wird aufgebaut aber danach ist Sense, es wird keine Sprache übertragen. Das VoIP nach dem eigentlichen Verbindungsaufgbau durch die TA eine Punkt zu Punkt Verbindung aufgbaut ist mir klar und ich schätze auch das dort das Problem liegt.
Schätzungsweise ist RRAS das Problem das aus irgendwelchen Gründen die Kommunkaiton der Clients unter sich im VPN Netzwerk unterbindet, aber ich finde keine Einstellung die das bewirkt, vielleicht hat hier jemand einen Rat wo ich noch suchen kann. Im Ereignisprotokoll tauchen keinerlei Fehler auf, weder am Client noch am Server.
Testumfeld: Server 2019, Stand 10-2020, Windows 10 Enterprise stand 1909 / 10-2020, VoIP: Cisco CallManager mit Jabber als SoftPhone.
Vielleicht hat ja jemand ein ähnliches Problem gehabt - oder bei gleicher Konstellation ist es gar nicht vorhanden (Neuinstallation wäre blod aber machbar).
Bei Fragen einfach melden
Grüße aus dem warmen (ja echt!) und windigen Münsterland
@clSchak
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 618517
Url: https://administrator.de/contentid/618517
Printed on: April 19, 2024 at 07:04 o'clock
12 Comments
Latest comment
Moin,
baut dein Cisco CallManager die Verbindung nur auf oder mittelt der auch Sprache? Ansonsten könnte es schlicht sein, dass die Route von zu VPN und zu von VPN nicht supported wird.
Grüße,
Christian
certifiedit.net
baut dein Cisco CallManager die Verbindung nur auf oder mittelt der auch Sprache? Ansonsten könnte es schlicht sein, dass die Route von zu VPN und zu von VPN nicht supported wird.
Grüße,
Christian
certifiedit.net
Hi certifiedit.net
der Initiert nur und dann geht es weiter mit RTSP (bin jetzt mit dem Protokoll nicht sicher), es betrifft ja lediglich VPN-Client zu VPN-Client, alle anderen Wege funktionieren, selbst vom _alten_ Einwahl-VPN Richtung Always-On VPN funktioniert es anstandslos, nur innerhalb des AO VPN Netzes nicht.
der Initiert nur und dann geht es weiter mit RTSP (bin jetzt mit dem Protokoll nicht sicher), es betrifft ja lediglich VPN-Client zu VPN-Client, alle anderen Wege funktionieren, selbst vom _alten_ Einwahl-VPN Richtung Always-On VPN funktioniert es anstandslos, nur innerhalb des AO VPN Netzes nicht.
Dann schau mal auf die Rechte sich gegenseitig zu erreichen, wie beschrieben.
Moin @clSchak,
hast du evtl. einen Traffic Filter konfiguriert, die nun den Datenverkehr blockieren?
Gruß,
Dani
hast du evtl. einen Traffic Filter konfiguriert, die nun den Datenverkehr blockieren?
Gruß,
Dani
Nein, es sind keinerlei Filter aktiv, ich habe auch schon die FW komplett ausgeschaltet um das zu testen, scheinbar routet der den Traffic nicht zurück von Interface das im internen Netz hängt und dem virtuellen Interface für die VPN Clients. Ich habe es bereits mit unterschiedlich Einstellungen am RRAS Server (NAT, RIP Router, usw.) getestet aber immer das gleiche.
Das "lustige" ist, mit DirectAccess funktioniert alles, da gibt es keinerlei Probleme (bis auf eine Anwendung die mit dem IPv6 nicht zurecht kommt), würde das ja am liebsten weiter verwenden, aber das ist ja mehr oder wenig abgekündigt seitens MS :| darum der test mit alwayson VPN.
Das "lustige" ist, mit DirectAccess funktioniert alles, da gibt es keinerlei Probleme (bis auf eine Anwendung die mit dem IPv6 nicht zurecht kommt), würde das ja am liebsten weiter verwenden, aber das ist ja mehr oder wenig abgekündigt seitens MS :| darum der test mit alwayson VPN.
Naja, dann weisst du ja, was es ist - Rückroute...Vielleicht denkt er, er muss für den Zugriff nicht über das GW...
ja, die sind ja alle eingetragen aber der RRAS Server verwirft da was, aber ich weis nicht was. Die Routen sind alle korrekt eingetragen. Es läuft ja auch alles bis auf VoIP von VPN zu VPN.
Wir haben ja parallel DirectAcces und für ältere und nicht Windows Enterprise Clients IPSec Tunnel, da läuft ja alles. Somit kann auch den VoIP Client als Problem ausschließen.
Wir haben ja parallel DirectAcces und für ältere und nicht Windows Enterprise Clients IPSec Tunnel, da läuft ja alles. Somit kann auch den VoIP Client als Problem ausschließen.
wir haben das mal weiter eruiert ... es funktioniert nun alles - aber ich weis nicht warum. Die Config haben wir nicht angepasst, ich tippe mittlerweile das irgendwo ein Update fehlte oder zu viel war. Seit der letzten Woche funktioniert alles wie es soll .
Danke für die Hinweise
.Danke für die Hinweise
Guten Abend @clSchak
kannst du noch nachvollziehen, ob Updates installiert werden? Und falls dem so ist, die KB Nummern posten.
Wir haben im Frühjahr ebenfalls ein Wechsel vor und würden den Kollegen eine Lektüre geben.
Gruß,
Dani
kannst du noch nachvollziehen, ob Updates installiert werden? Und falls dem so ist, die KB Nummern posten.
Wir haben im Frühjahr ebenfalls ein Wechsel vor und würden den Kollegen eine Lektüre geben.
Gruß,
Dani
Sorry, irgendwie kam die Mail mit der Info das eine Antwort geschrieben wurde erst heute morgen 
Das müsste die November Kumulativ Updates sein
- https://support.microsoft.com/de-de/help/4594440
- https://support.microsoft.com/de-de/help/4586786
Zusätzlich noch ein kleiner Tipp, wenn Ihr das nicht bereits plant:
RegKey setzen damit der Verbindungsstatus in dem Fenster bei den WLANs auftaucht, so wie bei DirectAccess, wenn Ihr Device Tunnel verwendet taucht der da nicht von alleine auf:
Erspart eine Menge Tickets ...
Das müsste die November Kumulativ Updates sein
- https://support.microsoft.com/de-de/help/4594440
- https://support.microsoft.com/de-de/help/4586786
Zusätzlich noch ein kleiner Tipp, wenn Ihr das nicht bereits plant:
RegKey setzen damit der Verbindungsstatus in dem Fenster bei den WLANs auftaucht, so wie bei DirectAccess, wenn Ihr Device Tunnel verwendet taucht der da nicht von alleine auf:
New-Item -Path 'HKLM:\SOFTWARE\Microsoft\Flyout\VPN' -Force
New-ItemProperty -Path 'HKLM:\Software\Microsoft\Flyout\VPN\' -Name 'ShowDeviceTunnelInUI' -PropertyType DWORD -Value 1 -Force Erspart eine Menge Tickets ...
Weitere Ergänzung zu dem Thema, da wir gerade das Problem hatten:
Wenn das interne CA Zertifikat erneuert wird, verwendet das Always-ON nicht direkt das Root-Zertifikat und man kann nur ein Root-Zertifikat zur Authentifizierung definieren, entweder sperrt man alle neuen oder alle alten Zertifikate damit aus, je nachdem wie schnell die Clients sich ein neues Zertifikat besorgen, kann das zu Problemen führen (Fehler -> "ike authentication credentials are unacceptable")
Root-CA Zertifikat setzen (das Zertifikat darf nur 1x in dem Ordner vorhanden sein, ansonsten funktioniert der Befehl nicht)
Zu dem gibt es Probleme, wenn mehr wie ein (eigenes) Zertifikat mit Serverauthentifizierung vorhanden ist auf dem RAS Server, der Dienst nimmt sich irgendeines aus dem Verzeichnis mit der Erweiterten Eigenschaft "Serverauthentifizierung", prüft aber nicht ob das Zertifikat auch IKEv2 und den passenden SN hat. (führt am Client zum Fehler 13801, wenn das falsche Zertifikat gezogen wurde).
Wenn das interne CA Zertifikat erneuert wird, verwendet das Always-ON nicht direkt das Root-Zertifikat und man kann nur ein Root-Zertifikat zur Authentifizierung definieren, entweder sperrt man alle neuen oder alle alten Zertifikate damit aus, je nachdem wie schnell die Clients sich ein neues Zertifikat besorgen, kann das zu Problemen führen (Fehler -> "ike authentication credentials are unacceptable")
Root-CA Zertifikat setzen (das Zertifikat darf nur 1x in dem Ordner vorhanden sein, ansonsten funktioniert der Befehl nicht)
$Thumbprint = 'Root CA Certificate Thumbprint'
$RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})
Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru
Restart-Service RemoteAccess -PassThruZu dem gibt es Probleme, wenn mehr wie ein (eigenes) Zertifikat mit Serverauthentifizierung vorhanden ist auf dem RAS Server, der Dienst nimmt sich irgendeines aus dem Verzeichnis mit der Erweiterten Eigenschaft "Serverauthentifizierung", prüft aber nicht ob das Zertifikat auch IKEv2 und den passenden SN hat. (führt am Client zum Fehler 13801, wenn das falsche Zertifikat gezogen wurde).
