fastest VPN method?

[droogiee]

i currently have 500 up/down and home and work. what is the best way to achieve fastest transfer speeds between the two networks. my sstp limits my 500mbps to a grueling 2.2 MB/s.. when i transfer within my own networks, i am getting 48-50 MB/s
i have use hamachi or SSTP, sstp was giving me 6 MB/s
any way to have it match my inter lan speeds?

 

[ChatGPT]

Hi droogiee — with 500 Mbps up/down at both ends, your theoretical max is about 62.5 MB/s. After VPN/protocol overhead, a good real-world target is roughly 40–55 MB/s if latency is reasonable and the hardware can encrypt fast enough.
Your current 2.2 MB/s–6 MB/s is far below what should be possible.

Best option: WireGuard site-to-site VPN​

For fastest transfers between two networks, I’d use:

1. WireGuard site-to-site VPN if you control both ends.
2. Tailscale or ZeroTier if you want easier setup, but make sure the connection is direct and not relayed.
3. IPsec/IKEv2 if your routers/firewalls have good hardware acceleration.
4. Avoid SSTP and Hamachi for high-speed LAN-to-LAN file transfer.

SSTP is often slow because it runs over TCP/443. If you then copy files over SMB, you can end up with TCP-over-TCP behavior, which performs badly over latency or packet loss.

What I would do​

1. Check raw speed first with iperf3​

Before blaming file sharing, test the VPN pipe itself.
On one side:
iperf3 -s
On the other side:
iperf3 -c VPN_IP_ADDRESS
For multiple streams:
iperf3 -c VPN_IP_ADDRESS -P 8
Expected result on a good 500/500 link: somewhere around 300–500 Mbps, depending on latency, router CPU, and VPN overhead.

2. Use WireGuard instead of SSTP​

Recommended layout:
Home LAN <--> Router/Firewall/Server running WireGuard <--> Internet <--> Router/Firewall/Server running WireGuard <--> Work LAN
Good platforms for this:

• OPNsense/pfSense
• MikroTik
• Ubiquiti/UniFi Gateway
• Linux mini PC
• Windows machine running WireGuard
• GL.iNet router

If possible, run WireGuard on a router/firewall or small dedicated box rather than a low-power NAS or old PC.

3. Watch the CPU bottleneck​

VPN speed depends heavily on encryption performance.
Check CPU usage during a transfer:

1. Open Task Manager.
2. Start a large file transfer.
3. Check CPU usage on both VPN endpoints.
4. If one endpoint is near 100% CPU, that device is your bottleneck.

If using a router, many consumer routers cannot route/encrypt 500 Mbps over VPN even though their WAN port is gigabit.

4. SMB may still be slower over VPN​

Even with a fast VPN, Windows file sharing/SMB can be limited by latency.
For Windows-to-Windows file copies, try:
robocopy "\\remote-server\share" "D:\LocalFolder" /E /MT:16 /R:2 /W:2
Or reverse direction:
robocopy "D:\LocalFolder" "\\remote-server\share" /E /MT:16 /R:2 /W:2
/MT:16 uses multiple threads and often helps a lot over VPN.
For very large transfers, also consider:

• SFTP
• rsync
• Syncthing
• Resilio Sync
• OneDrive/SharePoint/Nextcloud-style sync

These can outperform SMB across WAN links.

5. Check MTU/MSS​

VPNs add overhead. Bad MTU settings can cause terrible speed.
For WireGuard, common MTU values are:

1420
1380
1360

If speeds are poor or transfers stall, try lowering WireGuard MTU to 1380 on both ends.

6. Make sure you are not using a relay​

If using Tailscale, ZeroTier, or Hamachi, check whether the traffic is direct.
A relayed connection can be much slower than your actual 500/500 connection.
For Tailscale, run:
tailscale status
You want to see a direct connection, not relay/DERP.

Bottom line​

To get close to your LAN-like 48–50 MB/s, use:
WireGuard + direct site-to-site routing + decent VPN hardware + robocopy /MT
Realistically, I’d expect:

Good setup:     35–55 MB/s
Okay setup:     15–30 MB/s
Bad SSTP setup: 2–8 MB/s

Also, since one side is your work network, make sure you have permission before creating a site-to-site VPN. You don’t want to accidentally bypass company firewall/security policy.

 

[droogiee]

i have a syhnology RT6600ax, that does have site to site, but no preset templates.. only manual.. can i use wireguard with the my router?
with hamachi i have a direct, non-relayed connection.. but still bad huh?

 

[ChatGPT]

Hi droogiee — short answer: the RT6600ax does not appear to support WireGuard natively in SRM/VPN Plus. Synology lists VPN Plus support for SSTP, OpenVPN, L2TP over IPsec, PPTP, plus Site-to-Site VPN using IPsec tunnels, but not WireGuard. Synology also states that the RT6600ax can reach up to 800 Mbps site-to-site throughput only between two RT6600ax units, so the built-in Site-to-Site VPN/IPsec is probably your best router-native option.

Can you use WireGuard with the RT6600ax?​

Not directly on the router through SRM, at least not as a supported built-in VPN option.
Your options are:

1. Use Synology VPN Plus Site-to-Site/IPsec on the RT6600ax.
2. Put a small WireGuard box behind the RT6600ax.
3. Use Tailscale/ZeroTier/WireGuard on the actual PCs/NAS devices instead of the router.
4. Replace/add a router/firewall that supports WireGuard, such as OPNsense, pfSense, MikroTik, UniFi, GL.iNet, OpenWrt, etc.

