05.12.2020

4242

Windows Server 2019 als VPN Server Problem

Hallo,

ich versuche gerade eine VPN Verbindung zu einem Windows Server 2019 herzustellen.
Beim Start der RAS-Verbindungsverwaltung tritt folgender Fehler auf :

Fehler beim Starten der RAS-Verbindungsverwaltung, da das Protokoll-Engine [GRE] nicht initialisiert wurde. The operation identifier is not valid.

dementsprechend bekomme ich von außen keine Verbindung.

Kann mir hier jemand helfen ? ich finde dazu im Netzt nichts.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 628739

Url: https://administrator.de/forum/windows-server-2019-als-vpn-server-problem-628739.html

Ausgedruckt am: 05.02.2025 um 21:02 Uhr

40 Kommentare

Neuester Kommentar

Hättest du noch die Güte uns ggf. mitzuteilen welches der zahllosen VPN Protokolle du denn nutzt oder nutzen willst ?!
GRE besagt ja nichts Gutes, denn das ist Teil des PPTP VPN Protokolls was weithin aus gutem Grund schon lange nicht mehr genutzt wird:
https://www.heise.de/security/artikel/Der-Todesstoss-fuer-PPTP-1701365.h ...

Ja, natürlich.

Die Verbindung soll über L2TP/IKEv2 laufen, ohne Zertifikat.
Der Zugriff soll von Windows Clients und im 2. Schritt von Lancom Routern aus erfolgen.

Was denn nun L2TP oder IPsec native mit IKEv2 ? L2TP nutzt im Backend normal immer IKEv1.
Grundlagen dazu u.a. auch hier:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer

Zitat von @tmevent:

Ja, natürlich.

Die Verbindung soll über L2TP/IKEv2 laufen, ohne Zertifikat.
Der Zugriff soll von Windows Clients [...] aus erfolgen.

Vergiss Windows-Server als VPN-Server.
Wenn Du sowieso schon Lancom-Router im Einsatz hast wickel das VPN darüber ab.

und im 2. Schritt von Lancom Routern

Für Site2Site Verbindungen nicht auf L2TP setzen.

Gruß

Alex

Es geht nicht um Lokale Geräte. Ich muss einen gehosteten Server einbinden.

Was ist da besser als L2TP und mit windows Server - Boardmitteln realisierbar ?

idealerweise IKEv2, L2TP ist dabei der Erste schritt mal eine Verbindung aufzubauen, das lief eben auch schon.

Dann belasse es bei L2TP. Never touch a running System.

Alternative wäre eben noch IPsec weil du bei IKEv2 immer ein Server Zertifikat hast was den Server verifiziert. Das hast du bei L2TP nicht. Native IPsec ist also in der Beziehung etwas sicherer das dir keiner einen Fake VPN Server unterschieben kann.
Grundlagen dazu auch hier:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Das System wird ja eh neu aufgesetzt. Bei L2TP kann ich ja leider kein oder nur eingeschränktes Split-Tunneling nutzen.
Wobei das mit dem Lancom VPN Client machbar sein müsste, dann nutze ich den wohl besser weiter und nicht die Windows Boardmittel am Client.

Bei L2TP kann ich ja leider kein oder nur eingeschränktes Split-Tunneling nutzen.

Wieso leider ? Es liegt doch rein nur an dir und deinen Anforderungen bzw. deiner Konfig ob die Split Tunneling oder Gateway Redirect machst ! Das hat doch mit dem VPN Protokoll nichts zu tun.

und nicht die Windows Boardmittel am Client.

Wäre eigentlich recht sinnfrei ! Warum sollte es von Vorteil sein einen fremden L2TP Client zu nutzen wenn man im Betriebssystem einen hat der bestens integriert ist. Diese Logik müsstest du in einem Administratorforum schon mal erklären...

