Forward a Virtual IP over IPsec to Multiple Servers

A virtual IP can point to multiple internal servers through a route-based IPsec tunnel. The remote site addresses only the virtual IP. On the server-site firewall, a DNAT rule translates new connections to an IP list of backends using Round robin.

The key distinction is that DNAT, the firewall rule, and routing perform three separate tasks. DNAT translates the destination but doesn’t allow traffic. The firewall rule allows the service and uses the zone of the translated destination as its Destination zone. The route determines which packets enter the XFRM interface.

Quick procedure

1. Use a working route-based any-to-any IPsec tunnel with an addressed XFRM interface.
2. Configure narrow routes for the destinations actually required at both sites.
3. On the server firewall, create the virtual IP and backends under Hosts and services > IP host.
4. Create a manual DNAT rule from the virtual IP to the backend IP list.
5. On the client firewall, allow the client network to the VIP from LAN to VPN. On the server firewall, create the corresponding VPN-to-server-zone rule. Keep both rules narrow and above overlapping rules.
6. Validate the health check and several genuinely new connections using logs and Packet Capture.

⚠️ A green IPsec connection proves neither DNAT nor backend availability. Don’t change the production route until the real application flow, including its return path, has been tested.

When this design fits

Use this design when clients at a remote site must reach an internal service through a fixed address and several equivalent backends provide that service. A single known server generally only needs routing and a firewall rule. Internet publishing instead follows the standard DNAT or WAF workflow.

This guide uses a route-based tunnel with Any for Local subnet and Remote subnet. SFOS creates an addressable XFRM interface for this design; static, SD-WAN, or dynamic routes then select the tunnel path. With traffic selectors, SFOS creates the route itself, so the XFRM gateway steps here don’t apply unchanged. See Set up a site-to-site IPsec VPN for general tunnel planning.

Example and values to adapt

Client site                     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:443         10.0.20.22:443

192.0.2.0/24 and 198.51.100.0/24 are documentation networks; 10.0.20.0/24 is the example server network. Replace every value with the local address plan. The XFRM transfer network must not be used elsewhere. The virtual IP must not collide with an interface, host, VPN network, or other NAT publication.

The example preserves client addresses with Translated source (SNAT): Original. Both backends therefore need a return path to 192.0.2.0/24 through the server firewall. If that can’t be arranged, deliberately planned SNAT may be required; it hides the client address and isn’t a general fix for incorrect routing.

Preserve the starting state

Before changing anything, take a configuration backup and record IPsec status, XFRM addresses, routing and SD-WAN order, firewall and NAT rule IDs, existing usage counts, and backend default gateways. Don’t use established sessions as the test.

On both firewalls, the tested tunnel must already exist under Site-to-site VPN > IPsec as Route-based (Tunnel interface) with Any for both subnets. Under Network > Interfaces, assign a transfer address to the automatically created XFRM interface: 10.255.255.1/30 and 10.255.255.2/30 in the example. The XFRM interface always belongs to the VPN zone.

Create the IP objects

On the server firewall, create three objects under Hosts and services > IP host > Add:

• 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 10.0.20.21,10.0.20.22.

In SFOS 22, an IP list accepts up to 800 comma-separated IP addresses and can’t be added to an IP host group. This design uses the list directly as Translated destination (DNAT). Include only servers providing the same published service; the list doesn’t make their routing or application state identical.

Define the tunnel routes

With an any-to-any tunnel, each side must explicitly route traffic that should be encrypted to the XFRM interface. At minimum, configure:

• Client site: a route for VIP-App (198.51.100.10/32) toward the server site.
• Server site: a route for Remote-Clients (192.0.2.0/24) toward the client site.

Whether these are static, dynamic, or SD-WAN routes depends on the existing architecture. Don’t configure competing methods without explicit precedence. For a static route, specify the destination, peer XFRM address as the gateway, and local XFRM interface under Routing > Static routes.

If SD-WAN is already the routing standard

To create an XFRM gateway, go to Routing > Gateways > Add, use the peer XFRM address as Gateway IP, and select the local XFRM Interface. An enabled health check evaluates only its configured Monitoring conditions. Use an always-available host behind the gateway; a successful ICMP or TCP probe doesn’t prove HTTPS health on both backends. Create and test a custom gateway covers the gateway object, health check, and functional test in detail.

On the client firewall, keep the route under Routing > SD-WAN routes > IPv4 > Add narrow: set Incoming interface to the client-facing interface, Source networks to Remote-Clients, Destination networks to VIP-App, Services to HTTPS, and select the XFRM gateway under Primary and backup gateways. Route only through specified gateways drops traffic if none of those gateways is reachable. When cleared, SFOS evaluates other SD-WAN routes and then the default route, so this choice belongs in the failure plan.

The server firewall still needs an effective route to Remote-Clients. Don’t assume that a mirror-image SD-WAN route handles replies: SD-WAN routes apply to reply packets only when set routing sd-wan-policy-route reply-packet enable is enabled. Check the existing global setting before choosing SD-WAN for the return path; otherwise use the established static or dynamic routing design.

