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, gekozen routes, VPN-regels en NAT moeten op beide firewalls als één gezamenlijk pad werken.
Kort proces
- Test op beide firewalls een route-based Any-to-Any-tunnel met geadresseerde XFRM-interfaces.
- Maak bij gebruik van SD-WAN op elke firewall een gateway naar het XFRM-adres van de peer aan.
- Routeer
VIP-App(198.51.100.10/32) en het clientnetwerk naar XFRM met statische, dynamische of SD-WAN-routes volgens de bestaande architectuur. - Maak beperkte firewallregels voor de externe bron, het virtuele IP en de benodigde service.
- Maak aan de serverzijde een DNAT-regel van het virtuele IP naar een serverlijst met Round-robin.
- 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 10.0.20.21 en 10.0.20.22 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.0.2.0/24 → xfrm2 10.255.255.2 ⇄ 10.255.255.1 xfrm1 → VIP 198.51.100.10
│ DNAT
┌───────────────┴───────────────┐
10.0.20.21 10.0.20.22
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; 10.0.20.0/24 is het voorbeeldservernetwerk.
De beginsituatie vastleggen
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.
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 versionIPv4, TypeIP, IP address198.51.100.10.Remote-Clients: TypeNetwork, IP address192.0.2.0, Subnet/24.App-Backends: IP versionIPv4, TypeIP list, IP addresses10.0.20.21,10.0.20.22.
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.
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.
Als SD-WAN al de routingstandaard is
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.2viaxfrm1 - Firewall 2: Gateway IP
10.255.255.1viaxfrm2
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.
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
10.0.20.21en10.0.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, Port443
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.
De bijbehorende firewallregel maken
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
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.
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:
- Schakel de nieuwe DNAT-regel uit.
- Schakel alleen de voor dit pad gemaakte statische of SD-WAN-routes uit.
- Zet de specifieke firewallregels terug naar de vorige toestand.
- Verwijder alleen nieuwe gateways en nieuw toegewezen XFRM-adressen wanneer er geen afhankelijkheden zijn.
- 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.