Tunnelblick connects ok - ping ok - but any other traffic is VERY slow (a few kb/s at most)

[gde...@gmail.com]

Hi all,

I have an OpenVPN server that has been running for years without any major problem, but for one client (and so far one only) the connection is almost unusable.
As said in the subject, Tunnelblick can connect, but the bandwidth is awful ! (regular tcp connection to the same server without the VPN is about 1 MB/s).

OSX was Yosemite, but client has since upgraded to Sierra and it did not change anything
Tunnelblick version is 3.7.1

Most clients are using OSX Sierra and a recent version of Tunnelblick (and things are working very well for them).

I can ping the server from the client, and the client from the server (no packet lost).

I tried moving to a TCP OpenVPN server on port 21 (to make sure there was no interference of the internet provider on port 1194) but that did not work any better.

Have you ever seen something like that (I am puzzled by the extremely low bandwidth) ?
Thanks for your help.

Guillaume

PS: I chose the tunnelblick group because this only concerns one mac cient so far - so I assume the problem lies on the client side (and could totally be a mac problem rather than a Tunnelblick problem, but I don't know where to start...)

Server configuration: the client-config-dir just assign a static ip, nothing fancy

port 1194

proto udp
dev tun
ca ***
cert ***
key ***
dh /etc/openvpn/keys/dh1024.pem
server 10.22.0.0 255.255.0.0
client-config-dir /etc/openvpn/ccd
keepalive 10 120
comp-lzo
max-clients 100
user nobody
group nobody
persist-key
persist-tun
push "route 10.10.1.0 255.255.255.0"

Client config

client
dev tun
proto udp
remote *** 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ***
cert ***
key ***
ns-cert-type server
comp-lzo

[Tunnelblick developer]

It's hard to see how Tunnelblick itself could be the problem: Tunnelblick uses OpenVPN to set up and run the VPN. An easy way to eliminate Tunnelblick itself as causing the problem would be to try to connect using Viscosity (a non-free GUI for OpenVPN).

Although OpenVPN could in theory be the problem (because everything in the tunnel passes through OpenVPN), the most likely cause is the OS, some third-party software, or something about the computer's connection to the Internet that is interfering with the connection.

[Guillaume dd]

I agree with you - and am suspecting something fishy with the OS / software installed but nothing came when I looked at the computer.
There is another VPN (native ipsec) configured, but it was not connected so I don't see how that could be the problem.
I will try Viscosity as you suggested.

Thanks
Guillaume

[Guillaume dd]

Same problem with Viscosity. I will try with another mac on the same network...

[sergey.sh...@gmail.com]

I am experiencing same problem connecting using TunnelBlick 3.7.5a to my company VPN network.

The transfer speed is about 10-30KB/s.

I have tried 2 Mac books with one being freshly installed to High Sierra 10.13.4. 

Thus, I experience same bahaviour on all my Mac Books.

Interestingly, it seems that that is only me in my company who is experiencing speed problems connecting to the VPN.

My colleagues on Windows and Linux do not experience the slow download speed. 

Some colleagues on Mac do NOT experience slow download speed.

But some of my colleagues on Mac experience the same slow speed as me as well.

The last Mac Book that I've tried has no software installed except tunnelblick.

I have also tried to use the .openvpn files from the colleagues who do not have speed problems with the speed on their Macs. Exact same config on my Mac causes very slow connection.

Best regards,

Sergey Shcherbakov

четверг, 15 июня 2017 г., 14:17:27 UTC+2 пользователь Guillaume dd написал:

[Tunnelblick developer]

As reported by Guillaume dd, this happens on Tunnelblick and on Viscosity, so it looks like an OpenVPN/OS/Internet connection problem, not a problem with Tunnelblick itself.

Sergey, if you haven't already, you should try one of the computers that works well on the network on which the computers that don't work well, so it uses the same Internet connection, and try one that works badly on a network where others work well. That could help eliminate the Internet connection as causing the problem.

You could also get help from some of the following OpenVPN references:

• OpenVPN FAQ

• OpenVPN HOWTO

• OpenVPN 2.3 Man Page

• OpenVPN Documentation

• OpenVPN Users Forum

• OpenVPN Users Mailing List

[Tunnelblick developer]

You might want to consider MTU issues. There is an OpenVPN Users Mailing List thread about this. The mailing list archive seems to be down at the moment, but here is an interesting post by Jan Just Keijser, one of the OpenVPN developers:

On 11/05/18 16:30, Kor Korrd wrote:

Hi,

I am struggling with MTU Problems with a lot of clients, which usually

results in unusable slow connections.

So I was thinking on how to solve the problem so that almost any client

can connect to my VPN regardless if their ISP has a reduced MTU.

After a lot of reading about this MTU topic and possible solutions with

OpenVPN, I was more confused than enlightened, because the possible

solutions vary and the documentation regarding MTU options is not

unambiguous.

Therefore I would like to ask you for some advice regarding MTU problems

and solutions and furthermore some comments on my solutions or if I made

some mistakes (e.g. calculating the MTUs).

Following on I will only give the OpenVPN options of relevance. The VPN

Server is reachable through IPv4+IPv6 and has also IPv4+IPv6 inside the

tunnel, so it is completely Dual-Stack.

proto udp6

server *some IPv4 net*

server-ipv6 *some IPv6 net*

Basically I came up with two solutions:

1. using a combination of

tun-mtu 1500

fragment 1300

mssfix

to let the the tunnel appear with a normal MTU even when the ISP can not

handle it and let OpenVPN fragment the packages so that they will fit

through the Internet connection.

 

this will work only with UDP connections, of course.

Other than that, this is the most widely used solution to the problem you're seeing

 

Or 2. make actually the tunnel smaller and let the operating-system

fragment the packets:

tun-mtu 1300

mssfix 1360

In a test with several different clients I found out, that the second

solution is about 10-20% faster than the first one but has a 30% longer

ping. I favourite the second solution for now, but I am not sure if my

mssfix value makes any sense.

Furthermore some clients report some speed/ping problems with both

solutions.

 

Actually, setting mssfix works only for TCP-based connections, so ping is not affected by mssfix; however, if you change the tun-mtu value then it is often useful to also adjust the fragment size (so something like 1300 or a little less for tun-mtu=1360). I am curious what your ping-speeds will be when you do that.