Konfigurera och felsök Sophos SD-RED

Med en Sophos SD-RED kan man ansluta filialer, kontor eller mindre hemmakontor till en Sophos Firewall. RED skapar en krypterad tunnel till brandväggen och tillhandahåller ett nätverk på den avlägsna platsen som styrs centralt via brandväggen.

Den praktiska fördelen: På plats behövs normalt ingen komplex VPN-konfiguration. SD-RED ansluts till internet, laddar sin konfiguration via Sophos RED Provisioning Service och bygger sedan upp tunneln till Sophos Firewall. Tunneln ensam löser dock inte allt. Zoner, brandväggsregler, DHCP, VLAN, routing, DNS och firmwarestatus måste också stämma.

Driftläget måste bestämmas före den egentliga konfigurationen. Det avgör DHCP, gateway, internetväg, central kontroll och beteende vid tunnelavbrott. Välj rätt driftläge för Sophos RED förklarar skillnaderna och beslutskriterierna.

Planering och förutsättningar

Klassificering: SD-RED och RED mellan brandväggar

RED har två aktuella användningsfall som måste hållas isär. Den här artikeln behandlar en fysisk SD-RED 20 eller SD-RED 60 på en filial. SFOS 22 stöder fortfarande också en Site-to-Site RED-tunnel mellan två Sophos Firewall, där en brandvägg fungerar som Firewall RED server och den andra som Firewall RED client.

Det andra användningsfallet kräver ingen RED-hårdvara. Konfigurera Site-to-Site RED mellan två Sophos Firewall förklarar provisioningfilen, statiska routes utan valt gränssnitt, regler på båda sidor och RED-tjänsten. SD-RED-driftlägena gäller inte för den designen.

Förutsättningar på huvudplatsen

Innan RED ansluts bör följande punkter vara klara på Sophos Firewall:

• RED Service är aktiverad på brandväggen.
• Offentlig IP-adress eller DNS-/DynDNS-namn för brandväggen är åtkomlig.
• RED-anslutningar till brandväggen är tillåtna på WAN-sidan.
• RED är tillåten under Administration > Device access för rätt WAN-zon eller specifikt tillåten via Local Service ACL.
• RED-gränssnitt, zon och IP-konfiguration är planerade.
• Brandväggsregler från RED-nätet till målnäten är förutsedda.
• DHCP, DHCP Relay eller statisk adressering för klienter bakom RED är klarlagd.
• RED Firmware Pattern på brandväggen är aktuell.
• Backup och firmwarestatus för brandväggen är dokumenterade före större ändringar.

För RED-kommunikation är särskilt TCP 3400, UDP 3410 och NTP 123 relevanta. Dessa anslutningar får inte blockeras av leverantörsroutrar, brandväggar uppströms eller säkerhetsgateways.

Förutsättningar på den avlägsna platsen

På den avlägsna platsen behöver SD-RED en stabil internetanslutning. Avgörande är inte bara bandbredd, utan framför allt stabilitet, latens, paketförlust och om leverantören tillåter de nödvändiga anslutningarna.

Man bör kontrollera:

• Internetanslutningen är stabil.
• WAN-porten på RED får en adress via DHCP eller har en korrekt statisk konfiguration.
• Standardgateway är åtkomlig.
• DNS fungerar.
• NTP är åtkomlig.
• TCP 3400, UDP 3410 och NTP 123 blockeras inte.
• Leverantörsroutern eller en brandvägg uppströms utför ingen oväntad filtrering.
• Vid VLAN är det klart vilken port som är taggad, otaggad eller hybrid.

För enkla platser räcker ofta en liten anslutning. I praktiken är dock paketförlust, instabila konsumentroutrar, CGNAT, DNS-problem eller restriktiva leverantörsbrandväggar oftare orsaken än ren bandbredd.

Provisionering och driftsättning

Provisionera automatiskt via Sophos Provisioning Service

För normal online-provisioning behöver brandväggen och SD-RED internetåtkomst. Vid den första starten måste SD-RED få en WAN-adress via DHCP för att kunna hämta konfigurationen. En statisk WAN-konfiguration kräver därför manuell provisioning via USB. På brandväggen aktiveras RED provisioning service under System services > RED, kontaktuppgifterna anges och Sophos användarvillkor godkänns.

Därefter skapas ett gränssnitt under Network > Interfaces > Add interface > Add RED. Ställ in Branch name, enhetstyp, Automatically via provisioning service, brandväggsadress, uplink, driftläge, RED-nät, zon och DHCP för platsen. För en RED som används för första gången lämnas Unlock code tomt. När konfigurationen sparas laddar brandväggen upp den till provisioning-tjänsten. SD-RED hämtar den, öppnar kontrollkanalen på TCP 3400 och upprättar därefter Layer 2-tunneln på UDP 3410.

För den egna RED-zonen anger du ett namn som RED-Branch under Network > Zones > Add, ställer in Type på LAN eller DMZ och väljer endast de tjänster som faktiskt behövs under Device access. Spara med Save och välj denna zon under RED network settings på RED-gränssnittet. I Administration > Device access aktiveras däremot tjänsten RED för den zon från vilken RED når brandväggen, normalt WAN; tillämpa med Apply. Klientzonen bakom RED och RED-tunnelns ingångszon är inte samma sak.

Vid den första lagringen genererar provisioning-tjänsten en enhetsspecifik unlock code. Den visas i WebAdmin och skickas till e-postadressen som konfigurerats under System services > RED. Koden ska förvaras säkert eftersom den behövs när RED flyttas till en annan brandvägg. WebAdmin visar den igen när gränssnittet tas bort. Om koden saknas måste Sophos Support kontaktas.

Ange globala RED-skyddsinställningar medvetet

Vid den första aktiveringen under System services > RED skapar SFOS ett certifikat för RED-kommunikationen från Organization name, City, Country och Email. Därför får Organization name och City inte innehålla omljud eller specialtecken. E-postadressen måste förbli nåbar, eftersom Sophos skickar nya unlock codes dit.

