On 01/10/2019 14:50, Jan Just Keijser wrote: > Hi there, > > On 24/09/19 08:40, free...@tango.lu wrote: >> Hello List, >> >> Inconsistency is really pissing me off and I want to understand the root >> cause. I have a dual xeon server on gigabit running OpenVPN 2.2.1 (sorry for >> the old version I will not upgrade, this working since many years). >> >> As clients I use mini computers such as Raspberry pi 2-3s with >> 2.3.4-5+deb8u2. >> >> Normally copying file with FTP inside the tunnel yields 1.35 MB/s >> >> 1.35 MB = 10.8 Mbit >> >> That is about 10 Mbit downlink which is not great (compared to that the vDSL >> should have theoretically 100Mbit/s) but it still acceptable. >> >> The clients behind DSL routers so after experimenting I have settled on >> tun-mtu 1350 for the tunnel. >> >> Now the point is not even all this but sometimes this tunnel starts behaving >> crazy slow with packet loss, transfer speed around 100kbit/s without ANY >> config modification. The configs and openvpns are the same since years and I >> would like to understand WHY. >> >> When this slowness occurred yesterday I have run speedtest-clis on both ends >> to see if it might be the internet connection which was slowed down, no it >> wasn't which is from the client: >> >> Testing download speed........................................ >> Download: 70.61 Mbits/s >> Testing upload speed.................................................. >> Upload: 27.86 Mbits/s >> >> On the server I get dual gbit up and down so there is no prob there. >> >> When you download file through the tunnel from the server that uses the >> download which is more than enough so why can the tunnel be stalled? >> >> I use UDP for the tunnel. >> >> Any clues? Any workarounds? now because of this I ordered a raspberry pi 4 >> just to be able to fix this as soon as possible and by morning it went back >> to normal without ANY changes. Very annoying! >> > > of course, Gert's comment about 2.2.1 being antique is fully valid. Let's > say you/we could pin this down to being a bug in the OpenVPN 2.2 code base, > then there would never be a new 2.2 release. Having said that: in my > experience, most cases where a tunnel slows down over time are related to key > renegotiation. You could try turning off key reneg (== insecure) or you could > *shorten* the key reneg interval to see if the problem pops up more often - at > least then you will know. > > Finally, without config files it is impossible to tell what is going on; my > bet is that switching to a stronger cipher > cipher aes-256-cbc > auth sha256
Strictly speaking, 'auth sha1' is more than adequate for HMAC operations. And it saves you a few more bytes in the overhead compared to SHA256. In fact even MD5 is considered reasonable when used in HMAC operations [1] but that's a message hard for people to fully grasp - due to the "MD5 is broken beyond repair" campaigns (and MD5 _itself_ is broken indeed). This is all to HMAC needing a shared secret being part of the hashing operation - and hash collisions does not affect the security of HMAC. Naturally, AES-*-GCM is the best alternative, with the lowest overhead and generally much better performance - especially on hardware with AES instructions in the CPU ... but that requires OpenVPN 2.4 or newer. So, yet another reason to upgrade. [1] <https://en.wikipedia.org/wiki/HMAC#Security> -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