Ich hätte hinter den Satz wohl besser ein Fragezeichen gesetzt.
Bisher habe ich noch nicht rausgefunden wie ich mit L2TP ein Splitt Tunneling umsetze und bin bei meiner Suche nach Hilfe zur Konfiguration Von Windows eigenen VPN Servern und Clients über die Aussage mehrfach gestolpert es würde nicht gehen. Genauer habe ich mich damit aber bisher noch nicht auseinander gesetzt.
Das mache ich jetzt und freue mich dazu über jede Hilfe.

Grundlegendes Zur Netzwerkumgebung :
10.0.0.0/24 ist ein Lokales Netz
10.2.0.0/24 ist ebenfalls ein Lokales Netz

Diese Beiden Netze sind mit VPN verbunden.

10.3.0.0/24 ist das Netz welches ich nun zusätzlich am einbinden bin.

Im Ersten Schritt über den Windows VPN Client nur an einzelnen Rechnern, da diese nicht immer in den Beiden Lokalen Netzen sind. Wenn dieser Client dann später auch auf die beiden Lokalen Netze zugreifen könnte wäre super, ist aber nicht unbedingt ein Muss.

Im zweiten Schritt möchte ich die beiden Lokalen Netze mit neuen Netz verbinden, aber eins nach dem Anderen.

Aktuell meine Baustellen :

Aktuell meine Baustellen :

Fehlte da noch was ???
OK, du hast dann 2 Optionen:

Bei Split Tunneling kannst du als Netzwerk an dem Client mitgeben 10.0.0.0/8 dann wir generell alles was 10er Netze betrifft in den Tunnel geroutet.
Oder einen Redirect als Schrotschuss was dann sämtlichen Traffic redirected.

Beides führt zum Erfolg.

Zitat von @aqui:

Aktuell meine Baustellen :

Das war zuviel, sorry.

Ich setze mich gerade mit beiden Varianten auseinander und schaue wie es sich jeweils unter Windows konfigurieren lässt.

offensichtlich ist das so eine Sackgasse ....
Ich finde aktuell keine Möglichkeit den Lancom per VPN mit dem Windows Server zu verbinden (über L2TP)
Ich müsste über IKEv2 gehen aber dann bin ich an einen Zertifizierungdienst gebunden und das Thema ist komplettes Neuland für mich zumal ich keine AD habe(n will).
Evtl. hat da ja auch noch jemand einen Tipp

Ich müsste über IKEv2 gehen aber dann bin ich an einen Zertifizierungdienst gebunden

Sorry aber das ist doch Quatsch. Du kannst doch auch ein selbst signiertes Zertifikat nehmen. Zusätzlich kann man bei IKEv2 auch die Zertifikatsprüfung deaktivieren.
Und wenn alle Stricke reissen was bitte hintert dich denn daran IKEv1 zu nehmen ??
IKEv1 ist ebenso sicher und mit dem kostenfreien Shrew_Client rennt es auf der Winblows Maschine fehlerlos und im Handumdrehen zum Lancom.
Wo ist also dein wirkliches Problem ?!

Wie gesagt, mit der Anwendung von Zertifikaten kenn ich mich null aus. Bei dem was ich mache ist das normalerweise nicht notwendig.

IKEv1 habe ich am laufen.

Als Client bzw. 2. Gegenstelle will ich den Lancom 1781VAW einsetzen. Dieser Soll sich mit dem Windows VPN Server verbinden.
Bei der Suche nach der Konfiguration vom Lancom habe ich mehrfach die Aussage gefunden das dieser sich nicht mit einem Windows VPN Server verbinden kann. Was mich wundert. Mehr an Informationen konnte ich dazu aber bisher nicht finden.

Aktuelle Windows Versionen erzwingen IKEv2 mit dem onboard Client was der Lancom dann vermutlich nicht kann.
Deshalb ja auch die Empfehlung hier Shrew mit v1 zu nehmen. Shrew ist ein IKEv1 Client. Das klappt wasserdicht.

