Sophos Firewall Zones en interfaces configureren

Zones en interfaces behoren tot de belangrijkste fundamenten van een Sophos Firewall. Als u ze zorgvuldig plant, worden latere firewallregels, NAT, VPN, webbescherming en probleemoplossing veel eenvoudiger. Als je ze te snel in elkaar klikt, creëer je vaak een omgeving waarin regels verwarrend worden of beheerdiensten op de verkeerde plekken toegankelijk zijn.

Een Zone is een logische beveiligingsgroep. Een Interface is een fysieke of virtuele verbinding, bijvoorbeeld Port1, een VLAN, een bridge, een LAG, een alias, een RED interface of een XFRM-interface voor routegebaseerde VPN. Elke interface is aan precies één zone toegewezen. Firewallregels zullen later zwaar gaan werken bij deze zones, dus de zonestructuur moet niet alleen technisch worden gepland, maar ook op het gebied van veiligheid.

Welk netwerkontwerpartikel is geschikt?

Zones en interfaces zijn vaak het startpunt, maar niet altijd het daadwerkelijke doel van de configuratie. Afhankelijk van de taak is een specifieker artikel beter geschikt:

Deze scheiding voorkomt typische ontwerpfouten. Een zone vervangt geen firewallregel, een VLAN vervangt geen beveiligingsconcept en Device Access is niet hetzelfde als normaal verkeer tussen twee netwerken. Ten eerste moet duidelijk zijn welke veiligheidsgebieden er zijn. Interfaces, VLANs, regels, NAT, DNS en beheertoegang worden vervolgens overeenkomstig gebouwd.

Waarom zones belangrijk zijn

Zones zijn meer dan alleen een visuele groepering op de Sophos Firewall. Dit definieert beveiligingsgebieden die op verschillende plaatsen worden gebruikt:

• Firewallregels werken met Bronzone en Bestemmingszone.
• Device Access bepaalt welke lokale firewalldiensten per zone bereikbaar zijn.
• NAT, SD-WAN, VPN, webbeveiliging en logboeken worden gemakkelijker te begrijpen gemaakt door middel van schone zones.
• Het oplossen van problemen wordt duidelijker omdat u direct kunt zien uit welk beveiligingsgebied een pakket komt en waar het naartoe moet.

Een goede zonering voorkomt niet automatisch elke fout, maar dwingt wel duidelijke grenzen af. Een clientnetwerk, een servernetwerk, een gast-WLAN en een DMZ mogen niet allemaal eenvoudigweg worden behandeld als “LAN” als ze verschillende risico’s en regels hebben. Anders zullen er later grote toestemmingsregels, onduidelijke uitzonderingen en onnodig open beheertoegang ontstaan.

Goede zones beantwoorden altijd deze vraag: Welke netwerken hebben hetzelfde vertrouwensniveau en kunnen op dezelfde manier worden behandeld? Als twee netwerken verschillende toegangsrechten, logvereisten of beheertoegang nodig hebben, is een aparte zone of op zijn minst een zeer bewust regelconcept zinvol.

Belangrijk is het onderscheid tussen zone en netwerkobject. De zone beschrijft via welk beveiligingsgebied een pakket de firewall binnenkomt of waar het naartoe moet. Het netwerkobject beschrijft de concrete IP-bron of het concrete doel. Een regel is pas schoon wanneer beide kloppen: Source zone mag niet alleen grofweg LAN heten terwijl Source networks and devices op Any blijft staan. Omgekeerd helpt een correct netwerkobject weinig als het verkeer via een andere zone binnenkomt dan verwacht.

Standaardzones begrijpen

Sophos Firewall wordt geleverd met verschillende standaardzones:

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

Belangrijk: een zone is geen automatische toestemming. Afhankelijk van de richting en het scenario zijn ook passende firewallregels vereist tussen twee interfaces in dezelfde zone. Verkeer tussen twee LAN zone-interfaces is niet automatisch toegestaan, maar vereist een geschikte LAN-to-LAN regel.

Sophos Firewall ondersteunt eigen zones, maar niet onbeperkt als vervanging voor schone regels. De officiële grens ligt bij maximaal 100 zones. In de praktijk moet die grens niet worden opgezocht. Als bijna elke VLAN een eigen zone krijgt terwijl veel daarvan identieke regels en dezelfde Device Access nodig hebben, wordt het regelwerk vaak minder onderhoudbaar, niet veiliger.

Plan zones voordat u ze aanmaakt

Voordat u zones aanmaakt, moet u weten welke netwerken verschillende beveiligingsvereisten hebben. Typische voorbeelden:

• werkplek LAN
• servernetwerk
• Beheernetwerk
• DMZ
• Gast WLAN
• VoIP
• Camera- of IoT-netwerk
• Productienetwerk
• VPN-clients
• MPLS- of locatieverbindingen

