VSAT Connectivity in Low-Bandwidth Field Environments

VSAT Basics — Latency is the Real Problem

In field ICT deployments across Africa, the Middle East, and Asia, VSAT (Very Small Aperture Terminal) is frequently the only available WAN connectivity option. The key characteristics you must design around:

The most common mistake is treating VSAT like a slow fibre connection. It is fundamentally different: the latency is fixed (physics — the signal travels 72,000 km round trip to GEO orbit), which means TCP's congestion control and retransmission timers are poorly tuned for it out of the box.

Traffic Audit Before You Tune

Before touching QoS or shaping, run a traffic audit for 48–72 hours to understand what is actually consuming your bandwidth. In my experience, the top consumers in field sites are almost always:

1. Windows Update (often consuming 100% of uplink for hours)
2. Microsoft Defender signature updates
3. Cloud backup sync (OneDrive, Dropbox, personal services)
4. Video streaming (YouTube, social media) during lunch breaks
5. Zoom/Teams video calls without bandwidth caps

Use your router/firewall's flow monitoring (NetFlow, sFlow, or SNMP) or a dedicated probe like ntopng to capture this data. On a FortiGate:

# Enable flow sampling to see top talkers
config system netflow
    set collector-ip 192.168.1.100
    set collector-port 2055
    set active-flow-timeout 60
end

# Quick bandwidth usage per interface
diagnose netlink interface list
get system interface physical

QoS Classification & Queuing Design

For VSAT links, I use a 5-class QoS model. The key insight is that voice and critical operations traffic must be guaranteed a fixed bandwidth slice regardless of what else is happening on the link.

Traffic Shaping & Rate Limiting

Traffic shaping proactively enforces bandwidth limits per class or per user to prevent any single consumer from starving others. On a FortiGate (common in field deployments), configure traffic shaping policies:

Key addresses to rate-limit in a field environment

• Windows Update: *.update.microsoft.com, *.windowsupdate.com, *.delivery.mp.microsoft.com
• Defender updates: *.wdcp.microsoft.com, *.wd.microsoft.com
• Cloud backup: *.onedrive.com (if not a priority service in your context)
• Streaming: *.youtube.com, *.netflix.com, *.twitch.tv

Caching Strategies for Field Sites

A caching proxy is the single highest-ROI investment for a VSAT site. Web content served from cache does not consume satellite bandwidth. For a site with 30+ users, a small caching server (an old PC with 500 GB disk is sufficient) can reduce HTTP/HTTPS traffic by 30–50%.

Squid proxy with SSL inspection

Squid is the standard open-source caching proxy for field deployments. Deploy it on a local Linux VM:

Windows Update caching with WSUS or MCC

For Windows Update specifically, deploy Microsoft Connected Cache (MCC) — a Docker container that caches Windows Update, Defender definitions, and Intune app downloads locally. Each subsequent device on the LAN pulls updates from cache, not the satellite link.

Optimising Microsoft 365 over VSAT

M365 services are sensitive to latency. Teams calls, in particular, suffer significantly on 600–900 ms VSAT links. These optimisations make M365 usable:

• Split tunneling for VPN: If users are VPN'd to a hub, ensure M365 traffic (IP ranges published by Microsoft) bypasses the VPN tunnel and goes directly to Microsoft over the satellite link. Double-tunnelling through VPN + satellite multiplies the latency.
• Teams: enforce audio-only mode by default for VSAT sites. Configure a Teams meeting policy with video disabled. 1 video stream consumes more bandwidth than 20 audio streams.
• Exchange Online: reduce sync frequency. Configure Outlook to sync every 30 minutes instead of every 5 minutes to reduce polling traffic.
• SharePoint: pre-stage large files during off-peak hours. Use Robocopy or AzCopy to sync large SharePoint libraries overnight when contention is low.
• Outlook Cached Exchange Mode: Ensure all Outlook clients use Cached Mode — this prevents Outlook from sending real-time MAPI requests over the high-latency link for every UI action.

Monitoring a Low-Bandwidth WAN

You cannot manage what you cannot measure. For field sites, a lightweight monitoring stack that doesn't itself consume much bandwidth: