Route-based IPsec redundant maken met twee internetverbindingen

Een tweede internetverbinding maakt een IPsec-tunnel niet automatisch redundant. Voor betrouwbare failover heeft elke lijn een eigen route-based verbinding, een afzonderlijk geadresseerde XFRM-interface en een bewaakt routepad nodig. Alleen dan kan Sophos Firewall verkeer gericht van ISP1 naar ISP2 omschakelen en na herstel terugkeren naar het voorkeurspad.

Dit proces behandelt route-based Any-to-Any-IPsec tussen twee Sophos Firewalls met SFOS 22.0 en volgt het door Sophos beschreven ontwerp met twee internetverbindingen. Policy-based tunnels en route-based tunnels met concrete Traffic Selectors gebruiken in plaats daarvan een IPsec-failovergroep.

⚠️ De actuele Sophos-documentatie spreekt zichzelf tegen over twee Any-to-Any-verbindingen. De specifieke dual-ISP-handleiding bouwt twee tunnels zonder failovergroep. De algemene instructies voor IPsec-probleemoplossing stellen daarentegen dat meerdere verbindingen met dezelfde Local en Remote Subnets, inclusief Any-Any, alleen in dezelfde failovergroep werken. Een groep wijzigt DPD en Failback. Daarom wordt die stap hier niet verzonnen: test het ontwerp op de geïnstalleerde SFOS 22 Maintenance Release en leg afwijkend gedrag vóór productie voor aan Sophos Support.

Kort proces

1. Test op beide firewalls afzonderlijk een Any-to-Any-tunnel via ISP1 en een via ISP2.
2. Geef elk van de vier XFRM-interfaces een uniek overdrachtsadres.
3. Maak op elke firewall voor beide XFRM-adressen van de peer een Custom Gateway met een bewust gekozen Health Check.
4. Voeg twee statische routes naar hetzelfde externe LAN toe: Primary met een lagere en Backup met een hogere Administrative Distance.
5. Leg de globale Route Precedence vast en stel deze alleen op static vpn sdwan_policyroute in als dit bij het hele ontwerp past.
6. Controleer firewallregels en retourpaden voor beide XFRM-paden.
7. Onderbreek ISP1 gecontroleerd, test echt applicatieverkeer via ISP2 en controleer daarna de Failback naar ISP1.

⚠️ Route Precedence geldt voor de hele firewall. Een wijziging kan ook bestaande Static-, VPN- en SD-WAN-paden beïnvloeden. Leg eerst de actuele waarde en alle overlappende routes vast, maak een configuratieback-up en controleer een onafhankelijke beheerroute.

Ontwerp en vereisten

Het failovermodel begrijpen

De twee IPsec-verbindingen blijven zelfstandige tunnels. De route met de lagere Administrative Distance is het voorkeurspad voor gegevens. Als de bewaakte XFRM-gateway als onbereikbaar wordt beoordeeld, kan de route via de tweede tunnel overnemen.

Dit zijn twee afzonderlijke toestanden:

• De tunnel is actief: IKE en Child SA zijn opgebouwd.
• Het pad is bruikbaar: gateway, route, firewallregel, NAT-verwachting, peer en retourpad werken voor echt verkeer.

Een groene tunnel alleen bewijst daarom geen failover. Normale WAN-failover is evenmin voldoende: WAN link manager maakt geen tweede IPsec-verbinding en geen passende route op de peer aan.

Any-to-Any gebruikt geen extra VPN-failovergroep. Geadresseerde XFRM-interfaces, gateways en routes selecteren het pad. Een site-to-site IPsec VPN instellen legt de volledige basisconfiguratie van zo’n tunnel uit.

SFOS 22 staat statische, SD-WAN- of dynamische routes toe voor Any-to-Any-XFRM-interfaces. De specifieke dual-ISP-procedure gebruikt uitdrukkelijk twee statische routes. Deze werkwijze volgt dat ontwerp; voeg geen SD-WAN-route naar dezelfde bestemming toe zonder de wisselwerking en prioriteit afzonderlijk te ontwerpen en testen.

De voorbeeldtopologie plannen

Het voorbeeld verbindt een hoofdkantoor met een filiaal:

• Hoofdkantoor: 172.16.16.0/24
• Filiaal: 192.168.10.0/24
• Primary: ISP1
• Backup: ISP2
• ISP1-XFRM-netwerk: 10.255.1.0/30
• ISP2-XFRM-netwerk: 10.255.2.0/30

Head office 172.16.16.0/24                 Branch office 192.168.10.0/24

       xfrm-ISP1 10.255.1.1  ⇄  10.255.1.2 xfrm-ISP1     AD 1
Firewall HQ                                                   Firewall BO
       xfrm-ISP2 10.255.2.1  ⇄  10.255.2.2 xfrm-ISP2     AD 2

De adressen zijn documentatiewaarden en worden vervangen door eigen, niet-overlappende overdrachtsnetwerken. Elk XFRM-paar heeft een afzonderlijk netwerk nodig. De publieke ISP-adressen, Local en Remote IDs, Profiles en Listening Interfaces moeten voor elke tunnel op de peer zijn afgestemd.

Tunnels, gateways en routes configureren

Twee tunnels voorbereiden

Maak op elke firewall twee verbindingen onder Site-to-site VPN > IPsec. Beide gebruiken Route-based (Tunnel interface) en Any bij Local subnet en Remote subnet. In een gebruikelijke opzet met hoofdkantoor en filiaal gebruikt het hoofdkantoor Respond only en het filiaal Initiate the connection.

De eerste tunnel gebruikt de WAN-interface van ISP1, de tweede die van ISP2. Test beide verbindingen afzonderlijk voordat failover wordt geconfigureerd. Activeer daarbij telkens alleen de bedoelde tunnel en test een vaste gegevensstroom in beide richtingen.

Geef de automatisch aangemaakte XFRM-interfaces onder Network > Interfaces deze voorbeeldadressen:

• Hoofdkantoor: 10.255.1.1/30 voor ISP1 en 10.255.2.1/30 voor ISP2
• Filiaal: 10.255.1.2/30 voor ISP1 en 10.255.2.2/30 voor ISP2

Wijzig het adres van een XFRM-interface niet zolang andere routes of services ervan afhankelijk zijn. Controleer vóór elke wijziging Object usage, tunnelstatus en bestaande routingobjecten.

XFRM-gateways bewaken

Maak aan beide zijden onder Routing > Gateways per tunnel een gateway naar het XFRM-adres van de peer. Op het hoofdkantoor zijn dat 10.255.1.2 en 10.255.2.2; op het filiaal 10.255.1.1 en 10.255.2.1.

Stel per gateway minimaal Name, Gateway IP en Interface in. Gateway IP is het XFRM-adres van de peer en Interface de bijbehorende XFRM. Health check staat standaard uit en moet voor padbewaking worden ingeschakeld. SFOS 22 toont dan Interval (standaard 60 seconden), Time-out (2 seconden), Retries (3) en ten minste één Monitoring condition met Protocol, bij TCP Port, en IP address.

De probe-IP moet een host achter de gateway zijn. Kies voor beoordeling van het hele achterliggende pad een stabiel, toegestaan endpoint achter de peer. Een ping naar alleen het XFRM-adres bewijst slechts het directe tunnelsegment. Meerdere voorwaarden kunnen met AND of OR worden gecombineerd: AND vereist alle antwoorden, OR test van boven naar beneden tot een doel antwoordt.

Protocol, doel en intervallen zijn operationele keuzes: het doel moet betrouwbaar antwoorden, tijdens normaal onderhoud beschikbaar blijven en de juiste toestemming hebben. De standaardwaarden zijn beginwaarden, geen gegarandeerde omschakeltijd. Accepteer de wijziging pas nadat detectie-, Failover- en Failback-tijd zijn gemeten. Een Custom Gateway maken en controleren legt Health Check, status en stopvoorwaarden uit.

Statische Primary- en Backup-routes toevoegen

Voeg op het hoofdkantoor onder Routing > Static routes twee IPv4-Unicast-routes naar filiaalnetwerk 192.168.10.0/24 toe:

• via 10.255.1.2 en de ISP1-XFRM met Administrative distance 1
• via 10.255.2.2 en de ISP2-XFRM met Administrative distance 2

