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. Op de firewall op de serverlocatie vertaalt een DNAT-regel nieuwe verbindingen met Round robin naar een IP-lijst van de backends.

Dit is geen gewone internet-DNAT: tunnel, XFRM-adressen, gekozen 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 bij gebruik van SD-WAN op elke firewall een gateway naar het XFRM-adres van de peer aan.
3. Routeer VIP-App (198.51.100.10/32) en het clientnetwerk naar XFRM met statische, dynamische of SD-WAN-routes volgens de bestaande architectuur.
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. Maak eerst een configuratieback-up en leg de uitgangssituatie vast. 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.

Deze specifieke procedure vereist een route-based tunnel met Any als lokaal en extern netwerk, geadresseerde XFRM-interfaces en expliciete routing. Een route-based tunnel met Traffic Selectors kan hetzelfde doel dienen, maar SFOS maakt de routes dan op basis van de selectors; de stappen voor XFRM-gateways zijn daarom niet ongewijzigd toepasbaar. Deze procedure geldt niet voor policy-based IPsec.

Voorbeeldtopologie

In het voorbeeld benaderen clients uit 192.0.2.0/24 het virtuele adres 198.51.100.10. Servers 172.16.20.21 en 172.16.20.22 staan achter Firewall 1. De XFRM-overdrachtsadressen zijn 10.255.255.1/30 en 10.255.255.2/30.

Clientlocatie                  Route-based IPsec               Serverlocatie
192.0.2.0/24  →  xfrm2 10.255.255.2  ⇄  10.255.255.1 xfrm1  →  VIP 198.51.100.10
                                                                        │ DNAT
                                                        ┌───────────────┴───────────────┐
                                                        172.16.20.21:443       172.16.20.22:443

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.

Het voorbeeld behoudt clientadressen met Translated source (SNAT): Original. Beide backends hebben daarom een retourpad naar 192.0.2.0/24 via de serverfirewall nodig. Als dat niet mogelijk is, kan bewust geplande SNAT nodig zijn; dit verbergt het clientadres en is geen algemene oplossing voor onjuiste routing.

192.0.2.0/24 en 198.51.100.0/24 zijn documentatienetwerken; 172.16.20.0/24 is het voorbeeldservernetwerk.

De beginsituatie vastleggen

Controleer de al geteste tunnel onder Site-to-site VPN > IPsec, inclusief Gateway type: Respond only aan de serverzijde en Initiate the connection aan de clientzijde in dit voorbeeld. Maak de tunnel niet opnieuw aan en wijzig de rollen niet zonder controle. De XFRM-interface hoort altijd bij zone VPN.

Maak vóór elke wijziging een configuratiebackup en leg de IPsec-status, XFRM-adressen, routing- en SD-WAN-volgorde, firewall- en NAT-Rule ID’s, bestaande tellers en standaardgateways van de backends vast. Gebruik bestaande sessies niet als test.

Klik onder Network > Interfaces op de verticale blauwe balk naast de fysieke Listening interface om de onderliggende interfaces te tonen. Selecteer xfrm1 of xfrm2 en sla het geplande overdrachtsadres op met Save; wijzig adressen van een bestaande tunnel niet zonder de wijziging te valideren.

IP-objecten maken

Open op de serverfirewall Hosts and services > IP host > Add. Maak VIP-App met IP version IPv4, Type IP en het virtuele adres, en Remote-Clients met Type Network. Maak App-Backends met Type IP list en door komma’s gescheiden serveradressen. In SFOS 22 bevat een IP list maximaal 800 adressen en kan deze geen lid zijn van een IP host group. Gebruik de lijst rechtstreeks als Translated destination (DNAT).

De concrete objectwaarden in het voorbeeld zijn:

• VIP-App: IP version IPv4, Type IP, IP address 198.51.100.10.
• Remote-Clients: Type Network, IP address 192.0.2.0, Subnet /24.
• App-Backends: IP version IPv4, Type IP list, IP addresses 172.16.20.21,172.16.20.22.

Neem alleen servers op die dezelfde gepubliceerde dienst leveren: de lijst maakt routing of applicatiestatus niet automatisch gelijk.

De tunnelroutes definiëren

