Published 13 May 2026
We have deployed SD-WAN across retail chains, broadcast facilities, maritime vessels, construction compounds, and enterprise office networks ranging from five sites to well over two hundred. We have worked with most of the major SD-WAN platforms in that time. And we keep coming back to Peplink.
This is not a vendor brochure. This is a technical explanation, written from the perspective of the engineers who have to make these networks actually work, of why Peplink consistently wins the evaluation when the requirements are real and the budgets are finite.
The problem with traditional SD-WAN vendors
The SD-WAN market is dominated by a handful of names: Cisco Meraki, Cisco Viptela, Fortinet, VMware VeloCloud, Palo Alto Prisma, and Versa Networks. Each of them produces capable hardware. Each of them has a well-funded marketing department. And each of them has a licensing model that makes multi-site deployment significantly more expensive than the hardware cost alone suggests.
Take Cisco Meraki. The hardware itself is competitively priced. But every Meraki device requires an active cloud licence to function at all. If the licence expires, the device stops forwarding traffic. For a 50-site deployment using MX67 appliances, the annual licence cost alone runs into tens of thousands of pounds. Over a five-year period, you will spend more on licensing than you spent on hardware. And if you want advanced security features, the licence tier goes up again.
Fortinet takes a different approach. The FortiGate hardware is owned outright, but the SD-WAN orchestration layer (FortiManager plus FortiAnalyzer) requires its own licensing. The security features that make FortiGate attractive, such as IPS, web filtering, and sandboxing, all require FortiGuard subscription bundles. A 50-site FortiGate deployment with full security and centralised management is not cheap to run year on year.
VMware VeloCloud (now Broadcom, which tells you something about where the product is heading) charges per-edge licensing that scales with bandwidth tier. A small branch at 200 Mbps pays less than a hub at 1 Gbps, which sounds fair until you realise that the per-edge cost at the higher tiers becomes a serious line item. The Broadcom acquisition has introduced further uncertainty about long-term pricing and product direction.
The common thread across all of these platforms is that the vendor retains ongoing control of your network through licensing. If you stop paying, you lose functionality. In some cases, you lose the network entirely.
How Peplink licensing actually works
Peplink's model is fundamentally different. You buy the hardware. It works. The device routes traffic, builds VPN tunnels, bonds WAN connections, and applies traffic policies without any recurring licence. The Balance router you deploy at a branch site will continue to function for as long as the hardware lasts, whether or not you pay Peplink another penny.
There are optional subscriptions. InControl2, the cloud management platform, requires a subscription for advanced features like centralised configuration push and reporting. SpeedFusion licences on certain models unlock additional VPN peers or higher bonding throughput. But these are additive. The core routing and SD-WAN functionality works out of the box.
Compare that with Meraki, where the device is a brick without a licence. Peplink devices continue to work locally even if your InControl2 subscription lapses. You lose centralised visibility, not the network itself. That distinction matters enormously when you are presenting a five-year TCO to a finance director.
InControl2: centralised management done properly
Centralised management is the entire point of SD-WAN. If you are managing 50 or 200 sites, you need a single pane of glass that shows you the health of every WAN link, the status of every tunnel, and the ability to push configuration changes to groups of devices simultaneously.
InControl2 is Peplink's cloud-based management platform, and it handles this well. Every Peplink device phones home to InControl2 on first boot. From the dashboard, you can see real-time WAN status, bandwidth usage, client counts, and tunnel health across your entire estate. Configuration templates let you define a standard branch config once and apply it to dozens of sites. When you need to make a change (a new firewall rule, a QoS policy update, a DNS change), you make it once in the template and push it out.
The platform also supports role-based access control, so you can give your NOC team read-only visibility while restricting configuration changes to senior engineers. Audit logging tracks every change. API access allows integration with external monitoring platforms.
Where InControl2 particularly shines is in WAN health monitoring. For every WAN interface on every device, you get latency, jitter, packet loss, and throughput graphs over time. When a branch site reports poor performance, you can pull up the WAN history and see exactly which circuit degraded and when. That kind of visibility across 200 sites, without having to SSH into each device individually, is what makes centralised management worthwhile.
Zero-touch provisioning at scale
Deploying SD-WAN across 50 sites is a logistics exercise as much as a network engineering exercise. If each device needs an engineer on site to configure it, you are looking at weeks of site visits, travel costs, and scheduling headaches. Zero-touch provisioning eliminates most of that.
With Peplink, the process works like this. You pre-configure the device in InControl2 with its WAN settings, VLAN configuration, firewall rules, and SpeedFusion tunnel definitions. You assign it to a group and a site. You ship the hardware directly to the branch location. Someone on site (it does not need to be a network engineer) plugs in the power cable and the WAN cables. The device boots, contacts InControl2 over any available internet connection, downloads its configuration, and builds its tunnels. The site is live.
We have used this model to deploy 30 sites in a single week for a retail customer. The devices were pre-staged in our workshop, tested with their intended configurations, boxed up, and shipped to each store. Store managers plugged them in. Every device came online within minutes. The only site visits we made were to the three locations where the existing ISP handoff was not where the store manager expected it to be.
Compare that with a Cisco Viptela deployment, where the ZTP process requires the device to reach the vBond orchestrator, authenticate against vManage, and then pull its template. It works, but the infrastructure behind it (vBond, vManage, vSmart controllers) is considerably more complex to set up and maintain. For a 200-site enterprise, that orchestration infrastructure is a project in itself.
SpeedFusion: bonding that actually bonds
This is where Peplink genuinely differs from every other SD-WAN vendor on the market. SpeedFusion is not just a failover mechanism. It is packet-level WAN bonding that aggregates multiple connections into a single logical tunnel with combined throughput.
Most SD-WAN platforms offer "WAN load balancing," which means they distribute sessions or flows across multiple links. If one link fails, active sessions on that link drop and re-establish on the surviving link. It works, but it is not invisible to the user, and it does not combine bandwidth.
SpeedFusion bonds at the packet level. A single TCP session, a single video stream, a single file transfer can use the combined bandwidth of all available WAN links simultaneously. If you have a 50 Mbps leased line and a 30 Mbps broadband connection, SpeedFusion gives you a single tunnel with approximately 80 Mbps of usable throughput. If the broadband drops, the tunnel continues on the leased line with no session interruption. There is no re-establishment, no dropped packets, no user-visible outage.
For organisations in broadcast, live events, and maritime, this is not a nice-to-have. It is the reason the network works at all. A broadcast truck sending live video from a rural location does not have the luxury of waiting for a VPN to re-establish. SpeedFusion Hot Failover keeps the stream running while individual WAN paths come and go. We have deployed this in scenarios where the only available connectivity is three or four cellular connections on different networks, each delivering between 10 and 40 Mbps depending on load and signal conditions. SpeedFusion bonds them into a single stable tunnel that carries production-quality video back to the studio.
The other SD-WAN vendors simply do not offer this. Meraki's SD-WAN uses per-flow load balancing. Fortinet's SD-WAN steers traffic based on SLA metrics but does not bond at the packet level. VeloCloud does dynamic path selection but, again, does not aggregate bandwidth within a single flow. Peplink's SpeedFusion is unique in the market for genuine packet-level bonding, and it has been doing it for over a decade.
Replacing MPLS: the pattern that works
MPLS circuits are expensive, slow to provision, and increasingly difficult to justify when broadband and cellular connectivity can deliver equivalent or better bandwidth at a fraction of the cost. The challenge is that MPLS provides guaranteed bandwidth and low latency between sites, and replacing it with internet-based connectivity introduces variability.
The MPLS replacement pattern we deploy with Peplink follows a consistent model. At each branch site, we install a Peplink Balance router (the specific model depends on throughput requirements and the number of WAN connections). Each branch gets at least two WAN connections: typically a business broadband circuit and a bonded cellular connection using multi-network SIMs. In locations where leased lines are available at reasonable cost, we add one as a third path.
All branch devices build SpeedFusion tunnels to a hub device. For smaller deployments (under 20 sites), the hub can be a physical Peplink Balance appliance at the head office or data centre. For larger deployments, we use FusionHub, Peplink's virtual appliance, running in AWS, Azure, or a co-located data centre. FusionHub handles the tunnel termination for all branch sites and provides the central routing point for inter-site traffic.
The key insight is that SpeedFusion bonding across two or three internet circuits delivers better real-world performance than a single MPLS circuit at most branch sites. The aggregate bandwidth is higher. The resilience is better (losing one of three WAN paths is less disruptive than losing your only MPLS circuit). And the cost is dramatically lower.
A typical 10 Mbps MPLS tail circuit in the UK costs between £400 and £800 per month depending on location and provider. A business broadband connection delivering 80 Mbps costs £30 to £50 per month. A multi-network cellular connection with 100 GB of pooled data costs roughly the same. For the price of one MPLS circuit, you can deploy two or three diverse WAN paths with ten times the aggregate bandwidth. The economics are not close.
Branch hardware sizing: the Balance range
Peplink's Balance range covers everything from a small retail location to a high-throughput data centre hub. Getting the sizing right matters, because an undersized device creates a bottleneck and an oversized device wastes budget.
For small branches with 10 to 30 users and two WAN connections, the B One 5G or Balance 310X handles the workload comfortably. The B One 5G offers dual Gigabit WAN, Wi-Fi 6, an integrated 5G modem, and 1 Gbps SpeedFusion throughput. The 310X adds a third WAN port for sites that need it. They are compact, fanless, and draw minimal power. For a 50-site retail deployment, this is the branch device.
For medium branches with 30 to 100 users, multiple VLANs, and three or four WAN connections, the Balance 580 or Balance 710 provides higher throughput and more port density. These devices handle 500 Mbps to 1 Gbps of SpeedFusion throughput and support USB WAN for additional cellular modems.
For large branches or regional hubs with 100+ users and multiple high-bandwidth WAN connections, the Balance 2500 or Balance 5000 EC delivers multi-gigabit routing and SpeedFusion performance. The 5000 EC is the current flagship, with 30 Gbps SpeedFusion throughput and support for up to 4,000 VPN peers. These are rack-mounted devices with redundant power supplies and the processing headroom to handle hundreds of concurrent VPN tunnels.
The point is that the hardware range covers the full spectrum without forcing you into an oversized chassis at small sites or an underpowered box at large ones. Each model runs the same firmware, supports the same feature set, and is managed through the same InControl2 interface. A branch B One and a hub Balance 2500 appear identically in the management dashboard.
Hub deployment with FusionHub
FusionHub is Peplink's virtual SD-WAN appliance. It runs as a VM on VMware ESXi, Hyper-V, KVM, or as a cloud instance on AWS and Azure. Its job is to terminate SpeedFusion tunnels from branch devices and route traffic between sites, to the internet, or into your data centre infrastructure.
For a hub-and-spoke topology (which is what most multi-site enterprises need), FusionHub sits in the data centre or cloud and every branch device connects to it. Inter-site traffic flows through the hub. Internet breakout can happen locally at each branch or centrally through the hub, depending on your security and compliance requirements.
We typically deploy FusionHub on a dedicated VM in a co-located data centre with diverse internet connectivity. The VM gets allocated four or eight vCPUs and 4 to 8 GB of RAM depending on the number of tunnels. A FusionHub Solo licence (included with the software) supports up to five SpeedFusion peers. FusionHub Essential supports up to 150 peers, which covers most enterprise deployments. For very large estates, FusionHub licences scale to 1,000+ peers.
The alternative is a physical hub device. For organisations that prefer hardware in their own rack, a Balance 2500 or Balance 5000 EC at the head office handles the hub role. The trade-off is flexibility: FusionHub in the cloud can be replicated across regions for geographic redundancy, while a physical appliance requires a second device at a DR site.
We often deploy both. A primary FusionHub in AWS eu-west-2 (London) and a secondary FusionHub in eu-west-1 (Ireland) gives branch devices two hub targets. If the primary goes down, branches fail over to the secondary automatically. The total cloud cost for running two FusionHub instances is roughly £150 to £250 per month, depending on instance size and data transfer. That buys you geographic redundancy that would cost thousands per month with physical hardware at two co-location facilities.
Traffic policies and QoS
SD-WAN without traffic policy is just a VPN. The value of SD-WAN comes from the ability to steer traffic intelligently based on application, source, destination, and link quality.
Peplink's outbound policy engine supports weighted balance, priority, enforced, and overflow algorithms per traffic rule. You define rules based on source IP/subnet, destination IP/subnet, protocol, port, DSCP marking, or application. Each rule specifies which WAN connections to use and in what order.
A typical branch policy might look like this: voice traffic (SIP and RTP) is prioritised onto the lowest-latency WAN link with spillover to the next-best link. Video conferencing traffic gets weighted across all links via the SpeedFusion tunnel. Bulk data transfers (backups, file sync) are relegated to the broadband connection only, keeping the cellular data budget for interactive traffic. Guest Wi-Fi traffic breaks out locally to the internet and never enters the SpeedFusion tunnel.
QoS within SpeedFusion tunnels supports bandwidth reservation and priority queuing. You can guarantee that voice traffic gets 2 Mbps of the tunnel bandwidth regardless of what else is happening. You can cap guest traffic at 10 Mbps aggregate. You can set burst limits on backup traffic so it uses spare capacity without affecting production applications.
The configuration is done through the web interface or via InControl2 templates. It is not as granular as a dedicated application-aware firewall (Peplink's DPI engine recognises common applications but is not as deep as Palo Alto's App-ID or Fortinet's application control). But for SD-WAN traffic steering, which is what we are doing here, it is more than sufficient. And it works without any additional security subscription.
Comparison with traditional SD-WAN vendors
Here is how the platforms compare on the criteria that matter for a 50-site enterprise deployment:
Licensing model. Peplink: hardware purchase, optional InControl2 subscription. Meraki: mandatory annual licence per device. Fortinet: hardware purchase plus FortiGuard subscriptions plus FortiManager/FortiAnalyzer licensing. VeloCloud: per-edge subscription tiered by bandwidth.
WAN bonding. Peplink: packet-level bonding via SpeedFusion. Meraki: per-flow load balancing only. Fortinet: per-session steering, no packet-level bonding. VeloCloud: dynamic path selection, no packet-level bonding.
Cellular integration. Peplink: built-in dual-cellular on many models, mature multi-network SIM support, extensive antenna options. Meraki: built-in LTE on selected models, limited carrier support. Fortinet: USB dongle support, no built-in cellular on most models. VeloCloud: no built-in cellular.
Zero-touch provisioning. All four platforms support ZTP. Peplink's is the simplest to set up because InControl2 is cloud-native with no on-premise orchestration infrastructure. Viptela/VeloCloud require controller infrastructure. Fortinet requires FortiManager.
Offline operation. Peplink devices continue to function fully if the management platform is unreachable. Meraki devices stop functioning when the licence expires. Fortinet devices continue locally but lose centralised policy. VeloCloud devices continue with cached policy.
Security features. This is the one area where Peplink is not the leader. Fortinet and Palo Alto have deeper security stacks with NGFW, IPS, sandboxing, and threat intelligence feeds. Peplink provides stateful firewall, content filtering, and basic intrusion detection. For organisations that need deep packet inspection and advanced threat prevention at the branch, we pair Peplink SD-WAN with a dedicated security appliance or cloud-based security service. For organisations where the primary requirement is reliable connectivity with sensible firewalling, Peplink's built-in security is adequate.
Deployment pattern: 50-site retail chain
A UK retail customer with 50 stores needed to replace ageing MPLS and provide consistent, resilient connectivity for EPOS, CCTV, stock management, and guest Wi-Fi. The MPLS contract was costing £22,000 per month across all sites.
We deployed a Balance 20X at each store (now superseded by the B One series for new deployments) with two WAN connections: existing FTTC broadband (typically 40 to 80 Mbps down) and a bonded cellular connection using dual-network SIMs providing 20 to 60 Mbps depending on location. Each device built a SpeedFusion tunnel to a pair of FusionHub instances running in AWS.
Traffic policy at each store: EPOS traffic routed through the SpeedFusion tunnel to the head office with priority queuing. CCTV upload shaped to 5 Mbps and sent via SpeedFusion. Stock management and email routed through SpeedFusion with standard priority. Guest Wi-Fi broke out locally to the internet through the broadband connection, bypassing the tunnel entirely.
The total hardware cost was approximately £45,000 (50 Balance 20X units plus antennas, cabling, and two FusionHub licences). The ongoing connectivity cost was roughly £5,500 per month (broadband and cellular across 50 sites, plus AWS hosting for FusionHub). The InControl2 subscription for 50 devices added approximately £2,000 per year.
The monthly saving compared with MPLS was over £16,000. The hardware investment paid for itself in under three months. The aggregate bandwidth at each store increased from 10 Mbps (MPLS) to 60 to 140 Mbps (bonded broadband plus cellular). And every store had WAN resilience that the single MPLS circuit never provided.
Deployment took three weeks. Week one: pre-stage all devices in the workshop, test configurations, and ship to stores. Week two: store managers plug in devices, remote verification via InControl2. Week three: site visits to the handful of locations with cabling issues, plus performance tuning across the estate.
Deployment pattern: 200-site enterprise
A multi-national organisation with 200 sites across the UK, Ireland, and mainland Europe needed a unified SD-WAN to replace a patchwork of MPLS, site-to-site VPN, and standalone broadband connections. Sites ranged from 5-person satellite offices to 500-person regional headquarters.
The architecture used three tiers of hardware. Small offices (under 20 users, 120 sites) got Balance 310X units with broadband plus cellular. Medium offices (20 to 100 users, 65 sites) got Balance 580 units with broadband, cellular, and a leased line where available. Large offices and regional HQs (15 sites) got Balance 2500 units with dual leased lines, broadband, and cellular backup.
The hub layer comprised four FusionHub instances: two in AWS eu-west-2 (London) for UK and Ireland traffic, and two in AWS eu-central-1 (Frankfurt) for mainland European traffic. Branch devices were assigned to their nearest hub pair with automatic failover to the secondary hub in each region.
Traffic policy was more complex than the retail deployment. Voice traffic (Microsoft Teams, SIP) used the SpeedFusion tunnel with dedicated bandwidth reservation. ERP traffic (SAP) was routed through the tunnel with high priority. Internet browsing broke out locally at medium and large sites but was tunnelled to the hub at small sites for centralised web filtering. Inter-site file transfers used the tunnel with best-effort priority.
The deployment was phased over 12 weeks. UK sites went first (weeks 1 through 6), followed by Ireland (weeks 7 and 8), then mainland Europe (weeks 9 through 12). Zero-touch provisioning handled the majority of small office deployments. Medium and large sites received an engineer visit for rack installation, cable routing, and integration with existing LAN infrastructure.
The previous network (MPLS plus ad-hoc VPN) cost approximately £68,000 per month. The Peplink-based SD-WAN cost approximately £19,000 per month in ongoing connectivity and cloud hosting, plus an InControl2 subscription of roughly £8,000 per year. The hardware investment was approximately £280,000 including installation. Annual saving: approximately £580,000. Payback period: under six months.
TCO analysis: five-year view
The numbers above tell a clear story, but it is worth breaking down the total cost of ownership more formally. For a 50-site deployment over five years, here is how Peplink compares with Cisco Meraki:
Peplink (B One, 50 sites): Hardware: £45,000 (one-time). InControl2: £10,000 (5 years). FusionHub hosting: £15,000 (5 years). Connectivity (broadband + cellular): £330,000 (5 years). Total five-year cost: approximately £400,000.
Cisco Meraki (MX67, 50 sites): Hardware: £40,000 (one-time). Licensing (Advanced Security, 5 years): £125,000. Connectivity (broadband only, no native cellular bonding): £180,000 (5 years). Total five-year cost: approximately £345,000. But this comparison is misleading, because the Meraki deployment does not include cellular bonding. It has broadband only, with LTE failover on selected models. To get equivalent resilience, you would need to add standalone cellular routers at each site, increasing the total to approximately £420,000 or more. And the Meraki solution still does not provide packet-level bonding.
Fortinet (FortiGate 60F, 50 sites): Hardware: £50,000 (one-time). FortiGuard subscriptions (5 years): £75,000. FortiManager/FortiAnalyzer licensing: £25,000 (5 years). Connectivity: £180,000 (5 years). Total five-year cost: approximately £330,000. Again, no packet-level bonding. The Fortinet solution has a stronger security stack, but the SD-WAN capability is session-based steering, not true bonding. For organisations that need both deep security and bonded WAN, we deploy Peplink for the SD-WAN layer and a separate security service for threat prevention.
The consistent finding across every deployment we have done is that Peplink's TCO is competitive with or lower than the alternatives, while providing genuinely superior WAN bonding and resilience. The gap widens as the deployment grows, because Peplink's licensing costs scale slowly while subscription-based vendors' costs scale linearly with site count.
Why we chose Peplink after evaluating the alternatives
We did not start as a Peplink partner. We evaluated multiple platforms over several years before committing to Peplink as our primary SD-WAN technology. The decision came down to five factors.
First: SpeedFusion bonding is unique. No other vendor offers true packet-level WAN bonding across heterogeneous connections. For our customers in broadcast, maritime, and live events, this capability is non-negotiable. Once you have deployed a network where four cellular connections bond into a single stable 120 Mbps tunnel carrying live video, it is difficult to go back to per-flow load balancing.
Second: the licensing model is honest. You buy the hardware, it works. You are not held to ransom by annual subscriptions. Your network does not stop functioning because a purchase order was delayed. This matters to our customers, many of whom operate in environments where a connectivity outage has immediate operational and financial consequences.
Third: cellular is a first-class citizen. Peplink's heritage is in cellular routing. Their devices have superior modem integration, antenna design, and carrier compatibility. When we deploy a Balance router with dual embedded cellular modems and external MIMO antennas, we get measurably better cellular performance than plugging a USB dongle into a FortiGate.
Fourth: the platform scales without complexity. A five-site deployment and a 200-site deployment use the same hardware family, the same firmware, the same management platform, and the same configuration approach. There is no "enterprise tier" that requires a completely different architecture. You add devices to InControl2 and build tunnels. That simplicity translates directly into faster deployments and lower support costs.
Fifth: the hardware is built for real-world conditions. Peplink devices are deployed on fishing boats, in broadcast trucks, at temporary event sites, and in remote construction compounds. They handle temperature extremes, vibration, and unreliable power. The industrial design is not an afterthought; it is core to the product. Try deploying a Meraki MX in a maritime engine room and you will understand why this matters.
When Peplink is not the right choice
Honesty matters. Peplink is not the answer to every SD-WAN requirement.
If your primary requirement is next-generation firewall with deep packet inspection, advanced threat prevention, and integrated SIEM, then Fortinet or Palo Alto will serve you better. Peplink's firewall is stateful and functional but it is not an NGFW. We address this by deploying Peplink for SD-WAN connectivity and pairing it with a cloud-based security service or dedicated security appliance where the threat model demands it.
If your organisation is locked into a Cisco ecosystem with existing ISE, DNA Centre, and Catalyst infrastructure, the integration overhead of introducing Peplink may outweigh the cost savings. In those environments, Cisco Viptela or Meraki will integrate more smoothly with your existing management and authentication stack.
If you have a compliance requirement that mandates a specific vendor (some government contracts specify Cisco or Juniper), then the decision is already made for you.
For everyone else, particularly mid-market enterprises, multi-site retailers, organisations with remote or challenging sites, and any business that needs genuine WAN bonding rather than just failover, Peplink is the platform we recommend. It has earned that recommendation through years of deployments, and it continues to earn it every time we compare the alternatives.
Getting started
If you are evaluating SD-WAN for a multi-site deployment, we would encourage you to start with a proper connectivity audit across your sites. Understand what WAN paths are available, what cellular coverage looks like from inside each building, and what your actual traffic patterns are. That audit shapes the hardware sizing, the topology design, and the traffic policy. Without it, you are guessing.
We offer a no-obligation network assessment for organisations considering SD-WAN migration. We will review your current connectivity, map out a Peplink-based architecture, and provide a detailed TCO comparison against your existing setup and any alternatives you are evaluating. Get in touch to arrange a conversation.
You can also browse the Peplink Balance range in our online store, or read more about our SD-WAN deployment services.