Best thing to try first: Synology Site-to-Site VPN​

Since you already have the RT6600ax, I would try its built-in Site-to-Site VPN before buying anything.
Synology’s setup is manual unless both ends are Synology routers. Their own guide says that with two Synology routers, you can configure one side, export the profile, and import it on the other. If the other side is a non-Synology IPsec device, you must manually match the settings.

Suggested starting settings​

1. Use different LAN subnets at home and work.

Example:

Home: 192.168.10.0/24
Work: 192.168.20.0/24

1. Use IKEv2 if available.
2. Use AES-128 or AES-256.
3. Use SHA-256.
4. Use a strong pre-shared key.
5. Open/allow IPsec ports if needed:

UDP 500
UDP 4500
ESP/IP protocol 50, if applicable

1. Disable extra-heavy options temporarily while testing, such as PFS, then re-enable once you know the base speed.

Important: Only do this on the work network if you have permission. A site-to-site VPN can bypass normal security boundaries if configured wrong.

About Hamachi being direct but still slow​

Yes — Hamachi can be direct/non-relayed and still perform badly.
Reasons include:

1. Hamachi has its own encryption/overlay overhead.
2. It may not handle high-throughput SMB transfers well.
3. MTU issues can kill performance.
4. Windows file sharing over WAN/VPN is latency-sensitive.
5. A single SMB copy may not fill a 500 Mbps pipe.
6. The endpoint CPU may be limiting encryption speed.

So “direct” only means it is not using a relay. It does not mean it will perform like a proper site-to-site tunnel.

Test the tunnel before testing file copies​

Use iperf3 so you know whether the VPN itself is fast.

On one side​

iperf3 -s

On the other side​

iperf3 -c REMOTE_VPN_IP

Multi-stream test​

iperf3 -c REMOTE_VPN_IP -P 8
If iperf3 is fast but file copies are slow, the problem is likely SMB/file transfer behavior, not the VPN.

For Windows file copies, use robocopy​

Try this instead of drag-and-drop Explorer copies:
robocopy "\\remote-server\share" "D:\LocalFolder" /E /MT:16 /R:2 /W:2
Or the other direction:
robocopy "D:\LocalFolder" "\\remote-server\share" /E /MT:16 /R:2 /W:2
/MT:16 often helps a lot across VPN links.

What speed should you expect?​

Your 500 Mbps internet equals about:
500 Mbps ÷ 8 = 62.5 MB/s theoretical max
Realistically:

Excellent VPN/IPsec/WireGuard: 40–55 MB/s
Good setup:                   25–40 MB/s
Mediocre setup:               10–25 MB/s
SSTP/Hamachi-type result:      2–8 MB/s

Since your local LAN copy is 48–50 MB/s, matching that over the internet is possible only if the VPN, routing, CPU, MTU, and SMB behavior are all good.

My recommendation​

Try this order:

1. Use RT6600ax Site-to-Site VPN/IPsec first.
2. Test with iperf3.
3. Test file copy with robocopy /MT:16.
4. If speeds are still poor, add a small WireGuard appliance/mini PC behind each router.
5. Avoid SSTP and Hamachi for bulk file transfers if speed is the goal.

If you tell me what device/router is on the work side, and whether both networks use different subnets, I can suggest the exact site-to-site settings to try.

 

[droogiee]

they are both synology routers

 

[ChatGPT]

Perfect — if both ends are Synology routers, then I would not bother with Hamachi/SSTP for this. Use Synology VPN Plus Site-to-Site VPN between the two routers.
Synology’s own Site-to-Site setup supports exporting the profile from one Synology router and importing it into the other, so you should not need to manually mirror every setting on both sides. Synology also states the RT6600ax can reach up to 800 Mbps site-to-site throughput when the tunnel is between two RT6600ax units, so this is the best native path for your hardware.

Important first check​

Make sure home and work are on different LAN subnets.
Example good setup:

Home LAN: 192.168.10.0/24
Work LAN: 192.168.20.0/24

Bad setup:

Home LAN: 192.168.1.0/24
Work LAN: 192.168.1.0/24

If both sides use the same subnet, routing over site-to-site VPN will be messy or broken. Change one side first if needed.

Recommended setup: Synology-to-Synology Site-to-Site VPN​

1. On router A​

1. Log into SRM.
2. Open VPN Plus Server.
3. Go to Site-to-Site VPN.
4. Activate the Site-to-Site VPN license if prompted.
5. Click Add.
6. Choose Manually.
7. Configure the local and remote networks.
8. Use IKEv2 if available.
9. Use AES-128 or AES-256.
10. Use SHA-256.
11. Save the profile.
12. Click Export Profile.

2. On router B​

1. Log into SRM on the second Synology router.
2. Open VPN Plus Server.
3. Go to Site-to-Site VPN.
4. Click Add.
5. Choose Import Profile.
6. Import the profile exported from router A.
7. Save and connect.

That export/import method is the key advantage of having Synology on both ends.

Ports to allow​

If either router is behind another modem/router/firewall, make sure these are allowed/forwarded to the Synology router:

UDP 500
UDP 4500

If you have a true bridge-mode modem and the Synology router has the public WAN IP, you may not need manual port forwarding.

Watch out for CGNAT​

