Sophos Firewall zones en interfaces configureren

Zones en interfaces horen bij de belangrijkste basisconcepten van een Sophos Firewall. Wie ze goed plant, maakt latere firewall regels, NAT, VPN, Web Protection en troubleshooting veel eenvoudiger. Wie ze te snel aanklikt, bouwt vaak een omgeving waarin regels onoverzichtelijk worden of managementdiensten op verkeerde plaatsen bereikbaar zijn.

Een zone is een logische beveiligingsgroep. Een interface is een fysieke of virtuele aansluiting, bijvoorbeeld Port1, een VLAN, een Bridge, een LAG, een Alias, een RED-interface of een XFRM-interface voor route-based VPN. Elke interface is precies aan één zone gekoppeld. Firewall regels werken later sterk met deze zones, daarom moet de zonestructuur niet alleen technisch, maar ook vanuit security worden gepland.

Waarom zones belangrijk zijn

Zones zijn op Sophos Firewall meer dan een visuele groepering. Ze definiëren securitygebieden en worden op meerdere plaatsen gebruikt:

• Firewall regels gebruiken Source zone en Destination zone.
• Device Access bepaalt per zone welke lokale firewall-diensten bereikbaar zijn.
• NAT, SD-WAN, VPN, Web Protection en logs zijn met duidelijke zones eenvoudiger te begrijpen.
• Troubleshooting wordt overzichtelijker, omdat men direct ziet uit welk securitygebied een pakket komt en waar het naartoe moet.

Een goede zonering voorkomt niet automatisch elke fout, maar dwingt wel tot duidelijke grenzen. Een clientnetwerk, servernetwerk, gasten-WiFi en DMZ moeten niet allemaal als LAN worden behandeld wanneer ze verschillende risico’s en regels hebben. Anders ontstaan later te brede Allow-regels, onduidelijke uitzonderingen en onnodig open managementtoegang.

Goede zones beantwoorden altijd deze vraag: welke netwerken hebben hetzelfde vertrouwensniveau en mogen op dezelfde manier worden behandeld? Als twee netwerken verschillende rechten, logging-eisen of managementtoegang nodig hebben, is een eigen zone of minstens een heel bewust regelconcept zinvol.

Standaardzones begrijpen

Sophos Firewall levert meerdere standaardzones mee:

De standaardzones vindt men onder Network > Zones. Eigen zones kunnen als type LAN of DMZ worden aangemaakt. Extra WAN- of VPN-zones kunnen niet vrij worden aangemaakt, omdat deze zonetypen speciale functies in de firewall hebben.

Belangrijk: een zone is geen automatische toestemming. Ook tussen twee interfaces in dezelfde zone zijn, afhankelijk van richting en scenario, passende firewall regels nodig. Sophos wijst er in de documentatie expliciet op dat traffic tussen twee LAN-zone-interfaces niet automatisch is toegestaan, maar een passende LAN-to-LAN-regel nodig heeft.

Zones plannen voordat ze worden aangemaakt

Voor het aanmaken moet men noteren welke netwerken verschillende security-eisen hebben. Typische voorbeelden:

• Werkplek-LAN
• Servernetwerk
• Managementnetwerk
• DMZ
• Gasten-WiFi
• VoIP
• Camera- of IoT-netwerk
• Productienetwerk
• VPN-clients
• MPLS- of locatieverbindingen

Een eigen zone is zinvol wanneer een netwerk eigen regels, eigen Device Access of een ander vertrouwensniveau nodig heeft. Meerdere VLANs kunnen ook in dezelfde zone liggen als ze gelijk behandeld worden. Te veel zones maken een configuratie niet automatisch veiliger. Ze helpen alleen als er duidelijke regels achter zitten.

Voor veel kleine en middelgrote omgevingen is deze basisstructuur een goed begin:

Niet elke VLAN heeft automatisch een eigen zone nodig. Als meerdere client-VLANs exact dezelfde firewall regels, dezelfde Web Policy en dezelfde Device Access krijgen, kunnen ze in één gezamenlijke clientzone blijven. Maar als één VLAN servers mag bereiken, een andere alleen internet, en een derde helemaal geen toegang tot lokale firewall-diensten mag hebben, moet die scheiding bewust gemodelleerd worden.

