Planera zoner och gränssnitt i Sophos Firewall på rätt sätt

En zon samlar gränssnitt med liknande förtroendenivå. Ett gränssnitt är den fysiska eller virtuella anslutningen, till exempel Port1, ett VLAN, LAG, RED- eller XFRM-gränssnitt. Varje bundet gränssnitt tillhör exakt en zon; fysiska portar kan också vara obundna.

Viktigt: En zon tillåter inte trafik automatiskt. Även mellan två gränssnitt i zonen LAN krävs en lämplig LAN-to-LAN-brandväggsregel. Åtkomst till själva brandväggen, till exempel WebAdmin, SSH eller DNS, styrs dessutom via Device Access.

Konfigurera zoner och gränssnitt direkt

Skapa en zon

En egen zon skapas i fyra steg under Network > Zones > Add:

1. Ange ett entydigt namn, till exempel Server, Management, Guest eller IoT.
2. Välj LAN eller DMZ som Type.
3. Tillåt under Device Access endast de lokala brandväggstjänster som faktiskt behövs från zonen.
4. Spara.

Zonen ska därefter visas under Network > Zones och kunna väljas som Source zone eller Destination zone i en brandväggsregel. Produktionstrafik kan använda zonen först när minst ett gränssnitt har tilldelats den.

Egna zoner kan endast skapas med typen LAN eller DMZ. Det går inte att skapa ytterligare WAN- eller VPN-zoner. SFOS tilldelar automatiskt VPN-gränssnitt till zonen VPN. Det maximala antalet zoner beror på versionen: SFOS 22.0 tillåter upp till 100 zoner, SFOS 23.0 upp till 248 zoner.

Konfigurera ett fysiskt gränssnitt

Antalet tillgängliga fysiska portar beror på appliance-modellen. Kontrollera därför först vid planeringen vilka anslutningar den aktuella enheten har; virtuella gränssnitt ersätter inte ytterligare fysiska portar som behövs.

En befintlig port redigeras via Edit interface under Network > Interfaces:

1. Ange ett beskrivande Name med högst 58 tecken, till exempel Core Switch Trunk eller MPLS Provider.
2. Välj rätt Network zone.
3. Konfigurera IPv4 och vid behov IPv6.
4. Kontrollera Gateway och vid behov även MTU och MSS för WAN-gränssnitt.
5. Spara och kontrollera därefter länkstatus, gatewaystatus och Log Viewer.

Zonen WAN är avsedd för anslutningar med Default Gateway. Interna gränssnitt adresseras normalt statiskt; fysiska gränssnitt erbjuder metoderna Static, DHCP och PPPoE för IPv4. De följande fältinstruktionerna skiljer mellan dessa metoder. Gatewayfälten som anges där är inte i sig ett skäl att tilldela ett internt gränssnitt till zonen WAN: zon, adressering och routing måste stämma med nätverksdesignen och det formulär som faktiskt visas.

Om det fysiska gränssnittet redan har ett VLAN tillåter SFOS inte att IPv4-tilldelningen ändras från Static till DHCP eller PPPoE. För IPv6 blockeras även ändringen från Static till DHCP eller Delegated. Dokumentera före ändringen VLAN-beroendena under Object usage. Flytta sedan de berörda VLAN-gränssnitten till ett annat Parent Interface eller ta bort dem under ett servicefönster. Ändra först därefter tilldelningsmetoden, återställ VLAN-konfigurationen och testa anslutningen.

IPv4 på en fysisk port: Static eller DHCP

⚠️ Kör Object usage > Refresh innan du ändrar adress eller metod, dokumentera tidigare adress, nätmask, zon och gateway och förbered säkerhetskopia, underhållsfönster och oberoende administratörsåtkomst. Ändringen kan bryta den aktuella hanterings- och datavägen. Hantera först befintliga VLAN-beroenden enligt beskrivningen ovan. Återställningsvägen via konsolen längre ned ersätter inte den normala konfigurationen i WebAdmin.

Static: ange fasta IPv4-värden

1. Öppna rätt fysisk port under Network > Interfaces via Menu > Edit interface och kontrollera Hardware. Den fysiska anslutningen kan inte ändras här.
2. Välj IPv4 configuration och tilldelningsmetoden Static.
3. Ange den IPv4-adress som är avsedd för gränssnittet. Anpassa vid behov nätmasken till det planerade nätverket.
4. Ange Gateway name och Gateway IP address enligt det visade formuläret och de godkända nätverks- eller operatörsvärdena. Namnet ska identifiera gatewayen entydigt; gatewayens IP-adress är adressen till den avsedda motparten, inte ytterligare en adress på brandväggen.
5. Jämför värdena och portens ID igen och spara med Save. Kontrollera därefter sparad IP-adress och nätmask, länk, vid behov gatewaystatus samt routing, DNS, Device Access och den faktiska data- och hanteringsvägen.

Ett rent illustrativt exempel på en statisk WAN-anslutning använder IPv4-adressen 192.0.2.2, nätmasken 255.255.255.0, Gateway name ISP-Static och Gateway IP address 192.0.2.1. Dessa adresser tillhör ett dokumentationsnätverk och är inte operatörsvärden för produktionsdrift. Ersätt adress, nätmask och gateway med de sammanhörande uppgifterna från din egen operatör; välj ett namn som gör att anslutningen går att identifiera i drift.

DHCP: skilj mellan dynamisk adresshämtning och dokumenterade fält

1. Öppna den fysiska porten under Network > Interfaces > Menu > Edit interface, kontrollera Hardware och zonen och välj IPv4 configuration.
2. Välj DHCP. Denna metod hämtar gränssnittets adress från en DHCP-server; den konfigurerar inte en DHCP-server för klienter.
3. De dokumenterade fältinstruktionerna för DHCP anger dessutom att en IPv4-adress ska anges, att nätmasken kan ändras och att Gateway name och Gateway IP address ska fyllas i. Beskrivningen förklarar dock inte hur dessa uppgifter samverkar med adressen som hämtas från DHCP-servern. Dra därför inte slutsatsen att de innebär en manuell ersättningsadress, en fallback eller att DHCP-leasen skrivs över.
4. Kontrollera före lagring vilka fält som faktiskt är synliga respektive redigerbara i den installerade builden och jämför dem med den godkända DHCP-/operatörskonfigurationen. Kopiera inte statiska exempelvärden till DHCP-fält. Om rollen för ett obligatoriskt fält är oklar ska du inte spara ändringen, utan först reda ut detta med operatören eller supporten.
5. När konfigurationen har klarlagts, spara med Save och kontrollera att en lämplig adress hämtas. Connecting betyder att en lease fortfarande håller på att hämtas; om statusen kvarstår ska du först undersöka länken, DHCP-serverns nåbarhet och operatörens krav. Kontrollera därefter IP-adress, nätmask, gateway, DNS, routing och den faktiska hanterings- och datavägen.

