Konfigurera Sophos Firewall Site-to-Site IPsec VPN

En Site-to-Site IPsec VPN kopplar ihop två platser, eller en Sophos Firewall med en tredjepartsbrandvägg, via en krypterad tunnel. I praktiken misslyckas en sådan tunnel sällan på grund av en enda inställning i gränssnittet. Vanligare orsaker är otydliga nät, olika IPsec-profiler, saknade brandväggsregler, särskilda NAT-fall eller en returväg som har glömts på ena sidan.

Snabbt arbetsflöde: Välj tunneltyp, stäm av profil och IDs, skapa anslutningen, routa XFRM-interfacet för route-based Any-to-Any, konfigurera brandväggs- och NAT-regler och verifiera tunneln med verklig trafik, loggar och Packet Capture.

Proceduren passar för anslutningar mellan Sophos-brandväggar och anslutningar till tredjepart mellan huvudkontor, filial eller cloud gateway. Microsoft Azure och AWS har ytterligare leverantörsspecifika detaljer: Anslut Sophos Firewall till Azure VPN Gateway och Anslut Sophos Firewall till AWS Site-to-Site VPN. För Remote Access för enskilda användare passar i stället jämförelsen mellan Sophos Connect och SSL VPN. Om en befintlig tunnel redan är grön men ingen trafik går igenom, se Sophos Firewall IPsec VPN Troubleshooting.

Om endast två Sophos Firewalls ska anslutas och filialen ska upprätta tunneln som klient till ett huvudkontor som kan nås på en statisk adress, är SSL Site-to-Site VPN ett enklare alternativ. För tredjepartsutrustning, redundans, dynamisk routing eller växande nät är route-based IPsec fortfarande det mer flexibla valet.

För flera brandväggar som hanteras av Sophos Fusion (tidigare Sophos Central) kan en SD-WAN-anslutningsgrupp automatiskt generera route-based tunnlar, XFRM-gränssnitt, routes och valfria regler. Det ersätter varken topologiplanering eller lokal trafikverifiering.

Välj policy-based eller route-based

Före konfigurationen måste man bestämma om tunneln ska byggas som policy-based eller route-based. Utanför Sophos-gränssnittet kallas route-based också ofta tunnel-based. Båda termerna beskriver en tunnel med ett eget XFRM-interface. Den ibland använda termen “root-based” är däremot inget VPN-läge.

Sophos rekommenderar route-based VPN för nya designer. Any-to-Any är särskilt flexibelt för växande nät eftersom routeändringar inte kopplar ned tunneln. Ändringar av subnät eller Traffic Selectors avbryter däremot befintliga anslutningar. Båda tunneländarna måste använda samma typ: policy-based i ena änden och route-based i den andra stöds inte.

För OSPF eller BGP genom tunneln är route-based Any-to-Any med adresserade XFRM-interface den tydliga lösningen. Före en uppgradering av en äldre policybaserad lösning ska man kontrollera om VPN-nät annonseras via redistribute kernel; SFOS 22: IPsec-rutter och redistribute kernel förklarar versionsändringen och den säkra ramen för migreringen.

Vad en grön tunnel faktiskt bekräftar

En status som Established bekräftar att motparterna har förhandlat IKE och minst en Child SA. Den bekräftar inte att en route väljs, att brandväggsregeln matchar, att NAT är korrekt, att motparten känner till returvägen eller att målhosten svarar. En tunnel kan därför vara grön utan att transportera användbar trafik mellan platserna.

Sophos Firewall använder ESP i tunnelläge. ESP skyddar dataintegriteten, autentiserar nyttodatans ursprung och ger anti-replayskydd mot återuppspelade paket.

Datavägen kan förstås med följande modell:

Policy-based
Källa -> Brandväggsregel -> Local/Remote selector -> Child SA -> Peer -> Returroute och regel -> Mål

Route-based Any-to-Any
Källa -> Route eller SD-WAN Route -> Brandväggsregel -> XFRM -> Child SA -> Peer -> Returroute och regel -> Mål

Detta är en diagnostisk modell, inte en fullständig bild av den interna behandlingsordningen i SFOS. Skillnaden är ändå avgörande vid verifieringen: med policy-based avgör nätparet i IPsec-anslutningen vilken trafik som hör till tunneln. Med route-based Any-to-Any gör routing- eller SD-WAN-beslutet det valet.

Förutsättningar och planeringsdata

Dokumentera minst följande före konfigurationen:

• Lokal ändpunkt: Sophos Firewalls WAN-interface och adressen som motparten använder för att nå detta interface.
• Remote Gateway: publik IP-adress eller DNS hostname för motparten.
• Gateway type: vanligtvis Respond only på huvudkontoret och Initiate the connection i filialen.
• IP version: IPv4, IPv6 eller Dual. Dual är endast tillgängligt för route-based tunnelinterface med Any-to-Any som lokala subnät och fjärrsubnät. Med Dual måste IPv4- och IPv6-brandväggsregler planeras separat.
• Lokala nät: till exempel 172.16.10.0/24 och 172.16.20.0/24.
• Fjärrnät: till exempel 10.20.30.0/24.
• VPN-typ: policy-based eller route-based. Connection type Host-to-host finns också, men är inte fokus för den här platsguiden.
• Listening interface: WAN-interface på den lokala brandväggen. Ett bridge interface kan inte användas.
• IKE-version: helst IKEv2 om motparten stöder det.
• Authentication type: Preshared key, Digital certificate eller RSA key.
• Local ID och Remote ID: särskilt viktiga med FQDN, dynamiska motparter, NAT-T eller wildcard gateway.
• IPsec-profil: Encryption, Authentication, DH Group, PFS och Key life.
• Brandväggsregler: tillåtna Sources, Destinations och Services.
• NAT: ingen NAT eller SNAT/DNAT på grund av överlappande nät eller leverantörskrav.
• Drift: ansvarig, underhållsfönster, testplan, monitoring och fallbackväg.

Genomgående exempel för båda brandväggarna

Följande dokumentationsvärden gör de senare stegen lätta att följa. Ersätt dem helt med egna WAN-adresser, nät och namn:

Skapa först båda LAN-näten som nätverksobjekt under Hosts and services > IP host. På huvudkontoret är 10.10.10.0/24 Local subnet och 10.20.20.0/24 Remote subnet; i filialen byts värdena plats. Detsamma gäller IDs: ena sidans Local ID måste förväntas som Remote ID av motparten. Överföringsnätet 10.255.0.0/30 används bara för route-based Any-to-Any och får inte överlappa något produktions-, VPN- eller managementnät.

