Bionic711
I have a setup on a DD-WRT box as a server with config:
daemon
server-bridge xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
management localhost 5001
script-security 3
tun-mtu 1500
mssfix 1400
push "redirect-gateway bypass-dhcp bypass-dns def1"
push "dhcp-option dns xxx.xxx.xxx.xxx"
push "dhcp-option dns xxx.xxx.xxx.xxx"
comp-lzo
push "persist-tun"
push "persist-key"
port 1194
cipher AES-256-CBC
dev tap0
proto udp
keepalive 10 60
client-to-client
#tls-auth /tmp/openvpn/ta.key
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
auth-user-pass-verify "/jffs/verify.sh" via-file
tmp-dir /tmp/nvram
verb 7
And a Win 7 64 bit Client with config:
remote xxx.xxx.xxx.xxx 1194
client
float
persist-key
persist-tun
nobind
tun-mtu 1500
mssfix 1400
script-security 3
comp-lzo
auth-user-pass
ns-cert-type server
cipher AES-256-CBC
dev tap0
#tls-auth "C://Program Files (x86)//OpenVPN//config//tls-auth.txt"
proto udp
ca "C://Program Files (x86)//OpenVPN//easy-rsa//keys-443//ca.crt"
cert "C://Program Files (x86)//OpenVPN//easy-rsa//keys-443//Port443Client.crt"
key "C://Program Files (x86)//OpenVPN//easy-rsa//keys-443//Port443Client.key"
verb 7
The tunnel is up, connecting and working for the most part.
However, the speed through the tunnel is EXTREMELY slow. Both ends are on 30/10 cable lines.
Speedtest is rating the speeds at .21/1.6 which seems extremely slow. I figured I should be getting about 30% of max bandwidth using the redirect-gateway bridge.
Any information needed I can supply for you, just ask. I really don't think that a redirect-gateway should be holding the traffic at less than 1% dl speed. The ISP is the same and the locations are only about 10miles apart geographically.
Mimiko
Try testing speed removing options "comp-lzo" and "cipher".
janjust
try it without using
server-bridge
(use 'server ...' instead)
Bridging will almost always kill performance, esp on a Windows network with a Windows-based server. Why do you need bridging in the first place?
Bionic711
My VPN has mysteriously died since I tried to use the tls-auth command. Had it running for a day successfully so working out that kink. Will report on speed with comp off. Doesn't cipher encrypt the data? Just for testing purposes correct?
Also, it's a linux server. The ovpn server is a dd-wrt router. Windows network though.
Do I need to change anything other than server-bridge to server? Like push routes and stuff? I use bridge because I want the device connecting to be in the same subnet when connected as the devices in the server's LAN subnet.
In addition, I also have several devices I connect through the client to my home network. The bridge is the only way I've found to do this. (Other devices include a Tablet, a second laptop, and a smartphone)
Bionic711
Alright, fixed the issue. Had to reflash the Firmware to fix it but it's working now.
Anywho, took the comp-lzo off and now getting speeds of 25/7 on the same network with the tunnel up. I'll try tomorrow when I'm remote. I expect to be right around 6/1.2 tbh. Let you guys know how it goes.
Bionic711
Got some remote testing done and speeds are still the same as with cipher and comp taken out.
In order to change my configs to work as a routed rather than bridging, what do I need to change?
Bionic711
Alright, changed to a routed vpn and speeds are even slower.
Here's my configs:
Server:
daemon
server 192.168.17.184 255.255.255.248
push "route 192.168.17.192 255.255.255.224 192.168.17.185"
management localhost 5001
topology subnet
script-security 3
tun-mtu 1500
push "redirect-gateway bypass-dhcp bypass-dns def1"
push "persist-tun"
push "persist-key"
port 1194
dev tun0
#cipher AES-256-CBC
proto udp
keepalive 10 60
client-to-client
#tls-auth /jffs/tls.key 0
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem
#auth-user-pass-verify "/jffs/verify.sh" via-file
#tmp-dir /tmp/nvram
verb 7
Client:
remote xxx.xxx.xxx.xxx 1194
client
float
persist-key
persist-tun
nobind
dhcp-option DNS 208.67.222.222
dhcp-option DNS 208.67.220.220
tun-mtu 1500
#cipher AES-256-CBC
script-security 3
#auth-user-pass
ns-cert-type server
dev tun0
#tls-auth "C://Program Files (x86)//OpenVPN//config//tls.key" 1
proto udp
ca "C://Program Files (x86)//OpenVPN//easy-rsa//keys-443//ca.crt"
cert "C://Program Files (x86)//OpenVPN//easy-rsa//keys-443//Port443Client.crt"
key "C://Program Files (x86)//OpenVPN//easy-rsa//keys-443//Port443Client.key"
verb 7
Any other ideas on the insanely low speeds I'm getting? Using the router as a server shouldn't really be causing this should it?
maikcat
just to comment that disabling cypher directive
you simply still using blowfish (default).
Michael.
ps:do you have hardware specs of your router?
Bionic711
I understand it defaults to blowfish, however, blowfish is the fastest of them, so it should yield the best results for my purposes.
I have a netgear wndr3700.
CPU Type = Atheros AR7161 rev 2
CPU Speed = 680MHz
Flash Type = Serial
Flash Size = 32MB
RAM Size = 64MB
RAM Chip = hynix 830A HY5DU561622FTP-D43
Switch = RTL8366SR 95E89SE G920B
Port-based vlan = Yes
Ethernet Port Count = 1-10/100/1000-WAN 4-10/100/1000-LAN
Wired Standard = IEEE 802.3
bootloader = u-boot
Power = 12V/2.5A
USB = Yes
Serial Port = Yes
JTAG Port = Yes
dd-wrt K2.4 Support = No
dd-wrt K2.6 Support = Yes
Should be more than capable of handling traffic with none of the security at about 30% of the 30Mbps lines that each side has.
janjust
can you please a bit more specific about the performance numbers. If I understand your setup correctly then you have something like
Server -- Cable1 | Internet | Cable2 -- Client
both Cable1 and Cable2 are 30 Mbps download / 10 Mbps upload speeds.
Is this correct? If so, then I would expect the maximum performance to be *at most* 10 Mbps (try running 'iperf' over the raw tunnel between client and server. Add encryption and compression and I'd expect performance to drop to about 8, 9 Mbps.
What are you seeing when running 'iperf' ?
Bionic711
Here's the iperf results:
Strangely enough udp reported lower bandwidth than tcp.
And yes, the lines are exactly as you understand.
To be honest, I'm not even expecting 8 or 9 Mbps, more like 6 is what I'm looking for honestly. However, even 30% of 30 is 9 Mbps so I was right the same same max ballpark.
janjust
iperf udp performance is always ~ 1 Mbps unless you use the right options for iperf.
What is the performance *outside* of the tunnel?
Bionic711
Not sure how I'd run iperf outside the tunnel behind two NATed devices without the tunnel. I'm guessing I just need to forward port 5001 to the server? Speedtest puts both link constantly between 28 and 29 Mbps.
I even switched the server from the DD-WRT box to my desktop and still getting the same speeds.
Speeds are the same even with switching the server device.
Iperf results are nearly identical also between both server devices.
janjust
I'm guessing I just need to forward port 5001 to the server?
Yep; I'd use port-forwarding on the cable router to forward a port (e.g. TCP port 22222) to the server. You can then use
iperf -s -p 22222
and connect from the other end ; I would not recommend to port-forward port 5001 , as script kiddies sometimes scan this port.
The speedtests show that you can download stuff from speedtest to your client(s) @ 28 Mbps; it does NOT show fast you can transfer data
*BETWEEN* the clients.
Bionic711
These are with no tunnel up and running.
c:\>iperf -c x.x.x.x -p 11714
------------------------------------------------------------
Client connecting to x.x.x.x, TCP port 11714
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 172.22.103.231 port 61932 connected with x.x.x.x port 11714
[ ID] Interval Transfer Bandwidth
[156] 0.0-10.1 sec 1.27 MBytes 1.06 Mbits/sec
c:\>iperf -c x.x.x.x -p 11714
------------------------------------------------------------
Client connecting to x.x.x.x, TCP port 11714
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 172.22.103.231 port 61935 connected with x.x.x.x port 11714
[ ID] Interval Transfer Bandwidth
[156] 0.0-10.0 sec 1.05 MBytes 875 Kbits/sec
c:\>iperf -c x.x.x.x -p 11714
------------------------------------------------------------
Client connecting to x.x.x.x, TCP port 11714
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 172.22.103.231 port 61936 connected with x.x.x.x port 11714
[ ID] Interval Transfer Bandwidth
[156] 0.0-10.1 sec 688 KBytes 560 Kbits/sec
c:\>iperf -c x.x.x.x -p 11714
------------------------------------------------------------
Client connecting to x.x.x.x, TCP port 11714
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 172.22.103.231 port 61937 connected with x.x.x.x port 11714
[ ID] Interval Transfer Bandwidth
[156] 0.0-10.3 sec 968 KBytes 773 Kbits/sec
c:\>iperf -c x.x.x.x -p 11714
------------------------------------------------------------
Client connecting to x.x.x.x, TCP port 11714
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 172.22.103.231 port 61938 connected with x.x.x.x port 11714
[ ID] Interval Transfer Bandwidth
[156] 0.0-10.1 sec 488 KBytes 396 Kbits/sec
c:\>iperf -c x.x.x.x -p 11714
------------------------------------------------------------
Client connecting to x.x.x.x, TCP port 11714
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 172.22.103.231 port 61940 connected with x.x.x.x port 11714
[ ID] Interval Transfer Bandwidth
[156] 0.0-10.1 sec 1.01 MBytes 840 Kbits/sec
___________________________________________________________________________________________________________________________________________
These are with the tunnel up from the same location.
c:\>iperf -c 192.168.17.219 -p 11714
------------------------------------------------------------
Client connecting to 192.168.17.219, TCP port 11714
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 192.168.17.197 port 61950 connected with 192.168.17.219 port 11714
[ ID] Interval Transfer Bandwidth
[156] 0.0-11.0 sec 520 KBytes 386 Kbits/sec
c:\>iperf -c 192.168.17.219 -p 11714
------------------------------------------------------------
Client connecting to 192.168.17.219, TCP port 11714
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 192.168.17.197 port 61951 connected with 192.168.17.219 port 11714
[ ID] Interval Transfer Bandwidth
[156] 0.0-10.1 sec 576 KBytes 467 Kbits/sec
Why are there such limitations on the lines transferring data even though both lines are 30/10? Any ideas? Is this common with VPNs?
I feel these speeds are rather low compared to what I "should" be expecting. In all seriousness I'm only looking for 6Mbps as a general bandwidth on the 30Mbps lines. I'd try from a public hotspot but than I could run into issues with client throttling and potentially unknown band speeds.
Am I wrong to assume that 6/1 (of which I'm getting the 1) is too much to expect? I mean, 20% of the total line speed?
janjust
these numbers show that there is a lot of jitter on your UPlink (which is what will limit your VPN speed eventually). what does speedtest report for the upload speeds?
my DSL modem reports that I have a 17446 / 1022 kbps connection; in practice I get an upload speed of about 870 kbps , which is fairly optimal (measured using iperf).
the only thing you can try to do to work around jitter is to fragment your packets more; try adding
fragment 1300
mssfix
to both client and server configs.
Bionic711
Without the tunnel both sides get anywhere from 8-9Mbps consistently, upload. With the tunnel up they drop to about 1.1 - 1.6 Mbps which is about what I expected. On the other hand, The reason I started this was the download speeds going from 28-29 Mbps to .1 to .2 Mbps when the tunnel goes up.
Not doubting you at all, just trying to educate myself, but what about those readings indicates there is jitter? Is it just the rapid changes in transfer speeds?
Thanks for all the help for far Jan. It is much appreciated! Gonna test the Mssfix and 1300 fixes tomorrow and let you know how it turns out.
Bionic711
c:\>iperf -c 192.168.17.219 -p 11714
------------------------------------------------------------
Client connecting to 192.168.17.219, TCP port 11714
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 192.168.17.199 port 61438 connected with 192.168.17.219 port 11714
[ ID] Interval Transfer Bandwidth
[156] 0.0-10.0 sec 2.07 MBytes 1.73 Mbits/sec
c:\>iperf -c 192.168.17.219 -p 11714
------------------------------------------------------------
Client connecting to 192.168.17.219, TCP port 11714
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 192.168.17.199 port 61444 connected with 192.168.17.219 port 11714
[ ID] Interval Transfer Bandwidth
[156] 0.0-10.4 sec 2.16 MBytes 1.75 Mbits/sec
c:\>iperf -c 192.168.17.219 -p 11714
------------------------------------------------------------
Client connecting to 192.168.17.219, TCP port 11714
TCP window size: 8.00 KByte (default)
------------------------------------------------------------
[156] local 192.168.17.199 port 61446 connected with 192.168.17.219 port 11714
[ ID] Interval Transfer Bandwidth
[156] 0.0-10.4 sec 2.00 MBytes 1.62 Mbits/sec
Also: results from ping test before:
146ms jitter
After:
34ms jitter
The fragmenting of the files really helped with the jitter issue. Not as fast as I like, but however, in bridge mode (which was said will reduce speed) at 1.7Mbps I will not complain about it. That's basically fast as any of the clients will need to go in order to get work done.
Really appreciate your help janjust. Thank you. Unless you have any other ideas to speed it up, outside of dropping bridge mode as I said can't be done because multiple devices connect through the tunnel to the home from one connection, (some are droid devices and clients won't root due to void in warranty on the device) so this is the best option.
Again, thanks so much.