De volgende SD-WAN-routes zijn alleen nodig als SD-WAN al de gekozen routeringsmethode is. Een Any-to-Any-tunnel kan ook statische of dynamische routes gebruiken: routeer aan de clientzijde VIP-App (198.51.100.10/32) naar XFRM en aan de serverzijde Remote-Clients naar XFRM. Leid of dupliceer geen routes zonder de bestaande route precedence te controleren.

Controleer op Firewall 1 de bestaande tunnel als Route-based (Tunnel interface) met Respond only; 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.

Geef voor een statische route onder Routing > Static routes het doelnetwerk, het XFRM-adres van de peer als gateway en de lokale XFRM-interface op.

Als SD-WAN al de routingstandaard is

Maak de gateway onder Routing > Gateways > Add: Gateway IP is het XFRM-adres van de peer en Interface de lokale XFRM-interface. De Monitoring conditions moeten een permanent beschikbare host achter de gateway controleren. Een ICMP- of TCP-antwoord bewijst niet dat HTTPS op beide backends werkt.

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.

De SD-WAN-route op Firewall 2 stuurt verkeer van 192.0.2.0/24 naar 198.51.100.10 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.

Firewall 1 moet een effectieve route naar 192.0.2.0/24 via XFRM hebben. Neem niet aan dat een gespiegelde SD-WAN-route antwoorden verwerkt: SD-WAN-routes gelden alleen voor reply packets als set routing sd-wan-policy-route reply-packet enable actief is. Controleer deze globale instelling of gebruik de bestaande statische of dynamische routing.

Open op de clientfirewall Routing > SD-WAN routes > IPv4 > Add: Incoming interface is de interface aan de clientzijde, Source networks Remote-Clients, Destination networks VIP-App, Services HTTPS en Primary and backup gateways de XFRM-gateway. Zonder Route only through specified gateways beoordeelt SFOS de overige SD-WAN-routes en vervolgens, als geen route overeenkomt, de standaardroute.

SD-WAN-routes worden in lijstvolgorde beoordeeld. Afhankelijk van route precedence kan Destination networks: Any ook intern verkeer naar WAN sturen. Plaats daarom de specifieke VIP-route /32 vóór bredere routes. Traffic Count telt alleen verkeer waarvan bron en bestemming overeenkomen; het bewijst niet dat beide richtingen of de backends werken.

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:

• Rule name: DNAT-VPN-VIP-App
• Rule position: boven bredere NAT-regels die ook kunnen overeenkomen
• Original source: 192.0.2.0/24
• Translated source: Original
• Original destination: 198.51.100.10
• Original service: de echte applicatieservice, bijvoorbeeld HTTPS
• Translated destination: serverlijstobject met 172.16.20.21 en 172.16.20.22
• Translated service: Original
• Inbound interface / Outbound interface: Any (verplicht in NAT-velden voor VPN-verkeer)
• Load balancing method: Round robin
• Health check: ingeschakeld, Probe method TCP, Port 443

DNAT staat op zichzelf geen verkeer toe. Firewallregel, gekozen tunnelroute 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.

Round robin stuurt nieuwe aanvragen opeenvolgend naar de leden. Zonder Health check beschouwt SFOS alle leden als beschikbaar en kan het een uitgevallen server kiezen. Stel Probe interval, Response time-out en Deactivate host after in; een TCP-probe vervangt geen applicatietest. NAT geldt alleen voor het eerste pakket: wijzigingen verplaatsen bestaande sessies niet en moeten met nieuwe verbindingen worden getest.

SFOS beoordeelt NAT-regels van boven naar beneden en stopt bij de eerste overeenkomst.

De bijbehorende firewallregel maken

Maak de serverregel onder Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule. Any als Destination zones zou onnodig ruim zijn. Ook firewallregels worden van boven naar beneden tot de eerste overeenkomst beoordeeld; controleer de positie na het aanmaken.

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

De inkomende firewallregel staat alleen de geplande gegevensstroom toe:

• Rule name: Allow-VPN-VIP-App
• Rule position: boven overlappende regels
• Action: Accept
• Source zone: VPN
• Source networks and devices: 192.0.2.0/24
• Destination zone: zone van de vertaalde backends, in dit voorbeeld LAN
• Destination networks: alleen 198.51.100.10
• Services: alleen de applicatieservice, bijvoorbeeld HTTPS
• Log firewall traffic: ingeschakeld

SFOS zoekt eerst de DNAT-regel en gebruikt daarna de zone van de vertaalde bestemming in de firewallregel. Destination networks blijft de oorspronkelijke VIP. Controleer positie en Rule ID met echt verkeer.

