Wer heute ein Firmennetzwerk betreibt, braucht mehr als einen Router: Eine saubere Firewall ist Pflicht, spätestens seit Homeoffice, Cloud-Dienste und interne Server sicher getrennt werden müssen. Mit VyOS bekommt man ein Open-Source-Router-Betriebssystem, das auf Debian basiert und die gesamten Linux-Netfilter-Fähigkeiten (iptables/nftables) hinter einer konsistenten Kommandozeile bündelt – als Ersatz oder Ergänzung zu klassischen Kombigeräten.
VyOS ist kein abgespecktes Desktop-Linux mit Router-Funktionen, sondern ein Netzwerkbetriebssystem, das gezielt für den Betrieb als Router und Firewall gebaut wurde – komplett über eine durchgängige CLI, ohne Webinterface. Das ist in Zeiten von Verwaltungsoberflächen oft die eigentliche Stärke:
commit macht Änderungen wirksam, save schreibt sie dauerhaft. VyOS führt eine Commit-Historie, mit der sich Konfigurationen vergleichen und zur letzten funktionierenden Version zurückrollen lassen. Automatisierung über Ansible ist Standard (Collection vyos.vyos).VyOS kommt in Unternehmen in ganz unterschiedlichen Rollen zum Einsatz – die CLI und die Denkweise bleiben dabei immer dieselben:
Gerade der Punkt „eine Konfigurationsbasis für Geräte und Standorte" macht VyOS im Alltag wertvoll: Was im Rechenzentrum am BGP-Router gilt, funktioniert unverändert im 50-Personen-Standort – und umgekehrt.
VyOS ist Open Source – der Quellcode steht unter der GPL-2.0 auf GitHub. Damit ist die Grundsatzfrage schnell beantwortet: Es gibt keine Abrechnung pro Domain, kein „mehr Bandbreite durch teurere Lizenz", keine verdeckte Feature-Freischaltung. Wer will, baut sich sein Image jederzeit selbst aus dem Quellcode. Das Projekt finanziert sich stattdessen über Abonnements, die das Bequeme verkaufen: fertige Images, Updates und Support.
Die Release-Arten und Einstiege im Überblick:
current-Entwicklungsstand gebaute Images – nächtlich bzw. als regelmäßige Snapshots. Immer der neueste Stand mit allen Funktionen, aber ohne Stabilitätsgarantie. Ideal für Entwicklung, Labor und Feature-Tests.Unsere Praxis-Empfehlung für Unternehmen: Für produktive Standorte auf ein LTS-Abo setzen – Support und SLA sind im Fehlerfall Gold wert –, im Test- und Labortumfeld reichen die kostenlosen Rolling- und Stream-Images völlig aus.
In diesem Artikel konzentrieren wir uns auf die Firewall – das Fundament jedes Standorts. Die Konzepte, die wir hier aufbauen, sind dieselben, auf denen die übrigen Szenarien fußen.
Klassische Firewall-Konfigurationen sind Regelsammlungen pro Schnittstelle: Jede neue Schnittstelle bedeutet neue, oft kopierte Regeln. Eine Zonen-Firewall dreht das Konzept um: Statt Regeln an Interfaces zu hängen, fasst man gleichartige Schnittstellen in einer Zone zusammen und definiert die Politik zwischen Zonen.
Internet ──eth0──> ┌───────────────┐ <──eth1── LAN (192.168.1.0/24)
│ VyOS Router │
│ Zonen: WAN/LAN │
└───────────────┘
Davon profitieren vor allem kleine und mittlere Unternehmen:
In VyOS seit Version 1.4 (und 1.5) ist die Zonen-Firewall vollständig unterstützt, die Konfiguration liegt unter set firewall zone ….
Laut offizieller Doku braucht VyOS mindestens eine 64-bit-x86-CPU (Intel oder AMD), 4 GB RAM und 10 GB Speicher. Für den Praxiseinsatz plant man großzügiger: Mehr RAM und Kerne sind vor allem bei großen Routing-Tabellen (BGP), VPP und vielen Tunnel-Instanzen nötig.
An Images stellt VyOS für x86-64 ISO, QCOW2, OVA, RAW, VHD und XVA bereit – damit läuft es auf Bare-Metal genauso wie in KVM/Proxmox, VMware oder Xen; für die Clouds (AWS, Azure, GCP, …) gibt es passende, Cloud-Init-fähige Varianten. Wer ein geprüftes Gerät will, findet die offizielle Hardware Compatibility List unter vyos.io/hcl – dort sind alle von VyOS oder den Herstellern verifizierten Appliance-Modelle gelistet.
Die Erstinstallation erfolgt von der ISO (Live-Boot, dann install image); Updates werden später als neue Images eingespielt, nicht per Paketaktualisierung.
VyOS ist bewusst reine CLI-Software – wer Linux oder Cisco-Kommandozeilen gewohnt ist, findet sich sofort zurecht. Zwei Modi sind wichtig:
vyos@vyos$): alltagstaugliche Kommandos wie ping, tracepath, show version oder show system commit.configure, Prompt vyos@vyos#): hier wird die Konfiguration gebaut – set, delete, commit und Co. gibt es nur hier. Aus diesem Modus heraus startet run <Befehl> ein Operational-Kommando.Die Konfiguration ist ein Baum. Mit set fügt man Werte ein, mit delete entfernt man sie – dank Tab-Vervollständigung und ?-Hilfe, ohne auswendig gelernte Syntax. show zeigt die Zwischenkonfiguration, compare den Diff gegen die aktive Konfiguration; unbestätigte Änderungen fallen mit discard.
Eine typische Session:
vyos@vyos$ configure
vyos@vyos# set system host-name "gw01"
vyos@vyos# set interfaces ethernet eth0 address dhcp
vyos@vyos# set interfaces ethernet eth1 description 'LAN'
vyos@vyos# compare
vyos@vyos# commit
vyos@vyos# save
vyos@vyos# exit
commit macht wirksam, save macht dauerhaft: Änderungen greifen erst nach commit; erst save schreibt sie dauerhaft nach /config/config.boot. Bei riskanten Aktionen – der erste Firewall-Regelsatz ist ein Klassiker – hilft commit-confirm: Die Änderung wird vorläufig angewendet und muss innerhalb von 10 Minuten (konfigurierbar, z. B. commit-confirm 5) per confirm bestätigt werden – sonst kehrt das System automatisch zur vorherigen Revision zurück (Default per Reboot, auf reload umstellbar).
Config-Versionierung: Nach jedem commit legt VyOS automatisch eine Revision an; die letzten 100 bleiben erhalten (erweiterbar per set system config-management commit-revisions 1000). Damit lässt sich jede Änderung nachvollziehen:
vyos@vyos$ show system commit
vyos@vyos$ show system commit diff 5
vyos@vyos$ show system commit file 3
Rollback und Backup: rollback <Revision> stellt einen älteren Stand wieder her (aktuell mit Neustart verbunden – vorher das Ziel mit compare prüfen). Alternativ lädt load <Datei> eine gesicherte Konfiguration – lokal oder per SCP/HTTP und Co. – und macht sie mit commit wieder aktiv. Wer automatisch archivieren will, exportiert jede Revision auf einen TFTP-/FTP-/SCP-/SFTP-Server: set system config-management commit-archive "scp://benutzer:passwort@server/verzeichnis".
Die wichtigsten Befehle als Kurzreferenz:
| Befehl | Modus | Wirkung |
|---|---|---|
configure | Operational | In den Konfigurationsmodus wechseln |
set … | Config | Wert im Konfigurationsbaum setzen |
delete … | Config | Wert aus dem Konfigurationsbaum entfernen |
show | Config | Zwischenstand der Änderungen anzeigen |
compare | Config | Diff gegen die aktive Konfiguration (bzw. eine Revision) |
discard | Config | Unbestätigte Änderungen verwerfen |
commit | Config | Änderungen wirksam machen |
commit-confirm [n] / confirm | Config | Riskante Änderung vorläufig anwenden bzw. bestätigen |
save | Config | Dauerhaft nach /config/config.boot sichern |
load <datei> | Config | Konfiguration aus Datei laden (lokal, SCP, HTTP, …) |
rollback <rev> | Config | Frühere Revision wiederherstellen (mit Neustart) |
run <befehl> | Config | Operational-Kommando aus dem Konfig-Modus starten |
show system commit | Operational | Commit-Historie der Revisionen anzeigen |
Wir gehen von einer frisch installierten VyOS-Instanz auf einer x86-Appliance mit mindestens zwei Netzwerkkarten aus, eine Richtung Internet (eth0), eine Richtung LAN (eth1) – das ist der klassische Standortrouter. Alle Schritte nutzen die eben vorgestellten CLI-Konzepte.
configure
set system host-name firewall
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth1 address 192.168.1.1/24
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 range start 192.168.1.100 stop 192.168.1.199
set service dhcp-server shared-network-name LAN subnet 192.168.1.0/24 default-router 192.168.1.1
commit
save
eth0 bezieht seine Adresse vom Provider (DHCP), eth1 ist das Gateway des LANs. Wer keinen DHCP-Server am Router möchte, lässt die drei dhcp-server-Zeilen einfach weg.
Eine Zone gruppiert Schnittstellen mit gleicher Aufgabe. In unserem Szenario:
WAN – unzuverlässige Außenwelt: eth0LAN – internes Netz: eth1LOCAL – der Router selbst: Sitzungen, die für die Firewall bestimmt sind (z. B. SSH, NTP, OSPF)Wichtig bei VyOS: Eine Schnittstelle darf immer nur einer Zone angehören, und Traffic innerhalb einer Zone fließt grundsätzlich frei. Die Security-Grenze ist der Wechsel zwischen Zonen.
configure
set firewall zone LAN interface eth1
set firewall zone LAN default-action drop
set firewall zone WAN interface eth0
set firewall zone WAN default-action drop
set firewall zone LOCAL local-zone
set firewall zone LOCAL default-action drop
commit
save
Für jedes Zonen-Paar werden zwei Regel-Sets definiert – eines pro Richtung (wie das Router-Routing verläuft, dem folgt auch die Politik). Die Namenskonvention <Quelle>-<Ziel>-v4 des VyOS-Handbuchs halten wir konsequent ein.
Wir brauchen vier Sets:
LAN-WAN-v4 – ausgehender Internet-TrafficWAN-LAN-v4 – einfallender Verkehr aus dem InternetLAN-LOCAL-v4 – Zugriff auf den Router (z. B. SSH, DNS)WAN-LOCAL-v4 – Versuche, von außen auf den Router zu kommen (sollen scheitern)Das Regel-Set wird an der Ziel-Zone eingehängt, mit Angabe der Quell-Zone – also set firewall zone LAN from WAN firewall name WAN-LAN-v4 für eingehenden Verkehr vom WAN ins LAN. Zwei Beispiele dazu folgen gleich konkret, erst das Grundprinzip vor Augen:
Im Detail, für unser Beispiel (IPv4):
configure
# LAN → WAN: alles erlauben
set firewall ipv4 name LAN-WAN-v4 default-action accept
# WAN → LAN: nur Antworten und Folgepakete bestehender Verbindungen
set firewall ipv4 name WAN-LAN-v4 default-action drop
set firewall ipv4 name WAN-LAN-v4 rule 10 action accept
set firewall ipv4 name WAN-LAN-v4 rule 10 state established
set firewall ipv4 name WAN-LAN-v4 rule 20 action accept
set firewall ipv4 name WAN-LAN-v4 rule 20 state related
# Zugeordnete Sets an den Zonen einhängen
set firewall zone LAN from WAN firewall name WAN-LAN-v4
set firewall zone WAN from LAN firewall name LAN-WAN-v4
commit
save
Damit haben wir die wichtigste Regel überhaupt: LAN geht raus ins Internet, von außen kommt nichts durch. Verbindungen, die von innen aufgebaut wurden, werden dank Connection Tracking (state established/state related) als Antworten durchgelassen.
Der Zugriff auf den Router selbst läuft über LOCAL. SSH nur aus dem LAN, mit Default-Drop:
configure
set firewall ipv4 name LAN-LOCAL-v4 default-action drop
set firewall ipv4 name LAN-LOCAL-v4 rule 10 action accept
set firewall ipv4 name LAN-LOCAL-v4 rule 10 protocol tcp
set firewall ipv4 name LAN-LOCAL-v4 rule 10 destination port 22
set firewall ipv4 name WAN-LOCAL-v4 default-action drop
set firewall zone LOCAL from LAN firewall name LAN-LOCAL-v4
set firewall zone LOCAL from WAN firewall name WAN-LOCAL-v4
commit
save
Weitere Services, die der Router anbieten soll (DNS-Antworten ins LAN, NTP, DynDNS-Updates), werden als zusätzliche accept-Regeln vor der drop-Standardaktion ergänzt – am besten mit description.
Ohne Source-NAT kann das LAN nicht mit der öffentlichen Adresse von eth0 ins Internet – die Antwortpakete wüssten nicht, wohin. Klassische Konfiguration: alle Pakete aus 192.168.1.0/24, die über eth0 hinausgehen, bekommen als Absenderadresse die WAN-Adresse:
configure
set nat source rule 100 outbound-interface eth0
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade
commit
save
Von hier ist es nur noch ein Schritt zu Port-Forwardings (Destination NAT) – die werden wir in einem der Folgeartikel für Dienste wie Vaultwarden aufgreifen.
Je größer das Netzwerk, desto wichtiger werden Firewall-Gruppen – wiederverwendbare Listen für Adressen, Netze, Ports, Domains oder MAC-Adressen. Statt fünf IPs in fünf Regeln zu wiederholen, definiert man eine Gruppe und referenziert sie einmal:
configure
set firewall group network-group NET-MGMT network 192.168.1.0/24
set firewall group network-group NET-MGMT network 192.168.2.0/24
set firewall group address-group HOSTS-DNS address 10.0.0.53
set firewall group address-group HOSTS-DNS address 10.0.0.54
set firewall group port-group INCOMING-SERVICES port 443
set firewall group port-group INCOMING-SERVICES port 8443
set firewall ipv4 name WAN-LAN-v4 rule 30 action accept
set firewall ipv4 name WAN-LAN-v4 rule 30 protocol tcp
set firewall ipv4 name WAN-LAN-v4 rule 30 destination group port-group INCOMING-SERVICES
set firewall ipv4 name WAN-LAN-v4 rule 30 source group address-group HOSTS-MANAGEMENT
commit
save
Ändert sich die Liste später, genügt eine einzige Stelle – der Inhalt von Gruppen lässt sich sogar mit ! negieren („alles außer …“).
IPv6-Pakete laufen nicht über die IPv4-Regel-Sets. Wer IPv6 nutzt, braucht parallele Sets unter set firewall ipv6 name … und set firewall zone … from … firewall ipv6-name …. Die Namenskonvention endet dann auf -v6 (LAN-WAN-v6). Am einfachsten beginnt man mit default-action drop und ergänzt nur, was wirklich gebraucht wird.
Vor dem „Feuer“ jedes Regel-Sets: aktiviertes Logging ist Gold wert. Pro Regel lässt sich log setzen oder fürs ganze Set default-log – die Auswertung läuft im Betriebsmodus:
show firewall zone-policy
show firewall ipv4 summary
monitor log firewall
Ein Blick in show firewall zone-policy zeigt, welche Zone welche Schnittstellen hat und welche Regel-Sets an den Übergängen hängen. Verwirft eine Regel unerwartet Pakete, erkennt man das im Firewall-Log sofort am gestiegenen Drop-Zähler.
Zwei Praxis-Hinweise aus der VyOS-Doku, die man ignorieren würde, bis man gestolpert ist:
default-action akzeptieren Basis-Ketten (input/forward/output) standardmäßig alles. Zonen und Regel-Sets dagegen droppen standardmäßig. Man sollte nie darauf vertrauen, sondern immer explizit default-action drop setzen.Links, mit denen man direkt weitermacht:
Eine Zonen-basierte Firewall mit VyOS ist überschaubar, durchschaubar und Tausende Euro günstiger als viele kommerzielle Lizenzen – bei vollständiger Kontrolle über die Konfiguration. Wer die Denkweise „Default-Drop plus explizite Ausnahmen“ konsequent anwendet, bekommt damit ein solides Fundament für beliebig viele Standorte. In den nächsten Artikeln gehen wir die naheliegenden Erweiterungen an: Site-to-Site-VPN und Dual-WAN-Failover. Und weil jede Firewall mehr erreicht, wenn sie mit der eigenen Identität verbunden ist, schaut auch unser Beitrag zu kanidm vorbei. Wir richten euch VyOS-Firewalls, Router und komplette Standortnetzwerke ein – vom Konzept bis zum Rollout inklusive Wartung.