Een goed patroon is:

Nieuwe zone aanmaken

Open Network > Zones en klik op Add.

1. Geef een korte, duidelijke naam, bijvoorbeeld Server, Guest, Management of MPLS.
2. Kies als type LAN of DMZ.
3. Bepaal onder Device Access bewust welke lokale diensten van de firewall vanuit deze zone bereikbaar mogen zijn.
4. Sla op.

LAN of DMZ als zonetype?

Bij eigen zones kan men op Sophos Firewall meestal kiezen tussen LAN en DMZ. Beide typen groeperen interfaces zodat ze later netjes in regels, Device Access en policies gebruikt kunnen worden. Het verschil zit vooral in het security-idee achter de zone.

LAN gebruikt men voor interne, in principe vertrouwde netwerken. Denk aan clientnetwerken, interne servernetwerken, managementnetwerken, VoIP, printers of interne VLANs. Ook bij een LAN-zone geldt: traffic tussen interfaces is niet automatisch toegestaan. Als twee LAN-zones of twee interfaces binnen een LAN-zone met elkaar moeten praten, zijn passende firewall regels nodig.

DMZ gebruikt men voor netwerken met hoger risico of duidelijke isolatie. Typische voorbeelden zijn publiek bereikbare webservers, reverse proxies, mail gateways, jump hosts of systemen die vanuit meerdere securitygebieden bereikbaar moeten zijn. Een DMZ moet zo gepland worden dat ze alleen de noodzakelijke verbindingen naar binnen krijgt. Als een server in de DMZ wordt gecompromitteerd, mag daaruit niet automatisch brede toegang naar het interne LAN ontstaan.

Als eenvoudige vuistregel:

HA-interfaces horen eveneens in een DMZ-zone. Voor normale admin- of clientnetwerken is LAN meestal het passendere type.

Voor een intern adminnetwerk kan HTTPS zinvol zijn. Voor normale client- of gastnetwerken moet managementtoegang worden vermeden. Ping/ping6 is voor troubleshooting vaak nuttig, maar moet bewust geactiveerd worden. DNS is alleen nodig als clients in deze zone de firewall als DNS-server gebruiken.

⚠️ Device Access is niet hetzelfde als een firewall regel. Toegang tot lokale diensten van de firewall, bijvoorbeeld WebAdmin, SSH, User Portal, DNS of Ping, wordt via Administration > Device access en lokale ACL-uitzonderingen geregeld.

Interface configureren

Interfaces vindt men onder Network > Interfaces. Een fysieke poort kan bijvoorbeeld als LAN, WAN of DMZ worden gebruikt. Virtuele interfaces zoals VLAN, Bridge, LAG, RED of XFRM worden aanvullend aangemaakt.

Voor een fysieke interface zijn deze punten bijzonder belangrijk:

Alleen interfaces in de WAN zone krijgen een gateway-configuratie. Interne interfaces worden meestal statisch geadresseerd. Bij providerverbindingen kan DHCP of PPPoE zinvol zijn.

Beschrijvende namen zijn belangrijk. PortD zegt over zes maanden weinig. Server VLAN, MPLS Provider, Guest WiFi of Core Switch Trunk helpen in de praktijk veel meer.

VLAN-interface aanmaken

Een VLAN-interface maakt men aan onder Network > Interfaces > Add interface > Add VLAN. Vooral Parent Interface, Zone, VLAN ID en IP-configuratie zijn belangrijk.

De Parent Interface is de fysieke poort of een LAG waarop de getagde VLAN aankomt. Als de switch de VLAN op een andere poort, untagged of met verkeerde VLAN ID verstuurt, ziet de firewall wel een VLAN-interface, maar bereiken clients die niet betrouwbaar.

Voor interne VLANs gebruikt men meestal een statisch IP-adres op de firewall, bijvoorbeeld als Default Gateway voor deze VLAN. De zone bepaalt later welke firewall regels, Web Policies en Device Access instellingen gelden. Daarom moet men bij het aanmaken van een VLAN niet alleen het IP-adres invullen, maar meteen bedenken of de VLAN eerder bij Client, Server, Management, Guest, DMZ of een andere zone hoort.

