WireGuard Hub VPS for IoT

The problem this solves

A fleet of cellular routers spread across multiple sites, common in retail, industrial and remote monitoring deployments, traditionally faced a frustrating choice: expensive site-to-site VPN appliances, a tangle of manually configured peer-to-peer tunnels that don’t scale past a handful of sites, or no secure remote access at all beyond whatever the router manufacturer’s own (often paid, often vendor-locked) cloud platform offers. A single WireGuard hub VPS sidesteps all of this: every router, regardless of brand, connects outbound to the same central point, which is both cheap to run and works identically across a genuinely mixed-vendor fleet.

Why WireGuard support across major router brands matters here

This pattern’s real strength is that it isn’t tied to one manufacturer’s ecosystem. Teltonika routers (RUT and TRB series) support WireGuard natively through their web UI and via RMS for remote configuration. Milesight routers offer WireGuard through their Development Platform. Robustel and InHand routers likewise support it as a standard, built-in VPN option, not a third-party add-on. For an integrator or business running a mixed fleet, swapped between brands over time or by site, this means the central hub side of the architecture never has to change, only the per-router configuration step, which follows the same WireGuard fundamentals regardless of which manufacturer’s interface you’re clicking through.

Architecture

This extends the same hub-and-spoke pattern covered in VPS as a SCADA VPN Concentrator, generalised here specifically around routers as the connecting devices rather than individual sensors or PLCs:

[Interface]
PrivateKey = <vps-private-key>
Address = 10.50.0.1/24
ListenPort = 51820

[Peer]
# Site 1 - Teltonika RUTX12
PublicKey = <site1-public-key>
AllowedIPs = 10.50.0.2/32, 192.168.10.0/24

[Peer]
# Site 2 - Milesight UR75
PublicKey = <site2-public-key>
AllowedIPs = 10.50.0.3/32, 192.168.11.0/24

Each router’s own local network appears as the second range in its AllowedIPs line, exactly as in the multi-site industrial pattern, which is what lets the hub, and any other connected router, reach devices behind each site’s router, not just the router itself.

Configuring the router side, regardless of brand

Whichever manufacturer’s web interface you’re working in, the same fields need filling in consistently: the router’s own generated key pair, the VPS’s public key and address as the peer to connect to, and the router’s assigned tunnel IP address matching what’s configured on the hub. Teltonika’s RUT-series interface presents this under its dedicated WireGuard services page; Milesight’s Development Platform offers the same configuration through its VPN section; Robustel and InHand follow broadly equivalent patterns in their own interfaces. The underlying WireGuard configuration is identical regardless of brand, only the click-path to get there differs.

Why this beats a single-vendor cloud platform for many fleets

Most router manufacturers offer their own cloud management platform (RMS for Teltonika, for example), genuinely excellent for device management, firmware updates and monitoring, but these platforms are built around that manufacturer’s own hardware specifically. A self-hosted WireGuard hub doesn’t care which brand a given site’s router is, making it the natural fit for any fleet that’s grown across multiple manufacturers over time, through acquisitions, supplier changes, or simply different sites being provisioned at different points with whatever made sense then.

Combining this with manufacturer platforms, not replacing them

Worth being clear: this guide’s hub pattern and a manufacturer’s own management platform aren’t mutually exclusive. Many deployments run both, RMS or an equivalent platform for device-level management and firmware, the WireGuard hub specifically for secure data and remote-access connectivity between sites and central infrastructure, each doing the job it’s actually best at rather than forcing one platform to do everything.

Scaling to a genuinely large fleet

The sizing and monitoring considerations covered in Zero-Touch IoT Fleet Provisioning apply directly here for larger deployments, automating the peer-registration process rather than manually configuring each new router as it’s added, worth adopting once a fleet grows past the point where manual configuration per site is still comfortable.

Where iotvpn.co.uk fits

For businesses wanting this exact pattern without standing up and maintaining the hub VPS themselves, iotvpn.co.uk covers managed WireGuard hub hosting specifically for multi-router fleets, worth a look if the self-hosted route here is more ongoing infrastructure than your team wants to own directly.

Frequently asked questions

Can routers from different manufacturers really connect to the exact same hub without any compatibility issues?

Yes, since WireGuard is a standard protocol implemented consistently across every major router brand’s firmware, the hub VPS doesn’t distinguish between peers by manufacturer, only by their key and configured address, exactly as designed.

Does this require a specific firmware version on the routers?

Recent firmware on any of the brands mentioned here includes WireGuard support, though it’s worth checking your specific model and firmware version’s release notes if you’re on genuinely old firmware, since WireGuard support was added to most manufacturers’ lineups progressively over recent years rather than being present from day one on every model.

How many routers can one VPS hub realistically support?

Comfortably into the hundreds on a modestly specified VPS, the same scaling characteristics covered in the SCADA VPN concentrator guide; the limiting factor in practice is usually the registration and monitoring discipline around the fleet, not WireGuard’s own per-peer overhead.

What happens if a router’s local IP range overlaps with another site’s?

This needs resolving before connecting both to the same hub, either by re-addressing one site’s local network or using WireGuard’s NAT capabilities to remap overlapping ranges, worth planning for explicitly if router default configurations (many ship with the same default subnet) haven’t been customised per site already.

Is this pattern suitable for routers connecting over a cellular data SIM rather than fixed broadband?

