Een virtueel IP via IPsec naar meerdere servers sturen

Een virtueel IP kan via een bestaande route-based IPsec-tunnel naar meerdere interne servers verwijzen. De externe locatie gebruikt slechts één stabiel doeladres. Sophos Firewall routeert het verkeer via de XFRM-interface en vertaalt het virtuele adres daarna met DNAT naar een serverlijst.

Dit is geen gewone internet-DNAT: tunnel, XFRM-adressen, SD-WAN-routes, VPN-regels en NAT moeten op beide firewalls als één gezamenlijk pad werken.

Kort proces

1. Test op beide firewalls een route-based Any-to-Any-tunnel met geadresseerde XFRM-interfaces.
2. Maak voor elk XFRM-adres van de peer een gateway aan.
3. Configureer gespiegelde SD-WAN-routes voor het externe netwerk, de lokale netwerken en het virtuele IP.
4. Maak beperkte firewallregels voor de externe bron, het virtuele IP en de benodigde service.
5. Maak aan de serverzijde een DNAT-regel van het virtuele IP naar een serverlijst met Round-robin.
6. Controleer meerdere nieuwe verbindingen met Log Viewer, Rule IDs, NAT Rule ID en Packet Capture.

⚠️ Een groene IPsec-verbinding of actieve XFRM-gateway bewijst nog niet dat DNAT en de retourroute werken. Vóór de productieve omschakeling moet de echte applicatiestroom in beide richtingen te volgen zijn.

Wanneer dit ontwerp past

Dit proces past wanneer hosts op een externe locatie een interne service via een vast virtueel adres moeten bereiken, terwijl de echte serveradressen verborgen blijven. Een serverlijst kan nieuwe verbindingen bijvoorbeeld over twee gelijkwaardige applicatieservers verdelen.

Voor één directe verbinding met een bekende server volstaat meestal een normale route plus firewallregel. Als een service op internet moet worden gepubliceerd, past de klassieke DNAT- of WAF-procedure. De algemene tunnelplanning staat in Een site-to-site IPsec VPN instellen.

Dit ontwerp past niet bij policy-based IPsec of route-based tunnels met concrete Traffic Selectors. Het beschreven pad vereist een route-based tunnel met Any als lokaal en extern netwerk, geadresseerde XFRM-interfaces en expliciete routing.

Voorbeeldtopologie

In het voorbeeld benaderen clients uit 192.168.3.0/24 het virtuele adres 10.10.10.1. Servers 172.16.16.2 en 172.16.16.3 staan achter Firewall 1. De XFRM-overdrachtsadressen zijn 10.255.255.1/30 en 10.255.255.2/30.

Remote clients                 Route-based IPsec                 Server site
192.168.3.0/24  →  xfrm2 10.255.255.2  ⇄  10.255.255.1 xfrm1  →  VIP 10.10.10.1
                                                                        │ DNAT
                                                        ┌───────────────┴───────────────┐
                                                        172.16.16.2           172.16.16.3

Alle adressen zijn voorbeeldwaarden en worden door de echte netwerken vervangen. De XFRM-adressen moeten een eigen overdrachtsnetwerk vormen dat nergens anders wordt gebruikt. Het virtuele IP mag niet overlappen met een echte host, interface, VPN-netwerk of andere NAT-publicatie.

Tunnel en XFRM voorbereiden

Any-to-Any-tunnel en overdrachtsadressen

Op Firewall 1 wordt de tunnel als Route-based (Tunnel interface) met Respond only aangemaakt; op Firewall 2 wordt Initiate the connection gebruikt. Aan beide zijden staan Local subnet en Remote subnet op Any.

Daarna krijgen de XFRM-interfaces onder Network > Interfaces hun overdrachtsadressen:

• Firewall 1, xfrm1: 10.255.255.1/30
• Firewall 2, xfrm2: 10.255.255.2/30

De Phase 1- en Phase 2-parameters, IDs en authenticatie moeten al zijn getest. Wijzig XFRM-adressen niet op een ongeteste productietunnel.

XFRM-gateways maken

Voor de SD-WAN-routes heeft elke firewall een gateway naar het XFRM-adres van de peer nodig:

• Firewall 1: Gateway IP 10.255.255.2 via xfrm1
• Firewall 2: Gateway IP 10.255.255.1 via xfrm2

De gatewaystatus controleert alleen het gekozen Monitoring Target. Een Custom Gateway maken en controleren legt het object, de Health Check en de functionele test volledig uit.

Regels en SD-WAN-routes opbouwen

Firewall 1 op de serverlocatie

De inkomende firewallregel staat alleen de geplande gegevensstroom toe:

• Source zone: VPN
• Source networks and devices: 192.168.3.0/24
• Destination zone: Any, zoals in het Sophos-voorbeeld voor het virtuele adres
• Destination networks: 10.10.10.1 en alleen indien nodig andere lokale netwerken
• Services: alleen de applicatieservice, bijvoorbeeld HTTPS
• Log firewall traffic: ingeschakeld

Any in Destination zone is geen reden voor brede bronnen, doelen of services. Het virtuele IP is niet aan een normale interface toegewezen. Bevestig daarom de Rule ID met echt verkeer.

