OpenMPTCProuter: Bonding Multiple Internet Connections on OpenWrt

What OpenMPTCProuter is for, and who it is not for

A single uplink is a single point of failure and a single ceiling. OpenMPTCProuter attacks both at once: it takes several internet connections (the README lists fiber, VDSL, SHDSL, ADSL, 4G and 5G as the kinds of links it is independent of) and presents them as one path, then encrypts the result and exits through a VPS you control. The VPS is what gives you a dedicated public IP, so the remote end sees one stable address instead of a rotating carrier NAT.

The intended user is someone with more than one WAN and a server somewhere: a home or small office with a fiber line plus an LTE backup, a site where the wired link is unreliable, or anyone who wants their traffic to leave through a fixed address. It is not a consumer plug-and-play box. The README points at precompiled images on the project website, but the moment your hardware is not covered, you are in the wiki page about creating an image for an unsupported platform. If you want to bond connections without owning a VPS, this is the wrong shape of tool.

How the aggregation actually works: MPTCP, MLVPN and Glorytun

The mechanism is not a load balancer sitting in front of your router. Aggregation is based on Multipath TCP, and the README describes the result as ISP, WAN type and latency independent, with scenarios configured for either aggregation or failover. That distinction matters: aggregation uses the links simultaneously, failover keeps them warm and switches when one drops. Both are configured on the same MPTCP basis.

Two other transports are named as alternatives: Multi-link VPN (MLVPN) and Glorytun UDP with multipath support. The README credits Shadowsocks among the components the solution is mainly based on, which is consistent with the encryption and obfuscation role those pieces play in the tunnel.

Because the design sits on OpenWrt/LEDE, the router side is not a closed appliance. The README notes that other packages can be installed through the web interface or the terminal: VPN, QoS, routing protocols, monitoring. That is the real architectural bet. The bonding layer is the product, but the platform underneath is a general purpose router distribution you can extend. The cost is that you inherit OpenWrt's operational model, including its package and configuration conventions, rather than a single-purpose appliance UI.

Installing OpenMPTCProuter from a precompiled image

The README gives two paths. The first is the precompiled image: download it from the project website, then write it to an SD card. The commands below are copied from the README. The gunzip step expands the compressed image, and the dd step writes it to the raw device. Replace /dev/sdX with your actual card device; getting that wrong writes over the wrong disk.

gunzip omr-*.img.gz
dd bs=4M if=omr-*.img of=/dev/sdX conv=fsync

After the write completes, the card carries the router image and the device boots into OpenWrt with the OpenMPTCProuter packages. The second path is building from source. The README does not put the build steps in the README itself; it links to a wiki page titled Create image for unsupported platform. That is the honest answer for anyone whose board is not already covered.

Coverage is broad but finite. The repository carries per-board build configs, and the file names are the list: config-rpi2 through config-rpi5, config-x86 and config-x86_64, config-wrt3200acm, config-wrt32x, config-r7800, config-cznic_turris-omnia, config-espressobin, a run of GL.iNet boards (config-gl-mt2500, config-gl-mt3000, config-gl-mt6000, config-gl-x3000, config-gl-xe3000 and others), several Banana Pi R-series configs, config-rutx, config-rutx12 and config-rutx50, and a set of Z8102/Z8109 configs. If your board has no config-* file, you are on the build-from-source path.

The VPS side is a separate repository, and that is the real dependency

OpenMPTCProuter is split across repositories, and the split is not cosmetic. The router images and packages live in openmptcprouter-feeds; the server half lives in a separate repository, openmptcprouter-vps. The README names it plainly as the VPS script part.

This means the thing you install on the router is only half a system. The tunnel needs a termination point, and that termination point is a script you run on a VPS you pay for. Two consequences follow. First, your total cost is the router hardware plus the VPS, and your reliability is the weaker of the two. Second, the VPS is a single endpoint: if it goes down, every aggregated link goes down with it, no matter how many WANs you bolted together. The redundancy you bought at the edge is not redundancy at the exit.

