[Prompt]
custom: eSIMs are fantastic when you're travelling, and one situation almost every traveller hits is an iffy | Hosts: corn, herman

[Response]
Corn: You land, you open your laptop, and the Wi-Fi password the front desk gave you might as well be a dial-up modem from 1998. The Ethernet port in the wall is a hundred years old and nobody knows where it goes. And you've got a video call in twenty minutes. Every traveller knows this moment.

Corn: Daniel's been thinking about this from the build side. eSIMs solved the physical SIM problem — you don't need to hunt down a shop anymore. But the real challenge is bonding. Taking that dodgy hotel Wi-Fi, maybe a wired connection if you're lucky, and a couple of cellular links, and turning them into one pipe that doesn't drop when one of them chokes. He wants specifics. Which GL.iNet routers actually have eSIM right now, what they cost, whether Speedify is the practical answer for bonding, and — this is the part I hadn't thought about — whether you can rent a preconfigured remote bonding endpoint instead of building your own VPS. So let's start with the box itself. What can you actually buy right now that does eSIM?

Herman: The short answer is: not many. But the ones that do are genuinely good. GL.iNet is the obvious starting point, and the model you want is the GL-E5800 — they call it the Mudi. It's got a built-in eSIM slot and it also takes a physical SIM, so you're covered either way. Current price is right around two hundred ninety-nine dollars. There's also the newer GL-E750, the Mudi V2 — same deal, eSIM plus physical SIM, and that one comes in at about a hundred ninety-nine.

Corn: So the V2 is cheaper than the original?

Herman: Yeah, which is unusual. I think they streamlined the manufacturing. The E5800 has a slightly bigger battery and a screen on the front — the E750 dropped the screen to cut cost. But for our purposes, they're functionally identical. Both run OpenWrt under the hood, both have the eSIM chip. Now, here's where people get tripped up — and Daniel asked for specifics, so let's be specific. The GL-XE300, the Puli, has a physical SIM slot. It does not have eSIM. The GL-SFT1200, the Opal, and the GL-MT1300, the Beryl — neither of those has eSIM either. The eSIM feature is only in the E-series. If you're shopping and it doesn't start with E, it doesn't have eSIM.

Corn: That's the kind of thing you learn after you've already bought the wrong one.

Herman: And it's not clearly labelled on every Amazon listing. The other contender worth mentioning is Peplink. The BR1 Pro has eSIM support, but you're paying five hundred forty-nine dollars for it. It's a more rugged, enterprise-grade box — metal chassis, designed for vehicles. If you're outfitting a van or a boat, that's your pick. If you're a person with a backpack, the GL.iNet is the sweet spot.

Corn: And then there's Cradlepoint, which is basically if you want to spend a thousand dollars and also need a corporate purchasing agreement.

Herman: Right, the IBR series. Not a consumer product. So that's the hardware landscape. Now, the eSIM provisioning on these routers — it's not quite as smooth as a phone. On the GL.iNet, you log into the router's web admin panel, go to the cellular settings, and scan a QR code from your provider — Airalo, Ubigi, whoever you're using. The router downloads the profile and activates it. It works, but you're managing it through a web interface rather than a polished app. And you need to make sure the firmware is up to date, because early eSIM implementations on these boxes were temperamental.

Corn: I've used Airalo on a phone and it's dead simple. The router step sounds like it adds just enough friction to be annoying at the wrong moment.

Herman: It does. The other thing to know is that the eSIM profiles are stored on the chip itself, which is soldered to the board — you're not swapping anything physical. You can store multiple profiles, but only one can be active at a time. If you want to bond two cellular connections, you're still going to need a second cellular source — either a second router, or you tether your phone to the router over USB or Wi-Fi.

Corn: Which brings us to the actual bonding part. Because the hardware is only half the story. You can have a router with eSIM and Wi-Fi as WAN and Ethernet as WAN, but without bonding, you're just switching between them when one drops.