Dann muss ich den umgekehrten Weg gehen und den Lancom als VPN Server für die Netzwerke nutzen, was ich eigentlich nicht wollte, da sich mobile Clients auch am Windows Server anmelden (mit Boardmitteln) Wärs mir lieber die Netzwerke melden sich ebenfalls am Server an und nicht der Server am Netzwerk ... aber wenn's nicht anders geht gehe ich den umgekehrten Weg.

Dann muss ich den umgekehrten Weg gehen und den Lancom als VPN Server für die Netzwerke nutzen

Aber so hast du das doch oben auch geschrieben ?? Verwirrung komplett...

Wenn du den Winblows Server als IPsec VPN Server nehmen willst brauchst du das natürlich nicht. Der würde ja einen IKEv2 Server aktivieren, den man dann auch wieder mit den bordeigenen IKEv2 Clients bedienen kann.
https://docs.microsoft.com/de-de/windows-server/remote/remote-access/vpn ...
Irgendwie drehen wir uns grad im Kreis....

Als VPN Server soll ein Windows Server 2019 fungieren

Als Clients sollen zum einen Lancom Router zum Einsatz kommen, aber auch Endgeräte

Sorry wenn ich das unklar ausgedrückt habe

Da ich mit Zertifikaten noch nicht viel zu tun hatte versuche ich nun rauszufinden welche Zertifikate ich benötige, eine eigene CA möchte ich nicht unbedingt aufsetzen

Zitat von @tmevent:

Als VPN Server soll ein Windows Server 2019 fungieren

Wie schon weiter oben geschrieben ist das Blödsinn. Mag zwar funktionieren, aber ein Windows Server ist sicher nicht als ein robuster VPN-Router ausgelegt. Und schon zweimal nicht, wenn da noch etwas anderes drauf läuft (gehe ich mal von aus). Der richtige Horror fängt dann bei den Windows Updates an.

Einen gescheiten Router/Firewall als VPN-Router einsetzen statt den Windows Server.

Als Clients sollen zum einen Lancom Router zum Einsatz kommen, aber auch Endgeräte

Na warum dann nicht auch einen Lancom Router dort benutzen, wo Du den Windows Server einsetzen willst?

Gruß
Alex

Zitat von @Ad39min:
Einen gescheiten Router/Firewall als VPN-Router einsetzen statt den Windows Server.

Ist leider nicht möglich, der Windows Server ist im WEB gehostet. Ich kann dort keinen 2. Server aufsetzen, keine VM installieren und den Lancom auch nicht dazu stellen.

Zitat von @tmevent:

Zitat von @Ad39min:
Einen gescheiten Router/Firewall als VPN-Router einsetzen statt den Windows Server.

Ist leider nicht möglich, der Windows Server ist im WEB gehostet. Ich kann dort keinen 2. Server aufsetzen, keine VM installieren und den Lancom auch nicht dazu stellen.

Bietet der Webhoster keinerlei Site 2 Site Tunneling an?
Wenn nicht, würde ich es wirklich lieber so machen dass der Windows Server VPN Client zum Lancom ist und der Lancom der VPN-Host-Router.

dann muss ich mit den Endgeräten den Umweg über den Router gehen und niedrigere Bandbreite in Kauf nehmen, auch unschön.

Nachdem das wohl eine Sackgasse war, habe ich mich entschieden eine pfSense FW vor den Windows 10 Rechner zu setzen, sicher im ganzen die schönere Lösung.

Nun habe ich sobald ich mich von einem Client aus verbinde folgendes Problem :
In der lokalen Routing Tabelle des Clients erscheint der Eintag 10.0.0.0 255.0.0.0 mit der Schnittstelle 10.3.1.1, die IP meines Clients
Da ich im lokalen Netz (10.2.0.0/24) aber noch ein weiteres netz (10.0.0.0/24) erreichen muss, was dort über das Gateway normalerweise auch läuft, leitet der Eintrag in der Routing Tabelle die Pakete komplett falsch ins externe 10.3.0.0/24 nett (wobei er das ja mit /8 komplett aufmacht)