De SD-WAN-route op Firewall 1 stuurt retourverkeer via de XFRM-gateway naar het externe netwerk. Als Source networks worden de werkelijk benodigde lokale netwerken en 10.10.10.1 ingevoerd; als Destination networks wordt 192.168.3.0/24 gebruikt.

Firewall 2 op de externe locatie

De uitgaande regel gebruikt LAN als Source zone en VPN als Destination zone. De bron is 192.168.3.0/24, het doel is minimaal 10.10.10.1, de service komt overeen met de applicatie en logging blijft tijdens de ingebruikname actief.

De SD-WAN-route op Firewall 2 stuurt verkeer van 192.168.3.0/24 naar 10.10.10.1 via de XFRM-gateway. Route only through specified gateways voorkomt een uitwijkpad via een andere route wanneer de service uitsluitend via deze tunnel bereikbaar mag zijn.

Of deze optie gewenst is, hoort in het uitvalplan. Zonder de optie kan een andere route overnemen; met de optie verwerpt SFOS het verkeer als de opgegeven gateway niet beschikbaar is. Een SD-WAN-route maken en testen legt de volledige configuratie uit.

Het virtuele IP met DNAT naar de serverlijst vertalen

Maak op Firewall 1 onder Rules and policies > NAT rules > Add NAT rule > New NAT rule een gerichte regel:

• Original source: 192.168.3.0/24
• Translated source: Original
• Original destination: 10.10.10.1
• Original service: de echte applicatieservice, bijvoorbeeld HTTPS
• Translated destination: serverlijstobject met 172.16.16.2 en 172.16.16.3
• Translated service: Original
• Load balancing method: Round-robin

DNAT staat op zichzelf geen verkeer toe. Firewallregel, SD-WAN-route en retourroute blijven afzonderlijke vereisten. NAT op Sophos Firewall begrijpen legt originele en vertaalde waarden en de regelvolgorde uit.

Round-robin verdeelt nieuwe overeenkomende verbindingen over de leden van de serverlijst. Een hergebruikt browser- of applicatiekanaal is daarom geen goede verdelingstest. De selectiemethode bewijst evenmin automatisch dat de applicatie op elke backend gezond is. Test beide servers afzonderlijk met nieuwe sessies.

Het volledige pad testen

Documenteer vóór de test de tunnelstatus, XFRM-adressen, gatewaystatus, positie van de SD-WAN-routes en Rule IDs. Maak daarna meerdere nieuwe applicatieverbindingen van het externe netwerk naar het virtuele IP.

In Log Viewer moeten bron 192.168.3.0/24, doel 10.10.10.1, de verwachte Firewall Rule ID en de NAT Rule ID zichtbaar zijn. De Traffic Count van de SD-WAN-route moet toenemen. Een beperkte Packet Capture toont of pakketten op de XFRM-interface binnenkomen, na DNAT naar de geselecteerde server gaan en via dezelfde tunnel terugkeren.

Herhaal de test met beide backends. Controleer op de servers het verwachte clientadres, de service en de retourroute. Een ping naar het virtuele IP vervangt geen echte HTTPS-, SAP- of andere applicatietest.

Een firewallregel met Log Viewer en Packet Capture testen helpt bij de gecombineerde controle van regel, NAT en pakketpad.

Problemen systematisch afbakenen

De tunnel is groen, maar het virtuele IP antwoordt niet

Controleer eerst de SD-WAN-route op Firewall 2: komen bron, doel, service en XFRM-gateway overeen? Controleer daarna de Rule ID en NAT Rule ID op Firewall 1. Als de NAT Rule ID ontbreekt, komen Original source, Original destination, service of regelpositie niet overeen.

DNAT komt overeen, maar de server antwoordt niet

Controleer het serverlijstobject, de lokale serverservice en de gateway van de server. De retourroute moet via Firewall 1 lopen, zodat de bestaande NAT-sessie het antwoord weer naar 10.10.10.1 kan vertalen. Voeg geen brede MASQ-regel toe als snelkoppeling, omdat die de diagnose kan vertekenen.

Slechts één server ontvangt verbindingen

Gebruik meerdere werkelijk nieuwe sessies en sluit bestaande Keep-alive-verbindingen. Vergelijk daarna de serverlijst, Load balancing method en NAT Rule ID. Als één backend rechtstreeks niet werkt, herstel dan eerst de service of het lokale pad.

Verkeer neemt een andere route

Controleer de positie en Traffic Count van de SD-WAN-routes en de gekozen XFRM-gateways. Policy Tester houdt niet volledig rekening met SD-WAN-routes; gebruik Log Viewer, Route lookup en Packet Capture samen.

Veilig terugrollen

Documenteer vóór de wijziging de configuratieback-up, tunnelstatus, XFRM-adressen, gatewayobjecten, regels en routes. Als het nieuwe pad niet werkt:

1. Schakel de nieuwe DNAT-regel uit.
2. Schakel de twee nieuwe SD-WAN-routes uit.
3. Zet de specifieke firewallregels terug naar de vorige toestand.
4. Verwijder XFRM-gateways en overdrachtsadressen alleen als geen andere route ze gebruikt.
5. Test de oorspronkelijke tunnel en applicatiestroom opnieuw.

Verwijder geen gateway of XFRM-interface zolang Object usage nog afhankelijkheden toont. Back-up en herstel van Sophos Firewall legt het veilige back-up- en herstelproces uit.

FAQ