Herman: And that's the fundamental thing to understand. Failover is not bonding. Failover is: connection A goes down, the router notices, it switches to connection B. There's a gap — maybe a few seconds, maybe more. Bonding is: packets are flowing across A and B simultaneously, and if A drops a packet, B has it covered. You get bandwidth aggregation and redundancy at the same time.

Corn: So the question Daniel's really asking is: what's the practical path to bonding on a travel router? And the answer, in 2026, is still mostly Speedify.

Herman: It is. Speedify is the most accessible bonding solution by a wide margin. It runs on Linux, macOS, Windows, iOS, Android. The key question is whether you can run it on a GL.iNet router. The answer is yes, but with caveats. GL.iNet routers run a modified version of OpenWrt. You can SSH into them and install Speedify's command-line client. It's not a one-click install — you need to be comfortable with a terminal. And you need enough storage. The E5800 has five hundred twelve megabytes of flash, which is tight but workable. The E750 has the same. You'll want an SD card in the slot for extra breathing room.

Corn: So you're SSHing into a travel router, installing a CLI tool, and configuring bonding profiles by hand. This is not a consumer product.

Herman: It's not. But it's also not impossible. If you can follow a tutorial and you're not afraid of a command line, you can do it in an afternoon. What Speedify gives you is per-packet bonding across up to five connections. It splits your traffic into individual packets, sends them down different pipes, and reassembles them at the other end. It also uses forward error correction — it sends redundant packets so that if some get lost, the receiver can reconstruct the missing ones without waiting for a retransmission. That's what makes it feel seamless. You're on a video call, one connection drops fifty percent of its packets, and the call doesn't even stutter.

Herman: The catch is the pricing. The free tier is two gigabytes a month — that's nothing. The unlimited plan is forty-nine ninety-nine a month, or two ninety-nine a year if you pay annually. And that's for using Speedify's own cloud servers as your bonding endpoint.

Corn: Which brings us to the remote endpoint question. Because when you bond connections, the packets have to be reassembled somewhere. Speedify's default is their own servers. But Daniel's asking whether there's a way to rent a preconfigured endpoint, or whether you have to build your own VPS.

Herman: There are a few options. Speedify themselves offer something called Self-Hosted Bonding — it's a nine ninety-nine a month add-on that lets you run a Speedify server on your own VPS. So you're still paying for Speedify, but your traffic goes through a server you control. You spin up a Linux VPS, install the Speedify server package, and point your travel router at it. That's the middle ground between fully managed and fully DIY.

Corn: And then there's the fully open-source path.

Herman: Right. OpenMPTCProuter. This is a preconfigured Linux image that does multi-path TCP aggregation. It's available as a one-click deploy on DigitalOcean, Vultr, and Hetzner. You pick your provider, deploy the image, and you've got a bonding endpoint. On the client side, you run OpenMPTCProuter on your travel router — and yes, you can flash it onto a GL.iNet box, because it's OpenWrt-based. The cost for the VPS side: a basic Hetzner CX22 is three euros ninety-nine a month. The trade-off is that OpenMPTCProuter is more complex to configure than Speedify. It's not a polished commercial product — it's a community project. But it works, and it's free aside from the VPS cost.

Corn: So your options are: Speedify with their servers at fifty bucks a month, Speedify with your own VPS at sixty a month total, or OpenMPTCProuter at four euros a month plus your own time and expertise.

Herman: That's the spectrum. And there's also Peplink's SpeedFusion, but that requires Peplink hardware at both ends — you'd need a BR1 Pro on the road and another Peplink box at home or in a data center. It's the most polished solution, and also the most expensive. We're talking over a thousand dollars in hardware before you even start.

Corn: Let me pull on the VPS thread for a moment, because Daniel specifically asked about preconfigured services — something you can rent rather than build. Is anyone actually selling a turnkey bonding VPS? You go to a website, pay ten bucks a month, and they hand you an endpoint?

Herman: Not really, and that's interesting. There's a gap in the market. Speedify's self-hosted add-on is close — you're renting the software capability and bringing your own VPS. OpenMPTCProuter is a one-click deploy, which is almost turnkey, but you still need to configure the client side and manage the firewall rules. Nobody has packaged the whole thing as "here's your bonding endpoint, here's your client config, done." I think the reason is that bonding is inherently a two-sided problem — the endpoint needs to know about the client, and the client needs to know about the endpoint. It's not like a VPN where you can just hand out a config file and it works generically.

Corn: So if you want the easy path, you pay Speedify for their cloud servers. If you want control and lower cost, you build it yourself. The middle ground — a preconfigured service you can rent — doesn't really exist yet.

Herman: Not in a polished form. And that's partly because the market for this is tiny. Most travellers are fine with a single cellular connection and maybe hotel Wi-Fi. The number of people who need bonded multi-WAN on the move is... us. And a few thousand other weirdos.

Corn: We are the market. That's both comforting and depressing.

Herman: Let me sketch what the self-hosted VPS path actually involves, since Daniel asked for a second-half overview. You start by picking a VPS provider in a region with good peering to where you'll be travelling. If you're mostly in Europe, Hetzner in Germany is great. If you're in Asia, maybe a Vultr instance in Singapore. You want low latency to your travel destinations because that VPS is going to be reassembling your packets and forwarding them to the internet. If it's far away, you're adding lag to every connection.

Corn: And the VPS itself — what are the requirements?

Herman: Modest. A single CPU core, one gig of RAM, and maybe twenty gigs of storage is plenty. The heavy lifting is just packet reassembly and forwarding. The bandwidth is what matters — you want at least a hundred megabits per second, because you're potentially aggregating multiple connections. The Hetzner CX22 I mentioned is three ninety-nine euros a month and gives you one vCPU, two gigs of RAM, forty gigs of storage, and twenty terabytes of traffic. That's more than enough.

Corn: Twenty terabytes of traffic for four euros a month. The economics of cloud computing are still absurd.

Herman: They really are. So you've got your VPS. You install either the Speedify server or the OpenMPTCProuter image. You configure the tunnel — this is where it gets fiddly. You need to set up the VPN tunnel between your travel router and the VPS, configure the bonding protocol, and make sure the routing table on the VPS knows to forward traffic from the tunnel interface out to the public internet. If you're using OpenMPTCProuter, it handles most of this with its web interface, but you'll still need to set up firewall rules. The VPS needs to accept incoming connections on whatever port your tunnel uses, and it needs to do NAT for the traffic coming out of the tunnel.

Herman: Then on the travel router side, you configure the bonding client to connect to your VPS's IP address. You tell it which WAN interfaces to bond — that could be the eSIM cellular connection, Wi-Fi as WAN from the hotel, Ethernet if you've got it, and maybe a tethered phone as a second cellular link. The bonding software takes over from there. It monitors each link's latency and packet loss, adjusts how it distributes packets, and keeps the tunnel alive.

Corn: And if the VPS goes down, your whole setup is dead.

Herman: Yes. That's the single point of failure. With Speedify's cloud servers, they have redundancy built in. With your own VPS, you have one server in one data center. If it goes offline, your bonded connection evaporates. That's the trade-off for saving forty dollars a month.

Corn: So the self-hosted path is cheaper and gives you control, but you're on the hook when things break. And you need to monitor it.

Herman: You do. And that monitoring is non-trivial. You want to know if the VPS is up, if the tunnel is established, if packet loss is spiking. There are tools for this — Uptime Kuma, Netdata — but now you're running a monitoring stack on top of your bonding endpoint. The complexity compounds.

Corn: Which is why Speedify's fifty bucks a month starts to look reasonable when you factor in the value of your own time.

Herman: It really does. For most people who need bonding, the commercial option is the right answer. The self-hosted path is for people who enjoy the tinkering — or who need capabilities that Speedify doesn't offer, like running the endpoint in a specific country for latency reasons, or avoiding third-party servers for privacy.

Corn: Let's go back to the hardware for a moment. We've established that the GL-E5800 and E750 are the eSIM-capable options. But if you're going to run Speedify or OpenMPTCProuter on one of these, are there any gotchas with the hardware itself?

