10 replies to this topic

[zambs224]

Hey guys, I'm having another VPN issue, this time regarding FTP upload speeds. I followed this guide and it worked perfectly to connect to my FTP server, but trying to download something from the server is absolutely impossible. The first moment of connection will yield somewhere between 20 kB/s and 5 megs a second, but will deteriorate seemingly exponentially. I've let a connection run for half and hour or so, just to see what will happen, and the speed reaches a plateau at around 100 bytes a second.

 

Obviously, I refuse to believe the VPN is at fault for this; I assume it's my ISP. I've checked out others with similar problems, but I haven't found any solutions. In total, I have tried to download the file via my own IP, a DDNS pointing to the VPN server, the VPN server's exit IP, and the LAN address. From the LAN address, everything is as expected - a speed that is normal for me, about 3 megs. When connecting through my WAN IP through port 21 (which is correctly forwarded), I get a connection timeout error (Something I need to investigate).  When connecting through the VPN or the DDNS, the problem I described above plagues me. Below is what I monitored by eye when trying to download a file:

3.42 MB/s
19 kB/s
14 kB/s
12 kB/s
10 kB/s
9 kB/s
8 kB/s
7 kB/s
6.9 kB/s
6.4 kB/s
5.5 kB/s
4.8 kB/s
4.3 kB/s
4.02 kB/s
3.65 kB/s
3.21 kB/s
2.98 kB/s
... (it continues to fall, but I stopped the connection there)

 

And here is the log that it gave. I don't know if the information will be useful, though, since I prematurely terminated the connection.

 

 

 

If anyone can give me a hand, I'd really appreciate it!

[Staff]

Hello!

 

Just to understand whether the problem is related or not to UDP in your system and/or in your ISP settings, do you see any difference in performance if you establish a VPN connection in TCP (we're assuming that your current connection is on UDP)?

 

Kind regards

[giganerd]

Spoiler

Spontaneous idea: Change the OpenVPN compression algorithm. Default is [adaptive] and enables or disables it dynamically based on sample tests.

 

--comp-noadapt

When used in conjunction with --comp-lzo, this option will disable OpenVPN's adaptive compression algorithm. Normally, adaptive compression is enabled with --comp-lzo.

Adaptive compression tries to optimize the case where you have compression enabled, but you are sending predominantly incompressible (or pre-compressed) packets over the tunnel, such as an FTP or rsync transfer of a large, compressed file. With adaptive compression, OpenVPN will periodically sample the compression process to measure its efficiency. If the data being sent over the tunnel is already compressed, the compression efficiency will be very low, triggering openvpn to disable compression for a period of time until the next re-sample test.

 

Remembered this because it has effect on FTP traffic.

 

Compression is disabled without LZO. My god, I'm so dumb.

[EdensSpire]

I personally have rather slow speeds too, upload is full steam ahead tho, sometimes I may be able to reach a 20 Mbps download tho I figured it had to do with port but even after changing the FTP port on my server to something I forwarded on airvpn it didn't make a change.

[zhang888]

The best way to see if it's a server related issue or not would be downloading the same file from the same server, once with FTP and once with HTTP for example.

Many servers provide that option.

 

http://speedtest.ftp.otenet.gr/

http://ftp.telfort.nl/pub/test/

 

If you have an issue only with FTP and it occurs from many VPN servers, it is safe to assume that the issue is on the remote server (overload, traffic shaping, distance, etc)

[EdensSpire]

I should probably have stated it's only when I'm connected to VPN when I'm not, speed is at max.

 

Currently is one of such times where my speed is high =)

 

Also my server is in France with a 1Gbps connection. the VPN I'm connected to isn't far away from there.

Edited by EdensSpire, 05 May 2015 - 11:21 AM.

[zambs224]

Ah! Thanks for the discussion, it's nice to see I'm not the only with this issue to some extent

 

Hello!

 