För aktuella SD-RED 20 och 60 är TLS v1.2 (strict) and later en lämplig utgångspunkt. Valet använder endast de TLS 1.2-chiffer som Sophos rekommenderar. TLS v1.2 and later omfattar dessutom chiffer som Sophos inte rekommenderar och ska inte väljas utan ett bekräftat kompatibilitetsbehov. Efter en ändring ska alla RED-tunnlar i produktion anslutas på nytt och testas kontrollerat.

Automatic device deauthorization förhindrar att en RED som varit frånkopplad länge förblir auktoriserad obegränsat. Perioden måste passa den egna incident- och utbytesprocessen: när den löper ut tas enheten inte bort, men RED-gränssnittet måste uttryckligen aktiveras igen under Network > Interfaces. Övervakning och dokumentation av unlock code ingår därför i detta skydd.

Låt RED unified firmware vara aktiverat för SD-RED 20 och 60. Ett nytt RED-firmwaremönster installeras medvetet under Backup & firmware > Pattern updates och installeras inte automatiskt. Planera ett underhållsfönster och testa därefter tunneln och en klient.

För att konfigurera funktionen aktiverar du Automatic device deauthorization, anger tidsfristen och väljer Apply. Aktivera åter en RED vars auktorisering har återkallats efter tidsfristens slut under Network > Interfaces via Menu till höger om den berörda enheten. Skyddsfunktionen gäller även en Firewall RED Client. RED unified firmware är valt som standard; vid en brandväggsmigrering behålls dock den befintliga inställningen. Efter en fabriksåterställning är alternativet valt igen. Kontrollera därför det faktiska värdet efter migrering eller återställning i stället för att bara anta standardvärdet.

Ansluta SD-RED

Typiskt förlopp:

1. Anslut WAN-porten på SD-RED till leverantörsroutern eller modemet.
2. Anslut LAN-porten till testklient, switch eller lokalt nätverk.
3. Förse SD-RED med ström.
4. Vänta tills RED startar, kontrollerar gateway och internet, laddar konfigurationen och bygger upp tunneln.
5. Kontrollera på Sophos Firewall om RED-gränssnittet är aktivt.
6. Anslut testklient bakom RED och kontrollera IP, DNS, gateway och målåtkomst.

När alla relevanta LEDs är gröna, är den tekniska tunneln upprättad. Därefter börjar den egentliga nätverkskontrollen: Zon, DHCP, brandväggsregler, återrouting, DNS och vid behov VLAN.

Manuell provisioning med USB-minne

Normalt provisioneras en SD-RED via Sophos RED Provisioning Service. Manuell provisioning med USB-minne är användbart när enheten står i ett privat eller starkt begränsat nät, behöver statisk WAN-konfiguration eller när den automatiska provisioningvägen inte är tillförlitlig.

Brandväggens tidskälla och tidsförsörjningen till RED är inte samma sak: Den manuella RED-guiden för SFOS 22 och 23 beskriver valet Use custom NTP server under Administration > Time, brandväggens egen IP i Search/Add samt Add och Apply som konfiguration av en NTP-server för RED. Dokumentationen för tidsinställning beskriver däremot detta fält som en överordnad tidskälla för brandväggens klocka. Rollerna stämmer därför inte entydigt överens; denna procedur är varken ett ovillkorligt krav eller ett bevis på att brandväggen tillhandahåller NTP för RED. Utan en bekräftad tidssynkroniseringsväg som stöds för den installerade versionen ska den fungerande NTP-konfigurationen lämnas oförändrad. Planera först varje bekräftad ändring mot det dokumenterade utgångsläget: ett byte av NTP-servrar återansluter alla IPsec-anslutningar. Om produktionsanslutningar berörs, säkerställ ett underhållsfönster och lokal eller alternativ administrationsåtkomst.

Flödet är mer exakt än att bara kopiera en provisioningfil till USB:

1. Klargör före manuell provisioning vilken tidssynkroniseringsväg som stöds för den installerade versionen och dokumentera de fungerande NTP-inställningarna samt brandväggens tid och synkroniseringsstatus. Ändra inte den globala tidskällan till brandväggens egen IP enbart på grund av denna RED-konfiguration; begränsningen och NTP/HTTPS-kontrollen anges nedan.
2. Under Network > Zones skapas en egen zon av typen LAN eller DMZ för RED-platser. En separat zon förhindrar att allmänna LAN-regler oavsiktligt gäller för fjärrplatsen. Om zonen VPN används i stället besvarar brandväggen inte själv DNS-frågor från RED-klienterna; DHCP måste då dela ut en annan åtkomlig DNS-server.
3. Under System services > RED aktiveras RED Provisioning Service.
4. Under Network > Interfaces > Add interface > Add RED skapas RED-gränssnittet.
5. Vid Device deployment väljs Manually via USB stick.
6. RED ID, Unlock Code, uplink, RED network settings, zon, DHCP och VLAN anges så att de passar platsen.
7. Öppna Menu för RED-gränssnittet under Network > Interfaces och ladda ned den provisioneringsfil som hör till detta gränssnitt och som genererats efter Save.
8. Filen kopieras till rotkatalogen på USB-minnet.
9. RED stängs av, USB-minnet sätts i och RED startas igen.
10. Efter start kontrolleras gränssnitt, LED, klient-IP, DNS, firewall-regel och åtkomst till mål.

Efter en bekräftad tidsändring, uppdatera WebAdmin och kontrollera brandväggens klocka under Administration > Time, synkroniseringsstatus och IPsec-anslutningarna. Kontrollera även RED-enhetens tidssynkroniseringsväg, TLS-handskakning och tunneletablering. Om tidssynkroniseringen misslyckas eller en regression uppstår, återställ de tidigare fungerande tidskällorna och inställningarna under Administration > Time och upprepa samma kontroller; även detta återbyte kan återetablera IPsec-anslutningar.

Om RED:s WAN-sida använder DHCP måste en DHCP-server faktiskt svara på fjärrplatsen. Om RED inte får någon adress kan den hamna i en omstartsloop. Vid statisk WAN-konfiguration måste IP-adress, gateway, DNS och NTP kontrolleras extra noggrant.