För exemplets IDs ställer du in Local ID type = DNS och Remote ID type = DNS på båda brandväggarna. På huvudkontoret anger du Local ID vpn-hq.example.invalid och Remote ID vpn-branch.example.invalid; i filialen anger du exakt det omvända. Dessa värden identifierar motparterna och används inte för DNS-uppslagning av deras gatewayadresser. Om en annan ID-typ används måste även typ och format stämma överens korsvis.

För varje IPv4-nätverksobjekt väljer du Add, IP version = IPv4, Type = Network, nätadressen och subnätsmasken /24 och sparar sedan. Lämpliga namn är HQ_LAN för 10.10.10.0/24 och Branch_LAN för 10.20.20.0/24; båda objekten behövs på båda brandväggarna. Ett hostobjekt används däremot för en enskild test- eller monitoringadress.

Genom att låta filialen vara initiator fördelas återanslutningsförsöken mellan filialerna, vilket också är lämpligt när filialens WAN-IP ändras. Om en initiator ska nå en motpart med dynamisk WAN-IP måste motpartens Gateway address innehålla ett DNS-värdnamn som vid namnuppslagning faktiskt ger motpartens aktuella publika adress. Konfigurera och kontrollera Dynamic DNS på Sophos Firewall beskriver registrering och test av namnuppslagningen. Enbart ett DNS-ID är inte en nåbar gatewayadress. DDNS endast på huvudkontoret gör inte filialens dynamiska adress möjlig att hitta.

⚠️ Site-to-Site VPN bör inte implementeras utan en dokumenterad returväg. Om den lokala brandväggen skickar trafik in i tunneln, men motparten saknar en route tillbaka eller förväntar sig annan NAT, ser tunneln ofta frisk ut trots att applikationer inte fungerar.

Nät, profil, IDs och certifikat

Lokala nät och fjärrnät får inte överlappa oavsiktligt. Vanliga standardnät som 192.168.0.0/24, 192.168.1.0/24 eller återanvända filialnät är särskilt problematiska. Överlappande nät kräver en medveten NAT-design. Att använda samma adressområde på båda sidor och senare översätta det “på något sätt” skapar tunnlar som är svåra att underhålla.

För nya platser lönar det sig därför med en ren IP-adressplan. Om VLANs eller zones ännu inte är tydligt modellerade, se Konfigurera Sophos Firewall zones och interfaces.

Båda sidor måste använda kompatibla parametrar för Phase 1 och Phase 2. Det omfattar kryptering, autentisering, DH group, PFS och lifetime. Vid anslutningar till tredjepartsbrandväggar är det ofta enklast att först dokumentera en gemensam profil och därefter konfigurera båda sidor.

Med IKEv2 kan Sophos använda unika Preshared Keys för varje kombination av Local ID och Remote ID. IKEv1 är mer begränsat eftersom bara en PSK gäller per gatewaykombination. I miljöer med flera tunnlar till samma motpart bör IKEv2 med tydligt definierade IDs användas.

⚠️ Med IKEv1 använder brandväggen PSK från den senast konfigurerade anslutningen för samma kombination av lokal gateway och fjärrgateway. Detta gäller IPsec-konfigurationer för site-to-site och fjärråtkomst. Om en anslutning senare konfigureras för den gatewaykombinationen med en annan PSK kan autentiseringen av befintliga anslutningar misslyckas vid en efterföljande förhandling. Kontrollera alla berörda IKEv1-konfigurationer innan en sådan anslutning läggs till eller en PSK ändras och stäm av PSK med respektive motpart före nästa förhandling.

NAT Traversal är alltid aktivt på Sophos Firewall. Om en sida ligger bakom en router eller provider-NAT blir IDs viktigare, eftersom den publika gatewayadressen inte identifierar motparten entydigt. Local ID på ena sidan måste motsvara Remote ID som förväntas av den andra. DNS-, IP- eller e-post-IDs behöver inte vara publikt upplösbara, men format och värde måste stämma överens korsvis.

Sophos Firewall har ingen separat NAT-T-omkopplare: Enheterna identifierar NAT automatiskt. Utan NAT använder IKE-förhandlingar UDP 500, medan datatrafiken använder ESP via IP protocol 50. När brandväggen identifierar en NAT-enhet kapslar den in efterföljande IKE- och fas 2-förhandlingar samt ESP-paket i UDP 4500.

Om det finns en NAT-enhet på IPsec-sökvägen och motparten är en tredjepartsbrandvägg måste NAT-T vara aktiverat även där. Inställningen kontrolleras mot motpartens dokumentation; Sophos Firewall behöver ingen extra omkopplare.

Motparterna identifierar en NAT-enhet under IKE-utbytet i fas 1 och kommer då överens om att använda NAT-T. ESP är ett lager 3-protokoll utan portinformation från lager 4, medan PAT även kan översätta portar. UDP-inkapsling via port 4500 ger därför NAT-sökvägen ett identifierbart UDP-hölje; motparten tar bort höljet och behandlar det ursprungliga IPsec-paketet.

Om Sophos Firewall själv står bakom en router måste routern använda DNAT eller portvidarebefordran från den publika adressen till brandväggens privata Listening interface. I det genomgående exemplet kan huvudkontorets router ha WAN-adressen 198.51.100.10, medan brandväggens WAN använder 172.31.255.2. Huvudkontoret väljer då sitt privata WAN som Listening interface; filialen ansluter fortfarande till 198.51.100.10, inte till 172.31.255.2. Routern översätter destinationsadressen från sin publika adress till 172.31.255.2. LAN-selectors förblir Local 10.10.10.0/24 och Remote 10.20.20.0/24 på huvudkontoret och exakt omvänt i filialen.

För NAT-T måste UDP 500 och UDP 4500 tillåtas. Anvisningarna för SFOS 22 och SFOS 23 om en brandvägg bakom en router anger dessutom IP protocol 50, inte TCP-/UDP-port 50. När NAT-T har förhandlats ligger ESP inuti UDP 4500; native ESP använder protokoll 50. Routerlistan och NAT-T-förklaringen får därför inte behandlas som identiska paketvägar. Dokumentera routerns funktioner och befintliga vidarebefordringar före ändringen och kontrollera med IKE-loggar och Packet Capture vilken väg som faktiskt används. Ta inte bort en befintlig ESP-tillåtelse utan att först kontrollera den; begränsa ytterligare tillåtelser till de planerade motpartsadresserna. Återställ den dokumenterade routerkonfigurationen om förhandlingen uteblir. Detta är skilt från SNAT/DNAT för överlappande LAN eller översatt nyttotrafik.