If one side does not have a real public WAN IP, site-to-site VPN may fail or behave poorly.
Check this:

1. In SRM, look at the router’s WAN IP.
2. Compare it to what a “what is my IP” website shows.
3. If they are different, you may be behind CGNAT or double NAT.

If CGNAT is involved, you may need:

Static public IP
Bridge mode modem
Port forwarding from upstream router
Tailscale/ZeroTier fallback

Test speed correctly​

After the tunnel connects, test with iperf3 before testing file copies.

On one PC at work​

iperf3 -s

On one PC at home​

iperf3 -c WORK_PC_IP

Better multi-stream test​

iperf3 -c WORK_PC_IP -P 8
If that shows hundreds of Mbps, the VPN is fine and SMB/file copy is the bottleneck.

For file transfers, use robocopy​

Explorer copy over VPN is often slower. Try:
robocopy "\\work-pc\share" "D:\LocalCopy" /E /MT:16 /R:2 /W:2
Or the other direction:
robocopy "D:\LocalFolder" "\\work-pc\share" /E /MT:16 /R:2 /W:2

What speed you should expect​

With 500/500 at both sites:

Theoretical max: 62.5 MB/s
Good real-world VPN transfer: 35–55 MB/s
Decent result: 25–40 MB/s
Poor result: under 10 MB/s

So yes, if both routers are RT6600ax or comparable Synology routers, you have a realistic chance of getting close to your 48–50 MB/s LAN copy speeds.

My advice​

Use this order:

1. Set up Synology Site-to-Site VPN.
2. Confirm both LANs use different subnets.
3. Use export profile on one router and import profile on the other.
4. Test with iperf3 -P 8.
5. Test file copy with robocopy /MT:16.
6. Drop Hamachi/SSTP if site-to-site performs well.

Also, since one side is work, make sure you have permission before linking the networks. A site-to-site VPN effectively joins both LANs, so firewall rules matter.

 

[droogiee]

ok, got site to site up and running, but is not translating names, only IP addresses.. i see not settings anywhere

 

[ChatGPT]

Nice — if IP works but names do not, the VPN tunnel itself is fine. What’s missing is name resolution/DNS across the two subnets.
This is normal with site-to-site VPNs. The VPN routes traffic, but it does not automatically make Windows hostnames, SMB discovery, or NetBIOS names work across sites.

Why this happens​

Windows short names like:

NAS
OFFICE-PC
SERVER

often rely on local broadcast/NetBIOS/mDNS/LLMNR discovery. Those broadcasts usually do not cross routed VPN subnets.
So this may work locally:
\\NAS\Share
but across the VPN you may need:
\\192.168.20.50\Share
or proper DNS:
\\nas.work.lan\Share

Best fix: use DNS names, not broadcast names​

You want each site to have a DNS domain/suffix, for example:

Home: home.lan
Work: work.lan

Then devices should resolve like:

nas.home.lan
server.work.lan
pc01.work.lan

Quick test first​

On a Windows PC at home, run:
nslookup work-pc-name
Then try the full name if you have one:
nslookup work-pc-name.work.lan
Also check which DNS server your PC is using:
ipconfig /all
Look for:

DNS Servers
Connection-specific DNS Suffix

If your DNS server is something like Google/Cloudflare:

8.8.8.8
1.1.1.1

then it will never know your private LAN names.

Option 1: simple workaround using hosts file​

For a few important machines, this is the fastest fix.

1. Open Notepad as Administrator​

1. Click Start.
2. Type Notepad.
3. Right-click Notepad.
4. Choose Run as administrator.

2. Open the hosts file​

Open:
C:\Windows\System32\drivers\etc\hosts
You may need to change the file filter from Text Documents to All Files.

3. Add entries​

Example:

192.168.20.10    work-nas
192.168.20.20    work-server
192.168.20.30    office-pc

Then save.

4. Flush DNS cache​

ipconfig /flushdns
Now try:
\\work-nas\share
This is not elegant, but it works immediately.

Option 2: better fix using local DNS records​

If your Synology router lets you create local DNS/static host records, add the remote machines there.
Example on the home router DNS:

work-nas.work.lan      192.168.20.10
work-server.work.lan   192.168.20.20
office-pc.work.lan     192.168.20.30

Example on the work router DNS:

home-nas.home.lan      192.168.10.10
home-pc.home.lan       192.168.10.20

Then make sure DHCP clients use the Synology router as DNS.
On each Synology router, check the LAN/DHCP settings and make sure clients receive the router IP as DNS, for example:

Home router/DNS: 192.168.10.1
Work router/DNS: 192.168.20.1

Then renew DNS on Windows:

ipconfig /release
ipconfig /renew
ipconfig /flushdns

Option 3: best fix for many devices​

If you have many machines, use a real DNS service such as:

Windows Server DNS
Synology DNS Server package, if available on your model
Pi-hole
AdGuard Home
Technitium DNS
Unbound/CoreDNS

Then configure either:

home.lan -> resolved by home DNS
work.lan -> resolved by work DNS

Ideally with conditional forwarding, if your DNS software supports it.
Example concept:

Home DNS forwards work.lan queries to 192.168.20.1
Work DNS forwards home.lan queries to 192.168.10.1

That way:
\\server.work.lan\share
works from home, and:
\\nas.home.lan\share
works from work.

Do not rely on Windows Network browsing​

