4

I'm using a "server" that is a hacked-up first generation Apple TV running Linux.

I'm having a lot of trouble getting OpenVPN performance to be what I would expect with my new OpenVPN setup. The network looks like this:

Home LAN 172.16.1.0/24 VPN Clients (10.8.0.0/24) -> Airport Extreme (forwarding OpenVPN port) -> OpenVPN Server (listening on OpenVPN port 1294) -> Home iMac -> NAS Box

I am using routing, with the following config file. Routing is set up using IP Masquerading on the OpenVPN server, because I can't create static routes on my gateway, which is an Airport Extreme). Note that CPU usage on the VPN server is minimal throughout all the tests below.

Server config:

port 1294
proto udp 
dev tun 
ca privnet/ca.crt
cert privnet/server.crt
key privnet/server.key
dh privnet/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120 
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 4
script-security 2
push "route 172.16.1.0 255.255.255.0"
topology subnet
route 192.168.163.0 255.255.255.0 10.8.0.2
tun-mtu 1500
fragment 1000
mssfix

The tests I am running use only one VPN client. Without the fragment and mssfix lines in both the client and server configs, performance was so bad that I got one VNC frame or so per second when VPNing across two 35Mb FiOS connections. When I added these lines, VPN performance improved but is still extremely slow.

My easier test case though is SCP performance.

  • Client downloading via SCP form the OpenVPN server without VPN is fast (1 MBps).
  • Client downloading via SCP from the OpenVPN server with VPN activated (using the VPN servers local LAN IP and port) is fast (1 MBps)
  • Client downloading via SCP from any other computer on the OpenVPN server's subnet with VPN activated is extremely slow (<50 KBps).
  • Client uploading via SCP to the OpenVPN server without VPN is fast (>300 KBps)
  • Client uploading via SCP to the OpenVPN server with VPN activated is fast (>300 KBps)
  • Client uploading via SCP to any other computer on the OpenVPN server's subnet with VPN activated is fast (>300 KBps)

Can anyone suggest what to do, and why I'm seeing these vastly differing speeds?

Wesley
  • 32,690
  • 9
  • 82
  • 117
Michael Gorbach
  • 71
  • 1
  • 6

4 Answers4

1

MTU is typically the issue across VPNs. Fragment might help, but you might try lowering the MTU on a test machine and doing a test SCP.

The other thing you might look at is NATing. Do TCPdumps on the internal interfaces (the unencrypted traffic) and make sure you are seeing the IPs you would expect. I've seen some misconfigured NATs and routing that completely tanked performance.

Also, a TCPdump will tell you packet size, which is good for troubleshooting.

JakeRobinson
  • 2,904
  • 18
  • 26
  • The only real NAT on the network is from the Airport Extreme. The OpenVPN router, on the other hand, is doing Masquerading. Do you mean lowing the MTU on the downloader machine or the machine hosting the downloaded file for an SCP? How would I do this lowering? – Michael Gorbach Jan 21 '12 at 04:18
1

Well it's a shot in the dark: Contrary to conventional wisdom, I had a situation over an easily congested connection (ADSL 6/0,6Mbit/s) that worked better (should I say only?) if the OpenVPN traffic is encapsulated in a TCP stream as opposed to UDP datagrams.

The problem was that timeouts on the inner TCP stream occured because of dropped UDP packets of the crypted stream (congestion being the primary source). Somehow the window scaling in the inner TCP channel did not help as expected (it should scale down to basically a send-waitack-cycle).

As for diagnosis: Install wireshark and capture the openvpn traffic and the lan traffic and watch out for excessive TCP retransmissions. These are signs of dropped packets. Also see if there is some routing problem with packets appearing on the wrong interface or with the wrong IP (as noted by JakeRobinson).

Also try to reduce tun-mtu to something innocent like 1300. This will hurt top speed but not in the region you are having problems in.

Good luck and let us know if you find out the cause!

Paul
  • 1,918
  • 4
  • 18
  • 24
  • netstat on the machine I am downloading from (on the VPN server's subnet) shows: 1223420 data packets (1420132954 bytes) retransmitted. On the other hand, netstat on the VPN client shows: 1602 segments retransmitted. Anyone know what is causing the retransmissions? – Michael Gorbach Jan 26 '12 at 03:49
1

Figured it out: It was a problem, either hardware or the drivers, with the network card on the server. The "server" is a hacked-up first generation Apple TV running Linux, and for some reason the built-in ethernet wasn't performing very well at all when doing masquerading. I've plugged in a USB gigabit ethernet dongle, and all is well!

Michael Gorbach
  • 71
  • 1
  • 6
0

If I understand your configuration well, I think, that you have a bad this line in the server's configuration:

push "route 172.16.1.0 255.255.255.0"

This line is directive for server to send to client, that route to subnet 172.16.1.0/24 is via VPN server, which is not right, isn't it?

And, secondly, I think that you have to have instead this line in the server's setup this line:

push "route 192.168.163.0 255.255.255.0"

because this is the net behind a VPN server...

You can check it, when you connect to the VPN server and list your routes...

Jan Marek
  • 2,180
  • 1
  • 13
  • 14
  • The second line (182.168.163.0) is left from me playing around with an earlier configuration, and doesn't do anything here. I've removed it without affect anything. The first push line though, as far as I see, is correct. The server's LAN is 17.16.0.1/24, and clients access machines on that LAN through the VPN server. Connectivity _is_ functional, just very slow ... – Michael Gorbach Jan 26 '12 at 02:58
  • OK, I misunderstood network configuration. But, if you are using ADSL, I can recommend you using link-mtu instead of tun-mtu and max link-mtu for ADSL have to be 1492 and if you are using PPPoE, then max link-mtu you can set to 1452. Or you can try a `--mtu-test` switch and leave openvpn to test your lines for optimal MTU. – Jan Marek Jan 26 '12 at 07:54