Herman: The main one is the Wi-Fi as WAN limitation. When you use Wi-Fi as WAN, you're connecting the router to the hotel's Wi-Fi as a client, and then rebroadcasting your own network for your devices. That means you're on a half-duplex medium — the router can't transmit and receive at the same time on the same channel. You're also fighting for airtime with every other device on that hotel network. If the hotel Wi-Fi is already congested, your bonded connection inherits that congestion. The bonding can mask some of it — if the Wi-Fi link drops packets, the cellular link picks up the slack — but you can't fix a fundamentally bad connection.

Corn: And then there's the double NAT problem.

Herman: Yes. The hotel network has its own NAT, and then your travel router adds a second layer. This can cause issues with some protocols, especially anything that expects end-to-end connectivity. VPNs can sometimes struggle with double NAT, though in practice most modern VPN protocols handle it fine. The bonding tunnel itself adds a third layer of encapsulation on top of all of that. It works, but it's not elegant.

Corn: So you're stacking NAT on NAT on tunnel. It's a miracle any of this functions.

Herman: It's a testament to how robust the internet's core protocols are. TCP was designed in the seventies and it handles this nonsense gracefully. But there are edge cases. Some hotel networks use captive portals — the "enter your room number and last name" page. Your travel router has to handle that. GL.iNet routers have a captive portal detection feature that pops up a browser window for you to authenticate, and then the router shares that authenticated session with all your devices. It usually works. Usually.

Corn: Usually. The most dangerous word in travel networking.

Herman: The other hardware consideration is power. The GL-E5800 and E750 are battery-powered — they're designed to be portable. But if you're bonding multiple connections and running a VPN tunnel, the CPU is working harder and the battery drains faster. You'll want to keep it plugged in if you're doing serious bonding. The E5800 has a seven thousand milliamp-hour battery, which is decent, but in my testing with Speedify running, you're looking at maybe four or five hours of actual use.

Corn: That's enough for a train ride. Not enough for a workday.

Herman: Right. So you pack a USB-C power bank. Which is fine — you're already carrying a router, cables, probably a second phone for tethering. The bonded travel rig is not a minimalist setup. It's a bag of gear.

Corn: And that's the thing Daniel's really asking, I think. Not just "what hardware" but "what does this lifestyle actually look like." You land in a new city. You check into your hotel. What's the ritual?

Herman: The ritual is: you unpack the router, plug it in, connect it to the hotel Wi-Fi through the admin panel. If there's an Ethernet port, you plug that in too. You make sure the eSIM profile is active and has data. You SSH into the router, start the Speedify client, verify that all three WAN connections are showing as active. Then you connect your laptop and phone to the router's Wi-Fi network. Total setup time: maybe ten minutes if everything goes smoothly. Twenty if the captive portal is being difficult.

Corn: And if you've done the self-hosted VPS route, you're also checking that the tunnel to your server is up.

Herman: Yes. And if it's not, you're troubleshooting from a hotel room with bad internet. That's the real argument for Speedify's cloud servers. When things break, you're not the one who has to fix them.

Corn: Let's talk about the eSIM side of this more concretely. You mentioned Airalo and Ubigi. Are there any quirks with using those on a router versus a phone?

Herman: The main quirk is that some eSIM providers don't officially support routers. Their terms of service might say "for use in phones only." In practice, the router identifies itself as a cellular device and it works — I've never heard of anyone being blocked. But it's worth knowing that you're in a grey area. The other thing is that router eSIM profiles are typically data-only. You're not getting a phone number. That's fine for bonding, but it means you can't receive SMS for two-factor authentication. You'd need a separate solution for that.

Corn: And the cost side? If you're bonding cellular with Wi-Fi, you're burning through cellular data faster than a normal traveller.

