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 andere fabrikant via een versleutelde tunnel. In de praktijk mislukt zo’n tunnel zelden door één instelling in de interface. Vaker zijn onduidelijke netwerken, verschillende IPsec-profielen, ontbrekende firewallregels, bijzondere NAT-situaties of een vergeten retourpad aan één kant de oorzaak.

Korte procedure: kies het tunneltype, stem profiel en ID’s af, maak de verbinding, routeer bij route-based Any-to-Any de XFRM-interface, stel firewall- en NAT-regels in en test de tunnel met echt verkeer, logs en Packet Capture.

De procedure is geschikt voor Sophos-naar-Sophos- en verbindingen met andere fabrikanten tussen hoofdkantoor, vestiging of cloud gateway. Voor Microsoft Azure en AWS gelden aanvullende providerdetails: Sophos Firewall met Azure VPN Gateway verbinden en Sophos Firewall met AWS Site-to-Site VPN verbinden. Voor Remote Access van individuele gebruikers helpt in plaats daarvan de keuze tussen Sophos Connect en SSL VPN. Als een bestaande tunnel al groen is maar geen verkeer doorlaat, gebruik dan Sophos Firewall IPsec VPN Troubleshooting.

Wanneer uitsluitend twee Sophos Firewalls worden verbonden en het filiaal de tunnel als client naar een statisch bereikbaar hoofdkantoor moet opbouwen, is SSL Site-to-Site VPN een eenvoudiger alternatief. Voor andere fabrikanten, redundantie, dynamische routing of groeiende netwerken blijft route-based IPsec de flexibelere keuze.

Voor meerdere door Sophos Central beheerde firewalls kan een SD-WAN-verbindingsgroep de route-based tunnels, XFRM-interfaces, routes en optionele regels automatisch genereren. Dit vervangt noch de topologieplanning noch de lokale verkeersvalidatie.

Policy-based of route-based kiezen

Voor de configuratie moet worden bepaald of de tunnel policy-based of route-based wordt opgebouwd. Buiten de Sophos-interface wordt route-based ook vaak tunnel-based genoemd. Beide termen beschrijven een tunnel met een eigen XFRM-interface. De soms gebruikte term “root-based” is daarentegen geen VPN-modus.

Sophos adviseert route-based VPN voor nieuwe ontwerpen. Any-to-Any is bijzonder flexibel voor groeiende netwerken, omdat wijzigingen aan routes de tunnel niet verbreken. Wijzigingen aan subnetten of Traffic Selectors onderbreken daarentegen bestaande verbindingen. Beide tunneluiteinden moeten hetzelfde type gebruiken: policy-based aan het ene uiteinde en route-based aan het andere wordt niet ondersteund.

Voor OSPF of BGP via de tunnel is route-based Any-to-Any met geadresseerde XFRM-interfaces de inzichtelijke opbouw. Wie een oudere policy-based oplossing bijwerkt, moet vooraf controleren of VPN-netwerken via redistribute kernel worden aangekondigd; SFOS 22: IPsec-routes en redistribute kernel legt de versiewijziging en het veilige migratiekader uit.

Wat een groene tunnel werkelijk bevestigt

Een status zoals Established bevestigt dat de peers IKE en ten minste één Child SA hebben onderhandeld. De status bevestigt niet dat een route wordt gekozen, de firewallregel overeenkomt, NAT correct is, de peer de retourroute kent of de doelhost antwoordt. Een tunnel kan dus groen zijn zonder bruikbaar verkeer tussen de locaties te transporteren.

Het gegevenspad kan met het volgende denkmodel worden bekeken:

Policy-based
Bron -> Firewallregel -> Local/Remote selector -> Child SA -> Peer -> Retourroute en regel -> Doel

Route-based Any-to-Any
Bron -> Route of SD-WAN Route -> Firewallregel -> XFRM -> Child SA -> Peer -> Retourroute en regel -> Doel

Dit is een diagnostisch model en geen volledige weergave van de interne SFOS-verwerkingsvolgorde. Het onderscheid is voor de acceptatietest toch essentieel: bij policy-based bepaalt het netwerkpaar in de IPsec-verbinding welk verkeer bij de tunnel hoort. Bij route-based Any-to-Any maakt de routing- of SD-WAN-beslissing die selectie.

Vereisten en planningsgegevens

Documenteer vóór de configuratie minimaal de volgende gegevens:

• Lokaal endpoint: WAN-interface van de Sophos Firewall en het adres waarop de tegenpartij deze interface bereikt.
• Remote Gateway: openbaar IP-adres of DNS-hostname van de tegenpartij.
• Gateway type: doorgaans Respond only op het hoofdkantoor en Initiate the connection bij de vestiging.
• IP version: IPv4, IPv6 of Dual. Dual is alleen beschikbaar voor route-based tunnelinterfaces met Any-to-Any als lokaal en extern subnet. Voor Dual moeten IPv4- en IPv6-firewallregels afzonderlijk worden gepland.
• Lokale netwerken: bijvoorbeeld 172.16.10.0/24 en 172.16.20.0/24.
• Externe netwerken: bijvoorbeeld 10.20.30.0/24.
• VPN-type: policy-based of route-based. Het Connection type Host-to-host bestaat ook, maar valt buiten deze handleiding voor locatieverbindingen.
• Listening interface: WAN-interface van de lokale firewall. Hiervoor kan geen bridge interface worden gebruikt.
• IKE-versie: bij voorkeur IKEv2, als de tegenpartij dit ondersteunt.
• Authentication type: Preshared key, Digital certificate of RSA key.
• Local ID en Remote ID: vooral belangrijk bij FQDN, dynamische tegenpartijen, NAT-T of een Wildcard Gateway.
• IPsec-profiel: Encryption, Authentication, DH Group, PFS en Key life.
• Firewallregels: toegestane bronnen, bestemmingen en services.
• NAT: geen NAT of SNAT/DNAT wegens overlappende netwerken of een providereis.
• Beheer: owner, onderhoudsvenster, testplan, monitoring en terugvalpad.

Doorlopend voorbeeld voor beide firewalls

De volgende documentatiewaarden maken de volgende stappen gemakkelijk te volgen. Vervang ze allemaal door uw eigen WAN-adressen, netwerken en namen:

Maak eerst beide LAN-netwerken als netwerkobjecten onder Hosts and services > IP host. Op het hoofdkantoor is 10.10.10.0/24 de Local subnet en 10.20.20.0/24 de Remote subnet; verwissel deze waarden bij de vestiging. Hetzelfde geldt voor de ID’s: de Local ID van de ene zijde moet overeenkomen met de Remote ID die de tegenpartij verwacht. Het transfernetwerk 10.255.0.0/30 wordt alleen gebruikt voor route-based Any-to-Any en mag met geen enkel productie-, VPN- of beheernetwerk overlappen.

⚠️ Een 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 andere NAT verwacht, lijkt de tunnel vaak gezond terwijl applicaties niet werken.

Netwerken, profiel, ID’s en certificaten

Lokale en externe netwerken mogen niet onbedoeld overlappen. Veelgebruikte standaardnetwerken zoals 192.168.0.0/24, 192.168.1.0/24 of hergebruikte vestigingsnetwerken zijn bijzonder problematisch. Bij overlap is een bewust NAT-ontwerp nodig. Aan beide zijden hetzelfde adresbereik gebruiken en dit later “op de een of andere manier” vertalen, levert moeilijk te beheren tunnels op.

Voor nieuwe locaties is daarom een duidelijk IP-adresplan zinvol. Als VLAN’s of zones nog niet correct zijn gemodelleerd, helpt Sophos Firewall-zones en interfaces configureren.

Beide zijden moeten compatibele parameters gebruiken voor Phase 1 en Phase 2. Dit omvat versleuteling, authenticatie, DH Group, PFS en levensduur. Bij verbindingen met firewalls van andere fabrikanten is het vaak het eenvoudigst om eerst een gezamenlijk profiel schriftelijk vast te leggen en daarna beide zijden te configureren.

Met IKEv2 kan Sophos unieke Preshared Keys per combinatie van Local ID en Remote ID gebruiken. Met IKEv1 is dit beperkter, omdat per gatewaycombinatie slechts één PSK geldt. In omgevingen met meerdere tunnels naar dezelfde tegenpartij verdient IKEv2 met duidelijke ID’s daarom de voorkeur.

NAT Traversal is op Sophos Firewall altijd actief. Als één zijde zich achter een router of provider-NAT bevindt, worden ID’s belangrijker omdat het openbare gatewayadres de peer niet eenduidig identificeert. De Local ID van de ene zijde moet overeenkomen met de verwachte Remote ID van de tegenpartij. DNS-, IP- of e-mail-ID’s hoeven niet openbaar oplosbaar te zijn, maar formaat en waarde moeten kruislings overeenkomen.

Sophos Firewall heeft hiervoor geen afzonderlijke NAT-T-schakelaar: De apparaten detecteren NAT automatisch. Zonder NAT gebruiken IKE-onderhandelingen UDP 500 en loopt het dataverkeer als ESP via IP protocol 50. Zodra de firewall een NAT-apparaat detecteert, kapselt ze de verdere IKE- en fase-2-onderhandelingen en ESP-pakketten in UDP 4500 in.

