Sophos Firewall VLAN einrichten und testen

Ein VLAN auf der Sophos Firewall ist mehr als eine VLAN ID. Damit das neue Netz wirklich funktioniert, müssen Parent Interface, Switch-Tagging, Zone, IP-Adresse, DHCP, DNS, Device Access, Firewall-Regeln und NAT zusammenpassen.

Der Artikel beschreibt den generischen Sophos-Firewall-Ablauf und die wichtigsten Betriebsentscheidungen rund um Segmentierung, Zone, DHCP, Regeln und Tests. Wenn es um eine konkrete Umsetzung mit UniFi Switches geht, passt der Artikel VLAN auf Sophos Firewall und UniFi Switch konfigurieren. Für Bridge-Sonderfälle nach SFOS 22 ist Sophos Firewall Bridge-VLANs nach SFOS 22 prüfen der bessere Einstieg.

Kurzantwort

Ein VLAN wird auf der Sophos Firewall unter Network > Interfaces > Add interface > Add VLAN erstellt. Danach braucht es meistens:

• eine passende Zone
• eine statische IP-Adresse als Gateway
• DHCP-Server oder DHCP Relay
• DNS-Design
• Device Access für lokale Firewall-Dienste
• Firewall-Regeln für Internet, interne Netze oder Server
• Logging und einen kurzen Abnahmetest

Erst wenn ein Testclient IP-Adresse, Gateway, DNS, erlaubte Verbindungen, blockierte Verbindungen und passende Logeinträge zeigt, ist das VLAN sauber abgenommen.

Wann ein VLAN sinnvoll ist

VLANs trennen Layer-2-Netze logisch voneinander. Auf der Sophos Firewall werden sie oft verwendet, um mehrere Netze über denselben physischen Uplink oder ein LAG zu führen.

Typische Einsatzfälle:

• Client-Netz und Servernetz trennen
• Gäste-WLAN vom internen LAN isolieren
• VoIP-Telefone in ein eigenes Netz legen
• IoT, Kameras oder Drucker begrenzen
• Management-Netz für Admin-PCs, Switches und Monitoring schaffen
• DMZ oder Servernetz über einen gemeinsamen Switch-Uplink führen

Ein VLAN ersetzt aber keine Firewall-Regeln. Es sorgt für die technische Trennung auf Layer 2. Ob Traffic zwischen VLANs erlaubt ist, entscheidet danach die Sophos Firewall über Zonen, Routing, Firewall-Regeln, NAT und Security Policies.

VLAN-Architektur planen

Die wichtigste Frage ist nicht, wie man ein VLAN anlegt. Die wichtigere Frage ist, welche Sicherheitsbereiche es im Netzwerk geben soll. Viele Probleme entstehen, weil VLANs rein technisch erstellt werden: VLAN 10, VLAN 20, VLAN 30. Nach ein paar Monaten weiss niemand mehr, welche Kommunikation erlaubt sein soll und warum bestimmte Netze getrennt wurden.

Wir empfehlen, VLANs zuerst nach Risiko, Funktion und Betriebsverantwortung zu planen. Eine gute Ausgangsstruktur sieht oft so aus:

• Management: Admin-PCs, Switches, Access Points, Monitoring und Controller. Zugriff auf Verwaltungsoberflächen sollte sehr eng kontrolliert sein.
• Clients: Arbeitsplatzgeräte, Notebooks und normale Benutzergeräte. Das ist meist das Standardnetz mit Internetzugriff und gezielten internen Freigaben.
• Server: Domain Controller, Fileserver und Applikationsserver. Server sollten nicht direkt von jedem Client-Netz erreichbar sein.
• Gäste: Gäste-WLAN und externe Geräte. Dieses Netz braucht normalerweise nur Internet und keinen Zugriff auf interne Systeme.
• IoT und Kameras: Kameras, Drucker, Sensoren und Gebäudetechnik. Viele dieser Geräte haben schwache Update- und Sicherheitsmodelle.
• VoIP: Telefone, PBX und SBC. Eigene DHCP-Optionen, QoS und klare Erreichbarkeit sind hier oft hilfreich.
• Backup: Backup-Server, Repositories und Immutable Storage. Die Trennung schützt vor Ransomware und lateraler Bewegung.
• DMZ: Öffentlich erreichbare Systeme oder Reverse Proxies. Exponierte Dienste gehören in einen getrennten Bereich.

