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 retourpad 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

Daarna volgt een gerichte regel Branch_LAN_to_WAN_drop voor hetzelfde filiaalnetwerk van LAN naar WAN. Deze voorkomt dat een te brede lokale internetregel het geplande tunnelpad omzeilt. 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 standaardwaarde is enable. Omdat een bestaand systeem daarvan kan afwijken, toont deze alleen-lezenopdracht in de Device Console eerst de huidige status:

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:

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

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

Herstel bij rollback de gedocumenteerde vorige status. Als de optie eerder actief was, wordt deze opdracht gebruikt:

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

Test na elke wijziging alle IPsec-verbindingen en vereiste firewalldiensten opnieuw.

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: het standaardontwerp heeft geen lokale internetbreakout. 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