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 voor policy-based IPsec. Voor nieuwe of groeiende ontwerpen is route-based Any-to-Any met XFRM en expliciete routing vaak flexibeler. 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.

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 gedocumenteerd retourpad en onderhoudsvenster.

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. Zonder correct retourpad en NAT kan de tunnel groen zijn terwijl internetverbindingen geen antwoord ontvangen.

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
• 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.

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.

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. Packet Capture toont heen- en terugpakketten via tunnel en hoofdkantoor-WAN.
6. Systeemgegenereerd verkeer gebruikt het vooraf gekozen lokale of centrale pad.

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.

Schakel bij rollback eerst Branch_LAN_to_WAN_drop uit en herstel gecontroleerd het eerder toegestane lokale internetpad. Verwijder daarna VPN-to-WAN- en MASQ-regels alleen als geen andere flow ze nodig heeft. Herstel Route Precedence en de systeemverkeeroptie exact naar de gedocumenteerde vorige waarden en test vervolgens beide locaties opnieuw.

FAQ