Sophos Firewall IPsec-profielen begrijpen en veilig configureren

Een IPsec-profiel bepaalt hoe veilig en onder welke voorwaarden een IPsec-tunnel wordt onderhandeld. Het legt de IKE-versie, versleuteling, integriteit, DH-groep, PFS, lifetimes, rekeying en Dead Peer Detection vast. Als deze waarden niet bij de tegenpartij passen, blijft de tunnel down of valt deze pas bij een latere rekey uit.

Korte aanbeveling voor nieuwe Site-to-Site-verbindingen: gebruik IKEv2, bied alleen de daadwerkelijk benodigde sterke proposals aan, activeer PFS en rekeying en configureer DPD passend bij de rol. Als beide tegenpartijen de waarden ondersteunen, is AES256GCM16 met DH19 en PFS19 een modern uitgangspunt. De vereisten van de provider en de tegenpartij hebben echter altijd voorrang.

Dit artikel legt het profiel uit. De eigenlijke verbinding met gateway, ID’s, netwerken, regels, NAT en routing wordt beschreven in Sophos Firewall Site-to-Site IPsec VPN instellen. Als een bestaande tunnel niet tot stand komt of geen verkeer doorlaat, gebruik dan Sophos Firewall IPsec VPN Troubleshooting.

Wat een IPsec-profiel regelt

Het profiel bevat de gemeenschappelijke beveiligingsparameters voor Phase 1 en Phase 2. Een profiel kan aan meerdere verbindingen worden toegewezen. Juist daarom mag een gebruikt systeem- of productieprofiel niet zomaar worden gewijzigd: de wijziging kan bij de volgende opbouw of rekey alle gekoppelde tunnels treffen.

Niet tot het profiel behoren:

openbaar peeradres of FQDN
Preshared Key, certificaat of RSA Key
Local ID en Remote ID
lokale en externe netwerken of Traffic Selectors
firewallregels, NAT en routing
XFRM-adres, SD-WAN Route of failoverpad

Deze waarden worden in de IPsec-verbinding of de bijbehorende netwerkregels geconfigureerd. Een groene Phase 1-status bewijst daarom niet dat Phase 2 klopt of dat het gebruikersverkeer correct wordt gerouteerd en toegestaan.

Authentication is niet hetzelfde als Authentication type

In een IPsec-profiel verwijst Authentication naar het integriteitsalgoritme, zoals SHA2 256. In de IPsec-verbinding bepaalt Authentication type daarentegen of de tegenpartijen zich identificeren met een Preshared Key, certificaat of RSA Key.

Deze twee velden hebben verschillende functies. Een correct SHA2 256 herstelt daarom geen verkeerde PSK en een passend certificaat compenseert geen incompatibel Phase 1-proposal.

Phase 1 en Phase 2 begrijpelijk uitgelegd

Phase 1 bouwt de beveiligde IKE Security Association op. Via dit besturingskanaal authenticeren de tegenpartijen zich en onderhandelen ze verdere sleutels en parameters. Daarvoor moeten ten minste de IKE-versie, versleuteling, integriteit en DH-groep compatibel zijn.

Phase 2 maakt de Child of IPsec Security Associations voor het eigenlijke gebruikersverkeer. Hier gelden de Phase 2-versleuteling, integriteit, PFS en de Traffic Selectors. Een tunnel kan Phase 1 dus succesvol afronden, terwijl door een verkeerde PFS-waarde of een afwijkende Phase 2-combinatie geen Child SA ontstaat.

Bij IKEv2 kan de eerste Child SA al samen met de IKE SA worden opgebouwd. Daardoor wordt een PFS- of rekeyprobleem mogelijk pas uren later zichtbaar wanneer de Child SA moet worden vernieuwd. Een acceptatietest is pas volledig nadat ten minste één rekey zonder onderbreking is waargenomen.

Parameters met de tegenpartij afstemmen

Voor de configuratie worden de waarden schriftelijk tussen beide beheerders afgestemd. Een screenshot is vaak niet voldoende, omdat fabrikanten dezelfde functie anders benoemen.

Documenteer ten minste:

rol: Initiator, Responder of opbouw door beide zijden
IKE-versie en bij IKEv1 de Main of Aggressive Mode
Phase 1-Encryption, Authentication en DH-groep
Phase 1-Key Life, Re-key Margin en randomisering
Phase 2-Encryption, Authentication, PFS en Key Life
tijdgebaseerde rekeying en welke zijde deze start
DPD-interval en actie wanneer de tegenpartij onbereikbaar is
bekende providergrenzen en toegestane proposals