Een aparte zone is zinvol als een netwerk zijn eigen regels, zijn eigen Device Access of een ander niveau van vertrouwen nodig heeft. Er kunnen zich echter ook meerdere VLAN’s in dezelfde zone bevinden als ze gelijk behandeld moeten worden. Te veel zones maken een configuratie niet automatisch veiliger. Zones zijn alleen nuttig als er duidelijke regels achter zitten.

Deze basisstructuur is een goed begin voor veel kleine en middelgrote omgevingen:

Niet elke VLAN heeft automatisch een eigen zone nodig. Als meerdere clients VLANs precies dezelfde firewallregels, hetzelfde webbeleid en dezelfde Device Access krijgen, kunnen ze in een gemeenschappelijke clientzone blijven. Als de ene VLAN echter toegang krijgt tot servers, de andere alleen toegang heeft tot internet, en een derde helemaal geen toegang mag hebben tot lokale firewalldiensten, moet de scheiding bewust worden gemodelleerd.

Een goed patroon is:

Vertaal het zonemodel naar een toegangsmatrix

Na de zoneplanning moet u kort bepalen welke zone met welke andere zone mag praten. Deze toegangsmatrix is ​​vaak nuttiger dan meteen regels maken in de WebAdmin omdat het tegenstrijdigheden zichtbaar maakt.

Een eenvoudig voorbeeld:

De matrix heeft geen groot zijn. Wat belangrijk is, is dat elke toegestane richting een doel heeft. Als een vermelding niet kan worden verklaard, mag deze niet als een brede firewallregel ontstaan.

Voor elke regel moet u ook noteren:

• vereiste services en poorten
• of gebruikers- of groepsmatching nodig is
• of NAT betrokken is
• of loggen permanent actief moet blijven
• welke beveiligingsfuncties geschikt zijn, bijvoorbeeld IPS, webbeleid of Application Control
• wie is technisch verantwoordelijk voor de toegang

Op basis van deze matrix worden vervolgens de daadwerkelijke firewallregels gemaakt. De gedetailleerde opties en typische fouten voor regelvolgorde, bron, bestemming, NAT en loggen worden beschreven in Sophos Firewall regels en configureer ze correct.

Planningscontrole vóór wijzigingen

Voordat zones of interfaces worden aangemaakt, verplaatst of verwijderd, moeten de afhankelijkheden schriftelijk worden verduidelijkt. Veel latere verstoringen worden niet veroorzaakt door het IP-adres zelf, maar door vergeten firewallregels, NAT-regels, DHCP-servers, Device Access of routeringsbeslissingen.

Voor elke nieuwe zone of interface moeten in ieder geval deze vragen worden beantwoord:

Er moet ook een actuele back-up beschikbaar zijn voor productieve wijzigingen. Als er al interfaces in gebruik zijn, is Object usage verplicht voordat de naam, zonebinding, IP-adres of interfacetype wordt gewijzigd.

Nieuwe zone aanmaken

Open Network > Zones en klik op Toevoegen.

1. Wijs een korte, unieke naam toe, bijvoorbeeld Server , Guest , Management of MPLS.
2. Selecteer LAN of DMZ als type.
3. Bepaal onder Device Access bewust welke lokale firewalldiensten vanuit deze zone toegankelijk mogen zijn.
4. Opslaan.

Na het opslaan moet de zone direct op twee plaatsen worden gecontroleerd: onder Network > Zones voor naam, type en Device Access, en later in een test-firewallregel als selecteerbare Source zone of Destination zone. Als de zone wel bestaat maar er geen interface in ligt, loopt er nog geen productief verkeer doorheen.

LAN of DMZ als zonetype?

Voor uw eigen zones kunt u meestal kiezen tussen LAN en DMZ op de Sophos Firewall. Beide typen groeperen interfaces zodat ze later netjes kunnen worden gebruikt in regels, Device Access en beleid. Het verschil ligt vooral in het veiligheidsidee achter de zone.

LAN wordt gebruikt voor interne, fundamenteel betrouwbare netwerken. Hiertoe behoren bijvoorbeeld clientnetwerken, interne servernetwerken, beheernetwerken, VoIP, printers of interne VLANs. Voor een LAN zone geldt ook het volgende: Verkeer tussen interfaces is niet automatisch toegestaan. Als twee LAN-zones of twee interfaces binnen een LAN-zone met elkaar moeten praten, zijn passende firewallregels vereist.

DMZ wordt gebruikt voor netwerken met een hoger risico of duidelijke isolatie. Typische voorbeelden zijn publiek toegankelijke webservers, reverse proxy’s, mailgateways, jumphosts of systemen die vanuit meerdere beveiligingsgebieden toegankelijk moeten zijn. Een DMZ moet zo worden gepland dat deze alleen de noodzakelijke interne verbindingen ontvangt. Als een gecompromitteerde server zich in de DMZ bevindt, zou dit niet automatisch moeten resulteren in wijdverspreide toegang tot de interne LAN.

Als eenvoudige vuistregel:

HA-interfaces horen ook thuis in een DMZ-zone. Voor normale beheerders- of clientnetwerken is LAN meestal het meest geschikte type.

HTTPS kan handig zijn voor een intern beheerdersnetwerk. Voor normale client- of gastnetwerken moet beheertoegang worden vermeden. Ping/ping6 is vaak nuttig bij het oplossen van problemen, maar moet bewust worden geactiveerd. DNS is alleen nodig als clients in deze zone de firewall gebruiken als DNS-server.

⚠️ Device Access is niet hetzelfde als een firewallregel. Toegang tot lokale firewallservices, bijvoorbeeld WebAdmin, SSH, User Portal, DNS of Ping, wordt beheerd via Beheer > Apparaattoegang en lokale ACL-uitzonderingen.

Interface configureren

Interfaces zijn te vinden onder Network > Interfaces. Een fysieke poort kan bijvoorbeeld worden gebruikt als LAN, WAN of DMZ. Er worden ook virtuele interfaces zoals VLAN, Bridge, LAG, RED of XFRM gemaakt.

Deze punten zijn vooral belangrijk voor een fysieke interface:

Alleen interfaces in de WAN zone ontvangen een gatewayconfiguratie. Interne interfaces worden doorgaans statisch geadresseerd. Voor providerverbindingen kan DHCP of PPPoE zinvol zijn.

Als de provider IPv6 via prefixdelegatie aanbiedt, moet u de beperkingen en het proces afzonderlijk plannen. Het praktijkartikel is Configureer IPv6 Prefix Delegatie op Sophos Firewall.

Betekenisvolle namen zijn belangrijk. PortD zegt weinig in zes maanden. Server VLAN, MPLS Provider , Guest WiFi of Core Switch Trunk helpen aanzienlijk meer tijdens het gebruik.

Een bestaande fysieke interface wordt zo bewerkt:

1. Open Network > Interfaces.
2. Open het menu van de gewenste poort en kies Edit interface.
3. Controleer Name, Network zone, IP-configuratie, gateway en MTU/MSS.
4. Controleer bij WAN-interfaces ook gatewaynaam en gateway-IP.
5. Sla op en controleer daarna linkstatus, gatewaystatus en Log Viewer.

Voor wijzigingen aan een productie-interface moet Object usage worden geopend. Interfacewijzigingen kunnen zone binding, DNS, gateways, SD-WAN routes, interface-gebaseerde hosts, VLAN-interfaces, Dynamic DNS, firewallregels en NAT raken. Bij het verwijderen van een virtuele interface verwijdert Sophos bovendien afhankelijke configuratie zoals firewallregels, DHCP- of routingreferenties. Juist daar ontstaan vervelende storingen wanneer alleen aan de poortnaam is gedacht.

Voordat u firmware-upgrades uitvoert, moet u er ook voor zorgen dat interfacenamen, hardwarenamen en vertakkingsnamen niet eindigen met een lang nummerblok. Een WebAdmin weergavefout wordt gedocumenteerd in de SFOS releaseopmerkingen wanneer zulke namen eindigen met tien of meer cijfers, bijvoorbeeld VLAN_1234567890. Voor upgradeplanning en specifieke tests past Sophos Firewall vóór SFOS 22 Upgrade controleren.

Maak een VLAN interface

Voor een gefocust proces met bovenliggende interface, switch-tagging, DHCP, Device Access, firewallregels en -tests, instellen en testen van Sophos Firewall VLAN. In de volgende sectie wordt VLANs binnen het grotere interface- en zonemodel geplaatst.

Er wordt een VLAN-interface aangemaakt onder Network > Interfaces > Add interface > Add VLAN. Wat vooral belangrijk is, zijn de bovenliggende interface, zone, VLAN ID en IP-configuratie.

De bovenliggende interface is de fysieke poort of een LAG waarop de VLAN getagd arriveert. Als de switch de VLAN op een andere poort verzendt, ongelabeld of met de verkeerde VLAN ID, ziet de firewall een VLAN-interface, maar kunnen de clients deze niet betrouwbaar bereiken.

Voor interne VLANs gebruikt u doorgaans een statisch IP-adres op de firewall, bijvoorbeeld als standaardgateway voor deze VLAN. De zone bepaalt later welke firewallregels, webbeleid en Device Access instellingen van toepassing zijn. Dat is precies de reden waarom je bij het aanmaken van een VLAN niet alleen het IP-adres moet invoeren, maar ook moet overwegen of de VLAN Client , Server , Management , Guest , DMZ of een andere zone nodig heeft.

Een concreet praktijkvoorbeeld met switch-poortprofielen, getagged/untagged-gedrag, DHCP en testsequentie is te vinden in VLAN om Sophos Firewall en UniFi Switch te configureren.

Op XGS-hardware noemt Sophos geen vast hard aantal VLAN-interfaces per fysieke interface. Dat betekent niet dat een enkele parent-poort altijd de beste operationele keuze is. Voor performance, foutopsporing en onderhoudbaarheid moeten VLANs zinvol over fysieke poorten of LAGs worden verdeeld, vooral bij veel VLANs, hoge east-west load of HA-ontwerpen.