Das ist kein starres Schema. Ein kleines Büro braucht nicht zwingend zehn VLANs. Eine Umgebung mit mehreren Standorten, Servern, WLANs, Kameras, Backup-Systemen und externen Zugängen sollte aber nicht alles in ein grosses LAN legen.

Mikrosegmentierung realistisch einordnen

Mikrosegmentierung bedeutet nicht, dass jedes einzelne Gerät ein eigenes VLAN braucht. In der Praxis ist der bessere Start meistens eine saubere Makrosegmentierung: Clients, Server, Management, Gäste, IoT, Backup und DMZ werden getrennt. Danach kann man besonders kritische Systeme feiner segmentieren.

Beispiele für feinere Segmentierung:

• Domain Controller in ein eigenes Server-Subnetz legen.
• Backup-Systeme nur von wenigen Quellen erreichbar machen.
• Kamera-Netz nur zum NVR oder VMS erlauben.
• Drucker nur über Printserver oder definierte Client-Netze erreichbar machen.
• Management-VLAN nur für Admin-Geräte und Monitoring öffnen.

Wichtig ist: Jede zusätzliche Trennung erzeugt auch Betriebsaufwand. Es braucht Regeln, Logs, Tests, Dokumentation und jemanden, der die Ausnahmen pflegt. Gute Segmentierung ist nicht möglichst kompliziert, sondern nachvollziehbar und überprüfbar.

Vorbereitung für ZTNA und moderne Zugriffe

Eine saubere VLAN-Struktur hilft später auch bei ZTNA, VPN, SASE oder anderen Zugriffskonzepten. Wenn interne Anwendungen bereits in klaren Server- oder Applikationsnetzen liegen, kann man Zugriffe gezielter veröffentlichen und muss nicht ein komplettes flaches LAN freigeben.

Für ZTNA ist besonders hilfreich:

• Applikationsserver sind in bekannten Servernetzen.
• Management-Zugriffe sind vom normalen Client-Traffic getrennt.
• DNS-Namen und interne Routen sind sauber dokumentiert.
• Firewall-Regeln zeigen, welche Benutzer- oder Standortgruppen welche Ziele benötigen.
• Alte pauschale LAN to LAN oder Any to Any Regeln werden abgebaut.

Wenn später Sophos ZTNA eingesetzt wird, passt der Einstieg über Sophos ZTNA Gateway planen und erstellen. Die VLAN-Planung ist dafür nicht zwingend Voraussetzung, macht den späteren Betrieb aber deutlich sauberer.

Wie viele VLANs braucht man?

Es gibt keine fixe richtige Anzahl. Man sollte VLANs dort erstellen, wo eine eigene Sicherheitsentscheidung nötig ist.

Ein eigenes VLAN ist meist sinnvoll, wenn mindestens einer dieser Punkte zutrifft:

• Das Netz braucht andere Firewall-Regeln. Dann sollte man eine eigene Zone oder mindestens ein eigenes VLAN-Objekt planen.
• Device Access soll anders aussehen. Eine eigene Zone ist dann oft sauberer.
• DHCP-Optionen unterscheiden sich, etwa bei VoIP, PXE oder Gastnetzen.
• Traffic soll separat geloggt, überwacht oder ausgewertet werden.
• Die Geräte haben ein deutlich anderes Risiko, zum Beispiel IoT, Gäste, Backup oder Management.
• Es gibt andere Verantwortliche oder einen eigenen Betriebsprozess.

Man sollte aber nicht jedes kleine Sonderthema sofort in ein neues VLAN zwingen. Wenn zwei Client-Netze exakt dieselben Regeln, dieselbe Web Policy und denselben Device Access bekommen, kann eine gemeinsame Zone mit klaren Netzwerkobjekten ausreichen.

Vorab planen

Vor dem Anlegen sollte das VLAN kurz dokumentiert werden. Das muss kein grosser Netzplan sein, aber die wichtigsten Werte sollten feststehen.

Ein kompaktes Planungsset reicht oft:

• VLAN Name: zum Beispiel Clients
• VLAN ID: zum Beispiel 100
• Subnetz: zum Beispiel 10.100.0.0/24
• Gateway auf Sophos Firewall: zum Beispiel 10.100.0.1
• Parent Interface: zum Beispiel Port3 oder LAG1
• Zone: zum Beispiel Client, LAN, Guest, Server oder DMZ
• DHCP: Sophos Firewall, DHCP Relay oder externer Server
• DNS: Firewall, interne DNS-Server oder bewusst anderes Design
• Zweck: zum Beispiel Arbeitsplatz-Clients mit Internetzugriff

Besonders wichtig ist die Zone. Diese Einstellung beeinflusst später Firewall-Regeln, Device Access, Web Policies, IPS, Logs und Troubleshooting. Für die grundsätzliche Zonenplanung passt Sophos Firewall Zonen und Interfaces konfigurieren.

Die VLAN ID muss im gültigen Bereich 1 bis 4094 liegen. Auf demselben physischen Parent Interface kann dieselbe VLAN ID nicht mehrfach angelegt werden. In produktiven Netzen sollte man die ID nicht nur technisch vergeben, sondern mit Switch-Konfiguration, WLAN-SSID, DHCP-Scope, Dokumentation und Monitoring gleich benennen. Wenn VLAN 100 auf der Firewall Clients heisst, auf dem Switch aber Office und im DHCP LAN-neu, wird Troubleshooting unnötig mühsam.

Parent Interface und Switch-Tagging verstehen

Das Parent Interface ist der physische Port, die Bridge oder das LAG, auf dem die Sophos Firewall die getaggten VLAN-Pakete empfängt. Die VLAN ID auf der Sophos Firewall muss exakt zu dem passen, was der Switch auf diesem Link sendet.

Typische Designs:

• Physischer Port als Trunk: Ein Switch-Uplink transportiert mehrere VLANs tagged zur Firewall.
• LAG als Trunk: Mehrere physische Ports bilden ein LAG, darauf liegen mehrere VLAN-Interfaces.
• RED-Interface: VLANs können auch auf geeigneten RED-Interfaces geplant werden, wenn der Standortmodus und die Switch-Seite dazu passen.
• Access-Port ohne VLAN-Tag: Ein Endgerät hängt untagged in einem VLAN. Das Tagging passiert am Switch, nicht am Client.
• Bridge mit VLANs: Sonderfall, den man besonders bei Migrationen oder transparenten Designs sorgfältig prüfen sollte.

Wenn ein normaler Client-PC direkt an einem Switch-Port hängt, sendet er normalerweise untagged. Der Switch ordnet diesen Port dann einem VLAN zu. Die Sophos Firewall sieht das VLAN erst auf dem Uplink, wenn der Switch das VLAN tagged zur Firewall transportiert.

Einzelne Ports oder VLAN-Trunk über LAG?

Man kann theoretisch pro VLAN einen eigenen physischen Firewall-Port verwenden. Das ist bei sehr kleinen Installationen verständlich, skaliert aber schlecht. Ports werden knapp, die Verkabelung wird unübersichtlich und Änderungen an Zonen, Switches oder HA werden später mühsamer.

In produktiven Umgebungen ist meistens ein Trunk-Design sauberer:

1. Die Sophos Firewall wird mit einem oder mehreren Core-Switches verbunden.
2. Ein physischer Port oder ein LAG transportiert mehrere VLANs tagged.
3. Auf der Firewall werden pro VLAN eigene VLAN-Interfaces auf diesem Parent Interface erstellt.
4. Die Firewall bleibt Default Gateway für die VLANs und entscheidet über Routing und Security Policies.

Unsere bevorzugte Variante ist oft ein LAG mit zwei schnellen Uplinks, zum Beispiel 2x SFP+, sofern Firewall und Switches das sinnvoll unterstützen. Darauf laufen dann die VLANs als getaggte Interfaces. Das bringt nicht automatisch doppelte Geschwindigkeit für eine einzelne Session, aber mehr Redundanz, mehr Reserven und ein klareres Design als viele einzelne Kupferports pro VLAN.

Die wichtigsten Varianten:

• Pro VLAN ein eigener Firewall-Port: leicht zu verstehen und mit wenig VLAN-Wissen umsetzbar. Es skaliert aber schlecht, braucht viele Ports und macht die Verkabelung schnell unübersichtlich.
• Ein Trunk-Port mit VLANs: einfach, sauber und mit wenigen Kabeln. Der einzelne Uplink bleibt aber ein Single Point of Failure.
• LAG mit VLAN-Trunk: redundant, sauber und gut skalierbar. Switch und Firewall müssen LAG beziehungsweise LACP korrekt unterstützen.
• Routing auf Core-Switch: sehr performant in grossen Netzen. Die Firewall sieht internen Ost-West-Traffic dann aber nicht mehr vollständig.

