Gotcha — if both LANs test at
~960 Mbps locally and both internet connections test at
~500/500, then I agree: this is
not a bad Ethernet link.
At this point, your
iperf3 result around
94 Mbps through the VPN means the bottleneck is almost certainly in the
site-to-site VPN path, not the PCs, switches, LAN cabling, or raw ISP speed.
What that leaves
The likely causes are now:
Code:
1. Synology IPsec/VPN processing limit
2. One router CPU/core maxing out during encryption
3. MTU/MSS fragmentation
4. Remaining SRM packet inspection/QoS/traffic-control processing
5. IPsec encryption settings too heavy
6. ISP routing/packet loss between the two public IPs
Your earlier CPU number is the biggest clue:
Code:
Your router CPU: 75–90%
Other router CPU: ~45%
That strongly suggests the busier Synology router is the limiting side.
Important detail about CPU usage
Even if SRM shows
75–90% and not 100%, VPN may still be CPU-limited.
Why? Because VPN encryption can hit one core/thread heavily while the total CPU graph averages across multiple cores. So the router may be effectively maxed for VPN even if the overall CPU meter is not pinned at 100%.
Your test results now mean this
Code:
LAN test: ~960 Mbps = local network is fine
Speedtest.net: ~500 Mbps = internet service is fine
VPN iperf3: ~94 Mbps = VPN tunnel path is the bottleneck
So the question is no longer “why is SMB slow?” It is:
Why is Synology site-to-site VPN only pushing ~90–220 Mbps?
Try lighter VPN settings
For testing, use the simplest reasonably secure settings.
On the Synology site-to-site tunnel, try:
Code:
IKE version: IKEv2
Encryption: AES-128
Authentication: SHA-256
PFS: Off temporarily
DH group: avoid very high groups for testing
If you are currently using something like:
Code:
AES-256
SHA-512
High DH group
PFS enabled
that can cost speed on router hardware.
Security note: I am not saying to leave everything weakened forever. This is to determine whether encryption overhead is the bottleneck.
MTU is still suspicious
You said:
Code:
ping REMOTE_PC_IP -f -l 1360 works
anything above 1360 fails
That means the effective MTU is around:
1360 + 28 = 1388
That is low, and if TCP MSS is not being clamped properly, performance can bounce around exactly like you are seeing.
Ask Synology support specifically about:
Code:
VPN MTU
TCP MSS clamping
IPsec tunnel fragmentation
Suggested values to test if SRM exposes them:
or:
Reboot after disabling Synology security features
Since disabling
Safe Access and
Threat Prevention helped a bit, do a clean test like this:
- Disable Safe Access on both routers.
- Disable Threat Prevention on both routers.
- Disable Traffic Control/QoS/bandwidth control if enabled.
- Disable heavy traffic logging temporarily.
- Reboot both routers.
- Run
iperf3 -P 8 again.
- Watch CPU on both routers during the test.
Undo: Re-enable protections after testing if you need them.
Run these exact iperf3 tests
Please run and compare these three:
.\iperf3.exe -c REMOTE_PC_IP
.\iperf3.exe -c REMOTE_PC_IP -P 8
.\iperf3.exe -c REMOTE_PC_IP -P 8 -R
The
-R result is very important.
If you get something like:
Code:
Normal: 94 Mbps
Reverse: 220 Mbps
then the bottleneck is direction-specific. Usually that means one router is slower at
encrypting outbound or
decrypting inbound, or one ISP path direction has loss/jitter.
Optional but very useful test: iperf3 outside the VPN
If you are comfortable doing this temporarily, test raw WAN-to-WAN performance without the VPN.
1. On one PC, run:
.\iperf3.exe -s
2. Temporarily port-forward TCP 5201 on that site’s router to that PC.
3. From the other site, run:
.\iperf3.exe -c PUBLIC_IP
4. Then remove the port forward immediately after testing.
Warning: Do not leave port
5201 open permanently. This is only a short diagnostic test.
If WAN
iperf3 gets near
400–500 Mbps but VPN
iperf3 stays around
90–220 Mbps, that proves the issue is the
VPN/router processing, not the ISP path.
My current conclusion
Based on everything you have posted:
Code:
Local LAN = good
Internet speed = good
Multiple PCs = same result
OpenSpeedTest = asymmetric
iperf3 through VPN = ~94 Mbps
Router CPU = 75–90%
MTU above 1360 = fails
My best guess is:
The Synology router on your end is hitting a practical IPsec processing/MTU limit.
It may not be a “bug” exactly — it may just be the real-world limit of that VPN mode/settings/features on that hardware.
What I would send Synology support
Send them this:
Code:
Both sites test 500/500 on speedtest.net.
Both local LANs test around 960 Mbps.
Site-to-site VPN iperf3 -P 8 gives about 94 Mbps one direction.
OpenSpeedTest gives about 90 Mbps one direction and 220 Mbps the other.
Largest successful no-fragment ping payload is 1360.
Anything above ping -f -l 1360 fails.
Home router CPU reaches 75–90% during VPN transfer.
Other router is around 45%.
Safe Access and Threat Prevention disabled improved speed slightly.
Testing is wired Ethernet only.
That gives them the right evidence. The key phrase to ask them is:
“Is IPsec hardware acceleration working for this site-to-site tunnel, and is MSS clamping being applied correctly?”