VLAN uitrol netjes geaccepteerd

Een VLAN wordt pas als voltooid beschouwd als niet alleen de interface is gemaakt, maar ook de switch, DHCP, DNS, firewallregel en logging allemaal in elkaar passen. Vooral bij nieuwe netwerken is het gemakkelijk om op de verkeerde plaats te zoeken: de firewallregel lijkt correct, maar de switch verzendt ongecodeerd. Of de client krijgt een IP-adres, maar Device Access geeft DNS geen toegang tot de firewall.

Voor elke nieuwe VLAN moeten deze punten worden gecontroleerd:

Als acceptatietest is het niet voldoende dat een client een IP-adres ontvangt. Een nuttige test bestaat uit verschillende stappen: verbind de client via DHCP, ping de gateway, controleer DNS, test een toegestane interne verbinding, kijk of een verboden toegang opzettelijk wordt geblokkeerd en controleer vervolgens de internettoegang. Zo kun je zien of VLAN, zone, Device Access, firewallregel en NAT echt bij elkaar passen.

Als er meerdere VLANs tegelijkertijd worden aangemaakt, moet u voor elke VLAN een aparte testclient of minstens één uniek test-IP gebruiken. Anders worden Log Viewer en Packet Capture onnodig verwarrend. Voor de daadwerkelijke pakketstroomtest is Test firewallregel met Log Viewer, Policy Test en Packet Capture geschikt.

Lees de interfacestatus correct

Onder Network > Interfaces geeft Sophos Firewall statusberichten weer. Deze statusmeldingen zijn erg handig bij het oplossen van problemen, omdat je snel kunt zien of een interface gewoon verkeerd is geconfigureerd of dat er echt geen koppeling is.

Als een interface onverwacht Not configured of Unplugged weergeeft, moet u niet eerst naar firewallregels zoeken. Controleer eerst de zonebinding, link, SFP/transceiver, kabel, switchpoort en, voor DHCP/PPPoE, de adrestoewijzing.

VLAN, Bridge, LAG, Alias ​​​​en RED classificeren

Sophos Firewall ondersteunt verschillende interfacetypes. Voor beginners is het belangrijkste wanneer welk type zinvol is.

Alias-interfaces worden vaak onderschat. Ze zijn vooral nuttig wanneer een provider meerdere publieke IP-adressen in hetzelfde subnet levert. Meerdere gescheiden WAN-interfaces in hetzelfde subnet veroorzaken op Sophos Firewall ARP-problemen en kunnen gateways onbereikbaar maken. In zulke ontwerpen is een alias op de bestaande WAN-interface of een goed geplande LAG meestal de betere keuze.

Voor nieuwe installaties is VLAN op een duidelijk gedefinieerde uplink naar de switch doorgaans schoner dan een grote brug over veel poorten. Een bridge kan handig zijn voor migraties of zeer eenvoudige configuraties, omdat meerdere poorten worden behandeld als een gemeenschappelijk Layer 2-segment. Maar dat is precies het nadeel: veiligheidsgrenzen, omroepdomeinen en bronnen van fouten worden minder duidelijk zichtbaar.

Wij adviseren Bridges daarom alleen specifiek en niet als standaard uitvoering. In de praktijk hebben bruggen verschillende nadelen:

• Meerdere poorten delen hetzelfde Layer 2-segment, waardoor de kans groter is dat uitzendingen en interferentie meerdere apparaten beïnvloeden.
• Firewallregels worden minder duidelijk omdat de scheiding niet langer duidelijk zichtbaar is over uw eigen interfaces, VLANs en zones.
• Het oplossen van problemen wordt moeilijker omdat pakketstroom, MAC-leren, STP-problemen en switchconfiguratie samen moeten worden bekeken.
• Latere segmentatie wordt complexer als er vanuit een eenvoudige brug afzonderlijke client-, server-, gast- of beheernetwerken moeten worden gecreëerd.
• HA, VLAN, DHCP of ontwerpen voor apparaattoegang worden snel verwarrend als er te veel functies over een brug lopen.

Bridges kunnen op de Sophos Firewall worden aangemaakt via fysieke interfaces, RED interfaces, VLANs of LAGs en worden bediend met of zonder eigen IP-adres. Dit is precies waar vaak misverstanden ontstaan:

• Zonder IP-adres werkt de bridge transparant, maar kan niet worden gebruikt als een normale gerouteerde interface.
• Als routing op een bridge vereist is, moet aan de bridge een IP-adres worden toegewezen.
• Voor verkeer tussen bridgeleden zijn nog steeds passende firewallregels tussen de betrokken zones vereist, bijvoorbeeld LAN tot LAN.
• STP kan nuttig zijn als er redundante paden zijn en bruglussen moeten worden voorkomen. Bij actieve HA kan STP op bridge-interfaces echter niet worden ingeschakeld.
• VLAN-filters en EtherType-filters kunnen helpen bij het beperken van Layer 2-verkeer dat door een brug gaat. Als een VLAN-filter actief is maar er geen toegestane VLANs zijn ingevoerd, verwerpt de firewall getagd verkeer van alle VLANs. Untagged traffic wordt hierdoor niet beïnvloed.
• Verkeer via bridge-interfaces zonder IP-adres kan worden verwijderd als het een firewallregel tegenkomt met webproxyfiltering of een NAT-regel. Dergelijke druppels worden niet geregistreerd. Bij NAT moet u bijzondere aandacht besteden aan de bronvertaling of de bronvertaling overschrijven.

Dit laatste punt is belangrijk: als je plotseling geen logs over een brug ziet, ook al werkt het verkeer blijkbaar niet, ligt het probleem niet altijd bij de Log Viewer. Dit kan te wijten zijn aan de bridge-modus, NAT of webproxyfiltering.

Als er al VLANs op de switch aanwezig zijn, moet de firewall deze VLANs bewust als zijn eigen VLAN-interfaces gebruiken. Dit resulteert in duidelijkere zones, schonere firewallregels en is op de lange termijn doorgaans gemakkelijker te onderhouden.

SFOS 22: Controleer brug, SNAT en haarspeldverkeer

Bij SFOS 22 is er nog een extra bridge-speciaal geval dat bij migraties snel over het hoofd wordt gezien. Routering via een bruginterface kan mislukken als SNAT of MASQUERADE wordt toegepast op verkeer over de brug en de bron en bestemming bereikbaar zijn via hetzelfde fysieke bruglid. In dit haarspeldscenario kunnen antwoordpakketten op de bridge worden gedropt zonder dat de drop duidelijk zichtbaar is in drppkt.

Dit is geen normaal probleem met het matchen van regels. Als Log Viewer weinig laat zien, de regel er correct uitziet en alleen bepaalde verbindingen over een brug mislukken, moet u NAT en de brugtopologie samen controleren:

• Is SNAT of MASQUERADE echt nodig voor brugverkeer?
• Komen bron en bestemming via hetzelfde fysieke bruglid?
• Is er slechts één actief gebruikt bridgelid?
• Zou een gerouteerd ontwerp of een speciale fysieke interface schoner zijn?
• Kan verkeer worden getest zonder bronvertaling?

Er is ook een apart SFOS-22 geval voor VLAN-getagd verkeer naar de firewall zelf. De praktische procedure vindt plaats in Sophos Firewall Bridge-VLANs na SFOS 22 controle.

RED Bridge: netwerk uitbreiden over locaties

Het is technisch mogelijk om RED interfaces in een bridge op te nemen en zo een Layer 2-netwerk over meerdere locaties uit te rekken. Dit kan in speciale gevallen helpen, bijvoorbeeld wanneer een applicatie in hetzelfde subnet moet blijven of een migratie moet plaatsvinden zonder onmiddellijke IP-wijzigingen.

Wij raden dit ontwerp slechts zeer voorzichtig aan. Een brug over RED breidt het Layer 2-domein uit over de tunnel. Hierdoor kunnen uitzendingen, ARP, onbekende unicast-pakketten en andere Layer 2-effecten via een WAN of internetverbinding worden uitgevoerd. Dit kan de prestaties verslechteren en fouten moeilijker te begrijpen maken. Als de RED-tunnel instabiel is, heeft dit ook directe gevolgen voor het uitgerekte netwerk.

In de meeste gevallen is een gerouteerd ontwerp beter: elke locatie heeft zijn eigen subnetten, de firewallroutes tussen de netwerken en firewallregels bepalen specifiek wat is toegestaan. Dit is overzichtelijker, schaalbaarder en veel handiger bij het oplossen van problemen.

LAG: Redundantie en bandbreedte correct plannen

Een Link Aggregation Group (LAG) combineert verschillende fysieke poorten in een logische interface. Dit is zinvol als u redundantie naar de kernswitch nodig heeft of meer bandbreedte tussen de firewall en switch wilt bieden. LAG vervangt geen schone zonering. Uiteindelijk is de LAG interface nog steeds slechts een interface waarop je dan bijvoorbeeld VLANs kunt bedienen of een zone kunt toewijzen.

Sophos Firewall ondersteunt hoofdzakelijk twee typische bedrijfsmodi:

Belangrijk is: LACP werkt alleen goed als de andere kant correct is geconfigureerd. Op de switch moeten de poorten zich in dezelfde LAG groep bevinden, dezelfde snelheid en duplexmodus gebruiken en overeenkomen met de firewallconfiguratie. Als u alleen een LAG op de firewall aanmaakt, maar de switch niet op de juiste manier configureert, ontstaan ​​er vaak pakketverliezen die moeilijk te begrijpen zijn of ontstaan ​​er vaak asymmetrische verbindingsproblemen.

