VPN providers such as NordVPN and IPVanish give you a WireGuard file per server, and allow one connected tunnel per account at a time. From 1.1.31, Korthveil can hold many servers of several providers in one failover group and keep exactly one tunnel per provider account connected: the first working NordVPN tunnel carries your traffic, the first working IPVanish tunnel is connected and ready, and every other tunnel waits idle until it is needed. When the active tunnel fails, the ready one of the other provider takes over at once.

At a glance:

The wizard System › Wizards › Send devices through a VPN does steps 1–4 in one pass and picks the right connection mode by itself.

Why one connection per account

A provider account allows one connected tunnel (one session per key). If two tunnels of the same account are connected together, the provider keeps dropping one of them: the tunnels go up and down, pings are lost, and the group switches back and forth. That happens when a group keeps all its members connected (the classic Failover, Fastest and Load balance), and in a failover pair before 1.1.30 (both firewalls connected the same tunnels).

Step 1: Import all files at once

VPN › WireGuard › Import configuration, then choose all your files in one go (for example five NordVPN and five IPVanish .conf files, or QR code pictures). Each file becomes its own client tunnel with its own random local port, so several tunnels of one provider never clash on port 51820. A file that is the same as an existing tunnel is skipped.

NordVPN gives every client the address 10.5.0.2: the import (and the wizard) give such tunnels /32 so they can exist side by side.

Step 2: Outbound NAT per tunnel

Every tunnel needs a Masquerade rule with the tunnel as out interface (Firewall › NAT › Source NAT), or the provider drops what you send. The wizard adds the missing ones; see Send your TVs through a VPN for the picture.

Step 3: The group

Network › Policy routing › Gateway groups › Add gateway group (or edit yours):

• How the members share the traffic: Failover: one at a time, in order.
• Connected tunnels: One tunnel per provider account (recommended). (Only the active tunnel keeps a single tunnel connected in total; All tunnels is the classic behaviour for tunnels that do not share an account.)
• Members, in your order of preference: for example NordVPN Seattle, NordVPN Dallas, NordVPN Portland, then IPVanish Seattle. Give each member its provider as Account (the wizard fills it from the server name); tunnels with the same key always count as one account.
• Go back to the earlier tunnel once it is connected: on: when the next tunnel of your first provider is connected again, the traffic returns to it.
• Return to the first tunnel: Never stays on the working tunnel of an account; Periodically tests your first tunnel again every so often (while another provider's ready tunnel carries the traffic, so there is no interruption).
• Retry a failed tunnel after (minutes): a failed tunnel is tried again, one per account, while that account has no working tunnel.
• Handshake within / answers needed: how long a woken tunnel has to connect (10 s) and how many pings it must answer (2) before it carries traffic. A tunnel without a handshake is marked failed: key not accepted?: the provider no longer accepts that file (download a new one).
• Kill switch: on for traffic that must never use your normal line (torrents); off with the internet line as the last member for devices that must never go offline (TVs).
• Clear old connections when the group switches: on.

Step 4: The route

Policy routes › Add policy route: the devices (an address object), destination any, Send via the group, and move it to the top. See Send your TVs through a VPN and Send chosen websites and torrent traffic through a VPN.

Step 5: Read the states

Network › Policy routing › Gateway groups shows each member:

• active: connected and carrying the traffic;
• ready: connected (the first working tunnel of another provider), standing by to take over at once;
• standby: idle, not connected: no handshake, no keepalive, no pings;
• failed: woken but did not answer; hover for the reason, for example no handshake within 10 s: key not accepted? or the monitor stopped answering.

VPN › WireGuard › Tunnel status shows the same from the tunnels' side: only the connected tunnels are online with a recent handshake; the standby ones show never and send nothing.

What happens when a tunnel fails

Tested on the test firewall with four provider servers (two NordVPN, one with an expired key, one IPVanish):

1. NordVPN Seattle stops answering: after its monitor misses 3 pings (3 seconds with a 1-second check), the traffic moves at once (0.1 s) to the ready IPVanish tunnel; the old connections are cleared.
2. In the background, the next NordVPN tunnel (Dallas) is woken; its key is no longer accepted, so it is marked failed within 10 seconds, and Portland is woken and connects.
3. Portland is earlier in your order than IPVanish, so the traffic moves back to NordVPN (Portland); IPVanish stays connected and ready.
4. If every tunnel fails: the kill switch drops the traffic (nothing leaves outside the VPN), or the internet line carries it (fail-safe).
5. A failed tunnel is retried later, one per account, while that account has no working tunnel. In the test, two NordVPN tunnels were never connected at the same time.

In a failover pair

From 1.1.30 the standby firewall keeps all provider tunnels idle; only the active firewall connects. After a failover, the new active firewall starts from your first tunnel of each account.

Good to know

• Detection time is the monitor's: Every (s) × down after. The default (5 s × 3) takes about 15 seconds; a shorter interval reacts faster but may switch on short ping loss.
• Fastest and Load balance cannot be combined with one connection per account: they need every tunnel connected.
• A tunnel you also use elsewhere (another router, a phone with the same file) takes the provider's single connection away; Korthveil then marks it failed. Use separate files (keys) per device.

The pictures are from the test firewall (version 1.1.31) with a simulated provider network.