Painfully slow OpenVPN connection between Pfsense and Synology NAS

I’ll preface this by saying that my networking knowledge is very limited.

I have an OpenVPN server running on an XG-1537 and a 10Gbit fiber network as well as a Synology RS3618xs with a bunch of SSDs in it. Both devices are connected a single rackmounted switch.

When connecting from another location over Viscosity (VPN app), it results in extremely poor sequential reads from the NAS (right about 8MB/s max), even I can download files at well above that speed (gigabit+ speeds).

This goes for smb on both mac and pc, and the Synology web interface. It seems capped at right about that number. All traffic is redirected over the server (send all traffic in Viscosity as well as on the pfsense server setting) and if you do a regular speedtest you can easily get high speeds downloading just about anything else.

What I’ve tried:

  • Changing encryption settings, encryption on/off, different algorithms, excluseviley 256-GCM or 128-GCM with AES-NI enabled.
  • Changing MTU values on the synology from 1500 to 9000 and lower, enabling SMB2 as max, enable opportunistic locking, disable encryption
  • Changing the MTU values in the pfsense openvpn server settings, buffer settings, and setting things such as fast-io, sndbuf 524288 , rcvbuf 524288.
  • Redirect IPv4 Gateway on and off, different compression settings (currently decompress incoming and disable compression)
  • Tried switching from UDP to TCP
  • Monitor hardware performance, absolutely no issues there from what I can see
  • There is an ipsec tunnel to Azure which to a fiew 10.0 networks, but the phase two records are all outside the range, for instance. I’ve also tried changing the ipv4 tunnel network on the VPN server.

The OpenVPN server is running over its own network, the synology is on a network together with the firewall which on the same subnet. NAT outbound has the default rules defined.

This is what the .ovpn settings look like:

dev tun
cipher AES-256-CBC
auth SHA1
resolv-retry infinite
remote *HIDDEN* 1194 udp
setenv opt block-outside-dns
lport 0
verify-x509-name "XX" name
ns-cert-type server
route-delay 5
route-method exe

# 2048 bit OpenVPN static key
-----BEGIN OpenVPN Static key V1-----

 key-direction 1

Any ideas what to try?

I have never tested using OpenVPN with Synology so I really don’t know how well it performs. Another option might be to test if something like Tailscale would be a better option.
Access Synology NAS from anywhere · Tailscale

Few things to note:

  • SMB does not work well over WAN or any higher than typical LAN latency. Any extra openvpn overhead will result in fragmentation and further slowdown (do a quick search on Reddit on how horrible it is). SMB3 attempts to address some of the problems, but it’s still a very chatty protocol with all the CRC checks.
  • OpenVPN server instances are single-threaded, thus the max speed you can encrypt traffic will only be as fast as a single thread/core can process (even with aes-ni acceleration, you will be limited by TLS?). Give wireguard (or tailscale) a try if you want to try a more performant vpn.
1 Like

@David has a good point regarding SMB, I connect to a NAS with ftp over OpenVPN which is a bit better, though my WAN is slow so I get close to line speed.

I tried Tailscale and I still have about 30-60M Bits/sec Bandwidth out according to traffic logs in pfsense. Doesn’t matter if I use windows explorer or try downloading directly from the web interface.

Keep in mind when I download files using a file explorer from a Virtual Machine in Azure the speeds caps out at the bandwidth that we pay for , about 304.59M Bits/sec

It’s so frustrating

Do you have Traffic Shaping?

Don’t know what or how, but I updated to the latest version of pfsense 22.01-RELEASE restarted and enable/disable the encryption settings on the NAS, set the DTU back to 1500, and the problem is suddenly no more. I’m maxing out my 400mbps connection at home now.

Can definately put in a recommendation for Tailscale , it was super easy to setup and well documented.

Thanks for the easy solution @LTS_Tom