Även en offline-provisionerad RED behöver en giltig tid inom certifikatets giltighetsperiod för TLS-handskakningen. För direkt tidssynkronisering måste den kunna namnuppslå 0.sophos.pool.ntp.org till 3.sophos.pool.ntp.org och nå dem via UDP 123. Om detta misslyckas försöker den synkronisera tiden med brandväggen via HTTPS på TCP 4444. Om HTTPS-administrationstjänsten inte är tillåten för WAN under Administration > Device access kan denna fallback misslyckas utan ett riktat undantag. Aktivera inte HTTPS generellt för WAN-zonen för detta ändamål: undantaget tillåter även HTTPS-administrationstjänsten och måste vara strikt begränsat.

Dokumentera de befintliga Device Access- och ACL-inställningarna före en ändring och kontrollera om det redan finns ett lämpligt undantag. Använd Diagnostics > Packet capture för att fastställa RED-anslutningens källadress som faktiskt observeras på brandväggen. Bakom en NAT-router är detta normalt filialens offentliga NAT-utgångsadress, inte RED-enhetens privata WAN-adress. Använd endast en tydligt känd och så stabil som möjligt IP-värd; vid en delad NAT-adress gäller tillåtelsen även andra enheter bakom denna adress. Ersätt inte en växlande eller okänd källa med en Any-tillåtelse.

1. Öppna Administration > Device access > Local service ACL exception rule > Add och ange ett unikt namn.
2. Ställ in Source zone på WAN. Välj under Source network or host IP-värden för den faktiskt observerade källadressen; skapa vid behov en lämplig IP-värd via Add.
3. Ställ in Destination host på brandväggens avsedda WAN-port, Services på HTTPS och Action på Accept. Spara med Save.
4. Kontrollera den sparade källbegränsningen och destinationsvärden. Testa därefter RED-tidssynkronisering, TLS-handskakning och tunneletablering och kontrollera att inga ytterligare WAN-källor har tillåtits för HTTPS.

Om ett nyskapat undantag endast behövs tillfälligt, ta bort det efter testet eller efter att den direkta NTP-vägen har återställts. Ta också bort det om det saknar effekt eller medför oönskad åtkomst; om ett befintligt undantag ändras, återställ dess dokumenterade utgångsläge. Kontrollera därefter källbegränsningen, HTTPS-nåbarheten och RED-tunneln igen. Dokumentera ett permanent nödvändigt undantag tillsammans med NAT-källadressen och granska det regelbundet.

Status, uppdateringar och migrering

Förstå LED-status

Status-LEDs är ofta den snabbaste ingången vid RED-felsökning, eftersom de visar vid vilken punkt startprocessen fastnar.

Legend:

• ⚫ av
• 🟢 lyser grönt
• 🟢 blinkar grönt
• 🔴 lyser rött
• 🔴 blinkar rött

Beroende på synvinkel, foto eller omgivande ljus kan en LED verka gulaktig eller orange. För diagnosen är det viktigast vilken LED som lyser eller blinkar och om den är grön eller röd.

Normal startprocess

Om alla fyra LEDs lyser grönt men ingen trafik fungerar, ligger problemet oftast inte längre vid tunneluppbyggnaden. Då är brandväggsregler, DHCP, VLAN, DNS, NAT eller routing mer sannolika.

Felkoder

3G/4G-failover

Vid SD-RED-modeller med 3G/4G-failover eller motsvarande modul kan ytterligare mönster uppstå.

Kontrollera firmware-uppdateringar

Om LED-lamporna blinkar tillsammans kan RED-enheten vara i färd med att installera firmware. Under denna fas bör enheten inte stängas av eller kopplas bort från internet. En uppdatering kan ta några minuter. Tolkningen måste stämma med det specifika LED-mönstret och modellen; enbart samtidig blinkning är inte en entydig firmwarediagnos, vilket även failover-mönstren visar.

På Sophos Firewall bör man dessutom kontrollera:

Backup & firmware > Pattern updates

Där måste RED Firmware Pattern vara aktuell. Enligt Sophos tar hämtning och installation fem till tio minuter. Om en RED fastnar i en loop eller inte startar korrekt efter en brandväggsuppdatering, bör man kontrollera om RED Firmware Pattern är föråldrat. Hur status, automatisk hämtning och medveten installation samverkar förklaras i Konfigurera och kontrollera mönsteruppdateringar i Sophos Firewall.

Ett relaterat driftsönskemål beskrivs i Sophos Firewall Feature Request 2024: Vid RED- och Access-Point-firmwareuppdateringar saknas ofta direkt synliga release notes i backend. För produktiva miljöer bör man därför planera uppdateringar medvetet och inte installera dem okoordinerat under kritiska driftstider.

Kontrollera RED-gränssnitt, zon och regler

Efter en lyckad tunneluppbyggnad behöver RED en korrekt brandväggskonfiguration.

Typiska kontrollpunkter:

• RED-gränssnitt är aktivt under Network > Interfaces.
• Gränssnittet ligger i rätt zon.
• DHCP-server eller DHCP-relä är korrekt inställd.
• Klienter får IP-adress, gateway och DNS.
• Brandväggsregler tillåter endast de nödvändiga målen.
• Återrouting till RED-nätet fungerar.
• NAT används endast om det är medvetet planerat.
• VLAN-konfiguration passar till RED-läge och switch-port.

För ett första funktionstest räcker en strikt begränsad regel under Rules and policies > Firewall rules: ange den egna zonen RED-Branch som Source zone, RED-klientnätet under Source networks and devices och endast det nödvändiga interna testnätet som mål. Internetåtkomst kräver en separat regel med WAN-zonen som mål och den planerade NAT-hanteringen. Begränsa därefter mål och tjänster till produktionsbehovet. På så sätt testas den avsedda vägen utan att fjärrplatsen får åtkomst till alla interna nät.

För regelgrunder passar Förstå och konfigurera Sophos Firewall-regler korrekt. Om tunneln är upprättad men trafik inte flödar, bör man kombinera Log Viewer och Packet Capture.

Den valfria MAC filtering type kan tillämpa en enhetsberoende begränsad allow- eller blocklista i RED-nätet, men ersätter ingen brandväggsregel. Remote IP assignment är inte heller ett standardvärde: alternativet tilldelar via DHCP eller statiskt en adress till bryggan med RED-tunneln på WAN-sidan och undersöks bara när enheter bakom RED inte svarar på ARP-förfrågningar. Inget av alternativen ska aktiveras som en generell lösning för prestanda eller anslutning.

