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

Därefter följer en riktad regel Branch_LAN_to_WAN_drop för samma filialnät från LAN till WAN. Den förhindrar att en alltför bred lokal internetregel kringgår den planerade tunnelvägen. Andra nät eller uttryckligen nödvändiga 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.

Standardvärdet är enable. Eftersom ett befintligt system kan ha ett annat värde visas först det aktuella tillståndet med detta skrivskyddade kommando i Device Console:

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:

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

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

Vid rollback återställs det dokumenterade föregående tillståndet. Om alternativet tidigare var aktiverat är motkommandot:

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

Efter varje ändring kontrolleras alla IPsec-anslutningar och nödvändiga brandväggstjänster på nytt.

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: standarddesignen erbjuder ingen lokal internet-breakout. 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