3

I use openvpn to access my workplace network. When I ssh into a server(Ubuntu) over openvpn, as I type into the shell prompt the characters and letters appear slowly. So I should wait a little to see on the screen what I type. If I ssh directly (not via openvpn) then there is no delay at all. All other services also respond slowly: for e.g. accessing intranet web-pages, ftp or router configuration GUI, almost everything shows delay. I use 2 Mbps down and 800 Kbps up ADSL connection at home. And at work place I have 4 Mbps up and down ethernet based internet connection.

lynxman
  • 9,397
  • 3
  • 25
  • 28
nixnotwin
  • 1,543
  • 5
  • 35
  • 55

3 Answers3

4

nix, make sure you are using UDP mode in OpenVPN. TCP will have to do fragment reassembly for one, and that will just get worse the lower quality the link is.

SpamapS
  • 348
  • 1
  • 8
  • 1
    I think this may hit the nail on the head. I agree with others above who are sceptical about the size overhead of encryption, but tunneling TCP in TCP is known to cause horrendous performance problems over congested or erratic lines, as the backoff and retransmit algorithms for the tunnel traffic and tunneled traffic step on each other's feet. See eg "The server is configured to use UDP packets since TCP over TCP can lead to poor performance" in http://www.dd-wrt.com/wiki/index.php/OpenVPN . – MadHatter Jan 26 '11 at 10:13
  • When I set it up, UDP had been selected by default, and I have left it as it is. – nixnotwin Jan 26 '11 at 11:02
3

Any encryption mechanism will add an overhead to your connection, have in mind that overheads for some encryption are enormous.

OpenVPN by average will add a 40% to 50% overhead to your connection, on top of that ssh will also add a 40% overhead average.

All this can very easily explain why your connection over openvpn+ssh is so slow, you can do some things to make the connection lighter but it'll sacrifice a bit of security.

  • Use crypto signatures of 1024 bytes top (don't go 2048 or 4096 unless you really need to)
  • Use SSH1 or SSH2 with RSA instead of DSA (a bit less overhead)
  • Use SSH compression by default

All this will help make the tunnel lighter and faster, also if you have direct SSH access try using SSH tunnels to your application instead of OpenVPN, will remove one encryption layer and will also help speed wise.

I've replied to your question because I find it interesting but have in mind that if you don't accept your answers (the 17% accept rate indicates that), the community will be a lot less willing to help you out, this site is all about community and that accept rate is showing you as a not community player, which will hinder your results in the future.

Just take it as my 2¢, no criticisim!

lynxman
  • 9,397
  • 3
  • 25
  • 28
  • 1
    What!?!?! do you really believe that crypto makes data 40% bigger? that's _so_ wrong! – Javier Jan 24 '11 at 18:47
  • IT is not a believe Javier, it's based on real bandwidth usage calculations that need to be done in order to expense a new line to the datancenter ;) – lynxman Jan 24 '11 at 18:51
  • Lynxman, how to have crypto signatures of 1024 bytes. I already have dh dh1024.pem. Is it what you are referring to? – nixnotwin Jan 25 '11 at 03:51
  • Yeah nixnotwin, exactly, 1024 bytes signatures will result in a smaller footprint – lynxman Jan 25 '11 at 08:04
  • 1
    public keys only get sent periodically with SSH and OpenVPN, so your 128 bytes of savings (1024 vs 2048) is mostly speculation. Agreed with Javier, encryption adds very little in payload size. Try it.. 'gpg --compress-algo none -c /etc/hosts' .. mine only grew from 340 bytes to 382 bytes. 12%, and thats likely because it was small and so didn't fit well in the blocks of CAST5. – SpamapS Jan 26 '11 at 09:45
0

I had kind of the same problem. But the strange thing was that it worked fine to connect to the vpn-server through Tunnelblick on my macbook, but it was damn slow from ubuntu.

I did change from tcp to udp, and then it worked fine again. Except from Netbeans, which is still slow.

Arlukin
  • 1,203
  • 6
  • 18
  • 27