Er zijn enkele praktische limieten van toepassing op LAGs:

• Een LAG bestaat uit twee tot vier fysieke interfaces op de Sophos Firewall.
• Alleen ongebonden fysieke interfaces met een statische configuratie zijn geschikt als leden.
• PPPoE, Cellular WAN en WLAN interfaces kunnen niet worden gebruikt als LAG leden.
• Voor LACP (802.3ad) moeten de aangesloten poorten hetzelfde type en dezelfde snelheid hebben.
• De xmit-hash-policy bepaalt hoe sessies over de links worden verdeeld. Een enkele TCP sessie wordt meestal niet ineens sneller omdat deze meestal op een link blijft staan.

Voor kleine omgevingen is één schone trunkpoort vaak voldoende. LAG is vooral de moeite waard als de core-switch redundant moet worden aangesloten, als veel VLAN’s over dezelfde uplink lopen of als de firewall echt meer doorvoer naar de switch nodig heeft.

XFRM: Begrijp routegebaseerde IPsec als interface

Een XFRM-interface behoort tot het onderwerp routegebaseerde IPsec VPN. Het is niet gepland zoals een normale VLAN of een fysieke poort, maar wordt gemaakt in de context van een IPsec-verbinding. De Sophos Firewall creëert automatisch een XFRM-interface wanneer zowel het lokale als het externe subnet zijn ingesteld op Any op een IPsec-verbinding.

Dit is een belangrijk verschil met klassieke, op beleid gebaseerde IPsec-tunnels. Met routegebaseerde VPN bepalen niet alleen het IPsec-beleid, maar ook routing, firewallregels en de XFRM-interface waar het verkeer naartoe gaat. Dit maakt complexere locatieverbindingen flexibeler, maar vereist een zorgvuldige planning:

• De XFRM-interface bevindt zich in de zone VPN.
• Onder Beheer > Apparaattoegang moet WAN worden toegestaan ​​voor de WAN zone, zodat de verbinding tot stand kan worden gebracht.
• Als lokale of externe subnetten niet Any zijn, wordt er geen XFRM-interface gemaakt.
• MTU en MSS zijn vooral belangrijk voor routegebaseerde VPN omdat IPsec extra overhead creëert. De praktische testprocedure staat in Sophos Firewall Controleer MTU en MSS op VPN-problemen.
• Een XFRM-interface wordt niet direct onder Network > Interfaces gedeactiveerd, maar via de bijbehorende IPsec-verbinding onder Site-to-site VPN > IPsec.

Voor beheerders is XFRM vooral relevant wanneer SD-WAN-routering, dynamische routering of meerdere netwerken goed moeten worden beheerd via een locatietunnel. Als u alleen maar een zeer eenvoudige site-to-site-verbinding met twee vaste netwerken nodig heeft, is een klassieke, op beleid gebaseerde tunnel vaak gemakkelijker 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 gecodeerde tunnel met de Sophos Firewall te verbinden. Dit kan worden geïmplementeerd met speciale SD RED-hardware of met firewall-naar-firewall RED-verbindingen.

Voordat u gaat plannen, moet het duidelijk zijn welke bedrijfsmodus vereist is:

Voor veel bedrijven is Standard/Unified de schoonste optie als de locatie volledig beveiligd moet worden via de centrale firewall. Het nadeel is duidelijk: als de RED-tunnel uitvalt, verliest de locatie, afhankelijk van het ontwerp, ook de centraal geregelde internettoegang. Standard/Split verkleint deze afhankelijkheid, maar betekent ook dat het lokale internetverkeer niet meer volledig gefilterd en gelogd wordt via de centrale Sophos Firewall.

Bij RED moet u deze punten vroegtijdig controleren:

• De dienst RED moet worden geactiveerd onder Systeemdiensten > RED.
• TCP 3400, UDP 3410 en NTP 123 zijn doorgaans vereist voor de verbinding.
• SD-RED apparaten hebben de juiste tijd nodig, anders kunnen TLS-handshake en tunnelopbouw mislukken.
• Tijdens de eerste inbedrijfstelling is DHCP op de uplink meestal eenvoudiger omdat het apparaat de provisioning moet voltooien.
• VLANs zijn niet even nuttig in elke RED-modus. Standard/Split en Transparent/Split zijn niet bedoeld voor VLAN getagde frames. Als achter een SD-RED VLANs nodig zijn, moet u de bedrijfsmodus bijzonder zorgvuldig kiezen.
• Als een RED-apparaat zich achter een router van een provider bevindt, moeten uitgaande verbindingen en DNS/NTP werken.

RED is erg handig voor kleine sites, maar je moet hem niet als een normale LAN kabel behandelen. Doorslaggevend is of de locatie centraal beschermd, lokaal autonoom of slechts gedeeltelijk via de tunnel verbonden moet zijn. Deze beslissing heeft invloed op DHCP, DNS, VLANs, routing, firewallregels, logboekregistratie en probleemoplossing.

