Enabling SpeedFusion is one checkbox. Configuring it so a mission-critical session survives real-world link behaviour is engineering, and the gap between the two is where most troubled deployments live. This is the workflow I use to build validated, resilient tunnels, and the decisions that matter at each step.
Prerequisites: where most failures are born
Most SpeedFusion problems are prerequisite problems wearing a configuration costume. Settle these first.
Know what you are licensed for. PepVPN is the base single-link protocol; SpeedFusion adds the multi-link suite: Bandwidth Bonding, Hot Failover, WAN Smoothing. Most MAX and Balance models include it, but some entry-level units need a licence or active PrimeCare to unlock bonding; check Feature Add-ons in the web admin on both peers before you design around a feature one end does not have.
Firmware. Run a recent stable release on both peers; 8.6.0 is now generally available and brings meaningful tunnel improvements, and note that several models (including the BR1 Pro family, Transit, Dome and B One series) must step through 8.5.4 before taking 8.6.0. Whatever you choose, matched and validated beats newest.
Topology. One end of the tunnel needs a static public IP, normally the hub or FusionHub instance, and if that end sits behind a third-party firewall you must forward the tunnel ports (by default TCP 32015 for the handshake and UDP 4500 for data) or the tunnel will never establish. Size a FusionHub for the aggregate throughput of every spoke it terminates, not the average.
Addressing. Overlapping LANs at each end (both sides on 192.168.1.0/24 is the classic) break routing outright. Plan distinct ranges before the first tunnel, not after the third.
Manual configuration via Web Admin
InControl2 is the right tool for fleet-scale rollout, but build and verify your first tunnel manually in the web admin (Network, then PepVPN/SpeedFusion); an engineer who understands the manual handshake can troubleshoot when cloud management is unreachable, which is precisely when troubleshooting happens.
On the local profile: set a Local ID using a consistent convention (site name or serial), enable AES-256 for anything mission-critical, and choose which WANs participate; cost-based selection lets you prefer cheap stable paths, fibre or satellite, before burning metered cellular data. On the remote side: enter the hub's Remote ID and public address, match the data port to your forwarding rules, apply, and watch the status page until the tunnel reads Established. If it never does, the fault is almost always ports, IDs or overlapping subnets, in that order.
Choosing sub-features: match the tool to the traffic
SpeedFusion is a suite, not a switch, and the design question is always the same: is this traffic's enemy throughput shortage, or is it jitter and loss?
Hot Failover keeps standby links warm for near-seamless transition; sufficient for ordinary business traffic, not protective against loss on an active link. Bandwidth Bonding splits a single stream across every link at packet level, so it is the answer when one flow needs more capacity than any single link offers, or when session survival through total link failure is the requirement. WAN Smoothing duplicates packets across links so the receiver uses whichever copy arrives; it is the tool for broadcast, VoIP and control traffic where a single lost packet is visible, and it roughly doubles the data consumed, so apply it to the traffic class that needs it rather than the whole tunnel. FEC sits between: parity data that reconstructs moderate loss without retransmission, at lower overhead than full duplication, particularly effective on high-latency satellite paths.
The professional pattern is layered: define sub-tunnels per traffic class, smoothing for the real-time flows, bonding for bulk, and priorities so the critical class always wins contention.
Scaling with InControl2
Once the design is proven manually, InControl2's SpeedFusion configuration turns it into a template: pick hubs and spokes, let the platform handle key exchange and routing, and enrol new sites into a known-good topology instead of hand-building each one. Fleet-wide tunnel health, latency and per-link performance then live on one screen; my InControl2 configuration guide covers the hierarchy and management-plane discipline that makes this safe at scale.
Validation before production
A tunnel that shows Established has proven nothing yet. Before an application rides it, pull each physical link in turn while a continuous test flow runs, and watch what the application experiences, not just what the status page says. Load-test at realistic peak with the protection overhead included; smoothing and encryption consume 15 to 25 percent, and a tunnel sized without that margin fails precisely at peak. Then record the working configuration and its test results, because the second-worst failure mode is an undocumented tunnel that only one departed engineer understood.
The short version
Verify licences and firmware on both peers, get the ports and addressing right, build the first tunnel by hand, match sub-features to traffic classes rather than switching everything on, template through InControl2, and validate by failure testing, not by the status page. If you have a tunnel design that needs a second pair of eyes, or a fleet that needs this done repeatably, get in touch for a scoping conversation.
Frequently asked questions
What is the difference between PepVPN and SpeedFusion?
PepVPN is the base site-to-site protocol over a single link. SpeedFusion is the multi-link suite on top: bonding, hot failover, smoothing and FEC. Entry-level hardware may carry PepVPN but need a licence for the full suite.
Why won't my tunnel establish?
In practice: blocked ports (TCP 32015 handshake, UDP 4500 data by default), mismatched Local/Remote IDs, or no reachable static IP at either end. Check those three before anything exotic.
Should I enable WAN Smoothing everywhere?
No. It roughly doubles data usage for the protected traffic. Reserve it for the real-time flows that genuinely cannot tolerate loss, and let bulk traffic ride plain bonding.
Do both ends need the same firmware?
They need compatible, recent, validated firmware; matched versions remove a whole class of subtle issues. Mind the models that require the 8.5.4 stepping stone before 8.6.0.
How much overhead should I budget?
Plan for 15 to 25 percent between encryption, encapsulation and any smoothing or FEC. Size links and FusionHub capacity so usable throughput after overhead still clears your peak requirement.