VPN connection between two Synology units extremely slow in one direction, fast the other way

VPN
1

Hello,
I have two Synology NAS boxen set up to backup each other; a 415+ “main” and a 215j “secondary”. They are located some 1000 km apart.

The master is exposing SSH (on an alternative port) and the standard OpenVPN UDP port through its router. Furthermore, it is connected to the synlology.me DynDNS and QuickConnect.

The secondary is only connected to QuickConnect and DynDNS, but nothing is currently forwarded.

The problem is that transmitting data from the master to the secondary via the VPN is painfully slow - scp claims ca. 60 kb/s; in comparison logging into the secondary via SSH (over the VPN) and scp’ing the same data using the external IP of the master runs at ca. 2 MB/s.

The other way is more or less fine, file transfers from the slave to the master via the VPN runs at ca. 2.3 MB/s vs. 2.5 MB/s without the VPN.

Does anyone have an idea of what’s going on there? Why is the VPN slow in one direction only?

2

Normally the upload speeds are slower than the download speed, so the thing that comes to my mind is that the upload speed is slower on one location than the other.

Are you sure that you are not using VPN one way and quickconnect the other way?

Try to port forward both Nas’s so all traffic goes through the VPN. (Direct connection)

Also quickconnect is slower that direct connection as it goes through Synology’s servers. But quickconnect don’t go through your VPN.

I do not know, I’m all out of ideas people. Sorry.

¯\_(ツ)_/¯

3

I’d say that at least one of your sites has an asynchronous internet connection. Meaning your upload speed at that site is significantly less than your download speed.

4

I might have found a solution - switching from UDP to TCP for the VPN connection. I guess the router on the “secondary” side (a ZyXEL P8702N provided by the Norwegian ISP “Canal Digital”), which had no forwarded ports, was just a bit slow handling incoming UDP packets. Speed is now up to > 1 MB/s (the test transfer finished while the speed was still climbing), which is still slower than ideal, but it is much acceptable than the old 60 kb/s…

Thanks!

5

Sure, they both have. But if I transfer the file via the direct SSH connection, in the same direction, the speed is much better.

6

Some more info about the workaround:

7

Eh. Suddenly, I suspect after an update to the VPNcenter app, TCP is now a lot slower than UDP. Switching back to UDP got much of that speed back, with UDP it was running at ~80 kb/s, TCP runs at ~1.5 MB/s.

This is in the middle of the day; usually this route (France/Orange → Norway/any ISP) is a lot faster during the night.

8

Could be an MTU issue… you don’t happen to have the MTU set higher than 1500, do you?

9

Hmm… how do I set that? It’s higher MTU generally better or worse?

10

Well, that’s a double-edged piece.

A MTU higher than the maximum that your VPN tunnel supports would be bad - as the packet will have to be fragmented it will slow things down.

But in some situations, like iSCSI connections or for transferring large blocks of data, having a larger MTU (aka Jumbo Frames) enabled can be a good thing.

In some situations having it set for one thing can negatively impact the other.

11

The maximum MTU over the VPN link is 1470, in either direction. It seems to be the same when pinging something outside of the VPN.

But I don’t think I can set the MTU of HyperBackup, and SSH/rsync should tune it automatically IIRC…

sudo ping -M do -s 1470 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 1470(1498) bytes of data.
1478 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=54.6 ms
^C
sudo ping -M do -s 1480 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 1480(1508) bytes of data.
ping: sendmsg: Message too long
ping: recvmsg: Message too long
12

The MTU is set on the Synology box itself on the IPv4 Interfaces:

Control Panel → Network → Network Interface → Expand Name(s) and you should see MTU. If it’s higher than 1500 you’ll want to drop it down to 1500 (1472 + the 28 header bytes gives you the 1500 - to confirm run your ping again at 1472).

The MTU is set automatically, and sometimes that can cause a problem if it is on a network that it thinks can handle a MTU of 9000

13

Thanks! I guess the higher MTU would make things speedier on the LAN, but the packages would be broken up by other networks when traversing the Internet → slow? Anyway, they are both set to 1500. The 28 header bytes are for IP+ICMP?

What did work was to switch the VPN to TCP mode; it seems that the router didn’t like forwarding UDP packages. Now it’s running stable at 1.7 MB/s, which is OK.

14

Makes sense, OpenVPN has that issue for me from certain locations.

15

Yeah. I suspect the remaining bandwith limitation to be due to the CPU of the 215j, it has a fairly slow dual-core CPU and it’s pegged around CPU 50% load (the 415+ has a quad-core atom that is quite a bit faster and isn’t even breaking a sweat, sitting at about 5% load). But eh, it works OK now, even if I could probably tweak it to get 0.5 MB/s more…