Om den förväntade vägen saknas efter någon av dessa ändringar ska du återställa den dokumenterade ursprungliga metoden och dess värden via den oberoende åtkomsten och testa igen. PPPoE använder däremot operatörens inloggningsuppgifter; hela arbetsflödet beskrivs i Konfigurera och kontrollera PPPoE-WAN.

IPv6 på en fysisk port: metod och mottagningsläge

Under IPv6 configuration finns Static eller DHCP för WAN-gränssnitt; interna gränssnitt erbjuder Static, DHCP eller Delegated. Delegated använder ett prefix som operatören har delegerat för interna gränssnitt. Hela arbetsflödet med WAN-DHCP, Upstream Interface och intern fördelning beskrivs i IPv6 Prefix Delegation på Sophos Firewall. Detta är en separat uppgift och ersätter inte den statiska konfigurationen eller valet av mottagningsläge nedan.

Static: IPv6-adress, prefix och gatewayfält

1. Öppna den fysiska porten under Network > Interfaces > Menu > Edit interface och välj IPv6 configuration.
2. Välj Static. Statiska IPv6-adresser är avsedda för både WAN-gränssnitt och interna gränssnitt.
3. Ange den planerade IPv6-adressen och anpassa vid behov prefixet till det tilldelade nätverket.
4. Fyll i fälten Gateway name och Gateway IP address som anges i Static-instruktionerna enligt det formulär som faktiskt visas och nätverksdesignen. De allmänna Static-instruktionerna nämner dessa fält även i avsnittet för WAN-gränssnitt och interna gränssnitt; dra därför inte slutsatsen att en intern Default Gateway är obligatorisk eller att fälten generellt bara gäller WAN. Klarlägg otydliga eller oväntade obligatoriska fält före en produktionsändring.
5. Spara med Save och kontrollera sparad IPv6-adress och prefix, vid behov gateway samt IPv6-routing, DNS och tillåtna anslutningar. Behåll den oberoende administratörsåtkomsten under tiden; återställ de tidigare dokumenterade IPv6-värdena om trafikvägen är fel.

Säkerhetsåtgärderna före IPv4-proceduren gäller även för IPv6: dokumentera tidigare metod och värden, kontrollera VLAN-beroenden och använd inte den aktuella hanteringsvägen som enda återställningsväg.

DHCPv6: Auto, Manual och Stateless

När DHCP har valts under IPv6 configuration styr Mode hur brandväggen själv tar emot adressen för sitt gränssnitt. Detta är inte samma inställning som en Router Advertisement-server för interna klienter:

• Auto: Gränssnittets adress tilldelas automatiskt enligt den konfigurationsmetod som används; den kan vara DHCP only eller Stateless. Dra inte slutsatsen att det finns en fast urvalsregel som inte dokumenteras här.
• Manual > DHCP only: Brandväggen tilldelar gränssnittet den adress och de övriga parametrar som DHCPv6-servern tillhandahåller.
• Manual > Stateless: Brandväggen bildar gränssnittets adress med Stateless Address Auto-Configuration (SLAAC) enligt de Managed- respektive Other-flaggor (M/O) som annonseras i Router Advertisements. Med Accept other configuration from DHCP kan ytterligare parametrar hämtas från DHCPv6-servern. Detta ändrar inte mottagningsläget till DHCP only.

Den valfria funktionen DHCP rapid commit använder ett utbyte av två meddelanden (solicit och reply) i stället för fyra (solicit, advertise, request och reply). Aktivera den endast om Rapid Commit också är aktiverat på DHCPv6-servern och passar den godkända konfigurationen. Detta är ingen generell lösning på prestandaproblem.

DHCPv6-instruktionerna anger Gateway name och Gateway IP address. När Mode är Manual och Stateless går det dock inte att ange Gateway IP address. Denna begränsning gäller Stateless-läget och får inte överföras till Manual > DHCP only. Jämför mottagningsläget och gatewayfälten med den avsedda RA-/DHCPv6-designen och det synliga formuläret före lagring; försök inte tvinga fram en gateway-IP om det valda läget inte tillåter den.

Efter Save ska du kontrollera den faktiskt tilldelade IPv6-adressen, prefixet och övriga parametrar samt routing, DNS och en tillåten IPv6-dataväg. Om adressen är fel eller saknas ska du först jämföra det valda läget, de mottagna RA-flaggorna och DHCPv6-serverns nåbarhet med motparten; växla inte mellan lägen utan föregående kontroll. Om hanteringsvägen bryts ska du återställa den tidigare konfigurationen via den oberoende åtkomsten.

Anpassa port- och länkinställningar

Under Advanced settings matchas Link mode, Auto-negotiation for media type, modellberoende Forward Error Correction (FEC) samt MTU och MSS mot motpartens enhet. För portar på 25, 50 och 100 Gbit/s sparas först Link mode, därefter öppnas gränssnittet igen och den rekommenderade konfigurationen läses in. På XGS 2100, 2300, 3100 och 3300 måste alla SFP+-portar i FleXi Port-modulerna använda samma hastighet. Hela arbetsflödet med Show recommended settings, Load recommended configuration, båda lagringsstegen och den avvikande visningen för andra portar, inklusive 40 Gbit/s, beskrivs i Konfigurera breakout-gränssnitt och portinställningar.

SFOS stöder inte DSCP-markering av systemgenererad DHCP- och ARP-trafik, även när brandväggen fungerar som DHCP-klient, relä eller server. En policy får därför inte förlita sig på DSCP-baserad prioritering för dessa paket. Begränsningen gäller DSCP; den innebär inte att all annan möjlig prioritering är utesluten.

