OpenVPN + Remote Desktop speed

hadeor

Hi,
I have set up an openvpn bridge for roadwarrior to access pc with remote desktop over vpn. First, since i had bad experience with udp i started a tcp connection - terrible speed. Since everybody says ofc, it is tcp over tcp == bad, i changed to udp but while the speed remained bad, it disconnects regularly. Tried to change MTU, lowered it even to 1300 but no change. mtu-test comes up with the 1572 (!) result, fragment, mssfix does nothing.
Forgot to mention, without vpn the remote desktop speed is even if not excellent, but almost totally smooth.
Any comment would be appreciated.

Cheers,
Hadeor

maikcat

hi there,

if you ping the server,

what response times you have 1)pinging the rdp server inside vpn 2)pinging your router without vpn?

cheers,

michael.

janjust

you state that you have set up an openvpn bridge - did you use bridging? can you try it without bridging? Bridging has quite an impact on performance. Also, post your server and client config files so that we can have a better understanding of what you're doing ;-)

hadeor

maikcat:
pinging rdp server over vpn
Minimum = 24ms, Maximum = 27ms, Average = 25ms
pinding router without vpn
Minimum = 22ms, Maximum = 25ms, Average = 23ms

janjust:
yes, i did bridging. i know there is SOME impact, but i think there must be some other explanation... after all it is only one user atm, with one rdp

server is an ubuntu 10.04 lts running on vmware (on windows server 2008 r2, on nice server hw), openvpn:
[strike]OpenVPN 2.1.0 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Jul 20 2010
i just realized it is a rather old openvpn, didnt think apt will use this... will update it later and test again[/strike]
OpenVPN 2.2-RC x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Mar 22 2011
updating from 2.1.0 to 2.2-RC did not bring any change

server config - currently with tcp since it is stable and the http/ssh/ftp is doing fine

mode server
dev tap0
port 1194
proto tcp-server
#proto udp
#fast-io
tls-server
dh /etc/openvpn/ssl/dh2048.pem
cert /etc/openvpn/ssl/vpnserver.crt
key /etc/openvpn/ssl/vpnserver.key
ca /etc/openvpn/ssl/dl-ca.crt
reneg-sec 216000

server-bridge
keepalive 5 60
comp-lzo
user nobody
group nogroup

persist-key
persist-tun

status /var/log/openvpn/xxx-status 1
log /var/log/openvpn/xxx.log

verb 1
mute 10

#tun-mtu 1500
#tun-mtu-extra 32
#max-clients 253

script-security 3
tmp-dir "/etc/openvpn/temp"

#tcp-queue-limit 128
#txqueuelen 200
#tcp-nodelay

inactive 600

#tun-mtu 1400
#fragment 1300
#mssfix
#mtu-test

client config

client
dev tap
proto tcp-client
#proto udp
remote xxx.xxx.xxx.xxx 1194
resolv-retry infinite
nobind
comp-lzo
persist-key
persist-tun
verb 3
mute 10
pull
ns-cert-type server
cert kosztyua.crt
key kosztyua.key
ca dl-ca.crt
tls-client
reneg-sec 0
#mtu-test

bridge

#!/bin/bash
openvpn --mktun --dev tap0
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 tap0
ifconfig tap0 0.0.0.0 promisc up
ifconfig eth0 0.0.0.0 promisc up
dhclient br0

janjust

bridging can easily destroy half your performance without a single user , so think carefully if you really need this.
As for your setup: if you must use 'proto tcp' then also enable 'tcp-nodelay' as this tends to have an impact on performance as well.

If all you're interested in is RDP via a VPN link then stop using bridging; you could even stop using OpenVPN and switch to simple SSH port-forwarding.

hadeor

No luck with changing from bridge to route, speed remains. I actually removed tcp-nodelay in hope of speeding up a bit (afaik it gives fast responses at the expense of efficiency), putting back gave no change.

Unfortunately SSH is not an option, management needs an easy solution.

I will try setting up openvpn on windows server now, outside of vmware (although it cant remain like that, only for testing)
UPDATE windows+openvpn server bad idea it seems, bad parameter --mode server 😛

UPDATE2 SSH tunnel is nice, speed much better than openvpn but slower than pure rdp.

hadeor

Btw I do not neccessarily want to stick with tcp, but i simply did not find a stable udp setup :/