Internetverkeer van een filiaal via het hoofdkantoor over IPsec leiden

Wanneer het internetverkeer van een filiaal centraal moet worden geïnspecteerd en via de WAN-verbinding van het hoofdkantoor naar buiten moet gaan, kan Sophos Firewall een policy-based Site-to-Site-IPsec-tunnel gebruiken. Filiaalclients sturen hun verkeer dan via de tunnel in plaats van rechtstreeks naar de lokale WAN. Op het hoofdkantoor gelden de centrale firewall-, NAT- en beveiligingsregels.

Filiaal-LAN → Filiaalfirewall → policy-based IPsec → Hoofdkantoor → MASQ → Internet

Dit ontwerp vereist meer dan een groene VPN-tunnel. Route Precedence, Traffic Selectors, regelvolgorde en retourpad moeten samenwerken. Als de tunnel of het hoofdkantoor uitvalt, heeft het filiaal in dit ontwerp normaal geen automatische lokale internetbreakout.

⚠️ Deze werkwijze geldt alleen voor policy-based IPsec. De peer mag niet route-based zijn. Gebruik voor nieuwe of groeiende ontwerpen route-based Any-to-Any: beide peers gebruiken Any-selectors, krijgen elk een XFRM-interface en vereisen expliciete Static-, SD-WAN- of dynamische routes. Meng die stappen niet met de policy-based werkwijze hieronder. De keuze wordt uitgelegd in Een Site-to-Site IPsec VPN instellen.

Voorbeeld en vereisten

Het voorbeeld gebruikt filiaalnetwerk 10.20.0.0/24. Het hoofdkantoor heeft een werkende WAN-verbinding en een reeds geplande policy-based tunnel. 10.20.0.0/24 is een documentatiewaarde die door het echte filiaalnetwerk moet worden vervangen.

Voor dit ontwerp moet de globale Route Precedence VPN, Static, SD-WAN zijn. Sla vóór een wijziging de huidige waarde op en identificeer alle andere Static-, VPN- en SD-WAN-paden die hierdoor worden beïnvloed. De gecontroleerde werkwijze staat in Route Precedence veilig wijzigen.

SFOS 22 gebruikt standaard Static, SD-WAN, VPN. Dit ontwerp wijkt af omdat Remote subnet: Any in het filiaal een automatische policy-based VPN-route voor alle doelen maakt. Verwijder de bestaande Static-default route 0.0.0.0/0 naar de lokale WAN niet: deze blijft beschikbaar voor door de firewall gegenereerd verkeer wanneer VPN-gebruik is uitgeschakeld en voor een gecontroleerde rollback. Lees de huidige waarde in Device Console met system route_precedence show; het Route Precedence-artikel bevat wijzigingscommando, impactanalyse en herstelpad.

Vóór de wijziging moeten ook beschikbaar zijn:

• een werkende policy-based IPsec-tunnel tussen beide firewalls;
• geteste beheerstoegang tot beide locaties;
• voldoende internet- en firewallcapaciteit op het hoofdkantoor;
• DNS, Web Policies, IPS, Application Control en gewenste uitzonderingen;
• een actuele configuratieback-up en wijzigingsregistratie met de oorspronkelijke selectors, Route Precedence, systeemverkeeroptie en firewall- en NAT-ID’s;
• een gedocumenteerd herstelpad en onderhoudsvenster.

Leg bij HA vóór de wijziging per locatie het actieve knooppunt, de gezonde clusterstatus en beheerstoegang tot de peer vast. HA vervangt geen tweede WAN op het hoofdkantoor en geen tweede locatie. Behandel failover als aparte test en leid dit niet af uit een groene tunnel.

De IPsec-selectors instellen

Stel op het hoofdkantoor Local subnet in op Any en Remote subnet op het filiaal-LAN. Gebruik in het filiaal de omgekeerde waarden: het lokale filiaalnetwerk en remote Any.

Test de tunnel daarna met een intern doel op het hoofdkantoor. Activeer het internetpad pas nadat locatieverkeer in beide richtingen werkt. Zo blijft een IPsec-fout te onderscheiden van een NAT- of firewallregelprobleem.

Firewall- en NAT-regels maken

Maak de regels onder Rules and policies > Firewall rules. Automatisch gegenereerde VPN-regels vormen geen compleet ontwerp voor dit internetpad.

Hoofdkantoor: VPN naar WAN

Een regel Branch_VPN_to_WAN staat verkeer van het filiaal naar internet toe:

• Action: Accept
• Source zones: VPN
• Source networks: 10.20.0.0/24
• Destination zones: WAN
• Destination networks: Any
• Services: alleen de werkelijk vereiste diensten
• Log firewall traffic: ingeschakeld
• Create linked NAT rule > Translated source (SNAT): MASQ

Selecteer Web Policy, IPS, Application Control en TLS Inspection bewust. De gekoppelde MASQ-regel vertaalt filiaalclients naar het openbare adres van het hoofdkantoor. Voor uitgaand verkeer evalueert SFOS eerst de firewallregel en daarna SNAT; controleer dus ook de NAT-volgorde, want een eerdere passende NAT-regel krijgt voorrang. NAT maakt bovendien geen route en NAT-wijzigingen raken alleen nieuwe verbindingen.