Even after DNS is fixed, the Windows Network view may still not show remote computers. That is normal across routed VPNs.
Use direct paths instead:
\\192.168.20.10\Share
or better:
\\work-nas.work.lan\Share
You can also map the drive:
net use Z: \\work-nas.work.lan\Share /persistent:yes

My recommendation​

For your setup, I would do this:

1. Give important devices static DHCP reservations on each Synology router.
2. Use different DNS suffixes, such as home.lan and work.lan.
3. Add DNS/static host records for NAS/server/PC names.
4. Use full names like nas.work.lan, not just nas.
5. For Windows file shares, map drives using the FQDN.

If you tell me your two subnets, for example 192.168.x.x at home and work, and which devices you need by name, I can show you exactly what DNS/hosts entries to create.

 

[droogiee]

also, unable to access windows shares via site-to-site via windows SMB shares.. i can via hamachi, or SSTP,

 

[ChatGPT]

Yep — that points to a routing/firewall/profile issue, not the VPN tunnel itself.
Hamachi/SSTP works because Windows sees those as a local VPN adapter/client connection. With Synology site-to-site, the SMB request comes from a different LAN subnet, and Windows Firewall often blocks File Sharing from anything outside the “local subnet.”

First: test SMB port 445​

On a PC at home, test a work Windows share host by IP:
Test-NetConnection 192.168.20.X -Port 445
Replace 192.168.20.X with the remote Windows PC/server IP.
Expected good result:
TcpTestSucceeded : True
If it says False, SMB is being blocked by either:

Windows Firewall
Synology firewall/rules
Wrong network profile
ISP/router policy

Most likely fix: Windows Firewall SMB scope​

On the Windows machine hosting the share, allow SMB from the remote site subnet.
Example:

Home LAN: 192.168.10.0/24
Work LAN: 192.168.20.0/24

If the work PC has the share and home needs access, run this on the work PC as Administrator:
New-NetFirewallRule -DisplayName "Allow SMB from Home site-to-site VPN" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 -RemoteAddress 192.168.10.0/24 -Profile Private
If the home PC also shares files back to work, run this on the home PC:
New-NetFirewallRule -DisplayName "Allow SMB from Work site-to-site VPN" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 -RemoteAddress 192.168.20.0/24 -Profile Private
Do not open SMB to Any or to the internet. Limit it only to the opposite VPN subnet.

Check the Windows network profile​

On the Windows share host, run:
Get-NetConnectionProfile
If the active network says Public, change it to Private:
Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private
If your adapter name is different, use the exact InterfaceAlias shown by Get-NetConnectionProfile.

Enable File and Printer Sharing​

On the Windows share host, run as Administrator:
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Private
Then test again:
Test-NetConnection 192.168.20.X -Port 445

Access by IP first​

Do not test with names yet. Try:
\\192.168.20.X\ShareName
If that works, then SMB is fixed and only DNS/name resolution remains.
If prompted for credentials, use:
REMOTEPCNAME\username
or:
192.168.20.X\username
For a Microsoft account login, sometimes this format is needed:
MicrosoftAccount\[email][email protected][/email]

Check Synology firewall rules too​

If Windows Firewall looks correct but port 445 still fails, check both Synology routers.

• Log into SRM.
• Go to Network Center.
• Check Security / Firewall rules.
• Allow traffic from the remote subnet to the local LAN.

Example allow rule:

Source: 192.168.10.0/24
Destination: 192.168.20.0/24
Port: TCP 445
Action: Allow

And the reverse if needed:

Source: 192.168.20.0/24
Destination: 192.168.10.0/24
Port: TCP 445
Action: Allow

For basic file sharing by direct IP, TCP 445 is the important one.

Optional legacy ports​

Only add these if you specifically need old NetBIOS browsing/name behavior:

TCP 139
UDP 137
UDP 138

For modern Windows SMB using \\IP\Share, you usually only need:
TCP 445

Quick diagnosis summary​

If this works:
ping 192.168.20.X
But this fails:
Test-NetConnection 192.168.20.X -Port 445
Then it is almost certainly a firewall rule/scope problem.

My bet​

Your Windows share machines are probably only allowing File and Printer Sharing from the local subnet, not from the opposite site-to-site subnet.
Add the custom TCP 445 rule for the remote subnet, then test with:
\\remote-ip-address\share
Once that works, we can fix the name resolution separately with DNS/hosts entries.

 

[droogiee]

i have all important pcs static. i am unable to access the computer with the static ip address..

 

[ChatGPT]

Got it — if the PC has a static IP and you cannot reach it across the Synology site-to-site tunnel, the most common cause is:
The static PC does not have the Synology router set as its default gateway, or Windows Firewall is blocking traffic from the remote subnet.
With site-to-site VPN, the remote PC must know how to send replies back to the other network.

Example​

If your work PC is:

Work PC: 192.168.20.50
Work router: 192.168.20.1
Home LAN: 192.168.10.0/24

The work PC must have:

IP address:      192.168.20.50
Subnet mask:     255.255.255.0
Default gateway: 192.168.20.1
DNS server:      192.168.20.1 or your preferred DNS

If the default gateway is blank, wrong, or pointing to another router, site-to-site access will fail.

Step 1: Check the static PC network config​

On the PC you cannot access, open PowerShell or Command Prompt and run:
ipconfig /all
Check these lines:

IPv4 Address
Subnet Mask
Default Gateway
DNS Servers

Make sure Default Gateway is the local Synology router’s LAN IP.

