Daniel's been thinking about connection bonding again — this time not the travel version, but what it would actually take to build the thing yourself, end to end. He names OpenMPTCProuter as the project everyone points to, and as far as he can tell it's the only serious open-source option. So he wants us to start there: name it properly, say what it is, and then walk through the full requirements on both ends.
The terminology really is a mess. People say "bonding" and mean six different things.
Right. His questions: on the router side, can OPNsense do real bonding or is its multi-WAN just load balancing and failover? On the VPS side — does any cheap box work, or does the aggregation node need specific kernel support, provider network behaviour, something that quietly rules out most budget hosts? He wants the bonding-endpoint-versus-VPN distinction made clear, because he thinks that's where most people get confused. And then the practical question: is there a middle ground between full DIY and Speedify — somewhere that just rents you a preconfigured VPS as the cloud-side bonding node, so you run your own router but don't have to build and maintain the server end yourself?
That last one's going to be a short answer, I think.
I suspect so. Let's start by naming the project properly, because the terminology here is a mess — you just said it, and you're right.
OpenMPTCProuter. OMR for short. It's an open-source router operating system and a VPS-side aggregation server that bonds multiple internet connections at the packet level using something called Multipath TCP — MPTCP. The project is maintained by a developer who goes by Ysurac, has a dedicated wiki, and it's actively developed. It supports Raspberry Pi, x86 hardware, a range of ARM-based routers. And it really is the only open-source project that gives you both pieces — the router firmware and the server-side aggregation — as one coherent system.
Why is it the only one?
Because the problem is genuinely hard in a way that most open-source networking projects don't touch. MPTCP requires kernel-level support. It's not something you can bolt on with a userspace daemon or a clever iptables rule. The router has to run a kernel that can split a single TCP flow across multiple interfaces at the packet level, tag each packet with sequencing information, and then something on the other end has to reassemble those packets in the right order before they hit the public internet. OMR provides both halves of that — a custom OpenWrt-based firmware for the router with MPTCP compiled into the kernel, and a set of scripts and configurations for the VPS that does the reassembly.
And the alternatives people reach for — load balancing, failover — those are not bonding.
Not even close. Load balancing takes multiple connections and distributes them across your available links. Connection one goes out WAN one, connection two goes out WAN two. A single TCP connection never leaves the interface it started on. Failover is even simpler — if WAN one dies, everything moves to WAN two. Bonding means a single TCP stream gets split. Packet one goes out your cable modem, packet two goes out LTE, packet three goes out cable again, and they all arrive at the VPS, get put back in order, and sent onward as if they came from one connection.
So when Daniel asks whether OPNsense can do this —
It cannot. OPNsense's multi-WAN is policy-based routing, load balancing, and failover. It's good at what it does — you can say "traffic from this VLAN goes out WAN one, traffic from that VLAN goes out WAN two," or you can round-robin connections across both links. But it does not include MPTCP support in its kernel. There is no mechanism in OPNsense to split a single TCP flow at the packet level across multiple interfaces. It's a completely different category of thing.
That's the router side. The physical prerequisite Daniel mentioned — two wired uplinks means two NICs — he's right, no amount of software fixes that. But he's assuming the hardware is in place and asking about the software layer. So what does the router actually need?
The router needs to run OMR's own firmware, which is based on OpenWrt. You flash it onto compatible hardware — a Raspberry Pi 4, an old x86 box with a couple of network ports, one of the supported ARM routers — and it gives you a web interface for configuring your WAN connections and your VPS endpoint. The key thing under the hood is the MPTCP-enabled kernel. That's the gate. Without MPTCP in the kernel, the operating system literally does not know how to split a TCP stream across multiple paths. It's not a configuration option you can toggle — it's a kernel compile-time decision.
And OMR ships with that compiled in.
Out of the box. You flash the image, you boot, you have an MPTCP-capable router. The configuration is still nontrivial — you have to set up each WAN interface, point the router at your VPS, configure the tunneling — but the kernel support is there from the first boot.
Which brings us to the VPS side. This is where I think most people nod along and then pick the wrong hosting plan.
The VPS side is the part people most often get wrong. The aggregation node runs on a Linux server — Debian or Ubuntu, per the OMR wiki — and it needs a kernel with MPTCP support. Kernel 5.6 and later have MPTCP in the mainline, but it's not necessarily enabled by default in every distribution's kernel build. OMR's wiki specifies a particular kernel build, and the installation script handles compiling or fetching the right one.
So "any cheap VPS" is not the answer.
It is definitely not the answer. The provider has to allow you to run a custom kernel, or at minimum offer a kernel with MPTCP compiled in. That immediately rules out every OpenVZ-based host. OpenVZ containers share the host's kernel — you cannot load kernel modules, you cannot swap the kernel, you get what the provider gives you. Same problem with LXC containers. You need KVM virtualization, where you get your own kernel and can do whatever you want with it.
Hetzner's CX line is KVM.
Hetzner's CX series is explicitly tested and known to work. You get a KVM virtual machine, you can install your own kernel, the OMR setup script runs without issues. A DigitalOcean droplet also works if you compile the right kernel — it's KVM underneath. But the five-dollar droplet from a budget host running OpenVZ? It will never work, no matter how much you tweak it.
That's the kind of thing that isn't obvious until you've already signed up and spent an evening failing to load a kernel module.
And it's not just the kernel. The VPS becomes a single point of failure and a bandwidth bottleneck. If you bond two hundred-megabit connections, your VPS needs to handle two hundred megabits of throughput — in both directions, because every packet goes through it twice, once inbound from your router and once outbound to the internet. Cheap VPS plans often have shared uplinks that cap out well below what you'd expect. They advertise a gigabit port but the fine print says "shared with two hundred other tenants."
And the geographic location matters.
Enormously. Every packet from your router goes to the VPS, gets reassembled, and then goes out to the internet. If you're in Australia and your VPS is in Germany, you've added about two hundred fifty milliseconds of round-trip latency to every single connection. For web browsing, fine — you probably won't notice. For a video call or a game, it's unusable. The VPS needs to be geographically close to you, or at least on a path that doesn't add significant latency.
So we've got a router running custom firmware with MPTCP kernel support, and a KVM VPS running a custom kernel with MPTCP enabled. That's the hardware and software picture. Now the distinction Daniel wants made clear — why is this not a VPN?
A VPN creates an encrypted tunnel. Your traffic enters one end, gets wrapped in an outer layer of encryption and encapsulation, travels through the tunnel, and gets unwrapped at the other end. The packets inside the tunnel are untouched — the VPN doesn't split them, doesn't reorder them, doesn't care about them at all except to encrypt and deliver them.
And a bonding endpoint?
A bonding endpoint does not encapsulate. It operates at the transport layer. When your router sends a TCP stream through OMR, the MPTCP stack splits that stream into subflows. Subflow one goes out your cable connection, subflow two goes out LTE. Each subflow is a regular TCP connection between your router and the VPS. The VPS receives both subflows, reassembles them into the original stream, and then forwards that reassembled stream to its destination — say, a web server. The web server has no idea the traffic was split across two paths. It sees one connection from one IP address — the VPS's public IP.
So the VPS is presenting a single public IP to the internet.
That's what makes it different from a VPN. A VPN server gives you a different IP address to hide behind, but your traffic is still a single stream through a single tunnel. A bonding endpoint gives you one IP address that represents the combined capacity of multiple connections. The traffic is not encrypted by default — though OMR can layer WireGuard on top if you want encryption. But the core function is multipath aggregation, not tunneling.
That distinction changes what you're paying for. If you think you're setting up a VPN, you might pick the cheapest VPS that can run WireGuard and call it a day. If you understand it's a bonding endpoint, you know you need a VPS that can handle your full combined bandwidth and run a custom kernel.
And the ongoing cost is something people consistently underestimate. Let's put some numbers on this. A Hetzner CX21 — two vCPU, four gigs of RAM, twenty terabytes of monthly traffic — runs about eight euros a month. Sounds reasonable. But if you bond two hundred-megabit connections and actually use them at full tilt, you're moving about sixty-three terabytes a month. That's over three times the included traffic. Hetzner charges for overage. It adds up fast.
What's the Speedify comparison?
Speedify's unlimited plan is about thirty dollars a month. It's a full SaaS — you install their client, it bonds whatever connections are available, and their servers handle the aggregation. You don't configure a VPS, you don't compile kernels, you don't think about any of this. For a lot of people, the thirty dollars is cheaper than the time it takes to build and maintain the DIY version.
But Speedify is the far end of the spectrum. Daniel's asking if there's something in between.
And the answer, as far as I can find, is no. There is no commercial service that rents you a preconfigured VPS as a cloud-side bonding node for you to pair with your own OMR router. The market has exactly two options: full DIY with OMR, where you build and maintain both ends, or full SaaS with Speedify, where you hand everything to them. There's no "I run the router, you run the VPS" middle ground.
Why not?
I think because the people who want this are a tiny niche. The Venn diagram of "willing to flash custom router firmware" and "does not want to manage a Linux VPS" is... probably not huge. Most people who can configure OMR on a router can also follow the VPS setup script. And the ones who can't are better served by Speedify anyway. There's just not enough demand for someone to build a business around preconfigured bonding VPS instances.
Although — the OMR wiki does mention community scripts for one-click deploys on some providers.
There are scripts that automate the VPS setup on Hetzner and a few other KVM hosts. You run a single command and it installs the kernel, configures MPTCP, sets up the firewall rules, and gives you the connection details to plug into your router. That's not quite "rent a preconfigured VPS," but it's closer than compiling everything by hand. You still need to provision the VPS yourself, you still need to maintain it — security updates, kernel updates that might break MPTCP compatibility, monitoring disk usage and bandwidth.
The maintenance is the real cost. Not the eight euros a month, not the Raspberry Pi — it's the evening you lose when a kernel update ships and suddenly your bonded connection is just... two separate connections that don't talk to each other.
And you don't notice until you're on a call and it drops because the LTE modem flapped and the bonding didn't catch it. The OMR wiki is good, but it assumes you're comfortable with Linux networking. If you've never compiled a kernel or debugged an iptables rule, the learning curve is steep. The router firmware is straightforward to flash — that part is easy. The VPS side is where the sysadmin skills come in.
So the barrier isn't the hardware cost or the conceptual difficulty. It's the time commitment to maintain the server side, and the risk that a routine update breaks the whole setup.
And the risk that you pick the wrong VPS provider and waste a weekend on a host that will never work because it's OpenVZ and you didn't know to check. That's the kind of thing that burns people out on DIY networking projects.
Let's talk about what happens when it does work. You've got your OMR router bonding two connections, your VPS is humming along in a nearby data center, everything is reassembled and clean. What does that actually feel like from the user's perspective?
When it works, it's impressive. You pull the cable on one connection and... The stream doesn't blink. MPTCP detects the subflow failure and shifts traffic to the remaining path without dropping the TCP connection. It's not failover with a two-second gap — it's seamless. And when both connections are up, you get the combined throughput. A single file download uses both links. A speed test shows the sum of your connections.
Which is the promise that load balancing can never deliver.
Load balancing can give you aggregate throughput across multiple downloads — you download two files at once, each one uses a different link, total throughput is the sum. But a single download, a single TCP stream, will never exceed the speed of one link. Bonding breaks that limit. That's the whole point.
The catch being that the VPS is now in the critical path for everything. If the VPS goes down, you have no internet. If the VPS is underprovisioned, everything is slow. If the VPS provider has a routing problem, you're affected.
You've traded two single points of failure — your two ISPs — for one single point of failure that you control. Whether that's a good trade depends on how reliable your VPS provider is versus how reliable your ISPs are. For a lot of people with flaky home internet, the VPS is the more reliable piece. Hetzner's uptime is better than most residential ISPs.
And you get a stable public IP, which is its own benefit. More ISPs are moving to carrier-grade NAT — CGNAT — where you don't get a public IP at all. Your router gets a private address and shares a public IP with dozens of other customers. That breaks a lot of things — hosting services at home, certain games, peer-to-peer connections. A bonding VPS gives you a single public IP that you control, regardless of what your ISPs are doing behind the scenes.
That's actually a use case that's growing. People who don't even care about the bandwidth aggregation — they just want a stable public IP and the VPS gives them one, with the bonding as a bonus.
So where does this leave Daniel's question about the middle ground? You said no commercial service exists. Is there anything on the horizon?
MPTCP is in the mainline Linux kernel now — since 5.6, which shipped in early twenty-twenty. That lowers the barrier considerably. You no longer need a custom kernel patchset; you can enable MPTCP on a stock kernel with a couple of sysctl settings. The OMR project has adapted to this, and the setup is simpler than it was a few years ago. But "simpler" is relative — you're still configuring a Linux server.
Could a VPS marketplace offer a one-click OMR deploy?
In principle, absolutely. DigitalOcean has a marketplace with one-click apps for things like WordPress and Minecraft servers. There's no technical reason someone couldn't package OMR's VPS side as a marketplace image. The fact that nobody has done it suggests the demand isn't there — or the people who want it are the same people who would rather build it themselves anyway.
The classic open-source paradox. The users who want the one-click deploy are exactly the users who won't step up to build the one-click deploy.
And the people who could build it don't need it. They're already running the setup script and moving on with their lives.
So the advice to Daniel, if he wants to try this, is: get a KVM VPS from a provider that allows custom kernels, run the OMR setup script, budget time for maintenance, and don't expect anyone to sell you the server side preconfigured.
And pick a VPS location close to you. If you're in Jerusalem, something in Tel Aviv or Frankfurt — not Oregon. The latency matters more than most tutorials let on.
You know what nobody talks about in any of these tutorials?
What?
The modems.
Hm.
All this architecture assumes your uplinks are stable. Two wired connections, sure — cable and DSL, they're fine. But a lot of people bonding connections are using LTE modems. USB dongles, hotspot devices. Those things are not designed for continuous operation. They overheat, they drop carrier, they need to be power-cycled.
That's... actually a much bigger deal than the VPS configuration. The VPS setup is a one-time thing. Keeping two LTE modems alive and connected is an ongoing battle.
I feel like we're about to hear about this from someone who's actually done it.
I think you're right.
Hilbert: The modems. You're all talking about the VPS like it's the hard part. It's not.
Go on.
Hilbert: I ran a little wireless ISP in Vermont — this was twenty-seventeen, twenty-eighteen — serving internet to about six cabins up a mountain. No cable, no DSL. Two LTE modems from different carriers, bonded through an early version of OpenMPTCProuter on a Raspberry Pi 3. Five-dollar-a-month VPS from a provider called PacketPond. They're gone now.
PacketPond. That's a name I haven't heard.
Hilbert: The VPS setup took me an afternoon. The modems took two weeks. USB LTE dongles — the kind you plug into a USB port and they show up as a network interface. They overheat. Every four hours, like clockwork, one of them would drop the carrier signal. The connection was still there as far as the Pi was concerned — the USB device was still enumerated — but no traffic would pass. I wrote a script that pinged the VPS on each interface separately, and if one failed three pings in a row, it power-cycled that USB port.
USB port power cycling from userspace — that's a specific ioctl call, isn't it?
Hilbert: You echo zero or one to the authorization file in sysfs for that port. Works on most Raspberry Pi models. The problem was the dongles didn't always come back clean. Sometimes they'd re-enumerate as a different interface name. The script had to detect that and update the routing table.
Did you try cooling them?
Hilbert: Zip-tied a forty-millimeter Noctua fan to the Pi's case, blowing across both dongles. Helped — stretched the interval from four hours to about seven. Didn't fix it. The real fix was switching to proper outdoor LTE modems with PoE, mounted on the roof. Those ran for months without touching them. But that's three hundred dollars a unit instead of forty.
So the bonding worked perfectly, and the modems didn't.
Hilbert: The bonding was flawless. MPTCP handled the failover every time the script killed a port. The cabins never noticed. I'd get an alert on my phone, look at the logs, see that modem two had dropped and come back, and nobody on the mountain knew anything had happened. That's the part the architecture diagrams don't show. They draw two clean lines going into a box labeled "router" and assume those lines stay up. They don't.
How long did you run it?
Hilbert: About fourteen months. Then the local electric co-op ran fiber up the mountain and I shut it down. I still have the Pi in a box somewhere. The dongles I threw out. They were cooked.
The physical layer is always where the clean abstractions break down. We talk about MPTCP and kernel versions and VPS providers, and the thing that actually fails is a forty-dollar USB dongle that can't dissipate heat.
A zip-tied Noctua fan is the real unsung hero of DIY networking.
Hilbert: It helped. Didn't fix it. Nothing fixes a USB LTE dongle except replacing it with something that was designed to run continuously. Those things are built for occasional use — plug it into your laptop at a coffee shop, not run it twenty-four seven on a mountain.
And that's the gap between the tutorial and the real world. The tutorial says "connect your LTE modem." It doesn't say "your LTE modem will overheat every four hours and you'll need to write a watchdog script that power-cycles the USB port and handles interface renaming."
Hilbert: Nobody writes that part down because it's not interesting. The VPS is interesting. Kernel compilation is interesting. Babysitting USB dongles is just... work.
That's the whole project, though, isn't it? The interesting parts are a weekend. The work is forever.
Hilbert: The work is until the fiber co-op shows up, if you're lucky.
We've got a project that works — works — but the hard part isn't what the documentation suggests. The VPS setup is solvable, the router firmware is straightforward, and the real friction is the physical layer and the ongoing maintenance. And there's no middle ground between doing all of it yourself and paying Speedify to do all of it for you.
That gap is real, and I don't see it closing soon. The market for "I want to run my own bonding router but I don't want to manage a Linux server" is just too small. The people who care about running their own router are, by and large, the same people who are comfortable with a Linux VPS. And the people who aren't comfortable with a Linux VPS are better served by Speedify anyway.
Although — MPTCP in the mainline kernel does change things. A few years ago you needed a patched kernel on both ends. Now the VPS can run a stock Debian install with MPTCP enabled via sysctl. That's a much lower bar. A one-click marketplace image becomes more feasible when you don't need a custom kernel anymore.
True. The technical barrier is dropping. Whether the market appears is a different question. Someone would need to build the image, maintain it, handle support — and charge enough to make it worth their time, but less than Speedify's thirty dollars a month. That's a narrow window.
Maybe the play isn't a commercial service at all. Maybe it's a community-maintained image on the DigitalOcean marketplace, free to use, unsupported, here's the source if you want to fix something. That's how a lot of these gaps get filled in open source — not by a business, but by someone who got annoyed enough to package it up properly.
That's the thing about OpenMPTCProuter — it's a mature project. The wiki is thorough, the community is active, the developer is responsive. It's not some abandoned repo with a three-year-old last commit. If you're willing to put in the time, it works. The question is whether you want to put in the time, or whether thirty dollars a month to Speedify is the better deal.
Daniel's the kind of person who probably enjoys putting in the time. But he also has a family and a job, and the maintenance overhead is real.
The maintenance overhead is the thing. The initial setup is fun — it's a project. Flashing firmware, provisioning a VPS, watching the speed test show the combined throughput for the first time — that's satisfying. The maintenance is less fun. It's checking logs, applying updates, debugging why one WAN interface is showing packet loss. It becomes part of your home infrastructure, and home infrastructure should be boring.
That's the real trade-off. Not the money, not the technical difficulty — the boredom. Do you want your internet connection to be a project, or do you want it to be a utility?
For most people, the answer is utility. Which is why Speedify exists and why there's no middle ground. The people who want it to be a project want the whole project. The people who want a utility pay someone else.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping us honest about USB dongles.
If you enjoyed this episode, leave us a review wherever you listen — it helps other people find the show. And if you've got a weird prompt of your own, email it to show at my weird prompts dot com. We read every one.
We'll be back soon.
