Konfigurera zoner och interfaces i Sophos Firewall

Zoner och interfaces hör till de viktigaste grunderna i en Sophos Firewall. När de planeras ordentligt blir senare firewall-regler, NAT, VPN, Web Protection och troubleshooting mycket enklare. Om de klickas ihop för snabbt skapas däremot ofta en miljö där regler blir oöverskådliga eller management-tjänster är åtkomliga från fel platser.

En zon är en logisk säkerhetsgrupp. Ett interface är en fysisk eller virtuell anslutning, till exempel Port1, ett VLAN, en Bridge, ett LAG, ett Alias, ett RED-interface eller ett XFRM-interface för route-based VPN. Varje interface tillhör exakt en zon. Firewall-regler arbetar senare mycket med dessa zoner, därför bör zonstrukturen planeras både tekniskt och säkerhetsmässigt.

Varför zoner är viktiga

Zoner i Sophos Firewall är mer än bara visuell gruppering. De definierar säkerhetsområden och används på flera ställen:

• Firewall-regler använder Source zone och Destination zone.
• Device Access styr per zon vilka lokala firewall-tjänster som är åtkomliga.
• NAT, SD-WAN, VPN, Web Protection och loggar blir lättare att förstå med tydliga zoner.
• Troubleshooting blir tydligare eftersom man direkt ser från vilket säkerhetsområde ett paket kommer och vart det ska.

Bra zonering förhindrar inte automatiskt alla fel, men den tvingar fram tydliga gränser. Ett klientnät, ett servernät, ett gäst-WiFi och en DMZ bör inte alla behandlas som LAN om de har olika risker och regler. Annars uppstår senare breda Allow-regler, oklara undantag och onödigt öppen management-åtkomst.

Bra zoner svarar alltid på frågan: vilka nät har samma förtroendenivå och kan behandlas på liknande sätt? Om två nät behöver olika rättigheter, olika logging-krav eller olika management-åtkomst är en egen zon eller åtminstone ett mycket medvetet regelkoncept rimligt.

Förstå standardzonerna

Sophos Firewall levereras med flera standardzoner:

Standardzonerna finns under Network > Zones. Egna zoner kan skapas som typen LAN eller DMZ. Ytterligare WAN- eller VPN-zoner kan inte skapas fritt, eftersom dessa zontyper har särskilda funktioner i firewallen.

Viktigt: en zon är inte en automatisk tillåtelse. Även mellan två interfaces i samma zon behövs passande firewall-regler beroende på riktning och scenario. Sophos påpekar i dokumentationen att traffic mellan två LAN-zone-interfaces inte automatiskt tillåts, utan kräver en passande LAN-to-LAN-regel.

Planera zoner innan de skapas

Innan zoner skapas bör man notera vilka nät som har olika säkerhetskrav. Typiska exempel:

• Arbetsplats-LAN
• Servernät
• Management-nät
• DMZ
• Gäst-WiFi
• VoIP
• Kamera- eller IoT-nät
• Produktionsnät
• VPN-klienter
• MPLS- eller site-anslutningar

En egen zon är rimlig när ett nät behöver egna regler, egen Device Access eller en annan förtroendenivå. Flera VLAN kan också ligga i samma zon om de ska behandlas likadant. För många zoner gör inte en konfiguration automatiskt säkrare. De hjälper bara om det finns tydliga regler bakom.

För många små och medelstora miljöer är den här grundstrukturen en bra start:

Inte varje VLAN behöver automatiskt en egen zon. Om flera klient-VLAN får exakt samma firewall-regler, samma Web Policy och samma Device Access kan de stanna i en gemensam klientzon. Men om ett VLAN får nå servrar, ett annat bara Internet och ett tredje inte alls ska nå lokala firewall-tjänster bör separationen modelleras medvetet.

Ett bra mönster är:

Skapa en ny zon

Öppna Network > Zones och klicka på Add.

1. Ge ett kort och tydligt namn, till exempel Server, Guest, Management eller MPLS.
2. Välj typen LAN eller DMZ.
3. Under Device Access, definiera medvetet vilka lokala tjänster på firewallen som får nås från zonen.
4. Spara.

LAN eller DMZ som zontyp?