Interface-status correct lezen

Onder Network > Interfaces toont Sophos Firewall statusmeldingen. Deze meldingen zijn bij troubleshooting erg nuttig, omdat men snel ziet of een interface alleen verkeerd geconfigureerd is of dat er echt geen link bestaat.

Als een interface onverwacht Not configured of Unplugged toont, moet men niet eerst firewall regels zoeken. Eerst controleert men Zone Binding, link, SFP/transceiver, kabel, switchpoort en bij DHCP/PPPoE de adressering.

VLAN, Bridge, LAG, Alias en RED plaatsen

Sophos Firewall ondersteunt verschillende interface-typen. Voor beginners is vooral belangrijk wanneer welk type zinvol is.

Voor nieuwe installaties is VLAN op een duidelijk gedefinieerde uplink naar de switch meestal netter dan een grote Bridge over veel poorten. Een Bridge kan bij migraties of zeer eenvoudige setups praktisch zijn, omdat meerdere poorten als één gezamenlijk Layer-2-segment worden behandeld. Precies dat is ook het nadeel: securitygrenzen, broadcast-domeinen en foutbronnen zijn minder duidelijk zichtbaar.

We raden Bridges daarom alleen gericht aan en niet als standaarddesign. In de praktijk hebben Bridges meerdere nadelen:

• Meerdere poorten delen hetzelfde Layer-2-segment, waardoor broadcasts en storingen makkelijker meerdere apparaten raken.
• Firewall regels worden minder overzichtelijk, omdat de scheiding niet meer duidelijk via eigen interfaces, VLANs en zones zichtbaar is.
• Troubleshooting wordt moeilijker, omdat packet flow, MAC learning, STP-thema’s en switchconfiguratie samen bekeken moeten worden.
• Latere segmentatie wordt lastiger wanneer uit een eenvoudige Bridge later toch gescheiden client-, server-, gast- of managementnetwerken moeten ontstaan.
• HA-, VLAN-, DHCP- of Device Access-designs worden snel onoverzichtelijk wanneer te veel functies via een Bridge lopen.

Bridges kunnen op Sophos Firewall via fysieke interfaces, RED interfaces, VLANs of LAGs worden aangemaakt. Ze kunnen met of zonder eigen IP-adres werken. Juist hier ontstaan vaak misverstanden:

• Zonder IP-adres werkt de Bridge transparant, maar kan ze niet als normale routed interface worden gebruikt.
• Als routing op een Bridge nodig is, moet de Bridge een IP-adres krijgen.
• Voor traffic tussen Bridge members zijn nog steeds passende firewall regels tussen de betrokken zones nodig, bijvoorbeeld LAN naar LAN.
• STP kan zinvol zijn als redundante paden bestaan en bridge loops voorkomen moeten worden.
• VLAN filters en EtherType filters kunnen helpen om Layer-2-traffic door een Bridge te beperken.
• Sophos wijst erop dat traffic via Bridge interfaces zonder IP-adres kan worden gedropt wanneer die een firewall regel met Web Proxy Filtering of een NAT regel raakt. Zulke drops worden niet gelogd. Bij NAT moet men dan extra letten op Source Translation of Override Source Translation.

Dit laatste punt is belangrijk: als men via een Bridge plots geen logs ziet hoewel traffic niet werkt, ligt het probleem niet altijd bij de Log Viewer. Het kan liggen aan de Bridge-modus, NAT of Web Proxy Filtering.

Als er al VLANs op de switch bestaan, moet de firewall deze VLANs bewust als eigen VLAN-interfaces overnemen. Dat geeft duidelijkere zones, schonere firewall regels en is op lange termijn meestal beter onderhoudbaar.

RED Bridge: netwerk over locaties heen strekken

Het is technisch mogelijk om RED-interfaces in een Bridge op te nemen en daarmee een Layer-2-netwerk over meerdere locaties te strekken. Dat kan in speciale gevallen helpen, bijvoorbeeld wanneer een applicatie verplicht in hetzelfde subnet moet blijven of bij een migratie zonder directe IP-wijzigingen.