Uppgraderings- och migrationsfällor

Förväxla inte Site-to-Site RED med SD-RED

En RED-tunnel mellan brandväggar är fortfarande en separat design som stöds i SFOS 22. Den använder inget av de fyra SD-RED-driftlägena och definieras inte med DHCP eller LAN-portarna på en SD-RED. Vid en uppgradering inventeras båda RED-typerna och verifieras sedan med respektive funktionstest.

För större uppgraderingsplanering passar Planera Sophos Firewall Firmware Update korrekt. Det fullständiga flödet mellan brandväggar finns i Konfigurera Site-to-Site RED mellan två Sophos Firewall.

Ta bort legacy Firewall RED och äldre RED-enheter före SFOS 22

SFOS 22.0 och senare stöder inte längre Firewall RED Server Legacy eller Firewall RED Client Legacy. Så länge en sådan UTM-till-SFOS-konfiguration finns blockeras uppgradering, återställning och konfigurationsimport till SFOS 22. Detta gäller inte de aktuella typerna Firewall RED server och Firewall RED client. Före uppgraderingen ersätts alla beroenden till legacy-gränssnitten, gränssnitten tas bort och därefter skapas en ny konfigurationsbackup.

RED 15, RED 15w och RED 50 har också nått end-of-life. Deras tunnlar ansluter inte längre från och med SFOS 20.0 MR1. Efter en uppgradering eller återställning till SFOS 22 finns den gamla konfigurationen kvar synlig, men tillämpas inte och kan bara tas bort. Den kan inte importeras. Dessa platser måste migreras till SD-RED 20 eller SD-RED 60 före uppgraderingen och testas med den faktiska datavägen.

Korrigerad /32-mask för RED system hosts

Sophos korrigerade subnätmasken för automatiskt skapade RED system host objects till /32 i SFOS 21.0 MR2 och 21.5 MR1. Om sådana objekt tidigare användes i regler eller andra konfigurationer för flera värdadresser kan trafiken matcha annorlunda efter uppdateringen.

Kontrollera beroendena under Hosts and services > IP host redan före uppgraderingen: Öppna Usage för varje RED-systemvärd och ersätt systemvärden med lämplig IP- eller Network-värd i de angivna brandväggsreglerna, rutterna och övriga konfigurationerna. Exempel: För RED-adressen 192.168.1.1/24 var systemvärden tidigare 192.168.1.1/24; nu är den 192.168.1.1/32. En regel eller rutt för hela nätverket måste därför använda en uttrycklig Network-värd; systemvärden omfattar nu endast den konfigurerade IP-adressen för gränssnittet. Testa regelmatchningarna och datavägen igen efter uppgraderingen.

Efter en uppgradering bör man därför kontrollera:

• Används RED system hosts i brandväggsregler?
• Förväntar en regel av misstag ett nätverk istället för en enskild värd?
• Behöver IP Host eller Network Host-objekt ersättas?
• Stämmer regelmatchningar fortfarande i Log Viewer?

RED och HA-failover

I HA-miljöer bör RED-platser testas medvetet efter en failover. Sophos påpekar att RED-tunnlar efter en HA-failover inte alltid omedelbart återansluter till auxiliary-enheten. Tiden beror bland annat på antal gränssnitt och konfiguration.

För kritiska platser bör man inte bara kontrollera firewallens HA-status, utan även:

• RED-gränssnittets status efter failover
• klientåtkomst bakom RED
• relevanta firewall-regelträffar
• DNS och DHCP bakom RED
• monitoring-larm vid längre tunnelavbrott

Kontrollera RED-genomströmning och prestanda

Sophos anger en maximal tunnelgenomströmning på 250 Mbit/s för SD-RED 20 och 850 Mbit/s för SD-RED 60. Det är plattformens maxvärden, inte någon garanti för en enskild SMB-överföring, ett hastighetstest i webbläsaren eller en enda TCP-ström. Även endpoints, lagring, TCP-fönster, faktisk latens mellan platserna, paketförlust, operatörens väg, brandväggens belastning och säkerhetsprofiler påverkar resultatet.

En pingtid på exempelvis 8 ms till en offentlig hastighetstestserver beskriver inte nödvändigtvis latensen mellan de två RED-platserna. Ett hastighetstest på varje internetanslutning testar inte heller den krypterade end-to-end-vägen genom RED-tunneln. För den frågan behövs en testserver i ett LAN och en testklient i LAN:et på den andra platsen.

Testa RED-tunneln med iPerf3 i båda riktningarna

Före tunneltestet bör en lokal baseline skapas med samma kabelanslutna endpoints. Kör sedan iPerf3 genom RED-tunneln, först med en TCP-ström, därefter i omvänd riktning och till sist med fyra parallella strömmar:

iperf3 -c 10.10.10.50 -t 30
iperf3 -c 10.10.10.50 -t 30 -R
iperf3 -c 10.10.10.50 -t 30 -P 4

10.10.10.50 är endast en exempeladress och måste ersättas med IP-adressen till iPerf3-servern i det fjärranslutna LAN:et. Testet skapar avsiktligt belastning och ska genomföras i ett lämpligt underhållsfönster. Testa Sophos Firewall-prestanda korrekt med iPerf3 beskriver installation, den tillfälliga brandväggsregeln, UDP-tester och fullständig analys.

De tre resultaten besvarar olika frågor:

• Om den lokala baselinen redan är långsam ska endpoints, nätverkskort, drivrutiner, kablar, switchar och lagring kontrolleras först.
• Om en ström är betydligt långsammare än -P 4 är latens, TCP-fönstret eller det enskilda applikationsflödet mer sannolikt begränsningen. Det bevisar ännu ingen RED-gräns.
• Om en och fyra strömmar stannar vid samma gräns i båda riktningarna ska fysiska länkar, operatörsvägen, paketförlust, RED-konfiguration och brandväggsbelastning undersökas.
• Om endast en riktning är långsam ska motsvarande uppladdningshastigheter, gränssnittsräknare, fel, drops och returvägen jämföras.

