Sophos Firewall Site-to-Site IPsec VPN instellen

Een Site-to-Site IPsec VPN verbindt twee locaties, of een Sophos Firewall met een firewall van een derde partij, via een versleutelde tunnel. In de praktijk mislukt zo’n tunnel zelden door één enkele optie in de interface. Vaker gaat het om onduidelijke netwerken, verschillende IPsec-profielen, ontbrekende firewallregels, NAT-uitzonderingen of een retourpad dat aan één kant is vergeten.

Dit artikel legt uit hoe men een Site-to-Site IPsec-tunnel op Sophos Firewall schoon opbouwt. De focus ligt op planning, uitvoering en acceptatietest. Als een bestaande tunnel al groen is maar er geen verkeer loopt, is Sophos Firewall IPsec VPN Troubleshooting het betere vervolgartikel.

Wanneer dit artikel past

Dit artikel past bij klassieke locatieverbindingen, bijvoorbeeld:

• Hoofdlocatie naar filiaal
• Sophos Firewall naar Sophos Firewall
• Sophos Firewall naar firewall van een derde partij
• Sophos Firewall naar cloud gateway wanneer geen speciale cloud-assistent wordt gebruikt
• Migratie van eenvoudige oude policy-based tunnels naar een gedocumenteerde actuele configuratie

Voor Microsoft Azure of AWS zijn er ook eigen artikelen met de leveranciersspecifieke valkuilen: Sophos Firewall verbinden met Azure VPN Gateway en Sophos Firewall verbinden met AWS Site-to-Site VPN.

Het gaat niet om Remote Access voor individuele gebruikers. Daarvoor passen de artikelen Sophos Connect op Sophos Firewall configureren, Sophos Connect of SSL VPN: welke Remote Access-oplossing past? en Legacy Remote Access IPsec vóór SFOS 22 MR1 migreren.

Policy-based of route-based IPsec

Voor de configuratie moet worden beslist of de tunnel policy-based of route-based wordt opgebouwd. In actuele SFOS-versies zijn deze begrippen duidelijker gescheiden dan in oudere handleidingen, die deels nog over Site-to-Site of Tunnel Interface spreken.

• Policy-based IPsec: past bij eenvoudige locatieverbindingen met duidelijke lokale en externe netwerken. Wordt primair gestuurd via lokale en externe subnetten in de IPsec-verbinding en via firewallregels. Sophos maakt hierbij afzonderlijke Phase 2-tunnels voor de combinaties van lokale en externe subnetten.
• Route-based IPsec met traffic selectors: gebruikt ook lokale en externe subnetten, maar maakt een eigen XFRM-interface voor de verbinding aan. Dit vergemakkelijkt debuggen en scheidt de tunnel beter van andere IPsec-verbindingen.
• Route-based IPsec Any-to-Any: de meest flexibele variant voor groeiende netwerken, SD-WAN, dynamische routing en dual-stack-ontwerpen. Routes en firewallregels bepalen dan welke pakketten de tunnel in gaan, niet meer de subnetten in de IPsec-verbinding.

Voor kleine, stabiele verbindingen is policy-based IPsec vaak het snelst te begrijpen. Voor grotere of dynamische locatienetwerken is route-based IPsec meestal schoner, omdat routing en VPN-onderhandeling beter gescheiden zijn. Als meerdere netwerken, SD-WAN, BGP, OSPF of cloudnetwerken betrokken zijn, moet route-based IPsec bij voorkeur worden onderzocht.

Vereisten

Voor het instellen moet deze informatie gedocumenteerd zijn:

