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.

⚠️ 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. NAT-T-sökvägen måste tillåta UDP 500 och UDP 4500; ESP direkt via IP protocol 50 behövs bara på en sökväg utan NAT. Detta är skilt från den senare SNAT- eller DNAT-planeringen för överlappande nät eller översatt datatrafik.

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.

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

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.

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.

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 från routeval. Med Any-to-Any tillhandahåller SFOS ett eget adresserbart XFRM-interface. För specifika Traffic Selectors motsäger aktuell SFOS 22-dokumentation sig själv om huruvida interfacet skapas, enligt förklaringen nedan.

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

1. XFRM-interfacet syns under Network > Interfaces och har planerad överförings-IP.
2. Routen pekar på rätt XFRM-interface eller 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

Med specifika subnät är SFOS 22-beteendet i detta specialfall inte entydigt: ett XFRM-interface kan saknas, men brandväggen kan också skapa ett per Traffic Selector-konfiguration. Expandera Listening interface under Network > Interfaces och kontrollera det faktiska tillståndet i den installerade builden; ett befintligt XFRM-interface kan även väljas under Diagnostics > Packet capture. Om ett XFRM-interface visas ska du inte tilldela det en IP-adress eller routes. Den statiska routen skapas automatiskt när tunneln är established. Any på endast ena sidan med en specifik selector på den andra stöds inte.

Den här varianten passar små, tydligt definierade nät. Om interfacet syns används det enligt dokumentationen för att bekräfta utgående trafik i Diagnostics > Packet capture; kontrollera även automatisk route, Child SAs, loggar och trafik i båda riktningar. WAF över route-based IPsec med Traffic Selectors stöds 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.

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.

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

⚠️ Vid route-based IPsec med Traffic Selectors används NAT-inställningen i IPsec-anslutningen; tilldela ingen IP-adress eller manuell route till ett XFRM-interface om installerad build visar ett. 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 bara relevant för vissa scenarier med vidarebefordrad trafik och är inget standardsteg; systemgenererad trafik behöver den inte. 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.

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 filtreras de anslutningar som faktiskt är etablerade efter Connection name, Local subnet eller Remote subnet, och vyn uppdateras med Refresh. Disconnect kopplar ned en SA kontrollerat, exempelvis när båda sidor är redo för en ändring; åtgärden ersätter inte inaktivering eller återställning.

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.

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 om faktisk build visar XFRM-interfacet under Listening interface. Använd det i så fall i Packet Capture, men tilldela varken IP-adress eller route. Kontrollera även automatisk route, Selectors, VPN-zonens regler 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.

Å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 om builden visar det; interfacet hanteras genom att anslutningen inaktiveras.
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.

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 faktisk XFRM-synlighet dokumenterats; ingen XFRM-IP eller manuell route planeras, oavsett om builden visar 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.
• 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