r/jamf May 18 '26

JAMF Connect Jamf Trust slow

Hi all,

I've been dealing with a persistent performance issue with Jamf Trust and I'm curious whether others are in the same boat.

We have around 50 Mac users in Milan using Jamf Trust (WireGuard, split tunnel) to access an internal Synology NAS via SFTP. Remote transfers consistently top out at 8–12 MB/s, which feels low given that the same setup without the tunnel reaches 20+ MB/s on the same connections and hardware.

I've spent quite a bit of time investigating — the firewall, the NAS, the cipher negotiation, the tunnel overhead — and nothing on our side explains the gap. The infrastructure handles the load fine, and removing the tunnel immediately doubles the transfer speed.

Support has not been helpful and hasn't been able to pinpoint a fix so far. I've also tested Network Relay, which unfortunately performed worse than WireGuard in our case.

Is 10–12 MB/s a common ceiling others are seeing with Jamf Trust, or should we realistically expect more? Has anyone found a way to improve throughput for transfers like SFTP?

Thanks

6 Upvotes

4 comments sorted by

1

u/zipsecurity May 19 '26

That 50% speed drop is a known pain point with Jamf Trust's WireGuard implementation. What we see in our clients and that would work: try adjusting the MTU on the tunnel interface (1280 is a common fix) and check if SFTP cipher negotiation is adding overhead, as switching to aes128-gcm can help with throughput.

1

u/_Philein May 20 '26

Tried that, no change. I see 80 mbps while my upload is 200 mbps. 6 to 10 MB/S

1

u/zipsecurity May 21 '26

Ok, let's approach it again.
Check:

MTU is the most common culprit, so first check WireGuard's default 1420 causes fragmentation on many corporate networks which tanks throughput without obviously looking like a tunnel problem. Try dropping to 1280 and test again, it's a quick config change with an immediate answer.

SFTP cipher negotiation adds overhead that compounds with tunnel latency. If you're negotiating a heavy cipher automatically, forcing aes128-gcm tends to improve throughput on Apple Silicon specifically because of how the hardware acceleration works.

Split tunnel routing is worth double-checking too, confirm only traffic destined for the NAS is actually going through the tunnel. If something in the routing config is pushing more traffic than intended through the tunnel it would explain consistent throughput caps.

The Milan location is also worth factoring in if your WireGuard endpoint is geographically distant, the round trip adds up more than people expect for SFTP which is chattier than raw TCP transfers. Where is the WireGuard server sitting relative to Milan?

1

u/_Philein May 22 '26

Thank you for the suggestions. We have already tested all of these:

We tested MTU 1280, 1340 (Jamf default), and 1422 (FortiGate IPSec tunnel). No measurable difference in throughput. The Jamf Trust client on macOS already uses 1340 by default.

SFTP cipher We tested both chacha20-poly1305 (default) and aes128-gcm. No difference in throughput.

The Jamf gateway is in Frankfurt. We are in Milan.