• Local gateway: WAN-IP of FQDN van de lokale Sophos Firewall.
• Remote gateway: publiek IP of FQDN van de tegenpartij.
• Lokale netwerken: 172.16.10.0/24, 172.16.20.0/24.
• Externe netwerken: 10.20.30.0/24.
• VPN-type: policy-based of route-based. Het connection type Host-to-host bestaat ook, maar is niet de focus van deze locatiehandleiding.
• Listening interface: WAN-interface van de lokale firewall. Een bridge interface kan hiervoor niet worden gebruikt.
• IKE-versie: IKEv2 als de tegenpartij dit ondersteunt.
• Authenticatie: Preshared Key of certificaat.
• IPsec-profiel: Encryption, authentication, DH group, PFS, key lifetime.
• Firewallregels: toegestane bronnen, doelen en services.
• NAT: geen NAT, SNAT/DNAT vanwege overlappende netwerken of providervereiste.
• Beheer: owner, onderhoudsvenster, testplan, monitoring, fallbackpad.
• Gateway type: initiate connection of respond only, afhankelijk van welke zijde de tunnel opent.
• IP version: IPv4, IPv6 of Dual als beide zijden dit expliciet ondersteunen.
• Local ID en Remote ID: nodig als authenticatie niet alleen van het publieke IP-adres mag afhangen.

⚠️ Site-to-Site VPN mag niet zonder gedocumenteerd retourpad worden geïmplementeerd. Als de lokale firewall verkeer de tunnel instuurt, maar de tegenpartij geen route terug kent of NAT anders verwacht, ziet de tunnel er vaak gezond uit terwijl applicaties niet werken.

Voor de configuratie plannen

Netwerken eenduidig houden

Lokale en externe netwerken mogen elkaar niet onbedoeld overlappen. Vooral veelgebruikte standaardnetwerken zoals 192.168.0.0/24, 192.168.1.0/24 of hergebruikte filialenetwerken zijn problematisch. Als netwerken overlappen, is een bewust NAT-ontwerp nodig. Gewoon hetzelfde adresbereik aan beide kanten gebruiken en later “op de een of andere manier” vertalen, levert tunnels op die moeilijk te onderhouden zijn.

Voor nieuwe locaties loont daarom een schoon IP-adresconcept. Als VLANs of zones nog niet netjes zijn gemodelleerd, helpt Sophos Firewall zones en interfaces configureren.

IPsec-profiel afstemmen

Beide kanten moeten bij Phase 1 en Phase 2 compatibele parameters gebruiken. Daartoe behoren versleuteling, authenticatie, DH group, PFS en lifetime. Bij verbindingen met firewalls van derden is het vaak het eenvoudigst om eerst een gezamenlijk profiel schriftelijk vast te leggen en daarna beide kanten te configureren.

Als een tunnel niet opkomt, zijn NO_PROPOSAL_CHOSEN, ID-fouten of authenticatiefouten typische aanwijzingen. De gestructureerde analyse staat in Sophos Firewall IPsec VPN Troubleshooting.

Firewallregels niet vergeten

Een IPsec-tunnel geeft nog geen productieve toegang. Verkeer door de tunnel heeft nog steeds passende firewallregels nodig. Bij policy-based verbindingen zijn dat meestal regels tussen LAN en VPN of tussen eigen zones. Bij route-based designs behoort de XFRM-interface tot de VPN-zone; routes en firewallregels bepalen daarna welk verkeer daadwerkelijk door de tunnel mag.

Voor de introductie moet Log firewall traffic in de betrokken regels worden geactiveerd. Anders ontbreekt later precies de informatie welke regel een test heeft toegestaan of geblokkeerd. De algemene controle staat in firewallregel testen met Log Viewer, Policy Test en Packet Capture.

Automatisch gemaakte regels bewust controleren

Bij het maken van een Site-to-Site IPsec-verbinding kan de optie Create firewall rule helpen om een eerste regelset aan te leggen. Dat vervangt geen security review. Sophos Firewall maakt deze regels bovenaan de firewallregellijst. In actuele SFOS-versies ontstaan daarvoor afzonderlijke regels voor inkomend en uitgaand verkeer met de prefixen Incoming en Outgoing.

Voor beheer is daarom belangrijk:

• Regelpositie: Automatisch gemaakte regels na het opslaan naar de juiste plaats verplaatsen.
• Richting: Inkomende en uitgaande regel apart controleren, niet alleen de tunnelnaam.
• Bronnen en doelen: Lokale en externe netwerken strakker instellen als de assistent ze te breed maakt.
• Services: Any alleen voor de eerste test gebruiken en daarna beperken tot benodigde services.
• Logging: Tijdens introductie en foutanalyse activeren.
• Security Features: IPS, Web, Application Control of NDR bewust instellen, niet toevallig overnemen.

⚠️ Automatisch gemaakte firewallregels zijn een startpunt, geen afgerond security design. Vooral bij locatietunnels naar servernetwerken moet men na de eerste test services, bronnen en doelen beperken.

Bij route-based IPsec met Any-to-Any-subnetten moet men bijzonder zorgvuldig werken. Voor zulke route-based designs kunnen geen automatische firewallregels worden gemaakt. Bij dual IP-versies moeten IPv4- en IPv6-regels apart worden gepland. In deze scenario’s moeten firewallregels, XFRM-interface, routes en tests bewust handmatig worden opgebouwd.

Policy-based IPsec instellen

Policy-based IPsec is de klassieke variant voor eenvoudige Site-to-Site-verbindingen. De lokale en externe netwerken worden direct in de IPsec-verbinding gedefinieerd.

1. IPsec-profiel controleren of maken

Menu path:

Profiles > IPsec profiles

Eerst controleren of een bestaand profiel bij de tegenpartij past. Als een eigen profiel nodig is, moet het duidelijk worden benoemd, bijvoorbeeld IPsec_IKEv2_AES256_G14. De naam moet later begrijpelijk blijven wanneer meerdere tunnels en tegenpartijen bestaan.

Minimaal te documenteren:

• IKE-versie
• Phase 1 Encryption en Authentication
• DH Group
• Phase 2 Encryption en Authentication
• PFS
• Key lifetime

Bij firewalls van derden moet de tegenpartij dezelfde waarden schriftelijk bevestigen. Alleen een screenshot is vaak niet genoeg, omdat afzonderlijke velden per fabrikant anders heten.

2. IPsec-verbinding toevoegen

Menu path:

Site-to-site VPN > IPsec

Maak een nieuwe IPsec-verbinding en kies Policy-based als Connection type. Stel daarna de basisgegevens in:

• Naam van de tunnel, bijvoorbeeld branch-zurich
• Local gateway of Listening interface
• Remote Gateway als IP-adres of FQDN
• Authentication type: Preshared Key of certificaat
• Local ID en Remote ID indien nodig
• IPsec profile
• Local subnet
• Remote subnet

NAT Traversal is op Sophos Firewall altijd actief. Als één kant achter een router of provider-NAT staat, worden Local ID en Remote ID nog belangrijker, omdat het publieke gatewayadres alleen niet meer genoeg is voor zuivere peer-identificatie. DNS-, IP- of e-mail-ID’s hoeven niet publiek te resolven; ze moeten alleen aan beide kanten overeenkomen en een geldig formaat gebruiken.

Voor Preshared Keys moet een sterke, unieke sleutel worden gebruikt en veilig worden gedocumenteerd. Een gedeelde oude standaardsleutel voor meerdere locaties is een onnodig operationeel risico.

De geavanceerde instellingen voor User authentication mode horen alleen bij IKEv1-profielen met XAuth-logica, bijvoorbeeld zeer oude client-serverontwerpen. Voor normale site-to-siteverbindingen met IKEv2 moet men dit niet als extra authenticatiestap zien. Verouderde idle connection-instellingen moeten ook niet als modern operationeel ontwerp worden ingepland.

3. Tunnel activeren

Bij het opslaan kan Activate on save worden ingesteld. In productieomgevingen moet dit gebeuren in een gedefinieerd onderhoudsvenster, wanneer de tegenpartij bereikbaar is en beide kanten logs kunnen controleren.

Na het opslaan toont de lijst twee relevante statussen:

• of de verbinding actief is
• of de tunnel daadwerkelijk established is
• IP version, meestal IPv4.
• Gateway type, meestal initiate connection aan de zijde met een gedefinieerde remote gateway.

Een actieve vermelding is niet automatisch een opgebouwde tunnel. Bij meerdere lokale of externe netwerken kunnen er bovendien meerdere Security Associations zijn.

Route-based IPsec instellen

Route-based IPsec scheidt VPN-onderhandeling en routing duidelijker. Sophos Firewall maakt daarbij een XFRM-interface. Daarna bepalen statische routes, SD-WAN Routes of dynamische routing welk verkeer door de tunnel loopt.

1. Verbinding als route-based maken

Menu path:

Site-to-site VPN > IPsec

Kies bij de verbinding Route-based (Tunnel interface). De parameters voor gateway, authenticatie, IDs en IPsec-profiel moeten nog steeds bij de tegenpartij passen. Daarnaast moet duidelijk zijn welke XFRM-interface daarna ontstaat en hoe die wordt gerouteerd.

Sophos toont de gegenereerde XFRM-interface onder de gebruikte fysieke interface in:

Network > Interfaces

Afhankelijk van het design heeft de XFRM-interface een IP-adres nodig. Vooral bij Any-to-Any-designs, dual IP-versie of complexere routingscenario’s moet de interface-adressering schoon worden gepland. De XFRM-interface blijft toegewezen aan de VPN-zone; deze zonetoewijzing is geen vrij ontwerpveld zoals bij normale fysieke interfaces.

Wanneer Any-to-Any wordt gebruikt, beslist niet langer alleen de Tunnel Selector welk verkeer door de tunnel gaat. Routes en firewallregels worden dan de centrale sturing. Dat is flexibel, maar ook foutgevoelig: een te brede regel kan meer verkeer toestaan dan bedoeld, een ontbrekende route kan de tunnel groen laten lijken zonder dat gebruikersverkeer loopt.

2. Routing instellen

Bij route-based VPN is de IPsec-verbinding alleen niet genoeg. Er is een route naar het externe netwerk nodig:

• statische route naar de XFRM-interface
• SD-WAN Route met passende gateway of profiel
• dynamische route via BGP of OSPF als het design daarvoor is gebouwd
• Als beide subnetten op Any staan, bepaalt routing welk verkeer de tunnel ingaat.
• Als specifieke traffic selectors worden gebruikt, moeten ze exact overeenkomen met de peer.

1. XFRM-interface bestaat en bevindt zich in de juiste zone.
2. Route naar het externe netwerk wijst naar de XFRM-interface.
3. Firewallregels staan het vereiste verkeer tussen de juiste zones toe.

Voor eenvoudige setups is een statische route vaak voldoende. Als meerdere WAN-lijnen, SLA-controles of failoverpaden worden gebruikt, is een SD-WAN Route zinvoller. De algemene context rond SD-WAN, Reply Packets en systeemgegenereerd verkeer staat in Sophos Firewall SD-WAN routing voor Reply Packets en System Traffic controleren.

3. XFRM en MTU meenemen

Route-based VPNs zijn gevoeliger voor misverstanden rond routing, MTU en MSS. Als kleine tests werken maar grotere transfers blijven hangen, moet men niet meteen het IPsec-profiel wijzigen. Eerst MTU, MSS, fragmentatie en het echte pad controleren. De passende procedure staat in Sophos Firewall MTU en MSS bij VPN-problemen controleren.

Firewallregels maken

Na de IPsec-configuratie zijn regels nodig voor productief verkeer. Zonder passende regels blijft de tunnel mogelijk groen, maar werken applicaties niet.

Menu path:

Rules and policies > Firewall rules

Typische regels:

• Lokaal netwerk naar extern netwerk: LAN naar VPN of doelzone.
• Extern netwerk naar lokaal servernetwerk: VPN of XFRM-zone naar Server.
• Management of Monitoring: alleen gedefinieerde admin- of monitoringsystemen.
• DNS, AD, RDP, HTTPS: alleen benodigde services, niet algemeen Any.