Med Digital certificate måste certifikatformat och roller stämma exakt på båda sidor. Sophos stöder inte ECDSA-certifikat för IPsec-anslutningar; RSA-certifikat krävs. Local certificate tillhör den lokala brandväggen, Remote certificate tillhör motparten och Remote CA certificate utgör förtroendegrunden för motpartens certifikat. Använd ingen publik CA som Remote CA certificate: en angripare med ett giltigt certifikat från denna CA skulle annars kunna få obehörig åtkomst. Med ID-typen DER.ASN1 DN (X.509) används respektive certifikats Distinguished Name; som Remote ID anges DN från motpartens certifikat.

RSA key är en separat Authentication type, inte ett val av RSA-certifikat. Brandväggen genererar nyckelparet automatiskt och visar endast den publika nyckeln under Local RSA key. Kopiera den till Remote RSA key hos motparten och klistra in motpartens publika nyckel i den lokala brandväggens Remote RSA key. Båda sidor måste använda samma format, PKCS1 eller DNS. Privata nycklar överförs inte mellan brandväggarna.

Att ändra den lokala CA:n Default på en Sophos Firewall är en ändring av trust anchor, inte en kosmetisk certifikatändring. Peers med en importerad Default.pem och lokalt signerade certifikat måste migreras kontrollerat. Förnya Sophos Firewall Default CA kontrollerat förklarar inventering, underhållsfönster, tester och återställning.

När Digital certificate väljs räcker inte valet i anslutningsformuläret. CA-förtroende, lokala certifikat, motpartscertifikat och Certificate IDs måste förberedas i förväg. Den fullständiga processen beskrivs i Konfigurera IPsec Site-to-Site med certifikat. Om CA:n återkallar certifikat före utgångsdatumet måste även den aktuella återkallningslistan ingå i driftsplanen. Ett separat arbetsflöde beskriver CRL-import, kontroll av nextUpdate och ett kontrollerat negativt test på Sophos Firewall.

Om en tunnel inte kommer upp är NO_PROPOSAL_CHOSEN, ID-fel eller autentiseringsfel typiska indikationer. Avsnittet Testa och felsök tunneln börjar med rätt avgränsning.

Konfigurera policy-based IPsec

Policy-based IPsec är den klassiska varianten för enkla Site-to-Site-anslutningar. Lokala nät och fjärrnät definieras direkt i IPsec-anslutningen.

1. Kontrollera eller skapa IPsec-profil

Menysökväg:

Profiles > IPsec profiles

Kontrollera först om en befintlig profil passar motparten. Om en egen profil behövs bör den få ett tydligt namn, till exempel Branch-Zurich-IKEv2. Namnet ska fortfarande vara begripligt när det finns flera tunnlar och motparter.

Dokumentera minst:

• IKE-version
• Phase 1 Encryption och Authentication
• DH Group
• Phase 2 Encryption och Authentication
• PFS
• Key life

Vid tredjepartsbrandväggar bör motparten bekräfta samma värden skriftligt. En skärmbild räcker ofta inte, eftersom enskilda fält kan heta olika beroende på tillverkare.

Hur Phase 1, Phase 2, PFS, lifetimes, rekeying och DPD samverkar förklaras i Förstå och konfigurera IPsec-profiler säkert i Sophos Firewall. Kontrollera Dead peer detection före aktivering: Sophos anger Hold eller Disconnect för den svarande motparten och Re-initiate för initiatorn. En IPsec-failovergrupp ändrar beteendet och följer inte samma DPD-logik.

2. Lägg till IPsec-anslutningen

Menysökväg:

Site-to-site VPN > IPsec

Skapa en ny IPsec-anslutning och välj Policy-based som Connection type. Ange sedan grunddata:

• Tunnelns namn, till exempel branch-zurich
• IP version, vanligtvis IPv4
• Gateway type, till exempel Respond only på huvudkontoret eller Initiate the connection i filialen
• Listening interface som lokalt WAN-interface
• Motpartens Gateway address som IP-adress eller DNS hostname
• Authentication type: Preshared key, Digital certificate eller RSA key
• Local ID och Remote ID om det behövs
• IPsec profile
• Local subnet
• Remote subnet

I detta policy-based exempel väljs specifika nät på båda sidor. Dokumentationen för SFOS 22 och SFOS 23 är inte enhetligt formulerad när det gäller Any: översikten över policy-based anger att Any inte kan väljas för lokala subnät och fjärrsubnät, medan anvisningen Add an IPsec connection tillåter Any på högst ena sidan. Detta är en oklarhet i dokumentationen och ska inte tolkas som stöd för en policy-based Any-to-Any-konfiguration. Om ett ensidigt Any krävs ska alternativet i den installerade builden, motpartens selectors och avsedd routing kontrolleras i en isolerad testkonfiguration före införandet. Vid oväntad SA eller trafiktilldelning ska den nya anslutningen inaktiveras och de dokumenterade specifika selectors återställas. Med flera specifika lokala nät och fjärrnät skapas en Phase 2 SA per kombination: två lokala nät och två fjärrnät ger fyra SAs. Alla policy-based anslutningar delar ett IPsec-interface; en capture enbart på detta interface identifierar därför inte tunneln.

Med Respond only kan wildcardadressen * vara användbar när flera filialer eller dynamiska motparter ansluter till huvudkontoret. Minst ett Local ID eller Remote ID måste då anges; båda IDs är vanligtvis lämpliga för en entydig tilldelning. Local ID på ena sidan motsvarar Remote ID som förväntas av den andra. Initiate the connection stöder inte en wildcardadress, därför definieras motparten där som en IP-adress eller ett DNS hostname.

Använd en stark, unik Preshared Key och dokumentera den säkert. Att återanvända en gammal standardnyckel på flera platser är en onödig driftsrisk.

Med Authentication type = Preshared key anger du den överenskomna PSK:n och upprepar den i bekräftelsefältet. Ange exakt samma PSK hos motparten och bekräfta den även där; de spegelvända IDs ändrar inte den gemensamma nyckeln. Utbyt PSK:n endast via den avsedda säkra kanalen och ta inte med den i skärmbilder eller offentliga supportärenden.

Skapa därefter anslutningen spegelvänt hos motparten. I exemplet väntar huvudkontoret med Respond only på 203.0.113.20; Local/Remote-näten är 10.10.10.0/24 respektive 10.20.20.0/24. Filialen använder Initiate the connection, Gateway address 198.51.100.10 och byter plats på Local/Remote-nät och IDs. Profil, autentisering och PSK måste vara kompatibla. Aktivera först när båda posterna har sparats och reglerna kontrollerats.