wie kann ich pfsense dazu veranlassen diesen Eintrag nicht in die Routing Tabelle zu schreiben ?
das Ganze manuell am Client zu fixen wäre ja mehr als umständlich.

Danke für Hilfe und einen guten Rutsch

Dürfen wir noch erfahren welches der zahllosen VPN Protokolle du denn nun auf der pfSense nutzt für den Client Access ?? IPsec, L2TP oder OpenVPN ?
In allen diesen Protokollen wird das Client Netz im Setup festgelegt, deshalb solltest du dort natürlich auch auf einen 24 Bit Prefix achten wenn du für die VPN Clients ebenso ein 10er Netz genommen hast.

Klar.

Das Protokoll ist IPsec, .

Einwahl über den Windows 10 Clienten, also als Mobiler Client, da kann ich nur das Local Network definieren, nicht aber das remote Netzwerk, welches ja auch nicht geroutet wird.
Local Network ist wie folgt ausgefüllt :
Type: Network, Adress: 10.3.0.0/24

Bei einer site2site Verbindung habe ich auch gerade das Problem mit der route aber eins nach dem anderen *g*

Das Protokoll ist IPsec, .

Du hast alles Schritt für Schritt aus dieser Anleitung umgesetzt ??
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Ganz besonders was den IP Adress Pool der VPN Clients anbetrifft das der bei dir ein separates IP Netz ist was es in deinem Restnetz nicht noch einmal gibt und das dort ein 24 Bit Prefix verwendet wird wenn es eine 10er IP ist ?!

Hält man sich an die Anleitung und auch an das Client Adresskonzept funktioniert es fehlerfrei !

ja auch dieses netz ist eingerichtet
10.3.1.0/24

ich bin die Anleitung noch mal durchgegangen eh ich hier geschrieben habe

Mmmhh...kannst du mal diesen dubiosen Auszug aus der Routing Tabelle posten ? Idealerweise mit den anderen lokalen Interfaces.

anbei :

Tabelle im Normalzustand:

Schnittstellenliste
43...02 00 a5 92 e4 c0 ......NCP Secure Client Virtual NDIS6.20 Adapter
12...54 ee 75 9d f3 43 ......Hyper-V Virtual Ethernet Adapter #2
44...e4 b3 18 4c 5c 92 ......Bluetooth Device (Personal Area Network)
1...........................Software Loopback Interface 1
19...8c 89 98 47 58 40 ......Generic Mobile Broadband Adapter
73...00 15 5d 7f 16 77 ......Hyper-V Virtual Ethernet Adapter

IPv4-Routentabelle

Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 10.2.0.1 10.2.0.100 25
10.2.0.0 255.255.255.0 Auf Verbindung 10.2.0.100 281
10.2.0.100 255.255.255.255 Auf Verbindung 10.2.0.100 281
10.2.0.255 255.255.255.255 Auf Verbindung 10.2.0.100 281
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
172.30.224.0 255.255.240.0 Auf Verbindung 172.30.224.1 5256
172.30.224.1 255.255.255.255 Auf Verbindung 172.30.224.1 5256
172.30.239.255 255.255.255.255 Auf Verbindung 172.30.224.1 5256
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 10.2.0.100 281
224.0.0.0 240.0.0.0 Auf Verbindung 172.30.224.1 5256
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 10.2.0.100 281
255.255.255.255 255.255.255.255 Auf Verbindung 172.30.224.1 5256

Ständige Routen:
Keine

IPv6-Routentabelle