De profielnaam hoeft op beide apparaten niet gelijk te zijn. Doorslaggevend is dat ten minste één volledige combinatie aan beide zijden compatibel is. Meer proposals zijn daarbij niet automatisch beter: ze vergroten het aanvals- en foutoppervlak en kunnen IKE-pakketten zo groot maken dat fragmentatie een probleem wordt.

Veilige uitgangsconfiguratie kiezen

De volgende voorbeelden zijn Avanet-uitgangspunten voor nieuwe Site-to-Site-verbindingen. Ze vervangen geen voorschrift van Azure, AWS, een carrier of een firewall van een andere fabrikant.

Modern profiel voor gecontroleerde tegenpartijen

Als beide zijden actuele methoden ondersteunen:

Key exchange: IKEv2
Phase 1: AES256GCM16, DH19
Phase 2: AES256GCM16, PFS19
Re-key connection: On
Use strict profile: On
Compression: Off
SHA2 96-bit truncation: Off
Dead peer detection: On

AES256GCM16 is een AEAD-methode: deze versleutelt en beschermt de integriteit in één stap. Voor deze combinatie wordt geen extra Authentication-methode zoals SHA2 gekozen. GCM16 verwijst naar de Authentication Tag van 16 bytes en niet naar 16-bitsversleuteling.

De Pseudo-Random Function voor de IKE-sleutelgeneratie kan in SFOS niet afzonderlijk worden gekozen. De firewall leidt deze af uit de aangeboden integriteitsmethoden en stemt haar af met de tegenpartij.

DH19 gebruikt een elliptische kromme en biedt een goed compromis tussen beveiligingsniveau, pakketgrootte en rekenbelasting. AES128GCM16 is eveneens een actuele methode en niet automatisch onveilig voor een normaal beveiligingsniveau van 128 bit. De totale sterkte wordt altijd bepaald door de zwakste component van het profiel.

Compatibiliteitsprofiel voor actuele externe systemen

Als de tegenpartij geen AES-GCM of ECP-groep ondersteunt, is deze combinatie een breder compatibel uitgangspunt:

Key exchange: IKEv2
Phase 1: AES256, SHA2 256, DH14
Phase 2: AES256, SHA2 256, PFS14
Re-key connection: On
Dead peer detection: On

Hier werkt AES in CBC-modus en is daarom de afzonderlijke integriteitsbescherming SHA2 256 nodig. DH14 en PFS14 zijn een compatibiliteitskeuze, niet de moderne voorkeursvariant wanneer beide peers DH19 ondersteunen.

Vermijden voor nieuwe profielen

Voor nieuwe ontwerpen wordt het gebruik van IKEv1, Aggressive Mode, DES, 3DES, Blowfish, MD5, SHA1 en de DH-groepen 1, 2 en 5 afgeraden. Ook PFS: None blijft uitsluitend een gedocumenteerde uitzondering voor tegenpartijen die PFS niet ondersteunen.

AES-GMAC is ondanks zijn plaats in het Phase 2-veld Encryption geen versleuteling, maar levert alleen authenticatie en integriteit. Voor een normale vertrouwelijke Site-to-Site-tunnel wordt daarom AES-GCM of AES met een passende SHA2-methode gebruikt.

Leg legacy-afwijkingen vast met reden, betrokken tegenpartij, risico, owner en uitfaserdatum. Een zwakke combinatie zou niet naast sterke proposals moeten blijven staan alleen omdat de tunnel daarmee ook opkomt. Voor inhoudelijke richtlijnen kunnen de BSI TR-02102-3 over IPsec en IKEv2 en de NIST Guide to IPsec VPNs worden gebruikt.

Als een omgeving aan formele cryptografische vereisten moet voldoen, legt de aparte procedure uit hoe de FIPS 140-3-modus op Sophos Firewall platformen, profielen, certificaten, back-ups en HA beïnvloedt. FIPS-conformiteit vervangt niet de bewuste keuze voor een modern gemeenschappelijk proposal.

Profiel klonen of opnieuw maken

Menupad:

Profiles > IPsec profiles

Voor Sophos-naar-Sophos-verbindingen dienen de gekoppelde systeemprofielen als begrijpelijke sjabloon:

Branch office (IKEv2) voor de initiërende vestiging
Head office (IKEv2) voor het antwoordende hoofdkantoor

Het passende profiel wordt gekloond en duidelijk benoemd, bijvoorbeeld Branch-Zurich-IKEv2. Zo blijft het systeemprofiel ongewijzigd en kan bij een rollback het oude profiel opnieuw aan de bestaande tunnel worden toegewezen.

General settings

Key exchange: Voor nieuwe Site-to-Site-verbindingen IKEv2. IKEv1 alleen voor een aantoonbaar legacy-systeem.
Authentication mode: Bestaat alleen bij IKEv1. Aggressive Mode wordt niet gebruikt, omdat authenticatiegegevens minder beschermd worden overgedragen.
Key negotiation tries: Sophos adviseert 0. Bij een VPN-failovergroep stelt SFOS de effectieve waarde echter in op 3.
Re-key connection: Activeren zodat voor afloop nieuwe Phase 1- en Phase 2-sleutels worden onderhandeld. SFOS ondersteunt alleen tijdgebaseerde rekeying.
Use strict profile: Activeren wanneer de peerproposals exact bekend zijn. SFOS biedt dan alleen de geconfigureerde parameters aan. Controleer bij providerprofielen eerst hun voorschrift; in het officiële AWS-voorbeeld wordt de optie bijvoorbeeld niet gebruikt.
Pass data in compressed format: Normaal uitgeschakeld laten. Alleen activeren als het nut en de ondersteuning aan beide zijden zijn aangetoond.
SHA2 with 96-bit truncation: Alleen voor een gedocumenteerde compatibiliteitseis activeren, niet als algemene beveiligingsverbetering.

Use strict profile vermindert onverwachte fallbacks en kan helpen bij te grote IKE-proposals. Het is echter geen optie die blind in elk providerprofiel wordt geactiveerd.

Phase 1

Phase 1 bevat Key life, Re-key margin, Randomize re-keying margin by, DH-groep en maximaal drie paren van Encryption en Authentication.

SFOS accepteert voor Key Life 120 tot 86400 seconden, voor Re-key Margin 30 tot 999 seconden en voor randomisering 0 tot 100 procent. Een formeel toegestane waarde is niet automatisch zinvol: de Margin moet duidelijk kleiner blijven dan de Key Life en passen bij het gedrag van de tegenpartij.

Voer alleen de daadwerkelijk benodigde DH-groepen en proposals in. Het bekende probleem NC-136352 kan optreden wanneer een standaard IKEv2-profiel zoveel DH-groepen aanbiedt dat het IKE-pakket groter wordt dan 1'500 bytes. Als een tussenliggende component fragmenten verwerpt, blijft de Initiator verzenden terwijl de Responder niets ziet. Bij een bekende peer is één bevestigde DH-groep de duidelijkste configuratie.

Phase 2

Phase 2 bevat PFS, Key Life en Encryption en Authentication voor het gebruikersverkeer.

PFS forceert bij de Phase 2-rekey een nieuwe DH-sleuteluitwisseling. Als een langetermijnsleutel later wordt gecompromitteerd, moeten oudere opgenomen sessies daardoor niet met hetzelfde sleutelmateriaal kunnen worden ontsleuteld. Daarom wordt PFS geactiveerd en passend bij de tegenpartij gekozen. Bij moderne profielen komt de PFS-groep vaak overeen met de Phase 1-DH-groep.

De Phase 2-Key Life wordt kleiner gekozen dan de Phase 1-Key Life. Daardoor worden de sleutels voor het gebruikersverkeer vaker vernieuwd dan die voor het IKE-besturingskanaal.

Dead Peer Detection

DPD detecteert een tegenpartij die niet meer reageert. Het vervangt noch Gateway Monitoring, noch een echte applicatietest.

Vestiging of Initiator: Re-initiate, zodat de firewall na een DPD-time-out direct een nieuwe opbouw probeert.
Hoofdkantoor of Responder: Disconnect, zodat de verouderde verbinding wordt gesloten. Hold is een bewuste variant wanneer de Traffic Selectors behouden moeten blijven en pas bij nieuw verkeer opnieuw worden onderhandeld.
Check peer after every: controle-interval in seconden.
Wait for response up to: Werkt alleen bij IKEv1. Bij IKEv2 gebruikt SFOS de interne IKE-retransmission-time-out; de ingevoerde waarde verandert dit gedrag niet.