Device Access

Onder Beheer > Apparaattoegang kunt u zien welke lokale firewallservices vanuit welke zones toegankelijk zijn. Dit zijn onder andere:

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

Voor productieve omgevingen geldt: hoe minder lokale services vanuit een zone kunnen worden bereikt, hoe beter. In het bijzonder mogen HTTPS en SSH alleen worden toegestaan ​​vanaf betrouwbare beheernetwerken of via een Lokale ACL-uitzonderingsregel.

Als SSH nodig is, kunnen deze instructies helpen: SSH breng een verbinding tot stand met de Sophos Firewall.

Bij eigen zones kan Device Access ook direct zichtbaar zijn bij het maken of bewerken van de zone. Technisch gaat het nog steeds om lokale firewallservices, niet om normaal transitverkeer. Als clients de firewall als DNS-server gebruiken, moet DNS voor deze zone zijn toegestaan. Als beheerders WebAdmin moeten bereiken, hoort dat niet breed voor de hele clientzone open te staan, maar via een managementnetwerk of een Local Service ACL-uitzondering.

Houd rekening met afhankelijkheden

Wijzigingen aan interfaces komen zelden geïsoleerd voor. Zone binding, DNS, gateways, SD-WAN routes, interface-gebaseerde hosts, VLAN-interfaces, Dynamic DNS, firewallregels en NAT-regels kunnen van dezelfde interface afhangen. Voor grotere wijzigingen moet onder Object usage worden gecontroleerd waar een interface, zone of hostobject al wordt gebruikt. Sophos Firewall toont objectgebruik en linkt direct naar veel afhankelijke configuraties.

U moet bijzonder voorzichtig zijn bij het deactiveren of verwijderen van:

• Wanneer een interface wordt gedeactiveerd, blijft de configuratie behouden en is de status nog steeds zichtbaar.
• Site-to-site IPsec Tunnels waarbij de firewall de initiator is, worden onmiddellijk losgekoppeld.
• Site-to-site IPsec Tunnels als responders en RAS-verbindingen worden uiterlijk gescheiden vanwege inactiviteit of dode peer-detectie.
• Alias- en XFRM-interfaces kunnen niet direct worden gedeactiveerd zoals normale interfaces. Aliasinterfaces volgen de fysieke interface, XFRM-interfaces worden uitgeschakeld via Site-to-site VPN > IPsec.
• Wanneer een virtuele interface wordt verwijderd, kunnen afhankelijke firewallregels, DHCP-configuraties, ARP-items, routes, interface-hosts en andere referenties ermee worden verwijderd.

Daarom moet u vóór het verwijderen altijd controleren of de interface wordt gebruikt in firewallregels, NAT-regels, DHCP, routing, SD-WAN, dynamische DNS of hostobjecten. Een onzorgvuldige verwijdering kan meer dan alleen de interface zelf verwijderen.

Wijzigingen veilig doorvoeren

Interfaceveranderingen moeten geleidelijk plaatsvinden. Externe locaties, HA clusters, WAN interfaces, VLAN trunks, XFRM interfaces en beheernetwerken zijn bijzonder kritisch. Een kleine wijziging in de zonebinding kan voldoende zijn om firewallregels, Device Access- of SD-WAN-routes niet langer te laten werken zoals verwacht.

Bewezen proces:

1. Documenteer de huidige interface- en zoneconfiguratie.
2. Controleer de afhankelijkheden via Object usage en noteer de belangrijkste treffers direct.
3. Maak een back-up.
4. Definieer het onderhoudsvenster of de terugvaltijd.
5. Voeg eerst een nieuwe zone of nieuwe interface toe, verwijder niet meteen de oude configuratie.
6. Testklant of testverkeer voorbereiden.
7. Controleer na het wijzigen de verbindingsstatus, het IP-adres, de gateway, DHCP en DNS.
8. Valideer de firewallregel, NAT-regel en Device Access met Log Viewer of Packet Capture.
9. Verwijder pas oude regels, interfaces of objecten als het nieuwe pad stabiel is.

Een back-up is slechts een deel van de terugweg. Voordat kritische interface- of zonewijzigingen plaatsvinden, moet ook worden gedocumenteerd welk oud IP-adres, welke zone, VLAN ID, gateway, route, SD-WAN-route, firewallregel en NAT-regel moeten worden hersteld in het geval van een afbreking. Voor het daadwerkelijke back-up- en herstelproces is Sophos Firewall Back-up maken of terugzetten geschikt.

Wanneer u VLAN-migraties uitvoert, moet u bijzondere aandacht besteden aan getagd/niet-getagd gedrag. Als de switch en de firewall verschillende VLAN ID’s, native VLANs of trunkprofielen gebruiken, ziet de firewall helemaal geen verkeer of komt het verkeer in de verkeerde zone terecht.

