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.

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, förskjutna brandväggar 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 förskjuten brandvägg gö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.

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.

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

1. På firewallen under Administration > Time kontrolleras om firewallen lämpar sig som NTP-server för RED-scenariot. Vid manuell setup måste RED få giltig tid så att TLS-handshake med firewallen fungerar.
2. Under Network > Zones skapas en egen zon för RED-platser eller en befintlig zon som VPN eller WiFi används. LAN-zonen bör undvikas för RED, så att LAN-regler inte oavsiktligt gäller för den fjärranslutna platsen.
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. Den genererade provisioningfilen laddas ner från RED-gränssnittet.
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.

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.

Offline-RED behöver ändå giltig tid. Antingen får RED nå Sophos NTP-servrar, eller så planeras en riktad Local service ACL exception rule så att RED får kommunicera från WAN-zonen till firewallen. Som source används bara den kända RED-IP:n, destination är firewallens WAN-port, service i detta scenario HTTPS, action Accept. Undantaget ersätter inte att öppna RED brett via WAN.

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 LEDs blinkar tillsammans kan RED just nu installera en firmware. Under denna fas bör man inte stänga av enheten eller koppla bort den från internet. En uppdatering kan ta några minuter.

På Sophos Firewall bör man dessutom kontrollera:

Backup & firmware > Pattern updates

Där måste RED Firmware Pattern vara aktuell. Om en RED fastnar i en loop eller inte startar korrekt efter en brandväggsuppdatering, är ett föråldrat RED Firmware Pattern ett vettigt kontrollsteg. 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 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.

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.

RED system hosts efter SFOS 21.5 MR1

Sedan SFOS 21.5 MR1 får RED system host objects den korrekta /32-subnätmasken. Om sådana automatiskt genererade RED-systemobjekt tidigare användes i regler eller andra konfigurationer för mer än en värd-IP, kan trafiken matcha annorlunda efter uppdateringen.

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-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 förskjuten 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?

För RED-provisionering måste RED nå Sophos Provisioning Service. I många miljöer är red.astaro.com på TCP 3400 relevant.

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?

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, förskjuten brandvägg, 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

Först kontrollera strömförsörjning, kablar och DHCP. Därefter kontrollera RED Firmware Pattern, portåtkomst och konfiguration. Om RED skapas om eller återställs måste RED-ID och Unlock Code dokumenteras i förväg.

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.

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.

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.

Denna option bör endast sättas om det specifika scenariot passar och det är klart vilken brandväggsgränssnitts-IP enheterna ska nå. Vid allmänna RED-anslutningsproblem är DHCP Option 234 inte det första steget.

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.

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

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 RED system hosts efter SFOS 21.5 MR1 för /32-effekter.
• 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