Für viele KMU- und Mittelstandsnetzwerke ist Firewall als Default Gateway für die VLANs die bessere Sicherheitsentscheidung. Dann läuft interner Traffic zwischen VLANs über die Sophos Firewall und kann mit Firewall-Regeln, IPS, Web Policies, Logging und späteren Security-Funktionen kontrolliert werden. Routing auf dem Core-Switch kann sinnvoll sein, wenn sehr hoher interner Ost-West-Durchsatz nötig ist. Dann muss man aber bewusst akzeptieren, dass die Firewall nicht mehr jede interne Kommunikation sieht.

Als Faustregel:

• Sicherheitsorientiert und übersichtlich: VLAN-Gateways auf der Sophos Firewall.
• Sehr hohe interne Performance: Routing auf Core-Switch prüfen, aber Security-Zonen und ACLs sauber ergänzen.
• Neue Installationen: VLANs über Trunk oder LAG zur Firewall führen, nicht pro VLAN einen einzelnen Port verschwenden.
• Kleine Standorte: Ein einzelner Trunk-Port kann reichen, wenn Redundanz nicht gefordert ist.

Häufige Missverständnisse:

• Das VLAN ist auf der Firewall erstellt, aber der Switch-Uplink transportiert es nicht.
• Das VLAN ist am Access-Port tagged, obwohl der Client untagged erwartet.
• Die VLAN ID stimmt auf Switch und Firewall nicht überein.
• Das VLAN wurde auf dem falschen Parent Interface angelegt.
• Das Parent Interface wurde als normaler Access-Port statt als Trunk betrieben.
• Auf dem Parent Interface wurde bereits ein VLAN erstellt, danach soll der physische Port spontan auf DHCP oder PPPoE umgestellt werden. Solche Änderungen müssen vorher geplant werden, weil Sophos die IP-Zuweisung eines statischen physischen Interfaces nach VLAN-Konfiguration nicht beliebig auf DHCP oder PPPoE ändern lässt.

VLAN-Interface erstellen

Menüpfad:

Network > Interfaces > Add interface > Add VLAN

Vorgehen:

1. Name vergeben, zum Beispiel Clients VLAN 100.
2. Als Interface das Parent Interface auswählen, zum Beispiel Port3 oder LAG1.
3. Network zone bewusst wählen.
4. VLAN ID eintragen, zum Beispiel 100.
5. Unter IPv4 configuration meistens Static verwenden.
6. IP-Adresse und Subnetzmaske eintragen, zum Beispiel 10.100.0.1/24.
7. Speichern.

Für interne VLANs ist die Firewall-IP meistens das Default Gateway der Clients. Wenn ein anderes System routet oder die Firewall nur bestimmte Netze sieht, muss dieses Design ausdrücklich dokumentiert werden. Sonst sucht man später bei Firewall-Regeln, obwohl der Client die Sophos Firewall gar nicht als Gateway verwendet.

Nach dem Speichern sollte man unter Network > Interfaces das Parent Interface aufklappen oder den Filter VLAN verwenden. Sophos zeigt VLAN-Interfaces unterhalb des Parent Interface und zusätzlich in der VLAN-Ansicht. Der automatisch erzeugte Hardware-Name basiert auf Parent Interface und VLAN ID; für den Betrieb ist aber vor allem der sprechende Interface-Name wichtig, weil dieser in anderen Einstellungen, Logs und Regeln auftaucht.

Für Firewall-Regeln sollte zusätzlich ein passendes Netzwerkobjekt angelegt werden:

Hosts and services > IP host

Beispiel:

• Name: NET_Client_VLAN100
• IP version: IPv4
• Type: Network
• IP address: 10.100.0.0
• Subnet: /24

Solche Objekte machen Regeln, Logsuche und spätere Reviews deutlich klarer als rohe IP-Bereiche in jeder einzelnen Regel.

DHCP und DNS einrichten

Nach dem VLAN-Interface braucht es eine Entscheidung zur Adressvergabe.

