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. Policy-based tunnels en route-based tunnels met concrete Traffic Selectors gebruiken in plaats daarvan een IPsec-failovergroep.

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 bewaakte gateway.
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.

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.

Selecteer de betreffende XFRM als Interface. Als het volledige achterliggende pad moet worden beoordeeld, hoort het Monitoring Target een stabiel en toegestaan endpoint achter de peer te zijn. Een ping naar alleen het XFRM-adres van de peer bewijst uitsluitend het directe tunnelsegment.

De keuze van het doel is een operationele beslissing: het moet betrouwbaar antwoorden, mag tijdens normaal onderhoud niet verdwijnen en heeft de juiste toestemming nodig. Een Custom Gateway maken en controleren legt Health Check, status en stopvoorwaarden volledig 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.

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.

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.

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. Een actieve tunnel belooft niet dat bestaande TCP-sessies of routingtoestanden zonder onderbreking doorgaan.

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. strongswan.log en xfrmi.log helpen bij de IKE- en XFRM-lagen; IPsec VPN-problemen oplossen legt de veilige diagnose uit.

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