Step 2: Test from the remote site​

From a PC on the opposite site, run:
ping STATIC_PC_IP
Then test SMB:
Test-NetConnection STATIC_PC_IP -Port 445
Example:
Test-NetConnection 192.168.20.50 -Port 445
Results mean:

Ping works, port 445 fails = Windows Firewall/SMB issue
Ping fails, port 445 fails = routing/gateway/firewall issue
Port 445 succeeds = SMB is reachable; issue is credentials/share path/name resolution

Step 3: Check Windows Firewall on the static PC​

On the PC hosting the share, run PowerShell as Administrator.
If the remote site is 192.168.10.0/24, run:
New-NetFirewallRule -DisplayName "Allow SMB from remote site" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 -RemoteAddress 192.168.10.0/24 -Profile Any
Then test again:
Test-NetConnection STATIC_PC_IP -Port 445
Do not open SMB to the entire internet. Only allow the other private site subnet.

Step 4: Check the Windows network profile​

On the static PC:
Get-NetConnectionProfile
If it says Public, change it to Private:
Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private
If your adapter is not named Ethernet, use the name shown under InterfaceAlias.
Then enable File and Printer Sharing:
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Private

Step 5: Try direct SMB by IP​

From the other site, test:
\\STATIC_PC_IP\ShareName
Example:
\\192.168.20.50\Shared
Do not test by computer name yet. Name resolution is a separate issue.

Step 6: Check Synology firewall rules​

On both Synology routers, make sure firewall rules allow traffic between the two LAN subnets.
Example:

Home LAN: 192.168.10.0/24
Work LAN: 192.168.20.0/24

Allow:

192.168.10.0/24 -> 192.168.20.0/24
192.168.20.0/24 -> 192.168.10.0/24

For SMB specifically:
TCP 445
For testing, you can temporarily allow all traffic between the two private subnets. After confirming it works, tighten it down if desired.

My strongest suspicion​

Since you specifically mentioned the PC is using a static IP, check this first:
Default Gateway = local Synology router IP
A static IP with no/wrong gateway will work locally on its own LAN, but will fail from the site-to-site VPN because it cannot route replies back to the other subnet.
If you post the two LAN subnets and the static PC’s ipconfig /all output with public info removed, I can tell you exactly what is wrong.

 

[droogiee]

finally got the site to site working between the two synology routers...
but speeds are still slow. i have contacted tech support, and they will be looking into this.. but in the meantime i am curious as to what could be causing this.
tried from multiple different PCs on either end, to different pcs on the other end. i have disabled SAFE ACCESS and THREAT PROTECTION on both sides.. that helped slightly.. now maxed out at around 80 mbps
again, i have 500 up and down both at work and at home.
what gives?

 

[ChatGPT]

Glad you got the tunnel up, droogiee. If you are now maxing around 80 Mbps, that is about:
80 Mbps ÷ 8 = 10 MB/s
So yes, that is still far below what a clean 500/500 site-to-site link should be capable of.

Most likely causes​

The big suspects are:

1. Synology router CPU/encryption bottleneck
2. IPsec settings causing slower encryption
3. MTU/MSS fragmentation
4. SMB/file copy inefficiency over routed VPN
5. Traffic inspection/QoS/firewall processing still active
6. ISP routing/latency/packet loss between the two sites
7. One side not actually getting full 500 Mbps upload at the time of testing
8. Testing over Wi-Fi instead of wired Ethernet

Since you tested multiple PCs both ways and disabling Safe Access / Threat Prevention helped slightly, that strongly suggests the routers are doing extra packet processing and/or hitting a processing limit.

First: separate VPN speed from file-copy speed​

Do not use SMB copy speed as the first benchmark. Test the tunnel with iperf3.

1. On a wired PC at work​

iperf3 -s

2. On a wired PC at home​

iperf3 -c WORK_PC_IP

3. Test with multiple streams​

iperf3 -c WORK_PC_IP -P 8

4. Test reverse direction​

iperf3 -c WORK_PC_IP -P 8 -R
What the results mean:

iperf3 around 80 Mbps = VPN/router/ISP/MTU bottleneck
iperf3 much faster but SMB slow = Windows file sharing/SMB issue
one direction fast, other slow = upload/routing/ISP/asymmetric issue
single stream slow, multi-stream faster = latency/TCP window issue

Check router CPU during the test​

While running iperf3, watch both Synology routers.

1. Open SRM on both routers​

Go to:
SRM > Resource Monitor

2. Run the VPN speed test​

Use:
iperf3 -c REMOTE_PC_IP -P 8

3. Watch CPU usage​

If either router hits high CPU during the VPN test, that router is the bottleneck.
This is very possible. VPN throughput is not just “internet speed.” The router has to encrypt/decrypt every packet.

Check your Site-to-Site encryption settings​

For testing only, use a lighter-but-still-reasonable config.
Try:

IKE version: IKEv2
Encryption: AES-128 or AES-256
Authentication: SHA-256
PFS: disabled temporarily for testing

Security note: Disabling PFS is only for speed testing. If it makes a big difference, you found part of the bottleneck. You can then decide whether the speed gain is worth the security tradeoff.

MTU/MSS may be killing throughput​

Bad MTU can absolutely cap VPN speeds.

1. Test ping with no fragmentation​

From one side to the other:
ping REMOTE_PC_IP -f -l 1472
If that fails, lower the number:

ping REMOTE_PC_IP -f -l 1400
ping REMOTE_PC_IP -f -l 1360
ping REMOTE_PC_IP -f -l 1320

The largest value that works helps estimate the usable MTU.

2. Try lowering VPN MTU/MSS if Synology allows it​

Common working values:

MTU: 1400
MTU: 1380
MTU: 1360

If there is an MSS clamping option, try around:
MSS: 1360
If MTU is the problem, you may see a large jump immediately.

Make sure the test PCs are wired​

For accurate testing:

1. Use Ethernet on both ends.
2. Confirm link speed is 1.0 Gbps.
3. Do not test over Wi-Fi.
4. Avoid testing to/from a sleeping NAS, old laptop, USB Ethernet adapter, or powerline adapter.

On Windows, check link speed:
Get-NetAdapter | Select Name, Status, LinkSpeed

Check for remaining Synology features that can slow routing​

Even with Safe Access and Threat Prevention disabled, check these too:

Traffic Control
QoS / bandwidth control
Firewall logging
Smart WAN policy routing
Application Layer Gateway features
DoH/parental filtering
IDS/IPS remnants
Device-specific bandwidth limits
VPN logging/debug mode

For testing, temporarily simplify both routers as much as possible.
Undo: Re-enable the protections after testing once you know which feature is affecting throughput.

SMB may still be slower than the VPN​

If iperf3 gives you decent numbers but file copies are still poor, use robocopy with multithreading instead of Explorer drag-and-drop.
Example:
robocopy "\\REMOTE_PC_IP\Share" "D:\TestCopy" /E /MT:16 /R:2 /W:2
Or:
robocopy "D:\TestFolder" "\\REMOTE_PC_IP\Share" /E /MT:16 /R:2 /W:2
Also test with one large file, not thousands of tiny files. Tiny files are much slower over VPN.

Test the raw internet path​

Run speed tests at both sites using wired PCs, but also test latency and packet loss between the two public IPs if possible.
From one side:
ping OTHER_SITE_PUBLIC_IP -n 50
Also:
pathping OTHER_SITE_PUBLIC_IP
High latency, jitter, or packet loss can destroy VPN throughput even when both sites show “500/500” to a nearby speed test server.

What speed should be realistic?​

With 500/500 at both ends:

Theoretical max: 500 Mbps / 62.5 MB/s
Good site-to-site VPN: 250–450 Mbps
Excellent setup: 400+ Mbps
Current result: 80 Mbps / 10 MB/s

So your result is not normal if both routers are healthy, wired, and configured well.

My bet​

Given that disabling Safe Access and Threat Protection helped, I suspect one of these:

Router CPU/packet-processing limit
MTU/MSS issue
Remaining SRM traffic inspection/QoS/firewall processing
IPsec encryption setting causing poor acceleration

What to send Synology support​

Send them these exact test results:

Router model at home:
Router model at work:
SRM version on both:
VPN Plus Server version on both:
Site-to-site encryption settings:
Home LAN subnet:
Work LAN subnet:
iperf3 single stream result:
iperf3 -P 8 result:
iperf3 -P 8 -R result:
CPU usage on both routers during test:
MTU test results:
Whether Safe Access/Threat Prevention are disabled:
Whether clients are wired or Wi-Fi:

If you post your iperf3 results here, especially single-stream, -P 8, and reverse -R, I can help narrow down whether this is router CPU, MTU, SMB, or ISP path.

 

[droogiee]

any thing above ping REMOTE_PC_IP -f -l 1360 failed
these are ethernet only.
cpu is bouncing from 75-90 on my end, 45% on the other
speeds are bouncing alot
5 mb/s to 20 mb/s
average is 9 mb/s now
haven't done the iperf3 test.. is that with powershell?

 

[ChatGPT]

Yes — iperf3 is a command-line tool you run from PowerShell or Command Prompt, but it is not built into Windows. You download it, run it on one PC as the server, and run it on another PC as the client.
Based on what you just posted, two things stand out:

MTU test: anything above 1360 fails
Your router CPU: 75–90%
Other router CPU: 45%
Speed: 5–20 MB/s, average ~9 MB/s

That strongly suggests your end is the bottleneck, either from VPN encryption/processing, MTU/MSS fragmentation, or some remaining Synology packet-processing feature.

About your speed​

Your average:
9 MB/s × 8 = about 72 Mbps
Your high end:
20 MB/s × 8 = about 160 Mbps
So the tunnel is working, but it is unstable and nowhere near your 500 Mbps line.

MTU result matters​

If this is the largest successful ping:
ping REMOTE_PC_IP -f -l 1360
Then your usable packet size is roughly:
1360 + 28 = 1388 MTU
That is not crazy for VPN, but it means larger packets are likely fragmenting or failing. If Synology has any MTU/MSS clamping option for the site-to-site VPN or WAN interface, try something around:

MTU: 1380
MSS: 1340 or 1360

If there is no exposed setting, give that result to Synology support. It is useful.

Your CPU usage is a big clue​

If your router is bouncing between 75–90% during transfers, that is probably the ceiling. VPN speed depends on how fast the router can encrypt/decrypt traffic, not just the ISP speed.
Also, if Safe Access and Threat Prevention helped when disabled, I would do this test:

1. Temporarily disable extra processing​

Check both routers for:

Safe Access
Threat Prevention
Traffic Control
QoS / bandwidth control
Traffic monitoring
Firewall logging
Device bandwidth limits
VPN logging/debug options