Under Advanced settings > Interface settings använder Use default MAC address gränssnittets standard-MAC-adress. För ett gränssnitt med medlemsportar kommer denna standard-MAC-adress från den port som först lades till som medlem. Override default MAC address tillåter en annan MAC-adress; en fabriksåterställning återställer standard-MAC-adressen. Detta är ingen uppmaning att återställa enheten och inget krav för en separat fysisk PPPoE-port. Kontrollera beroendena och återställningsvägen som beskrivs nedan innan du gör en motiverad override.

Porthastigheterna på brandväggen och motpartens enhet måste stämma överens. En 25-Gbit/s-port kan till exempel inte anslutas till en 40-Gbit/s-port via breakout-kablar utan lämplig omvandling. Brandväggens 40- och 100-Gbit/s-portar som stöder breakout kan delas upp i två eller fyra portar med lämpliga breakout-kablar. Detta är ingen garanti för varje appliance eller kabelkombination; kontrollera före planeringen stödet för de aktuella portarna, transceivrarna och motpartens enhet.

Ange en IPv4-adress i den interaktiva recoverymenyn

Under 1. Network Configuration > Interface Configuration visar CLI IPv4-adress och nätmask, IPv6-adress och prefix, zon, gateways och konfigurerade alias för fysiska portar. VLAN- och WLAN-interface visas inte här.

y startar en IPv4-ändring. SFOS visar i tur och ordning aktuell adress, nätmask och zon för varje port; Enter utan nytt värde behåller fältet. Vägen gäller endast Gateway mode och statiska IPv4-värden. VLAN, DHCP, PPPoE, WLAN och WWAN kan inte konfigureras här och IPv6-dialogen skiljer sig.

Spara före ändringen alla värden, port-ID, zon, gateway, alias och en oberoende managementväg. Kontrollera efter lagring link, ny IP och nätmask, gateway, Device Access, routing, DNS och verklig managementväg. Om åtkomsten bryts eller datavägen är fel återställs ursprungliga värden via konsol eller oberoende åtkomst.

Korrigera link- och MAC-värden i Device Console

WebAdmin är fortfarande den normala konfigurationsvägen. Device Console är avsedd för en dokumenterad korrigering eller recovery, eftersom ett felaktigt link-värde omedelbart kan bryta den enda managementvägen. Dokumentera först Port ID, motpart, nuvarande Link mode, autonegotiation, FEC, oberoende administratörsåtkomst och rollback.

Den officiella SFOS 22-syntaxen accepterar 1000fd, 100fd, 100hd, 10fd, 10hd eller auto för de angivna kopparvärdena:

Följande exempel är alternativ, inte en kommandosekvens. Ersätt Port2 med den verifierade fysiska porten och välj exakt ett alternativ som motsvarar den godkända port- och motpartskonfigurationen; kör inte båda efter varandra. Dokumentera först de ursprungliga värdena för Link mode, autonegotiation och, där det är tillämpligt, FEC på båda sidor, tillsammans med länkstatus, faktisk hastighet och duplex. Säkerställ oberoende åtkomst och klarlägg exakt återställning via WebAdmin eller ett förfarande som supporten har bekräftat för den installerade builden. Om ursprungsvärdena eller återställningsvägen är okända ska du stoppa före CLI-ändringen och kontakta supporten.

Alternativ 1: automatisk hastighet och duplex, med ytterligare autonegotiation aktiverad:

set network interface-link Port2 linkmode auto autoneg on

Alternativ 2: 1000 Mbps full duplex, med ytterligare autonegotiation inaktiverad:

set network interface-link Port2 linkmode 1000fd autoneg off

autoneg styr ytterligare link-parametrar utöver hastighet och duplex. FEC-lägen beror på modellen och Sophos ger ingen universell lista i detta CLI-kommando. För portar på 25, 50 eller 100 Gbit/s används den rekommenderade konfigurationen för exakt appliance och transceiver, inte ett värde som kopierats från en annan modell.

Jämför omedelbart efter den valda ändringen de sparade värdena för Link mode, autonegotiation och, där det är tillämpligt, FEC i WebAdmin och hos motparten med de godkända målvärdena. Kontrollera länkstatus, faktisk hastighet och duplex på båda sidor samt normal administrationsåtkomst och de verkliga datavägar som behövs. Om en väg saknas, är instabil eller försämrad ska du via den oberoende åtkomsten återställa exakt de dokumenterade ursprungliga portvärdena och alla motpartsinställningar som anpassades för ändringen, inklusive ändrad FEC. Använd den återställningsväg som klarlagts i förväg och upprepa samma kontroller; konfigurationen på varje sida måste åter motsvara dess eget utgångsläge. Inget av exemplen, inte heller auto med autoneg on, är en generell återställning.

En MAC-adress åsidosätts endast för ett verifierat designberoende. Dokumentera före varje ändring den effektiva MAC-adressen och det konfigurerade läget (default eller override, inklusive en eventuell befintlig anpassad adress) som utgångsläge. Kontrollera Port Security, DHCP-bindningar, operatörens allowlist, HA, LAG och motpartens MAC-/ARP-kopplingar. Oberoende administratörsåtkomst och ett underhållsfönster måste finnas.

CLI-beskrivningarna för SFOS 22.0 och 23.0 säger att default behåller den befintliga MAC-adressen. Detta bevisar inte tolkningen att standard-MAC återställs efter en override. Kontrollera beteendet i den installerade builden; default är inget bekräftat inverskommando eller någon generell återställningsväg. Verifiera före override hur både den exakta adressen och läget återställs på den installerade builden. Om utgångsläget eller återställningsvägen inte kan verifieras ska inget ändras; klarlägg detta med Sophos Support.

Följande exempel ändrar MAC-adressen och kan bryta administrations- och dataanslutningar. Ersätt Port2 med den verifierade porten och den lokalt administrerade exempeladressen med den godkända måladressen som är unik i det egna nätverket. Den är inget återställningsvärde:

set network macaddr Port2 override 02:00:5e:10:00:02

För den verifierade återställningsvägen:

• Om det tidigare läget var override med en anpassad MAC-adress, använd den dokumenterade override-grenen för att ange exakt den dokumenterade adressen igen, inte exempeladressen. Förfarandet måste vara bekräftat för den installerade builden.
• Om det tidigare läget var default, använd Use default MAC address under Network > Interfaces > Edit interface > Advanced settings > Interface settings endast om denna inställning och återställningen av det dokumenterade utgångsläget har bekräftats på den installerade builden. Annars behövs ett buildspecifikt förfarande som bekräftats av Sophos Support; prova inte CLI default eller fabriksåterställning som ersättning.

Jämför efter ändringen och efter återställningen det konfigurerade läget och den effektiva adressen med de avsedda värdena; vid återställning måste båda motsvara det dokumenterade utgångsläget. Kontrollera även normal administratörsåtkomst, motpartens MAC-/ARP-inlärning och det berörda verkliga dataflödet. Stoppa vid avvikelser via den oberoende åtkomsten och klarlägg med supporten i stället för att experimentera med fler MAC-värden.

Sophos dokumenterar MTU 1500 och MSS 1460 som standardvärden; ändra dem endast med den kontrollerade proceduren i Kontrollera MTU och MSS vid VPN-problem.

För IPv6 anger DAD attempts hur många Neighbor Solicitation-meddelanden i följd brandväggen skickar vid Duplicate Address Detection på en preliminär (tentative) adress. Under Allowed RA servers anges MAC- eller IPv6-adresserna till de Router Advertisement-servrar vars stateless-konfiguration gränssnittet får acceptera. IPv6 Prefix Delegation på Sophos Firewall beskriver operatörsprefixet och den interna fördelningen; klientflaggor och annonserade prefix beskrivs i Konfigurera IPv6 Router Advertisement.

Följande fokuserade instruktioner hjälper vid konkreta uppgifter:

• Konfigurera och testa ett VLAN-gränssnitt
• Konfigurera och testa Wi-Fi som hanteras av SFOS
• Anslut befintliga APX med Wireless Mesh
• Konfigurera ett LAG-gränssnitt
• Konfigurera och testa en GRE-tunnel
• Transportera IPv6 över IPv4 eller IPv4 över IPv6 med en IP-tunnel
• Konfigurera och kontrollera PPPoE-WAN
• Konfigurera WAN-failover med en andra internetanslutning
• Konfigurera Sophos SD-RED
• Säkra Device Access
• Vidarebefordra Multicast mellan gränssnitt med en statisk Multicast-route
• Planera och verifiera dynamisk Multicast Routing med PIM-SM
• Konfigurera Site-to-Site IPsec VPN

Planera zonmodellen

Skilj mellan zon, gränssnitt och nätverksobjekt

De tre elementen har olika uppgifter:

• Zon: beskriver säkerhetsområdet som trafiken kommer från eller går till.
• Gränssnitt: ansluter brandväggen fysiskt eller virtuellt till ett nätverk.
• Nätverksobjekt: beskriver den konkreta IP-adressen eller det konkreta subnätet i en regel.

En regel blir exakt först när både zonen och nätverksobjektet stämmer. Source zone: LAN tillsammans med Source networks: Any är ofta onödigt brett. Omvänt hjälper inte ett korrekt nätverksobjekt om paketet kommer in genom en annan zon än den som anges i regeln.

Standardzonerna har fasta uppgifter:

• LAN för interna nätverk
• WAN för operatörs- och internetanslutningar
• DMZ för exponerade eller särskilt isolerade system
• WiFi för WLAN-miljöer
• VPN för Remote Access- och Site-to-Site-tunnlar

Zonen WiFi gäller för trådlösa nätverk som använder en egen zon. Med Bridge to AP LAN och Bridge to VLAN skapas däremot inget separat WiFi-interface; trafikvägen följer den valda bridge-tilldelningen.

Ett Wireless Network definierar gemensamma inställningar för WLAN-klienter: SSID, säkerhetsläge och hantering av klienttrafiken. Med Traffic Mode Separate zone skapar brandväggen en tillhörande VXLAN-tunnel. Valet av Traffic Mode avgör därmed också hur WLAN ansluts till brandväggen; det är inte bara en beteckning för nätverket.

Egna LAN-zoner passar till exempel för Client, Server, Management, Guest, IoT, VoIP, Backup eller OT. En egen DMZ-zon passar för publicerade servrar, Reverse Proxy-system och andra system vars åtkomst till det interna nätverket ska begränsas strikt.

Alla VLAN behöver inte en egen zon. Flera VLAN kan grupperas om de har samma förtroendenivå, brandväggsregler och Device Access. Om tillåtna mål, hanteringsåtkomst eller skyddsfunktioner skiljer sig åt är en egen zon vanligtvis tydligare.

Inga egna VPN-zontyper skapas för VPN-användare eller tunnlar mellan platser. Separationen sker i zonen VPN med exakta nätverksobjekt, användare och brandväggsregler.

Fastställ åtkomstriktningar före reglerna

Före konfigurationen räcker en kort lista över tillåtna riktningar. Exempel:

• Client till WAN: nödvändiga webb-, DNS-, NTP- och applikationstjänster
• Client till Server: endast definierade applikationsportar
• Guest till WAN: internetåtkomst men ingen åtkomst till interna nätverk
• IoT till Server: endast nödvändiga mål som DNS, NTP eller en hanteringsplattform
• Management till interna zoner: strikt begränsade och loggade administrationstjänster
• DMZ till LAN: blockerat som standard, endast uttryckligen nödvändiga anslutningar
• VPN till Server: endast godkända mål och tjänster

För varje tillåten riktning bör mål, tjänster, NAT-behov, loggning och ansvarig person vara kända. Utifrån detta skapas de faktiska reglerna. Struktur, ordningsföljd och matchning beskrivs i Konfigurera Sophos Firewall-regler på rätt sätt.

Kontrollera före en ändring

Innan ett gränssnitt skapas eller flyttas bör åtminstone följande punkter vara klarlagda:

• nätverkets zon och förtroendenivå
• IP-adress, subnät och Default Gateway
• DHCP-källa och DNS-servrar
• nödvändiga lokala brandväggstjänster
• brandväggs- och NAT-regler
• routing och SD-WAN
• testklient, förväntad åtkomst och förväntad loggpost

Produktionsändringar kräver en aktuell säkerhetskopia, en återställningsväg och en kontroll under Object usage.

Skapa och verifiera ett VLAN

Ett VLAN bildar en isolerad broadcast-domän: broadcast-trafik stannar inom detta VLAN. Att tilldela flera VLAN till samma säkerhetszon upphäver inte denna Layer 2-separation; zonen bestämmer kontexten för brandväggsregler och Device Access.

Ett VLAN skapas under Network > Interfaces > Add interface > Add VLAN. Följande fält är avgörande:

• Interface: det fysiska, RED-, Bridge- eller LAG-gränssnitt där det taggade VLAN:et anländer
• Network zone: VLAN-nätverkets säkerhetsområde
• VLAN ID: måste stämma med switchen och eventuellt Access Point
• IPv4/IPv6 configuration: vanligtvis en statisk gatewayadress för interna VLAN

Ett gäst-VLAN kan till exempel ligga på Port3 med VLAN ID 20, zonen Guest och gatewayadressen 192.168.20.1/24. På switchen måste VLAN 20 vara taggat på upplänken till Port3, och en klientport eller gäst-SSID placerar slutenheterna i detta VLAN.

Brandväggen kan visa gränssnittet korrekt trots att switchen skickar VLAN-trafiken till fel port, otaggad eller med ett annat VLAN ID. Ett VLAN är därför klart först när hela trafikvägen har testats:

1. Kontrollera VLAN ID, Parent Interface, zon, IP-adress och nätmask på brandväggen.
2. Konfigurera upplänken till brandväggen som Trunk med VLAN:et taggat.
3. Tilldela Access Port eller SSID till rätt VLAN.
4. Kontrollera DHCP, Gateway och DNS med en testklient.
5. Testa en tillåten intern åtkomst och en avsiktligt blockerad anslutning.
6. Kontrollera internetåtkomsten och bekräfta förväntat Firewall Rule ID i Log Viewer.

NAT behövs normalt inte för intern trafik. Om klienten får en adress men inte kan använda brandväggen som DNS-server eller nå den med Ping ska Device Access kontrolleras först. Hela förloppet med switchtaggning och DHCP beskrivs i Konfigurera och testa VLAN i Sophos Firewall.

Sophos anger ingen fast maximal mängd VLAN per fysisk Parent Port för XGS Appliances. Vid hög belastning, många VLAN eller HA-design kan flera upplänkar eller ett LAG ändå förenkla drift och felsökning.

Välj rätt gränssnittstyp

Virtuella gränssnitt och alias skapas under Network > Interfaces via Add interface. Välj önskad typ där och öppna dess konfiguration. Följande avsnitt hjälper dig att välja typ; ett alias kompletterar ett befintligt gränssnitt, medan exempelvis VLAN, Bridge och LAG representerar olika logiska anslutningar.

Alias

Ett Alias lägger till ytterligare en IP-adress på ett befintligt gränssnitt. Det är särskilt användbart när en operatör tillhandahåller flera publika IP-adresser i samma subnät.

Konfigurera och testa ett alias-IP på Sophos Firewall visar hur den extra adressen binds, används som hostobjekt i regler och NAT samt hur ARP och systemtrafik kontrolleras.

Flera separata WAN-gränssnitt i samma subnät kan orsaka ARP-problem och oåtkomliga gateways. I detta fall är ett Alias på det befintliga WAN-gränssnittet eller ett korrekt planerat LAG vanligtvis en bättre lösning. Ett Alias följer statusen för sitt Parent Interface och kan inte inaktiveras separat.

Bridge

En Bridge ansluter flera gränssnitt på Layer 2. Den kan användas med en IP-adress för routad trafik eller transparent utan IP-adress. VLAN är vanligtvis tydligare för nya segmenterade nätverk, medan Bridge lämpar sig bättre för migreringar eller medvetet transparenta designer.

Hela arbetsflödet med Bridge Members, STP, VLAN- och EtherType-filter, regler och kontroll beskrivs i Konfigurera ett Bridge-interface på Sophos Firewall.

Följande viktiga begränsningar gäller:

• En Bridge stöder inte Dynamic DNS, DHCP Client, PPPoE eller IPsec VPN.
• Trafik mellan Bridge Members kan fortfarande kräva brandväggsregler, till exempel LAN-to-LAN.
• HA kan inte aktiveras så länge STP är aktivt på en Bridge.
• Om VLAN Filter är aktiverat men inget VLAN är tillåtet kasserar brandväggen alla taggade ramar; otaggad trafik påverkas inte.
• Trafik över en Bridge utan IP-adress kan kasseras utan loggpost om den matchar en Web Proxy- eller NAT-regel.

För en transparent Bridge bör man därför kontrollera om Web Proxy Filtering eller Source Translation verkligen behövs.

Sophos dokumenterar NC-177630 för SFOS 22.0.0 GA-Respin Build 411. Felet kan uppstå när routad trafik över en Bridge översätts med SNAT eller MASQ och inkommande och utgående trafik använder samma fysiska Bridge Member. Svarspaketen kasseras då av Hairpin Filter utan att visas i drppkt. Detta gäller också när endast en Bridge Member är aktiv. Trafik över olika fysiska Bridge Members eller utan SNAT/MASQ påverkas inte.

Sophos anger SFOS 22.0.1 MR1 Build 490 som versionen med korrigeringen. På GA-Respin Build 411 får SNAT eller MASQ för det berörda trafikflödet bara tas bort om översättningen inte behövs och det finns en returväg till klientens ursprungliga IP-adress. Alternativt routas trafiken via ett dedikerat fysiskt gränssnitt i stället för via Bridgen. Om någon av de beskrivna utlösande faktorerna saknas eller om problemet uppstår på MR1 Build 490 eller senare måste en annan orsak sökas. Det separata SFOS 22-fallet för VLAN-trafik till brandväggen beskrivs i Kontrollera Bridge-VLAN efter SFOS 22.

En Bridge över RED kan förlänga ett Layer 2-nätverk mellan platser, men bör förbli ett motiverat specialfall.