Goede praktijk:

• Regelnaam met tunnel of locatie, bijvoorbeeld LAN_to_Branch_Zurich.
• Source en Destination zo smal mogelijk instellen.
• Services concreet definiëren.
• Logging tijdens introductie en troubleshooting activeren.
• Regelpositie controleren.
• Beschermingsfuncties bewust instellen in plaats van ze toevallig over te nemen.

Als internetverkeer van een filiaal via de centrale moet lopen, is daarnaast een bewust NAT- en securityconcept nodig. Dat is een ander design dan een eenvoudige locatieverbinding voor interne netwerken.

NAT bewust plannen

NAT is bij IPsec niet verboden, maar het moet duidelijk gemotiveerd zijn. Typische gevallen zijn overlappende netwerken, cloudvereisten of derde partijen die alleen bepaalde bronadressen accepteren.

• Bij overlappende netwerken is NAT vaak niet optioneel, maar onderdeel van het tunnelontwerp.
• Bij route-based Any-to-Any bepalen routing en firewallregels sterker welk verkeer de tunnel ingaat.
• Bij policy-based IPsec en route-based VPN met traffic selectors wijzigt NAT de adressen voordat ze met de selectors worden vergeleken.

Menu path:

Rules and policies > NAT rules

Voor een NAT-regel moeten deze vragen beantwoord zijn:

• Verwacht de tegenpartij originele IP-adressen of vertaalde adressen?
• Zijn er overlappende netwerken?
• Wordt NAT in de IPsec-verbinding opgelost of via afzonderlijke NAT-regels?
• Is de retourrichting gedocumenteerd?
• Toont Log Viewer na NAT de verwachte Source en Destination?

Voor policy-based uitzonderingen met NAT kan een handmatige IPsec Route op Sophos Firewall relevant worden. Dat is echter geen standaardstap voor elke tunnel.

Device Access en WAN-toegang

Voor inkomende IPsec-aanvragen moet de firewall IPsec-verkeer op de passende WAN-zone kunnen accepteren. Dat wordt niet via een normale LAN-to-WAN-regel opgelost, maar via de lokale services van de firewall.

Menu path:

Administration > Device access

Daar moet IPsec voor de benodigde zone zijn toegestaan. Tegelijk moet worden gecontroleerd of andere lokale services zoals WebAdmin, SSH, User Portal of VPN Portal onnodig breed bereikbaar zijn. Voor het hardenen van deze lokale services is Sophos Firewall-toegang beveiligen: Device Access correct configureren het centrale artikel.

Tunnel testen

Een goede acceptatietest controleert niet alleen de groene status. Hij controleert de daadwerkelijke datastroom.

Acceptatiematrix definiëren

Voor de eerste test moet een kleine acceptatiematrix vaststaan. Daardoor is duidelijk welke verbinding echt moet werken en welke verbinding bewust niet toegestaan mag zijn.

Zinvolle testgevallen:

• Lokaal clientnetwerk naar extern servernetwerk: typische applicatietest, bijvoorbeeld HTTPS, RDP, SMB, SQL of ICMP alleen als basistest.
• Extern clientnetwerk naar lokaal servernetwerk: controleer de tegenrichting als de verbinding bidirectioneel wordt gebruikt.
• DNS of AD via de tunnel: alleen testen als deze diensten echt door de tunnel moeten lopen. Leg source, doelserver en poort concreet vast.
• Monitoring of backup: controleer of geplande systemen vanuit de juiste richting toegang krijgen en niet per ongeluk Any-regels nodig hebben.
• Niet-toegestane test: een bewust niet vrijgegeven poort of netwerk moet worden geblokkeerd. Anders is de regelbasis te breed.
• Grote overdracht: let bij bestandsoverdracht, RDP, VoIP of applicatieproblemen ook op MTU/MSS en fragmentatie.

Noteer per testgeval source IP, destination IP, service, verwachte firewallregel, verwachte NAT-regel en verwachte richting. Na elke test vergelijk je Log Viewer, Packet Capture en byte-tellers. Als alleen ping is getest, is de tunnel nog niet geaccepteerd.