Als Sophos Firewall zelf achter een router staat, moet die router DNAT of port forwarding instellen van het openbare adres naar het privéadres van de Listening interface van de firewall. Voor het NAT-T-pad moeten UDP 500 en UDP 4500 worden toegestaan; native ESP via IP protocol 50 is alleen nodig op een pad zonder NAT. Dit staat los van het latere SNAT- of DNAT-ontwerp voor overlappende netwerken of vertaald dataverkeer.

Bij Digital certificate moeten certificaatformaten en rollen aan beide zijden exact overeenkomen. Sophos ondersteunt geen ECDSA-certificaten voor IPsec-verbindingen; hiervoor zijn RSA-certificaten nodig. Gebruik een openbare CA niet algemeen als Remote CA Certificate, omdat daarmee te veel vertrouwen aan externe certificaten wordt verleend. RSA key is een afzonderlijk Authentication type: beide firewalls wisselen hun openbare sleutels uit en moeten hetzelfde formaat PKCS1 of DNS gebruiken.

Het wijzigen van de lokale CA Default van een Sophos Firewall is een wijziging van de trust anchor, geen cosmetische certificaatwijziging. Peers met een geïmporteerde Default.pem en lokaal ondertekende certificaten moeten gecontroleerd worden gemigreerd. De Sophos Firewall Default CA gecontroleerd vernieuwen legt inventarisatie, onderhoudsvenster, tests en herstel uit.

Wanneer Digital certificate is geselecteerd, is de keuze in het verbindingsformulier niet voldoende. Het CA-vertrouwen, de lokale certificaten, de peercertificaten en de Certificate IDs moeten vooraf worden voorbereid. De volledige procedure wordt beschreven in Op certificaat gebaseerde IPsec Site-to-Site. Als de CA certificaten intrekt voordat deze verlopen, moet ook de actuele intrekkingslijst in het beheerplan worden opgenomen. Een afzonderlijke procedure beschrijft het importeren van een CRL, de controle van nextUpdate en een gecontroleerde negatieve test op Sophos Firewall.

Als een tunnel niet tot stand komt, zijn NO_PROPOSAL_CHOSEN, ID-fouten of authenticatiefouten typische aanwijzingen. Het gedeelte Tunnel testen en problemen oplossen begint met de passende afbakening.

Policy-based IPsec instellen

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

1. IPsec-profiel controleren of maken

Menupad:

Profiles > IPsec profiles

Controleer eerst of een bestaand profiel bij de tegenpartij past. Als een eigen profiel nodig is, geef het dan een duidelijke naam, bijvoorbeeld Branch-Zurich-IKEv2. De naam moet later begrijpelijk blijven als er meerdere tunnels en tegenpartijen bestaan.

Documenteer minimaal:

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

Bij firewalls van andere fabrikanten moet de tegenpartij dezelfde waarden schriftelijk bevestigen. Alleen een screenshot is vaak onvoldoende, omdat afzonderlijke velden per fabrikant anders kunnen heten.

Hoe Phase 1, Phase 2, PFS, lifetimes, rekeying en DPD samenhangen, wordt uitgelegd in IPsec-profielen op Sophos Firewall begrijpen en veilig configureren. Controleer voor activering Dead peer detection: Sophos specificeert Hold of Disconnect voor de reagerende peer en Re-initiate voor de initiator. Een IPsec failover groep verandert dit gedrag en volgt niet dezelfde DPD logica.

2. IPsec-verbinding toevoegen

Menupad:

Site-to-site VPN > IPsec

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

• Naam van de tunnel, bijvoorbeeld branch-zurich
• IP version, meestal IPv4
• Gateway type, bijvoorbeeld Respond only op het hoofdkantoor of Initiate the connection bij de vestiging
• Listening interface als lokale WAN-interface
• Gateway address van de tegenpartij als IP-adres of DNS-hostname
• Authentication type: Preshared key, Digital certificate of RSA key
• Local ID en Remote ID, indien nodig
• IPsec profile
• Local subnet
• Remote subnet

Bij policy-based IPsec mag maximaal één zijde van de Traffic Selectors op Any staan. Bij meerdere specifieke lokale en externe netwerken maakt Sophos voor elke combinatie een Phase 2 SA.