Maak op het filiaal spiegelbeeldig twee routes naar hoofdkantoornetwerk 172.16.16.0/24:

• via 10.255.1.1 en de ISP1-XFRM met Administrative distance 1
• via 10.255.2.1 en de ISP2-XFRM met Administrative distance 2

De lagere Administrative Distance wint zolang de bijbehorende gateway beschikbaar is. Identieke doelnetwerken en verschillende afstanden vormen zo Primary en Backup. Dit is iets anders dan ECMP met gelijke prioriteit. Een statische route instellen en testen legt de algemene route- en retourpadlogica uit.

De specifieke Sophos-handleiding schrijft automatisch Failover en Failback aan dit ontwerp toe. De algemene referentie voor statische routes bevestigt prioriteit via Administrative Distance, maar beschrijft niet afzonderlijk hoe een mislukte gateway-Health Check de route uit de selectie haalt. Observeer daarom bij acceptatie de actieve route en niet alleen de gatewaystatus.

Route Precedence gecontroleerd instellen

Sophos documenteert deze opzet met Static vóór VPN en SD-WAN. Leg eerst de bestaande toestand vast in de Device Console:

system route_precedence show

Stel deze volgorde alleen op beide firewalls in als ze bij het volledige routingontwerp past:

system route_precedence set static vpn sdwan_policyroute

Controleer de waarde daarna opnieuw met system route_precedence show. Deze wijziging is geen algemene IPsec-oplossing. Ze beïnvloedt ook andere overlappende Static-, VPN- en SD-WAN-routes. Route Precedence veilig wijzigen legt de globale werking en rollback uit.

De SFOS 22-help noemt als algemene standaard static, sdwan_policyroute, vpn, terwijl de specifieke handleiding voor dit ontwerp static vpn sdwan_policyroute vereist. Herstel daarom exact de eerder met show vastgelegde volgorde en pas niet blind de standaard toe.

Regels, NAT en retourpad afstemmen

Beide firewalls hebben passende regels tussen LAN en VPN nodig. Beperk bronnen, doelen en services tot de werkelijke locatienetwerken en applicaties; laat Log firewall traffic tijdens de ingebruikname actief.

Normaal gerouteerd locatieverkeer heeft meestal geen SNAT nodig. Als al NAT-uitzonderingen of gerichte vertalingen bestaan, moeten die op beide paden hetzelfde werken. Voeg geen brede MASQ-regel toe als failover-snelkoppeling.

Dit verschilt van NAT Traversal. Sophos Firewall schakelt NAT-T automatisch in en gebruikt UDP 4500 zodra NAT wordt gedetecteerd; zonder NAT gebruikt IKE UDP 500 en ESP IP-protocol 50. Staat een firewall achter een upstreamrouter, dan moeten DNAT en toegang op die router voor beide ISP-paden naar de juiste Listening Interface leiden. Overlappende locatienetwerken vereisen daarentegen passende SNAT- en DNAT-regels voor het dataverkeer.

De route op de peer is net zo belangrijk als het heenpad. Een tunnel kan actief zijn terwijl het antwoord via de verkeerde ISP of een algemenere route terugkomt. Beoordeel daarom Route Lookup, de actieve route, Firewall Rule ID, NAT Rule ID en Packet Capture samen.

Failover testen en beheren

Failover en Failback testen

Test vóór de uitvalproef beide tunnels afzonderlijk met dezelfde applicatiestroom. Houd één doorlopende testverbinding zichtbaar en bouw tijdens de test ook nieuwe sessies op.

Onderbreek in het onderhoudsvenster alleen het ISP1-pad op gecontroleerde wijze. Schakel niet beide WAN-poorten of beide tunnels tegelijk uit. De test beantwoordt vier vragen:

1. Wordt de ISP1-gateway als niet beschikbaar herkend?
2. Wordt de route met Administrative Distance 2 via de ISP2-XFRM actief?
3. Bereiken nieuwe verbindingen de peer en keren de antwoorden via ISP2 terug?
4. Wordt na herstel van ISP1 opnieuw de route met Administrative Distance 1 gebruikt?