We zouden dit design slechts zeer terughoudend aanbevelen. Een Bridge over RED verlengt het Layer-2-domein over de tunnel. Broadcasts, ARP, unknown unicast packets en andere Layer-2-effecten lopen dan over een WAN- of internetverbinding. Dat kan de performance verslechteren en fouten moeilijker traceerbaar maken. Als de RED-tunnel instabiel is, heeft dat direct effect op het gestrekte netwerk.

Beter is in de meeste gevallen een routed design: elke locatie heeft eigen subnetten, de firewall routeert tussen de netwerken en firewall regels bepalen gericht wat is toegestaan. Dat is schoner, beter schaalbaar en bij troubleshooting veel prettiger.

LAG: redundantie en bandbreedte goed plannen

Een Link Aggregation Group (LAG) voegt meerdere fysieke poorten samen tot één logische interface. Dat is zinvol als men redundantie naar de core switch nodig heeft of meer bandbreedte tussen firewall en switch wil leveren. LAG vervangt echter geen nette zonering. Het LAG-interface is uiteindelijk nog steeds één interface waarop men bijvoorbeeld VLANs gebruikt of een zone toewijst.

Sophos Firewall ondersteunt vooral twee typische modi:

Belangrijk: LACP werkt alleen netjes als de tegenpartij correct is geconfigureerd. Op de switch moeten de poorten in dezelfde LAG-groep liggen, dezelfde snelheid en duplexmodus gebruiken en passen bij de firewallconfiguratie. Als men alleen op de firewall een LAG maakt maar de switch niet passend configureert, ontstaan vaak moeilijk verklaarbare packet loss of asymmetrische verbindingsproblemen.

Voor LAGs gelden enkele praktische grenzen:

• Een LAG bestaat op Sophos Firewall uit twee tot vier fysieke interfaces.
• Alleen unbound fysieke interfaces met statische configuratie zijn geschikt als members.
• PPPoE-, Cellular-WAN- en WLAN-interfaces kunnen niet als LAG-members worden gebruikt.
• Bij LACP (802.3ad) moeten member ports hetzelfde type en dezelfde snelheid hebben.
• De xmit-hash-policy bepaalt hoe sessions over de links verdeeld worden. Eén TCP-session wordt daardoor normaal gesproken niet plots sneller, omdat die meestal op één link blijft.

Voor kleine omgevingen is één nette trunk port vaak voldoende. LAG loont vooral wanneer de core switch redundant aangesloten moet worden, veel VLANs over dezelfde uplink lopen of de firewall werkelijk meer doorvoer naar de switch nodig heeft.

XFRM: route-based IPsec als interface begrijpen

Een XFRM-interface hoort bij route-based IPsec VPN. Ze wordt niet zoals een normale VLAN of fysieke poort gepland, maar ontstaat in de context van een IPsec-verbinding. Sophos Firewall maakt automatisch een XFRM-interface aan wanneer bij een IPsec-verbinding zowel de lokale als de remote subnetten op Any staan.

Dat is een belangrijk verschil met klassieke policy-based IPsec-tunnels. Bij route-based VPN bepaalt niet alleen de IPsec Policy, maar ook routing, firewall regels en de XFRM-interface waar traffic heen gaat. Dat maakt complexere locatieverbindingen flexibeler, maar vraagt om duidelijke planning:

• De XFRM-interface ligt in de zone VPN.
• Onder Administration > Device access moet voor de WAN zone IPsec toegestaan zijn, zodat de verbinding kan worden opgebouwd.
• Als lokale of remote subnetten niet Any zijn, wordt geen XFRM-interface gemaakt.
• MTU en MSS zijn bij route-based VPN extra belangrijk omdat IPsec overhead toevoegt.
• Een XFRM-interface wordt niet direct onder Network > Interfaces uitgeschakeld, maar via de bijbehorende IPsec-verbinding onder Site-to-site VPN > IPsec.

Voor admins is XFRM vooral relevant wanneer SD-WAN-routing, dynamic routing of meerdere netwerken via een locatietunnel netjes gestuurd moeten worden. Als men alleen een zeer eenvoudige Site-to-Site-verbinding met twee vaste netwerken nodig heeft, is een klassieke policy-based tunnel vaak eenvoudiger te begrijpen.

