Second WAN VPN Entry Fails While the Primary Still Works

The primary tunnel stays up, users keep working, and the second ISP circuit sits idle no matter what you change. You published an address for the backup circuit, pointed a name at it, maybe added a backup entry to the client, and the client either never tries it or authenticates and then dies. In the cases I have traced, the failover feature was usually fine; what was missing was one of the five things that make an entry usable. A name can resolve to the backup address while nothing listens on that interface, and a listener can accept a connection while the reply leaves through the primary. Treat each WAN as a separate entry with its own contract and the failure stops looking like a client bug.

Each WAN needs its own entry contract

Record five fields per WAN: the public name and address, the transport and port, the interface or context that terminates it, the peer identity it should present, and where the reply leaves. Two circuits mean two complete sets. If the second set has no terminating interface or no return path, you do not have a backup entry; you have a DNS record describing an intention.

The appliance and its release also have to support the arrangement. A DNS record cannot open a service on another interface, and on many platforms the listener is configured per address rather than per device. Interface-based IPsec on an ASA ties crypto maps and tunnel groups to the outside interface, so a second uplink needs policy attached where those packets actually arrive. Route-based designs behave differently: the listener may bind to every address or to one named address, and that choice decides whether ISP B can answer at all.

Check that the second WAN really answers

Test from outside both circuits, not from a machine behind the gateway, and test the exact name the client profile uses. For a TLS listener, the fast check is openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts run from a host outside your network. You want a completed handshake whose chain matches the name in the profile, not merely a TCP port that accepts a connection.

RFC 9525 explains what the client is checking: the identity it intended to reach, compared against the certificate the service presents. A second entry that hands back the primary entry's certificate, or a default certificate that lists neither name, fails this test even though the port is open and the firewall permits it.

Two patterns explain most failures here. A connection that hangs usually means no listener on that interface, an access rule that only permits the primary subnets, or a carrier device in front of the second circuit dropping the port. A handshake that finishes with the wrong identity usually means a different trustpoint, a default virtual host, or configuration copied from the primary without adjusting the identity.

Follow the reply, not just the request

The second WAN usually breaks on the way back. A request arrives on ISP B, the appliance answers, and the reply leaves through the default route on ISP A with a source address the client never asked for. Stateful translation makes it worse: if the mapping was built for the primary interface, the returning packet misses the translation or carries a source the client's firewall discards. Providers also drop source addresses that do not belong to the circuit they handed you, which is why this looks like a one-way black hole instead of a clean protocol error.

Check the routing decision for traffic sourced from the second entry. The reply should leave the interface the request arrived on, or at least carry an address the far side accepts as belonging to that path. On policy-routing platforms that means a rule keyed to the incoming interface or the translated source, plus a translation statement bound to each outside interface. Capture on both interfaces at once while the client connects; a SYN arriving on ISP B with the SYN-ACK leaving on ISP A settles the question in one run.

Give the client a way to learn about entry two

Failover is a client-side decision, and each client family learns about alternatives differently. On an ASA, the backup-server list is delivered through the group policy's webvpn attributes, while other clients expect a list inside the profile or a manual second profile the user selects. Cisco's connection-policy guide describes both client-configured and gateway-provided backup information, and those protocol-specific details should not be generalized to every client or tunnel mode. Confirm which mechanism the deployed client implements before you build the second entry around the wrong one.

Whatever the mechanism, the client must be able to resolve the alternate name before it loses the primary path. That dependency is the one people miss: if the backup name is answered by a resolver reachable only through the tunnel that just failed, the fallback cannot even start. Publish the second name in a resolver that answers locally or over the internet. Expect a fresh authentication and a new application session after the move, because client failover is not stateful failover and long-lived sessions do not survive it.

One address on two providers is a different product

Keeping a single public address reachable through both circuits is a routing service, not a checkbox on the VPN. It needs address space both providers are willing to carry, announced in a way their networks accept, which is what multihoming with provider-independent space and BGP provides. Assigning ISP A's address to the ISP B interface does not get there; the packet arrives at a network that never advertised the prefix and is dropped upstream.

You do not need any of that to publish two entries. If the client can hold two names and fail between them, two independent entries are enough, and you avoid an AS number, a peering arrangement, and a prefix that has to be accepted everywhere. Consider the portable-address option only when you truly need one stable entry point that clients cannot be reconfigured to replace, or when DNS-based failover with its TTL delay is too slow for the outage you are designing against.

What to check next

Work outward from the failing entry in this order: does the second address answer from outside, does it present the identity the client expects, does the reply leave the way the request arrived, and can the client learn the name before it needs it. Where an answer is no, fix that layer and retest with the deployed profile rather than a test host, because a handshake from the lab proves less than a completed connection from the real client.

Keep a short record per WAN, with address, port, terminating interface, certificate name, return path and translation rule, and re-check it whenever a circuit, a NAT device or a client version changes. Idle backup paths rot silently: nothing alerts on the entry nobody uses until the day everyone depends on it.