De avancerade inställningarna för User authentication mode gäller bara IKEv1-profiler med XAuth-logik, till exempel mycket gamla client-server-designer. För normala Site-to-Site-anslutningar med IKEv2 ska detta inte tolkas som ett extra autentiseringssteg. Föråldrade idle connection-inställningar bör inte heller ingå i en modern driftsdesign.

3. Aktivera tunneln

Vid sparandet kan Activate on save väljas. I produktionsmiljöer bör det ske i ett definierat underhållsfönster när motparten är nåbar och båda sidor kan kontrollera loggar.

Utan Activate on save aktiveras den sparade anslutningen med dess Status-knapp under Site-to-site VPN > IPsec. Detta ska skiljas från Gateway type = Disable: anslutningen förblir inaktiv tills användaren initierar den. Respond only väntar på förfrågningar; Initiate the connection startar förhandlingen även efter en omstart av VPN-tjänsten eller brandväggen. Efter enbart Disconnect kan en initiator ansluta igen; vid återställning måste därför även anslutningen inaktiveras.

Efter sparandet visar listan två relevanta tillstånd:

• om anslutningen är aktiv
• om tunneln faktiskt är established

En aktiv post är inte automatiskt en etablerad tunnel. Vid flera lokala nät eller fjärrnät kan det dessutom finnas flera Security Associations.

XML-API: skilj konfiguration från styråtgärder

Översätt inte bara GUI-fälten till en XML-förfrågan för att automatisera den här proceduren. API-referensen för SFOS 22 och SFOS 23 visar inställningar under VPNIPSecConnection/Configuration och separata styrgrenar Active, DeActive, Connection och DisConnection, var och en med Name. Enligt exemplets kommentar fungerar dessa fyra grenar först efter att anslutningen har skapats. Konfigurationsexemplet innehåller dessutom Status med Active/Deactive; parameterraden för ActivateOnSave anger y/n. Att spara, aktivera, ange beteendet efter en omstart och faktiskt etablera en tunnel är alltså inte utbytbara inställningar eller bevis för en körbar API-förfrågan.

Den äldre beskrivningen innehåller också motsägelser mellan exemplet och parameterraderna:

• I exemplet följer AliasLocalWANPort efter en kommentar om en alias-WAN-port, men tabellen anger fältet som obligatoriskt ARRAY. Även Name och RemoteHost anges som ARRAY; detta fastställer varken en säker serialisering av flera värden eller hur värdena ska kopplas parvis.
• Exemplet för UserAuthenticationMode visar AsServer/AsClient, medan raden anger EnableAsServer/EnableAsClient. För DisconnectOnIdleInterval ligger standardvärdet 0 utanför det angivna intervallet 120..21600; 600 är bara exempelvärdet. Jämna inte ut skillnaderna utan förklaring och använd inte värdena som IKEv2-standardinställningar.
• Det äldre fältet AllowNATTraversal med Enable/Disable bevisar inte att det finns en aktuell NAT-T-omkopplare. Raden för RemoteHost förbjuder * med RSAKey; detta är en begränsning i den referensen, inte en allmän regel för GUI:ts körningsbeteende som har bekräftats här.

Använd WebAdmin-proceduren ovan så länge API-representationen för den installerade builden är oklar och red ut oklarheterna före automatisering. Den här informationen är ingen fullständig XML-mall; automatisk NAT-T-detektering och vägledningen för IKEv2, RSA och IDs är oförändrade för den beskrivna GUI-proceduren.

Konfigurera route-based IPsec

Route-based IPsec separerar VPN-förhandling från routeval. Med Any-to-Any tillhandahåller SFOS ett eget adresserbart XFRM-interface. Anvisningarna för SFOS 22 och SFOS 23 beskriver ett skapat XFRM-interface även för specifika Traffic Selectors; till skillnad från Any-to-Any får det inte tilldelas en IP-adress eller en manuell route. Före en migrering dokumenteras installerad SFOS-version, interfacetilldelning och den route som faktiskt har skapats.

1. Skapa anslutningen som route-based

Menysökväg:

Site-to-site VPN > IPsec

Välj Route-based (Tunnel interface) för anslutningen. Parametrarna för gateway, autentisering, IDs och IPsec-profil måste fortfarande stämma med motparten. Dessutom måste det vara klart vilket XFRM-interface som skapas och hur det routas.

2. Implementera Any-to-Any eller Traffic Selectors

För Any-to-Any visar Sophos det skapade XFRM-interfacet under det använda fysiska interfacet i:

Network > Interfaces

Ett skapat XFRM-interface förblir alltid tilldelat VPN-zonen. De två varianterna konfigureras på olika sätt.

Any-to-Any med IPv4, IPv6 eller Dual

När både Local subnet och Remote subnet är inställda på Any skapar SFOS automatiskt XFRM-interfacet för den route-based IPsec-anslutningen. Något separat XFRM-interface ska inte läggas till. Expandera i Network > Interfaces det fysiska interface som valts som Listening interface och öppna det skapade XFRM-interfacet. Huvudkontoret får i exemplet 10.255.0.1/30 och filialen 10.255.0.2/30. Med Dual krävs även separata IPv4- och IPv6-regler.

Det redigerbara fältet Name är visningsnamnet. Blanda inte ihop det med de värden som SFOS tilldelar: Hardware är postens namn, IPsec connection är den associerade route-based anslutningen och Network zone är alltid VPN. Konfigurera bara adressfälten för den IP-version som valts i IPsec-anslutningen:

• IPv4/netmask: ange den planerade IPv4-överföringsadressen och välj subnet.
• IPv6/prefix: ange den planerade IPv6-överföringsadressen och prefixet.
• Konfigurera båda adressfamiljerna med Dual. Om anslutningen bara använder IPv4 eller IPv6 tillämpar SFOS inte värden som angetts för den andra versionen.

Behåll standardvärdet för MTU under Advanced settings > Interface settings eller ange det särskilt testade värdet. SFOS beräknar standardvärdet genom att dra av maximal IPsec-overhead från det fysiska interfacets MTU. Aktivera Override MSS och ange ett värde endast om nätet kräver ett annat värde än brandväggens standard; anta inte ett odokumenterat numeriskt standardvärde.