• DHCP auf Sophos Firewall: passend für einfache Standorte, Client-, Gäste-, IoT- oder VoIP-Netze.
• DHCP Relay: sinnvoll bei zentralem Windows-DHCP-Server oder bestehender DHCP-Infrastruktur.
• Externer DHCP-Server im VLAN: Spezialfall, wenn ein Server direkt im VLAN zuständig ist.
• Statische IPs: passend für kleine Server-, Management- oder Infrastruktur-Netze.

DHCP auf der Sophos Firewall wird unter Network > DHCP erstellt. Wichtig sind Interface, Range, Gateway, DNS-Server und Suchdomain. Sonderoptionen wie PXE, VoIP oder herstellerspezifische Werte sind in Sophos Firewall DHCP Options konfigurieren beschrieben.

Sophos Firewall kann DHCP-Server und DHCP-Relay auf physischen und virtuellen Interfaces wie VLANs, Wireless Networks und Bridges konfigurieren. Auf Alias-Interfaces ist das nicht der richtige Ort. Wenn DHCP über VPN-Strecken geplant wird, muss zusätzlich geprüft werden, ob das konkrete VPN-Design DHCP Relay unterstützt; bei route-based VPNs ist das nicht automatisch gegeben.

Beim DNS-Design sollte man klar entscheiden, ob Clients die Sophos Firewall als DNS-Forwarder verwenden oder direkt interne DNS-Server fragen. Wenn die Firewall als DNS-Forwarder dient, müssen interne Domains oft über DNS Request Routes auf Sophos Firewall an die richtigen DNS-Server weitergeleitet werden.

Device Access prüfen

Device Access steuert lokale Dienste der Sophos Firewall. Das ist nicht dasselbe wie eine Firewall-Regel zwischen VLANs.

Typische Beispiele:

• Clients sollen die Firewall als DNS-Server verwenden: DNS für die Zone erlauben.
• Troubleshooting soll Ping auf die Firewall erlauben: Ping/Ping6 bewusst freigeben.
• Normale Client-, Gäste- oder IoT-VLANs sollen keinen WebAdmin- oder SSH-Zugriff haben.
• Management-Zugriff sollte über ein eigenes Admin-Netz oder Local Service ACL Exception Rules laufen.

Der genaue Ablauf steht in Sophos Firewall Zugriff absichern: Device Access richtig konfigurieren.

Firewall-Regeln und NAT ergänzen

Ein neues VLAN braucht danach passende Firewall-Regeln. Ohne Regel kann ein Client zwar eine IP-Adresse bekommen, aber nicht automatisch ins Internet oder in andere interne Netze.

Eine einfache erste Internet-Regel könnte so aussehen:

• Rule name: Clients_to_WAN
• Source zones: Client oder LAN
• Source networks: VLAN-Netz, zum Beispiel 10.100.0.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: bewusst benötigte Dienste, nicht automatisch Any
• Log firewall traffic: aktiviert

Für interne Zugriffe sollten separate Regeln erstellt werden. Ein Gäste-, IoT- oder Kamera-VLAN sollte nicht pauschal ins Server- oder Management-Netz dürfen. Die Regelplanung ist in Sophos Firewall-Regeln verstehen und sicher konfigurieren ausführlicher beschrieben.

NAT ist nicht für jeden VLAN-Verkehr nötig. Für normalen Internetzugriff wird häufig die bestehende MASQ- oder SNAT-Regel verwendet. Zwischen internen VLANs ist NAT meistens falsch, weil Zielsysteme dann nicht mehr die echte Client-IP sehen. Die Einordnung steht in NAT auf Sophos Firewall verstehen: SNAT, DNAT, MASQ, PAT.

Abnahmetest

Ein VLAN ist erst dann fertig, wenn der Paketfluss bewiesen ist. Ein einzelner Ping reicht dafür nicht.

Sinnvoller Testablauf:

1. Testclient an den vorgesehenen Switch-Port oder die vorgesehene SSID hängen.
2. Prüfen, ob der Client eine IP-Adresse aus dem richtigen VLAN erhält.
3. Gateway, DNS-Server und Suchdomain prüfen.
4. Firewall-IP im VLAN pingen, falls Ping erlaubt ist.
5. DNS-Auflösung für interne und externe Namen testen.
6. Erlaubten Internetzugriff testen.
7. Erlaubten internen Zugriff testen, falls vorgesehen.
8. Bewusst nicht erlaubten internen Zugriff testen und Block im Log Viewer prüfen.
9. Im Log Viewer Rule ID, Source zone, Destination zone und NAT ID kontrollieren.
10. Bei Unklarheit Packet capture auf dem VLAN-Interface verwenden.