Ett typiskt praktiskt mönster kan vara cirka 400 Mbit/s med en ström och mellan 700 Mbit/s och 800 Mbit/s med -P 4. Det tyder på att vägen kan bära en betydligt högre sammanlagd kapacitet, även om en enskild TCP- eller SMB-ström inte utnyttjar den fullt ut. Det garanterar inte att varje applikation når samma flerströmsresultat.

Under varje körning ska faktisk round-trip time och paketförlust mellan platserna, iPerf-retransmits, Firewall Rule ID, säkerhetsprofiler, brandväggens CPU och räknarna på berörda portar dokumenteras. WAN- och LAN-länkarna måste faktiskt arbeta med 1 Gbit/s, Full Duplex och utan ökande fel- eller droppräknare. Hastighet och duplex bör lämnas på auto-negotiation i båda ändarna i stället för att bara ena sidan tvingas till gigabit.

IPS eller andra säkerhetsprofiler ska inte stängas av generellt. För ett A/B-test används som mest en snäv tillfällig regel för den konkreta testkällan, testdestinationen och iPerf3-tjänsten, och den tas bort omedelbart efteråt. Om resultatet inte ändras utan IPS är det mindre sannolikt att IPS orsakar problemet på just denna testväg.

Inaktivera 802.3az eller EEE på riktigt

För optimal prestanda rekommenderar Sophos att 802.3az stängs av på switchar som är anslutna till en SD-RED 20 eller SD-RED 60. Det handlar om Energy Efficient Ethernet, förkortat EEE. Vid låg länkbelastning försätter EEE delar av Ethernet-PHY i tillståndet Lower Power Idle och sparar därmed energi. Det är inte samma sak som PoE eller 802.3x Flow Control.

Inställningen finns inte i Sophos Firewall WebAdmin eller CLI och inte heller på någon dokumenterad SD-RED-sida. Den ändras på den direkt anslutna switchporten. Detta gäller de LAN-anslutningar som används av RED och, om en hanterbar switch eller router är inblandad, även den fysiska WAN-länken. På utrustning från andra leverantörer kan alternativet heta EEE, Energy Efficient Ethernet, Green Ethernet, 802.3az eller Power Saving. Det finns ingen universell CLI.

På en Sophos Switch används sidan Port settings:

1. Välj porten som är direkt ansluten till SD-RED.
2. Öppna Edit.
3. Ställ EEE status på Off.
4. Spara med Apply.
5. Kontrollera länkstatus, förhandlad hastighet, duplex och felräknare och upprepa samma iPerf3-test.

På en aktuell Sophos Switch kan statusen visas read-only i CLI:

show eee

För exempelporten 0/1 inaktiveras EEE så här:

configure terminal
interface gigabitethernet 0/1
no eee
exit
exit
save
show eee

0/1 måste ersättas med porten som faktiskt är ansluten till RED. no eee ändrar portkonfigurationen. Om switchen endast kan nås via denna RED-väg krävs ett underhållsfönster och lokal eller alternativ administrationsåtkomst. Beroende på switch och firmware kan ändringen utlösa en ny länkförhandling.

För att återställa inställningen på en Sophos Switch används eee i stället för no eee i samma Interface Configuration Mode:

configure terminal
interface gigabitethernet 0/1
eee
exit
exit
save
show eee

Att stänga av EEE stänger varken av Ethernet eller gigabit. Nackdelen är att PHY inte längre sparar lika mycket energi under inaktiva perioder, så porten förbrukar något mer ström och kan generera mer värme. Det finns ingen garanti för en viss ökning av genomströmningen. Det reproducerbara testet före och efter är avgörande. På en ohanterad switch utan EEE-alternativ kan inställningen inte ändras på ett tillförlitligt sätt. För testet måste enheten kringgås eller tillfälligt ersättas med en hanterbar switch.

Ändra Tunnel compression och MTU endast kontrollerat

RED-gränssnittet redigeras under Network > Interfaces. Där finns Tunnel compression och MTU. Sophos beskriver Tunnel compression som ett sätt att komprimera RED-trafik och öka genomströmningen, särskilt på långsamma anslutningar. Data som redan är komprimerade eller krypterade kan knappast minskas ytterligare, medan komprimeringen medför extra bearbetning. Därför passar inte en enda inställning alla platser.

För ett A/B-test dokumenteras först utgångsläget och mätvärdena. Därefter ändras endast Tunnel compression, konfigurationen sparas och exakt samma iPerf3-serie upprepas. Återställ sedan utgångsläget eller dokumentera medvetet den variant som bevisligen gav bättre resultat. När konfigurationen sparas kan RED-tunneln avbrytas kort, så ett underhållsfönster och alternativ åtkomst är lämpliga.

MTU är ingen allmän hastighetsregulator. Den undersöks endast när små paket fungerar men större överföringar stannar, fragmentering syns eller iPerf3 visar många retransmits. Kontrollera MTU och MSS på Sophos Firewall vid VPN-problem beskriver det säkra DF-testet, paketstorlekarna och återställningen. Utan ett reproducerbart MTU-fynd behålls det dokumenterade utgångsvärdet.

Felsökning

RED-gränssnittet kan inte skapas eller redigeras

Om redan skapandet eller sparandet av ett RED-gränssnitt misslyckas ska du först kontrollera administratörsbehörigheterna, motstridiga konfigurationer, RED-ID och Unlock Code. Brandväggen själv måste nå Provisioning Server; ett test enbart i RED-enhetens WAN-nätverk räcker inte för att avgöra detta. Upprättandet av anslutningen kan kontrolleras i 5. Device Management > 3. Advanced Shell på brandväggen:

telnet red.astaro.com 3400

En lyckad anslutning bekräftar endast DNS-uppslagning och TCP 3400 från denna brandvägg. Den bekräftar varken registreringen eller Unlock Code. Om anslutningen misslyckas ska du kontrollera brandväggens utgående väg; om testet lyckas ska du fortsätta undersöka behörigheterna och den konkreta konfigurationen. Ta inte bort ett befintligt gränssnitt förhastat.

RED-IP kan inte ändras under SFOS 22.0 MR2

Under SFOS 22.0 MR2 Build 546 kan meddelandet Failed to update RED interface visas när IP-adressen för ett befintligt RED-gränssnitt ändras. Det förrädiska är att WebAdmin därefter redan kan visa den nya IP-adressen, trots att brandväggen internt fortfarande använder den gamla adressen. Den synliga IP-adressen är därför inte i sig ett bevis på att ändringen lyckades.

Den workaround som Sophos dokumenterar ändrar dessutom filialnamnet och sparar gränssnittet igen:

1. Dokumentera aktuell RED-IP, nätmask, Branch Name och ett eventuellt befintligt RED-DHCP-intervall.
2. Öppna det berörda RED-gränssnittet under Network > Interfaces och ange önskad IP-adress.
3. Om Failed to update RED interface visas, öppna gränssnittet igen.
4. Ändra faktiskt Branch Name, exempelvis från Branch-Zurich till Branch-Zurich-01, och spara igen med Save.
5. Kontrollera i 5. Device Management > 3. Advanced Shell med kommandot ifconfig, som inte gör några ändringar, om den nya adressen är aktiv på RED-gränssnittet:

ifconfig

Gränssnittsnamnet beror på konfigurationen och kan identifieras under Network > Interfaces. En omstart, tjänsteomstart eller borttagning av RED-gränssnittet ingår inte i denna workaround.

Om den nya RED-IP-adressen ligger i ett annat nät än det tidigare RED-DHCP-intervallet inaktiverar SFOS RED-DHCP-servern. Det är normalt produktbeteende och oberoende av felmeddelandet. Under Network > DHCP måste man då anpassa den befintliga servern till det nya nätet eller skapa en ny DHCP-server. Lease-intervall, statiska MAC-tilldelningar, gateway och DNS måste passa den nya adresseringen.

Förnya slutligen DHCP-leasen på en klient bakom RED och kontrollera IP-adress, gateway, DNS, tunnelstatus och den avsedda åtkomsten. I Log Viewer ska trafiken åter träffa den förväntade brandväggsregeln. Om backend-IP-adressen fortfarande är den gamla trots att gränssnittet sparats igen, finns det för närvarande ingen publicerad produktionskorrigering för NC-184971. Beroende regler eller gränssnitt bör inte tas bort på måfå; säkerhetskopiera i stället konfigurationen och kontakta Sophos Support.

RED får ingen IP-adress

Om RED fastnar vid routersteget eller felkoden pekar på DHCP eller gateway, ligger orsaken oftast på den avlägsna platsen.

Kontrollera:

• Ger leverantörsroutern ut en IP-adress via DHCP?
• Är nätverkskabeln korrekt ansluten till WAN-porten?
• Är standardgateway åtkomlig?
• Har en statisk IP-adress angetts fullständigt?
• Stämmer IP-adress, subnätmask, gateway och DNS?
• Blockerar en mellanliggande enhet trafiken?

Om DHCP inte fungerar på den avlägsna platsen kan RED hamna i en omstartsloop.

RED når inte internet

Om router eller gateway är åtkomlig men internet-LED inte blir permanent grön, ligger problemet oftast bakom den lokala routern.

Kontrollera:

• Fungerar internetanslutningen med en vanlig klient?
• Fungerar DNS?
• Är NTP åtkomlig?
• Blockeras TCP 3400, UDP 3410 eller NTP 123?
• Finns det en proxy eller brandvägg mellan RED och internet?
• Är leverantörsanslutningen tillräckligt stabil?
• Är provisioning-tjänsten åtkomlig via HTTPS på TCP 443?

För RED-provisionering måste RED-enheten nå Sophos Provisioning Service. Sophos dokumenterar *.astaro.com via TCP 3400 och UDP 3410; övriga tillverkarmål och valideringsgränser finns i Kontrollera utgående tjänster och portar för Sophos Firewall.

En klient i samma nät som RED-enhetens WAN-port kan använda telnet red.astaro.com 3400 för att testa DNS-uppslagning och etablering av en TCP-anslutning. En lyckad anslutning bekräftar endast att TCP 3400 är åtkomlig; den säger inget om UDP 3410, provisioning, autentisering eller RED-tunneln.

Om TCP-anslutningen lyckas men registreringen fortfarande misslyckas anger Sophos även hög nätverksbelastning som en möjlig orsak. Efter kontroll av internetåtkomst, DNS och utgående HTTPS på TCP 443 kan registreringen provas igen senare. Ett lyckat TCP-test bevisar varken nätverksbelastning eller en lyckad registrering; fortsätt undersöka övriga orsaker om felen kvarstår.

RED når inte Sophos Firewall

Om internet är åtkomligt men tunneln inte byggs upp, kontrollerar man brandväggssidan.

Kontrollera:

• Är RED Service aktiverad på Sophos Firewall?
• Är RED korrekt skapad?
• Stämmer RED-ID och Unlock Code?
• Är den offentliga IP:n eller FQDN för brandväggen åtkomlig?
• Är Administration > Device access för RED tillåten i rätt WAN-zon?
• Tillåter en Local Service ACL åtkomst från den avlägsna platsen?
• Kommer TCP 3400 och UDP 3410 fram till brandväggen?
• Är RED-enhetens tid korrekt för TLS-handshake vid manuell provisioning?
• Kan en offline-RED nå NTP eller det planerade Local Service ACL-undantaget?

I Advanced Shell kan man kontrollera om RED-trafik kommer fram:

tcpdump -ni any port 3400 or port 3410

Om inget kommer fram ligger problemet oftast före brandväggen: leverantörsrouter, NAT, brandvägg uppströms, felaktig offentlig IP, FQDN eller portblockering.

RED startar om hela tiden

En omstartsloop kan ha flera orsaker:

• instabil strömförsörjning
• defekt nätadapter
• ingen IP-adress via DHCP
• felaktig statisk IP-konfiguration
• blockerade portar
• föråldrat RED Firmware Pattern
• felaktig Unlock Code
• skadad eller felaktig RED-konfiguration

Kontrollera först strömförsörjning, kablar och DHCP. Kontrollera därefter RED Firmware Pattern, portåtkomst och konfiguration. Överväg en Factory Reset först om de tidigare kontrollerna inte har identifierat orsaken. Spara dessförinnan RED-ID, Unlock Code och gränssnittskonfiguration. Om uppgifterna saknas kan en ny auktorisering kräva Sophos Support.

Tunnel är grön, men ingen trafik flödar

Detta fall är särskilt vanligt. RED är ansluten, men klienter når inga interna system eller inget internet.

Möjliga orsaker:

• Brandväggsregel saknas eller ligger för långt ner.
• RED-gränssnitt ligger i fel zon.
• DHCP distribuerar fel gateway eller fel DNS-servrar.
• Återrouting till RED-nätet saknas.
• NAT översätter trafik oväntat.
• VLAN-tagging passar inte.
• Säkerhetsfunktion blockerar trafiken.

Kontrollordning:

1. Kontrollera klient-IP, gateway och DNS.
2. Filtrera Log Viewer på käll-IP för RED-klienten.
3. Kontrollera brandväggsregelmatchning.
4. Utför Packet Capture på RED-gränssnitt och målgränssnitt.
5. Kontrollera återvägen från målsystemet eller mål-nätverket.
6. Kontrollera NAT och routing.

Vid oklara regelmatchningar hjälper Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture.

Om avbrottet inträffar direkt efter en återställning med ny provisioning är även NC-181808 relevant. SFOS 22.0 MR3 Build 576 från den 16 oktober 2026 åtgärdar enligt versionsinformationen en trafikblockering orsakad av kvarvarande RED_DEVICE_DROP-poster. Detta förklarar inte varje grön tunnel utan nyttotrafik. Spara tidpunkten för återställning och provisioning, SFOS-builden samt de RED- och paketloggar som hör till testet och stäm av med Sophos Support vid en motsvarande misstanke. Ta inte bort interna poster på egen hand och återställ inte upprepade gånger; testa samma väg i båda riktningarna igen efter en kontrollerad korrigering.

Gröna lysdioder utesluter inte att UDP-datavägen är blockerad. Kontrollera i detta fall specifikt tunneltrafiken i 5. Device Management > 3. Advanced Shell:

tcpdump -ni any port 3410

Använd även Diagnostics > Packet capture under ett kontrollerat klienttest och fastställ om leverantören eller en uppströms enhet blockerar UDP 3410. Ett synligt paket i en riktning bekräftar ännu inte en fungerande väg i båda riktningarna; enbart saknade paket identifierar inte var blockeringen sker.

VLAN-trafik fungerar inte

Vid SD-RED 60 är VLAN-scenarier möjliga, men portläge, VLAN-ID och RED-läge måste passa ihop.

Sophos felsökningshjälp för SFOS 22 och 23 begränsar uttryckligen VLAN-trafik till standard/unified. Dessutom måste VLAN även skapas på RED-enheten och RED-enhetens LAN-portlägen ställas in på lämpligt sätt. Kontrollera därför inte VLAN-tilldelningen enbart på brandväggen eller switchen. Dra inte slutsatser om VLAN-möjligheterna i andra driftlägen utifrån ett lyckat untagged test; kontrollera det konkreta driftläget och portutformningen med hjälp av RED-driftlägena.

Kontrollera:

• VLAN-ID stämmer på brandvägg, RED och switch.
• RED-port är korrekt konfigurerad som Access, Hybrid eller Tagged Trunk.
• Switch-port på den avlägsna platsen är korrekt taggad eller otaggad.
• DHCP och DNS är planerade per VLAN.
• Brandväggsregler finns för respektive VLAN-nät.
• Det valda RED-läget stöder det önskade VLAN-scenariot.

För felsökning är ett enkelt otaggat testnätverk användbart. Om detta fungerar ligger orsaken oftast vid VLAN-ID, tagging, portläge eller switch-konfiguration.

RED Access Points förblir inaktiva

Om RED Access Points eller Wi-Fi-funktioner i VLAN-scenarier förblir inaktiva kan DHCP Option 234 vara relevant. Detta gäller särskilt fall där RED- eller Access-Point-kommunikation sker över VLAN-gränssnitt. Sophos anger SD-RED 20 och SD-RED 60 för detta accesspunktsscenario.

Ställ endast in alternativet när scenariot är relevant och IP-adressen till brandväggsgränssnittet som enheterna ska nå är känd. Välja rätt driftläge för Sophos RED förklarar hela sambandet mellan Wi-Fi-zon, VLAN och DHCP Option 234. Option 234 är inte den första kontrollen vid allmänna RED-anslutningsproblem.

För detta specifika VLAN-fel beskriver Sophos även en fördröjd återhämtning: Efter 30 återförsök kan RED få en LAN-IP från DHCP-servern och åter visas som Active. Detta bevisar inte att den önskade VLAN-vägen fungerar. Vänta därför inte bara på Active, utan kontrollera IP-adressen på VLAN-gränssnittet och det sparade alternativet 234.

Åtgärd i SFOS 23: Följande steg gäller RED Access Points som är konfigurerade i ett VLAN, visas som Inactive efter en omstart och saknar DHCP Option 234 i detta VLAN:

1. Öppna Network > DHCP och redigera DHCP-servern som är konfigurerad för RED Access Points VLAN.
2. Sök först efter kod 234 under DHCP options och dokumentera det befintliga värdet eller att alternativet saknas. Skriv inte blint över ett befintligt fungerande alternativ och skapa inte ett andra konkurrerande alternativ. Om ett värde finns, klargör först VLAN- och gränssnittstilldelningen; följande tilläggssteg gäller endast om alternativet saknas.
3. Under DHCP options, ställ Options på Custom och ange 234 i Code.
4. I Value, ange IP-adressen som är konfigurerad för det RED-Access-Point-gränssnitt som är anslutet till detta VLAN. Värdet beror på gränssnittskonfigurationen i den egna miljön; det är inte enhetens eller en klients tilldelade IP-adress och inte heller en godtycklig offentlig brandväggsadress.
5. Spara ändringarna.

Kontrollera sedan den sparade inställningen i DHCP-servern, inklusive koden och gränssnittets IP-adress. RED Access Point bör efter en kort stund få en IP-adress på sitt VLAN-gränssnitt. Kontrollera denna adresstilldelning och därefter RED Access Points status igen. Om den fortfarande är Inactive, kontrollera först att DHCP-servern, VLAN och gränssnittets IP-adress hör ihop.

