IPsec Site-to-Site met certificaten instellen op Sophos Firewall
Een gedeelde preshared key is snel ingesteld voor één tunnel tussen locaties. Bij meerdere firewalls of strengere PKI-eisen is een digital certificate vaak beter beheersbaar: elke kant heeft een eigen privésleutel, de peers vertrouwen de uitgevende CA’s en een afzonderlijk certificaat kan gericht worden vernieuwd of ingetrokken.
Deze procedure toont een policy-based IPsec-verbinding tussen twee Sophos Firewalls. Ze vult de algemene handleiding voor het instellen van een Site-to-Site IPsec VPN aan. Voor route-based ontwerpen moeten routing en XFRM bovendien worden gepland, maar de hier beschreven vertrouwens- en certificaatprocedure blijft hetzelfde.
De veilige procedure in acht stappen
- Leg tunnelrollen, netwerken, IKEv2-profiel en Certificate ID’s schriftelijk vast.
- Controleer op beide firewalls een configuratiebackup en werkende beheerderstoegang.
- Exporteer de uitgevende CA van elke firewall en importeer deze op de peer.
- Genereer op elke firewall een afzonderlijk lokaal ondertekend certificaat met een unieke Certificate ID.
- Exporteer alleen het openbare certificaat en importeer het op de peer als Remote Certificate.
- Maak aan beide kanten policy-based IPsec met Authentication type > Digital certificate.
- Controleer Device Access en automatisch gegenereerde firewallregels nauwkeurig.
- Valideer tunnelstatus, certificaatvertrouwen, logs en echt verkeer in beide richtingen.
⚠️ Het privésleutelbestand blijft op de firewall waarop het certificaat is gegenereerd. Voor de vertrouwensuitwisseling worden alleen CA-certificaten en openbare peercertificaten overgedragen. Schakel bestaande PSK-tunnels niet uit en vervang geen productiecertificaten zonder geteste tweede beheerderstoegang, een backup en een gedocumenteerde herstelroute.
Voorbeeld en planningswaarden
Het voorbeeld verbindt het hoofdkantoor SF1 met filiaal SF2:
SF1-LAN 192.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 192.20.20.0/24 SF2-LAN
- SF1-WAN:
172.10.10.1 - SF2-WAN:
172.20.20.1 - SF1-certificaat:
SF1_Certificate - SF2-certificaat:
SF2_Certificate - SF1 Certificate ID:
172.10.10.1 - SF2 Certificate ID:
172.20.20.1
Deze adressen en namen zijn documentatiewaarden. Gebruik in de eigen omgeving de werkelijke WAN-adressen, netwerkobjecten en een binnen de hele organisatie uniek ID-schema. De Certificate ID moet blijvend aan de betreffende peer zijn gekoppeld en mag niet worden verward met de weergavenaam of een willekeurige SAN.
Wederzijds CA-vertrouwen instellen
Controleer en download eerst op SF1 de uitgevende CA onder Certificates > Certificate authorities. Als in het voorbeeld de lokale Default-CA wordt gebruikt, geeft u het geëxporteerde bestand een duidelijke naam zoals Head_Office_Default.pem. Importeer het op SF2 onder Certificates > Certificate authorities > Add, bijvoorbeeld als SF1_CA.
Herhaal daarna de procedure in de andere richting: exporteer de CA van SF2, geef deze een duidelijke naam zoals Branch_Office_Default.pem en importeer deze op SF1, bijvoorbeeld als SF2_CA.
De bestandsnamen dienen alleen voor het beheer. Subject, Issuer, Fingerprint, geldigheid en de juiste CA-keten zijn bepalend. Vergelijk deze waarden vóór het importeren via een onafhankelijk kanaal. Certificaten beheren op Sophos Firewall beschrijft de algemene taken voor CA’s, certificaten en servicetoewijzingen.
Genereer de ingebouwde
Default-CA niet terloops opnieuw. Regeneratie wijzigt de Trust Anchor en kan andere portals, TLS-diensten en IPsec-peers beïnvloeden. Importeer voor een bedrijfs-CA in plaats daarvan de volledige vertrouwde keten.
Lokale en externe certificaten voorbereiden
Het lokale certificaat op SF1 maken
Maak op SF1 een certificaat onder Certificates > Certificates > Add > Generate locally-signed certificate. Het Sophos-voorbeeld gebruikt RSA, een Key length van 2048 en SHA-256. Deze waarden vervangen het cryptografie- en geldigheidsbeleid van de organisatie niet; het geselecteerde IPsec-profiel en beide peers moeten ze ondersteunen.
Selecteer onder Subject Alternative Names (SANs) > Advanced settings een Certificate ID. Ondersteunde typen zijn DNS, IP address, Email en DER ASN1 DN [X.509]. Het voorbeeld gebruikt IP address met 172.10.10.1.
Bij DER ASN1 DN [X.509] gebruikt Sophos het Subject van de uitgevende CA. Laat in dit geval DNS names en IP address onder de SANs leeg, omdat extra waarden volgens Sophos een conflict veroorzaken tijdens de IPsec-authenticatie.
Controleer na Save de geldigheid, Issuer, Certificate ID en aanwezigheid van de privésleutel. Exporteer het openbare certificaat, wijzig indien nodig de extensie in .cer en importeer het op SF2 onder Certificates > Certificates > Add > Upload certificate als SF1_Certificate. De kolom Trusted op de peer moet het vertrouwen via SF1_CA bevestigen.
Het lokale certificaat op SF2 maken
Herhaal de procedure op SF2 met een afzonderlijke privésleutel. In het voorbeeld heet het certificaat SF2_Certificate, is de Certificate ID 172.20.20.1 en is de uitgevende CA de lokale CA van SF2.
Importeer het openbare certificaat op SF1. Daar moet Trusted via de eerder geïmporteerde SF2_CA zijn bevestigd. Elke firewall heeft nu precies twee verschillende rollen:
- Local certificate: het eigen certificaat met de privésleutel.
- Remote certificate: het openbare certificaat van de peer, gevalideerd door diens CA.
Een groen vertrouwensvinkje bewijst de certificaatketen, maar niet dat de tunnel werkt. Geldigheid, Certificate ID, IKE-profiel, gateway en netwerken moeten nog steeds overeenkomen. Intrekking en CRL-distributie vormen een afzonderlijk operationeel proces; zie Certificate Revocation Lists op Sophos Firewall.
De IPsec-verbinding aan beide kanten maken
Maak onder Site-to-site VPN > IPsec > Add twee overeenkomende verbindingen. In het voorbeeld wacht het hoofdkantoor op het filiaal:
- Connection type:
Policy-based - Gateway type:
Respond only - Profile:
Head office (IKEv2)of een afgestemde eigen profielkloon - Authentication type:
Digital certificate - Local certificate:
SF1_Certificate - Remote certificate:
SF2_Certificate - Listening interface: WAN van
SF1 - Local subnet:
SF1_LAN - Gateway address: WAN-adres van
SF2 - Remote subnet:
SF2_LAN
Keer de rollen om op het filiaal:
- Gateway type:
Initiate the connection - Profile:
Branch office (IKEv2)of het bijpassende eigen profiel - Local certificate:
SF2_Certificate - Remote certificate:
SF1_Certificate - Local subnet:
SF2_LAN - Gateway address: WAN-adres van
SF1 - Remote subnet:
SF1_LAN
Plan de profielen als paar. IPsec-profielen op Sophos Firewall begrijpen legt uit hoe IKEv2, fase 1, fase 2, PFS, lifetimes en DPD samenwerken.
Device Access en firewallregels controleren
De kant met Gateway type > Respond only moet IPsec-verbindingen op het bedoelde WAN-pad kunnen accepteren. Activeer daarom onder Administration > Device access IPsec alleen voor de werkelijk benodigde WAN-zone of gebruik een beperkte Local Service ACL-exception voor bekende peeradressen. SSO, certificaten of een sterk IPsec-algoritme rechtvaardigen geen brede WebAdmin- of SSH-toegang. Device Access veilig configureren op Sophos Firewall beschrijft de ACL-planning.
Wanneer Create firewall rule is ingeschakeld, maakt SFOS automatisch VPN-regels. Deze regels vormen een startpunt. Controleer onder Rules and policies > Firewall rules de volgorde, richting, bron- en doelnetwerken, diensten en logging en beperk ze vervolgens tot de werkelijke behoefte. Firewallregels maken op Sophos Firewall beschrijft de regelvalidatie.
Ping/Ping6 voor de zone VPN is alleen nodig wanneer bewust een adres van de firewall zelf als testdoel wordt gebruikt. Voor een normale end-to-end-test tussen hosts achter de firewalls hoeft deze lokale dienst niet breed te worden ingeschakeld.
De tunnel en certificaten valideren
De validatie onderscheidt vier niveaus:
- Onder Site-to-site VPN > IPsec zijn de verbinding en tunnel actief.
- Beide firewalls tonen de verwachte Local en Remote Certificate, geldige looptijden en een vertrouwde Issuer.
- Een echte testhost bereikt de bedoelde dienst in het externe netwerk, waarna de omgekeerde richting wordt getest.
- Firewall Rule ID, Packet Capture en IPsec-logs bevestigen hetzelfde pad en dezelfde tijdstempels.
strongswan.log is het belangrijkste startpunt voor IKE- en certificaatfouten. charon.log, ipsec_monitor.log en het verbindingsspecifieke log onder /log/ipsec_conn/ bieden aanvullend bewijs. Sophos Firewall IPsec-troubleshooting behandelt de volledige diagnoseprocedure.
Fouten per symptoom afbakenen
Tunnel blijft down
Controleer eerst of Local certificate en Remote certificate aan beide kanten daadwerkelijk zijn gespiegeld. Controleer vervolgens Certificate ID, Gateway address, IKEv2-profiel, geldigheid en vertrouwensketen. Een geïmporteerd peercertificaat zonder de bijbehorende CA is geen vertrouwde identiteit.
Certificaat is Trusted, maar authenticatie mislukt nog steeds
Trusted bevestigt alleen de keten. Bij DER ASN1 DN [X.509] mogen geen extra DNS- of IP-SAN-waarden de identifier overschrijven. Bij de andere ID-typen moeten waarde, type en verwachte peer exact overeenkomen. Vergelijk in strongswan.log de daadwerkelijk aangeboden en verwachte ID’s van dezelfde verbindingspoging.
Tunnel is groen, maar er stroomt geen verkeer
De certificaatauthenticatie is al geslaagd. Controleer nu lokale en externe subnetten, automatische VPN-regels, Rule ID, NAT, retourroute en de echte doeldienst. Certificaten zonder bewijs opnieuw genereren verbergt in dit foutbeeld alleen de oorspronkelijke toestand.
Certificaat verloopt binnenkort
Bereid het nieuwe lokale certificaat parallel voor, draag het openbare deel over aan de peer en bevestig daar het vertrouwen. Wijzig Local certificate en Remote certificate aan beide kanten alleen tijdens een onderhoudsvenster op gecontroleerde wijze. Houd oude certificaten en CA’s beschikbaar tot de bidirectionele validatie is geslaagd en verwijder of trek ze pas daarna in.
Rollback en beheer
Documenteer vóór de wijziging beide IPsec-verbindingen, certificaatnamen, Fingerprints, Certificate ID’s, geldigheidsperioden en de huidige regelvolgorde. Een Sophos Firewall-configuratiebackup hoort bij de voorbereiding, maar vervangt geen directe hersteltoegang tot de firewall.
Als de validatie mislukt, herstelt u de eerder gebruikte certificaattoewijzingen of activeert u de nog beschikbare PSK-tunnel opnieuw. Verwijder nieuw geïmporteerde peercertificaten of CA’s pas nadat is vastgesteld dat geen andere verbinding of dienst ze gebruikt. Controleer daarna opnieuw de tunnelstatus en een echte teststroom.
In bedrijf hebben certificaten een eigenaar, verloopbewaking en een gepland vernieuwingsvenster nodig. De eerste waarschuwing moet genoeg tijd overlaten voor uitgifte, vertrouwensdistributie, parallel testen en rollback. Een certificaat pas op de vervaldatum vervangen, verandert gepland onderhoud in een VPN-storing.