It also means the public IP your clients present is the VPS address. That is the feature (dedicated public IP, net neutrality as the README frames it) and the constraint in one: you are routing your traffic through a machine you must maintain, patch and pay for.

Where OpenMPTCProuter is the wrong tool

The clearest failure mode is the one the architecture guarantees: no VPS, no aggregation. There is no mode in the README where the router bonds links on its own. If you cannot or will not run the server side, the project does not solve your problem at all.

A second limit is the hardware gate. Precompiled images exist for a specific set of boards, and the README does not claim universal coverage. On anything else you build the image yourself, which is a different project in terms of effort.

A third is subtler and worth stating directly: aggregation over links with very different latency is not free. MPTCP can only combine paths it can schedule across, and the README's claim of latency independence is about not requiring matched links, not about hiding the difference. A slow satellite or congested LTE link in the bundle affects what the tunnel can deliver in practice. The README also does not document rollback for a bad flash. If you write the image and the board does not boot, the README offers no recovery procedure; you are relying on the general OpenWrt flashing knowledge you brought with you.

Finally, this is a router distribution, not a service. There is no hosted control plane, no dashboard outside your own device, and no support contract implied anywhere in the README.

How it compares with Speedify, SmoothWAN and Peplink SpeedFusion

The related searches around this project are dominated by Speedify, SmoothWAN, Peplink SpeedFusion and the general phrase internet bonding software. The comparison is worth making concrete because the products differ in where the bonding happens and who owns the exit.

Speedify is a commercial service: the aggregation endpoint is the vendor's, and you are a customer of their network. OpenMPTCProuter inverts that. Your endpoint is your own VPS, running the openmptcprouter-vps script, and the software is GPL-3.0. You trade convenience for control and for the operational work of owning the server.

SmoothWAN is the closest in shape, since it is also a router-side approach rather than a hosted service, but the relevant point for a reader here is narrower: OpenMPTCProuter's aggregation is built on Multipath TCP, with MLVPN and Glorytun UDP as the alternative transports the README names. That is a kernel-level multipath design rather than an application-level tunnel multiplexer, and it is why the project can describe itself as WAN type independent.

Peplink SpeedFusion is commercial hardware with its own bonding implementation. The difference to weigh is not which is faster; it is that OpenMPTCProuter runs on OpenWrt, so the same box that bonds your links can also run your QoS, routing protocols and monitoring packages. If you want a single vendor to own the whole stack, that openness is a liability rather than a feature.

Licence, maintenance and the cost of staying current

The repository is licensed GPL-3.0 and is not archived. The last push to the develop branch was on 2026-09-25, three days before this writing, so the branch is being worked on. The default branch is develop rather than a stable branch, which is worth noting if you intend to build from source: you are tracking the development branch unless you pick a tag deliberately.

There are also CLA files in the repository root, both an individual and an entity version, which means contributions go through a contributor licence agreement. For a user this is mostly invisible, but it does tell you the project intends to hold the rights needed to relicense or dual-license, which is a common arrangement and not a problem in itself.

The upgrade cost is the part people underestimate. This is not a package you bump with a single command on a running system; the primary install path in the README is a full image written to storage. Staying current means reflashing or rebuilding, and the README does not document an in-place upgrade path. Budget for taking the router offline and for having a spare card or a recovery method before you start. On the licence side, GPL-3.0 governs the code you receive; what your ISP or VPS provider thinks about a bonded, encrypted tunnel exiting from a datacenter is a separate question that no licence answers, and it is worth checking before you build the whole thing.

Editorial conclusion

Adopt OpenMPTCProuter if you already run a VPS, can reflash a supported router, and want your uplinks bonded at the IP layer rather than per application. Do not adopt it if you have no VPS to terminate the tunnel, or if the hardware you own is not in the config-* list and you are not prepared to build an image yourself. Before committing, verify three things on your own setup: that your ISP does not block the tunnel transport, that the VPS provider permits the traffic, and that the per-link latency difference between your connections is small enough that aggregation still helps.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. Ysurac/openmptcprouter on GitHub