Het retourpad bestaat uit twee delen: MASQ brengt internetantwoorden terug naar het WAN-adres van het hoofdkantoor; daarna gebruikt het hoofdkantoor de automatisch gemaakte policy-based VPN-route naar het terugvertaalde doel 10.20.0.0/24. Staat het filiaal-LAN achter een andere router, documenteer en test dan ook diens heen- en retourpad.

Filiaal: LAN naar VPN toestaan

De regel Branch_LAN_to_VPN staat boven elke lokale LAN-to-WAN-toestaanregel:

• Action: Accept
• Source zones: LAN
• Source networks: 10.20.0.0/24
• Destination zones: VPN
• Destination networks: Any
• Services: alleen de werkelijk vereiste diensten
• Log firewall traffic: ingeschakeld

⚠️ Werking van webblokkering vooraf verduidelijken: De fabrikantdocumentatie spreekt elkaar tegen over Drop, HTTP/HTTPS, authenticatie en Web Exceptions. De dropregel alleen bewijst daarom niet dat lokale internettoegang volledig is geblokkeerd. Vraag vóór productiegebruik schriftelijke verduidelijking van Sophos voor de exacte SFOS-versie, build en verwerkingsroute, of controleer dit in een expliciet goedgekeurde, geïsoleerde test. Testgevallen en stopvoorwaarden staan bij acties en logging van firewallregels. Rol niet uit naar productie als webtoegang onverwacht of onduidelijk is.

Daarna volgt een gerichte dropregel Branch_LAN_to_WAN_drop voor hetzelfde filiaalnetwerk van LAN naar WAN. Deze vormt de geplande blokkeerlogica tegen een lokaal internetpad naast de tunnel; bevestig de daadwerkelijke werking zoals hierboven beschreven. Neem niet per ongeluk andere netwerken of expliciet benodigde lokale diensten mee.

De volgorde is onderdeel van de beveiliging: specifieke uitzonderingen, Branch_LAN_to_VPN, vervolgens Branch_LAN_to_WAN_drop en daarna bredere regels. Valideer na wijzigingen met nieuwe clientverbindingen en niet alleen met bestaande sessies.

Firewallregels veilig maken legt uit hoe regelpositie, Rule ID en gekoppelde NAT-regel samen worden gecontroleerd.

Afzonderlijk beslissen over systeemgegenereerd verkeer

De voorafgaande regels sturen doorgestuurd clientverkeer. DNS, NTP, updates, Central en andere verbindingen die de filiaalfirewall zelf genereert, zijn systeemgegenereerd verkeer.

Maak bij DNS ook onderscheid naar oorsprong. Een client met een openbare resolver volgt het clientpad door de tunnel. Een interne resolver op het hoofdkantoor vereist een passende selector, firewallregel en retourroute. Alleen DNS-verzoeken van de filiaalfirewall zelf volgen de systeemverkeeroptie hieronder. Daarom worden een openbaar IP-adres en een FQDN apart getest.

De gedocumenteerde standaardinstelling is enable; deze bewijst niet wat de daadwerkelijke status van een bestaande installatie is. De SFOS-22/23-referenties documenteren de volgende getter niet. Deze dient daarom uitsluitend als referentie ter bevestiging, niet als geverifieerde uitleesinstructie: gebruik deze alleen als de syntaxis en de betekenis van de uitvoer voor de geïnstalleerde build zijn bevestigd via de CLI-help van die build of door Sophos Support. Voer de getter anders niet uit en gebruik een bevestigde uitleesmethode. Lees vóór een wijziging de daadwerkelijke optiewaarde met deze methode uit en leg deze vast in de wijzigingsregistratie; bovendien moet de exacte herstelprocedure met de gedocumenteerde enable- of disable-setters vaststaan. Zonder bevestigde uitleesmethode, daadwerkelijke vorige waarde en exacte herstelprocedure wordt de optie niet gewijzigd.

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

Als alleen clientverkeer via het hoofdkantoor moet lopen, kan systeemgegenereerd firewallverkeer rechtstreeks via de filiaal-WAN naar buiten:

⚠️ Deze wijziging start alle IPsec-tunnels op de firewall opnieuw. Leg eerst status, onderhoudsvenster en herstelpad vast. Voer de opdracht niet alleen als test of op basis van een vermoeden uit.

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

Lees de optiewaarde direct na het instellen opnieuw uit met dezelfde bevestigde uitleesmethode; deze moet disable zijn. Deze statuscontrole vervangt niet de hieronder beschreven tests van alle tunnels, de benodigde firewalldiensten en het gekozen lokale of centrale datapad. Als de uitvoer niet eenduidig is of niet overeenkomt met de doelwaarde, voer dan geen verdere wijzigingen op basis van vermoedens uit, maar bespreek de afwijking met Sophos Support.