SFOS evaluates SD-WAN routes in list order. With the corresponding route precedence, a route whose Destination networks is Any can send internal traffic toward WAN. Use the /32 VIP here and place the specific route above broader ones. The traffic count only represents traffic whose source and destination match the route; it doesn’t prove both directions or backend health. See Create and test an SD-WAN route for the general workflow.

Create the DNAT rule

Under Rules and policies > NAT rules, select IPv4, then Add NAT rule > New NAT rule:

• Rule name: DNAT-VPN-VIP-App
• Rule position: above broader NAT rules that could also match
• Original source: Remote-Clients
• Translated source (SNAT): Original
• Original destination: VIP-App
• Translated destination (DNAT): App-Backends
• Original service: HTTPS
• Translated service (PAT): Original
• Inbound interface: Any
• Outbound interface: Any
• Load balancing method: Round robin

SFOS requires Any for NAT interfaces carrying VPN traffic because VPNs aren’t interfaces in these NAT fields. This doesn’t make the rule broad when source, destination, and service remain narrow.

Round robin sends matching new requests to each server sequentially. For failover, also enable Health check; for this example use Probe method TCP, Port 443, and deliberate values for Probe interval, Response time-out, and Deactivate host after. Without a health check, SFOS considers every list member available and may send traffic to a failed server. A TCP probe only confirms that the port responds; application-level monitoring remains necessary.

NAT rules apply only to the first packet of a connection. Rule or list changes therefore don’t move established sessions to another backend. SFOS evaluates NAT rules from top to bottom and stops at the first match. Understand NAT on Sophos Firewall explains connection state and rule order in more depth.

Create the matching firewall rule

On the client firewall, create or verify a rule from source zone LAN and Remote-Clients to destination zone VPN, destination VIP-App, and service HTTPS. On the server firewall, go to Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule and create a specific accept rule:

• Rule name: Allow-VPN-VIP-App
• Rule position: above overlapping rules
• Action: Accept
• Log firewall traffic: enabled
• Source zones: VPN
• Source networks and devices: Remote-Clients
• Destination zones: the zone containing App-Backends, LAN in this example
• Destination networks: VIP-App
• Services: HTTPS

For inbound DNAT, SFOS first determines the translated address and uses its zone as the Destination zone. The firewall rule’s Destination networks, however, remain the original virtual IP. Any would be unnecessarily broad as the Destination zone. Firewall rules are also evaluated top-down to the first match, so recheck the position after automatic or manual rule creation.

Validate the complete path

1. Check tunnel status, gateway health, and the effective route to 198.51.100.10.
2. Reset the new NAT, firewall, and optional SD-WAN usage counts, or record their starting values.
3. Open several new HTTPS connections from the client site to the VIP; close keep-alive sessions and connection pools for this test.
4. In Log Viewer, confirm the source, Firewall Rule ID, and NAT Rule ID. Use Packet Capture to compare the pre-NAT VIP with the translated backend; don’t infer translation from an ambiguous destination field alone.
5. Under Diagnostics > Packet capture, filter narrowly for the client, VIP, and both backend addresses. Expect ingress over XFRM, DNAT to a live server, and replies through the same firewall.
6. Check the application log and observed source address on each backend. An SD-WAN traffic count or ping to the VIP isn’t a substitute for this application test.

See Test a firewall rule using Log Viewer and Packet Capture for combined rule, NAT, and packet-path validation.

Troubleshoot systematically

No NAT Rule ID

Check Original source, VIP-App, HTTPS, and NAT rule position. Also verify that an earlier NAT rule isn’t matching first. Create a new connection after a correction because established sessions aren’t re-evaluated against NAT.

DNAT matches, but the firewall rule doesn’t

Destination zones must contain the translated backend addresses, not the VIP and not generically VPN. Destination networks remains VIP-App. Then check the Rule ID and drop event in Log Viewer again.

One backend remains unreachable

Compare health-check state, probe method, and port with the actual service. Without a health check, SFOS may select a failed member. Even a successful TCP probe doesn’t validate the application, TLS, or authorization; test the backend directly within the server network and then through a new VIP session.

The reply takes the wrong path

Check the backend default gateway or specific route, the route to Remote-Clients, and Packet Capture on the server firewall. Don’t add a broad MASQ rule as a diagnostic shortcut. With SD-WAN, also inspect list position, route precedence, gateway monitoring, and Route only through specified gateways.

Roll back without ignoring connection state

Don’t begin a rollback by deleting objects. First decide whether established sessions can drain or must be ended in a maintenance window: NAT changes only affect new connections.

1. Disable the new DNAT rule so no new VIP sessions start.
2. Observe active application sessions and let them drain or end them according to the maintenance plan.
3. Disable the new firewall rule and only the static or SD-WAN routes created for this path.
4. Restore the recorded rule and route order, then test the original application flow.
5. Remove newly created gateway and IP objects, and clear newly assigned XFRM addresses, only after Object usage and the recorded configuration show no dependencies. The XFRM interface itself is tunnel-created: don’t delete an existing tunnel that carries other networks.

See Sophos Firewall backup and restore for the safe backup workflow.

FAQ