Does Multipath QUIC Dream of a Next-Generation VPN?
I built an L3 VPN that bonds Wi-Fi, cellular, and satellite links using MASQUE CONNECT-IP over Multipath QUIC.
In an emulated 300 Mbps + 80 Mbps environment, it reached 356 Mbps while preserving the VPN session through link failures.
OpenMPTCProuter is now testing it for integration.
It's 2026. LLMs have come a long way, and they are reshaping one industry after another.
Software engineering is a case in point: the bar for reinventing the wheel has dropped. One person can now bring a project to a usable state in a relatively short time.
As a result, domains that once required the backing of a research project or an entire team are now within reach of individuals.
In times like these, have you ever wondered:
"If we rebuilt a VPN with today's technology, what would it look like?"
I did.
Most VPNs are built around a simple assumption: a tunnel runs over a single link.
Yet the devices around us have changed.
Smartphones have both Wi-Fi and 4G/5G.
Wi-Fi-equipped laptops are often plugged into wired Ethernet.
Dual-SIM devices are no longer rare.
Satellite links such as Starlink have also become far more accessible. Services such as Starlink Direct to Cell are beginning to connect ordinary smartphones directly to satellites in some countries. They are not yet equivalent to conventional terrestrial 5G links, but Starlink says its upcoming Mobile Gen 2 satellites will deliver terrestrial-like, LTE-level speeds directly to unmodified phones.
Amazon has also entered the NTN (non-terrestrial network) market with Amazon Leo. This segment is likely to keep growing, and using satellite and terrestrial cellular connectivity together outdoors may become increasingly common.
In other words, devices with access to multiple links are already commonplace, and they are likely to become even more so.
So what happens if we build a VPN that uses all of them at once?
Traditional VPNs assume a single link
WireGuard, OpenVPN, IPsec — the widely used VPNs each have their strengths. But what I want to focus on here is not their cryptography or performance.
It is something more fundamental: one VPN session generally uses one network path at a time.
Say a smartphone has two internet connections: Wi-Fi and 5G.
A regular VPN conceptually looks like this:
Application -- VPN +---- Wi-Fi
If you want to use 5G too, you have to switch paths.
But if both links exist anyway, you should really be able to do this:
+---- Wi-Fi
|
Application -- VPN +---- 5G
|
+---- Starlink
Using multiple links at once gives you two big benefits.
One is bandwidth aggregation. If Wi-Fi gives you 100 Mbps and 5G gives you 80 Mbps, combining them can potentially deliver more throughput than either link alone.
The other is fault tolerance. If Wi-Fi suddenly drops or 5G quality collapses, communication continues over the remaining paths.
None of this is a new idea, by the way.
Technologies and products that bond multiple links — including MPTCP and proprietary products such as Speedify and Peplink — have existed for a long time.
MPTCP in particular splits one TCP connection into multiple subflows so it can use several network paths at once, and it has a long history.
So the underlying problem,
"treat multiple physical links as one logical connection,"
already has a long history of research and implementation.
Meanwhile, if you look at internet transport in recent years, TCP is no longer the only option: QUIC has come into wide use.
QUIC is a transport protocol implemented on top of UDP, and it serves as the foundation of HTTP/3.
Unlike TCP, it is usually implemented in user space, and the protocol itself includes features built for the modern internet: encryption, stream multiplexing, and connection migration.
The property that matters here is connection migration: a connection can survive a change of network path mid-session.
For example, when a smartphone moves from Wi-Fi to 5G and its IP address changes, QUIC keeps the same connection alive and communication continues seamlessly.
That raises a question.
If we can seamlessly switch from Wi-Fi to 5G, why can't we use Wi-Fi and 5G at the same time?
Bringing that idea to QUIC is what Multipath QUIC is.
Multipath QUIC
Multipath QUIC is an extension of regular QUIC that lets it use multiple links, or paths. Its relationship to QUIC is analogous to that of Multipath TCP to TCP.
In regular QUIC, one connection generally uses one network path at any given time.
In Multipath QUIC, one QUIC connection can hold multiple paths.
Path 1: Wi-Fi
/
Client ===== QUIC Connection ===== Server
\
Path 2: 5G
From the application's point of view, it is a single QUIC connection.
But the packets that make up that connection can be sent over multiple network interfaces.
That makes it possible to use Wi-Fi and 5G simultaneously, aggregate the bandwidth of multiple links, prefer whichever link has better quality, and shift traffic to another link when one dies.
That brings us back to the VPN question at the start.
Could we use Multipath QUIC as the transport for a VPN, and get a VPN that uses multiple links at once?
That's the idea.
But Multipath QUIC alone does not make a VPN.
QUIC alone does not make an IP tunnel
QUIC is a transport protocol for moving application data between endpoints. What a VPN wants — an L3 VPN, at least — is to tunnel arbitrary IP packets across another network.
Of course, you could always shove raw IP packet bytes into QUIC with your own framing.
But then you would have to design the encapsulation format, address assignment, and tunnel establishment yourself.
This is where MASQUE comes in.
MASQUE is a family of specifications for proxying or tunneling UDP, IP, and other traffic over HTTP. There is CONNECT-ETHERNET for L2 tunnels, CONNECT-IP for L3 tunnels, and CONNECT-UDP and CONNECT-TCP for L4 tunnels — specifications covering several layers of the stack. Of these, CONNECT-UDP (RFC 9298) and CONNECT-IP (RFC 9484) are published RFCs, while CONNECT-ETHERNET and CONNECT-TCP are, as of this writing, Internet-Drafts still going through standardization. An L3 VPN needs L3 forwarding, so CONNECT-IP looks like the right tool.
MASQUE CONNECT-IP (RFC 9484)
RFC 9484 standardizes CONNECT-IP as a protocol for building IP tunnels over HTTP.
The RFC explicitly lists remote-access and site-to-site VPNs as use cases, so it is remarkably close to what we want here.
In CONNECT-IP, the client uses an HTTP CONNECT request to establish a tunnel to an IP proxy.
Once the tunnel is up, IPv4/IPv6 packets can be forwarded through it, packet by packet.
When running over HTTP/3 (QUIC), IP packets are carried as HTTP Datagrams. CONNECT-IP reserves Context ID 0 for regular IP packets, and the payload contains a full IP packet starting from the IP Version field.
Conceptually, it is quite simple.
CONNECT-IP Tunnel
Client Server
| |
| ---- IPv4 / IPv6 Packet --------> |
| <--- IPv4 / IPv6 Packet --------- |
| |
Looking at the transport stack:
IP Packet
|
+--> CONNECT-IP --> HTTP Datagram --> HTTP/3 --> QUIC --> UDP/IP
What's interesting is that CONNECT-IP does not merely define a format for stuffing IP packets into HTTP Datagrams.
Sending packets is not enough to build a VPN.
The client needs to know
"which IP address am I supposed to use?"
and it needs routing information:
"which destinations should be sent into this tunnel?"
CONNECT-IP defines capsule-based mechanisms for these too.
ADDRESS_REQUEST and ADDRESS_ASSIGN let tunnel peers request and assign IPv4/IPv6 addresses or prefixes.
And ROUTE_ADVERTISEMENT lets a peer announce, for the entire IPv4 address space or specific IP ranges,
"packets for these destinations may be sent to me."
So CONNECT-IP provides ADDRESS_REQUEST, ADDRESS_ASSIGN, and ROUTE_ADVERTISEMENT for the control plane, while carrying IP packets in HTTP Datagrams on the data plane. Together, these are the building blocks of an IP tunnel.
At this point we have most of what a VPN needs.
Create a TUN interface on the OS side and feed the IP packets it produces into CONNECT-IP, and the stack looks like this:
Application → TCP / UDP → IP → TUN → CONNECT-IP → HTTP Datagram → HTTP/3 → QUIC
That is an L3 VPN.
The part that matters here is the QUIC layer at the bottom.
So far this has been regular QUIC.
What happens if we swap it for the Multipath QUIC described earlier?
CONNECT-IP over Multipath QUIC
The structure becomes:
Application → TCP / UDP → IP → TUN → CONNECT-IP → HTTP Datagram → HTTP/3 → Multipath QUIC
├──→ Wi-Fi
├──→ 5G
└──→ Starlink
To the upper layers, it is one ordinary IP tunnel.
Neither the application nor the TCP/UDP flowing through it needs to know how many physical links are underneath.
But the Multipath QUIC connection carrying that tunnel has multiple paths below it.
So traffic on a single VPN connection can be spread across links:
IP Packet A -> Wi-Fi Path
IP Packet B -> 5G Path
IP Packet C -> Wi-Fi Path
If the Wi-Fi path becomes unusable, communication continues on the same QUIC connection over the remaining 5G path.
In short,
CONNECT-IP handles "what to tunnel," and Multipath QUIC handles "which physical paths carry that tunnel."
That division of labor is what makes this architecture interesting.
CONNECT-IP itself never needs to learn concepts like "Wi-Fi," "5G," or "Starlink."
The upper layers keep a single IP tunnel while the transport layer below uses multiple network paths.
To summarize:
CONNECT-IP -> L3 tunneling
HTTP/3 -> tunnel transport
Multipath QUIC -> multiple path management
Wi-Fi / 5G / Starlink -> physical network paths
With this stack, you can run MASQUE CONNECT-IP over Multipath QUIC to build a multipath VPN.
The theory is quite clean. Some of you are probably thinking: surely someone has already thought of this.
The MASQUE + Multipath QUIC idea has been around for a while
The idea itself — "Run MASQUE CONNECT-IP over Multipath QUIC, and you could build a link-bonding VPN" — is not new.
At the QUIC Multipath Interim held in 2020, Google's David Schinazi gave a presentation aptly titled "MASQUE & Multipath". Schinazi is also one of the authors of the early MASQUE Internet-Drafts.
The slides show a design where the QUIC leg from the client to the MASQUE HTTP/3 proxy is made multipath.
Conceptually:
Wi-Fi
/ \
Client ===== Multipath QUIC ===== MASQUE Proxy ----- Internet
\ /
5G
That is, give the client-to-proxy segment multiple network paths. The slides note that multipath itself was out of scope for MASQUE, while explicitly discussing how MASQUE could benefit from it.
In 2020, CONNECT-IP was still at the requirements-discussion stage, but the slides already introduce it as "a protocol for VPN over HTTP/3."
So the idea
CONNECT-IP + Multipath QUIC = Multipath VPN
was already on the table.
Did Google then go and productize it? That's where the story gets more complicated.
But Google walked away from Multipath QUIC
Years before the current IETF Multipath QUIC work, Google experimented with multipath support in gQUIC, its pre-standard QUIC implementation used by Chromium. This was an earlier, different design — not an implementation of the Multipath QUIC draft discussed in this article.
Google later removed that experimental support from Chromium.
In 2021, when asked on the Chromium net-dev mailing list about the state of Multipath QUIC, David Schinazi explained that it was removed because it did not yield good enough results and required significant complexity.
An Internet-Draft summarizing the QUIC multipath discussions of that era puts it similarly: Google stopped working on multipath and chose to focus on connection migration, which was what users were actually asking for.
For anyone thinking about Multipath QUIC, this is a sobering data point.
Even at Google's scale, the benefits didn't justify the complexity. So it's natural to wonder:
"Maybe Multipath QUIC just isn't practical?"
But I think there is a major difference in use case hiding here.
In a browser it's a nice-to-have; in a multipath VPN it's the whole point
My hypothesis is that multipath never mattered much to Chrome, the flagship product of Google's QUIC team.
Web pages load just fine over regular single-path QUIC.
From a browser's perspective, multipath is a bonus feature.
If a modest performance gain costs you substantial complexity in the protocol, path management, schedulers, and congestion control, it isn't worth it — and Schinazi's comment makes perfect sense.
On top of that, MPQUIC only works if the web server on the other end supports it. Native support in general-purpose servers such as Nginx, Apache, or LiteSpeed would require a compelling use case. For ordinary web browsing alone, the motivation to adopt MPQUIC does not appear especially strong.
A multipath VPN is a different story.
Take a user with three links:
Wi-Fi 100 Mbps
5G 80 Mbps
Starlink 150 Mbps
If the entire reason they run a VPN is
"I want to bond these,"
then multipath is not a bonus feature. It is the core feature.
At minimum, simultaneous bandwidth aggregation is impossible without multipath. Keeping several paths active for failover is also a core requirement of this kind of VPN.
So Google's Chromium-era question,
"is multipath worth this much complexity?"
may get a different answer for the VPN use case.
What was a bonus in a browser becomes, in a multipath VPN, the central mechanism that turns
"I can only use my 100 Mbps Wi-Fi"
into
"I can use Wi-Fi + 5G + Starlink all at once."
Same Multipath QUIC; different place; different return on complexity.
And compared with 2020, CONNECT-IP is now a published RFC, and devices with multiple internet connections — Wi-Fi, 5G, satellite — are everywhere.
So, in 2026, I decided to find out for myself:
What happens if you implement MASQUE CONNECT-IP + Multipath QUIC as a VPN?
Can it really bond the bandwidth of multiple links? When a link dies, does communication really continue on the same VPN connection?
And above all: can it work as a VPN you use daily, not just a research prototype?
Building a Multipath QUIC VPN
So earlier this year, I started building mqvpn in my spare time.
The goal is straightforward:
An L3 VPN that combines multiple internet connections into one logical link, providing bandwidth aggregation and failover.
For a device with Wi-Fi and 5G:
Wi-Fi
/ \
Application -- mqvpn ---- Server ---- Internet
\ /
5G
IP packets from the TUN interface are encapsulated with CONNECT-IP and sent via HTTP/3 DATAGRAM over Multipath QUIC.
There is a single QUIC connection with multiple paths underneath.
So traffic can be spread across links while keeping the same VPN connection.
Put that way, it sounds as though using Multipath QUIC automatically bonds your links and adds up their bandwidth.
It does not.
The bandwidth of multiple links does not simply add up on its own.
This is where the genuinely hard part of multipath begins.
The heart of multipath: which link do you send on?
The hard part of a multipath transport is not creating multiple paths.
The hard part is deciding
which packet to send, when, on which path.
Say you have two links:
Wi-Fi
RTT: 20 ms
Bandwidth: 100 Mbps
5G
RTT: 60 ms
Bandwidth: 30 Mbps
Naively you might alternate:
Packet 1 -> Wi-Fi
Packet 2 -> 5G
Packet 3 -> Wi-Fi
Packet 4 -> 5G
In practice it is not that simple.
Packet 3, sent later on Wi-Fi, may arrive before Packet 2, sent on 5G.
Split traffic 50:50 across a 100 Mbps link and a 30 Mbps link, and the 30 Mbps side congests first.
In real networks, RTT, bandwidth, congestion windows, loss, and jitter all change over time. On wireless networks — Wi-Fi, cellular, satellite — those changes are anything but negligible.
A multipath transport therefore has to decide how to distribute traffic across paths based on the observed network state.
The component that does this is the path scheduler.
The spec does not define the scheduler
So does the Multipath QUIC specification define an algorithm for us — perhaps "prefer the path with the lowest RTT," or "given 100 Mbps and 50 Mbps paths, send packets at a 2:1 ratio"?
No.
What the current Multipath QUIC specification defines is the machinery for creating, identifying, managing, and simultaneously using multiple paths within one QUIC connection.
Which traffic goes on which path — the scheduling policy itself — is out of scope. As of this writing, the Internet-Draft (draft-ietf-quic-multipath-21, approved by the IESG and awaiting RFC publication) states explicitly that it does not specify how applications schedule traffic across paths, and that no IETF specification defines a scheduler for using multiple paths simultaneously.
In other words, Multipath QUIC documents how to
make multiple roads usable
but not
how to use those roads for better performance or robustness.
From here on, it's the implementation's job.
Building mqvpn taught me that this blank space is a far bigger problem than it looks.
Challenge 1: how do you actually aggregate bandwidth?
One of the most obvious schedulers picks the path with the smallest RTT.
mqvpn has a minrtt scheduler.
Given
Path A: 300 Mbps / RTT 10 ms
Path B: 80 Mbps / RTT 30 ms
it nearly always picks Path A.
For minimizing latency, that is reasonable.
But the problem we want to solve is bonding links for aggregate bandwidth.
While Path A is being used exclusively, Path B's 80 Mbps of spare capacity goes unused.
For bandwidth aggregation, mqvpn implements its own WLB (Weighted Load Balancing) scheduler, which is now the default. I'll cover its design in detail in a separate post. Instead of picking paths 1:1, WLB distributes traffic in proportion to each path's capacity.
Even then, blindly spraying packets across paths is not the answer.
mqvpn's WLB currently treats TCP and UDP differently:
WLB
TCP Flow A -----------------> Path 1
TCP Flow B -----------------> Path 1
TCP Flow C -----------------> Path 2
UDP Packet 1 ---------------> Path 1
UDP Packet 2 ---------------> Path 2
UDP Packet 3 ---------------> Path 1
TCP gets flow affinity based on the 5-tuple: a given TCP flow generally stays pinned to one path. UDP is not pinned; its packets can be distributed across paths individually. There is a reason for the difference.
Scattering TCP packets carelessly across paths with different RTTs can cause substantial reordering at the receiver and hurt the inner TCP connection.
For TCP, then, mqvpn retains flow affinity and aggregates bandwidth by spreading multiple TCP flows across multiple paths.
Here is how that performs in mqvpn's current benchmarks in an asymmetric two-path environment:
The following results come from a same-host testbed that emulates link conditions with Linux network namespaces and traffic control. They are not measurements from real heterogeneous access networks; they are intended to compare forwarding modes and schedulers. The full setup is documented in the benchmark report.
Path A: 300 Mbps / 10 ms
Path B: 80 Mbps / 30 ms
Theoretical Max: 380 Mbps
With 16 TCP streams, the results are:
MinRTT : 263 Mbps
WLB : 319 Mbps
WLB delivers about 21% more throughput than MinRTT.
That is roughly 84% of the 380 Mbps theoretical maximum.
So far, so good.
Then the next problem showed up.
Challenge 2: bonding bandwidth breaks packet ordering
For UDP, if WLB aggressively distributes packets across paths, even a single flow can use multiple links' bandwidth.
But send
Packet 1 -> Path A
Packet 2 -> Path B
Packet 3 -> Path A
over
Path A: RTT 20 ms
Path B: RTT 60 ms
and they may arrive as
Packet 1
Packet 3
Packet 2
Recall mqvpn's structure:
Inner IP Packet -> CONNECT-IP -> HTTP Datagram -> Multipath QUIC
CONNECT-IP packets ride in QUIC DATAGRAM frames.
QUIC streams restore ordering at the receiver by design, but DATAGRAM frames have no offset-based in-order delivery mechanism.
So IP packets shuffled across paths come out of the tunnel in exactly the order in which they arrived.
This becomes a real problem when a congestion-controlled protocol — QUIC, say — runs inside the VPN.
Packets sent as
1, 2, 3, 4, 5
may be delivered to the inner QUIC as
1, 3, 5, 2, 4
If the reordering exceeds the packet or time thresholds tolerated by the inner QUIC's loss detection (RFC 9002, Section 6.1), packets can be declared lost even though they are merely late. That can trigger unnecessary retransmission and reduce the congestion window.
The result:
using two links is slower than using one
— about the saddest outcome a multipath system can produce.
And it isn't just theoretical.
When I ran a single inner QUIC flow through mqvpn, throughput collapsed in environments with jitter or cross-path RTT differences.
Countermeasure: reorder at the tunnel exit
So mqvpn gained a reorder buffer.
The idea is simple.
Instead of handing IP packets up immediately at the tunnel exit, mqvpn holds them briefly in per-flow buffers.
Arrival
1 -> deliver
3 -> hold
4 -> hold
2 -> gap filled
↓
1 -> 2 -> 3 -> 4
If the late packet arrives within a deadline, packets are put back in order before being written to TUN.
It doesn't wait forever for a missing packet:
wait a bounded time
|
+-- packet arrives -> reorder and deliver
|
+-- timeout -> give up, deliver what we have
The buffer size is also capped.
This adds no reliability. It is a mechanism that
trades a little latency and buffer space for the ability to absorb inter-path delay differences.
Of course, waiting longer is not automatically better.
Enabling the reorder buffer when paths have almost no delay difference only adds pointless waiting.
That is why the reorder buffer defaults to OFF in the current version of mqvpn and can be enabled for flows that need it.
Results: where the reorder buffer helps, and where it hurts
To characterize this behavior, I evaluated mqvpn with a single inner HTTP/3/QUIC flow across combinations of RTT, jitter, loss, and bandwidth conditions.
The results were genuinely interesting.
With nearly symmetric paths and no jitter:
Best Single Path : 40.6 Mbps
WLB : 73.9 Mbps
Bandwidth aggregated cleanly with no reorder buffer at all.
Enable the reorder buffer in this same environment and throughput drops to about 58 Mbps.
Trying to reorder when nothing needs reordering makes you slower.
Add jitter, and the picture inverts.
With 20 ms of jitter:
Best Single Path : 17.4 Mbps
WLB + Reorder OFF : 0.9 Mbps
WLB + Reorder ON : 37.6 Mbps
With WLB alone, cross-path reordering all but destroys the inner QUIC; add the reorder buffer and two-path aggregation works again.
So sending across multiple paths with WLB was not enough by itself.
WLB
|
| multiple paths usable
v
Cross-Path Reordering
|
| inner protocol mistakes it for loss
v
Throughput collapse
|
| tunnel-side reorder buffer
v
Aggregation restored
Only with all of this does a multipath tunnel start to become practical.
But there are more problems.
Challenge 3: asymmetry that even the reorder buffer cannot fix
Does the reorder buffer let you bond any two links cleanly?
Unfortunately, no.
Consider links with very different characteristics:
Fiber : high bandwidth / low RTT
LTE : low bandwidth / high RTT + jitter
If WLB eagerly pushes packets onto LTE just because "we have two links," the slow path can drag the fast path down with it.
In mqvpn's reorder-buffer evaluation, WLB managed only about 77 Mbps on the fiber_lte profile, even at its best settings with the reorder buffer enabled. Without the buffer, it collapsed to around 5 Mbps. Meanwhile, minrtt, which prefers the low-RTT path, reached about 212 Mbps, recovering nearly the fiber link's standalone performance.
This brings us back to the MinRTT scheduler from earlier.
minrtt is not "the scheduler that can't aggregate."
Rather:
when paths differ enough, refusing to use the slow path is itself the optimization.
So:
Similar paths
↓
aggressive aggregation with WLB
Jitter / small-to-medium RTT difference
↓
WLB + reorder buffer
Strongly asymmetric paths
↓
MinRTT, prefer the good path
The optimal strategy changes with the network environment.
Until I built this, I did not appreciate how deep this goes.
"Being able to use multiple paths" and "being faster because you use multiple paths" are entirely different problems.
Challenge 4: what about a single TCP connection?
One more problem.
As described above, mqvpn's normal WLB pins each inner TCP flow to one path.
So multiple flows aggregate fine:
TCP Flow A -> Path A
TCP Flow B -> Path B
But a single TCP connection
Single TCP Flow -> Path A
cannot use two paths at once.
Distribute it per-packet and cross-path reordering comes right back.
The current version of mqvpn therefore has one more mechanism: the hybrid TCP lane.
TCP traffic is pulled out of the normal CONNECT-IP datagram lane, terminated on the client side by an embedded TCP/IP stack (lwIP), and relayed to the server as an HTTP/3 stream.
+--> TCP
| |
TUN -> classifier ---+ v
| HTTP/3 Stream
| |
| v
| Multipath QUIC
|
+--> UDP / Others
|
v
CONNECT-IP Datagram
Each QUIC stream provides an in-order byte stream.
Instead of scattering inner TCP packets across paths, we let Multipath QUIC carry one ordered stream.
For a single TCP flow, the difference is dramatic.
In the published benchmarks, with two symmetric paths of 100 Mbps / 25 ms each:
Theoretical Max : 200 Mbps
Single TCP / raw tunnel : 96 Mbps
Single TCP / Hybrid TCP lane: 187 Mbps
A single TCP connection reaches about 93% of the combined theoretical bandwidth.
In an asymmetric environment:
Path A : 300 Mbps / 10 ms
Path B : 80 Mbps / 30 ms
Theoretical Max : 380 Mbps
1 flow 2 flows 8 flows
Raw 261 271 317 Mbps
Hybrid 327 350 356 Mbps
With the hybrid TCP lane, 2+ flows reach about 93% of the theoretical maximum. I attribute much of this to QUIC's stream multiplexing. Each stream has its own ordering space, so waiting for missing data on one stream does not directly block delivery to the application on another. Congestion control and connection-level flow control are still shared, however, so loss on one stream is not completely isolated from the others.
This makes one TCP flow = one QUIC stream a natural mapping. In fact, although it is not multipath, Hysteria 2 — one of the best-known QUIC-based proxies — uses a structurally similar design.
So can the bandwidth really add up?
By now the answer to this question looks a little different.
The answer is not
"use Multipath QUIC, and the bandwidth of multiple links adds up automatically."
In reality, you need to think through:
create multiple paths
|
v
measure each path's characteristics
|
v
distribute via a scheduler
|
v
handle cross-path reordering
|
v
choose a transport mode per flow type
But design all of that well, and you can achieve
300 Mbps
\
+----> over 350 Mbps
/
80 Mbps
through one VPN — throughput that no single physical link could deliver.
In mqvpn's current 300 Mbps + 80 Mbps asymmetric environment, plain WLB reaches 319 Mbps with multiple TCP flows, while the hybrid TCP lane reaches 350–356 Mbps. The latter is about 93% of the 380 Mbps theoretical maximum.
Everything so far has been about "how to go faster" — bandwidth aggregation.
Multipath has one more important property.
Multipath is not just about speed: communication can survive a dying link.
Beyond aggregation: staying connected when a link dies
So far, we've used multiple links to increase throughput.
The other big win of a multipath VPN is failover.
Multipath QUIC holds multiple paths inside one QUIC connection.
+---- Wi-Fi
|
QUIC Connection -+
|
+---- 5G
So when one path becomes unusable, communication continues on the remaining path or paths without re-establishing the connection.
I tested mqvpn with two paths (300 Mbps and 80 Mbps), bringing one interface down mid-transfer.
Cutting the 300 Mbps side:
Before failure : 276 Mbps
After failure : 73 Mbps
Throughput drops to the surviving link's capacity, but the VPN connection and the inner communication session remain established.
Cutting the 80 Mbps side:
Before failure : 274 Mbps
After failure : 264 Mbps
The VPN connection persists and traffic shifts to the remaining path.
When the link recovers, bandwidth aggregation across both paths resumes.
So mqvpn's goal is not merely bigger speed-test numbers.
Bandwidth Aggregation
+
Seamless Failover
The goal is to
turn several imperfect internet connections into one faster, harder-to-break logical link.
This matters most on networks whose quality changes over time — Wi-Fi, cellular, and Starlink.
Where is this useful?
A multipath VPN like mqvpn matters most in environments where no single link can be fully trusted.
Live streaming is the clearest example.
If you want to send an 8 Mbps video feed, but each available link gives you only about 6 Mbps, neither link alone is enough.
Wi-Fi : 6 Mbps ─┐
├─ mqvpn ──> 8 Mbps Streaming
5G : 6 Mbps ─┘
Bonding links can make a transmission possible that no single link could carry.
In live streaming, failover matters as much as aggregation.
At outdoor events or while moving, the quality of Wi-Fi and cellular links is never constant. If the VPN connection survives on one link when the other drops, the impact on the application can be reduced.
Disasters and major outages
The same idea — not trusting a single link — applies beyond live streaming.
Japan launched JAPAN Roaming on April 1, 2026. When a subscriber's carrier becomes unavailable because of a large-scale disaster or network outage, the service can temporarily connect supported devices to another carrier's 4G LTE network.
Under full-roaming mode, supported devices normally connect to the rescue network automatically. Depending on the device and circumstances, users may sometimes need to select a network manually, but end users otherwise have limited control over the switch.
However, the conditions for activating JAPAN Roaming, the rescue carriers, and the authentication and coordination mechanisms are all arranged by the mobile operators. It is not a way for users to bond arbitrary links during normal operation or apply their own failover and bandwidth-aggregation policies.
Multipath transport shifts more of that control toward the end user.
+---- Wi-Fi
|
Application -+---- 5G / LTE
|
+---- Satellite
Given several available access networks, an end-user policy can determine which paths to use, when to switch, and whether to use several simultaneously.
If one path becomes unstable, traffic can fail over to another. If several paths have spare capacity, they can be used together for bandwidth aggregation.
JAPAN Roaming expands the access-network options available during an emergency. Multipath transport, by contrast, is a way for end users to control how the access networks already available to them are used.
Path selection and failover do not necessarily have to remain under the exclusive control of network operators. End users can also combine the links available to them and control their own connectivity.
That is one of the worlds I want mqvpn to help enable.
For similar reasons, potential use cases include:
- Autonomous vehicles
- Field robots
- Drones
- Ships
- Remote access
If any of these use cases sound familiar, feel free to contact me at contact@mp0rta.dev.
Moving toward adoption by an existing open-source project
mqvpn is still under active development, but it is no longer merely an experiment running on my own machines. An established open-source project has begun testing it for integration.
One of those projects is OpenMPTCProuter (OMR).
OMR is an OpenWrt-based open-source project designed to bond multiple internet connections with MPTCP.
It has long faced one particularly difficult problem: aggregating bandwidth for UDP traffic.
MPTCP makes a TCP connection multipath, so it cannot carry UDP directly. OMR has offered methods that use V2Ray/XRay and similar tools to place UDP traffic inside a TCP tunnel, allowing it to traverse MPTCP.
Putting UDP traffic inside a TCP tunnel, however, introduces reliable, ordered delivery that UDP does not normally have. If one TCP segment is lost, later data cannot be delivered to the application until retransmission completes. This head-of-line blocking is a poor match for latency-sensitive UDP traffic.
In OMR Issue #3067, a user reported that traffic reaching about 140 Mbps on one WAN fell to roughly 50 Mbps in total when aggregated across three WANs.
In other words, the stack
UDP -> TCP tunnel -> MPTCP -> Multiple WANs
can distribute traffic across links, but in some cases it is slower than using a single link.
In that issue, the OMR maintainer noted in 2024 that packet ordering makes udp2tcp-style approaches problematic and suggested that Multipath QUIC or another UDP multipath mechanism might be the real solution. At the time, he also wrote that no usable implementation was available.
Then, this March — while I happened to be attending Kernel/VM Tankentai @ Tsukuba — I noticed that the OMR maintainer had forked mqvpn. I contacted him and received this reply:
"I tested mqvpn and it works correctly. I'm currently integrating it in OpenMPTCProuter to be able to test it in more case with more users."
mqvpn does not convert UDP traffic into TCP. Instead, it schedules it directly across paths as
UDP / IP Packet -> QUIC DATAGRAM -> Multipath QUIC -> Multiple WANs
This addresses OMR's long-standing problem — TCP can be bonded with MPTCP, but UDP lacks an efficient aggregation mechanism — using a different transport: Multipath QUIC.
I did not have OpenMPTCProuter integration in mind when I started mqvpn. Seeing the project address a problem that real users had faced for years has been one of the most rewarding parts of building it.
Multipath QUIC -> CONNECT-IP VPN -> mqvpn -> OpenMPTCProuter
What began as spare-time protocol research is now connecting with an established open-source project that bonds real links.
For me, this was the point at which the original goal — bringing Multipath QUIC into real-world deployment — first started to feel tangible.
Of course, open problems remain
After reading this far, you might think that bonding every link in sight always yields fast, unbreakable connectivity.
It is not that simple.
As shown above, when paths differ greatly in RTT or bandwidth, forcing both into service can make things worse.
mqvpn juggles
WLB
MinRTT
Reorder Buffer
Flow Affinity
Hybrid TCP lane
but no single scheduler is optimal for every network.
There is plenty of room left for adapting schedulers and policies to network conditions dynamically.
Power consumption is another cost of using multiple links.
Keeping Wi-Fi and cellular active simultaneously on a smartphone obviously consumes more power than using only one interface.
Power-aware policies — engage the second path only when needed, rather than running all paths at full speed all the time — will matter for mobile deployments.
Mobile OSes also don't necessarily let applications use multiple network interfaces freely.
A Linux router where you can bind
eth0
wlan0
wwan0
however you like is a different world from Android or iOS.
How naturally multipath can work within the constraints of VPN APIs, network selection, and background execution is an open question.
So mqvpn is not a project claiming
"Multipath QUIC solves everything."
Rather, building it is gradually revealing the real list of problems that must be solved to make multipath practical.
Why could this be built in 2026?
Back to where we started.
The concepts behind multipath, QUIC, and MASQUE did not suddenly appear in 2026.
Multipath QUIC has been discussed for years, and as noted above, David Schinazi of Google was already proposing a combination of MASQUE and multipath in 2020.
Still, there are reasons I could build this now.
First, the protocol primitives are finally all in place.
QUIC
Multipath QUIC
HTTP/3 Datagram
MASQUE CONNECT-IP
By combining them, you can assemble a multipath VPN from open standards and draft standards without designing a proprietary protocol from scratch.
Second, LLMs have changed the economics of software engineering.
mqvpn touches far more than QUIC:
Network interface control
Path control and state machine
Routing
TUN
HTTP/3
TLS
Multi-platform support (Windows / Linux / macOS / iOS / Android)
Benchmark environments
CI/CD
Covering this much ground alone used to be prohibitively costly.
LLMs will not, on their own, read an RFC, fully understand the protocol, and turn it into a correct end-to-end implementation. Nor will they design a scheduler or conduct performance evaluations without human direction.
But the cost of the surrounding work —
navigating unfamiliar codebases, looking up APIs, writing experimental code, porting to other platforms, and setting up and automating benchmark and test infrastructure, including CI/CD pipelines
— has dropped enormously.
As a result, modifying the protocol stack itself when needed has become a realistic option in areas where the old conclusion would have been "just use an existing library."
That is exactly what I meant at the top by "the bar for reinventing the wheel has dropped."
This does not mean ignoring existing wheels and rebuilding everything. It means that
individuals can now re-examine ideas whose complexity once outweighed their value even for large organizations, building on existing research and open-source software.
mqvpn may be one example of that.
Summary
This post walked through:
Multiple internet connections exist
↓
Want to use them simultaneously from one VPN
↓
Multipath QUIC + MASQUE CONNECT-IP
↓
mqvpn
In practice, building it was never as simple as spraying packets onto two links.
Use multiple paths, and reordering happens.
With bandwidth asymmetry, one side congests first.
With large RTT differences, using the slow path at all hurts.
Bonding a single TCP flow demands yet another mechanism.
In the end, what matters in multipath is
not how many paths you have, but how you use them.
Even so, mqvpn has reached the point where both bandwidth aggregation and failover across multiple links work, and another project has begun testing it for integration.
The goal is not to replace WireGuard or OpenVPN.
If one stable link is all you need, there is no reason to take on multipath's complexity.
But in environments that start out with multiple internet connections —
Wi-Fi + 5G
Fiber + LTE
Starlink + Cellular
— the very premise that
"a VPN is a tunnel over one link"
can be changed.
Not one tunnel over one path, but
one logical connection built on multiple physical paths.
Does Multipath QUIC dream of a next-generation VPN?
After spending the past six months exploring it, I believe the approach has real potential.