Bij Respond only kan een wildcardadres * nuttig zijn wanneer meerdere vestigingen of dynamische tegenpartijen met het hoofdkantoor verbinden. Dan moet ten minste een Local ID of Remote ID zijn ingesteld; voor een eenduidige toewijzing zijn meestal beide ID’s zinvol. De Local ID van de ene zijde komt overeen met de verwachte Remote ID van de andere. Initiate the connection ondersteunt geen wildcardadres, daarom wordt de tegenpartij daar als IP-adres of DNS-hostname gedefinieerd.

Gebruik voor Preshared Keys een sterke, unieke sleutel en documenteer deze veilig. Een oude standaardsleutel die op meerdere locaties wordt gedeeld, vormt een onnodig operationeel risico.

Maak daarna de verbinding bij de tegenpartij met gespiegelde instellingen. In dit voorbeeld wacht het hoofdkantoor met Respond only op 203.0.113.20; de Local/Remote-netwerken zijn respectievelijk 10.10.10.0/24 en 10.20.20.0/24. De vestiging gebruikt Initiate the connection, Gateway address 198.51.100.10 en verwisselt de Local/Remote-netwerken en -ID’s. Profiel, authenticatie en PSK moeten compatibel zijn. Activeer de verbinding pas nadat beide vermeldingen zijn opgeslagen en de regels zijn gecontroleerd.

De geavanceerde instellingen voor User authentication mode horen alleen bij IKEv1-profielen met XAuth-logica, bijvoorbeeld zeer oude client-serverontwerpen. Voor normale Site-to-Site-verbindingen met IKEv2 mag hieruit geen extra authenticatiestap worden afgeleid. Verouderde Idle Connection-instellingen horen evenmin thuis in een modern beheerontwerp.

3. Tunnel activeren

Bij het opslaan kan Activate on save worden ingesteld. Doe dit in productieomgevingen binnen een vastgelegd onderhoudsvenster, wanneer de tegenpartij bereikbaar is en beide zijden de logs kunnen controleren.

Na het opslaan toont de lijst twee relevante statussen:

• of de verbinding actief is
• of de tunnel daadwerkelijk established is

Een actieve vermelding betekent niet automatisch dat de tunnel is opgebouwd. Bij meerdere lokale of externe netwerken kunnen bovendien meerdere Security Associations bestaan.

Route-based IPsec instellen

Route-based IPsec scheidt VPN-onderhandeling van routeselectie. Met Any-to-Any biedt SFOS een eigen adresseerbare XFRM-interface. Voor specifieke Traffic Selectors spreken de huidige SFOS 22-documenten elkaar tegen over het maken van de interface, zoals hieronder toegelicht.

1. Verbinding als route-based maken

Menupad:

Site-to-site VPN > IPsec

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

2. Any-to-Any of Traffic Selectors implementeren

Voor Any-to-Any toont Sophos de gemaakte XFRM-interface onder de gebruikte fysieke interface in:

Network > Interfaces

Een gemaakte XFRM-interface blijft altijd aan de VPN-zone toegewezen. De twee varianten worden verschillend geconfigureerd.

Any-to-Any met IPv4, IPv6 of Dual

Wanneer Local subnet en Remote subnet beide op Any zijn ingesteld, maakt SFOS automatisch de XFRM-interface voor de route-based IPsec-verbinding. Er hoeft geen afzonderlijke XFRM-interface te worden toegevoegd. Vouw onder Network > Interfaces de als Listening interface gekozen fysieke interface uit en open de gegenereerde XFRM-interface. Wijs in dit voorbeeld 10.255.0.1/30 toe aan het hoofdkantoor en 10.255.0.2/30 aan de vestiging. Met Dual zijn ook afzonderlijke IPv4- en IPv6-firewallregels nodig.

De bewerkbare Name is de weergavenaam. Verwar deze niet met de waarden die SFOS toewijst: Hardware is de recordnaam, IPsec connection is de gekoppelde route-based verbinding en Network zone is altijd VPN. Configureer alleen de adresvelden voor de IP-versie die in de IPsec-verbinding is geselecteerd:

• IPv4/netmask: voer het geplande IPv4-transitadres in en selecteer het subnet.
• IPv6/prefix: voer het geplande IPv6-transitadres en de prefix in.
• Configureer met Dual beide adresfamilies. Als de verbinding alleen IPv4 of alleen IPv6 gebruikt, past SFOS waarden voor de andere versie niet toe.

Behoud onder Advanced settings > Interface settings de standaard-MTU of voer de doelgericht geteste waarde in. SFOS berekent de standaardwaarde door de maximale IPsec-overhead van de MTU van de fysieke interface af te trekken. Schakel Override MSS alleen in en voer alleen een waarde in als het netwerk een andere waarde dan de firewallstandaard vereist; ga niet uit van een niet-gedocumenteerde numerieke standaardwaarde.