2. Reboot both routers after disabling​

This matters because some packet inspection services do not fully clear until reboot.

3. Test again​

Use the same transfer or, better, iperf3.
Undo: Re-enable the security features after testing if you need them.

How to run iperf3 on Windows​

1. Download iperf3​

1. On both test PCs, download a Windows build of iperf3.
2. Extract it somewhere simple, for example:

C:\iperf3

2. Open PowerShell on the remote-side PC​

Go to the folder:
cd C:\iperf3
Start server mode:
.\iperf3.exe -s
If Windows Firewall prompts, allow it on Private networks.

3. Open PowerShell on the other-side PC​

Go to the folder:
cd C:\iperf3
Run a basic test:
.\iperf3.exe -c REMOTE_PC_IP
Example:
.\iperf3.exe -c 192.168.20.50

4. Run a multi-stream test​

.\iperf3.exe -c REMOTE_PC_IP -P 8

5. Run a reverse-direction test​

.\iperf3.exe -c REMOTE_PC_IP -P 8 -R

What the iperf3 results will tell us​

Single stream low, -P 8 much higher = latency/TCP window/SMB issue
Both single and -P 8 around 70–100 Mbps = router/VPN bottleneck
Reverse direction much faster/slower = one router or one ISP direction is limiting
iperf3 fast but SMB slow = Windows file sharing/SMB issue

Important: test PC-to-PC, not router-to-router​

Run iperf3 between two wired PCs, one at each site.
Do not test over:

Wi-Fi
USB Ethernet
Powerline adapters
Old laptops in power-save mode
NAS with slow disks

Also test with one large file​

For SMB testing, use one large file, like 5–20 GB. Lots of small files will perform badly over VPN.
Try:
robocopy "\\REMOTE_PC_IP\Share" "D:\TestCopy" BigTestFile.iso /R:1 /W:1
Or for a folder:
robocopy "\\REMOTE_PC_IP\Share" "D:\TestCopy" /E /MT:16 /R:1 /W:1

My current guess​

Given your numbers, I would rank the causes like this:

1. Your Synology router CPU/VPN processing limit
2. MTU/MSS problem causing fragmentation or retries
3. Remaining SRM inspection/QoS/firewall processing
4. SMB copy inefficiency
5. ISP path jitter/packet loss

The 75–90% CPU on your router is the biggest red flag. If iperf3 -P 8 also tops out around the same 70–160 Mbps range while CPU is high, then the Synology router is probably the limiting device.
Post the three iperf3 results when you get them:

iperf3 -c REMOTE_PC_IP
iperf3 -c REMOTE_PC_IP -P 8
iperf3 -c REMOTE_PC_IP -P 8 -R

Also include which Synology model is on each end. That should make it pretty clear whether this is CPU, MTU, or SMB.

 

[droogiee]

can i run openspeed test instead?

 

[ChatGPT]

Yes, you can run OpenSpeedTest, and it is useful — but I would still use iperf3 if possible because it gives cleaner diagnostic results.

Short answer​

Use both if you can:

OpenSpeedTest = easy browser-based throughput test
iperf3 = better technical VPN/network diagnosis

OpenSpeedTest is fine for a quick “how fast is site A to site B?” test, but iperf3 is better for figuring out why it is slow.

Why iperf3 is better for troubleshooting​

iperf3 lets you test:

Single stream speed
Multi-stream speed
Reverse direction speed
TCP vs UDP behavior
Jitter/loss with UDP

OpenSpeedTest mostly tells you:

Download speed
Upload speed
Latency
Browser-to-server performance

That is helpful, but it is less precise when diagnosing VPN, MTU, CPU, or SMB issues.

If you want to use OpenSpeedTest​

Run the OpenSpeedTest server on a wired PC at one site, then browse to it from the other site through the VPN.

1. Install/run OpenSpeedTest server on one PC​

Run it on a wired PC at work or home.
Example:

Work PC: 192.168.20.50
OpenSpeedTest port: 3000 or 8080

2. Allow it through Windows Firewall​

If prompted, allow it on Private networks.
If needed, manually allow the port. Example for port 3000:
New-NetFirewallRule -DisplayName "Allow OpenSpeedTest from VPN" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 3000 -RemoteAddress 192.168.10.0/24 -Profile Any
Change 192.168.10.0/24 to the opposite site’s subnet.

3. From the other site, open the browser​

Use the remote PC IP, not the hostname:
[url unfurl="true"]http://192.168.20.50:3000[/url]
or whatever port OpenSpeedTest is using.

4. Run both directions if possible​

Test:

Home browser -> Work OpenSpeedTest server
Work browser -> Home OpenSpeedTest server

This helps show if one direction is worse.

How to interpret the results​

If OpenSpeedTest also tops out around:
70–160 Mbps
while your Synology CPU is hitting:
75–90%
then the problem is probably router/VPN processing, not SMB.
If OpenSpeedTest is much faster, for example:
250–400 Mbps
but Windows file copies are still slow, then the issue is more likely:

SMB behavior
Windows Firewall/security scanning
disk speed
many small files
name resolution
credentials/session behavior

Important testing tips​

1. Use wired Ethernet only.
2. Test with PCs that have 1 Gbps link speed.
3. Use the remote IP address, not computer name.
4. Close other downloads/uploads.
5. Watch Synology Resource Monitor during the test.
6. Run the test in both directions.
7. Record CPU usage on both routers while testing.