Für die Auswertung mit Log Viewer, Policy Test und Packet Capture passt Sophos Firewall Regel testen mit Log Viewer, Policy Test und Packet Capture.

Typische Fehler

• VLAN nicht am Switch-Uplink erlaubt: Der Client bekommt keine IP-Adresse oder erreicht das Gateway nicht. Trunk beziehungsweise tagged VLAN am Switch prüfen.
• Falsches Parent Interface: Die Firewall sieht den Traffic nicht. VLAN-Interface und physische Verkabelung vergleichen.
• VLAN ID auf demselben Parent Interface bereits vorhanden: Sophos Firewall erlaubt dieselbe VLAN ID nicht zweimal auf demselben physischen Interface. In diesem Fall vorhandene VLAN-Interfaces prüfen, statt ein Duplikat anzulegen.
• Client-Port tagged statt untagged: Normale Clients landen nicht im VLAN. Access-Port- oder Native-VLAN-Profil prüfen.
• DHCP fehlt oder falscher DHCP antwortet: Der Client bekommt keine oder eine falsche IP-Adresse. DHCP-Leases und Packet Capture auf UDP 67/68 prüfen.
• Kein IP-Host-Objekt für das VLAN: Regeln enthalten rohe Netze oder falsche Objekte. IP host unter Hosts and services sauber anlegen und in Regeln verwenden.
• DNS Device Access fehlt: IP-Traffic funktioniert, Namensauflösung aber nicht. Device Access und Client-DNS prüfen.
• Falsche Zone gewählt: Regeln oder Policies greifen nicht wie erwartet. Interface-Zone und Firewall-Regeln vergleichen.
• Firewall-Regel fehlt: Der Client hat eine IP-Adresse, aber Traffic wird blockiert. Log Viewer und Rule ID prüfen.
• NAT zwischen internen VLANs: Zielsysteme sehen eine falsche Source-IP. NAT-Regeln prüfen und interne NAT-Ausnahmen planen.

Wenn eine Regel nicht matched, liegt das Problem oft bei Zone, Source Network, Gateway oder Switch-Tagging. Der Artikel Sophos Firewall Regel greift nicht: Ursachen prüfen hilft bei der Abgrenzung.

Betriebscheck

Für produktive VLANs sollte nicht nur die Erstkonfiguration stimmen. Entscheidend ist, dass spätere Admins nachvollziehen können, warum das VLAN existiert und welche Regeln dazu gehören.

Dokumentieren sollte man:

• VLAN ID, Name und Subnetz
• Parent Interface und Switch-Uplink
• automatisch erzeugter Hardware-Name und sprechender Interface-Name
• Zone und Sicherheitszweck
• IP-Host-Objekt für Firewall-Regeln
• DHCP-Quelle und DNS-Server
• erlaubte Zielzonen und Dienste
• NAT-Entscheidung
• zuständiger Owner
• Testclient oder Testverfahren
• Datum der letzten Regelprüfung

Bei grösseren Umgebungen lohnt sich zusätzlich eine einfache Zugriffsmatrix. Eine solche Matrix zeigt, welche VLANs miteinander sprechen dürfen und welche bewusst getrennt bleiben.

Eine einfache Zugriffsmatrix kann so aussehen:

• Clients zu Internet: erlaubt mit Web Policy, DNS Protection und Logging.
• Clients zu Server: nur definierte Applikationsports.
• Gäste zu intern: blockiert.
• IoT zu Internet: nur benötigte Ziele und Ports.
• IoT zu Server: nur zu NVR, Printserver oder Managementsystemen.
• Management zu Infrastruktur: erlaubt für Admin-Protokolle.
• Backup zu Server: gezielt erlaubt, Rückrichtung stark begrenzen.

Diese Matrix ist oft wichtiger als die VLAN-Liste selbst. Dadurch wird verhindert, dass später wieder pauschale Regeln entstehen, die die Segmentierung faktisch aushebeln.

Häufige Fragen