Leg vóór de wijziging de huidige naam, adressen, MTU, status en waarde van Override MSS en afhankelijke routes of gateways vast. Open de interface na het opslaan opnieuw en controleer of de toegewezen Hardware, IPsec connection en VPN-zone ongewijzigd zijn. Voer daarna op beide peers Route lookup uit en test echt verkeer in beide richtingen, inclusief een grote overdracht als MTU of MSS is gewijzigd. Zet voor een rollback de vastgelegde veldwaarden en eerdere routes of gateways terug. Deactiveer een nieuw uitgerolde verbinding en verwijder alleen de afhankelijke routes en regels; probeer de gegenereerde XFRM-interface niet afzonderlijk te verwijderen of opnieuw te maken.

Maak vervolgens de route naar de remote LAN aan beide zijden. Voor een eenvoudige statische opstelling, open Routing > Static routes > IPv4 unicast route > Add:

• Hoofdkantoor: Destination 10.20.20.0/24, Interface de lokale XFRM-interface.
• Vestiging: Destination 10.10.10.0/24, Interface de lokale XFRM-interface.

Gebruik als alternatief een SD-WAN Route of dynamische routing via BGP of OSPF. Bepaal voor een SD-WAN Route expliciet of een ander pad als uitwijkroute is toegestaan. Als het verkeer geen andere route mag gebruiken wanneer de tunnel omlaag is, schakel dan Route only through specified gateways in en test deze storingsmodus apart.

Routes en firewallregels bepalen welk verkeer de tunnel ingaat. Een eenvoudige statische route kan rechtstreeks naar de XFRM-interface wijzen. Voor meerdere verbindingen, SLA-controles of bepaalde failoverontwerpen wordt daarnaast een Custom Gateway met het peer-XFRM-IP gemaakt en in een SD-WAN Route gebruikt.

Any-to-Any-tunnels kunnen meerdere XFRM-gateways rechtstreeks via SD-WAN en SLA-controles aansturen; daarvoor is geen extra VPN-failovergroep nodig. Policy-based tunnels en route-based tunnels met Traffic Selectors gebruiken voor redundante verbindingen daarentegen een IPsec-failovergroep. De gekoppelde werkwijze legt de volgorde, Health Check, Automatic failback en de gecontroleerde uitvaltest uit. De groep schakelt DPD voor de toegewezen verbindingen uit en stelt Key negotiation tries in op 3.

Controleer vier punten na het opslaan:

1. De XFRM interface is zichtbaar onder Network > Interfaces en heeft het geplande IP-adres.
2. De route naar het externe netwerk wijst rechtstreeks naar de XFRM interface of, in een gateway/SD-WAN ontwerp, naar de juiste XFRM gateway.
3. Diagnostics > Tools > Route lookup geeft de verwachte XFRM interface of XFRM gateway terug voor een werkelijke host in de remote LAN. Doe dezelfde test op de peer.
4. Firewall regels staan alleen de geplande richtingen en diensten.

Traffic Selectors

Met specifieke subnets is het gedrag van SFOS 22 in dit bijzondere geval niet eenduidig: een XFRM-interface kan ontbreken, maar de firewall kan er ook één per Traffic Selector-configuratie maken. Vouw de Listening interface onder Network > Interfaces uit en controleer de werkelijke toestand op de geïnstalleerde build; een bestaande XFRM-interface kan ook onder Diagnostics > Packet capture worden geselecteerd. Als een XFRM-interface wordt weergegeven, wijs er dan geen IP-adres of routes aan toe. De statische route wordt automatisch gemaakt zodra de tunnel established is. Any aan slechts één kant met een specifieke selector aan de andere kant wordt niet ondersteund.

Deze variant is geschikt voor kleine, duidelijk gedefinieerde netwerken. Gebruik een zichtbare interface zoals gedocumenteerd om uitgaand verkeer in Diagnostics > Packet capture te bevestigen; controleer ook de automatische route, Child SAs, logs en verkeer in beide richtingen. WAF via route-based IPsec met Traffic Selectors wordt niet ondersteund.

Een Any-to-Any-tunnel kan niet rechtstreeks naar specifieke Traffic Selectors worden omgezet. Daarvoor moet de verbinding worden gekloond of opnieuw worden gemaakt en vervolgens gecontroleerd worden omgeschakeld.

3. Rekening houden met XFRM en MTU

Route-based VPN’s zijn gevoeliger voor misverstanden rond routing, MTU en MSS. Als kleine tests werken maar grotere overdrachten blijven hangen, wijzig dan niet direct het IPsec-profiel. Controleer eerst MTU, MSS, fragmentatie en het werkelijke pad. De juiste procedure staat in MTU en MSS op Sophos Firewall controleren bij VPN-problemen.