Just to understand whether the problem is related or not to UDP in your system and/or in your ISP settings, do you see any difference in performance if you establish a VPN connection in TCP (we're assuming that your current connection is on UDP)?

 

Kind regards

I've tried using tree connection modes: the default UDP and TCP options, and UDP port 2018, I hope this help

 

 

 

The best way to see if it's a server related issue or not would be downloading the same file from the same server, once with FTP and once with HTTP for example.

Many servers provide that option.

 

http://speedtest.ftp.otenet.gr/

http://ftp.telfort.nl/pub/test/

 

If you have an issue only with FTP and it occurs from many VPN servers, it is safe to assume that the issue is on the remote server (overload, traffic shaping, distance, etc)

I went ahead and tried testing this using the recommended server by country (America), default TCP connection mode. I'm using a headless server running Debian to do the testing, let me know if this isn't sufficient.

 

HTTP, VPN active

FTP, VPN active

 

Seeing that I was able to transfer so quickly with a VPN using FTP, I went and tried a public FTP site. The logs are here, and really this outcome is puzzling. Data transfer works fine for other servers, but not my own FTP server. Maybe posting my configuration will help (I'm using proftpd for this):

 

ServerName                      "ATMA2"
ServerIdent                     on "ATMA2 FTP server standing by."

ServerType                      standalone
DefaultServer                   on
Port                            21,44100

TimeoutNoTransfer               600
TimeoutStalled                  600
TimeoutIdle                     1200

MaxInstances                    14
DefaultRoot /path/tosomefiles zambs224

DisplayLogin               welcome.msg

PassivePorts 63178 63187
MasqueradeAddress 199.19.94.193
 

I have to edit the MasqueradeAddress directive when I launch openvpn and find out what address airvpn's server is giving me for the session, then restart the daemon, if you're wondering.


The settings are mostly defaults, though, nothing that I think would cause data transfer problems! Thanks again for the input, I'll continue doing research while I anticipate your guidance!

[zambs224]

More research leads to few answers. Without fail, the connection locks up after about .08 mb is transferred. If the file is smaller than that, it will transfer with no problem. AirVPN is a completely useless service without the ability to let download via ftp at speeds greater than 500-2000 bytes a second.

 

Absolutely ridiculous.

[Staff]

More research leads to few answers. Without fail, the connection locks up after about .08 mb is transferred. If the file is smaller than that, it will transfer with no problem. AirVPN is a completely useless service without the ability to let download via ftp at speeds greater than 500-2000 bytes a second.

 

Absolutely ridiculous.

 

Hello,

 

FTP servers and client work just fine in AirVPN. The FTP server requires specific setup due to how an FTP daemon maps ports for the client, please see https://airvpn.org/topic/1700-ftp-server-and-client-on-air-vpn/#entry1702

 

Assuming that everything was correctly set on your side (and it seems it's ok, because little files can be transferred succuessfully), then the issue looks like an MTU size problem. Try with directive "mssfix". Insert

mssfix 1400

in the "Custom" field which appears in "AirVPN" -> "Preferences" -> "Advanced" -> "OVPN directives", click "Save", start a new VPN connection and test again.

 

If necessary, decrease the mssfix value at steps of 50 (for example "mssfix 1350", "mssfix 1300" and so on) until the problem is resolved. If the problem is not solved, then it's probably not an MTU size issue.

 

Kind regards

[EdensSpire]

hmm I seem to be getting full speed on FTP now.

[zambs224]

Alright, I had a few days to take a breather; I think you're right about the MTU size, researching the issue was leading me to that being the culprit, but I wasn't aware that the VPN connection itself can have a custom defined size. I'd love to try our your solution, but...

 

 

Every server, every time. This is after trying 8 or so servers - checking to see if the custom parameter is the cause, then changing my passive port range (on airvpn and proftp -- service restarted and ready to roll, of course). I'll give it some time, check back later and see if the ports opens up for some reason, maybe try a few more config variations. I hope this is just coincidence. Anyways, in the meantime, thanks for the help everyone has given thus far, I appreciate it.