RED: externe locaties als eigen interfaceconcept

RED-interfaces zijn geen normale switchpoort. RED staat voor Remote Ethernet Device en wordt gebruikt om een externe locatie via een versleutelde tunnel met de Sophos Firewall te verbinden. Dit kan met dedicated SD-RED-hardware of met Firewall-to-Firewall RED-verbindingen.

Voor de planning moet duidelijk zijn welke bedrijfsmodus nodig is:

Voor veel bedrijven is Standard/Unified de schoonste variant wanneer de locatie volledig via de centrale firewall beschermd moet worden. Het nadeel is duidelijk: valt de RED-tunnel uit, dan verliest de locatie afhankelijk van het design ook centraal beheerde internettoegang. Standard/Split vermindert deze afhankelijkheid, maar betekent ook dat lokale internettraffic niet meer volledig via de centrale Sophos Firewall gefilterd en gelogd wordt.

Bij RED moet men deze punten vroeg controleren:

• De RED-service moet onder System services > RED geactiveerd zijn.
• Voor de verbinding zijn meestal TCP 3400, UDP 3410 en NTP 123 nodig.
• SD-RED-apparaten hebben correcte tijd nodig, anders kunnen TLS handshake en tunnelopbouw mislukken.
• Bij eerste ingebruikname is DHCP op de uplink meestal eenvoudiger, omdat het apparaat de provisioning moet bereiken.
• VLANs zijn niet in elke RED-modus even zinvol. Standard/Split en Transparent/Split zijn niet bedoeld voor VLAN-tagged frames. Als VLANs achter een SD-RED nodig zijn, moet men de bedrijfsmodus bijzonder zorgvuldig kiezen.
• Als een RED-apparaat achter een providerrouter staat, moeten uitgaande verbindingen en DNS/NTP werken.

RED is erg praktisch voor kleine locaties, maar moet niet als een normale LAN-kabel worden behandeld. Beslissend is of de locatie centraal beschermd, lokaal autonoom of slechts gedeeltelijk via de tunnel gekoppeld moet zijn. Die keuze beïnvloedt DHCP, DNS, VLANs, routing, firewall regels, logging en troubleshooting.

Device Access netjes beperken

Onder Administration > Device access ziet men welke lokale diensten van de firewall vanuit welke zones bereikbaar zijn. Daartoe behoren onder andere:

• HTTPS
• SSH
• User Portal
• VPN Portal
• DNS
• Ping/Ping6
• Captive Portal
• STAS
• Wireless Protection

Voor productieomgevingen geldt: hoe minder lokale diensten vanuit een zone bereikbaar zijn, hoe beter. Vooral HTTPS en SSH mogen alleen vanuit vertrouwde managementnetwerken of via een Local service ACL exception rule worden toegestaan.

Als SSH nodig is, helpt deze handleiding: SSH-verbinding met Sophos Firewall maken.

Afhankelijkheden in gedachten houden

Wijzigingen aan interfaces zijn zelden geïsoleerd. Sophos wijst erop dat interfacewijzigingen afhankelijke configuraties kunnen raken, bijvoorbeeld:

• Zone Binding
• DNS
• Gateways
• SD-WAN routes
• Interface-gebaseerde hosts
• VLAN-interfaces
• Dynamic DNS
• Firewall regels
• NAT regels

Voor grotere wijzigingen moet men daarom onder Object usage controleren waar een interface, zone of host-object al gebruikt wordt. Sophos Firewall toont het gebruik van objecten en linkt direct naar veel afhankelijke configuraties.

Bij deactiveren of verwijderen moet men bijzonder voorzichtig zijn:

• Als een interface wordt gedeactiveerd, blijft de configuratie behouden en blijft de status zichtbaar.
• Site-to-site IPsec tunnels waarbij de firewall initiator is, worden direct verbroken.
• Site-to-site IPsec tunnels als responder en Remote Access verbindingen verbreken uiterlijk door inactiviteit of Dead Peer Detection.
• Alias- en XFRM-interfaces kunnen niet direct zoals normale interfaces worden gedeactiveerd. Alias-interfaces volgen de fysieke interface, XFRM-interfaces worden via Site-to-site VPN > IPsec gedeactiveerd.
• Als een virtuele interface wordt verwijderd, kunnen afhankelijke firewall regels, DHCP-configuraties, ARP-items, routes, interface-hosts en andere verwijzingen mee verwijderd worden.