Herman: Yes, because the bonding is sending packets down all available links. If you're not careful, you can burn through a five-gigabyte eSIM plan in a day. Speedify has a setting to control how aggressively it uses each link — you can set the cellular link to "secondary" or "backup" mode, where it only kicks in when the primary link is struggling. That helps with data usage. But if you want true bonding with full bandwidth aggregation, you're going to use data on all links simultaneously.

Corn: So the traveller who wants robust bonding is also the traveller who buys the largest data plans and doesn't think about it.

Herman: Or they're expensing it. This is a business-travel setup, realistically. The cost of the hardware, the monthly Speedify subscription, the eSIM data plans — you're looking at maybe a hundred dollars a month all-in if you're using it heavily. That's hard to justify for a vacation. For someone who needs to be on video calls and can't afford to drop, it's cheap insurance.

Corn: Alright, let's pull this together. The hardware is a GL-E5800 or E750, around two to three hundred dollars. The bonding software is Speedify at fifty a month, or OpenMPTCProuter on a four-euro VPS if you're willing to do the work. The eSIM comes from Airalo or similar, and you're managing it through the router's web interface. The whole thing fits in a small bag, takes ten minutes to set up, and gives you a connection that survives individual link failures gracefully.

Herman: That's the state of the art in 2026. It's not seamless, but it's robust. And the gap in the market — the preconfigured bonding VPS you can just rent — is still open. If someone wanted to build a business, that's the play. Sell a managed bonding endpoint for ten or fifteen dollars a month, with a simple client config that works on GL.iNet routers. You'd have maybe a few thousand customers, but they'd be loyal.

Corn: The "bonding as a service" startup pitch. I'd invest.

Herman: You'd be the only investor. But seriously, the technology is all there. The pieces exist. It's just that nobody has put them together into a product you can buy with a credit card and configure in five minutes. That's the difference between a hobbyist project and a consumer product.

Corn: That's where we are with travel bonding in 2026. It's a hobbyist project that works really well, but you have to be the kind of person who enjoys the tinkering. If you just want internet that works, you pay for Speedify and move on with your life.

Herman: Which, to be fair, is what most people should do. The self-hosted path is for the curious and the cost-sensitive. Daniel, I suspect, is both.

Corn: He did bond DSL with cellular at two in the morning to keep Zoom calls alive, back before fiber reached his building. So yes, he's exactly the target audience for the self-hosted path.

Herman: The thing I keep coming back to is how much of this complexity is temporary. eSIM support in routers will become standard — it's already in the E-series, and I'd expect the next generation of GL.iNet's entire lineup to include it. The bonding software will get easier to install. Someone will eventually offer that turnkey bonding VPS. In three years, this whole setup might be a hundred-dollar box and a fifteen-dollar monthly subscription, and it just works.

Corn: Then we'll find something else to obsessively optimise.

Herman: Of course we will. That's the whole point.

Hilbert: Nineteen ninety-nine. I was on a cruise ship in the Caribbean, bonding four satellite links with a Perl script I wrote in two days because the IT director wanted to watch a football match.

Corn: Wait.

Hilbert: The ship had four separate satellite uplinks — each one was sixty-four kilobits per second. Individually, they were useless for video. But if you split the packets across all four and reassembled them on a server in Miami, you got about two hundred fifty kilobits. Barely enough for a grainy stream, but the captain didn't care about resolution. He cared about the score.

Herman: A custom Perl script doing per-packet bonding in 1999. That's basically what Speedify does, but twenty-five years earlier and held together with string.

Hilbert: It worked about sixty percent of the time. The other forty percent, we blamed on solar flares. The real problem was that the satellite links had different latencies — one was geostationary, one was on a different satellite, the other two were... I never actually found out what they were connected to. The Perl script had a buffer for reassembly, and if a packet arrived too late, it got dropped. The video would glitch, the captain would radio down, and I'd tell him it was sunspots.

Corn: And he believed you.

Hilbert: He had no choice. I was the only person on the ship who understood the setup. That's the secret of IT on cruise ships — if you're the only one who knows how it works, you can blame anything on the ionosphere.