Broadcast, ARP och okänd Unicast-trafik går då över WAN-anslutningen. En routad design med separata subnät för varje plats och riktade brandväggsregler är stabilare, skalbarare och enklare att felsöka.

LAG

En Link Aggregation Group samlar två till fyra fysiska gränssnitt i en logisk upplänk. VLAN kan sedan användas ovanpå den.

De vanliga driftlägena är:

• Active-Backup: en länk är aktiv och en annan tar över vid fel.
• LACP (802.3ad): flera länkar kan användas parallellt; brandvägg och switch måste vara identiskt konfigurerade.

Obundna fysiska gränssnitt med statisk konfiguration kan användas som medlemmar. PPPoE-, Cellular WAN- och WLAN-gränssnitt är uteslutna. Med LACP måste portarna vara av samma typ och ha samma hastighet.

xmit-hash-policy fördelar anslutningar mellan länkarna. En enskild TCP-anslutning blir normalt inte snabbare eftersom den stannar på en länk. LAG ger främst redundans och högre sammanlagd bandbredd för flera parallella anslutningar.

LAG och WAN-failover fyller olika funktioner: ett LAG samlar fysiska länkar i en logisk anslutning. Oberoende internetanslutningar används däremot via sina WAN-gateways under Network > WAN link manager. Flera aktiva gateways gör det möjligt att fördela belastningen mellan de tillgängliga anslutningarna; en reservgateway kan ta över när ett fel upptäcks. Detta garanterar varken att befintliga sessioner fortsätter utan avbrott eller mer bandbredd för en enskild anslutning. Konfigurera WAN-failover med en andra internetanslutning beskriver förfarandet och hur funktionen verifieras.

Cellular WAN och WWAN1

När Cellular WAN aktiveras skapar SFOS gränssnittet WWAN1. Det hör till mobilnätsanslutningen och ska inte likställas med ett fritt skapat VLAN eller alias. De begränsningar för HA som beskrivs nedan samt uteslutningen som LAG-medlem måste fortfarande beaktas.

I SFOS 23.0 finns under Network > Interfaces, i WWAN-gränssnittets Menu, åtgärderna Connect och Disconnect för att ansluta eller koppla från Cellular WAN-modemet. Reset startar om modemet och är endast tillgängligt för 5G-modeller från Quectel och Sierra Wireless, inte för andra modeller eller USB-donglar. Dessa åtgärder, som beskrivs för SFOS 23.0, ska inte förutsättas ha en identisk klickväg i SFOS 22.0.

Säkerställ oberoende administratörsåtkomst och ett underhållsfönster före Disconnect eller Reset om mobilnätsanslutningen används för produktionstrafik eller administrationsåtkomst. En hårdvaruomstart genom att stänga av brandväggen avbryter all trafik genom brandväggen; planera även för detta med oberoende administratörsåtkomst och ett underhållsfönster. För att starta om hårdvaran på en modell som inte stöds ska du först stänga av brandväggen, koppla ur och återansluta modemet och sedan starta brandväggen igen; ändra ingen fysisk WWAN-hårdvara medan brandväggen är igång. Kontrollera därefter gränssnittsstatusen och de data- och administrationsvägar som behövs. En omstart av modemet är ingen garanterad lösning på ett anslutningsfel vars orsak inte har klarlagts.

TAP / Discover Mode

En fysisk port i Discover Mode tar emot en trafikkopia som speglas av switchen. Porten står inte inline och kan varken blockera den observerade trafiken eller styra den med säkerhetspolicyer. Detta är användbart för inventering eller en proof of concept, men inte som produktionsväg för skydd.

I gränssnittsöversikten visas denna port som Discover, physical (TAP). Därmed går det att skilja den från ett vanligt gränssnitt i produktionstrafikens dataväg.

Konfigurera Discover Mode med TAP och SPAN beskriver hela konfigurationen med SPAN-port, Device Console-kommandon, Packet Capture, Security Audit Report och HA-gränser.

XFRM för route-based IPsec

För route-based IPsec skiljer man mellan Any-to-any-anslutningar och anslutningar med specifika Traffic Selectors. När båda subnäten är inställda på Any skapar SFOS automatiskt ett XFRM-gränssnitt i zonen VPN:

• Any-to-any: det automatiskt skapade XFRM-gränssnittet måste tilldelas en IP-adress under Network > Interfaces. Därefter avgör statiska, SD-WAN- eller dynamiska rutter vilken trafik som går genom tunneln.
• Traffic Selectors: SFOS skapar automatiskt en statisk rutt när tunneln upprättas. Om ett XFRM-gränssnitt visas ska man inte tilldela det en IP-adress eller manuella rutter.

Den officiella dokumentationen för SFOS 22 och SFOS 23 motsäger sig själv om skapandet av XFRM för specifika subnät: enligt ”Configure an XFRM interface” skapas inget XFRM, medan ”Route-based VPN” beskriver att ett skapas per konfiguration. Förutsätt därför inte att gränssnittet alltid finns eller alltid saknas. Expandera Listening interface under Network > Interfaces och kontrollera den faktiska synligheten i den installerade builden. Avsnittet Traffic Selectors i Konfigurera Site-to-Site IPsec VPN beskriver de befintliga kontrollerna av synlighet och trafik.

I båda fallen behöver VPN-trafiken lämpliga brandväggsregler. Under Administration > Device access tillåter IPsec i zonen WAN inkommande IPsec-anslutningsförfrågningar. Ping till en lokal brandväggsadress från zonen VPN tillåts separat via Ping/Ping6 under Administration > Device access. Ping mellan värdar genom VPN-tunneln är däremot transittrafik och kräver lämpliga rutter och brandväggsregler; tillståndet i Device Access tillåter inte denna trafik.

Ett XFRM inaktiveras inte direkt under Network > Interfaces, utan via sin anslutning under Site-to-site VPN > IPsec. Om SSL/TLS Decryption används för IPsec-trafik kräver Sophos att XFRM-gränssnittets MTU är minst 113 byte lägre än MTU på Listening Interface. Med MTU 1400 på Listening Interface får XFRM-gränssnittets MTU därför vara högst 1287. Denna produktspecifika gräns gäller FastPath Offload och är inte ett generellt värde för varje tunnel. Hela kontrollförloppet beskrivs i Kontrollera MTU och MSS vid VPN-problem.

