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.

1. Log into SRM.
2. Go to Network Center.
3. Check Security / Firewall rules.
4. 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.