Always-on-VPN mit einer Netzwerkkarte
Hallo zusammen,
ich bin tatsächlich einmal auf eure Hilfe angewiesen!
Ich habe für unser Unternehmen ein Domänennetzwerk auf einem Rootserver von Netcup erstellt und weitestgehend konfiguriert, hinsichtlich GPOs, Rechte etc. pp.
Aktuell läuft die Domänenverbindung über eine, durch den Benutzer initiierten, VPN-Verbindung.
Ich möchte allerdings gern einen Device-Tunnel haben und den Nutzern den zusätzlichen Schritt ersparen, bei der Anmeldung auf den Netzwerkanmeldungs-Button zu klicken.
Ich habe versucht einen Always-on-VPN mithilfe der Microsoft-Docs und einfaches-netzwerk.at zu konfigurieren, wobei ich allerdings auf diverse Probleme stoße. (Alles auf einem Server -> Cert, NPS, RRAS, AD)
Es wird überall gesagt, ich brauche eine zweite physikalische Netzwerkkarte. Diese lässt sich allerdings nur durch Netcup für 35,-€ pro Monat bereitstellen, was ist für absolut frech halte.
Jetzt zu meinen Fragen.
1: Kann ich den zweiten Netzwerkadapter für das interne Routen nicht mithilfe des Loopback-Adapter darstellen?
2: Ist es wirklich unmöglich, den NPS zusammen mit dem RRAS laufen zu lassen? -> oft gelesen, bei Fehlersuche
Zusätzliche Informationen:
OS: Windows Server 2019 Standard
CPU: AMD EPYC™ 7702 (4 Kerne, nicht shared)
RAM: 16 GB
Wenn ich was vergessen haben sollte, Schande auf mein Haupt.
Liebe Grüße
Simon
UND JA: Ich bin mir der Risiken bewusst, den DC extern zu hosten. Daher wird eine S2S-VPN verbindung genutzt!
ich bin tatsächlich einmal auf eure Hilfe angewiesen!
Ich habe für unser Unternehmen ein Domänennetzwerk auf einem Rootserver von Netcup erstellt und weitestgehend konfiguriert, hinsichtlich GPOs, Rechte etc. pp.
Aktuell läuft die Domänenverbindung über eine, durch den Benutzer initiierten, VPN-Verbindung.
Ich möchte allerdings gern einen Device-Tunnel haben und den Nutzern den zusätzlichen Schritt ersparen, bei der Anmeldung auf den Netzwerkanmeldungs-Button zu klicken.
Ich habe versucht einen Always-on-VPN mithilfe der Microsoft-Docs und einfaches-netzwerk.at zu konfigurieren, wobei ich allerdings auf diverse Probleme stoße. (Alles auf einem Server -> Cert, NPS, RRAS, AD)
Es wird überall gesagt, ich brauche eine zweite physikalische Netzwerkkarte. Diese lässt sich allerdings nur durch Netcup für 35,-€ pro Monat bereitstellen, was ist für absolut frech halte.
Jetzt zu meinen Fragen.
1: Kann ich den zweiten Netzwerkadapter für das interne Routen nicht mithilfe des Loopback-Adapter darstellen?
2: Ist es wirklich unmöglich, den NPS zusammen mit dem RRAS laufen zu lassen? -> oft gelesen, bei Fehlersuche
Zusätzliche Informationen:
OS: Windows Server 2019 Standard
CPU: AMD EPYC™ 7702 (4 Kerne, nicht shared)
RAM: 16 GB
Wenn ich was vergessen haben sollte, Schande auf mein Haupt.
Liebe Grüße
Simon
UND JA: Ich bin mir der Risiken bewusst, den DC extern zu hosten. Daher wird eine S2S-VPN verbindung genutzt!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 740040794
Url: https://administrator.de/contentid/740040794
Ausgedruckt am: 04.11.2024 um 18:11 Uhr
65 Kommentare
Neuester Kommentar
Moin,
Damit verbunden die Frage, was nicht funktioniert bzw. wo kommst du vom Client aus nicht hin?
Gruß,
Dani
Ich habe versucht einen Always-on-VPN mithilfe der Microsoft-Docs und einfaches-netzwerk.at zu konfigurieren, wobei ich allerdings auf diverse Probleme stoße. (Alles auf einem Server -> Cert, NPS, RRAS, AD)
Die da konkrekt lauten? 1: Kann ich den zweiten Netzwerkadapter für das interne Routen nicht mithilfe des Loopback-Adapter darstellen?
Sobald ein Client eine Verbindung erfolgreich zum VPN Server aufgebaut hat, wird automatisch für den definierten IP Adressbereich für Clients eine Loopback Adapter erzeugt. Daher für SSTP und IKEv2 jeweils RAS und Routing aktivieren.Damit verbunden die Frage, was nicht funktioniert bzw. wo kommst du vom Client aus nicht hin?
2: Ist es wirklich unmöglich, den NPS zusammen mit dem RRAS laufen zu lassen? -> oft gelesen, bei Fehlersuche
Technisch spricht nichts dagegen. Da es keinerlei Überschneidungen bei den Ports der Services gibt. RRAS: 443/tcp, 500/udp, 4500/udp; NPS: 1812/udp, 1813/udp. Allerdings wird vermutlich RRAS und Zertifizierungsstelle mit Web-Registierung in die Quere kommen. Letzters ist eigentlich aber nicht für AW VPN On notwendig. Hast du dazu noch die Links, wo evtl. auch eine technische Begründung zu finden ist?Gruß,
Dani
Kein passendes Zertifikat für IKEv2 gefunden
Muss man ja auch nicht "suchen" sondern generiert man sich selber !IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Bzw. bei IKEv2 Site-to-Site ist gar keins erforderlich.
IPsec IKEv2 Standort VPN Vernetzung mit Cisco, pfSense OPNsense und Mikrotik
Oder nutzt ein Client VPN Protokoll was kein Zertifikat erfordert wie L2TP
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Wenn man sinnigerweise bei allen Endgeräten immer die bordeigenen VPN Clients nutzt.
Zitat von @bluelight:
Hi Alex,
natürlich ist das meine Testumgebung. Solche Spielchen mache ich nicht in einer Produktivumgebung.
Oder was meinst du konkret?
Hi Alex,
natürlich ist das meine Testumgebung. Solche Spielchen mache ich nicht in einer Produktivumgebung.
Oder was meinst du konkret?
Dann bin ich beruhigt
Folgendes klang einfach wirklich so, als würdest Du auf einem im öffentlichen Netz rumfliegenden Root-Server die AD-Dienste und alles andere für euer Unternehmen einfach mal draufschmeissen und loslegen :D
Ich habe für unser Unternehmen ein Domänennetzwerk auf einem Rootserver von Netcup erstellt...
Gruß
Alex
Moin,
Gruß,
Dani
Kein passendes Zertifikat für IKEv2 gefunden, obwohl definitiv ein passendes Computer und Benutzerzertfikat vorhanden ist, Verbindung durch Richtlinie untersagt - die habe ich jetzt gerade nur aus dem Kopf.
Wichtig ist an dieser Stelle, dass das VPN Profil als Benutzer System erstellt bzw. importiert wird. Gerne darfst du sicherheitshalber einmal die ausgeführten Befehle hier posten. Des Weiteren muss das Computerzertifikat auch im Zertifikatsspeicher des Computers sein. Alles andere wird nicht funktionieren. Ist das gegeben? Ich komme theoretisch überall hin, nur wird überall bei DirectAccess oder AwOVPN eine zweite physische Netzwerkkarte vorausgesetzt.
theoretisch ist doch nicht relevant. Wie sieht es praktisch aus? Ich kann dir sagen, dass bei uns alle VPN Server ausschließlich über eine Netzwerkkarte verfügen. Schlussendlich ist es eine Kombination aus dem Netzwerkdesign und Routing sowie Sicherheitanforderungen. Mir wäre auch keine offzielle Microsoft Docs Seite bekannt, wo zwei Netzwerkkarten Pflicht sind. Gerne darfst du den Link posten. Jeweils keine technischen Begründen. Nur Feststellungen, dass es bei Trennung der Dienste auf verschiedene Server dann lief.
Nenn und bitte die konkrete Links. Dann können wir uns eine Meinung/Einschätzung bilden. Einzig könnte es sein, dass die beschriebene Vorgehensweise bzw. Einstellungen bei einer gemeinsamen VM abweichen werden.Gruß,
Dani
Moin,
Ich habe gerade nochmals bei uns nachgeschaut. Alle VPN Server haben bei uns eine Netzwerkkarte und es läuft seit Monaten ohne Probleme.
Gruß,
Dani
Ist gegeben!
Hast du als Gegenprobe den User Tunnel mit Benutzername und Passwort und Zertifikat ausprobiert? Um so auszuschließen, ob es ein Server oder Client Problem ist?! Microsoft Docs AwO VPN -> [...]Auf diesem Server müssen zwei physische Netzwerkadapter installiert sein, eine zum Herstellen einer Verbindung mit dem externen Umkreis Netzwerk und eine, um eine Verbindung mit dem internen Umkreis Netzwerk herzustellen.[...]
Die Aussage kommt zu Stande, weil Microsoft von einem klassischen Netzwerkdesign ausgehen.Ich habe gerade nochmals bei uns nachgeschaut. Alle VPN Server haben bei uns eine Netzwerkkarte und es läuft seit Monaten ohne Probleme.
Gruß,
Dani
Zitat von @bluelight:
Ist sowieso nur die Testdomäne, also ist das völlig schnuppe.
Die gibts in 3 Tagen nimmer.
Ist sowieso nur die Testdomäne, also ist das völlig schnuppe.
Die gibts in 3 Tagen nimmer.
Klar, um die AD selber geht's dabei auch gar nicht. Es ist daran allerdings auch ersichtlich, wo Du arbeitest (sofern Du die Testdomäne nicht nach einem anderen Unternehmen benannt hast) und mögliche Angreifer sehen hier dann direkt schon (oder in künftigen Beiträgen), wie eure Umgebung aufgebaut ist und kriegen mögliche Einfallstore auf dem Silbertablett serviert.
Gruß
Alex
Moin,
Wird in den meisten Fällen dazu genutzt, um nach der Servereinrichtung zu testen, ob alle Komponenten funktionieren. Denn wenn du alles eingerichtet hast und es funktioniert nicht ist immer die Frage woran es liegen kann.
Gruß,
Dani
Wenn du mir verraten würdest, wie sich das realisieren lässt. Würde mich interessieren.
damit wir nicht nochmals aneinander vorbei reden. Das gilt natürlich nur für AWVPNON auf Basis von User-Tunnels. Bei Device Tunnels ist das nicht möglich.Wird in den meisten Fällen dazu genutzt, um nach der Servereinrichtung zu testen, ob alle Komponenten funktionieren. Denn wenn du alles eingerichtet hast und es funktioniert nicht ist immer die Frage woran es liegen kann.
Habe jetzt den folgenden Fehler:
Da kommen mehrere Faktoren ins Spiel:- Dass im Zertifikat auf dem RAS-Server die notwendigen Verwendungszwecke (Server Authentification und/oder IP security IKE intermediate) fehlt.
- Das Attribut subjectName ist im Zertifikat des RAS-Servers nicht gesetzt.
- Das Root Zertifikat deiner CA ist nicht auf deinem Client vorhanden.
Gruß,
Dani
Moin,
sieht soweit in Ordnung aus.
Gruß,
Dani
sieht soweit in Ordnung aus.
- Sicherheitshalber noch die Frage nach dem Algorithmus der CA: Nutzt du SHA2 oder höher? SHA1 könnte Probleme machen.
- Hast du mehr als ein ausgestelltes Zertifikat von deiner CA im Zertifikatsspeicher des Computerkontos -> Eigene Zertifikate -> Zertifikate liegen? Dann könnte das hier zutreffen.
SubjectName wäre dann im deutschen Allgemeiner Name - alternative Namen sind ebenfalls per DNS-Attribut gesetzt.
Ist im SubjectName auch der FQDN des RAS-Servers enthalten? Setzt natürlich voraus, dass der RRAS-Server sowohl im LAN als auch über das Internet mit dem Selben erreichbar ist. Je nachdem für welche Methode (Split DNS oder Master-Slave) du dich entschieden hast. Können wir an Hand der fehlenden Informationen nicht erkennen.Gruß,
Dani
Moin,
Sei's drum: In diesen Fall bitte nochmals NPS und RAS Konfiguration durchführen, so dass du ggf. das Zertifikat nochmals auswählen kannst. Bitte den Neustart des Servers nicht vergessen. Sicher ist sicher. Somit ist sichergestellt, dass alle Services das vorhandene Zertifikat nutzen.
Es können im SubjectName natürlich mehrere Einträge vorhanden sein. Fakt ist, der FQDN muss im Zertifikat enthalten sein. Auf die Idee, intern und extern unterschiedliche Adressen zu verwenden, sind wir noch nicht gekommen. Weil es swohl technisch als auch logisch keine sinnvolle Gründe dafür gibt. Aber ich lerne gerne dazu...
Gruß,
Dani
Entfernen des NPS-Servercert hat nichts gebracht, nach wie vor die selbe Fehlermeldung.
Warum hast du das NPS Zertifikat gelöscht? Macht doch keinen Sinn.... denn bei Nutzung des NPS musst du bei dessen Konfiguration bereits explizit das Zertifikat auswählen. Damit ist eine Eindeutigkeit gegeben. Bei RRAS sieht es etwas anders aus. Da reicht es, wenn du den von mir geposteten Link berücksichtigst.Sei's drum: In diesen Fall bitte nochmals NPS und RAS Konfiguration durchführen, so dass du ggf. das Zertifikat nochmals auswählen kannst. Bitte den Neustart des Servers nicht vergessen. Sicher ist sicher. Somit ist sichergestellt, dass alle Services das vorhandene Zertifikat nutzen.
Der SubjectName ist bei mir nicht der FQDN des Servers bei dem Zertifikat für den RRAS Server, sondern die externe Subdomain, die ich für den VPN Zugriff eingerichtet habe: tom.example.de, welche auf die öffentlich IPv4 des Servers zeigt.
Die FQDN ist nicht aus dem Internet erreichbar, da die FQDN „tom.int.example.de“ lautet.Es können im SubjectName natürlich mehrere Einträge vorhanden sein. Fakt ist, der FQDN muss im Zertifikat enthalten sein. Auf die Idee, intern und extern unterschiedliche Adressen zu verwenden, sind wir noch nicht gekommen. Weil es swohl technisch als auch logisch keine sinnvolle Gründe dafür gibt. Aber ich lerne gerne dazu...
Wenn mich nicht alles täuscht, nutze ich die Split-DNS Konfiguration. Musste allerdings bisher noch nichts im DNS einstellen, da ich bisher noch keine eigenen Routen/DNS bereitstellen musste bei dem AWOVPN Test.
Split DNS bedeutet, dass du die Adresse vpn.domain.de sowohl intern als auch extern nutzen möchtest. In 98% der Fällle gibt es dazu einen DNS-Server im lokalen Netzwerk und die selbe Zone bei einem Domain/Webhoster. Somit ist jeweils ein A Records mit der jeweiligen IP-Adresse zu erstellen. NPS-Servercert ist sowieso überflüssig, da ein Cert mit Serverauthentifzierung reicht, da ich sowieso alles auf einem Host habe.
Testen/Spielen: Ja, Produtkiv: Nein. Zumal man eigentlich das Lab genauso aufbaut wie es später produktiv aussehen soll. So dass man die Gegebenheiten später nachschauen bzw. evtl. Fallstricke vermeidet.Info zur Client-Konfiguration: Da ich ohne zweites Netzwerkinterface am Server nicht NATen kann, wird am Client Split-Tunneling benutzt. Würde auch lieber über den VPN mit den Clients ins Internet gehen, funktioniert nur leider nicht.
Da du vermutlich keine VM mit einer Firewall betreibst, hat dein Root Server nach wie vor auf dem phys. Interface eine öffentliche IP-Adresse. Sobald ein VPN Client eingewählt ist, wird ein zweites Interface auf dem RAS Server erstellt und aktiviert. Somit müsste auch NAT möglich sein. Wobeiich nicht weiß, ob der RAS Service virtuelle Interfaces unterstützt.Als primärer DNS Server im Ethernet Interface ist die öffentliche IPv4 des Servers drin.
Das liegt an deinem Design (siehe Microsoft Docs). Die DNS-Server werden von RAS Server übernommen. Kann erst einmal nicht verändert werden. Bei der Nutzung des empfohlenen Netzwerk Design kann dies mit DNS Policies auf den VPN Clients gesteuert werden.Gruß,
Dani
wenn im Vorfeld ein zweites Interface vorhanden ist
Nein, zumindestens bei einem Hypervisor mit einem internen vSwitch ist das nicht erforderlich. Dort hängt man z.B. eine Firewall VM die VPN, NAT und alles andere bedient, wie z.B. pfSense einfach mit auf den vSwitch. Allerdings benötigt man dann eine 2te IP Adresse, das ist klar.
Moin,
Gruß,
Dani
Ich habe mich da lediglich an die Anleitung gehalten, welche besagt, dass im SubjectName die externe Subdomain zum ansprechen des VPN drin sein soll.
In der Anleitung nutzt der Blogger sicherlich intern und extern die gleiche Domain. Was aber bei dir nach meinem bisherigen Verständnis nicht der Fall ist.Aber damit mein Server und Client weiß, wie genatet werden soll, muss ich ihm das vorher schon sagen, Das kann ich aber nur, wenn im Vorfeld ein zweites Interface vorhanden ist - belehr mich gern eines besseren
Ich habe das letzte Mal vor 10 Jahren NAT auf einem Windows Server eingerichtet. Das war ein windiges Konstrukt bei einem Kunden. Ich kenn diesbezüglich die aktuellen Voraussetzungen nicht. Da ist Kollege @aqui vermutlich besser informiert.Gruß,
Dani
Moin,
Gruß,
Dani
So, habe gerade noch einmal neu Konfiguriert und erhalte den selben Fehler.
hast du auch die Problematik bezüglich FQDN und SubjectNames im Zertifikat behoben? Kann ich nicht irgendwo Logs am Client & Server auslesen, die mir genau sagen, wo es hakt?
Die Ereignisanzeige ist wie immer die erste Anlaufstelle.Gruß,
Dani
@aqui
In diesem Fall ist es phys. Server, auf dem allen notwendigen Rollen betrieben werden. Also kein VM, kein vSwitch.
Gruß,
Dani
In diesem Fall ist es phys. Server, auf dem allen notwendigen Rollen betrieben werden. Also kein VM, kein vSwitch.
Gruß,
Dani
@aqui
Gruß,
Dani
Wie gruselig.... Microsoft so ungeschützt direkt ins Internet zu exponieren macht ja nichtmal mehr ein IT Laie heutzutage...aber egal.
In diesen Fall werde ich im September nochmals eine Lehre anfangen. Gibts bei euch noch ne Lehrstelle? Gruß,
Dani
Zitat von @bluelight:
Gib mir gerne Tipps und Infos an die Hand.
Ich bin recht neu im Administrieren von Windows Servern!
@aqui, darf ich Antworten? 🤣Zitat von @aqui:
Wie gruselig.... Microsoft so ungeschützt direkt ins Internet zu exponieren macht ja nichtmal mehr ein IT Laie heutzutage...aber egal.
Wie gruselig.... Microsoft so ungeschützt direkt ins Internet zu exponieren macht ja nichtmal mehr ein IT Laie heutzutage...aber egal.
Gib mir gerne Tipps und Infos an die Hand.
Ich bin recht neu im Administrieren von Windows Servern!
Moin,
b) Vermeidlich gibt es nicht. Es ist erst einmal alles relevant was nicht ausgeschlossen werden kann.
Gruß,
Dani
Ich nutze folgendes Design:
Öffentliche Domain: example.de
AD-Domäne: int.example.de
Es handelt sich dabei grundsätzlich um Split-DNS. Allerdings mit verschiedenen Zonen. Daher ist die Domain bzw. FQDN intern und extern unterschiedlich und damit kein definiertes Split-DNS wie es Microsoft gerne definiert.Öffentliche Domain: example.de
AD-Domäne: int.example.de
Ja, habe ich.
Welche FQDN stehen aktuell im Attribut SubjectNames drin? Ich bin recht neu im Administrieren von Windows Servern!
Jeder fängt mal klein, keine Frage. Aber warum suchst du dir gleich die schwerste Rolle Always on-VPN neben AD FS mit WAP heraus? Dort bekomme ich aber nur eine, vermeintlich, nicht relevante Meldung.
a) Das ist nicht nicht klassische Ereignisanzeige.b) Vermeidlich gibt es nicht. Es ist erst einmal alles relevant was nicht ausgeschlossen werden kann.
Gruß,
Dani
Moin
Einfaches Beispiel: Wie möchtest du die Sperrliste deiner CA(s) (je nachdem ob 1 oder 2 stufig) im Internet zu veröffentlich, damit die potenziellen Clients vor der Einwahl prüfen können, ob das Zertifikat des Computers noch gültig ist?!
Gruß,
Dani
Antragsteller: CN=tom.int.example.de
Antragssteller und SubjectNames (zu deutsch alternative Antragsteller) sind zwei verschiedene Baustellen. Das ist Grundkurs PKI für Windows. Was steht bei dir bei alternative Antragsteller drin?Weil ich Idiotensicher und Benutzerfreundlich arbeiten muss, da die Mitarbeiter manchmal ein wenig auf den Kopf gefallen sind. -> der zusätzliche Klick auf das Netzwerksymbol fällt weg.
Das Ziel/Vorhaben ist lobenswert. Erklärt aber meiner Meinung nach nicht, warum du als Anfänger nicht auf einfachere Lösungen konzentrierst, mit denen du das selbe Ziel erreichen kannst. Das Einrichten von Always-On VPN ist im Vergleich zum Betrieb noch der einfache Teil. Die Wartung und die Pflege der CA ist eine wiederkehrende Aufgabe, die nicht zu unterschätzen ist.Außerdem möchte ich die PCs Administrieren können, ohne dass ein Nutzer angemeldet sein muss um die VPN Verbindung herzustellen.
Mit der richtigen Software im Bereich Fernwartung ist auch das problemlos ohne VPN Tunnel sicher und verlässlich möglich.Einfaches Beispiel: Wie möchtest du die Sperrliste deiner CA(s) (je nachdem ob 1 oder 2 stufig) im Internet zu veröffentlich, damit die potenziellen Clients vor der Einwahl prüfen können, ob das Zertifikat des Computers noch gültig ist?!
Gruß,
Dani
Moin,
Das bringt aber nur was, wenn die Sperrliste von den Clients über das Internet vor dem Verbindungsaufbau auf die Sperrliste abfragen kann. Ist das nicht möglich, erfolgt keine Validierung. Was somit ein Sicherheitsloch darstellt.
Im internen Netzwerk lässt sich die Erreichbarkeit relativ einfach umsetzen, zumal in den meisten Fällen keine Edge Firewalls genutzt werden. Aber im externen Netzwerk (Internet) muss das Hand und Fuß haben. Denn hier kann jede geschaffene Türe ein potenzielles Angriffsziel sein.
Aber was erzähl ich da... PKI unter Windows ist kein Thema für 5-6 Tage sondern für mehrere Wochen. Denn da gibt's schon bei der Einrichtung eine haufen Steine, mit denen du dir den Weg verbauen kannst.
Gruß,
Dani
Als alternativer Antragsteller habe ich: DNS-Name: tom.int.example.de im NPS Zertifikat
Und was hast du beim Zertifikat für RRAS Server angegeben?Wie kann ich denn einen Device- und User-Tunnel erstellen, ohne Benutzerinteraktion?
rasdial per Script ist raus, weil er keine Eingabe von Benutzerdaten via Script zulässt.
Des Weiteren kann die Verbindung ganz leicht durch den Benutzer getrennt werden.
Wenn du ein Device Tunnel nimmst, gibt es einen Parameter für Automatic Logon. Sprich sobald eine Internetverbindung vorhanden ist (auch dem Login des Benutzers), wird der IKEv2 Tunnel aufgebaut. Der Benutzer kann diesen zwar manuell trennen. Aber das System baut den Tunnel sofort wieder auf. Bei einem User-Tunnel bin ich gerade überfragt, da wir dies produktiv nicht nutzen. Sondern ausschließlich im LAB für den Tests von Firewall-Regeln.rasdial per Script ist raus, weil er keine Eingabe von Benutzerdaten via Script zulässt.
Des Weiteren kann die Verbindung ganz leicht durch den Benutzer getrennt werden.
Es geht mir primär um Softwareverteilung wie z.B.: ein Update der Warenwirtschaft auf allen Workstations + Packtischen fahren, ohne mich vorher überall aufschalten zu müssen um den VPN zu verbinden.
Warum nicht klassische Produkte für Softwareverteilung nutzen? Wenn es nichts Kosten soll/darf, geht's sicherlich auch mit dem WSUS Package Publisher (WPP). Sprich die Updates werden über die Windows/Microsoft Update API auf den Systemen zur Installation bereitgestellt. Hier ist sicherlich auch Einarbeitungszeit notwendig, bis das System verstanden und ein Konzept für die Nutzung geschrieben ist. Also ich weiß schon, was eine Sperrliste ist, aber mit der Veröffentlichung dieser habe ich mich noch nicht befasst.
Nehmen wir an, ein Notebook wird gestohlen oder ein Mitarbeiter fristlos entlassen. Dann sollte die IT heutzutage in der Lage sein, dass sofort Benutzerkonto zu sperren. Bei Einsatz von Always-On VPN muss eben auch das betroffene Zertifikat des Computer oder/und Benutzers gesperrt und anschließend die Sperrliste aktualisiert werden.Das bringt aber nur was, wenn die Sperrliste von den Clients über das Internet vor dem Verbindungsaufbau auf die Sperrliste abfragen kann. Ist das nicht möglich, erfolgt keine Validierung. Was somit ein Sicherheitsloch darstellt.
Im internen Netzwerk lässt sich die Erreichbarkeit relativ einfach umsetzen, zumal in den meisten Fällen keine Edge Firewalls genutzt werden. Aber im externen Netzwerk (Internet) muss das Hand und Fuß haben. Denn hier kann jede geschaffene Türe ein potenzielles Angriffsziel sein.
Ich würde halt die Sperrliste per Freigabe + DNS Eintrag + CA Konfiguration für die Clients verfügbar machen, jetzt so aus dem Kopf raus.
Wenn du mit Freigabe ein Share auf SMB/CIFS meinst, vergiss es. Da holst du dir schneller eine Malware o.ä. wie du Always-On VPN einrichten kannst. Zudem müssen je nach Verfahren der Sperrliste (CRL und/oder OCSP) die Domains für deren Abruf im internen und externen Netzwerk identisch sein (z.B. crl.domain.de, keine Subdomains für intern o.ä.).Aber was erzähl ich da... PKI unter Windows ist kein Thema für 5-6 Tage sondern für mehrere Wochen. Denn da gibt's schon bei der Einrichtung eine haufen Steine, mit denen du dir den Weg verbauen kannst.
Gruß,
Dani
Moin,
Anschließend nochmals den Verbindungsaufbau testen. Danach die exakte Fehlermeldung posten und parallel dazu in der Ereignisanzeigen von Client, RAS Server und NPS Server durchschauen. Am Besten jede Warnung und Fehler die im Zusammenhang steht posten. Denn ein Logfile gibt es so erstmal nicht. Wäre auch von der Microsoft Logik her auch nicht logisch.
Gruß,
Dani
Antragsteller: CN=tom.example.de; CN=tom.int.example.de
Alternativer Antragsteller: DNS-Name: tom.example.de; DNS-Name: tom.int.example.de; DNS-Name: 192.145.xx.xx (öffentliche IP) tom.example.de stellt den öffentliche A-Record da, der auf den Host/VPN zeigt.
Okay. Das nenne ich mal 101%. Hast du das Zertifikat hinzugefügt nachdem du das ursprüngliche Zertifikat gelöscht hast?! Dann solltest du dieses nochmals in der Konfiguration über die GUI oder per Powershell zuweisen und den Server neu starten. Den Client sicherheitshalber auch nochmals neu starten.Alternativer Antragsteller: DNS-Name: tom.example.de; DNS-Name: tom.int.example.de; DNS-Name: 192.145.xx.xx (öffentliche IP) tom.example.de stellt den öffentliche A-Record da, der auf den Host/VPN zeigt.
Anschließend nochmals den Verbindungsaufbau testen. Danach die exakte Fehlermeldung posten und parallel dazu in der Ereignisanzeigen von Client, RAS Server und NPS Server durchschauen. Am Besten jede Warnung und Fehler die im Zusammenhang steht posten. Denn ein Logfile gibt es so erstmal nicht. Wäre auch von der Microsoft Logik her auch nicht logisch.
Ändert doch nichts an der Situation, dass die Clients mit dem Hosts kommunizieren können müssen um die Software bereit zu stellen, oder bin ich doof? Würde allerdings gern PDQ Deploy nutzen, weil ich mich viel mit dem Programm beschäftigt habe und damit alles läuft, zwecks Inventarisierung etc.
Du hast bisher noch kein Wort über den Einsatzzweck uns genannt. Daher habe ich einfach mal spekuliert. Womit du grundsätzlich Recht hast, das ist aber das nächste Thema was ich anpacke, da ich mich aktuell in meinem Lab befinde und ja nicht mal das gewünschte Konzept läuft - Sperrliste hin oder her.
Nicht das es zuletzt an der Sperrliste noch scheitert. Ich bin mir nämlich nicht sicher, ob der Revocation Check standardmäßig (de)aktiviert ist. Bei älteren Windows 10 Versionen war es optional ob es bei der aktuellen Version auch noch so ist, weiß ich nicht. Nein, meine eine Freigabe via IIS.
Da reden wir evtl. nochmals drüber, wenn du dich eingelesen hast.Gruß,
Dani
Moin,
Gruß,
Dani
Die bereits vorher geposteten Fehlermeldungen sind die einzigen die ich bekommen habe. Sonst gibt es keine Ereignisse zum Zeitpunkt des Verbindungsversuches.
welche IP-Adresse hast du auf dem NPS Server unter dem Radius Server Gruppe hinzugefügt? Weil im Screenshot des Ereignisanzeige die IP-Adresse 192.145.x.y ignoriert wird. Dazu gibt es auch von Microsoft Lesestoff: Event ID 25 — NPS Proxy Configuration Aber das wäre doch humbuk. Dann würde ja keine CERT-Auth mehr funktionieren, sobald die Sperrliste, warum auch immer, nicht verfügbar ist.
Warum legen CA Anbieter ihre CRLs mehrfach redudant aus und bieten in der Regel auch noch OCSP an. Bestes Beispiel sind Webseiten mit SSL Zertifikat.Gruß,
Dani
Moin,
Gruß,
Dani
Ich habe die öffentlich IP hinzugefügt.
Okay. Bekommst du immer noch die selbe oder neue Fehlermeldung bei einem weiteren Test-Verbindung.Ich kann dem RRAS Server kein Zertifikat zuweisen. Ich kann lediglich dem NPS Server in der Richtlinie sagen, mit welchem Zertifikat er sich ggü. den Client authentifizieren soll. Oder nicht?
Doch das ist möglich. Weil im Regelfall der Client eine Verbindung zum RAS-Server aufbaut und dieser anschließend einen Request an den NPS Server schickt. Sind für mich zwei Bausteine. Was steht dazu in deiner genannten Anleitung?Gruß,
Dani
Zitat von @bluelight:
Hi @Dani,
ich habe einen neuen Denkansatz.
Diese Thema Always-on-VPN mit Windowsmitteln nervt mich dermaßen, dass ich langsam keine Lust mehr habe, mich damit zu beschäftigen.
Was wäre denn, wenn ich jetzt zum Beispiel eine Linux VM miete, dort pfSense o.Ä. installiere und den DC per vLAN da dran hänge. So ist der DC nicht dem öffentlichen Netz ausgesetzt, ich könnte über die Firewall VM NATen, mit der VM IP ins Internet gehen und trotzdem auf die benötigen Unternehmensressourcen zugreifen.
Als Tool auf den Clients könnte ich ja entweder 3rd Party Tools (OpenVPN o.Ä.) oder ggf. eine VPN Verbindung direkt über die FritzBox am Standort herstellen, so dass ich quasi auch einen Always-on-VPN habe. Für mich ist halt eine Start before Logon Verbindung nötig um Computer entsprechend in die Domäne joinen zu können und neue Mitarbeiter den First-Login durchführen können am gewohnten Anmeldebildschirm ohne auf Netzwerkanmeldung drücken zu müssen.
Funktioniert dieser Gedanke oder nur Wunschvorstellung?
Liebe Grüße
Simon
Hi @Dani,
ich habe einen neuen Denkansatz.
Diese Thema Always-on-VPN mit Windowsmitteln nervt mich dermaßen, dass ich langsam keine Lust mehr habe, mich damit zu beschäftigen.
Was wäre denn, wenn ich jetzt zum Beispiel eine Linux VM miete, dort pfSense o.Ä. installiere und den DC per vLAN da dran hänge. So ist der DC nicht dem öffentlichen Netz ausgesetzt, ich könnte über die Firewall VM NATen, mit der VM IP ins Internet gehen und trotzdem auf die benötigen Unternehmensressourcen zugreifen.
Als Tool auf den Clients könnte ich ja entweder 3rd Party Tools (OpenVPN o.Ä.) oder ggf. eine VPN Verbindung direkt über die FritzBox am Standort herstellen, so dass ich quasi auch einen Always-on-VPN habe. Für mich ist halt eine Start before Logon Verbindung nötig um Computer entsprechend in die Domäne joinen zu können und neue Mitarbeiter den First-Login durchführen können am gewohnten Anmeldebildschirm ohne auf Netzwerkanmeldung drücken zu müssen.
Funktioniert dieser Gedanke oder nur Wunschvorstellung?
Liebe Grüße
Simon
Das wäre ohnehin die bessere Variante, ein Site 2 Site VPN.
Gruselig wäre es, den VPN Server direkt auf dem DC zu betreiben, daher lass das lieber (aus diesem Grund auch meine Bedenken oben)
An eurem Standort kannst Du dann z.B. ein APU Board mit PFsense installieren. Schau Dich mal bei @aqui um, der hat da ein paar gute Anleitungen geschrieben wie man sowas wasserdicht einrichtet.
Gruß
Alex
Zitat von @bluelight:
Hey @Ad39min,
Grüße
Simon
Hey @Ad39min,
Gruselig wäre es, den VPN Server direkt auf dem DC zu betreiben, daher lass das lieber (aus diesem Grund auch meine Bedenken oben)
Na, ich steh auf Gruselige Dinge An eurem Standort kannst Du dann z.B. ein APU Board mit PFsense installieren. Schau Dich mal bei @aqui um, der hat da ein paar gute Anleitungen geschrieben wie man sowas wasserdicht einrichtet.
Muss ich ein APU Board dafür nehmen? Die F!B unterstützt ja auch IPsec. Der Chef ist ein Geizkragen und versteht sowieso nicht, wieso ich das alles mache. Dem ist Unternehmenssicherheit ein Fremdwort.....Grüße
Simon
Du musst nichts, du kannst natürlich auch z.B. eine Fortinet für 1000 Euro nehmen statt ein günstiges APU-Board
oder halt die VPN-Funktion der Fritte. Diese ist allerdings performance-technisch nicht mit der PFsense vergleichbar und wohl in Deiner Umgebung ein Flaschenhals. Aber wenn Deine Kollegen mit Anmeldezeiten von über 10 Minuten leben können, dann ist das natürlich kein Thema (war jetzt leicht übertrieben, aber schon ein kleiner Vorgeschmack)
Und wo wir schon über Kosten reden: Weiß Dein Chef denn schon was vom Windows Server her lizenztechnisch für Kosten auf ihn zukommen?
Gruß
Alex
Zitat von @bluelight:
Für mich zum Verständnis des Aufbaus: Telefonleitung ankommend auf APUBoard -> von da auf Fritzbox -> auf restliche Netzwerkgeräte?
Zitat von @Ad39min:
Du musst nichts, du kannst natürlich auch z.B. eine Fortinet für 1000 Euro nehmen statt ein günstiges APU-Board
oder halt die VPN-Funktion der Fritte. Diese ist allerdings performance-technisch nicht mit der PFsense vergleichbar und wohl in Deiner Umgebung ein Flaschenhals. Aber wenn Deine Kollegen mit Anmeldezeiten von über 10 Minuten leben können, dann ist das natürlich kein Thema (war jetzt leicht übertrieben, aber schon ein kleiner Vorgeschmack)
Und wo wir schon über Kosten reden: Weiß Dein Chef denn schon was vom Windows Server her lizenztechnisch für Kosten auf ihn zukommen?
Gruß
Alex
Zitat von @bluelight:
Hey @Ad39min,
Grüße
Simon
Hey @Ad39min,
Gruselig wäre es, den VPN Server direkt auf dem DC zu betreiben, daher lass das lieber (aus diesem Grund auch meine Bedenken oben)
Na, ich steh auf Gruselige Dinge An eurem Standort kannst Du dann z.B. ein APU Board mit PFsense installieren. Schau Dich mal bei @aqui um, der hat da ein paar gute Anleitungen geschrieben wie man sowas wasserdicht einrichtet.
Muss ich ein APU Board dafür nehmen? Die F!B unterstützt ja auch IPsec. Der Chef ist ein Geizkragen und versteht sowieso nicht, wieso ich das alles mache. Dem ist Unternehmenssicherheit ein Fremdwort.....Grüße
Simon
Du musst nichts, du kannst natürlich auch z.B. eine Fortinet für 1000 Euro nehmen statt ein günstiges APU-Board
oder halt die VPN-Funktion der Fritte. Diese ist allerdings performance-technisch nicht mit der PFsense vergleichbar und wohl in Deiner Umgebung ein Flaschenhals. Aber wenn Deine Kollegen mit Anmeldezeiten von über 10 Minuten leben können, dann ist das natürlich kein Thema (war jetzt leicht übertrieben, aber schon ein kleiner Vorgeschmack)
Und wo wir schon über Kosten reden: Weiß Dein Chef denn schon was vom Windows Server her lizenztechnisch für Kosten auf ihn zukommen?
Gruß
Alex
Für mich zum Verständnis des Aufbaus: Telefonleitung ankommend auf APUBoard -> von da auf Fritzbox -> auf restliche Netzwerkgeräte?
Wenn das an eurem Anschluss geht, ist das die zu bevorzugende Variante und die Fritzbox kann man gleich weglassen, solange sie nicht z.B. noch gleichzeitig Telefonanlage ist.
Ansonsten kann das APUBoard natürlich auch hinter der FritzBox stehen, auch wenn das die unschönere Variante ist.
Oder wie ist dort der Aufbau?
Ich hätte sonst noch ein kleinen Lenovoserver da stehen, den könnte ich doch statt dem APUBoard nehmen, oder nicht?
Ich hätte sonst noch ein kleinen Lenovoserver da stehen, den könnte ich doch statt dem APUBoard nehmen, oder nicht?
Da lässt sich bestimmt auch PFSense drauf installieren (müsstest Du halt testen).
Hat allerdings nur einen LAN Anschluss.
Das ist unschön, aber in dem Modell PFSense hinter Fritzbox dennoch machbar. Ein Sicherheitsrisiko ist es auch noch, da Du dann mittels Port-Forwarding ungeschützt Traffic aus dem Internet in euer Firmennetz lassen musst. Sofern sich das irgendwie vermeiden lässt, sollte man es tun.
-
Und wieso nicht gleich den Lenovo-Server bei euch intern als Windows-Server betreiben?
Gruß
Alex
Zitat von @bluelight:
Aber die Variante PF hinter Fritte ist sowieso die Variante der Wahl, weil wir die Fritte für die Telefone nutzen. Haben kein Cloud-SIP.
Wenn das an eurem Anschluss geht, ist das die zu bevorzugende Variante und die Fritzbox kann man gleich weglassen, solange sie nicht z.B. noch gleichzeitig Telefonanlage ist.
Fritzbox wird als DECT-Basisstation genutzt.Ansonsten kann das APUBoard natürlich auch hinter der FritzBox stehen, auch wenn das die unschönere Variante ist.
Will ja vermeiden, einen weiteren Einkauf zu tätigen. Also APU Board vorerst keine Option.Da lässt sich bestimmt auch PFSense drauf installieren (müsstest Du halt testen).
Bestimmt. Debian 10 drauf und ab gehts!Das ist unschön, aber in dem Modell PFSense hinter Fritzbox dennoch machbar. Ein Sicherheitsrisiko ist es auch noch, da Du dann mittels Port-Forwarding ungeschützt Traffic aus dem Internet in euer Firmennetz lassen musst. Sofern sich das irgendwie vermeiden lässt, sollte man es tun.
Ich versuche alles zu geben, um das alles so sicher wie nur möglich zu gestalten. Aber mir sind die Hände halt Budgettechnisch ein wenig gebunden.Aber die Variante PF hinter Fritte ist sowieso die Variante der Wahl, weil wir die Fritte für die Telefone nutzen. Haben kein Cloud-SIP.
Und wieso nicht gleich den Lenovo-Server bei euch intern als Windows-Server betreiben?
Weil der uralt ist und einen HDD drin hat. Der ist wirklich sehr langsam. Da muss man sich zusammen reißen, wenn man darauf arbeitet.Eine Variante wäre auch die FritzBox hinter die PFSense zu packen und rein für die IP-Telefonie als IP Client einzurichten. Das scheitert nur daran, dass die PFsense nur einen LAN-Anschluss hat. Schade.
Unter den Umständen, dass wirklich gar kein Geld für die ganze Aktion zu Verfügung steht ist das alles natürlich schon sehr gewagt.
Vielleicht bleibt dann doch nur noch die Lösung die FritzBox als Site-to-Site Komponente zu verwenden, als einzig vernünftige Variante.
Oder, (falls sich irgendwie 50-70€ noch locker machen lassen) ein Mikrotik RouterBoard. Aber auch bei den letzteren beiden Varianten muss man im Fall der Fälle mit Mehrkosten rechnen, falls etwas nicht rennt wie es soll.
Angenommen ihr habt 10 User könnten nach Inbetriebnahme auch nochmal Lizenzkosten von ca. 800 Euro auf euch zukommen, allein dafür dass ihr Windows Server benutzt (Lizenz + CALs).
Gruß
Alex
Das scheitert nur daran, dass die PFsense nur einen LAN-Anschluss hat
Mit einem APU4 Mainboard hat sie dererlei 4 !!! Ansonsten tuts bei Budget Knappheit ja ein Mikrotik hAP für 20 Euronen der hat 4 LAN Ports:
https://www.varia-store.com/de/produkt/97209-rb941-2nd-routerboard-hap-l ...
Allways on VPNs macht der MT mit links...
Moin,
GRuß,
Dani
ich habe einen neuen Denkansatz.
Diese Thema Always-on-VPN mit Windowsmitteln nervt mich dermaßen, dass ich langsam keine Lust mehr habe, mich damit zu beschäftigen.
Oha, das war ein kurzes Gastspiel. Wenn deine Geduld so kurz ist, empfehle ich dir dich von PKI und AD FS fern zu halten. Diese Thema Always-on-VPN mit Windowsmitteln nervt mich dermaßen, dass ich langsam keine Lust mehr habe, mich damit zu beschäftigen.
GRuß,
Dani