Daarom moet men voor het verwijderen altijd controleren of de interface in firewall regels, NAT regels, DHCP, routing, SD-WAN, Dynamic DNS of host-objecten wordt gebruikt. Onzorgvuldig verwijderen kan meer weghalen dan alleen de interface zelf.

Typische valkuilen

Interface is unbound of disabled: controleer of een zone is toegewezen. Een fysieke interface kan niet worden verwijderd, maar de configuratie kan worden verwijderd door de zone op None te zetten.

VLAN werkt niet: controleer VLAN ID, switchpoort, Tagged/Untagged-configuratie, Native VLAN en of de VLAN op de juiste Parent Interface is aangemaakt.

Clients bereiken de firewall niet via Ping of HTTPS: controleer niet eerst normale firewall regels. Controleer Administration > Device access en lokale ACL-uitzonderingen.

Traffic tussen twee interne netwerken werkt niet: controleer Source zone, Destination zone, netwerkobjecten, routing en de positie van de firewall regel.

WAN-gateway wordt niet actief: controleer IP-configuratie, Gateway-IP, link status, PPPoE-gegevens, DNS en eventueel WAN link manager.

Meerdere WAN-interfaces in hetzelfde subnet: als meerdere WAN-interfaces IP-adressen uit hetzelfde subnet gebruiken, kunnen ARP-problemen ontstaan en gateways soms onbereikbaar worden. Als een provider meerdere publieke IP’s in hetzelfde subnet levert, zijn Alias- of LAG-interfaces meestal netter dan meerdere gescheiden WAN-interfaces in hetzelfde netwerk.

SFP, port speed of breakout past niet: poortsnelheid op switch, router, transceiver en firewall moet bij elkaar passen. Een 25 Gbit/s-poort kan niet zonder passende techniek direct op een 40 Gbit/s-poort worden aangesloten. Bij modellen met 40G- of 100G-poorten kunnen breakout-kabels relevant zijn wanneer één poort in meerdere kleinere poorten moet worden verdeeld.

MTU-problemen bij VPN of PPPoE: controleer MTU en MSS. Bij VPN-traffic kan een te hoge MTU-waarde packet loss veroorzaken die in dagelijks gebruik lijkt op willekeurige verbindingsproblemen.

Troubleshooting

Voor foutzoeken is deze volgorde praktisch:

1. Network > Interfaces: link status, IP address, zone en gateway controleren.
2. Network > Zones: Device Access en zonetype controleren.
3. Hosts and services: controleren of host- en service-objecten correct zijn.
4. Rules and policies > Firewall rules: Source zone, Destination zone, Services en volgorde controleren.
5. Rules and policies > NAT rules: als NAT meespeelt, Original en Translated netjes vergelijken.
6. Log viewer: controleren welke regel of drop van toepassing is.
7. Diagnostics > Tools > Packet capture: controleren of pakketten überhaupt aankomen en waarheen ze worden doorgestuurd.

Als zones en interfaces netjes zijn aangemaakt, wordt de volgende stap veel eenvoudiger: Sophos Firewall regels begrijpen en correct configureren. Als traffic ondanks ogenschijnlijk correcte zone niet werkt, helpt de checklist Firewall-regel grijpt niet: volgorde, matching en logs controleren. Voor diepere analyse kan men ook Packet Capture in WebAdmin gebruiken en bij vertalingen of port forwarding het artikel NAT op Sophos Firewall begrijpen: SNAT, DNAT, MASQ, PAT erbij nemen.

Meer informatie

• Sophos Firewall - Add a zone
• Sophos Firewall - Interfaces
• Sophos Firewall - Bridge interfaces
• Sophos Firewall - Link aggregation groups
• Sophos Firewall - Add a link aggregation group
• Sophos Firewall - XFRM interfaces
• Sophos Firewall - RED interfaces
• Sophos Firewall - Add a RED interface