Het volledige pad testen

Zet de tellers op nul of noteer de beginwaarden en sluit keep-aliveverbindingen en verbindingspools voor de test. Beperk onder Diagnostics > Packet capture de filters tot de client, de VIP en beide backendadressen. SD-WAN Traffic Count vervangt de controle van applicatielogs op elke server niet.

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.

Controleer in Log Viewer de bron, de verwachte Firewall Rule ID en de NAT Rule ID. Vergelijk de VIP vóór NAT en de vertaalde backend met een beperkte Packet Capture; leid de vertaling niet af uit één onduidelijk bestemmingsveld. De capture toont ook de aankomst via XFRM en de retourstroom via dezelfde firewall.

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.

Controleer voor een optionele ping naar de firewall op beide locaties Administration > Device access > Ping/Ping6 voor de zone VPN. Deze toestemming geldt voor de firewallservice, niet voor de applicatie achter de VIP. Schakel dit alleen in als het nodig is, leg de vorige toestand vast en trek toestemming die uitsluitend voor de test is verleend daarna weer in; open hiervoor geen WAN-toegang of andere beheerdiensten.

Test als operationele voorzorg ook tunneluitval en herstel tijdens een goedgekeurd onderhoudsvenster: nieuwe VIP-verbindingen moeten het gekozen uitvalplan volgen en met Route only through specified gateways worden verworpen als geen opgegeven gateway beschikbaar is. Controleer na herstel beide backends en het retourpad opnieuw. Controleer na rollback ook nieuwe verbindingen en de oorspronkelijke applicatiestroom. Dit zijn controles die in de eigen omgeving moeten worden uitgevoerd, geen hier geclaimde testresultaten op een appliance.

Problemen systematisch afbakenen

Geen NAT Rule ID

Controleer Original source, VIP-App, HTTPS en de positie van de NAT-regel. Controleer ook of een eerdere NAT-regel niet als eerste overeenkomt. Maak na een correctie een nieuwe verbinding, want bestaande sessies worden niet opnieuw door NAT beoordeeld.

DNAT komt overeen, maar de firewallregel niet

De Destination zones moeten overeenkomen met de zone van de vertaalde backendadressen, niet met de VIP en niet algemeen met VPN. Destination networks blijft VIP-App. Controleer daarna de Rule ID en dropgebeurtenis opnieuw in Log Viewer.

Eén backend blijft onbereikbaar

Vergelijk de Health Check-status, probemethode en poort met de werkelijke service. Zonder Health Check kan SFOS een uitgevallen lid selecteren. Ook een geslaagde TCP-probe valideert de applicatie, TLS of autorisatie niet; test de backend rechtstreeks in het servernetwerk en daarna via een nieuwe VIP-sessie.

Het antwoord neemt het verkeerde pad

Controleer de standaardgateway of specifieke route van de backend, de route naar Remote-Clients en Packet Capture op de serverfirewall. Voeg geen brede MASQ-regel toe als diagnostische omweg. Controleer bij SD-WAN ook positie, route precedence, monitoring en Route only through specified gateways.

Veilig terugrollen

Schakel eerst DNAT uit om nieuwe sessies te blokkeren en laat bestaande sessies daarna uitlopen of beëindig ze in het onderhoudsvenster. NAT-wijzigingen worden niet opnieuw op een gevestigde verbinding toegepast. Schakel vervolgens alleen de voor dit pad gemaakte regels en routes uit en herstel de vastgelegde volgorde.

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 alleen de voor dit pad gemaakte statische of SD-WAN-routes uit.
3. Zet de specifieke firewallregels terug naar de vorige toestand.
4. Verwijder alleen nieuwe gateways en nieuw toegewezen XFRM-adressen wanneer er geen afhankelijkheden zijn.
5. Test de oorspronkelijke tunnel en applicatiestroom opnieuw.

Verwijder geen gateway zolang Object usage nog afhankelijkheden toont. De XFRM-interface wordt door de tunnel gemaakt; verwijder geen bestaande tunnel die andere netwerken vervoert. Back-up en herstel van Sophos Firewall legt het veilige back-up- en herstelproces uit.

Verwijder nieuwe IP- en gatewayobjecten en nieuw toegewezen XFRM-adressen pas als Object usage en de vastgelegde beginconfiguratie geen afhankelijkheden tonen.

FAQ