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.

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.

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. Öppna Administration > Time på firewallen, välj Use custom NTP server och lägg till firewallens IP-adress som NTP-server. Vid manuell setup måste RED kunna hämta giltig tid från firewallen via den planerade vägen så att TLS-handshake fungerar.
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. 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.

Även en offline-provisionerad RED behöver giltig tid. För direkt tidssynkronisering måste den kunna slå upp 0.sophos.pool.ntp.org till 3.sophos.pool.ntp.org och nå dem via UDP 123. Om det misslyckas försöker den synkronisera tiden med brandväggen via HTTPS på TCP 4444. Då kan en riktad Local service ACL exception rule krävas. Ange endast den kända RED-IP-adressen som source och brandväggens WAN-port som destination; service är HTTPS och action Accept. Eftersom undantaget exponerar HTTPS-administrationstjänsten måste det begränsas till RED-IP-adressen.

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 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. 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.

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 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.

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.

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.

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.

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