Failover

XplicitTrust supports transparent failover for services hosted on an Asset by pairing the primary Asset with a Virtual Asset that shares the same DNS name.

When the primary Asset becomes unreachable, clients automatically fall over to the gateway asset that provides the Virtual Asset, without any user intervention and without DNS changes.

How it works

The key requirement is that the primary Asset and the Virtual Asset are configured with the same DNS name.

1. The primary Asset runs the XTNA-agent and serves the service directly.
2. A second Asset — the gateway asset — is configured with a Virtual Asset that points to the same service (for example, by its local IP on a secondary network path, or to a standby host).
3. Both the primary Asset and the Virtual Asset are assigned the same DNS Name in the Management Console.
4. When a client resolves the shared DNS name, it receives endpoints for both the primary and the virtual path. Connections are attempted against the most recently working endpoint first; if it fails, the client transparently rotates to the next one.

Because failover happens inside the agent's connection layer, existing sessions re-establish against the gateway path without requiring a DNS TTL to expire.

Typical setup

A common topology:

• Primary Asset — app.internal — an XTNA-agent running on the service host itself.
• Gateway Asset — a Linux Asset on the same network segment as the service.
• Virtual Asset — app.internal — configured on the gateway asset, with its Public IP set to the service's local IP (or the IP of a standby host).

Multiple gateway assets

The same underlying service can be made reachable through more than one gateway asset by configuring a separate Virtual Asset on each gateway, all sharing the same DNS name.

Each gateway adds another candidate path for the shared DNS name. Clients will rotate through all available paths on failure, so a setup with two gateway assets gives you two independent paths to the same service.

This is useful when the gateway assets themselves sit on different network segments or in different sites, so that a single gateway outage doesn't take down the failover path.

Policies

The primary Asset and the Virtual Asset are two separate destinations from the perspective of policies, even though they share a DNS name. The shared DNS name enables the agent-side failover at the connection layer — it is not a policy-level alias.

For failover to work, every policy that grants access to the primary Asset must also grant access to the Virtual Asset (and vice versa). If only one endpoint is covered by a policy for a given client, that client will only ever see one candidate address for the shared DNS name and there will be nothing to fall over to.

The simplest approach is to add both the primary Asset and the Virtual Asset as destinations on the same policy.

Notes

• The primary Asset and the Virtual Asset must share every DNS name on which failover should apply.
• The gateway asset must be able to reach the service's IP directly (usually same LAN).
• Failover is bidirectional in the sense that either endpoint may serve traffic at any given time; clients always prefer whichever path most recently worked.