Herman: The thing that strikes me about that story is the latency mismatch problem. That's still the hard part of bonding today. If one link has twenty milliseconds of latency and another has two hundred, the bonding algorithm has to buffer the fast link to keep the packets in order. Too much buffer and you add delay. Too little and you drop packets. Speedify's whole secret sauce is their dynamic buffer management.

Hilbert: We didn't have dynamic anything. We had a hard-coded buffer of five hundred milliseconds. If a packet was later than that, it was gone. The captain learned to live with the occasional glitch. He also learned that if he called down to complain, I'd start explaining how the buffer worked, and he'd suddenly remember he had somewhere else to be.

Corn: The universal IT defence mechanism. Explain the technical details until the complainer gives up.

Hilbert: It's never failed me. Anyway, the point is — you're right that Speedify is the practical answer. It's what we wished we had. But I miss the Perl script. It had character. It had comments in it that said things like "I don't know why this works, don't touch it." You don't get that with a polished commercial product.

Herman: There's something to that. The self-hosted OpenMPTCProuter path has a bit of that spirit. It's not polished, but you understand what it's doing because you had to configure it yourself. You're not just paying someone else to solve the problem.

Hilbert: Though I wouldn't go back. I still have the old Cisco 3800s in my garage — rescued them from decommissioning when the cruise line upgraded. They've got the Perl script on them. I fire them up sometimes just to see if they still work. They do. The fan noise is unbearable.

Corn: Of course you kept them.

Hilbert: They're in a box. Next to the satellite phone I used to call the Miami server when the script crashed. That phone cost four dollars a minute. The football match cost the cruise line about six hundred dollars in satellite time. Worth every penny, according to the captain.

Herman: The economics of bonding have certainly improved. Four euros a month for a Hetzner VPS versus six hundred dollars for a single football match.

Hilbert: The funny thing is, the fundamental problem hasn't changed. You've got multiple connections, you want them to act like one. The hardware is smaller and the software is better, but you're still fighting physics. Latency, packet loss, buffer management. The same three problems I was fighting in 1999. The Perl script is gone, but the physics are eternal.

Corn: That's almost comforting. The tech changes, the constraints don't.

Hilbert: The other thing that hasn't changed: it's always about video. Nobody bonds connections to check email. They bond connections because someone, somewhere, wants to watch something in real time. The captain and his football match. The business traveller and their Zoom call. Same impulse, different decade.

Herman: That's a useful insight. When you're designing a bonding setup, optimise for video. Low latency, consistent jitter, enough bandwidth for a clear stream. If it works for video, it works for everything else.

Corn: If it doesn't work for video, you blame solar flares.

Hilbert: That's the other thing that never changes.

Corn: Where does this leave us? The hardware exists — GL.iNet's E-series with eSIM, around two to three hundred dollars. The software exists — Speedify for the easy path, OpenMPTCProuter for the DIY path. The VPS path is cheap and doable if you're willing to learn. And somewhere out there, a business opportunity is sitting unclaimed: the turnkey bonding endpoint you can rent with a credit card.

Herman: That's the open question. Will someone build it? The pieces are all there. GL.iNet has the router hardware. Speedify has the bonding protocol. The cloud providers have the infrastructure. Someone just needs to package it. My guess is we'll see it within a year or two. The demand is small but real, and the margins would be healthy.

Corn: Until then, the self-hosted path is the answer for anyone who wants control and lower cost. It's not turnkey, but it's not rocket science either. If you can follow a tutorial and you're not afraid of a terminal, you can build it.

Herman: If you want the full build guide — the step-by-step, which VPS provider, which image, how to configure the firewall rules — let us know. That's a whole episode on its own, and we'd love to do it.

Corn: This has been My Weird Prompts. Thanks to our producer, Hilbert Flumingtop, for the war stories and the Cisco routers in his garage.

Herman: If you enjoyed this, leave us a review wherever you listen. You can also email the show at show at my weird prompts dot com — we read every one, and yes, we do take episode requests.

Corn: We'll be back soon. Until then, may your packets arrive in order.