Voor externe locaties moet er altijd een toegangspad zijn buiten de interface die u zojuist hebt gewijzigd. Dit kan Sophos Central zijn, een tweede WAN toegang, een lokale beheerder ter plaatse of een apart beheernetwerk.

Typische struikelblokken

Interface is niet gebonden of uitgeschakeld: Controleer eerst of een zone is toegewezen. Een fysieke interface kan niet worden verwijderd, maar de configuratie ervan kan worden verwijderd door de zone in te stellen op None .

VLAN werkt niet: VLAN Controleer ID, schakelpoort, getagde/niet-getagde configuratie, native VLAN en ouderinterface.

Clienten kunnen de firewall niet bereiken via ping of HTTPS: Controleer niet eerst de normale firewallregels. Beheer > Apparaattoegang en lokale ACL-uitzonderingen zijn cruciaal.

Verkeer tussen twee interne netwerken werkt niet: Controleer bronzone, bestemmingszone, netwerkobjecten, routering en positie van de firewallregel.

WAN gateway wordt niet actief: Controleer IP-configuratie, gateway-IP, linkstatus, PPPoE-toegangsgegevens, DNS en indien nodig WAN linkmanager.

Meerdere WAN interfaces in hetzelfde subnet: Als meerdere WAN interfaces IP-adressen uit hetzelfde subnet gebruiken, kunnen ARP-problemen optreden en kunnen gateways onbereikbaar worden. Als een provider meerdere openbare IP’s op hetzelfde subnet aanbiedt, zijn alias- of LAG-interfaces doorgaans schoner dan meerdere afzonderlijke WAN-interfaces op hetzelfde netwerk.

SFP, poortsnelheid of breakout komen niet overeen: De poortsnelheid op de switch, router, transceiver en firewall moeten overeenkomen. Een 25 Gbit/s-poort kan zonder de juiste technologie niet rechtstreeks op een 40 Gbit/s-poort worden aangesloten. Voor modellen met 40G- of 100G-poorten kunnen breakout-kabels relevant zijn als een poort moet worden opgesplitst in meerdere kleinere poorten.

MTU-problemen met VPN of PPPoE: Controleer MTU en MSS. Bij VPN-verkeer kan een te hoge MTU-waarde leiden tot pakketverlies, wat in het dagelijks leven lijkt op willekeurige verbindingsproblemen. Voor systematische beperking is Sophos Firewall Controleer MTU en MSS op VPN-problemen geschikt.

Problemen oplossen

Deze volgorde is handig bij het oplossen van problemen:

1. Network > Interfaces: Controleer de verbindingsstatus, het IP-adres, de zone en de gateway.
2. Network > Zones: Controleer Device Access en zonetype.
3. Hosts en services: Controleer of host- en serviceobjecten correct zijn.
4. Rules and policies > Firewallregels: Controleer bronzone, bestemmingszone, services en volgorde.
5. Rules and policies > NAT regels: Als NAT in het spel is, vergelijk dan zorgvuldig het origineel en de vertaling.
6. Logviewer: Controleer welke regel of drop van toepassing is.
7. Diagnostiek > Tools > Pakketopname: controleer of pakketten überhaupt aankomen en waar ze naartoe worden doorgestuurd.

Als zones en interfaces goed zijn ingedeeld, wordt de volgende stap veel eenvoudiger: Sophos Firewall-regels begrijpen en correct configureren. Als het verkeer ondanks de ogenschijnlijk correcte zone niet werkt, kan de checklist Firewallregel is niet van toepassing: controleer volgorde, matching en logs helpen. Voor een diepere analyse kunt u ook Packet Capture in WebAdmin gebruiken en voor vertalingen of port forwarding het artikel NAT begrijpen op Sophos Firewall: SNAT, DNAT, MASQ, PAT raadplegen.

Operationele checklist

• Zonemodel gedocumenteerd: Client, Server, Management, Guest, DMZ, WAN en VPN opzettelijk gescheiden of opzettelijk gecombineerd.
• Nieuwe VLANs gedocumenteerd met VLAN ID, bovenliggende interface, switchpoortprofiel en gateway-IP.
• Zone en concreet IP-hostobject per belangrijk netwerk gedocumenteerd.
• Device Access gecontroleerd per zone, vooral voor HTTPS, SSH, DNS, Ping, User Portal en VPN Portal.
• Firewallregels gemaakt met bronzone, bestemmingszone, services en logboekregistratie.
• Alias gecontroleerd in plaats van een extra WAN-interface wanneer meerdere publieke IPs in hetzelfde providersubnet worden gebruikt.
• NAT regels gecontroleerd of er sprake is van internettoegang, DNAT, SNAT of VPN.
• DHCP, DNS en NTP getest voor nieuwe netwerken.
• Object usage gecontroleerd vóór wijzigingen aan bestaande interfaces.
• Linkstatus, Log Viewer en Packet Capture gecontroleerd op wijzigingen.
• Beheertoegang verzekerd via een onafhankelijk pad.
• Back-up beschikbaar vóór grote wijzigingen.

FAQ