I've recently been tasked with setting up remote connectivity to mobile vans and trailers. Starlink looked like the easy part of this project. Drop a dish on a mobile, get internet, build a tunnel back to the data center, done. That is what the architecture diagram promised. The diagram was lying, or at least leaving out the part where every layer of the stack had its own caveats.

This is the story of how a "just route everything over the tunnel" requirement turned into a small pile of workarounds on the Cisco side, and why we eventually walked away from the platform entirely.

Getting started

Starlink hands the trailer router a public IP and pushes a default route via DHCP using bypass mode so the unit can reach the internet on its own. That part is fine. On top of that, we add a static route pointing at the data center's public IP, which is what actually stands up the IPsec tunnel. So far, two routes, two jobs. Nothing unusual.

Problem one: the next hop that wouldn't sit still

The first hiccup is that you cannot point a static route at an interface as the next hop on this platform and expect it to forward correctly out the WAN side. You need an IP. Except Starlink's gateway IP is not guaranteed to stay the same, so hardcoding it is asking for a future outage.

The workaround here is reasonable as workarounds go: append dhcp to the static route so it tracks whatever gateway DHCP currently hands out, instead of relying on the DHCP-installed default route itself. It works. It is also workaround number one.

Problem two: two default routes walk into a router

We wanted all traffic, not just the tunnel-bound stuff, riding over the IPsec tunnel. The obvious move is a static default route pointing at the tunnel interface. The router disagreed. It already had a default route from the DHCP interface, and the two routes did not coexist peacefully, even after we stopped actually using the DHCP-sourced default.

The fix that actually worked was assigning IP addresses to both ends of the tunnel interface and using those as the next hop instead of pointing the default route at the interface itself. Functional, yes. Also more moving parts than the original ask called for, and a design choice that ran straight into a separate constraint. We didn't want IPs on the tunnels at all. Without them, this approach falls apart.

Workaround number two, and it's already in tension with workaround number one's spirit of "keep this simple."

Problem three: the data center had its own ideas

Then the data center joined in. Because the IPsec connection there is dial-in, it automatically installs a route based on the phase 2 selectors (which can easily ruin your entire day), local and remote addresses baked right into the tunnel negotiation. That route can be disabled, but it is yet another behavior you have to know about, account for, and document so the next person does not get surprised by it six months from now.

Three problems in, and each fix was solving a real issue. None of them were wrong, exactly. But stack them together and you get a configuration that only a small number of people fully understand, which is its own kind of risk with a large organization.

The VRF idea, and where we drew the line

At this point the conversation turned to using multiple VRFs to cleanly separate the tunnel routing from the rest of the table. It would probably have worked. It also would have been workaround number four, layered on top of three other workarounds, all in service of a requirement that started out sounding simple: send traffic over a tunnel.

That is the point where I stopped and asked what we were actually optimizing for. Not "can we make this work," because we clearly could, eventually, with enough duct tape. The real question was whether this was the right amount of complexity for what the trailers needed. It wasn't. We were engineering around the platform instead of choosing the platform that fit the job, and every additional workaround made the eventual handoff and troubleshooting story worse, not better.

Choosing the simpler hill

Swapping the tunnel endpoint to an actual firewall changes the math entirely. The tunnel configuration is straightforward. Routing all traffic over the tunnel does not require tunnel IPs, conditional defaults, or any of the next-hop gymnastics we'd been doing. East-west segmentation between trailer and data center traffic becomes a firewall policy decision instead of a routing table puzzle. The dial-in route quirk goes away because the architecture around it is different.

There's also a longer-term upside sitting right there: the firewalls could build tunnels directly to our SSE solution, which would stop the mobile's internet-bound traffic from having to hairpin through the data center just to get scanned and sent back out. Not a priority for this phase, but it's the kind of option that falls out naturally once you're not fighting the platform anymore. You can focus on growth and optimization.

The actual lesson

None of the Cisco-side workarounds were mistakes. Each one was a correct, narrow answer to a real constraint, and if the requirement had been to make it work on that specific router no matter what, we would have gotten there. But "can we make it work" and "should we" are different questions, and somewhere around the third workaround is usually where it's worth asking the second one.

Simplicity isn't the absence of hard problems. It's choosing not to solve the same hard problem four different times on four different layers when one architectural decision makes three of those problems disappear.