Aktive Routen:
If Metrik Netzwerkziel Gateway
1 331 ::1/128 Auf Verbindung
12 281 fe80::/64 Auf Verbindung
73 5256 fe80::/64 Auf Verbindung
73 5256 fe80::904f:1b5:4c78:b0cb/128
Auf Verbindung
12 281 fe80::a10b:d75a:7f10:55a9/128
Auf Verbindung
1 331 ff00::/8 Auf Verbindung
12 281 ff00::/8 Auf Verbindung
73 5256 ff00::/8 Auf Verbindung

Ständige Routen:
Keine

Tabelle bei bestehender VPN Verbindung ins Netz 10.3.0.0/24:

Schnittstellenliste
43...02 00 a5 92 e4 c0 ......NCP Secure Client Virtual NDIS6.20 Adapter
12...54 ee 75 9d f3 43 ......Hyper-V Virtual Ethernet Adapter #2
79...........................AZURE
44...e4 b3 18 4c 5c 92 ......Bluetooth Device (Personal Area Network)
1...........................Software Loopback Interface 1
19...8c 89 98 47 58 40 ......Generic Mobile Broadband Adapter
73...00 15 5d 7f 16 77 ......Hyper-V Virtual Ethernet Adapter

IPv4-Routentabelle

Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 10.2.0.1 10.2.0.100 25
10.0.0.0 255.0.0.0 Auf Verbindung 10.3.1.1 26
10.2.0.0 255.255.255.0 Auf Verbindung 10.2.0.100 281
10.2.0.100 255.255.255.255 Auf Verbindung 10.2.0.100 281
10.2.0.255 255.255.255.255 Auf Verbindung 10.2.0.100 281
10.3.0.0 255.255.255.0 Auf Verbindung 10.3.1.1 26
10.3.0.255 255.255.255.255 Auf Verbindung 10.3.1.1 281
10.3.1.1 255.255.255.255 Auf Verbindung 10.3.1.1 281
10.255.255.255 255.255.255.255 Auf Verbindung 10.3.1.1 281
20.52.136.192 255.255.255.255 10.2.0.1 10.2.0.100 26
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
172.30.224.0 255.255.240.0 Auf Verbindung 172.30.224.1 5256
172.30.224.1 255.255.255.255 Auf Verbindung 172.30.224.1 5256
172.30.239.255 255.255.255.255 Auf Verbindung 172.30.224.1 5256
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 10.2.0.100 281
224.0.0.0 240.0.0.0 Auf Verbindung 172.30.224.1 5256
224.0.0.0 240.0.0.0 Auf Verbindung 10.3.1.1 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 10.2.0.100 281
255.255.255.255 255.255.255.255 Auf Verbindung 172.30.224.1 5256
255.255.255.255 255.255.255.255 Auf Verbindung 10.3.1.1 281

Ständige Routen:
Keine

IPv6-Routentabelle

Ständige Routen:
Keine

Da geht in der Tat etwas schief !
Die vom VPN Server übermittelte Route ist falsch, da sie das gesamte 10er Netz in den Tunnel routet. Irgend etwas ist da im VPN Setup oder dem VPN Client falsch konfiguriert.
Vermutung ist das du den Client Parameter:
Add-VpnConnectionRoute -ConnectionName "pfSense" -DestinationPrefix 10.0.0.0/8 -PassThru
so mit dem 8er Prefix falsch eingegeben hast und damit die dynamisch übermittelte Route vom VPN Server ausgehebelt hast ?!
Kann das sein ?
https://docs.microsoft.com/en-us/powershell/module/vpnclient/add-vpnconn ...
Ggf. den Client nochmal komplett löschen und ohne oder mit korrigierter VPN Route eingeben.

ich hab die Verbindung noch mal neu angelegt aber keine Besserung

PS C:\WINDOWS\system32> Add-VpnConnectionRoute -ConnectionName "pfSense excl" -DestinationPrefix 10.3.0.0/24 -PassThru

DestinationPrefix : 10.3.0.0/24
InterfaceIndex :
InterfaceAlias : pfSense excl
AddressFamily : IPv4
NextHop : 0.0.0.0
Publish : 0
RouteMetric : 1
PolicyStore :

ich wüsste auch nicht wo ich im Server einen falsche Prefix angegeben haben könnte

Nee, das ist falsch mit -DestinationPrefix 10.3.0.0/24 - wenn das 10.3.0.0er Netz dein VPN Client Netz ist. Diese Route wäre dann Unsinn. Der -DestinationPrefix gibt immer das Zielnetz an was in den Tunnel geroutet wird.
Oder hab ich das jetzt missverstanden mit dem Client IP Netz ?
Wenn ja und es das nicht war, dann kommt diese falsche VPN Route dynmaisch über den Server. Dann ist irgendwas in der pfSense noch falsch konfiguriert.
Vielleicht solltest du dann den Haken Provide a List of accessible networks to clients testweise einmal weglassen und checken was dann in der Routing Tabelle steht.

Das 10.3.0.0 ist das entfernte Netz. Clients bekommen eine IP im 10.3.1.0 zugewiesen.
Auch der Haken Provide a List of accessible networks to clients ändert nichts an der Situation

Hast du die Route ggf. mal mit dem "all User" Parameter versucht ?
Add-VpnConnectionRoute -ConnectionName "pfSense" -DestinationPrefix 192.168.1.0/24 -AllUserConnection -PassThru

leider auch erfolglos

ich habe es auch auf anderen Geräten getestet, das ist mir ein Rätzel

gleichzeitig habe ich das Problem das ich bei site2site Verbindungen von Lancom Routern zur pfSense zwar Geräte aus dem Netz der pfSense erreiche, aber nicht umgekehrt (10.0.0.0/24 -> 10.3.0.0/24 geht, umgekehrt aber nicht)

Verstehe ich im Moment auch nicht. Hier haben die Routen exakt die Masken für die sie konfiguriert sind.

Geräte aus dem Netz der pfSense erreiche, aber nicht umgekehrt

Sind das ggf. Windows Maschinen ? Wenn ja hast du da das Firewall Setup beachtet.

Verstehe ich im Moment auch nicht. Hier haben die Routen exakt die Masken für die sie konfiguriert sind.

Echt merkwürdig. Ich werde erst mal damit leben können / müssen.

Sind das ggf. Windows Maschinen ? Wenn ja hast du da das Firewall Setup beachtet.

Die Firewalls sind weitgehend aus im internen netz (zu Testzwecken) ich schau mir das aber noch einmal an.
Ein Problem war sicher das der Client im virtuellen AZURE Netz als Gateway ja ein ganz anderes Gateway als meine Firewall vom DHCP vorgegeben bekommt. Aber das scheint nicht alles zu sein. Das schau ich mir noch genauer an.

Echt merkwürdig. Ich werde erst mal damit leben können / müssen.

Lies dir das nochmal genau durch:
https://forum.netgate.com/topic/113227/ikev2-vpn-for-windows-10-and-osx- ...
(Zitat: )
The network range you put here must be completely off the LAN network that’s on your firewall. This includes, for example, if you have taken an entire /16, EG 10.1.0.0/16 as your LAN. Putting a pool of 10.1.2.0/24 here will not work, since the /16 covers everything that starts with 10.1.* If that’s how your network is set up, then do something completely different here, such as 172.16.1.0/24.

Dein interner Client VPN Pool darf NICHT im 10er Netz sofern sich die masken irgendwo überschneiden.
Die Lösung dein Client Netz statt eines 10er Subnetzes einmal auf ein 172er mit einem /24er Prefix umstellen um der Problematik aus dem Weg zu gehen ist also ggf. der richtige Weg.

Falls alle Stricke reissen bleibt dir ja bei der pfSense ja immer noch die Alternative L2TP wenn du mit dem bordeigenen VPN Clients für alle Betriebssysteme arbeiten willst !
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer