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 policy-based IPsec. För nya eller växande designer är route-based Any-to-Any med XFRM och explicit routing ofta flexiblare. 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.
| Inställning | Huvudkontor | Filial |
|---|---|---|
| Local subnet | Any | 10.20.0.0/24 |
| Remote subnet | 10.20.0.0/24 | Any |
| Gateway type | Respond only | Initiate the connection |
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.
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 dokumenterad returväg och ett underhållsfönster.
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. Utan korrekt returväg och NAT kan tunneln vara grön medan internetanslutningarna inte får något svar.
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 - 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.
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.
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:
- På filialen matchar
Branch_LAN_to_VPN; den lokala LAN-to-WAN-drop-regeln matchar inte det här lyckade flödet. - På huvudkontoret matchar
Branch_VPN_to_WANoch den länkade MASQ-regeln. - Den publikt synliga källadressen tillhör huvudkontoret.
- DNS, HTTPS och ett avsiktligt blockerat mål beter sig enligt den centrala policyn.
- Packet Capture visar utgående paket och svarspaket genom tunneln och huvudkontorets WAN.
- Systemgenererad trafik använder den tidigare valda lokala eller centrala vägen.
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.
Vid rollback inaktiveras först Branch_LAN_to_WAN_drop och den tidigare tillåtna lokala internetvägen återställs kontrollerat. Därefter tas VPN-to-WAN-regeln och MASQ bort endast om inget annat flöde behöver dem. Route Precedence och systemtrafikalternativet återställs exakt till de dokumenterade tidigare värdena. Sedan genomförs nya tester på båda platserna.