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 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. Aktuella SFOS-versioner skiljer tydligare mellan dessa begrepp än äldre instruktioner, som ibland fortfarande talar om Site-to-Site eller Tunnel Interface.

• Policy-based IPsec: passar enkla platsförbindelser med tydligt definierade lokala nät och fjärrnät. Styrs främst via lokala subnät och fjärrsubnät i IPsec-anslutningen samt via brandväggsregler. Sophos skapar separata Phase 2-tunnlar för kombinationerna av lokala subnät och fjärrsubnät.
• Route-based IPsec med Traffic Selectors: använder också lokala subnät och fjärrsubnät, men skapar ett eget XFRM-interface. Sophos skapar routen automatiskt; ingen IP-adress eller egna routes får tilldelas XFRM-interfacet. WAF stöds inte med den här varianten.
• Route-based IPsec Any-to-Any: är det mest flexibla alternativet för växande nät, SD-WAN, dynamisk routing och dual-stack-design. Routes och brandväggsregler, inte subnäten i IPsec-anslutningen, avgör då vilka paket som går in i tunneln.

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.

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.

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

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.

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. En publik CA bör inte generellt användas som Remote CA Certificate, eftersom det ger för stort förtroende för externa certifikat. RSA key är en separat Authentication type: båda brandväggarna utbyter sina publika nycklar och måste använda samma format, PKCS1 eller DNS.

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.

Om CA:n återkallar certifikat före utgångsdatumet måste även den aktuella återkallningslistan ingå i driftsplanen. Den separata processen beskriver CRL-import, nextUpdate och ett kontrollerat negativt test i 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 IPsec_IKEv2_AES256_G14. 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.

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

Vid policy-based IPsec får högst ena sidan av Traffic Selectors vara inställd på Any. Med flera specifika lokala nät och fjärrnät skapar Sophos en Phase 2 SA för varje kombination.

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.

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.

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.

Konfigurera route-based IPsec

Route-based IPsec separerar VPN-förhandling och dataväg via ett eget XFRM-interface. Om detta interface ska adresseras och routas manuellt beror på den valda varianten.

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

Sophos visar det skapade XFRM-interfacet under det använda fysiska interfacet i:

Network > Interfaces

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

Any-to-Any och Dual

När båda subnäten är inställda på Any, eller när Dual används, får XFRM-interfacet en överförings-IP. Därefter krävs en statisk route, SD-WAN Route eller dynamisk route via BGP eller OSPF. Med Dual krävs separata IPv4- och IPv6-brandväggsregler.

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 anslutningar, SLA-kontroller eller vissa failoverdesigner skapas dessutom en Custom Gateway med motpartens XFRM-IP och används i en SD-WAN Route.

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 tre punkter efter sparandet:

1. XFRM-interfacet syns under Network > Interfaces och är adresserat med planerad överförings-IP.
2. Routen till fjärrnätet pekar direkt på XFRM-interfacet eller, i en gateway-/SD-WAN-design, på rätt XFRM-gateway.
3. Brandväggsregler tillåter endast planerade riktningar och services.

Traffic Selectors

Med specifika Local och Remote subnets skapar Sophos också ett XFRM-interface, men ingen IP-adress eller egna routes får tilldelas interfacet. Den statiska routen skapas automatiskt så snart tunneln är established. Any på bara ena sidan med en specifik selector på den andra stöds inte.

Den här varianten passar små, tydligt definierade nät och förenklar XFRM-diagnostik. WAF över route-based IPsec med Traffic Selectors stöds dock inte.

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.

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.

⚠️ 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 tredjeparter som bara accepterar vissa källadresser.

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.

⚠️ Vid route-based IPsec med Traffic Selectors har XFRM-interfacet ingen IP-adress. Om trafiken matchar en MASQ SNAT-regel kasserar brandväggen paketen. Använd NAT-inställningen i IPsec-anslutningen för överlappande nät och kontrollera att ingen MASQ SNAT-regel matchar trafiken.

Sedan SFOS 22 skapar policy-based IPsec VPN-routen i backend. En manuell ipsec_route är bara relevant för viss översatt, vidarebefordrad trafik och är inget standardsteg; systemgenererad trafik behöver den inte. Ytterligare grunder om NAT finns i 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.

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.

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.

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: konfigurera ingen IP-adress eller manuell route på XFRM-interfacet. Kontrollera den automatiska routen, Selectors, reglerna för VPN-zonen och en möjlig MASQ-regel.
• Flera tunnlar påverkar varandra: överlappande nät eller liknande Selector-konfigurationer är troliga. Kontrollera tunnelobjekt, failover group och routes.

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 planeras ingen IP-adress eller manuella routes på XFRM-interfacet.
• 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.
• En acceptansmatris med minst ett test per nödvändig riktning är definierad.
• 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