Herstel bij rollback de gedocumenteerde vorige status. Het herstellen van de optie start ook alle IPsec-tunnels opnieuw; neem vooraf dezelfde voorzorgsmaatregelen voor status, onderhoudsvenster en herstelpad. Als de optie eerder actief was, wordt deze opdracht gebruikt:

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

Als de vastgelegde vorige waarde disable was, mag de rollback niet zonder meer de waarde op enable zetten. Als de huidige optiewaarde al overeenkomt met de vorige waarde, is geen nieuwe setter nodig; anders wordt exact de vastgelegde vorige waarde hersteld met de passende gedocumenteerde setter. Lees na elke wijziging en elke rollback de optiewaarde opnieuw uit met dezelfde bevestigde uitleesmethode en vergelijk deze met de betreffende doelwaarde of de vastgelegde vorige waarde. Controleer afzonderlijk alle IPsec-verbindingen, de benodigde firewalldiensten en het vastgelegde lokale of centrale datapad opnieuw. Claim bij een onduidelijk of afwijkend uitleesresultaat niet dat het herstel is geslaagd en schakel Sophos Support in.

Het datapad valideren

Een client uit 10.20.0.0/24 opent eerst een openbaar IP-adres en daarna een FQDN via HTTPS. De acceptatietest bewijst meerdere lagen:

1. In het filiaal matcht Branch_LAN_to_VPN; de lokale LAN-to-WAN-dropregel matcht deze succesvolle flow niet.
2. Op het hoofdkantoor matchen Branch_VPN_to_WAN en de gekoppelde MASQ-regel.
3. Het openbaar zichtbare bron-IP-adres hoort bij het hoofdkantoor.
4. DNS, HTTPS en een bewust geblokkeerd doel gedragen zich volgens de centrale policy.
5. Onder Diagnostics > Packet capture tonen In interface, Out interface, Rule ID, NAT ID, Status en Reason heen- en terugpakketten via tunnel en hoofdkantoor-WAN.
6. Systeemgegenereerd verkeer gebruikt het vooraf gekozen lokale of centrale pad.
7. Current activities > IPsec connections blijft tijdens de test actief en de Log viewer toont geen onverwachte drops.
8. Voer bij HA afzonderlijk een goedgekeurde node-failover uit en herhaal de volledige test. Claim zonder die test geen HA-redundantie.

Alleen een Speedtest is niet voldoende. Test ook echte applicaties, DNS, beveiligingslogs en een langere download. Gebruik bij prestatieproblemen de aparte procedures voor internetsnelheidstests en MTU en MSS in VPN.

Typische fouten en rollback

• Filiaalclient gebruikt nog steeds de lokale WAN: controleer regelvolgorde, bronnetwerk, LAN-to-VPN-regel en dropregel. Voeg geen brede uitzondering toe als snelle oplossing.
• Tunnel is groen maar internet werkt niet: controleer op het hoofdkantoor VPN-to-WAN-regel, Rule ID, MASQ, WAN-gateway, DNS en retourpad.
• Alleen de firewall zelf gebruikt het verkeerde pad: controleer policy-based-ipsec-vpn system-generate-traffic. Verwar clientverkeer niet met systeemgegenereerd verkeer.
• Andere tunnels vallen uit na de CLI-wijziging: het herstarten van alle IPsec-tunnels is gedocumenteerd gedrag. Herstel de vorige status en valideer elke tunnel afzonderlijk.
• Tunnel of hoofdkantoor valt uit: dit ontwerp voorziet niet in een automatische lokale internetfallback. Een dergelijke fallback vereist een afzonderlijk gepland beveiligings- en routingpad.
• Een openbaar IP-adres werkt maar een FQDN niet: controleer het DNS-adres van de client, de DNS-regel, het pad naar de centrale resolver en antwoorden. De systeemverkeeroptie telt alleen wanneer de firewall het verzoek genereert.

Bereid voor de rollback eerst boven Branch_LAN_to_WAN_drop een tijdelijke LAN-to-WAN-regel voor die alleen één testclient toestaat. Herstel daarna Route Precedence naar de vastgelegde waarde en controleer het lokale WAN-pad met een nieuwe sessie van die client. Herstel bij een mislukte test onmiddellijk de routevolgorde en regelstatus van de full tunnel via onafhankelijke beheerstoegang. Schakel pas na een geslaagde test de vroegere reguliere LAN-to-WAN-regel in, schakel Branch_LAN_to_WAN_drop uit en verwijder de tijdelijke regel.

Herstel vervolgens de systeemverkeeroptie naar de vorige waarde en controleer alle IPsec-verbindingen, omdat deze wijziging de tunnels herstart. Schakel Branch_LAN_to_VPN, VPN-to-WAN en MASQ alleen uit of verwijder ze als Rule ID, NAT ID en gebruik aantonen dat geen andere flow ervan afhangt. Herstel ten slotte de oorspronkelijke IPsec-selectors of verwijder een tunnel die alleen voor dit pad is gemaakt. Houd de configuratieback-up en onafhankelijke beheerstoegang beschikbaar totdat nieuwe DNS-, HTTPS- en applicatiesessies op beide locaties slagen.

FAQ