Firewallregels, NAT en Device Access

Firewallregels en automatische regels

Na de IPsec-configuratie zijn regels voor productie-verkeer nodig. Zonder passende regels kan de tunnel groen blijven terwijl applicaties niet werken.

Menupad:

Rules and policies > Firewall rules

Typische regels:

• Lokaal netwerk naar extern netwerk: bijvoorbeeld van LAN naar VPN.
• Extern netwerk naar lokaal servernetwerk: bijvoorbeeld van VPN naar Server.
• Management of Monitoring: alleen vastgelegde beheer- of monitoringsystemen toestaan.
• DNS, AD, RDP, HTTPS: alleen benodigde services toestaan, niet algemeen Any.

XFRM-interfaces behoren altijd tot de VPN-zone. Als beide richtingen worden gebruikt, zijn passende inbound- en outboundregels nodig. Afzonderlijke regels met logging maken bij de acceptatietest duidelijker welke zijde welke services mag bereiken. De algemene opbouw wordt beschreven in Sophos Firewall-regels maken en veilig controleren.

De optie Create firewall rule maakt afzonderlijke regels met de voorvoegsels Incoming en Outgoing bovenaan de regellijst. Daarna:

• Controleer de regelpositie.
• Beperk Source en Destination verder.
• Beperk Any tot de vereiste Services.
• Activeer Log firewall traffic voor ingebruikname en foutanalyse.
• Kies IPS, Web, Application Control en andere Security Features bewust.
• Geef de regel een begrijpelijke naam, bijvoorbeeld LAN_to_Branch_Zurich.

⚠️ Automatisch gemaakte firewallregels zijn een startpunt, geen voltooid beveiligingsontwerp. Vooral bij locatietunnels naar servernetwerken moeten services, bronnen en bestemmingen na de eerste test worden beperkt.

Voor route-based Any-to-Any kan Sophos geen regels automatisch maken. Bij Dual worden IPv4- en IPv6-regels afzonderlijk gemaakt. Als internetverkeer van een vestiging via het hoofdkantoor moet lopen, is bovendien een eigen NAT- en beveiligingsontwerp nodig.

NAT per tunneltype plannen

NAT is niet verboden met IPsec, maar het moet een duidelijke reden hebben. Typische gevallen zijn overlappende netwerken, cloud-eisen of derden die alleen specifieke bronadressen accepteren. NAT vervangt geen route en verandert de routingbeslissing niet: onafhankelijk van de vertaling moet SFOS een geschikte VPN-, statische, SD-WAN- of dynamische route naar de bestemming kunnen kiezen.

Menupad:

Rules and policies > NAT rules

Beantwoord vóór een NAT-regel deze vragen:

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

De NAT-logica verschilt per VPN-type:

• Bij policy-based IPsec en route-based VPN met Traffic Selectors kan NAT voor overlappende netwerken rechtstreeks in de IPsec-verbinding worden geconfigureerd.
• Bij route-based Any-to-Any worden SNAT- en DNAT-regels onder Rules and policies > NAT rules gebruikt.
• Bij overlappende netwerken moeten beide zijden hetzelfde vertaalplan begrijpen. Eenzijdige NAT zonder planning van het retourpad levert vaak groene tunnels zonder bruikbaar verkeer op.

⚠️ Gebruik bij route-based IPsec met Traffic Selectors de NAT-instelling in de IPsec-verbinding en wijs geen IP-adres of handmatige route toe aan een XFRM-interface als de geïnstalleerde build die toont. IPsec met NAT voor overlappende netwerken toont het volledige gespiegelde adres-, DNS- en NAT-ontwerp.

Als payloadverkeer van policy-based IPsec door een afzonderlijke SNAT-regel wordt vertaald, moet de Outbound interface op Any staan. Een regel die daar alleen specifieke WAN-poorten vermeldt — normaal gesproken de standaard-SNAT-regel — komt niet overeen met dit VPN-verkeer.

Sinds SFOS 22 maakt policy-based IPsec de VPN-route in de backend. Een handmatige ipsec_route is alleen relevant voor bepaalde scenario’s met doorgestuurd verkeer en is geen standaardstap; systeemgegenereerd verkeer heeft deze niet nodig. Meer NAT-basisprincipes staan in NAT-regels van Sophos Firewall begrijpen.

Device Access voor inkomend IPsec

Voor inkomende IPsec-aanvragen moet de firewall IPsec-verkeer op de juiste WAN-zone kunnen accepteren. Dit wordt niet met een normale LAN-naar-WAN-regel geregeld, maar via de lokale services van de firewall.