In Log Viewer en een beperkte Packet Capture moeten de verwachte Firewall Rule ID, de actieve XFRM-interface en de gegevensstroom in beide richtingen overeenkomen. Een ping alleen is niet genoeg. HTTPS, RDP, VoIP of een andere echte applicatie toont daarnaast of sessieopbouw, MTU en retourpad werken. Een firewallregel met Log Viewer en Packet Capture testen legt de gecombineerde werkwijze uit.

Test in een HA-cluster na een geplande Failover een nieuwe verbinding via beide ISP-paden. SFOS 22 herstelt route-based IPsec-tunnels naadloos, maar beperkt sessie-Failover voor verkeer in de tunnel tot stateless protocollen zoals UDP en ICMP; TCP wordt niet ondersteund. Beoordeel een bestaande en een nieuwe TCP-verbinding apart. HA-logs en -rapporten blijven bovendien alleen op het knooppunt dat het verkeer verwerkte; controleer beide apparaten.

Problemen systematisch afbakenen

Beide tunnels zijn groen, maar ISP2 neemt niet over

Controleer gatewaystatus, Monitoring Target en beide statische routes. Doelnetwerk en prefix moeten identiek zijn, terwijl Next Hops en XFRM-interfaces verschillend moeten zijn. Vergelijk daarna Administrative Distance en de actuele Route Precedence.

ISP2 neemt over, maar applicaties antwoorden niet

Controleer firewallregels, NAT-uitzonderingen en de retourroute aan beide zijden. Packet Capture moet request en reply op de ISP2-XFRM tonen. Als alleen het antwoord ontbreekt, ligt de fout meestal achter de peer of in een asymmetrisch retourpad.

Failback schakelt te vroeg of helemaal niet terug

Observeer Health Check en Monitoring Target. Het doel mag de tunnel niet af en toe als gezond melden terwijl het applicatiepad nog verstoord is. Controleer Administrative Distance, de actieve route en een werkelijk nieuwe sessie samen; bestaande verbindingen kunnen aan hun eerdere toestand gebonden blijven.

Slechts één richting werkt

Vergelijk de spiegelbeeldige configuratie: XFRM-adres, gateway, statische route, regel en retourpad moeten op beide firewalls aanwezig zijn. De actuele Sophos-diagnose noemt /log/strongswan.log, /log/charon.log, /log/strongswan-monitor.log en /log/dgd.log; het laatste bevat Dead Gateway Detection- en VPN-Failover-events. In de Advanced Shell toont het alleen-lezen commando ip xfrm state of Transform States aanwezig zijn. IPsec VPN-problemen oplossen legt de veilige diagnose uit.

Tunnel- en gatewaystatus spreken elkaar tegen

DPD en Gateway Health Check meten verschillende zaken. Dead Peer Detection staat onder Profiles > IPsec profiles en detecteert een niet-antwoordende IKE-peer nadat de Phase 2-tunnel inactief bleef; Sophos adviseert DPD in te schakelen. De Health Check van de Custom Gateway test de gekozen host achter het XFRM-pad. Schakel DPD niet uit om een defect probe-doel te verhullen. Vereist Sophos Support wegens het documentatieconflict toch een failovergroep, houd er dan rekening mee dat deze DPD in het profiel uitschakelt, Key negotiation tries op 3 zet en eigen Automatic failback met maximaal vijf pogingen invoert. Meng dit andere bedrijfsmodel niet zonder afzonderlijke acceptatietest met deze werkwijze.

Veilig terugrollen

Documenteer vóór de wijziging de back-up, oorspronkelijke Route Precedence, tunnelstatus, XFRM-adressen, gateways, regels en routes. Als het redundante pad niet betrouwbaar werkt:

1. Schakel de nieuwe Backup-routes uit.
2. Schakel de ISP2-gateways en tweede tunnel uit in plaats van ze direct te verwijderen.
3. Herstel de oorspronkelijke Route Precedence op beide firewalls.
4. Herstel regels en NAT naar de gedocumenteerde vorige toestand.
5. Test het oorspronkelijke ISP1-pad opnieuw met een nieuwe applicatiesessie.

Verwijder XFRM-adressen, gateways of tunnels pas wanneer Object usage geen afhankelijkheden meer toont. Back-up en herstel van Sophos Firewall legt het back-up- en herstelproces uit.

FAQ