Two Uplinks but One Tunnel: Failover, Balancing or Bonding
Failover, per-flow balancing and single-flow aggregation are three different promises. Two default routes give you the first, and not the other two.
Two internet lines can make a VPN more available, and they can make it faster for some workloads, but the mechanism decides which of those happens. A router with two default routes is not bonded, and a tunnel carrying thousands of inner connections is still one outer flow. Naming the promise first is the difference between a design and an expensive disappointment. The table below separates the options by what each one needs at the far end and what a link loss does to a transfer.
Three promises, and only one needs a partner
Link failover keeps a path available when the preferred link disappears. Flow-hash balancing spreads independent flows over both uplinks. Single-flow aggregation lets one transfer use both links at once. Those are different products with different requirements, and only the last one needs cooperation from something beyond your router.
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
Nothing in that table is a reason to buy a second line. What it does is stop a failover design from being evaluated as if it were bonding.
Why a tunnel looks like a single flow to the router
A load-balancing router hashes source and destination addresses together with ports, then sends the whole flow where the hash points. A VPN tunnel is one such flow from the router's perspective, whatever runs inside it. Inner connections never reach the hashing decision, because the outer header already decided the path. That is why a second uplink can double total capacity for many users and change nothing for one user's large transfer.
Two separate tunnels can give you two candidates, but they still need an intentional policy that assigns traffic and keeps replies on the path that carried the request. Asymmetric routing is the usual result of skipping that step. A policy that names the flow, the preferred link and the fallback link is the minimum.
Ethernet bonding does not cross unrelated providers, because the far end has to participate in the aggregation protocol. A bond across two ISPs is a research project unless a cooperating endpoint exists.
What multipath TCP needs at both ends
Linux's Multipath TCP documentation describes multiple subflows belonging to one connection. Kernel support at one end converts nothing on its own, since the peer also has to accept those subflows. A proxy at the far side is the other common arrangement, and it becomes a component with its own capacity and availability to plan for. The same logic rules out an easy answer for WireGuard, whose transport is UDP: MPTCP grows TCP subflows and cannot aggregate that tunnel without something else in the design.
Check whether the kernel feature is enabled before designing around it, since many distributions ship it off. These three commands answer that in a minute.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showChoose from the workload, not the brochure
If the workload is many independent sessions, flow-hash balancing can add capacity without far-end cooperation. If it is one large transfer, only an aggregation design will help, and that design needs a cooperating peer. If the requirement is that work continues when a link dies, failover is the answer and the throughput of a single transfer is irrelevant.
Write the requirement in one sentence with a verb in it: one backup finishes twice as fast, or a dropped link does not end a session. Vague goals produce designs nobody can accept or reject. Then decide what the far end is allowed to be, because the cheapest option is often the one that requires nothing new there. That constraint eliminates most of the brochure claims before the first meeting.
Keep the three promises separate in the requirement document. A design that claims all three usually delivers one and quietly assumes the others. The next section tests which one is actually delivered.
Test one transfer and many, then pull a link
Compare one sustained transfer with several parallel transfers to the same destination, and record loss, delay and per-link utilisation for each. A gain only with parallel sessions points at flow distribution, not at single-flow aggregation. Test the loss of one uplink separately, because capacity while both links work says nothing about failover for an established session. Capture the route, the socket and the retransmission counters before and after each test.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5When the single transfer still uses one uplink, the design is doing exactly what a flow hash implies. When parallel transfers spread across both, balancing works and aggregation does not. Record which of the three promises the design actually keeps, and the next capacity conversation starts from evidence instead of a vendor claim.