För egna zoner i Sophos Firewall kan man normalt välja mellan LAN och DMZ. Båda typerna grupperar interfaces så att de senare kan användas rent i regler, Device Access och policies. Skillnaden ligger främst i säkerhetstanken bakom zonen.

LAN används för interna, i grunden betrodda nät. Det kan vara klientnät, interna servernät, management-nät, VoIP, skrivare eller interna VLAN. Även i en LAN-zon gäller: traffic mellan interfaces tillåts inte automatiskt. Om två LAN-zoner eller två interfaces inom en LAN-zon ska kommunicera behövs passande firewall-regler.

DMZ används för nät med högre risk eller tydlig isolering. Typiska exempel är publika webbservrar, reverse proxies, mail gateways, jump hosts eller system som måste nås från flera säkerhetsområden. En DMZ bör planeras så att den bara får nödvändiga anslutningar inåt. Om en server i DMZ komprometteras får det inte automatiskt ge bred åtkomst till interna LAN.

Som enkel tumregel:

HA-interfaces hör också hemma i en DMZ-zon. För vanliga admin- eller klientnät är LAN oftast den lämpligare typen.

För ett internt adminnät kan HTTPS vara rimligt. För vanliga klient- eller gästnät bör management-åtkomst undvikas. Ping/ping6 är ofta hjälpsamt för troubleshooting, men bör aktiveras medvetet. DNS behövs bara om klienter i zonen använder firewallen som DNS-server.

⚠️ Device Access är inte samma sak som en firewall-regel. Åtkomst till lokala tjänster på firewallen, till exempel WebAdmin, SSH, User Portal, DNS eller Ping, styrs via Administration > Device access och lokala ACL-undantag.

Konfigurera interface

Interfaces finns under Network > Interfaces. En fysisk port kan till exempel köras som LAN, WAN eller DMZ. Virtuella interfaces som VLAN, Bridge, LAG, RED eller XFRM skapas dessutom.

För ett fysiskt interface är dessa punkter särskilt viktiga:

Endast interfaces i WAN-zonen får gateway-konfiguration. Interna interfaces adresseras oftast statiskt. Vid provideranslutningar kan DHCP eller PPPoE vara rimligt.

Beskrivande namn är viktiga. PortD säger lite om sex månader. Server VLAN, MPLS Provider, Guest WiFi eller Core Switch Trunk hjälper betydligt mer i drift.

Skapa VLAN-interface

Ett VLAN-interface skapas under Network > Interfaces > Add interface > Add VLAN. Det viktigaste är Parent Interface, Zone, VLAN ID och IP-konfiguration.

Parent Interface är den fysiska port eller LAG där VLAN:et kommer taggat. Om switchen skickar VLAN:et på en annan port, otaggat eller med fel VLAN ID, ser firewallen visserligen ett VLAN-interface, men klienterna når det inte tillförlitligt.

För interna VLAN använder man oftast en statisk IP-adress på firewallen, till exempel som Default Gateway för VLAN:et. Zonen avgör senare vilka firewall-regler, Web Policies och Device Access-inställningar som gäller. Därför bör man vid skapande av ett VLAN inte bara fylla i IP-adressen, utan direkt fundera på om VLAN:et hör bättre hemma i Client, Server, Management, Guest, DMZ eller en annan zon.

Läsa interface-status korrekt

Under Network > Interfaces visar Sophos Firewall statusmeddelanden. De är mycket hjälpsamma vid troubleshooting eftersom man snabbt ser om ett interface bara är felkonfigurerat eller om det verkligen saknas link.

Om ett interface oväntat visar Not configured eller Unplugged bör man inte börja med firewall-regler. Först kontrolleras Zone Binding, link, SFP/transceiver, kabel, switchport och vid DHCP/PPPoE adressutdelningen.

Placera VLAN, Bridge, LAG, Alias och RED

Sophos Firewall stöder olika interface-typer. För nybörjare är det viktigast att veta när vilken typ är rimlig.

För nya installationer är VLAN på en tydligt definierad uplink till switchen oftast renare än en stor Bridge över många portar. En Bridge kan vara praktisk vid migreringar eller mycket enkla setups, eftersom flera portar behandlas som ett gemensamt Layer-2-segment. Just det är också nackdelen: säkerhetsgränser, broadcast-domäner och felkällor blir mindre tydliga.

Vi rekommenderar därför Bridges bara riktat och inte som standarddesign. I praktiken har Bridges flera nackdelar:

• Flera portar delar samma Layer-2-segment, vilket gör att broadcasts och störningar lättare påverkar flera enheter.
• Firewall-regler blir mindre överskådliga eftersom separationen inte längre syns tydligt via egna interfaces, VLANs och zoner.
• Troubleshooting blir svårare eftersom packet flow, MAC learning, STP och switchkonfiguration måste analyseras tillsammans.
• Senare segmentering blir mer omfattande om en enkel Bridge senare ska bli separata klient-, server-, gäst- eller management-nät.
• HA-, VLAN-, DHCP- eller Device Access-design blir snabbt otydliga om för många funktioner går via en Bridge.

Bridges kan skapas i Sophos Firewall över fysiska interfaces, RED interfaces, VLANs eller LAGs. De kan köras med eller utan egen IP-adress. Här uppstår ofta missförstånd:

• Utan IP-adress arbetar Bridge transparent, men kan inte användas som ett normalt routed interface.
• Om routing på en Bridge behövs måste Bridge få en IP-adress.
• För traffic mellan Bridge members krävs fortfarande passande firewall-regler mellan berörda zoner, till exempel LAN till LAN.
• STP kan vara rimligt om redundanta vägar finns och bridge loops ska förhindras.
• VLAN filters och EtherType filters kan hjälpa till att begränsa Layer-2-traffic genom en Bridge.
• Sophos påpekar att traffic över Bridge interfaces utan IP-adress kan droppas om den träffar en firewall-regel med Web Proxy Filtering eller en NAT-regel. Sådana drops loggas inte. Vid NAT måste man därför vara särskilt uppmärksam på Source Translation respektive Override Source Translation.

Den sista punkten är viktig: om man via en Bridge plötsligt inte ser några loggar trots att traffic inte fungerar, ligger problemet inte alltid i Log Viewer. Det kan bero på Bridge-läge, NAT eller Web Proxy Filtering.

Om VLANs redan finns på switchen bör firewallen medvetet ta över dem som egna VLAN-interfaces. Det ger tydligare zoner, renare firewall-regler och är oftast bättre att underhålla långsiktigt.

RED Bridge: sträcka ett nät över platser

Det är tekniskt möjligt att lägga RED-interfaces i en Bridge och därmed sträcka ett Layer-2-nät över flera platser. Det kan hjälpa i specialfall, till exempel om en applikation absolut måste stanna i samma subnet eller vid en migrering utan omedelbara IP-ändringar.

Vi skulle bara rekommendera denna design mycket försiktigt. En Bridge över RED förlänger Layer-2-domänen genom tunneln. Broadcasts, ARP, unknown unicast packets och andra Layer-2-effekter går då över en WAN- eller Internetförbindelse. Det kan försämra performance och göra fel svårare att förstå. Om RED-tunneln är instabil påverkas det sträckta nätet direkt.

I de flesta fall är en routed design bättre: varje plats har egna subnet, firewallen routar mellan näten och firewall-regler definierar exakt vad som tillåts. Det är renare, mer skalbart och betydligt trevligare vid troubleshooting.

LAG: planera redundans och bandbredd rätt

En Link Aggregation Group (LAG) samlar flera fysiska portar till ett logiskt interface. Det är rimligt när man behöver redundans till core-switchen eller mer bandbredd mellan firewall och switch. LAG ersätter däremot inte tydlig zonering. LAG-interfacet är i slutändan fortfarande bara ett interface där man till exempel kör VLANs eller tilldelar en zon.

Sophos Firewall stöder framför allt två typiska lägen:

Viktigt: LACP fungerar bara rent om motparten är korrekt konfigurerad. På switchen måste portarna ligga i samma LAG group, använda samma hastighet och duplexläge och passa till firewall-konfigurationen. Om man bara skapar en LAG på firewallen men inte konfigurerar switchen rätt uppstår ofta svårförklarad packet loss eller asymmetriska anslutningsproblem.

För LAGs finns några praktiska gränser:

• En LAG i Sophos Firewall består av två till fyra fysiska interfaces.
• Som medlemmar passar bara unbound fysiska interfaces med statisk konfiguration.
• PPPoE-, Cellular-WAN- och WLAN-interfaces kan inte användas som LAG members.
• Vid LACP (802.3ad) måste member ports ha samma typ och hastighet.
• xmit-hash-policy avgör hur sessions fördelas över länkarna. En enskild TCP-session blir normalt inte plötsligt snabbare eftersom den oftast stannar på en länk.

