Client access for file transfers very slow
-
Setup:
Single pfsense v2.1-RELEASE (i386) build on wed Sep 11 18:16:50 EDT 2013, FreeBSD 8.3-RELEASE-p11 (just updated Friday)Server is a 1u dell rack server, 2x Xeon 2.8ghz, 4gb's ram (running 32bit pfsense so 3.5gb usable)
Intel em4 pci-express 4-port gigabit card used for the following interfaces:
2 x FIOS static IP WAN ports, using gateway groups to load balance (150Mb down / 65Mb up + 35Mb down / 35Mb up) - have tried using both interface external IP's to connect to via openVPN with exact same result
1 x LAN port
1 x WIFI guest network port
All connected through 1000baseT/full duplexServing about 150 internal clients, about 10 openVPN clients but usually only 2 connected at any given time (nobody works remotely other than on nights/weekends)
CPU usage is typically <10% even at full load maxing out every port, memory usage never over 20%, disk usage 3% of 64Gb, swap usage 0%
All Internal windows clients are on gigabit and can download from internal server on LAN at 115MB/sec for the single test file that I am using here from windows shared folder (photoshop cs6 installer, ~7Gb and compressed with 7zip)
Remote clients through the openVPN link cannot exceed 400Kb/sec grabbing this same file.
Remote client has FIOS 50mb down/10mb up and FIOS 15mb down/2mb up connections, both see exact same behavioropenvpn config of client:
dev tun
persist-tun
persist-key
cipher BF-CBC
tls-client
client
resolv-retry infinite
remote x.x.x.x 1194 udp
tls-remote ZGopenVPNsvr
pkcs12 pfsense2-udp-1194-vpn.p12
tls-auth pfsense2-udp-1194-vpn-tls.key 1ip.fast-forwarding is set to 1 under advanced tuning on pfsense/openvpn server, have tried other forms of cipher, cipher to null, mssfix, mssfix 0, mssfix 1400, fragment 1400, fragment 0, various MTU sizes…etc
Any help greatly appreciated!
-
hi,
there are many factors that can reflect the speed of the OpenVPN client's download:
1. at the server end, if we do not have a symmetrical down/up link, the max up stream bandwidth will determine the download speed of the client.
2. at the client end, the local ISP that the client uses with the max. down stream speed will determine the speed. Also for the client's hardware and OS will also effect the speed (because of the encryption). A client might also use WIFI and the connection from client PC to the Wireless Access Point might be significantly slower than the actual ISP subscription.
-regards,
-
@rayh:
hi,
there are many factors that can reflect the speed of the OpenVPN client's download:
1. at the server end, if we do not have a symmetrical down/up link, the max up stream bandwidth will determine the download speed of the client.
2. at the client end, the local ISP that the client uses with the max. down stream speed will determine the speed. Also for the client's hardware and OS will also effect the speed (because of the encryption). A client might also use WIFI and the connection from client PC to the Wireless Access Point might be significantly slower than the actual ISP subscription.
-regards,
Thank you for the suggestions, but none of the endpoints have 200kb/sec speed limitations for transfers.
Server connections speeds are listed in the original post, the slowest uplink is 35Mb/sec FIOS (fiber)
Client 1 -
intel core i7-2600k cpu, 16gb ram, 5x WD 10k rpm velociraptor 150gb HDD's in RAID5, windows 7 pro x64FIOS 15Mb down / 5Mb up
Wired gigabit connection to FIOS routerClient 2 -
Intel core i7-4770k cpu, 16gb ram, Seagate 840 500gb SSD, windows 7 pro x64FIOS 75Mb down / 15Mb up
Wired gigabit connection to FIOS routerNote: all clients subscribe to the same ISP as the server (Verizon FIOS) and are in the same county, client 1 is 1.5 miles away from the server.
It's something in the openVPN config, but I don't know what has changed - this same config has worked to client 1 in the past at 15Mb/sec (maxing out my downstream) in the past.
-
I just ran an "openssl speed" test on the pfsense/openvpn server during a high load time (everyone is here working now) and got these results:
The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes md2 1867.71k 4184.08k 5871.39k 6003.36k 6663.95k mdc2 4398.47k 4964.94k 5091.24k 4997.65k 5128.14k md4 16679.65k 62489.84k 177446.29k 409024.13k 637289.96k md5 13617.40k 48709.93k 135906.65k 282906.40k 410481.74k hmac(md5) 14040.19k 50555.52k 144082.45k 292605.54k 361469.56k sha1 10114.28k 29187.63k 57644.13k 85464.09k 99433.10k rmd160 9227.07k 25920.55k 50163.75k 72121.12k 81864.23k rc4 83025.69k 104985.58k 110793.49k 112358.52k 111834.95k des cbc 55924.15k 58234.64k 58925.49k 58706.33k 58709.76k des ede3 20431.99k 21112.90k 21288.40k 21767.77k 21134.92k idea cbc 0.00 0.00 0.00 0.00 0.00 seed cbc 0.00 0.00 0.00 0.00 0.00 rc2 cbc 23283.56k 24586.17k 23265.54k 24663.30k 24925.26k rc5-32/12 cbc 147020.42k 156687.88k 165202.99k 167729.63k 168922.93k blowfish cbc 92127.81k 99392.55k 101027.43k 98740.60k 99144.11k cast cbc 81161.29k 86828.15k 88059.11k 88482.58k 87602.54k aes-128 cbc 53557.26k 54406.44k 55433.21k 55603.49k 48293.26k aes-192 cbc 45740.66k 44145.82k 48710.16k 49089.77k 49065.74k aes-256 cbc 42723.10k 42525.86k 42978.06k 42952.21k 43104.33k camellia-128 cbc 47396.04k 49785.95k 50296.36k 50846.24k 50111.99k camellia-192 cbc 35676.54k 37485.12k 37954.64k 38455.63k 38064.62k camellia-256 cbc 34709.38k 36690.59k 37905.97k 38057.95k 38005.11k sha256 8648.21k 20466.67k 35499.55k 43947.39k 47999.44k sha512 1813.17k 7177.76k 10239.01k 14293.80k 16086.35k aes-128 ige 51305.91k 54392.01k 55953.95k 55858.65k 56830.16k aes-192 ige 44964.03k 47786.11k 49083.11k 48823.24k 49381.62k aes-256 ige 40901.03k 40610.81k 41079.02k 43779.34k 44196.08k sign verify sign/s verify/s rsa 512 bits 0.001029s 0.000110s 972.1 9126.4 rsa 1024 bits 0.004948s 0.000269s 202.1 3715.0 rsa 2048 bits 0.029049s 0.000843s 34.4 1185.6 rsa 4096 bits 0.192514s 0.003025s 5.2 330.6 sign verify sign/s verify/s dsa 512 bits 0.000811s 0.000942s 1232.8 1061.5 dsa 1024 bits 0.002341s 0.002814s 427.2 355.3 dsa 2048 bits 0.007644s 0.009513s 130.8 105.1So my AES-128 @ 1024 column makes it look to me like this box can support 54.3Mb/sec with AES-128 encryption, so the dual xeon cpu's are definitely not the issue.
-
hi,
From your client config, you are using Blow Fish cipher.
openvpn config of client:
dev tun
persist-tun
persist-key
cipher BF-CBC
tls-client
client
resolv-retry infinite
remote x.x.x.x 1194 udp
tls-remote ZGopenVPNsvr
pkcs12 pfsense2-udp-1194-vpn.p12
tls-auth pfsense2-udp-1194-vpn-tls.key 1BlowFish is one of the ciphers which is very light in CPU load, so it is definitely not the CPU load is the problem.
One suggestion is that, you can put your client 1 PC directly into your GB LAN at your external server's LAN, preferably with a public IP address and access to your server via OpenVPN, this way, you can actually see what is the max bandwidth or transfer rate you can get. If you can get a good decent transfer rate, it means that there is nothing wrong with your OpenVPN setup (client/server), it must be something from the internet (e.i. your ISP Verizon?) ; I am not sure if there could be a max CAP for UDP port 1194??
If you can't get a decent transfer rate, then you can trouble shoot the Open VPN config.I would normally benchmark our setup this way, to see what the max bandwidth we can get out of our boxes, before we put them at the client end.
regards,