Bij IPsec-failovergroepen schakelt SFOS DPD voor de toegewezen verbindingen uit en stelt het Key negotiation tries in op 3. Daar neemt de groepsvoorwaarde de bewaking over. De gekoppelde handleiding legt de volgorde, Failover condition en Automatic failback uit; alleen de profielweergave toont niet het volledige effectieve failovergedrag.

Lifetimes en rekeying correct interpreteren

Key life is geen sessie- of idle-time-out. Deze beperkt de levensduur van een Security Association. Vóór de afloop start binnen de Re-key Margin de onderhandeling van nieuwe sleutels.

Kortere lifetimes vernieuwen sleutels vaker, maar veroorzaken meer rekenbelasting en meer momenten voor interoperabiliteits- of rekeyfouten. Langere lifetimes verminderen die belasting, maar gebruiken het sleutelmateriaal langer. Daarom is niet automatisch de kortste of de langste toegestane waarde de beste keuze.

NIST noemt 86400 seconden voor de IKE SA en 28800 seconden voor de IPsec SA als gangbare oriëntatie. Sophos en cloudproviders gebruiken afhankelijk van rol en platform andere waarden. Deze getallen zijn dus geen universeel SFOS-profiel.

Sophos adviseert om rekeybotsingen te voorkomen:

De Key Life van de Initiator is kleiner dan die van de Responder.
De Phase 2-Key Life is op beide firewalls kleiner dan de Phase 1-Key Life.
Rekeying is op ten minste één zijde geactiveerd en bij externe systemen expliciet tijdgebaseerd.

De randomisering verandert de Re-key Margin, niet de volledige Key Life. Bij acht uur Key Life, tien minuten Margin en 20 procent randomisering begint de rekey volgens Sophos tussen 7 uur en 48 minuten en 7 uur en 52 minuten.

Voor providers worden hun exacte waarden overgenomen. Het gedocumenteerde AWS-voorbeeld gebruikt op Sophos Firewall ongeveer Phase 1 28000, Re-key Margin 360, randomisering 50 en Phase 2 3600 seconden. Dit is een AWS-voorbeeld en geen algemene Avanet-default.

Profiel toewijzen en veilig testen

Het nieuwe profiel wordt tijdens een onderhoudsvenster eerst alleen aan de bedoelde verbinding toegewezen. Leg vooraf de profielnaam, bestaande waarden en rollback vast.

Voor Site-to-Site vindt de toewijzing plaats onder:

Site-to-site VPN > IPsec

Remote Access IPsec gebruikt eveneens profielen, maar kent andere grenzen: de huidige Sophos Connect-configuratie accepteert IKEv1-profielen met uitgeschakelde DPD of Disconnect. Het moderne Site-to-Site IKEv2-profiel wordt daarom niet zonder controle opnieuw gebruikt voor Remote Access. De volledige procedure staat in Sophos Connect op Sophos Firewall configureren. Het bijzondere OTP-/rekeygeval staat in Sophos Connect verbreekt de verbinding na ongeveer vier uur.

Na de opbouw worden in de Advanced Shell alleen-lezen de status en laatste IKE-meldingen gecontroleerd:

ipsec statusall
tail -n 200 /log/strongswan.log

Daarna volgt echt verkeer in beide richtingen. De Child SA-bytecounters moeten oplopen. De test wordt na ten minste één Phase 2-rekey herhaald; pas dan zijn lifetimes, PFS en rekeygedrag werkelijk gecontroleerd.

Typische foutindeling:

Tunnel blijft volledig down: IKE-versie, Phase 1-Encryption, Authentication, DH, Strict Profile, ID en peerauthenticatie controleren.
NO_PROPOSAL_CHOSEN vóór Phase 1: Phase 1-proposals vergelijken.
Phase 1 staat, Child SA ontbreekt: Phase 2-Encryption, Authentication, PFS en Traffic Selectors controleren.
Uitval na een vergelijkbare looptijd: Key Life, Re-key Margin, randomisering en Initiator-/Responderwaarden vergelijken.
Tunnel is groen maar er is geen verkeer: Niet eerst het profiel wijzigen, maar firewallregels, NAT, routing, retourpad en bytecounters controleren.

Als de wijziging problemen veroorzaakt, wordt het gedocumenteerde vorige profiel opnieuw aan de verbinding toegewezen. Services, databases of Advanced Shell-configuraties hoeven voor een normale profielrollback niet te worden gewijzigd.