RED

Ett RED-gränssnitt ansluter en extern plats via en krypterad tunnel. Driftläget avgör hur mycket trafik som går via den centrala brandväggen:

• Standard/Unified: den centrala brandväggen hanterar och filtrerar all trafik från platsen. Om tunneln går ner kan även internetåtkomsten försvinna.
• Standard/Split: endast definierade målnätverk går genom tunneln; internettrafiken går ut lokalt och filtreras inte centralt.
• Transparent/Split: RED arbetar transparent i ett befintligt nätverk. Det är flexibelt men svårare att planera och felsöka.
• Manual/Split: nätverkskonfigurationen görs i större utsträckning manuellt och kan möjliggöra lokal självständighet.

RED-tjänsten måste vara aktiv under System services > RED. Anslutningen kräver normalt TCP 3400, UDP 3410 samt NTP över UDP 123. DNS, korrekt systemtid och utgående internetåtkomst måste också fungera.

VLAN-beteendet beror på RED-modell, driftläge, LAN-portläge och WLAN-konfiguration. Sophos rekommenderar Standard/Unified när VLAN används bakom RED; på en SD-RED 60 är VLAN-taggning endast möjlig i detta läge. WLAN med Bridge to VLAN följer separata regler. Välj rätt driftläge för Sophos RED förklarar DHCP, gateway, internetväg och avbrottsbeteende för alla fyra lägen. Provisionering, LED-status och felsökning beskrivs i Konfigurera Sophos SD-RED.

Kontrollera status och Device Access

Gränssnittsstatus

Statusvärdena under Network > Interfaces visar om länken eller policyn bör undersökas först:

• Not configured: ingen zon har tilldelats
• Connected: konfigurerad och ansluten
• Connecting: hämtar en adress, till exempel via DHCP
• Disconnected: adressen har frigjorts
• Disconnecting: adressen håller på att frigöras
• Unplugged: ingen fysisk anslutning; för WiFi kan Access Point eller Wireless Network saknas
• Not available: konfigurerad FleXi Port utan installerad FleXi Port-modul

Vid Not configured eller Unplugged är brandväggsregler inte det första felsökningssteget. Kontrollera först Zone Binding, kabel, SFP, porthastighet, switchport samt DHCP eller PPPoE.

Lokala brandväggstjänster

Under Administration > Device access anges per zon om lokala tjänster som HTTPS, SSH, User Portal, VPN Portal, DNS, Ping/Ping6, Captive Portal, RADIUS SSO eller Wireless Protection ska vara åtkomliga.

Dessa tillstånd gäller själva brandväggen. Transittrafik mellan nätverk styrs med brandväggsregler. HTTPS och SSH bör endast tillåtas från ett hanteringsnätverk eller via en riktad Local service ACL exception rule. DNS krävs när klienter använder brandväggen som DNS-server.

⚠️ Om klienter får använda brandväggens Web Proxy behandlar SFOS HTTP- och HTTPS-förfrågningarna som interna Proxy-förfrågningar. Därför kan WebAdmin, Captive Portal, VPN Portal eller User Portal vara åtkomliga trots att respektive tjänst är inaktiverad för klientzonen. I en sådan design måste Proxy-åtkomst och lokala portaler kontrolleras separat.

Hantera beroenden och ändringar säkert

Object Usage före redigering eller borttagning

Zone Binding, DNS, Gateways, SD-WAN, Interface Hosts, VLAN, Dynamic DNS, DHCP, brandväggsregler, NAT och VPN kan vara beroende av samma gränssnitt. Object usage visar dessa referenser.

Det visade antalet uppdateras automatiskt endast en gång per dag. Klicka därför på Refresh före en ändring eller borttagning och dokumentera viktiga beroenden. Alla referenser kan inte redigeras i popup-fönstret. WAN-gateways och CLI-konfigurationer måste ändras på respektive konfigurationssida eller i CLI.

För redigerbara referenser i regler eller policyer leder antalet vidare till den aktuella konfigurationen:

1. Klicka på användningsantalet för det berörda objektet i kolumnen Usage. Popup-fönstret visar vilka konfigurationer som använder objektet.
2. Expandera rätt kategori med plusikonen för att visa dess regler eller policyer.
3. Klicka på den berörda regeln eller policyn för att redigera den. Ta bort referensen till objektet där, eller ersätt den med det avsedda ersättningsobjektet.

Efter beroendekontrollen aktiveras eller inaktiveras gränssnittet under Network > Interfaces i det berörda gränssnittets Menu med on respektive off. Säkerställ oberoende administratörsåtkomst och en återställningsväg före off; åtgärden kan bryta den dataväg som används för tillfället. Alias och XFRM kan inte inaktiveras separat här.

När ett gränssnitt inaktiveras behålls dess konfiguration. IPsec-tunnlar där brandväggen är initiator kopplas ner omedelbart. Tunnlar där brandväggen svarar och Remote Access-anslutningar avslutas senast genom inaktivitet eller Dead Peer Detection.

Ett virtuellt gränssnitt tas bort under Network > Interfaces via Menu > Delete interface. Utför denna åtgärd först efter Refresh under Object usage, en dokumenterad beroendekontroll samt förberedelse av säkerhetskopia och återställningsväg; den tar inte bara bort den synliga gränssnittsposten.

När ett virtuellt gränssnitt tas bort raderar SFOS alla brandväggsregler där det används, även om regeln innehåller andra gränssnitt. Dessutom tas beroende Zone Bindings, DHCP-servrar eller reläer, statiska ARP-poster och proxy-ARP-poster, Protected Servers och brandväggsregler som bygger på dem, Interface Hosts och deras gruppreferenser samt unicast- och multicastrutter bort. Alias-gränssnitt följer sitt överordnade gränssnitt; XFRM-gränssnitt hanteras via IPsec-anslutningen.

