TL;DR: Ein VLAN trennt Netze nur auf der untersten Ebene. Echte Trennung entsteht erst an einer Stelle, die mit Regeln entscheidet, welcher Verkehr zwischen den Segmenten erlaubt ist: einer Firewall. Ob die virtuell auf dem Server läuft oder als eigenes Gerät davor steht, hängt vor allem an einer Frage: Was passiert, wenn der Server selbst angegriffen wird?
Warum ein VLAN allein nicht trennt
Die Frage kommt in fast jedem Projekt: „Wir legen die neuen Systeme einfach in ein eigenes VLAN, dann sind sie getrennt, oder?“ Die kurze Antwort: nur zum Teil.
Ein VLAN teilt einen Switch logisch in mehrere Netze auf. Geräte in verschiedenen VLANs sehen sich nicht direkt, Broadcasts bleiben im eigenen Segment. Das ist ordentlich und übersichtlich. Aber sobald irgendwo zwischen den VLANs geroutet wird, ist die Trennung so gut wie die Regeln an genau dieser Stelle. Und geroutet wird fast immer: Die neuen Systeme brauchen Updates aus dem Internet, einen Zeitserver, DNS, vielleicht eine Datenbank im alten Netz.
Häufig übernimmt das Routing ein Layer-3-Switch oder ein Server mit zwei Netzwerkkarten. Beide leiten in der Grundeinstellung alles weiter. Dann ist das VLAN zwar ein eigenes Netz, aber keine Grenze.
Getrennt ist ein Segment erst, wenn eine Stelle mit Regeln entscheidet, was hinein und hinaus darf, und alles andere verwirft. Das ist die Aufgabe einer Firewall. Die eigentliche Entscheidung ist also nicht „VLAN oder nicht“, sondern: Wo läuft diese Firewall?
Drei Wege im Vergleich
| VLAN ohne Firewall | Virtuelle Firewall auf dem Host | Eigene Firewall-Hardware | |
|---|---|---|---|
| Regeln zwischen den Segmenten | keine oder nur einfache Filter | ja | ja |
| Unabhängig vom Server, den sie schützt | – | nein | ja |
| Mehrere Hosts und Standorte | über Switch-Konfiguration | nur mit zusätzlicher Vernetzung | ja |
| Snapshot und Umzug mit dem Server | – | ja | nein |
| Zusätzliches Gerät im Rack | nein | nein | ja |
Die virtuelle Firewall: schnell aufgebaut, aber auf demselben Host
Auf einem Virtualisierungshost wie Proxmox ist eine virtuelle Firewall schnell eingerichtet. Wir nutzen dafür unter anderem OPNsense: eine interne Bridge ohne physischen Anschluss für das neue Segment, die Firewall-VM als einziger Weg hinaus. Das hat echte Vorteile. Die Konfiguration lässt sich mit dem Host sichern, ein Snapshot vor jeder Änderung kostet nichts, und zieht der Host um, zieht die Firewall mit.
Zwei Schwächen bleiben aber:
- Sie läuft auf dem Host, den sie schützen soll. Wer den Hypervisor übernimmt, steht hinter der Firewall. Er kann Bridges umhängen, Regeln ändern oder die VM einfach ausschalten. Für die Trennung zweier Testnetze ist das vertretbar. Für die Grenze zwischen Produktion und allem anderen ist es zu wenig.
- Mehrere Hosts brauchen zusätzliche Vernetzung. Solange alles auf einem Server läuft, reicht eine interne Bridge. Verteilen sich die Systeme auf mehrere Hosts, muss das Segment über VLANs oder ein Overlay wie VXLAN zwischen ihnen gespannt werden. Damit ist man wieder beim Switch, und die Konfiguration wird deutlich komplexer.
Dazu kommt, was für jede Firewall gilt: Die Werkskonfiguration ist auf Bequemlichkeit ausgelegt, nicht auf Trennung. Ein typischer Fall: Die Firewall ist für IPv4 sauber eingerichtet, aber der Router davor verteilt längst IPv6-Adressen. Dann hat das Segment eine zweite Verbindung nach draußen, mit der unter Umständen niemand gerechnet hat. Eine Trennung gilt deshalb erst, wenn man sie von beiden Seiten getestet hat, für IPv4 und für IPv6. Wie wir solche Grenzen für KI-Agenten ziehen und testen, steht in KI-Agenten an der eigenen Infrastruktur: So setzen Sie Grenzen.
IPv6: die zweite Tür
Firewall-Regeln für IPv4 gelten nicht automatisch für IPv6. Hat ein Segment beides, braucht es zwei Regelwerke, und beide müssen getestet werden. Das gilt auch für die Dienste selbst: Auf welchen Adressen ein Programm lauscht, entscheidet mit, worüber es erreichbar ist. Unter Linux zeigt ss -ltn die offenen Ports, und die Schreibweise der lokalen Adresse verrät viel:
Ausgabe in ss -ltn |
Bedeutung |
|---|---|
0.0.0.0:4711 |
alle IPv4-Adressen, kein IPv6 |
[::]:4711 |
alle IPv6-Adressen, kein IPv4 (das Programm hat IPv4 ausdrücklich ausgeschlossen) |
*:4711 |
egal welche Adresse: IPv4 und IPv6 |
127.0.0.1:4711 oder [::1]:4711 |
nur auf dem Rechner selbst erreichbar |
Dass 0.0.0.0 kein IPv6 abdeckt, kann sehr sinnvoll sein: Ein Dienst, der nur auf IPv4 lauscht, ist über IPv6 gar nicht erst erreichbar. Umgekehrt gilt das nicht automatisch. Bindet ein Programm an ::, nimmt Linux in der Grundeinstellung auch IPv4-Verbindungen an, solange das Programm das nicht über die Socket-Option IPV6_V6ONLY abschaltet. In ss erscheint der Dienst dann als *:4711. Viele Programme akzeptieren in ihrer Konfiguration auch die Kurzform :4711, die genau das bedeutet.
Wir haben das auf einem aktuellen Linux nachgeprüft: Ein Dienst auf [::] mit ausgeschlossenem IPv4 lehnte eine Verbindung über 127.0.0.1 ab, derselbe Dienst ohne diese Einschränkung nahm sie an.
Tipp für Testumgebungen: Wird IPv6 nicht gebraucht, schalten Sie es bewusst ab, statt es halb konfiguriert mitlaufen zu lassen. Sonst bekommt das Segment womöglich IPv6-Adressen von einem Router weiter vorne, ohne dass es jemand geplant hat. Prüfen Sie danach, ob alle Dienste noch starten, denn manche sind auf ::1 konfiguriert. Wird IPv6 gebraucht, dann mit eigenen Regeln, die genauso gepflegt und getestet werden wie die für IPv4.
Die Hardware-Firewall: unabhängig vom Server
Eine eigene Firewall vor den Servern löst genau die beiden Schwächen der virtuellen Variante. Sie läuft auf eigener Hardware mit eigenem Betriebssystem. Wer einen Server übernimmt, hat damit noch keinen Zugriff auf die Regeln, die diesen Server vom Rest trennen. Und weil sie zwischen Switch und Hosts sitzt, trennt sie Segmente über beliebig viele Server hinweg, ohne dass ein Overlay nötig ist.
In Kunden- und Produktionsumgebungen setzen wir deshalb typischerweise auf dedizierte Firewall-Hardware, etwa Juniper SRX. Das Bild oben zeigt zwei SRX300 aus unserem Labor, jeweils mit sechs Gigabit-Ports und zwei SFP-Steckplätzen. Die SRX300 ist eine kleine, ältere Kiste, dafür sparsam und lüfterlos. Mit Junos 26 läuft sie auf aktuellem Stand und ist definitiv kein Spielzeug. Eine weitere Stärke eigener Hardware: Standortverbindungen per VPN hängen nicht davon ab, ob ein bestimmter Server gerade läuft. Das zählt vor allem nach einem Stromausfall oder geplanten Neustart: Läuft das VPN als VM, kann ein Hyper-V-Host beim Hochfahren auf einen Domänencontroller warten, der nur über genau dieses VPN erreichbar ist. Oder zwei Domänencontroller an verschiedenen Standorten warten aufeinander. Eine Firewall auf eigener Hardware ist dagegen einfach da, sobald sie Strom hat.
Der Preis dafür: ein weiteres Gerät, das gewartet, mit Updates versorgt und dokumentiert werden will. Ein Snapshot vor jeder Änderung ist nicht so bequem wie bei einer VM, die Konfiguration muss man selbst versionieren. Und auf das Alter des Geräts kommt es weniger an als auf die Software: Eine Firewall ohne aktuelle Sicherheitsupdates schützt nicht, sie täuscht Schutz nur vor.
Rollen teilen: Trennung hier, Zertifikate dort
In der Praxis ist es selten ein Entweder-oder. Bewährt hat sich bei uns eine klare Aufteilung der Rollen:
- Die Firewall trennt und routet: zwischen Segmenten, Hosts und Standorten. Ihre Regeln ändern sich selten, und jede Änderung ist eine bewusste Entscheidung.
- Der Reverse-Proxy kümmert sich um die Dienste: Er nimmt Verbindungen von außen an, beendet die TLS-Verschlüsselung und verwaltet die Zertifikate. Bei uns ist das ein HAProxy, wie in unserem Beitrag Docker-Registry hinter Traefik beschrieben.
- Virtuelle Firewalls bleiben, wo sie passen: für Test- und Entwicklungsnetze auf einem einzelnen Host, die schnell entstehen und wieder verschwinden.
So muss niemand die zentrale Firewall anfassen, nur weil ein neuer Dienst ein Zertifikat braucht. Und ein Fehler bei einem Dienst reißt nicht die Trennung zwischen den Netzen mit.
Dieselbe Frage bei KI-Agenten
Netze trennen ist kein reines Serverthema mehr. KI-Agenten auf Entwicklerrechnern rufen Webseiten ab, installieren Pakete und erreichen dabei alles, was der Rechner erreicht, auch interne Systeme. Die Werkzeuge ziehen hier gerade nach: GitHub Copilot CLI unterstützt seit einer Vorabversion vom 10. November in den Sandbox-Einstellungen IPv4- und IPv6-Netzbereiche in CIDR-Schreibweise für erlaubte und gesperrte Ziele. Statt einzelne Adressen aufzuzählen, lässt sich damit zum Beispiel ein ganzes internes Segment sperren.
Das ist ein sinnvoller Schritt, ersetzt aber keine Netztrennung. Die Regeln laufen auf demselben Rechner wie der Agent, es gilt also dieselbe Schwäche wie bei der virtuellen Firewall. Was ein Agent auf keinen Fall erreichen darf, sollte zusätzlich im Netz gesperrt sein. Warum das bei Agenten besonders wichtig ist, beschreiben wir in Warum KI-Agenten im Unternehmen echte Sandboxes brauchen.
Welcher Weg passt?
- Nur Ordnung schaffen, etwa Telefone, Drucker und Gäste in eigene Netze? Ein VLAN mit einfachen Regeln am Router reicht oft.
- Ein Testnetz auf einem einzelnen Server abschotten? Eine virtuelle Firewall ist schnell, günstig und lässt sich mitsichern.
- Produktion vom Rest trennen, mehrere Hosts oder Standorte verbinden? Dann gehört die Firewall auf eigene Hardware, unabhängig von den Servern, die sie schützt.
- In jedem Fall: Werkskonfiguration durch eigene Regeln ersetzen, nur das Nötige erlauben, und die Trennung von beiden Seiten testen.
Wie gut sind Ihre Netze wirklich getrennt?
Wir prüfen mit Ihnen, wo zwischen Ihren Segmenten geroutet wird, welche Regeln dort gelten und was aus jedem Segment heraus tatsächlich erreichbar ist. Danach wissen Sie, ob VLAN, virtuelle Firewall oder eigene Hardware zu Ihrem Netz passt.
Häufige Fragen
Ist ein VLAN eine Sicherheitsmaßnahme? Ein VLAN trennt Netze logisch auf dem Switch. Sicherheit entsteht erst durch Regeln an der Stelle, an der zwischen den VLANs geroutet wird. Ohne solche Regeln ist ein VLAN Ordnung, keine Grenze.
Was ist der Unterschied zwischen VLAN und Firewall? Das VLAN legt fest, welche Geräte im selben Netz sind. Die Firewall legt fest, welcher Verkehr zwischen verschiedenen Netzen erlaubt ist. Für eine echte Trennung braucht man in der Regel beides.
Reicht eine virtuelle Firewall wie OPNsense auf dem Server? Für Test- und Entwicklungsnetze auf einem einzelnen Host oft ja. Für die Grenze zur Produktion ist sie schwächer, weil sie auf demselben Host läuft, den sie schützen soll. Wer den Host übernimmt, kann sie umgehen.
Deckt 0.0.0.0 auch IPv6 ab?
Nein. Ein Dienst auf 0.0.0.0 lauscht auf allen IPv4-Adressen, aber nicht auf IPv6. Das IPv6-Gegenstück ist ::. Unter Linux nimmt ein Dienst auf :: in der Grundeinstellung allerdings auch IPv4 an, außer das Programm schließt es ausdrücklich aus. ss -ltn zeigt ihn dann als *:Port.
Wann lohnt sich eine Hardware-Firewall? Wenn ein Segment unabhängig von den Servern geschützt sein soll, wenn mehrere Hosts oder Standorte beteiligt sind oder wenn Standorte per VPN verbunden werden. Voraussetzung ist ein Gerät, das noch Sicherheitsupdates bekommt.
Fazit
Ein VLAN ist der Anfang, nicht die Trennung. Entscheidend ist, wo die Regeln stehen und wer sie umgehen kann. Virtuelle Firewalls sind für Testnetze schnell und praktisch. Wo es um Produktion, mehrere Hosts oder Standorte geht, gehört die Firewall auf eigene Hardware, und die Zertifikate gehören zum Reverse-Proxy. Wie wir Netze und Server für Unternehmen betreuen, steht auf unserer Seite Serverbetreuung und Netzwerk. Oder sprechen Sie uns direkt an.
Quellen: GitHub – Copilot CLI Release v1.0.109-1 (Vorabversion, 10.11.2026)