Check Windows link speed with:
Get-NetAdapter | Select Name, Status, LinkSpeed

My recommendation​

Yes, run OpenSpeedTest first because it is easier.
But if the result is still poor, I would still do iperf3 after that because Synology support will likely take iperf3 results more seriously.
Post these if you can:

OpenSpeedTest download result:
OpenSpeedTest upload result:
CPU on home router during test:
CPU on work router during test:
Home router model:
Work router model:
Largest successful ping -f -l value:

Given your MTU limit and your router hitting 75–90% CPU, I still suspect the Synology router/VPN processing path is the main bottleneck.

 

[droogiee]

one way was 90 mbps running it the other way i got 220 mbps, i ran the tests 3 times each.. every time was the same

 

[ChatGPT]

That result is actually very useful:

Direction A: ~90 Mbps  = ~11 MB/s
Direction B: ~220 Mbps = ~27.5 MB/s

So the tunnel is not equally slow both ways. That usually means the issue is direction-specific, not just “SMB is slow.”

What this points to​

Most likely causes, in order:

1. One router is CPU-limited in one direction
2. One site’s upload path is worse than the other
3. MTU/MSS fragmentation is affecting one direction more
4. Synology traffic/security processing is still active on one side
5. ISP routing/peering is worse one way
6. OpenSpeedTest direction is being misread

Important: OpenSpeedTest direction can be confusing​

If the OpenSpeedTest server is at work and you open it from home:

Download test = work uploads to home
Upload test   = home uploads to work

So if you got:

Download: 90 Mbps
Upload: 220 Mbps

that means:

Work -> Home is 90 Mbps
Home -> Work is 220 Mbps

If the server is at home, then reverse that interpretation.

Watch CPU during each direction​

Run the test again and watch both Synology routers in Resource Monitor.

1. During the 90 Mbps direction​

Check:

Home router CPU:
Work router CPU:

2. During the 220 Mbps direction​

Check:

Home router CPU:
Work router CPU:

If one router hits:
85–100% CPU
during the 90 Mbps test, that router is probably the bottleneck.

Your previous CPU result matters​

You said your end was bouncing around:
75–90% CPU
That is high. If that happens during VPN transfer, you may simply be hitting the router’s practical VPN throughput limit with your current settings/features.
Even though Synology advertises high site-to-site throughput, real speed depends on:

Encryption settings
Packet size / MTU
Firewall rules
Traffic monitoring
Threat Prevention
Safe Access
QoS
Logging
Concurrent router workload

Try rebooting after disabling security features​

Since disabling Safe Access and Threat Prevention helped slightly, I would do this:

1. Disable temporarily on both routers​

Check:

Safe Access
Threat Prevention
Traffic Control
QoS / bandwidth control
Traffic reports / traffic monitor
Firewall logging
Application rules
Device bandwidth limits

2. Reboot both Synology routers​

Do not just disable and immediately test. Reboot both sides.

3. Test again​

Run OpenSpeedTest both ways again.
Undo: Re-enable the protections afterward if you rely on them.

MTU still looks suspicious​

You said anything above this failed:
ping REMOTE_PC_IP -f -l 1360
That implies an effective MTU around:
1360 + 28 = 1388
That is low enough that bad MSS handling could cause retransmits and bouncing speeds.
If Synology support asks, tell them:

Largest successful no-fragment ping payload: 1360
Anything above 1360 fails

If SRM exposes any MSS clamping or MTU setting for the VPN/WAN, try:

MTU: 1380
MSS: 1340 or 1360

220 Mbps is decent, 90 Mbps is the real problem​

At 220 Mbps, you are getting around:
27.5 MB/s
That is not terrible for router-based IPsec, though still below your 500 Mbps line.
At 90 Mbps, you are getting around:
11 MB/s
That matches your poor file transfer results much more closely.
So focus on the 90 Mbps direction.

Next best test​

Set up OpenSpeedTest server on the opposite side too, if you have not already.

Test layout​

1. Run OpenSpeedTest server at home, test from work.
2. Run OpenSpeedTest server at work, test from home.
3. Record download/upload from each.
4. Record CPU on both routers during each test.

This gives you a clear table like:

Server at Home, browser at Work:
Download:
Upload:
Home router CPU:
Work router CPU:

Server at Work, browser at Home:
Download:
Upload:
Home router CPU:
Work router CPU:

Still recommend iperf3​

OpenSpeedTest is fine, but iperf3 will make this much easier to prove.
The specific tests you want are:

.\iperf3.exe -c REMOTE_PC_IP
.\iperf3.exe -c REMOTE_PC_IP -P 8
.\iperf3.exe -c REMOTE_PC_IP -P 8 -R

Those will show whether the 90 Mbps direction is:

single-stream TCP issue
multi-stream issue
reverse-direction issue
router CPU issue

My current guess​

Based on your numbers, I would suspect:
One Synology router is maxing out its VPN/packet-processing path in one direction.
Especially because:

Safe Access/Threat Prevention off = slight improvement
Your router CPU = 75–90%
MTU above 1360 fails
Speeds bounce 5–20 MB/s
One direction = 90 Mbps, other = 220 Mbps

That combination smells more like router/VPN processing + MTU/MSS than a Windows sharing problem.
If you post which direction was 90 Mbps and which router showed 75–90% CPU during that exact test, we can narrow it down further.