21
PfSense Routing von separaten OpenVPN-Tunneln
Hi Leute,
ich habe auf einer pfSense (OpenVPN Interface) 3 OVPN-Tunnel mit Port 1194, 1195, 1196
und unterschiedlichem IP-Range am laufen.
2 davon laufen im peer-to-peer Modus und verbinden die beiden remoten Netze
jeweils mit dem Server-LAN und der DMZ.
Der dritte Tunnel dient einem Client als Zugriff zum Server-LAN und läuft als Remote Access.
Zugriffe funktionieren in jeweils beide Richtungen problemlos.
Der Zugriff der remoten Standorte untereinander war und ist nicht geplant, sonst hätte ich
nur einen Tunnel im Multi-Client-Modus laufen.
Nun bin ich aber kurzfristig gezwungen vom Remoten-Client über Tunnel 3 auf
die pfSense und mein LAN zuzugreifen, was auch problemlos funktioniert.
Die Erreichbarkeit der 2 remoten Standorte ist aber leider eingeschränkt,
sie funktioniert nicht direkt vom Client aus.
Mit dem "Umweg" über die pfSense komme ich auch per ssh auf die remoten Clients der anderen Tunnel,
leider eben nicht direkt von Tunnel zu Tunnel.
Hat hier einer von Euch Erfahrung, ob und wie ein Routing mehrerer Tunnel über ein Interface
auf der pfSense hier überhaupt funktioniert.
Da ich in den nächsten Wochen aber nur über diesen Weg auf die pfSense komme,
kann ich mir keine großen, nicht fundierten Experimente erlauben, die mir dann zu guter letzt
meine Verbindung zur pfSense kappen.
Gruß & Danke orcape
ich habe auf einer pfSense (OpenVPN Interface) 3 OVPN-Tunnel mit Port 1194, 1195, 1196
und unterschiedlichem IP-Range am laufen.
2 davon laufen im peer-to-peer Modus und verbinden die beiden remoten Netze
jeweils mit dem Server-LAN und der DMZ.
Der dritte Tunnel dient einem Client als Zugriff zum Server-LAN und läuft als Remote Access.
Zugriffe funktionieren in jeweils beide Richtungen problemlos.
Der Zugriff der remoten Standorte untereinander war und ist nicht geplant, sonst hätte ich
nur einen Tunnel im Multi-Client-Modus laufen.
Nun bin ich aber kurzfristig gezwungen vom Remoten-Client über Tunnel 3 auf
die pfSense und mein LAN zuzugreifen, was auch problemlos funktioniert.
Die Erreichbarkeit der 2 remoten Standorte ist aber leider eingeschränkt,
sie funktioniert nicht direkt vom Client aus.
Mit dem "Umweg" über die pfSense komme ich auch per ssh auf die remoten Clients der anderen Tunnel,
leider eben nicht direkt von Tunnel zu Tunnel.
Hat hier einer von Euch Erfahrung, ob und wie ein Routing mehrerer Tunnel über ein Interface
auf der pfSense hier überhaupt funktioniert.
Da ich in den nächsten Wochen aber nur über diesen Weg auf die pfSense komme,
kann ich mir keine großen, nicht fundierten Experimente erlauben, die mir dann zu guter letzt
meine Verbindung zur pfSense kappen.
Gruß & Danke orcape
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: 228913
Url: https://administrator.de/contentid/228913
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
21 Kommentare
Neuester Kommentar
Hallo,
Erreichbarkeit Deiner VPN Verbindung zum Rest des Netzwerkes.
Richte doch einfach mal Routen in die anderen Netzwerke bzw.
auf die IP Ranges ein, damit Du dann auch dort hinein kommst.
Gruß
Dobby
und unterschiedlichem IP-Range am laufen.
Ich glaube dort liegt der Fehler, für die nur teilweiseErreichbarkeit Deiner VPN Verbindung zum Rest des Netzwerkes.
Richte doch einfach mal Routen in die anderen Netzwerke bzw.
auf die IP Ranges ein, damit Du dann auch dort hinein kommst.
Gruß
Dobby
Hi D.o.b.b.y,
Das sind 3 verschiedene Tunnel, die das pfSense interne LAN erreichen.
Es geht mir nur um die Verbindung vom VPN 3 zu den anderen beiden.
Da diese aber auf einem Interface liegen...
Eine Route hatte ich schon definiert, hat aber nicht den gewünschten Effekt.
Gruß orcape
Ich glaube dort liegt der Fehler, für die nur teilweise
Erreichbarkeit Deiner VPN Verbindung zum Rest des Netzwerkes.
Ich glaub Du interpretierst Da was verkehrt.Erreichbarkeit Deiner VPN Verbindung zum Rest des Netzwerkes.
Das sind 3 verschiedene Tunnel, die das pfSense interne LAN erreichen.
Es geht mir nur um die Verbindung vom VPN 3 zu den anderen beiden.
Da diese aber auf einem Interface liegen...
Eine Route hatte ich schon definiert, hat aber nicht den gewünschten Effekt.
Gruß orcape
Das sind 3 verschiedene Tunnel, die das pfSense interne LAN erreichen.
Ja aber jedes mit einem anderen IP Bereich, oder?Es geht mir nur um die Verbindung vom VPN 3 zu den anderen beiden.
Dann sollte die Route von eben diesem auf die anderen beiden abzielenoder aber man regelt (erlaubt den Zugriff) das mittels der Firewallregeln.
#grey| Gruß
Dobby##
Dann sollte die Route von eben diesem auf die anderen beiden abzielen
Zum erstellen einer Route müsste ich aber einen neuen Gateway festlegen.Für das virtuelle Interface "OpenVPN" lässt sich aber kein Gateway manuell erstellen.
Wenn ich hierzu die Tunnel-IP als Gateway verwende, bin ich mir nicht sicher, ob ich mir das WAN irgendwie blocke.
Mit dem WAN als Gateway und einer erstellten Rule funktioniert es definitiv nicht.
Wie gesagt, ein falscher Handgriff und das kann es für ein paar Wochen gewesen sein.
Wäre schön, wenn das so auf der pfSense schon mal jemand praktiziert hätte...
Gruß orcape
Wäre schön, wenn das so auf der pfSense schon mal jemand praktiziert hätte
Dann solltest Du lieber warten bis @aqui sich dazu äußert Gruß
Dobby
...das waren auch schon so meine Gedanken...
Gruß orcape
Gruß orcape
1
Hey,
für den Zugriff vom 3 Tunnel auf die Tunnel 1 und 2 musst du im Normalfall eine Route für die Clients (also Gegenseite der pfSense) pushen.
Für den Tunnel 3 sollte dies so aussehen (VPN --> OpenVPN --> Server --> Tunnel 3
push "route 172.168.1.0 255.255.255.0";
push "route 172.168.2.0 255.255.255.0";
Nun findet aber nur der Client im Tunnel 3 den Weg zum Tunnel 1 und 2, diese kenne aber keinen Rückweg.
Deshalb sind in Tunnel 1 und 2 noch folgende Einträge notwendig
push "route 172.168.3.0 255.255.255.0";
Dies kann auch unter Umständen direkt auf dem Client erfolgen, sollte dann aber nur wie folgt aussehen.
route 172.168.3.0 255.255.255.0
PS: Die Befehle gehören in den unteren Bereich Advanced configuration
Gruß
für den Zugriff vom 3 Tunnel auf die Tunnel 1 und 2 musst du im Normalfall eine Route für die Clients (also Gegenseite der pfSense) pushen.
Für den Tunnel 3 sollte dies so aussehen (VPN --> OpenVPN --> Server --> Tunnel 3
push "route 172.168.1.0 255.255.255.0";
push "route 172.168.2.0 255.255.255.0";
Nun findet aber nur der Client im Tunnel 3 den Weg zum Tunnel 1 und 2, diese kenne aber keinen Rückweg.
Deshalb sind in Tunnel 1 und 2 noch folgende Einträge notwendig
push "route 172.168.3.0 255.255.255.0";
Dies kann auch unter Umständen direkt auf dem Client erfolgen, sollte dann aber nur wie folgt aussehen.
route 172.168.3.0 255.255.255.0
PS: Die Befehle gehören in den unteren Bereich Advanced configuration
Gruß
Hi Orcape
Hast du die OVPN Routing Dok dazu mal gelesen:
http://community.openvpn.net/openvpn/wiki/RoutedLans
Ggf. hilft das..
Hast du die OVPN Routing Dok dazu mal gelesen:
http://community.openvpn.net/openvpn/wiki/RoutedLans
Ggf. hilft das..
@ gresser
Die einzelnen OpenVPN-Server kennen ja die Route zu Ihrem Client-LAN bereits.
Das pushen der Routen ist für ein Netzwerk hinter dem Server kein Problem.
Ein Eintrag wie von Dir vorgeschlagen, führt zu keiner Änderung in der Routing-Tabelle.
Die pfSense müsste auf dem OpenVPN-Interface von einem Tunnel in den anderen routen, dann wären die remoten Clients sofort erreichbar.
Der "push route" Befehl funktioniert da nicht.
@ Aqui
...hab mir das mal reingezogen. So ein Fall ist aber nicht beschrieben.
Also wohl doch erst mal weiter die "Notlösung" mit dem Umweg über den Router und später einen Multi-Client Modus mit den entsprechenden Regeln.
Es sei denn, hier hat noch jemand eine "zündende " Idee, die dann schon getestet und auch funktioniert...
Gruß orcape
für den Zugriff vom 3 Tunnel auf die Tunnel 1 und 2 musst du im Normalfall eine Route für die Clients (also Gegenseite der pfSense) pushen.
Wenn das nur so einfach wäre.Die einzelnen OpenVPN-Server kennen ja die Route zu Ihrem Client-LAN bereits.
Das pushen der Routen ist für ein Netzwerk hinter dem Server kein Problem.
Ein Eintrag wie von Dir vorgeschlagen, führt zu keiner Änderung in der Routing-Tabelle.
Die pfSense müsste auf dem OpenVPN-Interface von einem Tunnel in den anderen routen, dann wären die remoten Clients sofort erreichbar.
Der "push route" Befehl funktioniert da nicht.
@ Aqui
...hab mir das mal reingezogen. So ein Fall ist aber nicht beschrieben.
Also wohl doch erst mal weiter die "Notlösung" mit dem Umweg über den Router und später einen Multi-Client Modus mit den entsprechenden Regeln.
Es sei denn, hier hat noch jemand eine "zündende " Idee, die dann schon getestet und auch funktioniert...
Gruß orcape
Die Frage ist generell warum du 3 unterschiedliche OVPN Instanzen hast ? Gibt es einen Grund dafür ?
Hi,
Irgendwann war da mal ein erster Tunnel mit der entsprechenden CA, *.crt, und Key für einen Client.
Später kam dann ein zweiter hinzu, mit neuer CA, *.crt, und Key..usw.
Die Tunnel brauchten bis Dato keine Verbindung untereinander und das kann und soll auch so bleiben.
Sicher kann man einen einzelnen Tunnel draus machen und den im Multi-Client Modus laufen lassen.
Entsprechend konfigurieren und gut iss es.
Das müsste aber dann passieren, wenn ich direkten Zugriff auf die pfSense habe.
Die Tunnel laufen alle auf einem Interface, wäre es eine Möglichkeit für jeden Tunnel
ein Interface zu machen und dann entsprechend zu routen ?
Gruß orcape
Die Frage ist generell warum du 3 unterschiedliche OVPN Instanzen hast ? Gibt es einen Grund dafür ?
Gute Frage...Irgendwann war da mal ein erster Tunnel mit der entsprechenden CA, *.crt, und Key für einen Client.
Später kam dann ein zweiter hinzu, mit neuer CA, *.crt, und Key..usw.
Die Tunnel brauchten bis Dato keine Verbindung untereinander und das kann und soll auch so bleiben.
Sicher kann man einen einzelnen Tunnel draus machen und den im Multi-Client Modus laufen lassen.
Entsprechend konfigurieren und gut iss es.
Das müsste aber dann passieren, wenn ich direkten Zugriff auf die pfSense habe.
Die Tunnel laufen alle auf einem Interface, wäre es eine Möglichkeit für jeden Tunnel
ein Interface zu machen und dann entsprechend zu routen ?
Gruß orcape
Das ast du ja jetzt mit den separaten Prozessen. Vermutlich ist das auch das grundlegende Problem, denn normalerweise hat man nur einen Prozess und steuert den Zugriff über die Firewall.
Langfristig wäre es also besser wenn man die Konfig im Hinblick darauf optimiert.
Langfristig wäre es also besser wenn man die Konfig im Hinblick darauf optimiert.
Das ast du ja jetzt mit den separaten Prozessen. Vermutlich ist das auch das grundlegende Problem, denn normalerweise hat man nur einen Prozess und
steuert den Zugriff über die Firewall.
Ist eigentlich kein Problem 3 Tunnel auf einem Interface, so lange man nicht zwischen den Tunneln routen muss.steuert den Zugriff über die Firewall.
Eigentlich müssten sich doch 3 Virtuelle Interfaces für die Tunnel definieren lassen, die dann bei Bedarf entsprechend geroutet werden können.
Nur ist das für mich von remote zur Zeit ein zu hohes Risiko, wenn das Szenario noch keiner am laufen hat.
Langfristig wäre es also besser wenn man die Konfig im Hinblick darauf optimiert.
Das wird dann wohl irgendwann so werden, wenn ich denn hier in 3 Wochen aus dem Funkloch mit GPRS <10Kbit/s wieder raus bin...Gruß orcape
Hi,
hab das ganze Routing auf der pfSense eben hinbekommen ohne einen Multiclienttunnel zu machen.
Hier mal eine Beispiel-conf....
Für das OpenVPN-Interface noch ein paar Regeln erstellen und bei Bedarf modifizieren...
Vom Aufwand her nicht mehr wie ein Multiclienttunnel, wenn man´s weiß.
Leider habe ich dazu nichts in den Manuals finden können.
Gruß orcape
hab das ganze Routing auf der pfSense eben hinbekommen ohne einen Multiclienttunnel zu machen.
Hier mal eine Beispiel-conf....
OpenVPN-Server3
Advanced Configuration
push "route 10.7.8.0 255.255.255.0"; # zu OVPN-Netz 1
push "route 192.168.65.0 255.255.255.0"; # zu LAN hinter OVPN 1
route 192.168.65.0 255.255.255.0; # zu LAN hinter OVPN 1
push "route 10.14.8.0 255.255.255.0"; # zu OVPN-Netz 2
push "route 192.168.187.0 255.255.255.0";# zu LAN hinter OVPN 2
route 192.168.187.0 255.255.255.0; # zu LAN hinter OVPN 2
Advanced Configuration
push "route 10.7.8.0 255.255.255.0"; # zu OVPN-Netz 1
push "route 192.168.65.0 255.255.255.0"; # zu LAN hinter OVPN 1
route 192.168.65.0 255.255.255.0; # zu LAN hinter OVPN 1
push "route 10.14.8.0 255.255.255.0"; # zu OVPN-Netz 2
push "route 192.168.187.0 255.255.255.0";# zu LAN hinter OVPN 2
route 192.168.187.0 255.255.255.0; # zu LAN hinter OVPN 2
OpenVPN-Server2
Advanced Configuration
push "route 10.13.6.0 255.255.255.0"; # zu Tunnel3
route 10.13.6.0 255.255.255.0; # zu Tunnel3
Advanced Configuration
push "route 10.13.6.0 255.255.255.0"; # zu Tunnel3
route 10.13.6.0 255.255.255.0; # zu Tunnel3
OpenVPN-Server1
Advanced Configuration
push "route 10.13.6.0 255.255.255.0"; # zu Tunnel3
route 10.13.6.0 255.255.255.0; # zu Tunnel3
Advanced Configuration
push "route 10.13.6.0 255.255.255.0"; # zu Tunnel3
route 10.13.6.0 255.255.255.0; # zu Tunnel3
Für das OpenVPN-Interface noch ein paar Regeln erstellen und bei Bedarf modifizieren...
pass Tunnel3-Tunnel1
pass Tunnel3- LAN 1
pass Tunnel1-Tunnel3
pass LAN1 -Tunnel3
pass Tunnel3- LAN 1
pass Tunnel1-Tunnel3
pass LAN1 -Tunnel3
pass Tunnel3-Tunnel2
pass Tunnel3- LAN 2
pass Tunnel2-Tunnel3
pass LAN 2 -Tunnel3
...und schon klappt die Verbindung in die remoten LAN´s.pass Tunnel3- LAN 2
pass Tunnel2-Tunnel3
pass LAN 2 -Tunnel3
Vom Aufwand her nicht mehr wie ein Multiclienttunnel, wenn man´s weiß.
Leider habe ich dazu nichts in den Manuals finden können.
Gruß orcape
Vom Aufwand her nicht mehr wie ein Multiclienttunnel, wenn man´s weiß.
Das meins du im Hinblick auf die zahllosen Konfig Parameter oben nicht wirklich Ernst, oder ?Es bleibt immer noch die Frage warum der ganze Frickelkram mit den 3 separaten Instanzen ? Das ist von der grundsätzlichen Konfig her falsch und müsste so nicht sein und erzwingt in letzter Konsequenz auch diese überflüssig aufwendige Konfig.
Gut wenns nun klappt und für dich alles rennt ists ok aber es mpüsste nicht so sein.
Hört sich so ein bischen nach " Warum einfach machen wenns umständlich auch geht ?!" an.
Hört sich so ein bischen nach " Warum einfach machen wenns umständlich auch geht ?!" an.
Ja gut irgend eine Ausrede braucht man ja...Aber beim Multiclienttunnel muss ich auch genügend Regeln definieren um auf Nummer sicher zu gehen, wenn die Oma mir nicht
"in die Suppe spucken soll".
Also was soll´s Aqui, Du weist vielleicht schon das Aufgeben nicht mein Ding ist und nun wissen wir wenigstens das es auch anders geht.
Gruß orcape
Hallo,
Ich habe genau das Gleiche Problem, stolpere gerade über diesen uralten Thread und möchte diese Frage gerne beantworten: "Man hat sich als Dienstleister an den vorgelagerten Systemen" zu orientieren. Dort gelten z.B. unterschiedliche Firewallregeln für unterschiedliche Ports bzw. die "Ports an sich" werden aus unterschiedlichen Netzen angesprochen, liegen auf separaten Gateways usw. usf.
Und vielleicht möchte man die Instanzen ja auch separat konfigurieren und neu starten können. Für den OpenVPN-Server für die Administratoren oder Netzkopplungen gelten ganz andere Spielregeln wie für die RoadWarrior.
Ich nehme für mich mal mit, dass das nicht so "ohne Weiteres" möglich ist - was ich sehr schade finde.
Gruß,
Jörg
Zitat von @aqui:
Es bleibt immer noch die Frage warum der ganze Frickelkram mit den 3 separaten Instanzen ?
Es bleibt immer noch die Frage warum der ganze Frickelkram mit den 3 separaten Instanzen ?
Ich habe genau das Gleiche Problem, stolpere gerade über diesen uralten Thread und möchte diese Frage gerne beantworten: "Man hat sich als Dienstleister an den vorgelagerten Systemen" zu orientieren. Dort gelten z.B. unterschiedliche Firewallregeln für unterschiedliche Ports bzw. die "Ports an sich" werden aus unterschiedlichen Netzen angesprochen, liegen auf separaten Gateways usw. usf.
Und vielleicht möchte man die Instanzen ja auch separat konfigurieren und neu starten können. Für den OpenVPN-Server für die Administratoren oder Netzkopplungen gelten ganz andere Spielregeln wie für die RoadWarrior.
Ich nehme für mich mal mit, dass das nicht so "ohne Weiteres" möglich ist - was ich sehr schade finde.
Gruß,
Jörg
Na ja mit 3 VMs hat man ja 3 separate Instanzen und damit ist das dann wieder ein Kinderspiel...
Oder...man nimmt einem kleinen Cisco und arbeitet mit VRFs
Oder...man nimmt einem kleinen Cisco und arbeitet mit VRFs
Hallo,
Es gibt gute Gründe, Firewalls nicht in einer VM zu installieren.
Da hast Du sicherlich auch Recht. Aber ich bin nun mal Freund von OpenSource und immer geneigt, derartige Projekte zu unterstützen und schaue grundsätzlich zuerst in diese Richtung - gerade weil ich es auch wichtig finde, die Communities monetär zu unterstützen. Aber in diesem Falle geht es halt nicht (gut) - wie Du ja selber festgestellt hast.
Gruß,
Jörg
Es gibt gute Gründe, Firewalls nicht in einer VM zu installieren.
Oder...man nimmt einem kleinen Cisco und arbeitet mit VRFs
Da hast Du sicherlich auch Recht. Aber ich bin nun mal Freund von OpenSource und immer geneigt, derartige Projekte zu unterstützen und schaue grundsätzlich zuerst in diese Richtung - gerade weil ich es auch wichtig finde, die Communities monetär zu unterstützen. Aber in diesem Falle geht es halt nicht (gut) - wie Du ja selber festgestellt hast.
Gruß,
Jörg
Hi,
weil das wieder so schön "aufgewärmt" wurde, hier 4 Jahre später auch noch meinen Senf dazu.
Ich muss im nachhinein feststellen, das die 3 Instanzen (nicht in einer VM), sehr wohl eine Berechtigung gegenüber einem Multiclienttunnel haben und das Handling bei eventuellen remoten Ausfällen einfacher ist.
Wobei ich im reinen Road-Warrior Betrieb, um remote EInzelclients ins Firmennetz einzubinden, wohl auch den Multiclienttunnel bevorzugen würde.
Gruß orcape
weil das wieder so schön "aufgewärmt" wurde, hier 4 Jahre später auch noch meinen Senf dazu.
Ich muss im nachhinein feststellen, das die 3 Instanzen (nicht in einer VM), sehr wohl eine Berechtigung gegenüber einem Multiclienttunnel haben und das Handling bei eventuellen remoten Ausfällen einfacher ist.
Und vielleicht möchte man die Instanzen ja auch separat konfigurieren und neu starten können.
Genau hier liegt der Vorteil des Constructs, bei mehreren anzubindenden remoten Netzen.Wobei ich im reinen Road-Warrior Betrieb, um remote EInzelclients ins Firmennetz einzubinden, wohl auch den Multiclienttunnel bevorzugen würde.
Gruß orcape
Hallo,
Genau das habe ich mir nämlich auch gedacht. Gerade am Vortag habe ich einen Kollegen bei einem Szenario unterstützt, wo eine zusätzliche Netz-zu-Netz Kopplung etabliert wurde. Die "Gegenseite" hat es tatsächlich geschafft, derart unförmige Pakete zu schicken, dass das openswan mit Kernelfehlern ausgestiegen ist.
Und auf einmal waren auch die ganzen RoadWarrior weg und wir standen zudem vor einen Szenario, wo wir den VPN-Dienst mehrfach neu starten mussten. Die (leistungsorientiert bezahlten bzw. scheinselbstständigen) Außendienstler, die von Kundentermin zu Kundentermin flitzen, haben sich wohlwollend bedankt.
Man kann durchaus darüber diskutieren, mehrere Firewalls an den Start zu bringen. Aber dann habe ich letztendlich auch 3 Netzteile, 3 Gehäuse, 3 CPUs und baue direkt daneben noch mal 3 Redundanzen für meine Ausfallsicherheit auf.
Mit anderen Worten: Genau so, wie eine Virtualisierung bei Betriebssystemen Sinn macht, macht auch eine Verteilung von einzelnen Diensten auf ein- und derselben Hardware Sinn.
Gruß,
Jörg
Zitat von @orcape:
Wobei ich im reinen Road-Warrior Betrieb, um remote EInzelclients ins Firmennetz einzubinden, wohl auch den Multiclienttunnel bevorzugen würde.
Wobei ich im reinen Road-Warrior Betrieb, um remote EInzelclients ins Firmennetz einzubinden, wohl auch den Multiclienttunnel bevorzugen würde.
Genau das habe ich mir nämlich auch gedacht. Gerade am Vortag habe ich einen Kollegen bei einem Szenario unterstützt, wo eine zusätzliche Netz-zu-Netz Kopplung etabliert wurde. Die "Gegenseite" hat es tatsächlich geschafft, derart unförmige Pakete zu schicken, dass das openswan mit Kernelfehlern ausgestiegen ist.
Und auf einmal waren auch die ganzen RoadWarrior weg und wir standen zudem vor einen Szenario, wo wir den VPN-Dienst mehrfach neu starten mussten. Die (leistungsorientiert bezahlten bzw. scheinselbstständigen) Außendienstler, die von Kundentermin zu Kundentermin flitzen, haben sich wohlwollend bedankt.
Man kann durchaus darüber diskutieren, mehrere Firewalls an den Start zu bringen. Aber dann habe ich letztendlich auch 3 Netzteile, 3 Gehäuse, 3 CPUs und baue direkt daneben noch mal 3 Redundanzen für meine Ausfallsicherheit auf.
Mit anderen Worten: Genau so, wie eine Virtualisierung bei Betriebssystemen Sinn macht, macht auch eine Verteilung von einzelnen Diensten auf ein- und derselben Hardware Sinn.
Gruß,
Jörg
