TCP Acceleration¶
TCP Acceleration makes TCP applications (web, file transfer, SaaS, database and API traffic) much faster over long, high-latency links such as satellite, long-distance international circuits and congested cellular. It works transparently: users, servers and applications need no changes, and nothing is installed on end devices.
On a 550 ms satellite-class path, accelerated traffic typically completes about twice as fast, and downloads run up to 3 times faster (see Expected Performance).
Overview¶
The Problem¶
TCP was designed for short, low-latency paths. Over a long path, two of its built-in behaviours hold every connection back, no matter how much bandwidth the link has:
- Connection setup — every new connection waits a full round trip for its handshake before the first byte of data moves. At 600 ms, opening a web page with dozens of connections spends most of its time just waiting.
- Slow start and window limits — a TCP sender ramps up its sending rate one round trip at a time, and can never have more data in flight than its window allows. The longer the round trip, the slower the ramp and the lower the ceiling.
The result is a link that tests well on a speed test but feels slow for real applications, especially short transfers.
How TCP Acceleration Works¶
TCP Acceleration splits each TCP connection into three parts at the two routers on either end of the long path:
- The branch router (client role) answers the LAN device's connection locally, so the handshake completes in milliseconds instead of a full round trip.
- The data is carried across the long path inside a small pool of pre-established, always-warm sessions between the two routers. These sessions are already up to speed, so a new connection skips both the handshake and slow start on the long leg.
- The hub router (server role) opens the real connection to the destination server and relays the data in both directions.
The routers decide which connections to accelerate by their normal routing decision: any new TCP connection that the branch routes out an accelerated interface is accelerated, including connections steered there by Traffic Steering policies.
If the accelerated sessions are unavailable (hub unreachable, misconfiguration), new connections automatically go direct, unaccelerated — traffic keeps flowing.
Congestion Control¶
Congestion control is the logic that decides how fast TCP sends and how it reacts when the path is congested. TCP Acceleration uses CUBIC on the accelerated long leg, on both the branch and the hub/gateway:
- Window growth is based on time, not round trips. Classic TCP grows its sending window once per round trip, so a 600 ms path ramps up 20–30 times slower than a local one. CUBIC grows its window as a function of the time since the last loss, so long paths regain speed far faster.
- Fast return to the previous rate. After a loss CUBIC reduces its rate by about 30% (classic TCP halves it), climbs quickly back toward the rate where the loss happened, holds steady near it, then probes carefully for more.
- Predictable and fair. CUBIC is loss-based and is the default in Linux and most operating systems, so accelerated sessions share links fairly with other traffic.
Because the long leg is carried by sessions established in advance and shared by many connections, the slow start that normally penalises every new connection on a long path is avoided, and CUBIC only has to manage the steady flow on the shared sessions.
Other congestion control algorithms, including model-based ones such as BBR, were evaluated. On satellite and cellular paths with alternating upload and download traffic, CUBIC gave the most consistent results; BBR occasionally held a download far below the link rate after an upload. CUBIC is therefore the default.
Benefits¶
- About 2x faster for typical TCP traffic over satellite-class latency; downloads up to 3x faster
- Much faster page loads and short transfers — connection setup happens locally instead of across the long path
- Better use of available bandwidth — accelerated sessions reach the link's capacity instead of being held back by TCP window limits
- Transparent — no client software, no application or server changes
- Fail-safe — falls back to direct, unaccelerated forwarding if the accelerator is unavailable
- Resilient — on a VPN tunnel it follows the tunnel through WAN failover, so existing connections are kept when a WAN link fails (see Resiliency and WAN Failover)
- Point-to-multipoint — one hub serves any number of branches with a single setting
- Works over any interface — VPN tunnels (recommended), Ethernet or cellular WAN interfaces
Use Cases¶
| Scenario | Why it helps |
|---|---|
| Vessels, remote sites and rigs on satellite (GEO, ~550–700 ms) | Removes most of the per-connection latency penalty; web and SaaS feel responsive |
| Branches reaching HQ or a data centre over long-distance international paths | Higher throughput per connection for file transfers, backups, ERP and database traffic |
| Sites on cellular with high or variable latency | Faster page loads and API calls; downloads use more of the available bandwidth |
| Many small transfers (web, APIs, SaaS, POS, telemetry) | Short connections gain the most: each one skips a full handshake round trip |
| Centralised internet breakout through the hub | Branch web browsing through the hub's internet link is accelerated end to end |
TCP Acceleration helps TCP only. It does not change UDP traffic, including voice, video calls, DNS and QUIC (HTTP/3).
Requirements¶
| Item | Requirement |
|---|---|
| Firmware | A release that includes TCP Acceleration on both routers — see Branch Release Notes and Gateway Release Notes |
| Roles | One router runs the server role (hub/gateway); each branch runs the client role. Point-to-point links can run both roles on both ends (p2p) |
| Interfaces | Any interface type: WireGuard tunnel (recommended), other tunnels (IPsec, GRE, VXLAN), or Ethernet/cellular WAN |
| Server port | TCP 7070 on the server's address on the accelerated interface. Inside a tunnel no extra configuration is needed; over a WAN interface the hub must be reachable on TCP 7070 (see Firewall and NAT) |
| Addressing | IPv4 |
| Authentication | Optional pre-shared key (psk), required when the accelerated interface is a WAN interface |
Deployment Scenarios¶
TCP Acceleration can be enabled on any interface type, but it is best applied on a VPN tunnel interface, especially WireGuard:
- the tunnel already encrypts and authenticates the traffic between the routers;
- the server listens on the tunnel address, so no firewall or NAT changes are needed;
- the accelerated path follows the tunnel, including across WAN failover.
In mfusion, the setting can be pushed as part of the VPN instance settings, or as an interface setting for Ethernet (ethX) and cellular (wwanX) interfaces.
Hub-and-Spoke (One-to-Many)¶
The most common deployment. Applications and the internet breakout sit behind the hub; every branch accelerates the TCP connections its users open toward the hub. The hub runs the server role once for all branches; each branch runs the client role.
Hub (server role) — one line per tunnel interface, serving every branch on that tunnel:
Each branch (client role) — point the client at the hub's tunnel address:
Note
In hub-and-spoke, only connections opened from the branch side are accelerated (data then flows fast in both directions). Connections opened from behind the hub toward a branch — for example a server at HQ connecting to a device at the branch — are forwarded normally, unaccelerated.
Spoke-to-Spoke via the Hub¶
When branches reach each other through the hub, the same hub-and-spoke configuration applies: the hub is the server and the branches are clients. A connection from Branch 1 to a host at Branch 2 is accelerated on the long leg from Branch 1 to the hub; the hub then opens the connection to Branch 2 over its tunnel as normal TCP.
No extra configuration is needed beyond the hub-and-spoke settings above.
Point-to-Point (Two-Way)¶
On a dedicated tunnel between two sites — for example a site-to-site WireGuard tunnel or a link in a mesh VPN — both sides open connections to each other. Use the p2p role on both ends: each router runs both client and server, so connections are accelerated whichever side opens them.
Site A:
Site B:
Note
The p2p role needs a point-to-point subnet (/30 or /31) so each side can find the other automatically. On any other subnet it runs as server only and shows a warning — use the client and server roles instead.
Over a WAN Interface (No Tunnel)¶
TCP Acceleration can also run directly on an Ethernet or cellular WAN interface, for example when traffic to a hosted service is routed straight out the WAN. The branch points the client at the hub's public address, and the hub runs the server role on its WAN interface. Always set a psk on both ends in this case.
Hub:
Branch:
Warning
Never enable the server role on an internet-facing interface without a psk. Without authentication, anyone who can reach TCP 7070 could relay connections through the hub. The accelerator authenticates sessions with the psk but does not encrypt them; use a VPN tunnel when the traffic must be protected in transit.
Pre-Shared Key on Tunnels¶
A psk can also be added to any role on a tunnel interface for extra assurance. It must match on both ends:
Removing TCP Acceleration¶
Connections already in progress through the accelerator are closed; new connections are forwarded normally.
Resiliency and WAN Failover¶
When TCP Acceleration runs on a VPN tunnel interface, it lives inside the tunnel and inherits the tunnel's resiliency. If the branch's active WAN link fails, the router's WAN failover mechanisms move the tunnel to another available link (for example from fibre to 4G/5G), and the accelerated sessions move with it:
- Existing connections are kept. Accelerated connections are not dropped and applications do not need to reconnect when the tunnel moves to another WAN link — no accelerator change or reconfiguration is involved.
- Expect a short pause, not a reset. Traffic pauses while the tunnel moves to the new link, then resumes. The pause depends mainly on how quickly the failure is detected: a link that goes down (cable unplugged, carrier lost) switches over in seconds, while a failure detected by health-check probes adds the detection time. On high-latency links TCP itself takes a few extra seconds to resume after any outage.
- Failback is handled the same way when the original link recovers.
A prolonged outage of the tunnel itself — every WAN link down — can end transfers that are in progress, as it would without acceleration; new connections are accelerated again as soon as the tunnel is back.
Combining WAN links
TCP Acceleration speeds up traffic over the path a tunnel uses; it does not combine the bandwidth of several WAN links. Aggregating multiple WAN links into a single higher-capacity connection is covered in a separate topic.
Firewall and NAT¶
| Deployment | What to configure |
|---|---|
| Accelerated tunnel interface | Nothing. The server listens on its tunnel address and the router opens TCP 7070 on that tunnel only |
| Accelerated WAN interface, hub directly on the internet | Nothing on the router (TCP 7070 is opened on that interface automatically). Ensure upstream firewalls allow inbound TCP 7070 to the hub |
| Accelerated WAN interface, hub behind a firewall or NAT | On the upstream firewall, forward TCP 7070 on the public address to the hub's WAN address, and point branches at the public address with tcp-accelerate client peer <public-ip> |
| Branch behind NAT | Nothing. Branches only make outbound connections to the hub |
If the accelerator runs on a tunnel interface, port forwarding may be needed to establish the tunnel (if it's behind another router or firewall).
MTU and TCP MSS¶
No MTU or MSS setting is needed for TCP Acceleration:
- Accelerated long leg — the sessions between the routers are opened by the routers themselves on the accelerated interface, so their segment size follows that interface's MTU automatically. On a tunnel, this is the tunnel MTU the router already discovers and maintains.
- Short legs — the LAN client's connection to the branch, and the hub's connection to the destination server, each negotiate their own segment size on their local network.
- Traffic that is not accelerated (UDP, IPv6, connections that fall back to direct forwarding) keeps using the router's automatic per-tunnel TCP MSS clamping as before. See TCPMSS Clamp to PMTU.
If a tunnel's MTU is wrong (for example a cellular modem MTU that needs manual attention), fix it at the tunnel or WAN level as described in MTU Configuration and Troubleshooting; accelerated sessions then follow the corrected MTU.
Expected Performance¶
Measured with an x86 hub and branch routers on a path with about 550 ms round-trip time (satellite-class), median of repeated runs, VXLAN over WireGuard.
HSA-520-class branch (ARM), cellular WAN:
| Traffic | Without acceleration | With acceleration | Improvement |
|---|---|---|---|
| 10 small downloads (512 KB each, new connection each) | 92 s | 48 s | 1.9x faster |
| Single download | 6.4 Mbit/s | 13.5 Mbit/s | 2.1x |
| Download, 4 connections | 16.0 Mbit/s | 43.9 Mbit/s | 2.7x |
| Single upload | 9.3 Mbit/s | 20.2 Mbit/s | 2.2x |
| Upload, 4 connections | 17.5 Mbit/s | 21.7 Mbit/s | 1.2x |
HSA-520-class branch (ARM), fixed broadband WAN (median of three runs):
| Traffic | Without acceleration | With acceleration | Improvement |
|---|---|---|---|
| 10 small downloads (512 KB each, new connection each) | 86 s | 47 s | 1.8x faster |
| Single download | 5.5 Mbit/s | 16.7 Mbit/s | 3.1x |
| Download, 4 connections | 16.8 Mbit/s | 48.9 Mbit/s | 2.9x |
Without acceleration, the sender's TCP window on this path settled between about 300 and 800 KB: after each loss burst it halved and regrew only once per 550 ms round trip, which caps a connection at roughly 5–11 Mbit/s however fast the link is. With acceleration, the long leg runs over persistent connections whose windows have already grown. The same setup without the added latency carried 75–100 Mbit/s with or without acceleration, so these results are not limited by the link or the router.
Over a cellular link with high latency (IPsec tunnel), ten small downloads completed in 49 s instead of 93 s, and single downloads rose from 19.6 to 30.8 Mbit/s.
What affects the gain:
- Round-trip time — the longer the path, the larger the gain. Below about 50 ms the improvement is small and may not justify the extra CPU; on a 10 ms path there was no gain, and short transfers were slightly slower (14 s vs 12 s for ten 512 KB downloads).
- Transfer size and count — many short connections gain the most (each skips a handshake round trip); long bulk transfers gain from faster ramp-up and higher in-flight data.
- Router CPU — the accelerator relays traffic through the router's CPU. On entry-level models the CPU can become the limit before the link does (see below).
Limitations and When Not to Use It¶
Router CPU (Entry-Level Models)¶
Acceleration processes every accelerated byte on the router CPU. On entry-level routers such as the XE-300, the CPU saturates at modest rates, and acceleration can make bulk transfers slower:
| XE-300, 550 ms path | Without | With |
|---|---|---|
| 10 small downloads | 86 s | 47 s (faster) |
| Download, 4 connections | 7.3 Mbit/s | 16.4 Mbit/s (faster) |
| Upload, 4 connections | 16.5 Mbit/s | 7.4 Mbit/s (slower) |
On entry-level models, enable acceleration for browsing, SaaS and download-heavy sites; leave it off for upload-heavy sites (backups, CCTV upstream). On HSA-520-class routers this limit is well above typical satellite and cellular rates.
Gateway-class (x86) routers used as branches have far more CPU headroom, so performance is much less likely to be limited by turning TCP Acceleration on. The achievable rate still depends on the model, the total traffic the router carries, and the speed of the link or tunnel in use.
Latency for Other Traffic Under Heavy Load¶
Accelerated transfers fill the link more effectively. During heavy bulk transfers, latency for other traffic sharing the link (for example voice or video calls) can rise noticeably; in testing, peak round-trip time under load rose from about 560 ms to 1.5 s. Combine acceleration with Traffic Shaping to protect real-time traffic, or leave it off on links dedicated to real-time services.
Other Limitations¶
| Limitation | Details |
|---|---|
| TCP only | UDP traffic (voice, video calls, DNS, QUIC/HTTP3) is not accelerated |
| IPv4 only | IPv6 TCP is forwarded normally |
| Forwarded traffic only | Connections opened by the router itself (management, routing protocols) are not accelerated |
| Direction (client/server) | Only connections opened from the client side are accelerated; use the p2p role on point-to-point links for both directions |
| Source address at the destination | The destination server sees the hub's address as the connection source, not the original LAN client's address. Adjust server allow-lists or logging that rely on the client IP |
| Connection reporting | A LAN client's connection is answered locally first. If the destination then refuses or is unreachable, the client sees the connection close instead of a refusal |
| Existing connections | Only new connections are accelerated; connections open before enabling continue as before |
| End-to-end TCP options | Each leg negotiates its own TCP options; applications relying on end-to-end TCP behaviour (rare) may be affected |
| Fast-path offload | On branch routers, enabling the client role disables hardware/software fast-path forwarding, which raises CPU usage for all forwarded traffic |
When Not to Use It¶
- Low-latency links (below about 50 ms): little gain, extra CPU.
- Entry-level routers carrying heavy uploads (see XE-300 above).
- Links dedicated to real-time UDP (voice/video): nothing to accelerate, and shared-link latency can rise during transfers.
- Applications that must see the original client IP at the server, unless the server's allow-list or logging can use the hub address instead.
Verification¶
| Items to Test | Command | Expected Outcome |
|---|---|---|
| Client is connected to the hub | show tcp-accelerate (branch) |
HEALTH up, POOL 4/4 for the interface |
| Connections are being accelerated | show tcp-accelerate (branch), then open a few web pages from a LAN device |
New TCP conns shows classified and accelerated counts increasing; ACTIVE/TOTAL rise |
| Hub sees each branch | show tcp-accelerate (hub) |
Each branch listed under CLIENT with STATE up, 4 sessions and a measured RTT |
| psk accepted | show tcp-accelerate (hub) |
AUTH psk, AUTHFAIL 0 for the listener |
| Fallback works | Remove the server role on the hub temporarily | Branch HEALTH changes to failing; LAN traffic still flows (FALLBACK count rises) |
Branch (client) example:
Router# show tcp-accelerate
====================================================================================================================
TCP Accelerate : vxlan1 (client)
====================================================================================================================
Client role : classifier running, up 1h13m
New TCP conns : 7 classified, 7 accelerated, 0 lookup errors
====================================================================================================================
INTERFACE PEER AUTH HEALTH POOL PORT MARK ACTIVE TOTAL FAILED FALLBACK OUT IN
--------------------------------------------------------------------------------------------------------------------
vxlan1 10.1.172.1:7070 none up 4/4 7101 0xa0100000 0 7 0 0 274.34MB 1.1KB
--------------------------------------------------------------------------------------------------------------------
Hub (server) example:
Router# show tcp-accelerate
====================================================================================================================
TCP Accelerate : vxlan1 (server)
====================================================================================================================
Server role : running, up 13h2m, 1 listener(s), tcp/7070
Sessions : 8 authenticated, 0 authentication failure(s) since start
Connections : active 0, total 433, failed 0, aborted 144
Traffic : peer->dest 2.94GB, dest->peer 1.37GB
====================================================================================================================
INTERFACE LISTEN AUTH SESSIONS AUTHFAIL CLIENTS
--------------------------------------------------------------------------------------------------------------------
vxlan1 10.1.172.1:7070 none 8 0 2
--------------------------------------------------------------------------------------------------------------------
CLIENT INTERFACE STATE SESSIONS CONNECTED RTT ACTIVE TOTAL FAILED UP DOWN
--------------------------------------------------------------------------------------------------------------------
10.1.172.3 vxlan1 up 4 13h2m 4.3ms 0 0 0 0B 0B
10.1.172.4 vxlan1 up 4 9h31m 554.5ms 0 34 0 30.71MB 91.41MB
--------------------------------------------------------------------------------------------------------------------
Each branch keeps its sessions alive with a keepalive every 15 seconds, so the hub's CLIENT list and RTT stay current even when idle. A disconnected branch is listed under Problems with the time it was last seen.
Status fields:
| Field | Meaning |
|---|---|
| HEALTH | up — all sessions to the hub are up; degraded — some are up; failing — none, new connections go direct (unaccelerated) |
| POOL | Warm sessions up / configured (4) |
| ACTIVE / TOTAL / FAILED | Accelerated connections now / since start / failed to open |
| FALLBACK | Connections sent direct because no session was available |
| OUT / IN | Bytes carried toward / from the hub |
| AUTHFAIL (hub) | Sessions rejected for a psk mismatch |
| RTT (hub) | Round-trip time to each branch, from the keepalive |
Troubleshooting¶
| Symptom | Likely Cause | Solution |
|---|---|---|
HEALTH failing, POOL 0/4 |
Hub unreachable on TCP 7070, wrong peer address, or server role not configured | Check tcp-accelerate client peer <ip> matches the hub's address on that interface; confirm the hub shows the server role; on a WAN interface check upstream firewall/NAT for TCP 7070 |
| Hub shows AUTHFAIL increasing | psk mismatch (or psk set on one side only) | Set the same psk on both ends, or remove it from both |
classified stays at 0 |
Traffic is not routed out the accelerated interface, or it is not TCP/IPv4 | Check the route to the destination points at the accelerated interface; remember UDP/QUIC, IPv6 and router-originated traffic are not accelerated |
| No improvement | Low-latency path, or bulk single transfer already at link capacity | Expected — the gain grows with round-trip time. Compare with a test across the high-latency path |
| Slower with acceleration (entry-level model) | Router CPU saturated | Leave acceleration off for upload-heavy sites on entry-level routers |
| p2p role shows "p2p: server only, not point-to-point" | The interface subnet is not /30 or /31 | Use a /30 or /31 on the point-to-point link, or use client/server roles |
| Destination server rejects or logs the wrong client IP | The connection now originates from the hub | Allow the hub's address on the server, or exclude that traffic from the accelerated route |
| Voice/video quality drops during large downloads | Accelerated transfers fill the link | Apply Traffic Shaping to prioritise real-time traffic |
Best Practices¶
- Prefer tunnel interfaces, especially WireGuard. The tunnel provides encryption, NAT traversal and failover; acceleration rides inside it with no firewall changes.
- Enable on high-latency paths (satellite, long-distance, high-latency cellular). Measure before and after on low-latency links.
- One server role per hub tunnel: a single
tcp-accelerate serverserves every branch on that tunnel. - Always use a psk on WAN interfaces, and use strong, unique keys.
- Match router capacity to the site: on entry-level routers, enable for browsing-heavy sites and avoid upload-heavy ones.
- Protect real-time traffic with Traffic Shaping when voice or video shares the accelerated link.
- Check the destination's source-IP expectations before enabling for traffic to servers with IP allow-lists.
Related Features¶
- VPN Topology — hub-and-spoke, spoke-to-spoke and full-mesh designs
- VPN Instance — tunnel configuration
- Multi-WAN — WAN failover underneath the accelerated tunnel
- WAN Failover — use-case guide for automatic failover between WAN links
- Traffic Steering — choose which traffic uses the accelerated path
- Traffic Shaping — protect real-time traffic on accelerated links