För små miljöer räcker ofta en enda ren trunk port. LAG lönar sig framför allt när core-switchen ska anslutas redundant, många VLANs går över samma uplink eller firewallen verkligen behöver mer throughput till switchen.

XFRM: förstå route-based IPsec som interface

Ett XFRM-interface hör till route-based IPsec VPN. Det planeras inte som ett normalt VLAN eller en fysisk port, utan uppstår i samband med en IPsec-anslutning. Sophos Firewall skapar ett XFRM-interface automatiskt när både lokala och remote subnet i en IPsec-anslutning är satta till Any.

Det är en viktig skillnad mot klassiska policy-based IPsec-tunnlar. Vid route-based VPN avgör inte bara IPsec Policy, utan även routing, firewall-regler och XFRM-interface vart traffic går. Det gör mer komplexa site-anslutningar flexiblare, men kräver ren planering:

• XFRM-interfacet ligger i zonen VPN.
• Under Administration > Device access måste IPsec vara tillåtet för WAN-zonen så att anslutningen kan byggas upp.
• Om lokala eller remote subnet inte är Any skapas inget XFRM-interface.
• MTU och MSS är särskilt viktiga vid route-based VPN eftersom IPsec ger extra overhead.
• Ett XFRM-interface stängs inte av direkt under Network > Interfaces, utan via tillhörande IPsec-anslutning under Site-to-site VPN > IPsec.

För administratörer är XFRM särskilt relevant när SD-WAN-routing, dynamic routing eller flera nät över en site-tunnel ska styras rent. Om man bara behöver en mycket enkel Site-to-Site-anslutning med två fasta nät är en klassisk policy-based tunnel ofta lättare att förstå.

RED: externa platser som eget interface-koncept

RED-interfaces är ingen normal switchport. RED står för Remote Ethernet Device och används för att ansluta en extern plats till Sophos Firewall via en krypterad tunnel. Det kan göras med dedikerad SD-RED-hårdvara eller med Firewall-to-Firewall RED-anslutningar.

Före planeringen bör det vara klart vilket driftläge som behövs:

För många företag är Standard/Unified den renaste varianten om platsen helt ska skyddas via den centrala firewallen. Nackdelen är tydlig: om RED-tunneln faller tappar platsen, beroende på design, även centralt styrd Internetåtkomst. Standard/Split minskar beroendet, men betyder också att lokal Internet-traffic inte längre filtreras och loggas helt via den centrala Sophos Firewall.

Vid RED bör man tidigt kontrollera:

• RED-tjänsten måste aktiveras under System services > RED.
• För anslutningen behövs typiskt TCP 3400, UDP 3410 och NTP 123.
• SD-RED-enheter behöver korrekt tid, annars kan TLS handshake och tunneluppbyggnad misslyckas.
• Vid första driftsättning är DHCP på uplinken oftast enklare eftersom enheten måste nå provisioning.
• VLANs är inte lika rimliga i alla RED-lägen. Standard/Split och Transparent/Split är inte avsedda för VLAN-tagged frames. Om VLANs behövs bakom en SD-RED bör driftläget väljas särskilt noggrant.
• Om en RED-enhet står bakom en provider-router måste utgående anslutningar och DNS/NTP fungera.

RED är mycket praktiskt för små platser, men bör inte behandlas som en vanlig LAN-kabel. Avgörande är om platsen ska skyddas centralt, vara lokalt autonom eller bara delvis kopplas via tunneln. Det påverkar DHCP, DNS, VLANs, routing, firewall-regler, logging och troubleshooting.

Begränsa Device Access tydligt

Under Administration > Device access ser man vilka lokala tjänster på firewallen som är åtkomliga från vilka zoner. Bland annat:

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

För produktionsmiljöer gäller: ju färre lokala tjänster som är åtkomliga från en zon, desto bättre. Särskilt HTTPS och SSH bör bara tillåtas från betrodda management-nät eller via en Local service ACL exception rule.

Om SSH behövs hjälper denna guide: skapa SSH-anslutning till Sophos Firewall.

Ha beroenden i åtanke

Ändringar på interfaces är sällan isolerade. Sophos påpekar att interface-ändringar kan påverka beroende konfigurationer, till exempel:

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

Före större ändringar bör man därför kontrollera under Object usage var ett interface, en zon eller ett host object redan används. Sophos Firewall visar objektanvändning och länkar direkt till många beroende konfigurationer.

Vid avaktivering eller borttagning måste man vara särskilt försiktig:

• Om ett interface avaktiveras finns konfigurationen kvar och statusen är fortfarande synlig.
• Site-to-site IPsec tunnels där firewallen är initiator kopplas från direkt.
• Site-to-site IPsec tunnels som responder och Remote Access-anslutningar bryts senast genom inaktivitet eller Dead Peer Detection.
• Alias- och XFRM-interfaces kan inte avaktiveras direkt som normala interfaces. Alias-interfaces följer det fysiska interfacet, XFRM-interfaces avaktiveras via Site-to-site VPN > IPsec.
• Om ett virtuellt interface tas bort kan beroende firewall-regler, DHCP-konfigurationer, ARP-poster, routes, interface-hosts och andra referenser också tas bort.

Därför bör man alltid kontrollera före borttagning om interfacet används i firewall-regler, NAT-regler, DHCP, routing, SD-WAN, Dynamic DNS eller host objects. En obetänksam borttagning kan ta bort mer än bara interfacet.

Vanliga fallgropar

Interface är unbound eller disabled: kontrollera om en zon är tilldelad. Ett fysiskt interface kan inte raderas, men dess konfiguration kan tas bort genom att zonen sätts till None.

VLAN fungerar inte: kontrollera VLAN ID, switchport, Tagged/Untagged-konfiguration, Native VLAN och om VLAN:et skapades på rätt Parent Interface.

Klienter når inte firewallen via Ping eller HTTPS: kontrollera inte vanliga firewall-regler först. Kontrollera Administration > Device access och lokala ACL-undantag.

Traffic mellan två interna nät fungerar inte: kontrollera Source zone, Destination zone, nätobjekt, routing och firewall-regelns position.

WAN-gateway blir inte aktiv: kontrollera IP-konfiguration, Gateway-IP, link status, PPPoE-uppgifter, DNS och vid behov WAN link manager.

Flera WAN-interfaces i samma subnet: om flera WAN-interfaces använder IP-adresser från samma subnet kan ARP-problem uppstå och gateways kan bli oåtkomliga. Om en provider levererar flera publika IP-adresser i samma subnet är Alias- eller LAG-interfaces oftast renare än flera separata WAN-interfaces i samma nät.

SFP, port speed eller breakout passar inte: porthastigheten på switch, router, transceiver och firewall måste passa ihop. En 25 Gbit/s-port kan inte utan rätt teknik anslutas direkt till en 40 Gbit/s-port. På modeller med 40G- eller 100G-portar kan breakout-kablar vara relevanta om en port ska delas upp i flera mindre portar.

MTU-problem vid VPN eller PPPoE: kontrollera MTU och MSS. Vid VPN-traffic kan ett för högt MTU-värde orsaka packet loss som i vardagen ser ut som slumpmässiga anslutningsproblem.

Troubleshooting

För felsökning är denna ordning praktisk:

1. Network > Interfaces: kontrollera link status, IP address, zone och gateway.
2. Network > Zones: kontrollera Device Access och zontyp.
3. Hosts and services: kontrollera om host och service objects är korrekta.
4. Rules and policies > Firewall rules: kontrollera Source zone, Destination zone, Services och ordning.
5. Rules and policies > NAT rules: om NAT är inblandat, jämför Original och Translated tydligt.
6. Log viewer: kontrollera vilken regel eller drop som gäller.
7. Diagnostics > Tools > Packet capture: kontrollera om paket överhuvudtaget kommer fram och vart de vidarebefordras.

Om zoner och interfaces är rent skapade blir nästa steg betydligt enklare: förstå och konfigurera Sophos Firewall-regler korrekt. Om traffic trots till synes korrekt zon inte fungerar hjälper checklistan firewall-regel träffar inte: kontrollera ordning, matching och loggar. För djupare analys kan man dessutom använda Packet Capture i WebAdmin och vid översättningar eller port forwarding artikeln förstå NAT i Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Mer information

• 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