Bypassing CGNAT: WireGuard VPN Built for Ham Radio Access

When the customer's home switched from Frontier DSL to Starlink, the internet got a lot faster. But something important got lost in the upgrade: a real, public IP address. Frontier had provided one without any complications. Starlink, like most modern ISPs, uses carrier-grade NAT (CGNAT), which means the customer's network no longer had a public-facing IP of its own.

That's a bigger deal than it sounds like for anyone running services that need to be reachable from the outside world. In this case, the customer needed it for Echolink, an application used in amateur radio to connect radio systems over the internet. Without a public IP, Echolink and similar services simply can't work the way they're supposed to.

The Problem

The customer had already done a lot of the legwork. They'd spun up a VPS running Ubuntu 24.04 on Vultr, installed a WireGuard server following a YouTube tutorial, and set up a WireGuard client on a Windows 11 laptop. The tunnel would activate, but there was a catch: once it was up, the laptop lost internet access entirely.

The end goal wasn't just to get one laptop online through the tunnel. The customer wanted a way to route traffic from their home network, which runs on a UniFi UCG-Ultra with a 192.168.253.0/24 subnet, through the VPS so devices could effectively "borrow" its public IP. They'd also set up the WireGuard addressing scheme themselves (server at 10.0.0.1, client at 10.0.0.2) and had noticed that their UniFi gateway had its own built-in WireGuard client option, which raised the question of whether that might be a cleaner solution than running WireGuard on an individual PC. On top of all that, there was a FreePBX server in the customer's past setup that they hoped to bring back into the picture eventually.

This is a networking and VPN ticket at its core, but it touches on routing, NAT, and gateway configuration too, all things that can get tangled quickly when you're troubleshooting solo from tutorials and forum posts.

The Approach

Roland, the technician who picked up the ticket, spent the session working through the WireGuard configuration with the customer, explaining the settings that were causing the internet drop during an active tunnel. That kind of issue usually comes down to how traffic is being routed once the tunnel comes up, specifically what's allowed to pass through versus what's being sent to the VPS by default.

Rather than just patching the immediate problem, Roland walked through the reasoning behind the settings so the customer could understand what was happening and why, not just what to click. The review specifically called this out, noting that Roland "explained some Wireguard settings that helped me better understand the few areas I was not quite clear on."

The conversation also touched on the UniFi UCG-Ultra's built-in WireGuard client option, since that could end up being a more robust way to route traffic at the network level instead of relying on a single laptop running its own client. For a setup that might eventually need to support multiple devices, including a possible future FreePBX server, that's a meaningful architectural decision.

One detail that turned out to be a nice bonus: Roland is a licensed amateur radio operator himself. Since the customer's long-term goal involves hosting an Allstar node, an application used by ham radio operators for linking radio repeaters over the internet, having a technician who already understood the terminology and use case made the conversation move a lot faster. Instead of spending time explaining what Echolink or Allstar even are, they could jump straight into the actual networking questions.

The Solution

By the end of the session, the customer had a clearer picture of how their WireGuard tunnel was configured and why it had been knocking out internet access when active. They also came away with a better understanding of their options going forward, including whether to keep running WireGuard on the Windows laptop or shift to the UCG-Ultra's native client for a more network-wide solution.

The session was quick. Just 0.7 hours. But it was focused entirely on solving the specific issue at hand and setting the customer up to make informed decisions about the next steps in their VPN setup.

The Outcome

The customer walked away with a much better grasp of the WireGuard configuration that's going to be central to their networking plans going forward and gave Roland a 5-star review. Whether that means routing a single laptop through the VPS to run Echolink, or eventually setting up the UniFi gateway to handle the tunnel for the whole network including a future FreePBX server, they now understand the mechanics well enough to move forward with confidence.

It's a good example of what these tickets often look like in practice. Not a total network overhaul, but a focused, expert-guided session that clears up confusion and gets someone unstuck. Sometimes that's exactly what's needed, especially when the underlying goal, like getting a ham radio application working around a CGNAT limitation, is a little outside the norm.

Rogue Support exists for exactly this kind of situation. Customers submit a ticket describing what they're working on, vetted technicians bid on the job, and the customer picks who they want to work with. In this case, that meant getting matched with someone like Roland, who brought both networking expertise and a personal familiarity with amateur radio to the table. No wasted time, no generic script, just a technician who understood the problem from more than one angle.