Åtgärd under SFOS 22: Den versionsspecifika Sophos-guiden använder Device Console för samma VLAN-fel i stället för inmatningen i WebAdmin som beskrivs ovan. Välj 4. Device Console i CLI och granska före varje ändring bindningarna för rätt VLAN-DHCP-server utan att ändra dem:

system dhcp dhcp-options binding show dhcpname <dhcp server name>

Ersätt <dhcp server name> med namnet på DHCP-servern i RED-accesspunktens VLAN. Dokumentera den befintliga bindningen för alternativ 234 inklusive värdet, eller att den saknas. Skriv inte blint över en fungerande bindning och lägg inte till en konkurrerande bindning. Om ett värde finns, klargör först VLAN- och gränssnittstilldelningen. Klargör före en ny bindning även den dokumenterade administrationsproceduren för att ändra eller ta bort DHCP-alternativbindningar för den installerade versionen. Om denna återställningsprocedur är oklar, gör inga ändringar utan kontakta Sophos Support. Lägg till bindningen på ett riktat sätt endast om alternativet saknas:

system dhcp dhcp-options binding add dhcpname <dhcp server name> optionname dhcp_magic_ip(234) value <interface ip address>

Ersätt <dhcp server name> enligt ovan och <interface ip address> med den konfigurerade IP-adressen för RED-accesspunktens gränssnitt som är anslutet till VLAN:et. Använd inte klientens IP-adress. Kör efter ändringen samma skrivskyddade kommando system dhcp dhcp-options binding show dhcpname <dhcp server name> igen och kontrollera den sparade bindningen inklusive värdet. Kontrollera därefter IP-adressen på VLAN-gränssnittet och statusen. Tillämpa inte SFOS 22-CLI-bindningen och SFOS 23-WebAdmin-proceduren parallellt utan kontroll; välj den variant som passar den installerade versionen och verifiera det sparade alternativet.

Återställning för båda varianterna: Om åtgärden förblir verkningslös eller VLAN-adresstilldelningen eller statusen försämras, återställ det dokumenterade utgångsläget. Under SFOS 23, återinför det tidigare värdet i samma DHCP-server under Network > DHCP > DHCP options eller ta endast bort det nytillagda alternativet 234 och spara. Under SFOS 22, använd den tidigare klargjorda administrationsproceduren för DHCP-alternativbindningar som är dokumenterad för den installerade versionen: återställ den registrerade bindningen eller ta endast bort den nyskapade bindningen. Ta inte bort något annat alternativ eller någon DHCP-server; prova inte obekräftad borttagningssyntax. Kontrollera därefter de sparade alternativen eller bindningarna, IP-adressen på VLAN-gränssnittet och RED-accesspunktens status igen.

Offline-provisionering skrivs över

Om en RED först provisionerades online och senare provisioneras offline via USB, kan en gammal online-konfiguration finnas kvar på Sophos Provisioning Server. Om RED inte når brandväggen kan den provisionera online igen och skriva över USB-konfigurationen.

Då måste RED provisioneras offline igen. Dessutom bör den gamla online-konfigurationen tas bort via Sophos Support.

Diagnostik och driftskontroll

Diagnospunkter på Sophos Firewall

För RED-problem är dessa punkter användbara:

• Network > Interfaces för RED-gränssnitt och status
• Administration > Device access för RED-service-tillstånd
• Rules and policies > Firewall rules för trafik från RED-nätet
• Diagnostics > Packet capture för vägkontroll
• Log viewer med RED-, brandväggs- och systemhändelser
• Backup & firmware > Pattern updates för RED Firmware Pattern
• Advanced Shell med tcpdump

En lyckad anslutning kan även bekräftas i enhetens specifika loggar. I /log/red.log visas ett meddelande som New connection from ... with ID <RED ID>. I /log/red-<RED ID>.log följer bland annat connected OK, pushing config och efter en återanslutning is now re-connected. Dessa rader bekräftar anslutningen och konfigurationsöverföringen, men ännu inte fungerande produktionstrafik. Den fullständiga enhetsspecifika loggen kan innehålla provisioning- och konfigurationsdata och måste rensas innan den delas.

För loggfiler och tjänstetilldelning passar Sophos Firewall Troubleshooting: Services och Logs.

Om däremot hela brandväggen startar i Failsafe-läge med Failed to start Red server service är det inte ett vanligt RED-tunnelfel. Failsafe-runbooken förklarar avgränsningen mellan Builds och hur bevis sparas före recovery.

Driftschecklista

Före utrullning:

• RED-ID och Unlock Code dokumenterade.
• Offentlig brandväggsadress eller FQDN kontrollerad.
• TCP 3400, UDP 3410 och NTP 123 kontrollerade.
• RED Service och Device Access planerade på brandväggen.
• Zon, DHCP, routing och brandväggsregler definierade.
• VLAN-läge vid behov testat i förväg.

Efter anslutning:

• LEDs visar lyckad tunneluppbyggnad.
• RED-gränssnitt är aktivt.
• Klient får IP, gateway och DNS.
• Log Viewer visar förväntad brandväggsregel.
• Interna målsystem och internetväg fungerar som planerat.
• Firmware Pattern är aktuellt.

I drift:

• Kontrollera RED-firmwaremönster regelbundet.
• Testa platsanslutningar efter brandväggsuppgraderingar.
• Testa RED-tunnlar mellan brandväggar separat från fysiska SD-RED-platser.
• Kontrollera effekterna av den korrigerade /32-masken på RED system hosts efter en uppgradering till SFOS 21.0 MR2 eller 21.5 MR1.
• Jämför RED-genomströmning med en lokal baseline, en och fyra iPerf3-strömmar samt båda riktningarna.
• Håll 802.3az eller EEE inaktiverat på direkt anslutna switchportar och kontrollera det igen efter switchbyten.
• Ändra Tunnel compression och MTU endast med ett dokumenterat test före och efter.
• Inkludera RED-platser i övervakning, backup och nödfallsplanering.

FAQ