Forward a Virtual IP over IPsec to Multiple Servers

A virtual IP can point to multiple internal servers through an existing route-based IPsec tunnel. The remote site uses only one stable destination address. Sophos Firewall routes the traffic through the XFRM interface and then translates the virtual address to a server list using DNAT.

This isn’t ordinary internet DNAT: The tunnel, XFRM addresses, SD-WAN routes, VPN rules, and NAT must work as a single path on both firewalls.

Quick procedure

1. Validate a route-based any-to-any tunnel with addressed XFRM interfaces on both firewalls.
2. Create a gateway for each peer XFRM address.
3. Configure mirrored SD-WAN routes for the remote network, local networks, and virtual IP.
4. Create narrow firewall rules for the remote source, virtual IP, and required service.
5. On the server side, create a DNAT rule from the virtual IP to a server list using Round-robin.
6. Verify several new connections using Log Viewer, Rule IDs, NAT Rule ID, and Packet Capture.

⚠️ A green IPsec connection or active XFRM gateway does not yet prove that DNAT and the return path work. Before the production change, the actual application flow must be traceable in both directions.

When this design fits

This workflow fits when hosts at a remote site must reach an internal service through a fixed virtual address while the real server addresses remain hidden. A server list can distribute new connections across two equivalent application servers, for example.

For a single direct connection to a known server, a normal route plus a firewall rule is usually sufficient. If a service must be published to the internet, use the standard DNAT or WAF workflow instead. General tunnel planning is covered in Set up a site-to-site IPsec VPN.

This design doesn’t fit policy-based IPsec or route-based tunnels with specific traffic selectors. The path described here requires a route-based tunnel with Any as the local and remote networks, addressed XFRM interfaces, and explicit routing.

Example topology

In this example, clients from 192.168.3.0/24 access virtual address 10.10.10.1. Servers 172.16.16.2 and 172.16.16.3 are behind Firewall 1. The XFRM transfer addresses are 10.255.255.1/30 and 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

All addresses are example values and must be replaced with the actual networks. The XFRM addresses must use a dedicated transfer network that isn’t used elsewhere. The virtual IP must not collide with a real host, interface, VPN network, or another NAT publication.

Prepare the tunnel and XFRM

Any-to-any tunnel and transfer addresses

On Firewall 1, create the tunnel as Route-based (Tunnel interface) with Respond only; on Firewall 2, use Initiate the connection. On both sides, set Local subnet and Remote subnet to Any.

Then assign the transfer addresses to the XFRM interfaces under Network > Interfaces:

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

The Phase 1 and Phase 2 parameters, IDs, and authentication must already have been validated. Don’t change the XFRM addresses on an untested production tunnel.

Create XFRM gateways

Each firewall needs a gateway to the peer XFRM address for the SD-WAN routes:

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

The gateway status checks only the selected monitoring target. Create and validate a custom gateway fully explains the object, health check, and functional test.

Build rules and SD-WAN routes

Firewall 1 at the server site

The inbound firewall rule allows only the intended data flow:

• Source zone: VPN
• Source networks and devices: 192.168.3.0/24
• Destination zone: Any, as in the Sophos example for the virtual address
• Destination networks: 10.10.10.1 and other local networks only if required
• Services: only the application service, for example HTTPS
• Log firewall traffic: enabled

Any in the Destination zone is not a reason to use broad sources, destinations, or services. The virtual IP isn’t assigned to a normal interface. Therefore, verify the Rule ID with actual traffic.

The SD-WAN route on Firewall 1 sends return traffic to the remote network through the XFRM gateway. For Source networks, enter the local networks that are actually required and 10.10.10.1; for Destination networks, enter 192.168.3.0/24.

Firewall 2 at the remote site

The outbound rule uses LAN as the Source zone and VPN as the Destination zone. The source is 192.168.3.0/24, the destination is at least 10.10.10.1, the service matches the application, and logging remains enabled during rollout.

The SD-WAN route on Firewall 2 sends traffic from 192.168.3.0/24 to 10.10.10.1 through the XFRM gateway. Route only through specified gateways prevents an alternate path through another route when the service must only be reachable through this tunnel.

Whether this option is desired belongs in the failure plan. Without it, another route can take over; with it, SFOS drops the traffic when the specified gateway is unavailable. Create and test an SD-WAN route explains the complete setup.

Translate the virtual IP to the server list using DNAT

On Firewall 1, create a targeted rule under Rules and policies > NAT rules > Add NAT rule > New NAT rule:

• Original source: 192.168.3.0/24
• Translated source: Original
• Original destination: 10.10.10.1
• Original service: the actual application service, for example HTTPS
• Translated destination: server list object containing 172.16.16.2 and 172.16.16.3
• Translated service: Original
• Load balancing method: Round-robin

DNAT doesn’t allow traffic by itself. The firewall rule, SD-WAN route, and return path remain separate requirements. Understand NAT on Sophos Firewall explains original and translated values and rule order.

Round-robin distributes new matching connections across the members of the server list. A reused browser or application channel is therefore not a valid distribution test. The selection method also doesn’t automatically prove application health on each backend. Test both servers separately using new sessions.

Validate the complete path

Before testing, document tunnel status, XFRM addresses, gateway status, SD-WAN route positions, and Rule IDs. Then create several new application connections from the remote network to the virtual IP.

In Log Viewer, source 192.168.3.0/24, destination 10.10.10.1, the expected Firewall Rule ID, and the NAT Rule ID must be visible. The traffic count of the SD-WAN route must increase. A narrow Packet Capture shows whether packets arrive on the XFRM interface, are sent to the selected server after DNAT, and return through the same tunnel.

Repeat the test with both backends. On the servers, verify the expected client address, service, and return path. A ping to the virtual IP is no substitute for an actual HTTPS, SAP, or other application test.

Test a firewall rule using Log Viewer and Packet Capture helps with the combined rule, NAT, and packet-path validation.

Troubleshoot systematically

The tunnel is green, but the virtual IP doesn’t respond

First verify the SD-WAN route on Firewall 2: Do the source, destination, service, and XFRM gateway match? Then check the Rule ID and NAT Rule ID on Firewall 1. If the NAT Rule ID is missing, the Original source, Original destination, service, or rule position doesn’t match.

DNAT matches, but the server doesn’t respond

Check the server list object, local server service, and server gateway. The return path must run through Firewall 1 so the existing NAT session can translate the reply back to 10.10.10.1. Don’t add a broad MASQ rule as a shortcut because it can distort the diagnosis.

Only one server receives connections

Use several genuinely new sessions and close existing keep-alive connections. Then compare the server list, Load balancing method, and NAT Rule ID. If one backend doesn’t work directly, repair its service or local path first.

Traffic takes another route

Check the position and traffic count of the SD-WAN routes and the selected XFRM gateways. Policy Tester doesn’t fully account for SD-WAN routes; use Log Viewer, Route lookup, and Packet Capture together.

Roll back safely

Before the change, document the configuration backup, tunnel state, XFRM addresses, gateway objects, rules, and routes. If the new path doesn’t work:

1. Disable the new DNAT rule.
2. Disable the two new SD-WAN routes.
3. Restore the specific firewall rules to their previous state.
4. Remove XFRM gateways and transfer addresses only if no other route uses them.
5. Retest the original tunnel and application flow.

Don’t delete a gateway or XFRM interface while Object usage still shows dependencies. Sophos Firewall backup and restore explains the safe backup and recovery workflow.

FAQ