Dirigera filialens internet via huvudkontoret över IPsec

När en filials internettrafik ska inspekteras centralt och gå ut via huvudkontorets WAN-anslutning kan Sophos Firewall använda en policy-based site-to-site-IPsec-tunnel. Filialens klienter skickar då inte trafiken direkt till sitt lokala WAN, utan genom tunneln till huvudkontoret. Där tillämpas de centrala brandväggs-, NAT- och säkerhetsreglerna.

Filial-LAN → Filialbrandvägg → policy-based IPsec → Huvudkontor → MASQ → Internet

Den här lösningen kräver mer än en grön VPN-tunnel. Route Precedence, Traffic Selectors, regelordning och returväg måste stämma överens. Om tunneln eller huvudkontoret slutar fungera har filialen i den här designen normalt ingen automatisk lokal internet-breakout.

⚠️ Det här arbetsflödet gäller endast policy-based IPsec. Motparten får inte vara route-based. För nya eller växande designer rekommenderas route-based Any-to-Any: båda parter använder Any-selektorer, får var sitt XFRM-interface och kräver explicita Static-, SD-WAN- eller dynamiska rutter. Blanda inte dessa steg med det policy-based arbetsflödet nedan. Typvalet förklaras i Konfigurera site-to-site IPsec VPN.

Exempel och förutsättningar

I exemplet används filialnätet 10.20.0.0/24. Huvudkontoret har en fungerande WAN-anslutning och en redan planerad policy-based tunnel. 10.20.0.0/24 är ett dokumentationsvärde som ska ersättas med det verkliga filialnätet.

För den här designen måste den globala Route Precedence vara VPN, Static, SD-WAN. Innan den ändras sparas det aktuella värdet och alla andra static-, VPN- och SD-WAN-vägar som kan påverkas identifieras. Det kontrollerade arbetsflödet beskrivs i Ändra Route Precedence på ett säkert sätt.

Standardvärdet i SFOS 22 är Static, SD-WAN, VPN. Den här designen avviker eftersom Remote subnet: Any skapar en automatisk policy-based VPN-rutt för alla mål på filialen. Ta inte bort den befintliga Static-standardrutten 0.0.0.0/0 till lokalt WAN: den behövs fortfarande för brandväggsgenererad trafik när VPN-användning är avstängd och för en kontrollerad rollback. Läs aktuellt värde i Device Console med system route_precedence show; artikeln om Route Precedence innehåller ändringskommando, konsekvensanalys och återställningsväg.

Före ändringen måste även följande vara på plats:

• en fungerande policy-based IPsec-tunnel mellan de två brandväggarna;
• testad administrativ åtkomst till båda platserna;
• tillräcklig internet- och brandväggskapacitet på huvudkontoret;
• DNS, Web Policies, IPS, Application Control och önskade undantag;
• en aktuell konfigurationsbackup och ändringslogg med ursprungliga selektorer, Route Precedence, systemtrafikalternativ samt brandväggs- och NAT-ID:n;
• en dokumenterad returväg och ett underhållsfönster.

Vid HA dokumenteras före ändringen aktiv nod, felfri klusterstatus och administrativ åtkomst till peer på varje plats. HA ersätter varken ett andra centralt WAN eller en andra plats. Failover behandlas som ett separat test och härleds inte från en grön tunnel.

Ange IPsec-selektorerna

På huvudkontoret anges Local subnet som Any och Remote subnet som filialens LAN. På filialen gäller det omvända: det lokala filialnätet och Any som fjärrnät.

Därefter testas tunneln mot ett internt mål på huvudkontoret. Internetvägen aktiveras först när platstrafiken fungerar i båda riktningarna. På så sätt kan ett IPsec-fel fortfarande skiljas från ett NAT- eller regelfel.

Skapa brandväggs- och NAT-regler

Reglerna skapas under Rules and policies > Firewall rules. Automatiskt skapade VPN-regler är inte i sig en färdig design för den här internetvägen.

Huvudkontor: VPN till WAN

Regeln Branch_VPN_to_WAN tillåter trafik från filialen till internet:

• Action: Accept
• Source zones: VPN
• Source networks: 10.20.0.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: endast de tjänster som verkligen behövs
• Log firewall traffic: aktiverad
• Create linked NAT rule > Translated source (SNAT): MASQ

Web Policy, IPS, Application Control och TLS Inspection väljs medvetet. Den länkade MASQ-regeln översätter filialklienterna till huvudkontorets publika adress. För utgående trafik utvärderar SFOS brandväggsregeln före SNAT; kontrollera därför även NAT-ordningen, eftersom en tidigare matchande NAT-regel har företräde. NAT skapar inte heller en rutt, och NAT-ändringar gäller endast nya anslutningar.

Returvägen har två delar: MASQ för tillbaka internetsvaren till huvudkontorets WAN-adress; huvudkontoret använder därefter sin automatiskt skapade policy-based VPN-rutt till den återöversatta destinationen 10.20.0.0/24. Om filialens LAN ligger bakom en annan router ska även dess väg i båda riktningarna dokumenteras och testas.

Filial: tillåt LAN till VPN

Regeln Branch_LAN_to_VPN placeras ovanför alla lokala regler som tillåter LAN till WAN:

• Action: Accept
• Source zones: LAN
• Source networks: 10.20.0.0/24
• Destination zones: VPN
• Destination networks: Any
• Services: endast de tjänster som verkligen behövs
• Log firewall traffic: aktiverad

⚠️ Klargör blockeringen av webbtrafik i förväg: Tillverkarens uppgifter om Drop, HTTP/HTTPS, autentisering och Web Exceptions motsäger varandra. Drop-regeln bevisar därför inte ensam att lokal internetåtkomst är fullständigt blockerad. Före produktionssättning måste den exakta SFOS-versionen, builden och bearbetningsvägen verifieras genom ett skriftligt klargörande från Sophos eller ett uttryckligen godkänt, isolerat test. Testfall och stoppvillkor finns under Action och loggning i brandväggsregler. Rulla inte ut i produktion om webbåtkomst tillåts på ett oklart eller oväntat sätt.

Därefter följer en riktad Drop-regel Branch_LAN_to_WAN_drop för samma filialnät från LAN till WAN. Den utgör den planerade blockeringslogiken för en lokal internetväg vid sidan av tunneln; dess faktiska effekt måste bekräftas enligt ovan. Andra nät eller uttryckligen planerade lokala tjänster ska inte omfattas av misstag.

Ordningen är en del av säkerheten: specifika undantag, Branch_LAN_to_VPN, därefter Branch_LAN_to_WAN_drop och sedan bredare regler. Efter ändringar används nya klientanslutningar för verifiering, inte bara befintliga sessioner.

Skapa brandväggsregler på ett säkert sätt förklarar hur regelposition, Rule ID och den länkade NAT-regeln kontrolleras tillsammans.

Bestäm separat hur systemgenererad trafik ska hanteras

Reglerna ovan styr vidarebefordrad klienttrafik. DNS, NTP, uppdateringar, Central och andra anslutningar som filialbrandväggen själv skapar är systemgenererad trafik.

Även DNS delas upp efter ursprung. En klient med publik resolver följer klientvägen genom tunneln. En intern resolver på huvudkontoret kräver lämplig selektor, brandväggsregel och returväg. Endast DNS-frågor som brandväggen själv skapar följer systemtrafikalternativet nedan. Därför testas en publik IP-adress och ett FQDN separat.

Den dokumenterade standardinställningen är enable; den visar inte det faktiska tillståndet i en befintlig installation. SFOS-22/23-källorna anger inte följande getter. Den är därför endast en referens för bekräftelse, inte en verifierad läsanvisning: använd den endast om syntaxen och innebörden av utdata har bekräftats för den installerade builden via dess CLI-hjälp eller av Sophos Support. Kör den annars inte, utan använd en bekräftad läsmetod. Före en ändring ska alternativets faktiska värde läsas med denna metod och dokumenteras i ändringsloggen; dessutom måste det exakta återställningsförfarandet med de dokumenterade enable- eller disable-kommandona vara fastställt. Utan en bekräftad läsmetod, det faktiska föregående värdet och ett exakt återställningsförfarande ändras inte alternativet.

show routing policy-based-ipsec-vpn system-generate-traffic

Om endast klienttrafiken ska gå via huvudkontoret kan brandväggens systemgenererade trafik gå ut lokalt via filialens WAN:

⚠️ Den här ändringen startar om alla IPsec-tunnlar på brandväggen. Dokumentera status och återställningsväg samt planera ett underhållsfönster före körning. Kommandot ska inte köras enbart som test eller på måfå.

set routing policy-based-ipsec-vpn system-generate-traffic disable

Läs omedelbart efter ändringen av alternativet av dess värde igen med samma bekräftade läsmetod; det måste vara disable. Denna tillståndsverifiering ersätter inte de tester av samtliga tunnlar, nödvändiga brandväggstjänster och den valda lokala eller centrala datavägen som beskrivs nedan. Om utdata är otydliga eller inte motsvarar målvärdet ska inga ytterligare ändringar göras på måfå; utred i stället avvikelsen tillsammans med Sophos Support.

Vid rollback återställs det dokumenterade föregående tillståndet. Även återställningen av alternativet startar om alla IPsec-tunnlar; vidta samma försiktighetsåtgärder för status, underhållsfönster och återställningsväg före körning. Om alternativet tidigare var aktiverat är motkommandot:

set routing policy-based-ipsec-vpn system-generate-traffic enable

Om det registrerade föregående värdet var disable får rollback inte schablonmässigt sätta värdet till enable. Om alternativets aktuella värde redan motsvarar det föregående värdet behövs inget nytt inställningskommando; annars återställs exakt det registrerade föregående värdet med motsvarande dokumenterade inställningskommando. Efter varje ändring och varje återställning ska alternativets värde läsas tillbaka med samma bekräftade läsmetod och jämföras med respektive målvärde eller det föregående värdet i ändringsloggen. Separat kontrolleras alla IPsec-anslutningar, de nödvändiga brandväggstjänsterna och den fastställda lokala eller centrala datavägen på nytt. Om återläsningen är otydlig eller visar ett avvikande värde får återställningen inte anges som lyckad; kontakta Sophos Support.

Verifiera datavägen

En klient i 10.20.0.0/24 öppnar först en publik IP-adress och därefter ett FQDN via HTTPS. Verifieringen bekräftar flera lager:

1. På filialen matchar Branch_LAN_to_VPN; den lokala LAN-to-WAN-drop-regeln matchar inte det här lyckade flödet.
2. På huvudkontoret matchar Branch_VPN_to_WAN och den länkade MASQ-regeln.
3. Den publikt synliga källadressen tillhör huvudkontoret.
4. DNS, HTTPS och ett avsiktligt blockerat mål beter sig enligt den centrala policyn.
5. Under Diagnostics > Packet capture visar In interface, Out interface, Rule ID, NAT ID, Status och Reason utgående paket och svarspaket genom tunneln och huvudkontorets WAN.
6. Systemgenererad trafik använder den tidigare valda lokala eller centrala vägen.
7. Current activities > IPsec connections förblir upprättad under testet och Log viewer visar inga oväntade drops.
8. Vid HA utförs en godkänd nod-failover separat och hela testet upprepas. Utan detta test görs inget påstående om HA-redundans.

Ett speed test är inte ensamt ett fullständigt bevis. Testa även verkliga program, DNS, Security Logs och en längre nedladdning. Vid prestandaproblem finns separata arbetsflöden för internethastighetstester och MTU och MSS i VPN.

Vanliga fel och rollback

• Filialklienten använder fortfarande lokalt WAN: kontrollera regelordning, Source Network, LAN-to-VPN-regeln och drop-regeln. Lägg inte till ett brett undantag som snabb lösning.
• Tunneln är grön, men internet saknas: kontrollera VPN-to-WAN-regeln, Rule ID, MASQ, WAN-gateway, DNS och returväg på huvudkontoret.
• Endast brandväggen själv använder fel väg: kontrollera policy-based-ipsec-vpn system-generate-traffic. Blanda inte ihop klienttrafik med systemgenererad trafik.
• Fler tunnlar slutar fungera efter CLI-ändringen: omstarten av alla IPsec-tunnlar är dokumenterat beteende. Återställ det föregående tillståndet och verifiera varje tunnel separat.
• Tunneln eller huvudkontoret slutar fungera: automatisk lokal internet-fallback ingår inte i den här designen. En sådan fallback kräver en separat och medvetet planerad säkerhets- och routingväg.
• En publik IP-adress fungerar men inte ett FQDN: kontrollera klientens DNS-adress, DNS-regeln, vägen till central resolver och svarspaketen. Systemtrafikalternativet spelar bara roll när brandväggen skapar frågan.

För rollback förbereds först en tillfällig LAN-to-WAN-regel ovanför Branch_LAN_to_WAN_drop, begränsad till en enda testklient. Därefter återställs Route Precedence till det dokumenterade värdet och den lokala WAN-vägen kontrolleras med en ny session från klienten. Om testet misslyckas återställs omedelbart full tunnel-prioriteringen och regelstatusen via oberoende managementåtkomst. Först efter ett lyckat test aktiveras den tidigare ordinarie LAN-to-WAN-regeln, Branch_LAN_to_WAN_drop inaktiveras och den tillfälliga regeln tas bort.

Därefter återställs systemtrafikalternativet till sitt tidigare värde och alla IPsec-anslutningar kontrolleras, eftersom ändringen startar om tunnlarna. Branch_LAN_to_VPN, VPN-to-WAN och MASQ inaktiveras eller tas bort endast när Rule ID, NAT ID och användning visar att inga andra flöden behöver dem. Slutligen återställs de ursprungliga IPsec-selektorerna eller så tas en tunnel som skapats enbart för den här vägen bort. Konfigurationsbackup och oberoende managementåtkomst behålls tills nya DNS-, HTTPS- och applikationssessioner fungerar på båda platserna.

FAQ