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. In actuele SFOS-versies zijn deze begrippen duidelijker gescheiden dan in oudere handleidingen, waarin soms nog over Site-to-Site of Tunnel Interface wordt gesproken.

• Policy-based IPsec: geschikt voor eenvoudige locatieverbindingen met duidelijke lokale en externe netwerken. De verbinding wordt vooral gestuurd via lokale en externe subnetten in de IPsec-verbinding en via firewallregels. Sophos maakt afzonderlijke Phase 2-tunnels voor de combinaties van lokale en externe subnetten.
• Route-based IPsec met Traffic Selectors: gebruikt eveneens lokale en externe subnetten, maar maakt een eigen XFRM-interface. Sophos genereert de route automatisch; aan de XFRM-interface mogen geen IP-adres of eigen routes worden toegewezen. WAF wordt met deze variant niet ondersteund.
• Route-based IPsec Any-to-Any: is de flexibelste variant voor groeiende netwerken, SD-WAN, dynamische routing en dual-stackontwerpen. Routes en firewallregels bepalen dan welke pakketten de tunnel ingaan, niet langer de subnetten in de IPsec-verbinding.

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.

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.

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

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.

Als de CA certificaten vóór de vervaldatum intrekt, hoort ook de actuele intrekkingslijst in het beheerplan. De aparte procedure beschrijft CRL-import, 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 IPsec_IKEv2_AES256_G14. 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.

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.

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 en datapad met een eigen XFRM-interface. Of deze interface zelf een adres en routes krijgt, hangt af van de gekozen variant.

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

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

Network > Interfaces

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

Any-to-Any en Dual

Als beide subnetten op Any staan of Dual wordt gebruikt, krijgt de XFRM-interface een overdrachts-IP. Daarna is een statische route, SD-WAN Route of dynamische route via BGP of OSPF nodig. Voor Dual zijn afzonderlijke IPv4- en IPv6-firewallregels vereist.

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 na het opslaan drie punten:

1. De XFRM-interface is zichtbaar onder Network > Interfaces en geadresseerd met het geplande overdrachts-IP.
2. De route naar het externe netwerk wijst rechtstreeks naar de XFRM-interface of, bij een gateway-/SD-WAN-ontwerp, naar de passende XFRM-gateway.
3. Firewallregels staan alleen de geplande richtingen en services toe.

Traffic Selectors

Bij specifieke Local en Remote subnets maakt Sophos eveneens een XFRM-interface, maar aan deze interface mogen geen IP-adres of eigen routes worden toegewezen. De statische route ontstaat automatisch zodra de tunnel established is. Any aan slechts één zijde en een specifieke Selector aan de andere worden niet ondersteund.

Deze variant is geschikt voor kleine, duidelijk gedefinieerde netwerken en vereenvoudigt XFRM-diagnostiek. WAF via route-based IPsec met Traffic Selectors wordt echter 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 bij IPsec niet verboden, maar moet duidelijk worden gemotiveerd. Typische situaties zijn overlappende netwerken, cloudeisen of externe partijen die alleen bepaalde bronadressen accepteren.

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.

⚠️ Bij route-based IPsec met Traffic Selectors heeft de XFRM-interface geen IP-adres. Als dit verkeer overeenkomt met een MASQ-SNAT-regel, verwerpt de firewall de pakketten. Gebruik daarom bij overlappende netwerken de NAT-instelling in de IPsec-verbinding en zorg dat geen MASQ-SNAT-regel dit verkeer onderschept.

Sinds SFOS 22 maakt policy-based IPsec de VPN-route in de backend. Een handmatige ipsec_route is alleen relevant voor bepaalde vertaalde, doorgestuurde verkeersstromen en is geen standaardstap; door het systeem gegenereerd verkeer heeft deze niet nodig. Meer NAT-basisinformatie staat in Sophos Firewall NAT-regels 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.

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: configureer geen IP of handmatige route op de XFRM-interface. Controleer 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.

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 zijn geen IP of handmatige routes op de XFRM-interface 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 minimaal één test per benodigde richting is gedefinieerd.
• 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