Yes, and it’s arguably the strongest use case, since the router-initiates-outbound pattern works cleanly behind carrier-grade NAT on a standard data SIM, the same advantage covered in Fixed vs Dynamic IP SIM for Home/Office IoT and its business-focused counterpart.

A realistic deployment scenario: an integrator managing client sites

This pattern is particularly well suited to an integrator or managed service provider responsible for routers across multiple client sites, often a genuinely mixed fleet accumulated over years of different projects and client preferences. One hub VPS, with each client site’s router connecting in as its own peer, gives the integrator a single, consistent point of remote access and troubleshooting regardless of which specific router model or brand sits at any given site, replacing what would otherwise be a patchwork of different remote-access methods per manufacturer.

Keeping client or site data properly separated on a shared hub

Worth addressing directly for anyone managing multiple separate clients or sites through one hub: WireGuard’s AllowedIPs configuration, the same mechanism used to define each peer’s reachable network range, doubles as the access-control boundary. A peer’s AllowedIPs only grants the hub permission to route traffic to that peer’s specific declared range, it doesn’t automatically grant other peers access to each other’s networks unless explicitly configured to. For multi-client deployments, leaving inter-site routing disabled by default, only enabling it deliberately where genuinely needed, keeps each client’s network properly isolated from every other client connected to the same hub.

Firmware update considerations across a mixed fleet

One practical wrinkle worth planning for: WireGuard support and its specific configuration options have matured at different rates across manufacturers’ firmware releases. Keeping a simple record of which firmware version each site is running, and confirming WireGuard support specifically before assuming it’s available, avoids the frustrating discovery that an older router at one site needs a firmware update before it can join the hub at all.

Comparing this against manufacturer-specific VPN concentrator hardware

Some router manufacturers also sell dedicated VPN concentrator appliances, physical hardware designed specifically to terminate many tunnels from their own routers. These work well within a single-vendor fleet but, by design, don’t extend to other manufacturers’ hardware. A VPS-based hub trades the polish and official support of a dedicated appliance for genuine cross-vendor flexibility and considerably lower cost, the right trade for any fleet that isn’t, and doesn’t plan to stay, single-vendor.

Can this hub also serve non-router devices, like the smart home or industrial sensor setups covered elsewhere on this site?

Yes, a WireGuard hub doesn’t distinguish between peer types, a router, a single sensor, or a laptop all connect the same way, so the same VPS can serve a mixed set of routers and individual devices without needing separate infrastructure for each category.

Is there a meaningful performance difference between WireGuard implementations across router brands?

Generally minimal for typical IoT and remote-access traffic levels, since WireGuard’s core protocol is standardised; differences show up more in each manufacturer’s web interface and configuration experience than in the underlying tunnel performance itself.

How do I handle a site with a router that genuinely doesn’t support WireGuard at all?

Older or more basic hardware without WireGuard support typically still supports OpenVPN, a mature, well-supported alternative; the same hub VPS can run both WireGuard and OpenVPN simultaneously for a genuinely mixed-capability fleet during a transition period.

What’s a sensible way to document a growing multi-router hub setup?

A simple spreadsheet or shared document recording each site’s router model, firmware version, assigned tunnel IP and local subnet, kept current as sites are added, saves considerable time during troubleshooting and is worth establishing from the very first few sites rather than retrofitting once the fleet has grown unwieldy.

A realistic first deployment to build confidence

Before rolling this out across an entire fleet, build it first against two routers, ideally from two different manufacturers if your fleet is genuinely mixed-vendor, specifically to confirm the cross-vendor claim at the heart of this guide holds true in your own environment rather than taking it on faith. Connect both to the same hub, confirm each can reach its own local network through the tunnel, and confirm the hub correctly keeps each site’s traffic properly separated using the AllowedIPs isolation discussed earlier. Once this two-router proof of concept is solid, scaling to the rest of a fleet is genuinely just repetition of an already-proven pattern, not a leap into unknown territory.

This staged approach, small proof of concept before full rollout, is worth treating as standard practice for this kind of infrastructure change generally, not just specific to this guide, since the cost of discovering a fundamental configuration mistake against two routers is trivial compared to discovering the same mistake after it’s already been replicated across fifty sites.

A note for integrators evaluating this against their existing service offering

For an integrator already selling router installation and support as part of a service package, this pattern is worth framing to clients as a genuine feature, centralised, secure remote support across their entire fleet, rather than purely as an internal cost-saving measure. A client whose site can be remotely diagnosed and reconfigured without an engineer visit, made possible by exactly this kind of hub, is a tangible service-level improvement worth highlighting in client conversations, not just background infrastructure invisible to the end customer.

For a reader who has just finished setting up their own home remote access through this guide, the leap to managing this for multiple client sites is smaller than it might first appear.

A note on keeping the hub itself secure

The WireGuard hub VPS is a particularly high-value target: it’s the central point through which every connected site’s traffic passes. Following the hardening checklist covered in VPS Security Hardening for IoT matters more here than for a single-site deployment. Specifically: automatic unattended security updates enabled, fail2ban protecting SSH, and the WireGuard port the only firewall opening beyond SSH. The rest of the VPS attack surface being minimised is the right posture for infrastructure this many sites depend on. This discipline takes less than thirty minutes to implement and matters considerably more here than for any single-site deployment covered elsewhere on this site.