VyOS als Firewall

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.

Was macht VyOS aus?

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:

• Kein Webinterface, weniger Angriffsfläche: Es gibt keine Web-UI, die man selbst absichern, patchen und im Audit erklären muss. Verwaltung läuft über eine skriptbare Kommandozeile.
• Eine Konfiguration, kein Flickwerk: Alle Einstellungen liegen in einer einzigen, als Text exportierbaren Konfiguration. Diese lässt sich in der Versionskontrolle ablegen und per Diff nachvollziehen.
• Kommits wie in einem großen System: 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).
• Mehr als eine Firewall: BGP, OSPF, IS-IS und RIP gehören zum Standardumfang. VyOS ist damit genauso zuhause, wo Routing im großen Stil betrieben wird – im Rechenzentrum, beim Provideranbindungs-Design oder in verteilten Standorten. Dazu kommen IPsec, WireGuard und OpenVPN für den Fernzugriff.
• Performance für den Datenpfad: Die VPP-Implementierung (Vector Packet Processing) stellt einen hochoptimierten Datenweg zur Verfügung, wenn Paketraten über das klassische Linux-Networking hinausgehen sollen.

Einsatzszenarien

VyOS kommt in Unternehmen in ganz unterschiedlichen Rollen zum Einsatz – die CLI und die Denkweise bleiben dabei immer dieselben:

• Standort- und Firmennetzwerk: Die klassische Anwendung als Router und Firewall am Rand des LANs – DHCP, DNS, NAT und QoS in einem Gerät. Genau das Szenario, das wir in diesem Artikel durchgehen.
• Rechenzentrum und Housing: Mit BGP, ECMP und VRF übernimmt VyOS Router-Rollen am Providerrand – etwa als Edge-Router zwischen Kunde und Uplink, mit Policy Routing und sauberer Trennung der Dienste über VRFs. Es ersetzt damit klassische Edge-Boxen in der Rack-Einheit.
• Multi-Site-Firmengruppen: Standortkoppelung über IPsec- oder WireGuard-Tunnel mit klaren Zonen-Regeln zwischen den Filialnetzen – als Hub-and-Spoke oder Full-Mesh.
• Ausfallsichere Anbindung: Uplink-Bündelung mit Failover (Dual WAN), damit ein Provider- oder Leitungsschaden nicht die Produktion stoppt.
• Cloud und Virtualisierung: Als virtuelle Appliance (KVM, VMware, Proxmox oder nativ bei Hyperscalern) übernimmt VyOS Gateway- und Sicherheitsfunktionen im eigenen VPC-Design – gleiche CLI, gleiche Konfiguration, egal wo es läuft.

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.

Open Source und Lizenzmodell

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:

• Nightly & Rolling (kostenlos): Automatisch aus dem 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.
• Stream: Seit 2024 die offizielle Technologie-Vorschau und das Qualitäts-Gate des kommenden LTS – in der Rolle so etwas wie „CentOS Stream". Vierteljährlich veröffentlichte Images, für jeden frei. Anders als beim Rolling sind Config-Syntax und API hier vorwärtskompatibel (Rückbau von Features nur noch über einen formalen Deprecation-Prozess), sodass sich externe Tools und Playbooks stabil auf den künftigen LTS vorbereiten können.
• Release Candidate & Early Production Access (EPA): Nach dem Feature-Freeze folgen RC-Builds und schließlich sehr stabile EPA-Images – der letzte Prüfstand, bevor die finale LTS-Version erscheint.
• LTS (Long Term Support): Über Jahre gepflegte Versionen mit eingefrorenem Funktionsumfang (aktuell z. B. Sagitta 1.4 und Circinus 1.5) und zeitnahen Security-Updates. Offizielle LTS-Images und der zugehörige Quellcode sind bewusst Abonnenten, aktiven Contributor sowie gemeinnützigen und akademischen Institutionen vorbehalten – das ist die Finanzierung des Projekts –, bauen lässt sich das Image aus dem offenen Quellcode aber jederzeit selbst.
• Abonnements On-Premise: Corporate (ein Unternehmen, ein Rechtskreis), Global (Standorte über Ländergrenzen) und Alliance (für IT-Dienstleister/MSPs mit Rechten zur kommerziellen Bereitstellung beim Kunden). Allen gemeinsam: unbegrenzt viele Instanzen mit allen Features und voller Performance – ohne Obergrenzen bei Interfaces oder Durchsatz. Bezahlt wird für Images, Updates und Support (inkl. optionaler SLA-Add-ons), nicht für Lizenzschlüssel im System. Für einzelne Geräte gibt es ein Per-Device-Abo, ein HA-Paar zählt als eine Instanz.
• Cloud: Für AWS, Azure, Google Cloud & Co. gibt es separate Abo-Varianten nach demselben Prinzip.
• VyOS for Good: Bildungseinrichtungen, Hilfsorganisationen und gemeinnützige Projekte bekommen Zugang kostenlos, Startups erhalten Rabatte – ein sinnvolles Programm, das dem Open-Source-Gedanken Rechnung trägt.

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.

Warum eine Zonen-Firewall?

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:

• Klarheit: Man sieht auf einen Blick, was von wo nach wo erlaubt ist.
• Weniger Fehler: Neue Schnittstellen landen in einer Zone, statt $n$ neue Regeln zu erzeugen.
• Sicherheit durch Denkweise: Standard ist „Default-Drop“ – alles, was nicht explizit erlaubt ist, wird verworfen.

In VyOS seit Version 1.4 (und 1.5) ist die Zonen-Firewall vollständig unterstützt, die Konfiguration liegt unter set firewall zone ….

Systemvoraussetzungen und Installation

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.

Erste Schritte in der CLI

VyOS ist bewusst reine CLI-Software – wer Linux oder Cisco-Kommandozeilen gewohnt ist, findet sich sofort zurecht. Zwei Modi sind wichtig:

• Operational Mode (Prompt vyos@vyos$): alltagstaugliche Kommandos wie ping, tracepath, show version oder show system commit.
• Konfigurationsmodus (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:

Grundkonfiguration

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.

Die Zonen festlegen

Eine Zone gruppiert Schnittstellen mit gleicher Aufgabe. In unserem Szenario:

• WAN – unzuverlässige Außenwelt: eth0
• LAN – internes Netz: eth1
• LOCAL – 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

Regel-Sets für die Übergänge

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-Traffic
• WAN-LAN-v4 – einfallender Verkehr aus dem Internet
• LAN-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.

NAT: Internetzugang erst durch Masquerading

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.

Firewall-Gruppen halten das Set übersichtlich

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 nicht vergessen

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.

Testen und Troubleshooting

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:

• Beim Boot initialisieren die Schnittstellen vor der Firewall – es gibt ein kurzes Zeitfenster, in dem ungefilterter Verkehr möglich ist. Interfaces, die nicht sofort gebraucht werden, sollten entsprechend abgesichert sein.
• Ohne gesetztes 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.

Weiterführende Quellen

Links, mit denen man direkt weitermacht:

• Dokumentation: docs.vyos.io – nach Release-Versionen archiviert (aktuelles LTS und rolling)
• Images: Rolling/Nightly frei unter downloads.vyos.io; LTS-Images über Abo bzw. als Contributor
• Hardware Compatibility List: vyos.io/hcl
• Forum und Community: forum.vyos.io sowie das Development-Portal vyos.dev
• Quellcode: github.com/vyos

Fazit

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.