A VPN tunnel can be configured to carry all of a site's traffic or only some of it, and for a remote gateway on a metered cellular link that choice has real consequences for bandwidth and latency. A split-tunnel VPN sends only the traffic that needs protecting, the SCADA host traffic, through the encrypted tunnel, while letting everything else reach the internet directly. This guide explains the difference between split and full tunnelling, why routing only SCADA traffic through the tunnel saves cellular bandwidth and reduces latency, and what an operator gives up in exchange for that efficiency.
Split-tunnel VPN in one line: A split-tunnel VPN routes only selected traffic, typically the SCADA host traffic, through the encrypted tunnel, while all other traffic breaks out to the internet directly. A full-tunnel VPN, by contrast, forces every packet through the tunnel. Split tunnelling saves cellular bandwidth and reduces latency by not sending unrelated traffic on a detour through the VPN endpoint, at the cost of the extra oversight a full tunnel provides over all of the site's traffic.
The distinction is about scope: which of a site's traffic the VPN tunnel carries. A full-tunnel configuration sends everything the site generates through the encrypted tunnel to the VPN endpoint, and from there onward, so every packet, whether it is bound for the SCADA host or anywhere else, takes the tunnel first. A split-tunnel configuration is selective: it defines which destinations go through the tunnel, usually the SCADA host and related systems, and lets all other traffic take the ordinary path straight out to the internet without entering the tunnel at all.
The mechanism is routing. In a split tunnel, the gateway is configured with routes that direct traffic for the protected destinations, the SCADA host addresses, into the tunnel, while its default route sends everything else out locally. In a full tunnel, the default route itself points into the tunnel, so there is no local breakout and everything is captured. The difference between the two is therefore just a matter of how the gateway's routing is set up, but the operational consequences of that routing choice are significant.
It helps to be clear that this is a different question from what a VPN tunnel is or how it protects traffic. Both split and full tunnels can use the same encryption and provide the same protection to whatever they carry; the split-versus-full decision is only about how much of the site's traffic is placed inside the tunnel in the first place. The encryption and authentication are the same either way. What changes is the tunnel's scope, and that scope is what drives the bandwidth, latency, and oversight trade-offs that follow.
On a full tunnel, all of a site's traffic detours through the VPN endpoint even when its destination has nothing to do with the SCADA system. If a gateway or an attached device reaches out for an update, a time source, or any other internet service, that traffic is dragged into the tunnel, sent to the VPN endpoint, and only then forwarded on, and the responses come back the same long way. On a metered cellular link that detour consumes bandwidth carrying traffic that did not need protecting and did not need to go there, and it adds latency because every packet takes a longer path than the direct route would.
A split tunnel eliminates that waste for everything except the SCADA traffic. Because only the SCADA host traffic is routed into the tunnel, unrelated traffic breaks out locally and takes the shortest path to its destination, neither consuming tunnel bandwidth nor incurring the extra hop to the VPN endpoint and back. On a bandwidth-constrained, latency-sensitive cellular connection this is a meaningful efficiency: the scarce link capacity is spent on the traffic that matters, and the SCADA traffic itself is not competing with a lot of unrelated packets that a full tunnel would have forced through the same encrypted path.
The latency benefit compounds the bandwidth one. SCADA polling and reporting care about timely, consistent round trips, and a full tunnel that routes even the SCADA traffic through a distant endpoint can add delay to that path, while also loading the link with the unrelated traffic it is carrying. A split tunnel keeps the tunnel lean, carrying only what needs protecting, which tends to give the SCADA traffic a cleaner, less congested path. For remote sites where every kilobyte and every millisecond counts, sending only what must be tunnelled is the efficient default.
What a split tunnel gives up is centralized oversight of all the site's traffic. With a full tunnel, everything the site sends passes through the operator's VPN endpoint, so it can all be inspected, filtered, and logged in one place, which some security postures value highly. A split tunnel deliberately lets non-SCADA traffic bypass that chokepoint, so that traffic is not seen or controlled by the central endpoint, and any policy for it has to be enforced elsewhere, at the gateway or through other controls. Whether that matters depends on how much untrusted or general traffic the site actually generates.
In practice, the case for split tunnelling is strongest exactly where remote SCADA sites live, because those sites usually generate very little traffic that is not SCADA-related, and they sit on constrained, costly cellular links where efficiency matters. When the only traffic worth protecting and centralizing is the SCADA host traffic, and there is little else besides, tunnelling everything gains little oversight while costing real bandwidth and latency. The split tunnel captures the traffic that matters and spares the link the rest, which aligns the configuration with how these sites are actually used.
For an operator feeding a cloud SCADA platform such as Merobix, a split tunnel that routes just the traffic to the platform's endpoints through the VPN is often the natural fit. The SCADA data gets the protected, controlled path it needs to reach the platform, while the gateway's occasional other traffic breaks out locally without burdening the cellular link. This pairs well with tight egress controls such as an APN whitelist, which can independently constrain where the non-tunnelled traffic is even allowed to go, so the split tunnel delivers its bandwidth and latency savings without leaving the local breakout as an open door. The result is an efficient connection that spends its scarce capacity on the SCADA conversation that the site exists to have.
A full tunnel routes all of a site's traffic through the encrypted VPN tunnel, so every packet goes to the VPN endpoint first regardless of destination. A split tunnel routes only selected traffic, typically the SCADA host traffic, through the tunnel and lets everything else break out to the internet directly. Both can use the same encryption; the difference is only how much of the site's traffic is placed inside the tunnel.
In a full tunnel, unrelated traffic such as updates or time-sync detours through the VPN endpoint, consuming link bandwidth and adding latency even though it did not need protecting. A split tunnel keeps only the SCADA traffic in the tunnel and lets other traffic take the shortest local path out, so the scarce cellular capacity is spent on the traffic that matters and the SCADA path is not competing with unrelated packets. That saves both bandwidth and latency.
You lose centralized oversight of the traffic that bypasses the tunnel. With a full tunnel, everything passes through the operator's VPN endpoint where it can be inspected, filtered, and logged in one place, whereas a split tunnel lets non-SCADA traffic reach the internet directly, unseen by that chokepoint. Whether this matters depends on how much non-SCADA traffic the site generates; remote SCADA sites usually generate little, so the trade-off often favours the split tunnel.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.