Menupad:

Administration > Device access

Daar moet IPsec voor WAN zijn toegestaan wanneer de firewall inkomende aanvragen accepteert, bijvoorbeeld met Respond only. Dit vervangt geen regels voor het gebruikersverkeer door de tunnel. Controleer tegelijk of WebAdmin, SSH, User Portal of VPN Portal niet onnodig breed bereikbaar zijn. Voor het beveiligen van deze lokale services is toegang tot Sophos Firewall beveiligen: Device Access correct configureren het centrale artikel.

Tunnel testen en problemen oplossen

Een goede acceptatietest controleert niet alleen de groene status, maar de daadwerkelijke gegevensstroom.

Acceptatiematrix definiëren

Leg vóór de eerste test een kleine acceptatiematrix vast. Zo is duidelijk welke verbinding werkelijk moet werken en welke verbinding bewust niet mag worden toegestaan.

Nuttige 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 tegengestelde richting als de verbinding bidirectioneel wordt gebruikt.
• DNS of AD door de tunnel: test dit alleen als deze services werkelijk 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 onbedoeld Any-regels nodig hebben.
• Niet-toegestane test: een bewust niet-vrijgegeven poort of netwerk moet worden geblokkeerd. Anders is de regelbasis te ruim.
• Grote overdracht: observeer bij bestandsoverdracht, RDP, VoIP of applicatieproblemen ook MTU/MSS en fragmentatie.

Noteer per testgeval Source IP, Destination IP, Service, verwachte firewallregel, verwachte NAT-regel en verwachte richting. Vergelijk na elke test Log Viewer, Packet Capture en bytecounters. Als alleen ping wordt getest, is de tunnel nog niet geaccepteerd.

1. Status controleren

In de WebAdmin-interface:

Site-to-site VPN > IPsec

Controleer:

• De verbinding is actief.
• De tunnelstatus is established.
• Bij meerdere netwerken zijn alle verwachte Child SA’s opgebouwd.

Onder Current activities > IPsec connections filtert u de verbindingen die daadwerkelijk zijn opgebouwd op Connection name, Local subnet of Remote subnet en werkt u de weergave bij met Refresh. Disconnect beëindigt een bestaande SA op een gecontroleerde manier, bijvoorbeeld zodra beide zijden klaar zijn voor een configuratiewijziging; het vervangt niet het uitschakelen of terugrollen van de verbinding.

Bepaal vooraf het verwachte aantal: route-based Any-to-Any maakt één Phase 2-verbinding per XFRM-interface, terwijl Dual er één voor IPv4 en één voor IPv6 maakt. Policy-based en route-based met Traffic Selectors maken één verbinding voor elke combinatie van Local en Remote subnet.

Controleer vóór het eerste payloadverkeer via route-based Any-to-Any het werkelijke adres van de doelhost onder Diagnostics > Tools > Route lookup. Op elke firewall moet het resultaat verwijzen naar de beoogde XFRM interface of XFRM gateway.

2. Log Viewer controleren

Menupad:

Log viewer

Genereer testverkeer met duidelijke Source, Destination en Service. Controleer vervolgens in Log Viewer welke firewallregel overeenkomt en of NAT, Webfilter, IPS of andere modules het verkeer beïnvloeden. De procedure staat in een firewallregel testen met Log Viewer, Policy Test en Packet Capture. Terugkerende rekeys, disconnects en verbindingsfouten worden in de IPsec-logs gecontroleerd en niet uit de actuele SA-status afgeleid.

3. Packet Capture en Advanced Shell

Als Log Viewer onvoldoende is, gebruik dan Packet Capture met een specifiek filter:

Diagnostics > 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 probleem met het retourpad, NAT of de tegenpartij.

Advanced Shell

Open voor diepgaandere troubleshooting via SSH 5. Device Management > 3. Advanced Shell en controleer de actuele SA-status:

ipsec statusall

Daarbij zijn onder meer relevant:

• IKE SA established
• Child SA installed
• lokale en externe Traffic Selectors
• bytecounters in beide richtingen

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

Actuele IPsec-logs

Het actuele SFOS 22-logoverzicht verdeelt de taken:

• strongswan.log: IPsec-service en verbindingen.
• charon.log: IPsec-service en NAT in IPsec-verbindingen.
• ipsec_monitor.log: monitoring van de IPsec-service.
• /log/ipsec_conn/ipsec_<connectionname>.log: activeren, deactiveren en verbinden via WebAdmin.
• xfrmi.log: XFRM-interfaces bij route-based IPsec.
• dgd.log: alleen aanvullend bij VPN-failover, SD-WAN, DGD of Link Load Balancing, niet als algemeen IPsec-log.

