11
Erfahrungen mit Always ON VPN unter Windows 10 od11
Hallo zusammen,
ich habe mal eine Frage an die Leute die Always On VPN vom Microsoft Einsetzen.
Hintergrund der Sache ist folgender:
Unser Wartungsvertrag für unsere einfache VPN Lösung ( F5 - Big IP ) läuft dieses Jahr aus und wir wollen eigentlich den
Vertrag nicht mehr verlängern da die Hardware nicht mehr die neuste ist ( ca 8 jahre ). Neue Hardware inkl. Wartungsvertrag würde uns eine ganze Stange Geld kosten was wir eigentlich nicht für eine VPN Only Appliance ausgeben wollen.
Mir ist bewusst das die Big IP Gateways eigentlich auch mehr können als nur VPN nur das ganze wird derzeit schon durch ein Cisco ASA Cluster mit 2 x DMZ in der Zentrale abgebildet was den Einsatz einer neuen Firewall überflüssig macht zumal die ASA irgendwann in den letzten 2 Jahren gegen FirePOWER ASA´s getauscht wurden so das ein Tausch eigentlich nicht wirtschaftlich wäre.
Jetzt fragt sich der Netzwerker natürlich, zu recht meiner Meinung nach, warum nicht das VPN der ASA nehmen ? Warum so umständlich. Nun ja ich versuche das ganze zu erklären...... Vor meiner Zeit wurde eine One Klick VPN Lösung gesucht womit der Benutzer am besten eine VPN Sitzung über eine Webseite aufbauen kann. Das ganze sollte damals so komfortabel für den User sein wie nur geht + DAU sicher....... Also Dienstleister ins Boot geholt und der hat die Big IP F5 Lösung an geschleppt. Die Lösung mit dem Big IP Edge Client funktioniert auch sehr gut wenn es denn läuft. Der Benutzer startet den Big IP Edge Client und klickt auf Verbinden und alles läuft autom. Anschließend ist er Verbunden........ Deswegen die Lösung.
Ich will da aber weg und habe jetzt mal kurz Quer gelesen das der Nachfolger vom alten Direct Access unter Server 2008 bzw. 2012 ganz gut sein soll. Profile per GPO installiert und wenn die Kiste ( Notebook ) im WLAN ist baut diese autom. eine Verbindung nach Hause auf OHNE das der Benutzer was machen muss. Gefällt mir schon mal. Datacenter Lizenzen und CAL´s haben wir mehr als genug vondaher brachen wir eigentlich keine Lizenzen kaufen. Der Gedanke ist hier zu nutzen was schon da ist bzw. was bereits gekauft wurde. Einen ( oder mehrerer RAS Server unter Windows Server aufzusetzen sollte kein Problem sein. )
Jetzt die Fragen:
Schonmal vielen dank.
Nebenei bemerkt: Ich kümmer mich in der Firma eigentlich um die VMWare Infrastruktur inkl SDS Storage über Datacore und einem 3PAR Cluster + Netzwerk Core Administration. An den Distribution Switches zu den Clients höhrt meine Zuständigkeit auf
Die WAN Anbindung hat man mir auch irgendwann mal aufs Auge gedrückt und hin und wieder mache ich zusammen mit einem Kollegen die VPN Administration und so wie es aussieht wohl jetzt auch noch das VPN Thema dauerhaft määääh ....
***
Mir ist bewust das ein AV nicht das Allheilmittel ist......
ich habe mal eine Frage an die Leute die Always On VPN vom Microsoft Einsetzen.
Hintergrund der Sache ist folgender:
Unser Wartungsvertrag für unsere einfache VPN Lösung ( F5 - Big IP ) läuft dieses Jahr aus und wir wollen eigentlich den
Vertrag nicht mehr verlängern da die Hardware nicht mehr die neuste ist ( ca 8 jahre ). Neue Hardware inkl. Wartungsvertrag würde uns eine ganze Stange Geld kosten was wir eigentlich nicht für eine VPN Only Appliance ausgeben wollen.
Mir ist bewusst das die Big IP Gateways eigentlich auch mehr können als nur VPN nur das ganze wird derzeit schon durch ein Cisco ASA Cluster mit 2 x DMZ in der Zentrale abgebildet was den Einsatz einer neuen Firewall überflüssig macht zumal die ASA irgendwann in den letzten 2 Jahren gegen FirePOWER ASA´s getauscht wurden so das ein Tausch eigentlich nicht wirtschaftlich wäre.
Jetzt fragt sich der Netzwerker natürlich, zu recht meiner Meinung nach, warum nicht das VPN der ASA nehmen ? Warum so umständlich. Nun ja ich versuche das ganze zu erklären...... Vor meiner Zeit wurde eine One Klick VPN Lösung gesucht womit der Benutzer am besten eine VPN Sitzung über eine Webseite aufbauen kann. Das ganze sollte damals so komfortabel für den User sein wie nur geht + DAU sicher....... Also Dienstleister ins Boot geholt und der hat die Big IP F5 Lösung an geschleppt. Die Lösung mit dem Big IP Edge Client funktioniert auch sehr gut wenn es denn läuft. Der Benutzer startet den Big IP Edge Client und klickt auf Verbinden und alles läuft autom. Anschließend ist er Verbunden........ Deswegen die Lösung.
Ich will da aber weg und habe jetzt mal kurz Quer gelesen das der Nachfolger vom alten Direct Access unter Server 2008 bzw. 2012 ganz gut sein soll. Profile per GPO installiert und wenn die Kiste ( Notebook ) im WLAN ist baut diese autom. eine Verbindung nach Hause auf OHNE das der Benutzer was machen muss. Gefällt mir schon mal. Datacenter Lizenzen und CAL´s haben wir mehr als genug vondaher brachen wir eigentlich keine Lizenzen kaufen. Der Gedanke ist hier zu nutzen was schon da ist bzw. was bereits gekauft wurde. Einen ( oder mehrerer RAS Server unter Windows Server aufzusetzen sollte kein Problem sein. )
Jetzt die Fragen:
- Klappt es meistens immer mit dem autom. Aufbau des Tunnels ?
- Redundanz über mehrere RAS Server sollte möglich sein ?
- Profile ( User und Computer ) kann ich per GPO verteilen - Klappt das gut ?
- Wie stelle ich sicher das bei der Einwahl geprüft wird ob auf dem System ein AV installiert ist
- Kann ich die Auth. bzw. Anmeldung an ein VPN Zertifikat alle IPSec mit Zertifikat binden
- Allgemein wie sind eure Erfahrungen mit dem Betrieb im allgemeinen ?
Schonmal vielen dank.
Nebenei bemerkt: Ich kümmer mich in der Firma eigentlich um die VMWare Infrastruktur inkl SDS Storage über Datacore und einem 3PAR Cluster + Netzwerk Core Administration. An den Distribution Switches zu den Clients höhrt meine Zuständigkeit auf
Die WAN Anbindung hat man mir auch irgendwann mal aufs Auge gedrückt und hin und wieder mache ich zusammen mit einem Kollegen die VPN Administration und so wie es aussieht wohl jetzt auch noch das VPN Thema dauerhaft määääh ....***
Mir ist bewust das ein AV nicht das Allheilmittel ist......
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: 5264000230
Url: https://administrator.de/contentid/5264000230
Ausgedruckt am: 19.11.2024 um 00:11 Uhr
11 Kommentare
Neuester Kommentar
1. Klappt immer, wenn die Kommunikation klappt. Device Tunnel ist in 2-5 Sekunden online, reicht um das Passwort zu tippen.
2. Ja. Und nicht nur das. Sondern auch Multipathing.
3. Klappt perfekt.
4. Denkfehler bitte beheben
5. Das ist grundsätzlich der Fall, nur ohne IPSec wie du es kennst.
Es läuft perfekt und wir haben über 10.000 Clients damit weltweit online.
Ohne wäre das Business nicht denkbar.
Es ist mit Abstand die beste VPN Lösung jedoch nur für Windows OS und Domain Member.
2. Ja. Und nicht nur das. Sondern auch Multipathing.
3. Klappt perfekt.
4. Denkfehler bitte beheben
5. Das ist grundsätzlich der Fall, nur ohne IPSec wie du es kennst.
Es läuft perfekt und wir haben über 10.000 Clients damit weltweit online.
Ohne wäre das Business nicht denkbar.
Es ist mit Abstand die beste VPN Lösung jedoch nur für Windows OS und Domain Member.
Moin,
Gruß,
Dani
Klappt es meistens immer mit dem autom. Aufbau des Tunnels ?
Durchweg.Redundanz über mehrere RAS Server sollte möglich sein ?
Ja. Wenn du mehrere RAS Server geografisch verteilt hat, ist Azure Traffic Manager zu empfehlen. Bei uns gibt es einen FQDN und je nachdem in welcher Region man sich befindet, wirst du zum nächst gelegen RAS-Server verbunden.Profile ( User und Computer ) kann ich per GPO verteilen - Klappt das gut ?
Wenn man weiß wie, Ja. Wie stelle ich sicher das bei der Einwahl geprüft wird ob auf dem System ein AV installiert ist
Das ist meiner Meinung nach nicht Aufgabe von VPN.Kann ich die Auth. bzw. Anmeldung an ein VPN Zertifikat alle IPSec mit Zertifikat binden
Ja. Dir muss nur klar sein, dass die Sperrlisten, etc. damit immer verfügbar sein müssen. Ansonsten könnte das mit der Einwahl schwierig werden.Allgemein wie sind eure Erfahrungen mit dem Betrieb im allgemeinen ?
Wir sind zufrieden damit.Gruß,
Dani
Guten morgen
schon mal vielen dank an an @2423392070 und @Dani für die schnelle und unkomplizierte Antwort.
Das ganze liest sich schon mal sehr gut und da es ja bei MS dabei ist sind keine Extra Lizenzen ( klar CAL und Server Lizenzen bzw. Clientlizenzen bracuh ich schon oder ggf. je nach Setup einen Ext. Connector .... ) bzw die Wartung ist über die SA sowieso schon bezahlt.
Das war doof formuliert. Ich meinte eher so eine Art Device Health Attestation weil das macht der jetzige F5 Big IP Edge Client... aber wenn das nicht geht dann ist es halt nicht möglich oder ich muss was mit dem NPS basteln
Wenn ich das jetzt alles mal so grob richtig verstanden habe ( Teils eure Antworten / Teil Technet Artikel ) dann bau ich das Ganze in etwa wie folgt auf:
2 x RRAS Server als Gateway ( Verschiedene Anschlüssen wenns geht mit unters. IP´s
1 x Azure Trafic Manager für die Erreichbarkeit welcher dann von AOVPN.firma.de auf rrasg01 od raasgw02.firma.de
weiterleitet wenn das eine defekt bzw. nicht erreichbar ist oder ich schenke mir den Quatsch mit den Traffic Manager und mach gleich Multipathing mit 2 RRAS Servern. Sprich der Client baut gleich 2 Verbindungen zum Always On VPN auf ?
Entsprechend dann durch die Firewall terminieren ( siehe unten ) und für die Clients dann die Zertifikate bzw. Konfiguration über eine / mehrere GPO je nach Anforderungen.....
Wir haben jetzt allerdings auch Notebooks welche kein LTE / 5G Modem haben. Hier würden die Benutzer sich dann erst beim WLAN einloggen wenns denn ohne Portal Seite ist bzw. wenn es eine Portal Seite gibt, auf der man die AGB anklicken muss, dann würden die Benutzer sich dann mit den cached Cred. am Gerät anmelden und anschließend die Verbindung übers WLAN ( Portalseite ) herstellen und dann würde der Tunnel aufgebaut ? Also sozusagen das der Tunnelaufbau erst nach der Anmeldung erfolgt. Alternativ müssen die User ihr Handy benutzen und dann entsprechend darüber arbeiten denn da muss nur der PSK eingegeben werden und alles ist gut.
Wie habt Ihr die RRAS Kisten abgesichert ? Firewall davor ( in unserem Fall ASA´s ) und dann die Ports gem. Technet für AOVPN freigegeben oder brauchts hier noch irgendein MS Proxy Dienst wie den Web Application Proxy ?
Ich würde die RRAS durch die DMZ Firewall erreichbar machen so das die VPN Tunnel dann in der DMZ terminieren und von da aus dann entsprechend weiter dürfen. und von da geht´s dann weiter
Fürs Verständnis und damit es nicht zu Missverständnissen kommt: Wir haben eine DMZ für unsere EXTERNEN Dienste welche wir Veröffentlichen bzw. welche über eine Öffentliche IP Erreichbar sind und wir haben eine Externe/INTERNE DMZ wo die Services für unsere Mitarbeiter ( derzeit per VPN ) bzw. Kunden terminieren. Das ganze ist wegen der ganzen Sicherheitseinstellungen bzw. Bereichen.....
Weitere Fragen :
1. Wie verhält es sich mich der Anmeldung wenn kein WLAN verfügbar ist ?
Ich bin nämlich am Überlegen das ich die Cached Credentials auf 1 oder max. 2 Benutzer zu stellen weil ich mach ja wenn ich eine WLAN / LAN Verbindung habe alles gegen den AD authentifiziert wird. 1 oder 2 gesp. Kennwörter nur für den Fall das keine Verbindung aufgebaut werden kann. Bzw. wenn kein WLAN dann müssen die Benutzer übers Handy via Teathering eine Verbindung aufbauen.
2. Homeoffice sollte keine Probleme geben da hier ja mind. WLAN vorhanden ist. Für die HO Only User könnte ich die Cached Cred. rein theoretisch sogar ganz abschalten da ja über den Tunnel immer eine Auth. gegen den AD statfinden kann. Ist das empfehlenswert das auf 0 oder 1 gesp. PW. setzen ?
3. Was ich jetzt gesehen habe ich das sich der NPS gleich mit Installiert wenn ich das Always ON VPN gem. Artikel von MS durcharbeite. Wir haben allerdings schon ein NPS Cluster für´s WLAN und für unsere 802.1x Auth. für die LAN Ports ( hier und DA wo die Dinger öffentlich zugänglich sind. Kann ich das so umbiegen das hier kein NPS mit installiert/konfiguriert wird ?
4. IPv6 wird angeblich nicht benötigt bzw. das ganze soll gem. diverser Gegenüberstellungen von Direct Access / Always On VPN nicht benötigt werden. Hingegen gibt es wohl Fehler wenn die/der DNS nicht per IPv6 erreichbar ist. IPv6 ist derzeit bei uns gerade erst in der Einführung***
Die Firewallfragen habe ich ja schon oben gestellt.
Wie gesagt ich bin erst am Anfang der ganzen Sache und arbeite mich da erstmal langsam ein. Nächster Schritt wäre dann eine Testumgebung. GGF. lass ich das aus Zeitgründen einen Dienstleister umsetzen aber es ist doch schon schön zu wissen wie es Funktioniert und was wo wie gemacht werden muss um mit dem DL über das richtige zu sprechen. Bringt mir ja nix wenn ich dem DL sage mach mal Always On VPN und der macht dann irgendwas und ich habe keinen Dunst Ziel ist es ja das ganze dann später selber zu betreiben und da muss man u.U. schon wissen wie es Aufgesetzt wird bzw. ist.
Aufbau der Testumgebung folt dann als zweiter Schritt wenn ich meine Fragen geklärt habe und einen POC erstellt habe.
Ich würde dann sogar eine Anleitung hier Posten was ich alles gemacht habe, vielleicht hilft es ja jemand anderem.
Bei der Testumgebung würde ich mich erstmals auf das Minimum beschränken und dann nach und nach erweitern. Mit erweitern meine ich zum Bsp. das ich einen zweiten RRAS GW Server hinzufügen würde / Azure Traffic Management + weiterer NPS usw......
Zu IPv6:
Da wir ein Teil eines größeren Konzerns sind muss ich mich leider an gewisse Standards halten welche mir / uns als IT vor Ort vorgegeben wird. IPv6 ist derzeit in der Erprobung bevor das ganze dann wohl gegen ende 2023 / Anfang - Mitte 2024 im Bereich Core Infrastruktur ( DC und weitere Infrastruktur Dienste wie Fileserver etc ... ) eingeführt werden soll. Ist die Vorgabe von oben. Finde ich auch Kacke- bin hier derzeit mächtig am revoltieren aber ist wohl von Oben nicht gewünscht und gibt Ärger wenn ich´s trotzdem einfach so mache. Angeblich kann die Security Software mit IPv6 nicht anfangen und deswegen würden sich hier Sicherheitslücken auftun so wurde mir gesagt.
Wenn ich Zwangsläufig v6 brauche dann habe ich ein Argument das ich es bei uns begrenzt einführen darf.
Begrenzt heißt dann nur da wo es wirklich gebraucht wird wie auf den DC´s / NPS / RRAS / Fileserver(n) / Webserver(n) halt alles was per Always On VPN erreichbar sein soll & muss + eben die Backend Systeme welche für den Betrieb benötigt werden wie eben ein DC welcher für die Authentifizierung für das TS Gateway oder VPN Einwahl benötigt wird usw....
Huhi war das wieder viel Text......... soviel wolltew ich eigentlich nicht schreiben aber ich denke es erklärt so besser das vorhaben bzw. das Problem. Falls ich was vergessen haben sollte einfach nachfragen ich ergänze das dann.
schon mal vielen dank an an @2423392070 und @Dani für die schnelle und unkomplizierte Antwort.
Das ganze liest sich schon mal sehr gut und da es ja bei MS dabei ist sind keine Extra Lizenzen ( klar CAL und Server Lizenzen bzw. Clientlizenzen bracuh ich schon oder ggf. je nach Setup einen Ext. Connector .... ) bzw die Wartung ist über die SA sowieso schon bezahlt.
Zitat von @Mr-Gustav:
- Wie stelle ich sicher das bei der Einwahl geprüft wird ob auf dem System ein AV installiert ist
Das war doof formuliert. Ich meinte eher so eine Art Device Health Attestation weil das macht der jetzige F5 Big IP Edge Client... aber wenn das nicht geht dann ist es halt nicht möglich oder ich muss was mit dem NPS basteln
Wenn ich das jetzt alles mal so grob richtig verstanden habe ( Teils eure Antworten / Teil Technet Artikel ) dann bau ich das Ganze in etwa wie folgt auf:
2 x RRAS Server als Gateway ( Verschiedene Anschlüssen wenns geht mit unters. IP´s
1 x Azure Trafic Manager für die Erreichbarkeit welcher dann von AOVPN.firma.de auf rrasg01 od raasgw02.firma.de
weiterleitet wenn das eine defekt bzw. nicht erreichbar ist oder ich schenke mir den Quatsch mit den Traffic Manager und mach gleich Multipathing mit 2 RRAS Servern. Sprich der Client baut gleich 2 Verbindungen zum Always On VPN auf ?
Entsprechend dann durch die Firewall terminieren ( siehe unten ) und für die Clients dann die Zertifikate bzw. Konfiguration über eine / mehrere GPO je nach Anforderungen.....
Wir haben jetzt allerdings auch Notebooks welche kein LTE / 5G Modem haben. Hier würden die Benutzer sich dann erst beim WLAN einloggen wenns denn ohne Portal Seite ist bzw. wenn es eine Portal Seite gibt, auf der man die AGB anklicken muss, dann würden die Benutzer sich dann mit den cached Cred. am Gerät anmelden und anschließend die Verbindung übers WLAN ( Portalseite ) herstellen und dann würde der Tunnel aufgebaut ? Also sozusagen das der Tunnelaufbau erst nach der Anmeldung erfolgt. Alternativ müssen die User ihr Handy benutzen und dann entsprechend darüber arbeiten denn da muss nur der PSK eingegeben werden und alles ist gut.
Wie habt Ihr die RRAS Kisten abgesichert ? Firewall davor ( in unserem Fall ASA´s ) und dann die Ports gem. Technet für AOVPN freigegeben oder brauchts hier noch irgendein MS Proxy Dienst wie den Web Application Proxy ?
Ich würde die RRAS durch die DMZ Firewall erreichbar machen so das die VPN Tunnel dann in der DMZ terminieren und von da aus dann entsprechend weiter dürfen. und von da geht´s dann weiter
Fürs Verständnis und damit es nicht zu Missverständnissen kommt: Wir haben eine DMZ für unsere EXTERNEN Dienste welche wir Veröffentlichen bzw. welche über eine Öffentliche IP Erreichbar sind und wir haben eine Externe/INTERNE DMZ wo die Services für unsere Mitarbeiter ( derzeit per VPN ) bzw. Kunden terminieren. Das ganze ist wegen der ganzen Sicherheitseinstellungen bzw. Bereichen.....
Weitere Fragen :
1. Wie verhält es sich mich der Anmeldung wenn kein WLAN verfügbar ist ?
Ich bin nämlich am Überlegen das ich die Cached Credentials auf 1 oder max. 2 Benutzer zu stellen weil ich mach ja wenn ich eine WLAN / LAN Verbindung habe alles gegen den AD authentifiziert wird. 1 oder 2 gesp. Kennwörter nur für den Fall das keine Verbindung aufgebaut werden kann. Bzw. wenn kein WLAN dann müssen die Benutzer übers Handy via Teathering eine Verbindung aufbauen.
2. Homeoffice sollte keine Probleme geben da hier ja mind. WLAN vorhanden ist. Für die HO Only User könnte ich die Cached Cred. rein theoretisch sogar ganz abschalten da ja über den Tunnel immer eine Auth. gegen den AD statfinden kann. Ist das empfehlenswert das auf 0 oder 1 gesp. PW. setzen ?
3. Was ich jetzt gesehen habe ich das sich der NPS gleich mit Installiert wenn ich das Always ON VPN gem. Artikel von MS durcharbeite. Wir haben allerdings schon ein NPS Cluster für´s WLAN und für unsere 802.1x Auth. für die LAN Ports ( hier und DA wo die Dinger öffentlich zugänglich sind. Kann ich das so umbiegen das hier kein NPS mit installiert/konfiguriert wird ?
4. IPv6 wird angeblich nicht benötigt bzw. das ganze soll gem. diverser Gegenüberstellungen von Direct Access / Always On VPN nicht benötigt werden. Hingegen gibt es wohl Fehler wenn die/der DNS nicht per IPv6 erreichbar ist. IPv6 ist derzeit bei uns gerade erst in der Einführung***
Die Firewallfragen habe ich ja schon oben gestellt.
Wie gesagt ich bin erst am Anfang der ganzen Sache und arbeite mich da erstmal langsam ein. Nächster Schritt wäre dann eine Testumgebung. GGF. lass ich das aus Zeitgründen einen Dienstleister umsetzen aber es ist doch schon schön zu wissen wie es Funktioniert und was wo wie gemacht werden muss um mit dem DL über das richtige zu sprechen. Bringt mir ja nix wenn ich dem DL sage mach mal Always On VPN und der macht dann irgendwas und ich habe keinen Dunst
Ziel ist es ja das ganze dann später selber zu betreiben und da muss man u.U. schon wissen wie es Aufgesetzt wird bzw. ist.Aufbau der Testumgebung folt dann als zweiter Schritt wenn ich meine Fragen geklärt habe und einen POC erstellt habe.
Ich würde dann sogar eine Anleitung hier Posten was ich alles gemacht habe, vielleicht hilft es ja jemand anderem.
Bei der Testumgebung würde ich mich erstmals auf das Minimum beschränken und dann nach und nach erweitern. Mit erweitern meine ich zum Bsp. das ich einen zweiten RRAS GW Server hinzufügen würde / Azure Traffic Management + weiterer NPS usw......
Zu IPv6:
Da wir ein Teil eines größeren Konzerns sind muss ich mich leider an gewisse Standards halten welche mir / uns als IT vor Ort vorgegeben wird. IPv6 ist derzeit in der Erprobung bevor das ganze dann wohl gegen ende 2023 / Anfang - Mitte 2024 im Bereich Core Infrastruktur ( DC und weitere Infrastruktur Dienste wie Fileserver etc ... ) eingeführt werden soll. Ist die Vorgabe von oben. Finde ich auch Kacke- bin hier derzeit mächtig am revoltieren aber ist wohl von Oben nicht gewünscht und gibt Ärger wenn ich´s trotzdem einfach so mache. Angeblich kann die Security Software mit IPv6 nicht anfangen und deswegen würden sich hier Sicherheitslücken auftun so wurde mir gesagt.
Wenn ich Zwangsläufig v6 brauche dann habe ich ein Argument das ich es bei uns begrenzt einführen darf.
Begrenzt heißt dann nur da wo es wirklich gebraucht wird wie auf den DC´s / NPS / RRAS / Fileserver(n) / Webserver(n) halt alles was per Always On VPN erreichbar sein soll & muss + eben die Backend Systeme welche für den Betrieb benötigt werden wie eben ein DC welcher für die Authentifizierung für das TS Gateway oder VPN Einwahl benötigt wird usw....
Huhi war das wieder viel Text......... soviel wolltew ich eigentlich nicht schreiben aber ich denke es erklärt so besser das vorhaben bzw. das Problem. Falls ich was vergessen haben sollte einfach nachfragen ich ergänze das dann.
Moin,
Wir haben das soweit getrieben, dass wir z.B. bei Paketloss oder bei hoher Auslastung über die API Nodes auf dem Traffic Manager nehmen.
Was du bisher ignoriert hast, ist das Thema PKI - Zertifikate, Vorlagen und Veröffentlichung von Sperrlisten. Das ist nicht von der Hand zuweisen und vermutlich wird das am meisten Planung, Zeit, Nerven und Wartung brauchen.
Gruß,
Dani
Das ganze liest sich schon mal sehr gut und da es ja bei MS dabei ist sind keine Extra Lizenzen ( klar CAL und Server Lizenzen bzw. Clientlizenzen bracuh ich schon oder ggf. je nach Setup einen Ext. Connector .... ) bzw die Wartung ist über die SA sowieso schon bezahlt.
Du brauchst für Device Tunnels auf den Clients Windows Enterprise. Je nach Lizenzierung hast du die schon. Weitere CALS oder external Connectors wie bei IIS ist nicht erforderlich.1 x Azure Trafic Manager für die Erreichbarkeit welcher dann von AOVPN.firma.de auf rrasg01 od raasgw02.firma.de
weiterleitet wenn das eine defekt bzw. nicht erreichbar ist oder ich schenke mir den Quatsch mit den Traffic Manager und mach gleich Multipathing mit 2 RRAS Servern.Wir haben das soweit getrieben, dass wir z.B. bei Paketloss oder bei hoher Auslastung über die API Nodes auf dem Traffic Manager nehmen.
Also sozusagen das der Tunnelaufbau erst nach der Anmeldung erfolgt. Alternativ müssen die User ihr Handy benutzen und dann entsprechend darüber arbeiten denn da muss nur der PSK eingegeben werden und alles ist gut.
Genau. Man kann die AWONVPN KOnfiguration soweit treiben, dass sobald eine Internetverbindung besteht der Device Tunnel aufgebaut wird. Das kann der User dann auch nicht mehr verhindern.Wie habt Ihr die RRAS Kisten abgesichert ?
Klassische Firewall + WAF mit einem entsprechenden Regelwerk.und dann die Ports gem. Technet für AOVPN freigegeben oder brauchts hier noch irgendein MS Proxy Dienst wie den Web Application Proxy ?
Nein, braucht keine weitere Komponenten.Ich würde die RRAS durch die DMZ Firewall erreichbar machen so das die VPN Tunnel dann in der DMZ terminieren und von da aus dann entsprechend weiter dürfen. und von da geht´s dann weiter
Passst aus meiner Sicht.1. Wie verhält es sich mich der Anmeldung wenn kein WLAN verfügbar ist ?
Wenn die Anmeldedaten in Cache liegen, funktioniert die Anmeldung auch ohne Tunnel.2. Homeoffice sollte keine Probleme geben da hier ja mind. WLAN vorhanden ist. Für die HO Only User könnte ich die Cached Cred.
Wir haben daran nicht verändert. Denn evtl. ändert sich doch mal ein Umstand und dann bist du froh wenn der User nicht gleich den Service Desk auseinander nimmt.Wir haben allerdings schon ein NPS Cluster für´s WLAN und für unsere 802.1x Auth. für die LAN Ports ( hier und DA wo die Dinger öffentlich zugänglich sind. Kann ich das so umbiegen das hier kein NPS mit installiert/konfiguriert wird ?
Das ist möglich. Wobei zu überlegen ist, ob bei der deiner Definition von interner und externer DMZ, dass so in euer Rahmen passt.Hingegen gibt es wohl Fehler wenn die/der DNS nicht per IPv6 erreichbar ist. IPv6 ist derzeit bei uns gerade erst in der Einführung***
Kann ich nichts dazu sagen, weil wir von Anfang an DualStack bereitstellen. Zumal in der Pandemie über IPv6 die Performance immer gut war. Hingegen bei IPv4 anfangs öfters Übergänge zu ISP überlastet waren.Bei der Testumgebung würde ich mich erstmals auf das Minimum beschränken und dann nach und nach erweitern.
Eine Testumgebung ist eine Testumgebung. Die brauchst du später wieder wenn du ein produktive Umgebung hast. Denn gerade das Zeugs mit den ganzen Zertifikaten würde ich niemals Live ausprobieren. Die Chance dass sich keiner mehr einwählen kann ist groß. Was du bisher ignoriert hast, ist das Thema PKI - Zertifikate, Vorlagen und Veröffentlichung von Sperrlisten. Das ist nicht von der Hand zuweisen und vermutlich wird das am meisten Planung, Zeit, Nerven und Wartung brauchen.
Gruß,
Dani
Hallo @Dani,
erstmal vielen dank dafür das du dir die Zeitgenommen hast um mir so ausführlich zu antworten. Ist ja heute nicht mehr alles selbstverständlich. Daher hier ein dickes Lob von mir. das gleiche gilt natürlich auch für den Kollegen @2423392070
PKI ist vorhanden. Wird intern reichlich genutzt.
Sperrlisten werden bereits online veröffentlicht.
Wir haben eine mehrstufige PKI vom Konzern vorgegeben.
Der Vorteil ist ja das wir schon eine PKI haben welche wir dann nur noch passend einarbeiten müssen.
Allerdings überlege ich ob wir nicht lieber eine eigene CA in unsere Umgebung integrieren damit wir hier komplett alles selber verwalten können ohne das der Konzern da rein spuckt. Aber ich denke das ist etwas viel und wir sollten eine von den vorhandenen CA´s nehmen vorzugsweise die wo auch 802.1x für LAN/WLAN macht .
Übersicht über die CA siehe am Ende
Wunderbar. Geld gespart bzw aus Kaufm. Sicht ein +1 für die Always On VPN Lösung . Windows 10 / 11 Enterprise haben wir im Einsatz für die Notebooks alleine wegen Bitlocker und Applocker. Von daher passt das alles. Einige Geräte sind über MS365 lizenziert und da ist Always On VPN mit drin.
Ich denke wir machen das dann mit 2 RRAS GW Servern an zwei Standorten, sprich wir haben dann 4 Stück im Einsatz. 2 x in DE und 2 in NL. Sollte also keine Probleme geben. Entsprechende GPO´s gesetzt und gut ist.
Werde ich testen in der Testumgebung. Dafür ist die ja da
Und weiter lesen im Technet was da benötigt wird. Ich denke so schnell bekomme ich kein IPv6 Netzwerk ( /56 od. größer )
Okay das macht Sinn zumindest für die User. Der Vorteil ist das jeder MA seinen eigenen Laptop hat und somit eigentlich nur einmal Zugangsdaten ( Pers. Zugangsdaten des Hauptnutzers ) speichern müsste. Würde die Sicherheit erhöhen. max. 2 Cred. cachen. Admins werden sowieso nicht gespeichert. Dom Admins / Server Admins etc... können sich eh nicht anmelden.
Stimmt auch wieder. Lizenzen haben wir eigentlich nug weil Datacenter und Leistung sowieso.
Dann die zwei NPS in die Interne DMZ packen und gut ist.
Der Kollege meinte jetzt noch mit den NPS in der Internen DMZ dann gegen die Internen NPS authentifizieren lassen und die dann gegen einen RODC.
RRAS Server --Firewall 1--> NPS Server ( Int. DMZ ) --Firewall 2--> NPS Server Intern --> RODC --> AD Struktur
Wobei ich das etwas doll finde. NPS gegen ROD seh ich ja noch ein aber NPS gegen NPS und dann noch gegen RODC. Ich weiß nicht. Das ganze macht es nur noch schwieriger was das debugging angeht.
Macht Sinn und nimmt den Druck raus wenn mal was in der Testumgebung nicht geht. Wenns Prod. System nicht geht dann heißt es Übersstunden bis alles wieder geht. Ich denke eine Testumgebung ist hier mehr oder weniger Pflicht. Wir haben bereits mehrere Umgebungen in unserem LAB für den Sharepoint / Datacore / ESX usw.... Immer gut wenn man ein Update Testen will. Erst die Updates in der Testumgebung einspielen und dann 2 bis 4 Wochen später bei der Prod. Umgebung. Die Clients hingegn testen wir in 3er Gruppen "live" erst die Admins ( nicht alle ) dann die KeyUser ( Ausgewählt Benutzer ) und dann die restlichen. Jeweils immer 2 Wochen Abstand
Überblick der groben Struktur :
KONZERN CA @
Offline Root CA [Konzern]
#> Intermediate CA [Konzern]
#>>>>>Devision CA [Konzern - Division ]
#>>>>>>>Company CA [ hier geht für uns los ]
#>>>>>>>>>>Standard CA med. Sec (Computer / User / EFS / Mail / etc....
#>>>>>>>>>>High Sec CA ( Wichtige Server
#>>>>>>>>>>802.1x für LAN und WLAN
#>>>>>>>>>>CA für Codesigning / Entwicklung / Programme etc....
#>>>>>>>>>>CA Reserve / Test / alles was sonst nirgens passt
Eigene CA ohne Konzernanbindung
Offline Root CA
#>Intermediate CA
#>>>>CA 1 Entwicklung
#>>>>CA 2 Testumgebungen
Das ganze ist eine grobe Übersicht. Ab Punkt 4 gehts dann für uns los.
erstmal vielen dank dafür das du dir die Zeitgenommen hast um mir so ausführlich zu antworten. Ist ja heute nicht mehr alles selbstverständlich. Daher hier ein dickes Lob von mir. das gleiche gilt natürlich auch für den Kollegen @2423392070
Zitat von @Dani:
Was du bisher ignoriert hast, ist das Thema PKI - Zertifikate, Vorlagen und Veröffentlichung von Sperrlisten. Das ist nicht von der Hand zuweisen und vermutlich wird das am meisten Planung, Zeit, Nerven und Wartung brauchen.
Was du bisher ignoriert hast, ist das Thema PKI - Zertifikate, Vorlagen und Veröffentlichung von Sperrlisten. Das ist nicht von der Hand zuweisen und vermutlich wird das am meisten Planung, Zeit, Nerven und Wartung brauchen.
PKI ist vorhanden. Wird intern reichlich genutzt.
Sperrlisten werden bereits online veröffentlicht.
Wir haben eine mehrstufige PKI vom Konzern vorgegeben.
Der Vorteil ist ja das wir schon eine PKI haben welche wir dann nur noch passend einarbeiten müssen.
Allerdings überlege ich ob wir nicht lieber eine eigene CA in unsere Umgebung integrieren damit wir hier komplett alles selber verwalten können ohne das der Konzern da rein spuckt. Aber ich denke das ist etwas viel und wir sollten eine von den vorhandenen CA´s nehmen vorzugsweise die wo auch 802.1x für LAN/WLAN macht .
Übersicht über die CA siehe am Ende
Das ganze liest sich schon mal sehr gut und da es ja bei MS dabei ist sind keine Extra Lizenzen ( klar CAL und Server Lizenzen bzw. Client Lizenzen brauch ich schon oder ggf. je nach Setup einen Ext. Connector .... ) bzw die Wartung ist über die SA sowieso schon bezahlt.
Du brauchst für Device Tunnels auf den Clients Windows Enterprise. Je nach Lizenzierung hast du die schon. Weitere CALS oder external Connectors wie bei IIS ist nicht erforderlich.
Wunderbar. Geld gespart
bzw aus Kaufm. Sicht ein +1 für die Always On VPN Lösung . Windows 10 / 11 Enterprise haben wir im Einsatz für die Notebooks alleine wegen Bitlocker und Applocker. Von daher passt das alles. Einige Geräte sind über MS365 lizenziert und da ist Always On VPN mit drin.1 x Azure Trafic Manager für die Erreichbarkeit welcher dann von AOVPN.firma.de auf rrasg01 od raasgw02.firma.de
weiterleitet wenn das eine defekt bzw. nicht erreichbar ist oder ich schenke mir den Quatsch mit den Traffic Manager und mach gleich Multipathing mit 2 RRAS Servern.
Ich denke wir machen das dann mit 2 RRAS GW Servern an zwei Standorten, sprich wir haben dann 4 Stück im Einsatz. 2 x in DE und 2 in NL. Sollte also keine Probleme geben. Entsprechende GPO´s gesetzt und gut ist.
Hingegen gibt es wohl Fehler wenn die/der DNS nicht per IPv6 erreichbar ist. IPv6 ist derzeit bei uns gerade erst in der Einführung
Kann ich nichts dazu sagen, weil wir von Anfang an DualStack bereitstellen. Zumal in der Pandemie über IPv6 die Performance immer gut war. Hingegen bei IPv4 anfangs öfters Übergänge zu ISP überlastet waren.
Werde ich testen in der Testumgebung. Dafür ist die ja da
Und weiter lesen im Technet was da benötigt wird. Ich denke so schnell bekomme ich kein IPv6 Netzwerk ( /56 od. größer )
Homeoffice sollte keine Probleme geben da hier ja mind. WLAN vorhanden ist. Für die HO Only User könnte ich die Cached Cred.
Wir haben daran nicht verändert. Denn evtl. ändert sich doch mal ein Umstand und dann bist du froh wenn der User nicht gleich den Service Desk auseinander nimmt.
Okay das macht Sinn zumindest für die User. Der Vorteil ist das jeder MA seinen eigenen Laptop hat und somit eigentlich nur einmal Zugangsdaten ( Pers. Zugangsdaten des Hauptnutzers ) speichern müsste. Würde die Sicherheit erhöhen. max. 2 Cred. cachen. Admins werden sowieso nicht gespeichert. Dom Admins / Server Admins etc... können sich eh nicht anmelden.
Wir haben allerdings schon ein NPS Cluster für´s WLAN und für unsere 802.1x Auth. für die LAN Ports ( hier und DA wo die Dinger öffentlich zugänglich sind. Kann ich das so umbiegen das hier kein NPS mit installiert/konfiguriert wird ?
Das ist möglich. Wobei zu überlegen ist, ob bei der deiner Definition von interner und externer DMZ, dass so in euer Rahmen passt.
Stimmt auch wieder. Lizenzen haben wir eigentlich nug weil Datacenter und Leistung sowieso.
Dann die zwei NPS in die Interne DMZ packen und gut ist.
Der Kollege meinte jetzt noch mit den NPS in der Internen DMZ dann gegen die Internen NPS authentifizieren lassen und die dann gegen einen RODC.
RRAS Server --Firewall 1--> NPS Server ( Int. DMZ ) --Firewall 2--> NPS Server Intern --> RODC --> AD Struktur
Wobei ich das etwas doll finde. NPS gegen ROD seh ich ja noch ein aber NPS gegen NPS und dann noch gegen RODC. Ich weiß nicht. Das ganze macht es nur noch schwieriger was das debugging angeht.
Bei der Testumgebung würde ich mich erstmals auf das Minimum beschränken und dann nach und nach erweitern.
Eine Testumgebung ist eine Testumgebung. Die brauchst du später wieder wenn du ein produktive Umgebung hast. Denn gerade das Zeugs mit den ganzen Zertifikaten würde ich niemals Live ausprobieren. Die Chance dass sich keiner mehr einwählen kann ist groß.
Macht Sinn und nimmt den Druck raus wenn mal was in der Testumgebung nicht geht. Wenns Prod. System nicht geht dann heißt es Übersstunden bis alles wieder geht. Ich denke eine Testumgebung ist hier mehr oder weniger Pflicht. Wir haben bereits mehrere Umgebungen in unserem LAB für den Sharepoint / Datacore / ESX usw.... Immer gut wenn man ein Update Testen will. Erst die Updates in der Testumgebung einspielen und dann 2 bis 4 Wochen später bei der Prod. Umgebung. Die Clients hingegn testen wir in 3er Gruppen "live" erst die Admins ( nicht alle ) dann die KeyUser ( Ausgewählt Benutzer ) und dann die restlichen. Jeweils immer 2 Wochen Abstand
Überblick der groben Struktur :
KONZERN CA @
Offline Root CA [Konzern]
#> Intermediate CA [Konzern]
#>>>>>Devision CA [Konzern - Division ]
#>>>>>>>Company CA [ hier geht für uns los ]
#>>>>>>>>>>Standard CA med. Sec (Computer / User / EFS / Mail / etc....
#>>>>>>>>>>High Sec CA ( Wichtige Server
#>>>>>>>>>>802.1x für LAN und WLAN
#>>>>>>>>>>CA für Codesigning / Entwicklung / Programme etc....
#>>>>>>>>>>CA Reserve / Test / alles was sonst nirgens passt
Eigene CA ohne Konzernanbindung
Offline Root CA
#>Intermediate CA
#>>>>CA 1 Entwicklung
#>>>>CA 2 Testumgebungen
Das ganze ist eine grobe Übersicht. Ab Punkt 4 gehts dann für uns los.
IPv6 bringt nicht zu unterschätzende Vorteile.
Natives IPv6 am Client bis zum Gateway ist wirklich eine feine Sache. Wenn die Bandbreiten und Latenzen stimmen ist das wie arbeiten im LAN/WiFi.
Ich würde Konsequent eine v4/v6 Dual-Konstrukt bauen. Dafür ist nur eine IPv6 Adresse nötig pro Gateway-Server.
Und immer ein Blick auf Richard haben: https://directaccess.richardhicks.com/2022/07/25/whats-new-in-always-on- ...
Natives IPv6 am Client bis zum Gateway ist wirklich eine feine Sache. Wenn die Bandbreiten und Latenzen stimmen ist das wie arbeiten im LAN/WiFi.
Ich würde Konsequent eine v4/v6 Dual-Konstrukt bauen. Dafür ist nur eine IPv6 Adresse nötig pro Gateway-Server.
Und immer ein Blick auf Richard haben: https://directaccess.richardhicks.com/2022/07/25/whats-new-in-always-on- ...
Moin,
Gruß,
Dani
Allerdings überlege ich ob wir nicht lieber eine eigene CA in unsere Umgebung integrieren damit wir hier komplett alles selber verwalten können ohne das der Konzern da rein spuckt. Aber ich denke das ist etwas viel und wir sollten eine von den vorhandenen CA´s nehmen vorzugsweise die wo auch 802.1x für LAN/WLAN macht .
Naja, grundsätzlich bin ich ein Freund sich an Vorgaben und Policies zu halten, wenn es diese gibt.Dann die zwei NPS in die Interne DMZ packen und gut ist.
Vorsicht... du wirst die NPS vermutlich im AD registrieren müssen. Das hängt ein bisschen vom Design und den Anforderungen ab.Der Kollege meinte jetzt noch mit den NPS in der Internen DMZ dann gegen die Internen NPS authentifizieren lassen und die dann gegen einen RODC.
Auch hier gibt es kein Ja und Nein von mir. Es hängt vom Design ab. Denn auch RODC benötigt Löcher in der Firewall. Vermutlich mehr als dir lieb ist. Da wird es doch sicherlich jemanden im Konzern geben, der euch da optimal beraten kann.Überblick der groben Struktur :
die Struktur kommt mir sehr bekannt vor... könnte 1:1 unsere sein. *huch*Gruß,
Dani
Schon mal vielen vielen dank euch zwei für die hilfreichen antworten.
Ich werde dann mal eine Testumgebung aufbauen und schauen wo es hängt oder auch nicht.
Das mit dem NPS und den RODC in der DMZ oder davor oder NPS in der DMZ und der RODC im LAN usw....
werde ich mal durch den Kopf gehen lassen.
Es gibt natürlich, wie überall, vor und Nachteile hier und da je nach Ausführung
Bezüglich den Standard welches es im Konzern gibt...... Nun ja die betreffen fast alle nur Port 443 bzw. in seltenen Fälle auch mal Port 80. Das geht alles über einen Reverse proxy welcher ZENTRAL in FFM betrieben wird. Die Anmeldung findet dann in der Anwendung an sich statt. SAP Systeme halt bzw. SAP FIORI Mischung. Auth geschickt ins Backend ausgelagert so das die Probleme hier nicht entstehen,
Ich bin alles relativ alleine auf weiter Flur
Ich werde aber mal versuchen den RRAS und den NPS in die DMZ ( internal DMZ ) zu stellen und die Auth dann gegen einen RODC im LAN ( Server Lan ) machen zu lassen. Mal sehen wie das Funktioniert. Die Alternative wäre aber das ich die RAS GW´s in die DMZ packe und hier per Radius gegen den NPS im LAN ( Server LAN ) autrh. lasse.
Für das LAN welches von der DMZ aus abgefragt wird gibt es noch die Besonderheit das es sich hier um ein eigenes LAN Segment handelt welches extra für die Server in der DMZ ( intern ) erstellt wurde. Hier sollen alle Systeme aus der DMZ ( Intern ) Ihre Anfragen hin senden und von hier aus gehts dann weiter. Ein Client bzw die Anfrage muss also durch die erste DMZ / WAN Firewall - dann zum RAS GW Server und von da aus dann durch die LAN Firewall ( Backend LAN ) zum NPS Server. Wenn die Anfrage hier ist angekommen ist dann fragt der NPS gegen den RODC ab und der wiederum muss nochmals durch eine ( High Sec ) ( Interface auf der Firewall ) Firewall welche sehr sehr restriktiv iist weil hier die DC´s stehen.
Mal sehen was wir da umsetzen. das ganze darf auch nicht zu Kompliziert werden so das man hinterher im Fehlerfalle einen ganzen Tag braucht für das debugging. So sicher wie geht aber noch bedienbar bzw. debuggbar ist das Ziel.
Wireshark ich Komme >Gleich mal ein Paar Ports fürs Monitoring via Wireshark freischalten lassen Die Netzwerker werden sich freuen
Ich werde dann mal eine Testumgebung aufbauen
und schauen wo es hängt oder auch nicht.Das mit dem NPS und den RODC in der DMZ oder davor oder NPS in der DMZ und der RODC im LAN usw....
werde ich mal durch den Kopf gehen lassen.
Es gibt natürlich, wie überall, vor und Nachteile hier und da je nach Ausführung
Bezüglich den Standard welches es im Konzern gibt...... Nun ja die betreffen fast alle nur Port 443 bzw. in seltenen Fälle auch mal Port 80. Das geht alles über einen Reverse proxy welcher ZENTRAL in FFM betrieben wird. Die Anmeldung findet dann in der Anwendung an sich statt. SAP Systeme halt bzw. SAP FIORI Mischung. Auth geschickt ins Backend ausgelagert so das die Probleme hier nicht entstehen,
Ich bin alles relativ alleine auf weiter Flur
Ich werde aber mal versuchen den RRAS und den NPS in die DMZ ( internal DMZ ) zu stellen und die Auth dann gegen einen RODC im LAN ( Server Lan ) machen zu lassen. Mal sehen wie das Funktioniert. Die Alternative wäre aber das ich die RAS GW´s in die DMZ packe und hier per Radius gegen den NPS im LAN ( Server LAN ) autrh. lasse.
Für das LAN welches von der DMZ aus abgefragt wird gibt es noch die Besonderheit das es sich hier um ein eigenes LAN Segment handelt welches extra für die Server in der DMZ ( intern ) erstellt wurde. Hier sollen alle Systeme aus der DMZ ( Intern ) Ihre Anfragen hin senden und von hier aus gehts dann weiter. Ein Client bzw die Anfrage muss also durch die erste DMZ / WAN Firewall - dann zum RAS GW Server und von da aus dann durch die LAN Firewall ( Backend LAN ) zum NPS Server. Wenn die Anfrage hier ist angekommen ist dann fragt der NPS gegen den RODC ab und der wiederum muss nochmals durch eine ( High Sec ) ( Interface auf der Firewall ) Firewall welche sehr sehr restriktiv iist weil hier die DC´s stehen.
Mal sehen was wir da umsetzen. das ganze darf auch nicht zu Kompliziert werden so das man hinterher im Fehlerfalle einen ganzen Tag braucht für das debugging. So sicher wie geht aber noch bedienbar bzw. debuggbar ist das Ziel.
Wireshark ich Komme
>Gleich mal ein Paar Ports fürs Monitoring via Wireshark freischalten lassen Die Netzwerker werden sich freuen
Moin,
Gruß,
Dani
Ich werde aber mal versuchen den RRAS und den NPS in die DMZ ( internal DMZ ) zu stellen und die Auth dann gegen einen RODC im LAN ( Server Lan ) machen zu lassen.
Du machst ein Fass bezüglich Sicherheit auf und ein Pseudo LDAP Proxy ala RODC steht im LAN? Sorry. Wenn du so viel Wert auf Sicherheit legst, sollte du einen LDAP Proxy wenden (z.B AD LDS oder LDAP Proxy) in der (Internal DMZ) verwenden.Die Alternative wäre aber das ich die RAS GW´s in die DMZ packe und hier per Radius gegen den NPS im LAN ( Server LAN ) autrh. lasse.
Aber doch nicht ohne Load Balancer und WAF?!Mal sehen was wir da umsetzen. das ganze darf auch nicht zu Kompliziert werden so das man hinterher im Fehlerfalle einen ganzen Tag braucht für das debugging.
Hängt davon ab wie hoch das Thema Sicherheit eingestuft wird. Falls wir beide im selben Konzern arbeiten, kenn ich bereits die Antwort - hoch. Gruß,
Dani
Aber doch nicht ohne Load Balancer und WAF?!
Sicher doch
Wobei ich mal schauen muss ob ich das für eine Testumgebung durch bekommeweil ist ja nur eine Testumgebung. Ich hätte natürlich lieber ein Load.Bal. Webapplikation Firewall
ist ebenfalls klar. Habe ich nur nicht mehr aktiv geschrieben weil es einfach gewisse Standards gibt die
eigentlich immer gelten wie Firewall / WAF usw......
Hängt davon ab wie hoch das Thema Sicherheit eingestuft wird. Falls wir beide im selben Konzern arbeiten, kenn ich bereits die Antwort - hoch
Wenns ein Stahlkonzern ist dann gut möglich - ja
Bzw. wenn die mir irgendwann alle auf den Sack gehen dann ist Feierabend mit Always On dann bekommen die wieder ihren Big IP Edge Client als one Click ( wofür einige zu doof sind ) und gut ist. Ist nicht mein Geld. Bevor ich hier über Jahre eine Genehmigung nach der anderen einholen muss ( wie auf dem Bauamt oder Finanzamt ) dann wird die alte Lösung einfach erneuert bevor ich wie bei Asterix und Obelix durchs "das Haus was verrückte macht" renne.
Ich glaube aber ich werde das ganze mal für mich zuhause in meinem LAB zusammenbauen und Privat testen.
WAF wegen SSTP?
IKEv2 braucht für Multipathing lediglich mehrere Einwahlpunkte in der Konfig.
Die WAF wird keine zusätzliche Sicherheit bringen.
IKEv2 braucht für Multipathing lediglich mehrere Einwahlpunkte in der Konfig.
Die WAF wird keine zusätzliche Sicherheit bringen.