1. Status controleren

In de WebAdmin-interface:

Site-to-site VPN > IPsec

Controleren:

• Verbinding is actief.
• Tunnelstatus is established.
• Bij meerdere netwerken zijn alle verwachte Child SAs opgebouwd.
• Geen terugkerende reconnects of fouten zichtbaar.

2. Log Viewer controleren

Menu path:

Log viewer

Testverkeer met duidelijke Source, Destination en Service genereren. Daarna in Log Viewer controleren welke firewallregel matcht en of NAT, Webfilter, IPS of andere modules het verkeer beïnvloeden.

3. Packet Capture gebruiken

Als Log Viewer niet genoeg is, moet Packet Capture met een smal filter worden gebruikt:

Diagnostics > Tools > Packet capture

Filtervoorbeeld:

host 172.16.10.25 and host 10.20.30.15

Bij VPN-troubleshooting is het belangrijk beide richtingen te controleren. Alleen uitgaande pakketten zonder antwoord wijzen meestal op een retourpad-, NAT- of tegenpartijprobleem.

4. CLI alleen gericht gebruiken

Voor diepere analyse kan via SSH de Advanced Shell worden gebruikt:

ipsec statusall

Daarbij zijn onder andere interessant:

• IKE SA established
• Child SA installed
• lokale en externe netwerken
• byte-tellers in beide richtingen
• terugkerende rekey- of disconnect-meldingen

Als SSH nog niet is voorbereid, helpt via SSH verbinden met Sophos Firewall.

Typische fouten

• Tunnel komt niet op: IKE-versie, profiel, PSK, certificaat, Local ID of Remote ID past niet. strongswan.log, IPsec-profiel, tegenpartij.
• Phase 1 staat, Phase 2 niet: lokale/externe netwerken of Phase 2 proposal passen niet. Traffic Selectors, subnetten, PFS.
• Tunnel is groen, maar geen toegang: firewallregel, NAT, routing of retourpad ontbreekt. Log Viewer, Packet Capture, routing.
• Slechts één richting werkt: tegenpartij kent retourroute niet of NAT is fout. tegenpartij, NAT-regels, byte-tellers.
• Kleine pings werken, applicaties blijven hangen: MTU/MSS, fragmentatie of Security Feature. MTU/MSS controleren, Packet Capture.
• Route-based tunnel werkt onduidelijk: XFRM-interface, route of SD-WAN Route past niet. Network > Interfaces, routing, SD-WAN.
• Meerdere tunnels beïnvloeden elkaar: overlappende netwerken of vergelijkbare Selector-configuratie. tunnelobjecten, failover group, routes.

Checklist

Voor de change:

• Lokale en externe netwerken zijn eenduidig.
• Policy-based of route-based is bewust gekozen.
• IPsec-profiel is met de tegenpartij afgestemd.
• Preshared Key of certificaten zijn veilig gedocumenteerd.
• Firewallregels zijn gepland, inclusief richting, regelpositie, logging en services.
• Bij Create firewall rule is duidelijk welke automatisch gemaakte regels moeten worden nabewerkt.
• Bij route-based Any-to-Any zijn handmatige firewallregels en routes gepland.
• NAT is uitgesloten of bewust gedocumenteerd.
• Device Access voor IPsec is gecontroleerd.
• Onderhoudsvenster, tegenpartij en fallbackpad zijn bekend.

Na de change:

• Tunnelstatus is established.
• Log Viewer toont de verwachte firewallregel.
• Packet Capture toont heen- en retourrichting.
• Interne DNS- en applicatietoegang is getest.
• Byte-tellers stijgen in beide richtingen.
• NAT en retourpad zijn met de tegenpartij afgestemd.
• Wijziging is in de netwerkdocumentatie bijgewerkt.
• Acceptatiematrix met minstens één test per vereiste richting gedefinieerd.

Veelgestelde vragen