Dokumentera före ändringen aktuellt namn, adresser, MTU, status och värde för Override MSS samt beroende routes eller gateways. Öppna interfacet igen efter att det sparats och kontrollera att tilldelade Hardware, IPsec connection och VPN-zon är oförändrade. Kör sedan Route lookup på båda peers och testa verklig trafik i båda riktningarna, även en stor överföring om MTU eller MSS ändrades. Återställ de dokumenterade fältvärdena och tidigare routes eller gateways vid rollback. Inaktivera en ny anslutning och ta endast bort dess beroende routes och regler; försök inte radera eller skapa om det genererade XFRM-interfacet separat.

Skapa sedan routen till fjärr-LAN på båda sidor via Routing > Static routes > IPv4 unicast route > Add:

• Huvudkontor: Destination 10.20.20.0/24, Interface det lokala XFRM-interfacet.
• Filial: Destination 10.10.10.0/24, Interface det lokala XFRM-interfacet.

Alternativt används en SD-WAN Route eller dynamisk routing via BGP eller OSPF. Bestäm uttryckligen om en annan väg får användas som fallback. Om inte, aktivera Route only through specified gateways och testa tunnelavbrottet separat.

Routes och brandväggsregler avgör vilken trafik som går in i tunneln. En enkel statisk route kan peka direkt på XFRM-interfacet. För flera förbindelser, SLA-kontroller eller vissa failoverdesigner skapas dessutom en Custom Gateway med motpartens XFRM-IP och används i en SD-WAN Route.

För SD-WAN-alternativet väljer du IPv4 och Add under Routing > SD-WAN routes. På huvudkontoret anger du Source networks = HQ_LAN, Destination networks = Branch_LAN och väljer Primary and backup gateways under Link selection settings. Under Primary gateway > Add anger du 10.255.0.2 som Gateway IP och väljer det lokala XFRM-interfacet med 10.255.0.1/30 som Interface. I filialen byter du plats på Source/Destination, använder Gateway IP 10.255.0.1 och det lokala XFRM-interfacet med 10.255.0.2/30. För Health check väljer du under Monitoring condition en intern host hos motparten som faktiskt svarar, till exempel 10.20.20.15 i filialen eller 10.10.10.25 på huvudkontoret. Själva kontrolltrafiken måste vara tillåten och använda den avsedda tunneln. För SLA-baserat vägval väljer du en SD-WAN-profil med tunnelns gateways. Statisk route och SD-WAN Route är alternativ här; skapa inte båda som konkurrerande vägar utan att först kontrollera konsekvenserna. Dokumentera befintlig Route Precedence och regler före ändringen och återställ tidigare route-/gatewayval vid rollback.

Any-to-Any-tunnlar kan styra flera XFRM-gateways direkt via SD-WAN och SLA-kontroller; någon extra VPN-failovergrupp behövs inte. Policy-based tunnlar och route-based tunnlar med Traffic Selectors använder däremot en IPsec-failovergrupp för redundanta anslutningar. Den länkade arbetsgången förklarar ordning, Health Check, Automatic failback och det kontrollerade avbrottstestet. Gruppen inaktiverar DPD för de tilldelade anslutningarna och sätter Key negotiation tries till 3.

Kontrollera fyra punkter efter sparandet:

1. XFRM-interfacet syns under Network > Interfaces och har planerad överförings-IP.
2. Routen till fjärrnätet pekar direkt på XFRM-interfacet eller, vid ett gateway-/SD-WAN-upplägg, på rätt XFRM-gateway.
3. Diagnostics > Tools > Route lookup returnerar för en verklig host i fjärr-LAN avsett XFRM-interface eller avsedd XFRM-gateway. Kör samma test hos motparten.
4. Brandväggsregler tillåter endast planerade riktningar och services.

Traffic Selectors

För specifika subnät beskriver de granskade anvisningarna för SFOS 22 och SFOS 23 ett XFRM-interface per IPsec-konfiguration. Expandera Listening interface med den blå markeringen under Network > Interfaces. Tilldela varken IP-adress eller manuell route till det skapade interfacet: den statiska routen skapas automatiskt när tunneln är established. På huvudkontoret väljer du Local HQ_LAN och Remote Branch_LAN; i filialen väljer du Local Branch_LAN och Remote HQ_LAN. Gateway, profil, autentisering och IDs speglas på samma sätt som för de andra varianterna. Any på endast ena sidan med en specifik selector på den andra stöds inte för route-based. Om det dokumenterade interfacet saknas i den installerade builden ska konfiguration, version och loggar först utredas; försök inte tvinga fram ett ersättnings-XFRM eller en Any-to-Any-adressering.

Den här varianten passar små, tydligt definierade nät; Sophos rekommenderar den framför policy-based, även för kompatibla tredjepartsanslutningar. Använd XFRM-interfacet under Diagnostics > Packet capture för att koppla utgående trafik till rätt anslutning; kontrollera även automatisk route, varje förväntad Child SA, loggar och trafik i båda riktningarna. WAF över route-based IPsec med Traffic Selectors stöds inte; för detta kan en lämplig route-based Any-to-Any-konfiguration användas. Om övergången misslyckas ska den nya anslutningen och endast dess nya regler inaktiveras och den dokumenterade tidigare anslutningen aktiveras igen.

En Any-to-Any-tunnel kan inte ändras direkt till specifika Traffic Selectors. Klona eller skapa anslutningen på nytt och genomför sedan en kontrollerad växling.

3. Beakta XFRM och MTU

Route-based VPN är mer känsliga för missförstånd kring routing, MTU och MSS. Om små tester fungerar men större överföringar fastnar ska IPsec-profilen inte ändras direkt. Kontrollera först MTU, MSS, fragmentering och den verkliga vägen. Rätt procedur beskrivs i Kontrollera Sophos Firewall MTU och MSS vid VPN-problem.

Brandväggsregler, NAT och Device Access

Brandväggsregler och automatiska regler

Efter IPsec-konfigurationen behövs regler för produktiv trafik. Utan passande regler kan tunneln vara grön, men applikationer fungerar inte.

Menysökväg:

Rules and policies > Firewall rules

Typiska regler:

• Lokalt nät till fjärrnät: till exempel LAN till VPN.
• Fjärrnät till lokalt servernät: till exempel VPN till Server.
• Management eller monitoring: tillåt endast definierade administrations- eller monitoringsystem.
• DNS, AD, RDP, HTTPS: tillåt endast nödvändiga Services, inte generellt Any.

XFRM-interface tillhör alltid VPN-zonen. Om båda riktningarna används krävs passande inbound- och outbound-regler. Separata regler med logging visar tydligare under acceptanstestet vilka services respektive sida får nå. Den allmänna strukturen beskrivs i Skapa och kontrollera Sophos Firewall-brandväggsregler säkert.

Inkommande IPsec-paket avkapslas och dekrypteras först. Den matchande brandväggsregeln tillämpar sedan sina säkerhetspolicyer på nyttotrafiken innan den vidarebefordras till målet. För utgående trafik tillämpas den matchande brandväggsregeln före inkapsling och kryptering.

Alternativet Create firewall rule skapar separata regler med prefixen Incoming och Outgoing högst upp i regellistan. Därefter:

• Kontrollera regelpositionen.
• Begränsa Source och Destination.
• Reducera Any till nödvändiga Services.
• Aktivera Log firewall traffic för införande och felanalys.
• Välj IPS, Web, Application Control och andra Security Features medvetet.
• Ge regeln ett tydligt namn, till exempel LAN_to_Branch_Zurich.

De skapade reglerna finns i gruppen Automatic VPN rules. I exemplet tillåter huvudkontoret utgående trafik med Source zone LAN, Source network HQ_LAN, Destination zone VPN och Destination network Branch_LAN; för inkommande trafik byts zoner och nät plats. I filialen gäller samma spegling med Branch_LAN som lokalt nät. Begränsa Services till de godkända applikationsportarna i varje regel och aktivera Log firewall traffic. Befintliga lämpliga regler kan kompletteras med rätt Source-/Destination-nät i stället för att nya regler skapas för varje tunnel. Kontrollera först påverkan på alla andra anslutningar som omfattas av regeln. SFOS utvärderar regler uppifrån och ned och stannar vid den första matchningen; en ny regel högst upp i listan kan därför åsidosätta tidigare begränsningar.

⚠️ Automatiskt skapade brandväggsregler är en startpunkt, inte en färdig säkerhetsdesign. Särskilt vid platstunnlar till servernät bör Services, Sources och Destinations begränsas efter det första testet.

Sophos kan inte skapa regler automatiskt för route-based Any-to-Any. Med Dual skapas IPv4- och IPv6-regler separat. Om en filials internettrafik ska gå genom huvudkontoret krävs också en separat NAT- och säkerhetsdesign.

Planera NAT efter tunneltyp

NAT är inte förbjudet med IPsec, men det måste finnas en tydlig anledning. Typiska fall är överlappande nät, cloudkrav eller särskilda källadresser som en tredjepart kräver. NAT ersätter inte en route och ändrar inte routingbeslutet: oberoende av översättningen måste SFOS kunna välja en lämplig VPN-, statisk, SD-WAN- eller dynamisk route.

Menysökväg:

Rules and policies > NAT rules

Besvara följande frågor innan en NAT-regel skapas:

• Förväntar sig motparten ursprungliga IP-adresser eller översatta adresser?
• Finns det överlappande nät?
• Konfigureras NAT i IPsec-anslutningen eller via separata NAT-regler?
• Är returriktningen dokumenterad?
• Visar Log Viewer förväntad Source och Destination efter NAT?

NAT-logiken skiljer sig mellan VPN-typer:

• Vid policy-based IPsec och route-based VPN med Traffic Selectors kan NAT för överlappande nät konfigureras direkt i IPsec-anslutningen.
• Vid route-based Any-to-Any används SNAT- och DNAT-regler under Rules and policies > NAT rules.
• Vid överlappande nät måste båda sidor förstå samma översättningsplan. Ensidig NAT utan planerad returväg ger ofta gröna tunnlar utan användbar trafik.

För NAT i IPsec-anslutningen aktiveras Network Address Translation (NAT). Translated subnet visar det lokala, översatta nät som har valts i anslutningen; under Original subnet väljs det faktiska överlappande lokala nätet. För nät utan översättning behålls Not translated. Stäm före sparandet av originalnät, översatt nät, motpartens Remote selector och DNS-måladress i en tabell. Dra inte slutsatser om riktningen enbart utifrån fältnamnen; den länkade NAT-proceduren innehåller det fullständiga exemplet. För Any-to-Any ska dessa fält inte användas som ersättning för separata SNAT-/DNAT-regler.

⚠️ Vid route-based IPsec med Traffic Selectors används NAT-inställningen i IPsec-anslutningen; tilldela ingen IP-adress eller manuell route till det skapade XFRM-interfacet. Kontrollera interfacet i den installerade builden mot dokumentationen för SFOS 22 och SFOS 23. IPsec med NAT för överlappande nät visar den fullständiga spegelvända adress-, DNS- och NAT-konfigurationen.

Om trafik från en route-based VPN med Traffic Selectors matchar en SNAT-regel med Translated source = MASQ, kastar brandväggen paketen eftersom dessa XFRM-interface inte har några tilldelade IP-adresser. Det kan förklara en grön tunnel utan användbar trafik. Kontrollera den matchande NAT-regeln och dess placering för det berörda testflödet och korrigera endast den regel som orsakar konflikten; inaktivera inte MASQ generellt för andra anslutningar. Kontrollera sedan samma flöde igen i båda riktningarna med Log Viewer och Packet Capture.

Om nyttotrafik för policy-based IPsec översätts med en separat SNAT-regel måste dess Outbound interface vara Any. En regel som bara innehåller specifika WAN-portar där — normalt standard-SNAT-regeln — matchar inte denna VPN-trafik. Med Any använder brandväggen den Translated source som är konfigurerad i den matchande SNAT-regeln. Detta beteende gäller även när Override source translation (SNAT) är aktiverat för specifika utgående interface.

Sedan SFOS 22 skapar policy-based IPsec VPN-routen i backend. En manuell ipsec_route är inget standardsteg, men kan vara relevant för vissa scenarier med vidarebefordrad trafik. För systemgenererade autentiseringsförfrågningar motsäger Sophos hjälptexter för SFOS 22 och SFOS 23 varandra: routing-/NAT-översikten anger att denna trafik inte behöver kommandot; autentiseringsanvisningen beskriver däremot ett policy-based undantag när vald Route Precedence inte skickar trafiken in i tunneln. Detta innebär varken att en extra route behövs för all systemtrafik eller att global Route Precedence ska ändras generellt.

Före en ändring måste källadress, sys-traffic-nat, Traffic Selectors och returväg stämma överens med det faktiskt observerade paketflödet. Den befintliga IPsec-routeguiden och proceduren för systemgenererade autentiseringsförfrågningar förklarar de riktade kontrollerna med en verklig förfrågan och Packet Capture samt separat rollback för NAT och route. Om beteendet i den installerade builden fortfarande är oklart måste det klargöras med Sophos Support före en ändring i produktionsmiljön. Se även Förstå NAT-regler på Sophos Firewall.

Device Access för inkommande IPsec

För inkommande IPsec-förfrågningar måste brandväggen kunna ta emot IPsec-trafik på rätt WAN-zon. Det löses inte med en vanlig LAN-to-WAN-regel, utan via brandväggens lokala services.

Menysökväg:

Administration > Device access

IPsec måste vara tillåtet för WAN när brandväggen tar emot inkommande förfrågningar, till exempel med Respond only. Det ersätter inte regler för användartrafik genom tunneln. Kontrollera samtidigt om WebAdmin, SSH, User Portal eller VPN Portal är onödigt brett nåbara. För att härda dessa lokala services, se Säkra åtkomst till Sophos Firewall: konfigurera Device Access rätt.

Om en motpart ska pinga själva brandväggen genom tunneln tillåter du zonen VPN under Ping/Ping6 och väljer Apply. Detta är inte ett nödvändigt globalt steg för att pinga en LAN-host: då är det de matchande transitreglerna och hostens brandvägg som avgör. Tillåt endast den lokala tjänst som behövs för testet, dokumentera dess ursprungliga inställning och återställ den efter testet om tillåtelsen inte behövs permanent. En ping från brandväggens shell har dessutom en annan källadress än en LAN-klient; behandla inte dessa två tester som likvärdiga kontroller av klientregeln.

Testa och felsök tunneln

Ett bra acceptanstest kontrollerar mer än grön status. Det kontrollerar det faktiska dataflödet.

Definiera en acceptansmatris

Definiera en liten acceptansmatris före det första testet. Då blir det tydligt vilken anslutning som ska fungera och vilken som avsiktligt ska förbli blockerad.

Användbara testfall:

• Lokalt klientnät till fjärrservernät: typiskt applikationstest, till exempel HTTPS, RDP, SMB, SQL eller ICMP endast som grundtest.
• Fjärrklientnät till lokalt servernät: kontrollera motsatt riktning om anslutningen används dubbelriktat.
• DNS eller AD genom tunneln: testa endast om dessa tjänster verkligen ska gå genom tunneln. Ange Source, målserver och port exakt.
• Monitoring eller backup: kontrollera att planerade system ansluter från rätt riktning och inte av misstag behöver Any-regler.
• Blockerat test: en avsiktligt otillåten port eller ett otillåtet nät ska blockeras. Annars är regelbasen för bred.
• Stor överföring: vid filöverföring, RDP, VoIP eller applikationsproblem ska även MTU/MSS och fragmentering övervakas.

För varje testfall bör Source IP, Destination IP, Service, förväntad brandväggsregel, förväntad NAT-regel och förväntad riktning noteras. Efter varje test jämförs Log Viewer, Packet Capture och byte-räknare. Om endast ping testas är tunneln ännu inte godkänd.

1. Kontrollera status

I WebAdmin-gränssnittet:

Site-to-site VPN > IPsec

Kontrollera:

• Anslutningen är aktiv.
• Tunnelstatus är established.
• Vid flera nät är alla förväntade Child SAs etablerade.

Under Current activities > IPsec connections visas endast anslutningar som faktiskt är etablerade. Tillgängliga filter är Connection name, Local server name, Local subnet, Username, Remote server/host och Remote subnet; Refresh uppdaterar vyn. Disconnect kopplar ned en befintlig SA kontrollerat, exempelvis när båda sidor är redo för en konfigurationsändring; åtgärden ersätter inte inaktivering eller återställning av anslutningen.

Fastställ det förväntade antalet: route-based Any-to-Any skapar en Phase 2-anslutning per XFRM-interface; Dual skapar en för IPv4 och en för IPv6. Policy-based och route-based med Traffic Selectors skapar en anslutning för varje kombination av Local och Remote subnet.

Före den första nyttotrafiken via route-based Any-to-Any kontrolleras den verkliga målhostadressen under Diagnostics > Tools > Route lookup. Resultatet måste peka på avsett XFRM-interface eller avsedd XFRM-gateway på båda brandväggarna.

2. Kontrollera Log Viewer

Menysökväg:

Log viewer

Generera testtrafik med tydlig Source, Destination och Service. Kontrollera sedan i Log Viewer vilken brandväggsregel som matchar och om NAT, Webfilter, IPS eller andra moduler påverkar trafiken. Proceduren beskrivs i Testa en brandväggsregel med Log Viewer, Policy Test och Packet Capture. Återkommande rekeys, disconnects och anslutningsfel kontrolleras i IPsec-loggarna och ska inte härledas från aktuell SA-status.

3. Packet Capture och Advanced Shell

Om Log Viewer inte räcker används Packet Capture med ett snävt filter:

Diagnostics > Packet capture

Filterexempel:

host 172.16.10.25 and host 10.20.30.15

Vid VPN-felsökning är det viktigt att kontrollera båda riktningarna. Utgående paket utan svar tyder oftast på ett problem med returvägen, NAT eller motparten.

I det genomgående exemplet testar du från LAN-klienten 10.10.10.25 mot en faktiskt befintlig host i filialen, 10.20.20.15, inte mot nätadressen 10.20.20.0. På Windows startar ping 10.20.20.15 -t ett kontinuerligt test; avsluta med Ctrl+C. Under Diagnostics > Packet capture > Configure anger du host 10.10.10.25 and host 10.20.20.15 and proto ICMP som BPF string, sparar och aktiverar capture. För route-based kontrolleras utgående trafik på tillhörande XFRM-interface och returpaketen. Sök efter den faktiska klientadressen i Log viewer; öppna den matchande regeln med hjälp av Firewall rule ID och Filter firewall rule. Testa därefter även en planerad applikationsport och motsatt riktning. Stäng av capture igen och återställ tillfälliga filter och tillåtelser; en kontinuerlig capture är inte driftövervakning. Bakom en router kontrolleras dessutom i båda motparternas loggar att NAT har identifierats och NAT-T har förhandlats.

Advanced Shell

För djupare felsökning via SSH, öppna 5. Device Management > 3. Advanced Shell och kontrollera aktuell SA-status:

ipsec statusall

Följande är bland annat relevant:

• IKE SA established
• Child SA installed
• lokala Traffic Selectors och fjärrsidans Traffic Selectors
• byte-räknare i båda riktningar

Om SSH ännu inte är förberett, se Anslut till Sophos Firewall via SSH.

Aktuella IPsec-loggar

Den aktuella SFOS 22-loggöversikten skiljer mellan funktionerna:

• strongswan.log: IPsec-tjänst och anslutningar.
• charon.log: IPsec-tjänst och NAT i IPsec-anslutningar.
• ipsec_monitor.log: monitoring av IPsec-tjänsten.
• /log/ipsec_conn/ipsec_<connectionname>.log: aktivering, avaktivering och anslutning via WebAdmin.
• xfrmi.log: XFRM-interface vid route-based IPsec.
• dgd.log: endast som tillägg vid VPN-failover, SD-WAN, DGD eller Link Load Balancing, inte som allmän IPsec-logg.

För fullständig logg- och XFRM-diagnostik, se Sophos Firewall IPsec VPN Troubleshooting.

Typiska fel

• Tunneln kommer inte upp: IKE-version, profil, PSK, certifikat, Local ID eller Remote ID stämmer troligen inte. Kontrollera strongswan.log, IPsec-profilen och motparten.
• Phase 1 är uppe, Phase 2 inte: lokala nät eller fjärrnät, eller Phase 2 proposal, stämmer troligen inte. Kontrollera Traffic Selectors, subnät och PFS.
• Tunneln är grön, men ingen åtkomst finns: brandväggsregel, NAT, routing eller returväg saknas troligen. Kontrollera Log Viewer, Packet Capture och routing.
• Bara en riktning fungerar: motparten känner inte till returrouten eller NAT är fel. Kontrollera motparten, NAT-regler och byte-räknare.
• Små pings fungerar, men applikationer fastnar: MTU/MSS, fragmentering eller en Security Feature är troligen inblandad. Kontrollera MTU/MSS och Packet Capture.
• Route-based Any-to-Any fungerar inte: XFRM-IP, gateway, route eller brandväggsregel stämmer troligen inte. Kontrollera Network > Interfaces, routing och regler för VPN-zonen.
• Route-based med Traffic Selectors fungerar inte: kontrollera det dokumenterade XFRM-interfacet under Listening interface, automatisk route, varje förväntad Child SA, Selectors, VPN-zonens regler och en möjlig MASQ-regel. Använd XFRM-interfacet för Packet Capture, men tilldela varken IP-adress eller manuell route. Om det saknas ska build och konfiguration utredas i stället för att ett ersättningsinterface skapas.
• Flera tunnlar påverkar varandra: överlappande nät eller liknande Selector-konfigurationer är troliga. Kontrollera tunnelobjekt, failover group och routes.

Återställning efter underkänt acceptanstest

Återställ en ny tunnel kontrollerat i stället för att ta bort objekt på måfå:

1. Under Current activities > IPsec connections, koppla ned berörd SA med Disconnect och inaktivera den nya IPsec-anslutningen.
2. Inaktivera endast de statiska eller SD-WAN-routes, NAT-regler och brandväggsregler som skapades för ändringen, inklusive automatiska VPN-regler. Radera inte ett genererat XFRM-interface separat; interfacet hanteras genom att anslutningen inaktiveras. Om det dokumenterade interfacet saknas i builden ska version och konfiguration utredas, inte ett ersättningsinterface skapas.
3. Vid migrering, tilldela den tidigare profilen till den gamla anslutningen igen och aktivera därefter anslutningen och den gamla routingvägen.
4. Testa om det ursprungliga flödet samt lokal internettrafik respektive trafik mellan platser med Log Viewer och Packet Capture.
5. Ta bort nya objekt först när Object Usage inte visar andra beroenden och den gamla vägen bevisligen fungerar igen.

Ta bort en specifik sparad anslutning

Att radera en sparad IPsec-anslutning skiljer sig från Disconnect, inaktivering eller att radera en failovergrupp. Dokumentera före en separat godkänd borttagning exakt befintligt Name, Object Usage, grupptillhörigheter och en administrationsväg som inte är beroende av tunneln. Radera inte en anslutning så länge den tillhör en failovergrupp; den länkade failoverproceduren beskriver hur tilldelningen tas bort kontrollerat.

XML-API:ts borttagningsreferens för SFOS 22 och SFOS 23 anger Name som obligatoriskt ARRAY med datatyp STRING: första tecknet A-Za-z, efterföljande A-Za-z0-9_, högst 100 tecken och flera värden tillåtna. Den innehåller däremot inget exempel på en förfrågan. Härled varken en serialiserare för flera namn eller ett målnamn från GUI-exemplet branch-zurich; skriv inte om ett sparat namn för att få det att verka följa kraven.

Referensen kopplar XML-operationsstatus 200 till Message.IPSecDeleteSuccess, 201 till Message.IPSecConnInUse och 500 till Message.IPSecDeleteFail. Meddelandetexterna infogas genom JavaScript och är fortfarande olösta symboler: detta är varken HTTP-statuskoder eller fullständiga visade svarstexter. Räkna inte 201 som en lyckad borttagning bara för att talet börjar med 2; för Edit motsvarar samma tal Message.IPSecUpdated. Läs efter en godkänd borttagning tillbaka exakt det målet och kontrollera kvarvarande produktionsvägar. Vid oklart resultat ska målstatus och beroenden utredas innan ett nytt försök övervägs; upprepa inte blint.

Checklista

Före ändringen:

• Lokala nät och fjärrnät är entydiga.
• Policy-based eller route-based har valts medvetet.
• IPsec-profilen är avstämd med motparten.
• Preshared Key, certifikat eller RSA-nycklar är säkert dokumenterade.
• Brandväggsregler är planerade, inklusive riktning, regelposition, logging och services.
• Vid Create firewall rule är det klart vilka automatiskt skapade regler som måste efterbearbetas.
• Vid route-based Any-to-Any är XFRM-IP, gateway, manuella brandväggsregler och routes planerade.
• Vid route-based med Traffic Selectors har XFRM-interfacets faktiska synlighet, installerad SFOS-version, interfacetilldelning och den faktiskt genererade routen dokumenterats; oavsett om interfacet visas planeras varken XFRM-IP eller manuell route. Om interfacet saknas ska build, konfiguration och loggar utredas före migreringen.
• NAT är antingen uteslutet eller medvetet dokumenterat.
• Device Access för inkommande IPsec är kontrollerat.
• Underhållsfönster, motpart och fallbackväg är kända.

Efter ändringen:

• Tunnelstatus är established.
• Acceptansmatrisen med minst ett test per nödvändig riktning har genomförts och godkänts.
• Log Viewer visar den förväntade brandväggsregeln.
• Packet Capture visar utgående och återgående trafik.
• Intern DNS- och applikationsåtkomst har testats.
• Byte-räknare stiger i båda riktningar.
• NAT och returväg är avstämda med motparten.
• Ändringen är införd i nätverksdokumentationen.

Vanliga frågor