Eine virtuelle Firewall ist eine normale VM mit vielen Netzwerkkarten und einem Regelwerk. Sie eignet sich gut, um Netze im Inneren zu trennen, ein Labor zu schützen oder einen zweiten Standort ohne zusätzliches Gehäuse aufzubauen. Sie eignet sich schlecht als einziges Gerät am Internetanschluss, wenn sie auf demselben Host läuft wie die Server, die sie schützen soll. Fällt der Host aus, fallen Leitweg, VPN und die Maschinen gemeinsam aus, und der Zugriff für die Reparatur fehlt genau dann.

Wann die Firewall in der VM den Host mit einschließt

Dazu kommt die Startreihenfolge. Die Server brauchen DNS, manchmal die Firewall als Sprungpunkt, und die Firewall-VM braucht den Host, der wiederum ohne fertige Regeln schwer aus der Ferne erreichbar ist. Ein Hardware-Gerät am Anschluss bleibt erreichbar, während der Host neu startet. Ein mobiler Zugang oder eine zweite Leitung, die nicht durch dieselbe VM führt, ist der praktische Reparaturweg. Ohne den steht man bei einem Host-Ausfall vor einem schönen Regelwerk, das niemand öffnen kann.

Virtuelle Firewalls wollen zugewiesene Schnittstellen, nicht ein einziges Netz, in dem alle VMs und das WAN gemeinsam hängen. Durchgereichte Ports können sinnvoll sein, sie binden die VM aber enger an die Hardware und an die Updatefähigkeit des Hypervisors. Leistung ist selten das erste Problem im KMU; die Abhängigkeit ist es. Eine kommerzielle virtuelle Appliance braucht außerdem ihre eigene Lizenz und Updates, eine freie Distribution braucht Pflege durch die Betreuung. Beides ist tragfähig, keines ist „einfach eine VM mehr“.

Randgerät physisch, Segmentierung virtuell

  1. Rand. Das Gerät am Internetanschluss steht auf eigener Hardware, wenn es die einzige Tür ist. Seine Stromversorgung und sein Standort sind nicht der Host allein.
  2. Innen. Zusätzliche Trennungen, Labore oder Gastnetze dürfen als VM laufen, mit eigenen Schnittstellen und ohne das WAN zu monopolisieren.
  3. Zugang. Es gibt einen Reparaturweg, der nicht durch die VM auf dem ausgefallenen Host führt: Hardware-Gerät, Konsole vor Ort oder eine zweite Leitung.
  4. Export. Die Konfiguration wird nach Änderungen exportiert und außerhalb der Firewall gespeichert. Ein Ersatzgerät oder eine dokumentierte Neuinstallation ist benannt.
  5. Pflege. Updates der Firewall haben ein eigenes Fenster und eine eigene Lizenz- oder Distributionspflege, unabhängig vom Patch des Hypervisors.

Unser übliches Bild für einen Standort in Wien oder in einer Filiale: ein kleines Hardware-Gerät am Anschluss, die Server auf dem Host, und eine virtuelle Firewall nur dort, wo eine zusätzliche Trennung – etwa ein Labor oder ein Gastnetz mit eigenem Regelwerk – den Aufwand rechtfertigt. Die Regeln werden exportiert und liegen nicht ausschließlich auf dem Gerät. Ein Host-Wartungsfenster unterbricht dann nicht die einzige Tür in die Firma.

Woran Projekte in der Praxis scheitern

  • Die einzige Firewall als VM auf dem einzigen Host betreiben und keinen zweiten Zugang haben.
  • Das WAN und alle Server in dasselbe virtuelle Netz hängen, weil „die Firewall ja filtert“.
  • Konfigurationsexporte nur auf dem Dateiserver hinter derselben Firewall lagern.
  • Eine virtuelle Appliance installieren und ihre Updates dem Host-Patch „irgendwann“ zuschlagen.

Beispiel aus dem Betriebsalltag

Ein Ingenieurbüro hatte die Firewall als VM auf dem einzigen ESXi-Host, zusammen mit Dateidienst und Anwendung. Beim Host-Update fiel VPN aus, und der einzige Weg zur Konsole war ein Bildschirm im Serverraum, den niemand vom Homeoffice aus erreicht hat. Wir haben ein kleines Hardware-Gerät an den Anschluss gestellt, die bisherigen Regeln dorthin übernommen und die VM nur noch für ein internes Testnetz behalten. Das nächste Host-Update lief, während VPN über das Hardware-Gerät stand. Der Export der Konfiguration liegt seitdem neben den VM-Sicherungen, nicht auf der Firewall selbst. Die virtuelle Firewall blieb für das Labor erhalten, sie ist nicht mehr die einzige Tür.

Kurze Entscheidungshilfe

  • Bleibt ein Weg ins Netz, wenn der Virtualisierungshost aus ist?
  • Liegt ein aktueller Regelexport außerhalb dieses Hosts?
  • Hat die Firewall am Rand eigene Hardware oder einen gleichwertigen unabhängigen Zugang?
  • Sind Labor- und Produktivregeln getrennt und nicht in einer VM vermischt?

Wenn virtuelle Firewall oder Appliance bei Ihnen ansteht, klären wir den Umfang unverbindlich: Virtualisierung. Virtualisierung im KMU Alternativ direkt Kontakt aufnehmen oder die häufigen Fragen lesen.