Voor de volledige log- en XFRM-diagnostiek volgt u Sophos Firewall IPsec VPN Troubleshooting.

Veelvoorkomende fouten

• Tunnel wordt niet opgebouwd: IKE-versie, profiel, PSK, certificaat, Local ID of Remote ID komt waarschijnlijk niet overeen. Controleer strongswan.log, IPsec-profiel en tegenpartij.
• Phase 1 staat, Phase 2 niet: lokale of externe netwerken of het Phase 2-voorstel komen waarschijnlijk niet overeen. Controleer Traffic Selectors, subnetten en PFS.
• Tunnel is groen, maar geen toegang: waarschijnlijk ontbreekt een firewallregel, NAT, routing of retourpad. Controleer Log Viewer, Packet Capture en routing.
• Slechts één richting werkt: de tegenpartij kent de retourroute niet of NAT is verkeerd. Controleer tegenpartij, NAT-regels en bytecounters.
• Kleine pings werken, applicaties blijven hangen: waarschijnlijk spelen MTU/MSS, fragmentatie of een Security Feature een rol. Controleer MTU/MSS en Packet Capture.
• Route-based Any-to-Any werkt niet: XFRM-IP, gateway, route of firewallregel klopt waarschijnlijk niet. Controleer Network > Interfaces, routing en VPN-zoneregels.
• Route-based met Traffic Selectors werkt niet: controleer of de werkelijke build de XFRM-interface onder de Listening interface toont. Gebruik die zo ja in Packet Capture, maar wijs geen IP-adres of route toe. Controleer ook automatische route, Selectors, VPN-zoneregels en een mogelijke MASQ-regel.
• Meerdere tunnels beïnvloeden elkaar: waarschijnlijk zijn er overlappende netwerken of vergelijkbare Selector-configuraties. Controleer tunnelobjecten, Failover Group en routes.

Terugrollen na mislukte acceptatie

Rol een nieuwe tunnel op een gecontroleerde manier terug in plaats van regels en objecten speculatief te verwijderen:

1. Beëindig onder Current activities > IPsec connections de betrokken SA met Disconnect en schakel de nieuwe IPsec-verbinding uit.
2. Schakel alleen de statische of SD-WAN-routes, NAT-regels en firewallregels uit die voor deze wijziging zijn gemaakt, inclusief automatisch gegenereerde VPN-regels. Verwijder een gegenereerde XFRM-interface niet afzonderlijk als de build die toont; het uitschakelen van de verbinding beheert die interface.
3. Wijs bij een migratie het vorige profiel opnieuw toe aan de oude verbinding en activeer daarna de verbinding en het oude routingpad weer.
4. Test de oorspronkelijke teststroom en lokaal internet- of locatieverkeer opnieuw met Log Viewer en Packet Capture.
5. Verwijder nieuwe objecten pas nadat Object Usage geen verdere afhankelijkheid toont en aantoonbaar is dat het oude pad weer werkt.

Checklist

Voor de wijziging:

• Lokale en externe netwerken zijn eenduidig.
• Policy-based of route-based is bewust gekozen.
• Het IPsec-profiel is met de tegenpartij afgestemd.
• Preshared Key, certificaten of RSA-sleutels zijn veilig gedocumenteerd.
• Firewallregels zijn gepland, inclusief richting, regelpositie, logging en services.
• Bij Create firewall rule is duidelijk welke automatisch gemaakte regels moeten worden aangepast.
• Voor route-based Any-to-Any zijn XFRM-IP, gateway, handmatige firewallregels en routes gepland.
• Voor route-based Traffic Selectors is de werkelijke XFRM-zichtbaarheid vastgelegd; ongeacht de weergave zijn geen XFRM-IP of handmatige routes gepland.
• NAT is uitgesloten of bewust gedocumenteerd.
• Device Access voor inkomend IPsec is gecontroleerd.
• Onderhoudsvenster, tegenpartij en terugvalpad zijn bekend.

Na de wijziging:

• De tunnelstatus is established.
• Een acceptatiematrix met ten minste één test per vereiste richting is voltooid en goedgekeurd.
• Log Viewer toont de verwachte firewallregel.
• Packet Capture toont heen- en retourrichting.
• Interne DNS- en applicatietoegang zijn getest.
• De bytecounters nemen in beide richtingen toe.
• NAT en retourpad zijn met de tegenpartij afgestemd.
• De wijziging is in de netwerkdocumentatie bijgewerkt.

Veelgestelde vragen