Även enbart redigering kan påverka Zone Binding, DNS, gatewayar, SD-WAN-rutter och -profiler, Interface Hosts, VLAN och Dynamic DNS. Efter redigering eller borttagning kan anslutningar tillfälligt sluta svara eller upphöra att fungera. Kontrollera därför de faktiska data- och hanteringsvägarna efter varje ändring, inte bara den sparade gränssnittsposten.

Avsiktligt ta bort konfigurationen för en fysisk port

En fysisk port finns kvar på apparaten; endast dess konfiguration kan tas bort. off och Network zone None är inte likvärdiga: off behåller konfigurationen, medan None tar bort IP-konfigurationen. Denna åtgärd används för att avsiktligt frigöra en port som inte längre behövs, inte som ett första reparationssteg vid Unplugged eller en gateway som inte kan nås.

⚠️ Kör Object usage > Refresh före borttagningen, dokumentera och migrera beroendena samt testa säkerhetskopian och den oberoende administratörsåtkomsten. Dokumentera IP-adresser, masker eller prefix, zon, gatewayar och alias för återställning. Återställ inte porten via den enda åtkomstvägen för hantering.

1. Öppna den berörda fysiska porten under Network > Interfaces.
2. Sätt Network zone till None. IP-konfigurationen försvinner redan i formuläret; kontrollera portens ID igen före nästa steg.
3. Spara med Save.
4. Översikten måste visa Unbound, status Disabled och IP-adress N/A. Kontrollera därefter via den oberoende åtkomsten att övriga nödvändiga data- och hanteringsvägar fortfarande fungerar.

Om fel port återställdes, återställ dess tidigare zon och IP-konfiguration via den oberoende åtkomsten eller konsolen. Återställ borttagna beroende konfigurationer utifrån den tidigare inventeringen eller säkerhetskopian; att tilldela en zon på nytt ersätter inte detta. Testa slutligen länk, gateway, DHCP, DNS, routning, regler och Device Access igen.

HA och fjärrändringar

Dedikerade HA Link-gränssnitt hör hemma i en DMZ-zon. Andra övervakade gränssnitt eller gränssnitt som används för administration kan finnas i andra zoner.

Active-Active HA kräver statiskt konfigurerade gränssnitt. Cellular WAN inaktiveras med HA. Active-Passive kan använda dynamiskt adresserade WAN-gränssnitt, men anslutningar som PPPoE tas inte nödvändigtvis över med sin session vid Failover.

Före en produktionsändring:

1. Dokumentera konfiguration och beroenden.
2. Förbered underhållsfönster, tidpunkt för återställning, säkerhetskopia och en konkret återställningsväg.
3. Testa en oberoende administrationsåtkomst, till exempel Sophos Fusion (tidigare Sophos Central), en andra WAN-anslutning, ett separat hanteringsnät eller en person på plats.
4. Förbered en testklient eller entydig testtrafik och lägg därefter till och testa den nya zonen eller trafikvägen.
5. Kontrollera länk, IP, Gateway, DHCP, DNS, brandväggsregler, NAT och Device Access.
6. Ta bort gamla objekt först när den nya trafikvägen är stabil.

För en VLAN Trunk ska tidigare VLAN ID, Native VLAN och switchportprofil ingå i återställningsvägen. Vid WAN-ändringar är operatörsvärden och SD-WAN-rutter viktiga; för XFRM tillkommer tunnel, routing och båda riktningarna i brandväggsreglerna.

Felsök systematiskt

Orsaken går oftast snabbare att avgränsa genom att börja med symtomet:

• Gränssnittet är unbound eller disabled: Kontrollera först om porten avsiktligt inte har tilldelats någon zon eller om gränssnittet har stängts av. Om porten tidigare var i produktionsdrift, jämför den förväntade zonen och IP-konfigurationen med den dokumenterade konfigurationen och återställ dem via en oberoende åtkomstväg. None är ingen reparation, utan tar bort IP-konfigurationen; det avsiktliga förfarandet förklaras ovan under Avsiktligt ta bort konfigurationen för en fysisk port.
• VLAN fungerar inte: jämför VLAN ID, Parent Interface, Trunk, Tagged/Untagged och Native VLAN.
• Brandväggen kan inte nås med Ping, HTTPS eller DNS: kontrollera Device Access och Local Service ACL, inte en vanlig brandväggsregel först.
• Intern trafik blockeras: kontrollera Source zone, Destination zone, nätverksobjekt, routing, Services och regelordning.
• WAN Gateway förblir inaktiv: kontrollera länk, IP, Gateway, PPPoE-uppgifter och WAN Link Manager.
• Flera WAN-portar ligger i samma subnät: undvik ARP-problem och överväg Alias eller LAG.
• SFP eller Port Speed stämmer inte: Felsök SFP och SFP+ systematiskt visar hur transceiver, kabel, breakout och hastighet jämförs på båda sidor.
• VPN eller PPPoE är instabilt: kontrollera MTU och MSS.

Den egentliga felsökningen bör genomföras i följande ordning:

1. Network > Interfaces: länk, IP, Zone och Gateway
2. Network > Zones: zontyp och Device Access
3. Hosts and services: nätverks- och Service Objects
4. Firewall rules: riktning, ordning, Services och Logging
5. NAT rules: Original och Translation
6. Log viewer: Rule ID eller orsak till att trafik kasseras
7. Diagnostics > Tools > Packet capture: paketets ankomst och vidarebefordran

Om regeln ser korrekt ut men inte matchar hjälper Brandväggsregeln matchar inte. Paketflödet beskrivs i Använd Packet Capture i WebAdmin.

Checklista för drift

• zoner planerade och dokumenterade efter förtroendenivå
• zon, gränssnitt och nätverksobjekt inte sammanblandade
• VLAN ID, Parent, Trunk och Gateway kontrollerade
• Device Access begränsad, särskilt för HTTPS, SSH, DNS, Ping och portaler
• brandväggsregler skapade med konkreta zoner, nätverk, tjänster och Logging
• Alias kontrollerat för ytterligare operatörsadresser i samma subnät
• DHCP, DNS, NTP, routing och vid behov NAT testade
• Object Usage uppdaterad och kontrollerad före ändringar
• oberoende administrationsåtkomst och återställningsväg förberedda
• länkstatus, Log Viewer och Packet Capture kontrollerade efter ändringen

FAQ