Part Twenty-Seven: Remote Management & Out-of-Band Management
The topic
Managing the fleet is one thing (InControl, Part Seventeen); reaching the gear behind a router, or recovering a site whose primary link is down, is another. Peplink’s answer is InTouch, with the InControl Virtual Appliance (ICVA) as the on-premises option for organizations that can’t use the public cloud.
How it works on Peplink
InTouch lets you reach any device behind a Peplink router, a switch, camera, PLC, PDU, legacy serial gear, to view, configure, or troubleshoot it as if you were on site. Its defining trait is that it requires no public IP, no inbound firewall holes, and no VPN client or server: the session is brokered through InControl 2 over the router’s existing connection, and every remote app is wrapped in HTTPS, so even an insecure legacy web UI can be reached securely from anywhere. That makes it fundamentally different from traditional out-of-band management (OOBM), which means building and maintaining a whole second network at every site; InTouch delivers the same “get to it remotely even when things are broken” outcome using the backup links and remote-access suite already in place, with no second network to fund. Because it can ride a backup WAN (including, per Part Twenty-Four, Iridium), InTouch is also a primary-WAN recovery tool, you can get in and fix or reboot the edge after the main circuit fails.
ICVA is InControl running as a virtual appliance inside the customer’s own infrastructure, for organizations whose policy or compliance forbids cloud-hosted management. It gives the same centralized management and InTouch capability while keeping the management plane private; InControl can be hosted publicly by Peplink or privately by the customer.
Why it matters
Remote management is how a small team supports hundreds of sites without truck rolls, and InTouch is the part that reaches the things a normal VPN can’t, the unmanaged switch, the camera, the serial RTU, without the security compromises (public IPs, open ports) that those legacy devices would otherwise force. The recovery angle is just as important: when a site’s primary link drops, InTouch over a backup path is often the difference between a remote fix in minutes and a multi-hour drive.
Field note
Lead with InTouch instead of proposing a second OOBM network, it usually wins on both cost and security. For customers who can’t accept cloud management, position ICVA early; it changes the architecture (private hosting) so it shouldn’t be a late surprise. And pair InTouch with a reliable backup WAN, the whole point is reaching the site when the primary is down.
From the field — recovering a rig over Iridium: When a remote oil-and-gas site lost its primary WAN, admins reached it over an Iridium backup with InTouch to monitor, reboot, and restore the edge remotely, no flight, no truck. InTouch needs no public IP or VPN, so even the legacy gear behind the router was reachable the moment a backup path existed.
Part Twenty-Eight: Diagnostics Toolkit & Certification Path
The topic
Part Twenty-One covered the common mistakes and the fast playbooks; this part is the structured toolkit underneath them, the instruments a Peplink engineer reaches for, in order, plus the certification ladder that formalizes the skill.
How it works on Peplink
Troubleshooting on Peplink moves from the simplest signal outward, and almost every tool is built into the router or InControl, with nothing to install:
- Status lights — the first read at the device: power, boot, WAN, Wi-Fi, and cellular state, before you ever log in.
- Dashboard — the at-a-glance health page: per-WAN status, SpeedFusion status, connected clients and managed APs, IPsec, and device information (CPU load, temperature, uptime).
- Active sessions — what the box is actually carrying right now, searchable by protocol, IP, or interface, the fastest way to see who is using what.
- Event log — the timeline of what happened: links going up and down, SpeedFusion state changes, configuration applies.
- support.cgi — the deep diagnostic dump for hard cases and for sending to support.
- WAN Analysis — measures a link’s real quality (throughput, latency, loss, jitter) end to end between two Peplink endpoints (ports TCP/UDP 6000–6008, Part Twenty); use it to characterize a circuit before and after tuning.
- SpeedFusion test — puts synthetic load across each sub-tunnel and the bond as a whole so you can prove the tunnel’s real capacity.
- Real-time charts — live throughput, latency, and jitter on the router and in InControl, the picture that turns “it feels slow” into a number.
- Connection / speed tests — built-in reachability and throughput tests against external endpoints.
- Cellular site survey (Part Twenty-Two) and Wi-Fi site survey — characterize the RF environment before committing.
The non-tool tool is “draw your network.” Sketching the topology, WANs, VLANs, subnets, tunnels, endpoints, before touching settings is the single habit that prevents the overlapping-subnet, missing-route, and wrong-VLAN mistakes from Part Twenty-One.
The skill is formalized in Peplink’s certification path: PCSS (Sales Specialist, the product and positioning foundation), PCA (Certified Associate, hands-on configuration and deployment), and PCE (Certified Engineer, advanced design, integration, and troubleshooting, the level this complete-edition document is written toward).
Why it matters
Knowing the order, signal then dashboard then sessions then log then targeted test, is what separates a methodical engineer from one who guesses and reboots. Each instrument answers a specific question, and reaching for the right one first turns an afternoon of theorizing into a few minutes (the OSI-layer discipline from the fundamentals paper, applied with Peplink’s own tools). The certification ladder gives the team a shared vocabulary and a measurable training target.
Field note
When a ticket comes in, resist changing settings until you’ve read the lights, the dashboard, and the event log, the cause is usually already visible. Use WAN Analysis and the SpeedFusion test to get numbers before and after any change so you can prove the fix. And keep a current network drawing for every customer; it pays for itself the first time something breaks.
Part Twenty-Nine: Edge Computing
The topic
Some Peplink routers don’t just move traffic, they run applications. Edge computing means placing compute out where the devices and users are, instead of round-tripping everything to a data center or cloud, so that internet and transport latency stop being a factor for local workloads.
How it works on Peplink
Edge-capable Peplink models, the Balance EC line (for example the Balance 2500 EC and the Balance 5000 EC) and select MBX/BR units, can host customer applications directly on the router, either as a virtual machine or as a native app deployment. The router becomes an all-in-one box: WAN bonding and security plus a local compute platform. Typical patterns are an on-vehicle infotainment or telematics app, a local data-processing node that aggregates and filters sensor data (wind speed, temperature, humidity) before sending only what matters upstream, and in-store or on-site services that must keep working even when the WAN is degraded.
Why it matters
Edge computing addresses three things at once: speed and bandwidth (process locally, send less), resilience (a local app keeps running through a WAN hiccup), and security (a compromised segment can be cordoned off, and extra on-box processing can feed threat analysis). For IoT, industrial, and transportation customers it removes a separate edge server from the bill of materials, the Peplink box is already there, already managed, and now also runs the workload. It’s a genuine differentiator when a customer is comparing a router to a router.
Field note
Reach for an EC model when the use case has a latency-sensitive or bandwidth-heavy local workload (video analytics, sensor aggregation, infotainment) or must keep functioning during WAN outages. Size the platform (CPU, memory) to the app the same way you’d size a small server, and keep the compute and the networking config under the same InControl management so the whole edge is governed in one place.
From the field — compute on the vehicle: A transportation deployment ran infotainment and telematics as apps directly on the edge-capable Peplink router, and an industrial site aggregated sensor data (wind speed, temperature, humidity) locally before sending only what mattered upstream. Both kept working through WAN hiccups because the compute was already on-site.
Part Thirty: Adding WAN Capacity — Virtual WAN & Synergy
The topic
Sometimes a site needs more WAN inputs than the router has physical ports, or you want to add capacity to an existing controller without replacing it. Peplink offers two answers: Virtual WAN (VLAN-as-WAN) and Synergy mode.
How it works on Peplink
Virtual WAN (the Virtual WAN Activation License) lets you create a WAN on a VLAN rather than on a dedicated physical port, on either a WAN or a LAN interface. On a Balance 20X, for example, the license adds up to three additional virtual WAN inputs. This is not the same as “WAN-as-LAN” (which repurposes a physical WAN port as a LAN port); a virtual WAN frees you from the physical port count entirely. The one limit to remember: a virtual WAN on a LAN interface is bounded by the LAN bus, if the LAN is 1 Gbps, all virtual WANs riding it share that 1 Gbps. Virtual WAN is heavily used in the field, you’ll see “VLAN as WAN 3001/3101/3103…” throughout real West Networks designs, often to take a trunked upstream or a public-IP VLAN in as a WAN.
Synergy mode lets a controller (the Synergy Controller, an X-Series, Balance, or MAX) absorb the WAN ports of other Peplink devices (the synergized devices) so their cellular or wired WANs appear as additional WANs on the controller. There’s no fixed limit on how many devices you synergize, only how many WAN ports you have to land them on. Prerequisites: firmware 8.3.0 or later and the same firmware on both ends, an active care plan, and the controller must have at least one active WAN (besides the synergy link) that can reach InControl. A typical use is bolting a BR1 Pro 5G’s cellular onto a Balance to add a 5G WAN without swapping the Balance.
Why it matters
These are how you scale WAN capacity gracefully, add a 5G uplink to an existing fiber Balance, take in a trunked carrier VLAN, or grow a site past its physical ports, without a forklift upgrade. They’re common enough in real designs that an engineer who doesn’t recognize “VLAN as WAN” or Synergy will be lost reading a West Networks topology.
Field note
This is the home of the single most important gotcha in this document, repeated here because it bites everyone: adding a WAN to the device is not the same as adding it to the SpeedFusion tunnel. When you synergize a device, add a virtual WAN, add a modem, or light up a second ISP, the new interface defaults to a disabled priority inside every SpeedFusion profile, so the tunnel ignores it for bonding and failover until you explicitly add and prioritize it. The classic failure (Part Twenty-One): a Balance 380 synergizes a BR1 Pro 5G, the broadband fails, and nothing fails over, because the 5G was never enrolled in the tunnel (Part Thirty-Three walks through exactly this as a real West Networks case). Every time you add a WAN, open each SpeedFusion profile’s WAN list, add the interface, enable its priority, and test by pulling the primary.
Part Thirty-One: Newer Security, VPN & WAN Features
The topic
Peplink ships features continuously, and several recent additions (firmware 8.4 through 8.6) are now fundamentals rather than curiosities. An engineer should know what they are and when to reach for them.
How it works on Peplink
- SpeedFusion Boost (firmware 8.6.0, Part Eight) — prevents a slower link from dragging down faster ones, maximizing throughput over high-latency bonded paths (cellular, LEO). All models.
- WireGuard Remote Access VPN (8.6.0) — WireGuard added as a remote-user access VPN: faster, simpler, and more reliable client VPN than legacy options, with less setup and better performance across networks. This is the modern answer for client-to-site remote access alongside the classic options in the Networking Fundamentals paper.
- FIPS 140-2 (permanent activation on eligible devices, 8.6.0; 140-3 coming) — government-grade encryption enforcement for regulated industries; relevant any time you sell into government, defense, or healthcare.
- RadSec (RADIUS over TLS) (8.6.0) — encrypts Wi-Fi authentication traffic across untrusted or cloud-connected networks, hardening enterprise 802.1X (Part Twenty-Five).
- Native OneWeb support (8.6.0, Part Twenty-Four) and ongoing Starlink integration improvements.
- Jumbo Frame support (8.6.0) — larger MTU on capable links for efficiency on high-throughput LAN/WAN paths (mind the MTU/MSS interplay from the fundamentals paper).
- Per-WAN bandwidth limiting (8.6.0) — cap a specific WAN, useful for metered or expensive links.
- Wi-Fi metered networks (8.6.0) — treat a Wi-Fi-as-WAN uplink as metered so the router limits background usage on it.
- NetFlow enhancements and expanded QoS user groups (8.4/8.5, groups raised from 3 to 10) — finer traffic visibility and shaping.
- Synergy mode (Part Thirty) and SFC Relay access control round out the set.
Why it matters
Firmware is where Peplink’s competitive edge keeps moving, and a fundamentals course frozen at one release goes stale fast. The security and VPN additions in particular change what you can promise: WireGuard for clean remote access, FIPS for regulated buyers, RadSec for enterprise Wi-Fi, per-WAN limiting and metered Wi-Fi for cost control. Knowing these exist, and which firmware introduced them, lets you answer “can Peplink do X?” correctly instead of from last year’s knowledge.
Field note
Check the firmware release notes each cycle and confirm a feature’s model support before promising it, several of these are gated to specific models or SKUs (FIPS, for instance, excludes some entry and region-locked SKUs). Treat firmware currency as part of the deployment: the newest stable release often turns a “no” into a “yes.”
From the field — meeting the security bar: A regulated buyer required FIPS-validated encryption and clean remote access for distributed staff; permanent FIPS 140-2 on eligible devices and WireGuard Remote Access VPN, both in firmware 8.6.0, turned a “Peplink can’t meet our compliance” objection into a yes. Knowing which firmware shipped which feature is what wins those deals.