Server 2.4.4 on Ubuntu 16.04 - client speed problems Win7

BobAGI

I have just created an OpenVPN 2.4.4 server at home using Ubuntu Server 16.04-3LTS on a PC as the platform.
It is configured as I usually do and in my tests (using an Android phone) I get very good performance with speeds limited only by the mobile network and when using WiFi by the test router (only capable of 50 Mbit/s).
I also checked here at home with another Win7 laptop connected to the test router by Ethernet cable and then I got 70 Mb/s down and 75 Mb/s up, so the server must be working OK.
In case you wonder:
My main Asus router is connected to a fiber box and my test router (old TP-Link) is also connected to this fiber box on another Ethernet port so they have different WAN addresses. This makes it possible to test the system except for the full speed since the TP-Link is old so it has 100 Mbit Ethernet only and my fiber is at 250 Mbit/s.

This OpenVPN server is going to be used by my brother-in-law, who is currently abroad, in order to access the Swedish sports channels during the Olympics.
Yesterday night when he tested it using his iPad at his temporary home he got a transfer speed of 91 Mb/s download and 60 Mb/s upload.
The server side logs show that all is OK.

But when he next tested with his laptop (running Windows 7) he got a dismal 3 Mb/s download but 68 Mb/s upload.
Without the VPN tunnel he is getting close to 100 Mb/s both ways.

So "something" is not working correctly for downloading, I assume. But what?
I looked in the logs for his laptop attempts (I asked him to send his client log) and this is what I found:
Server log:

Thu Feb  1 07:52:01 2018 us=395383 93.122.xxx.xx:59873 [HakanUbu] Peer Connection Initiated with [AF_INET]93.122.xx.xx:59873
Thu Feb  1 07:52:01 2018 us=395454 HakanUbu/93.122.xxx.xx:59873 MULTI_sva: pool returned IPv4=10.8.0.3, IPv6=(Not enabled)
Thu Feb  1 07:52:01 2018 us=395571 HakanUbu/93.122.xxx.xx:59873 MULTI: Learn: 10.8.0.3 -> HakanUbu/93.122.xxx.xx:59873
Thu Feb  1 07:52:01 2018 us=395604 HakanUbu/93.122.xxx.xx:59873 MULTI: primary virtual IP for HakanUbu/93.122.xxx.xx:59873: 10.8.0.3
Thu Feb  1 07:52:02 2018 us=641069 HakanUbu/93.122.xxx.xx:59873 PUSH: Received control message: 'PUSH_REQUEST'
Thu Feb  1 07:52:02 2018 us=641253 HakanUbu/93.122.xxx.xx:59873 SENT CONTROL [HakanUbu]: 'PUSH_REPLY,route 192.168.119.0 255.255.255.0,redirect-gateway def1 bypass-dhcp,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.3 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Thu Feb  1 07:52:02 2018 us=641299 HakanUbu/93.122.xxx.xx:59873 Data Channel: using negotiated cipher 'AES-256-GCM'
Thu Feb  1 07:52:02 2018 us=641345 HakanUbu/93.122.xxx.xx:59873 Data Channel MTU parms [ L:1550 D:1450 EF:50 EB:406 ET:0 EL:3 ]
Thu Feb  1 07:52:02 2018 us=641695 HakanUbu/93.122.xxx.xx:59873 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Feb  1 07:52:02 2018 us=641733 HakanUbu/93.122.xxx.xx:59873 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Feb  1 07:52:02 2018 us=872911 HakanUbu/93.122.xxx.xx:59873 MULTI: bad source address from client [::], packet dropped
Thu Feb  1 07:56:06 2018 us=951176 HakanUbu/93.122.xxx.xx:59873 [HakanUbu] Inactivity timeout (--ping-restart), restarting
Thu Feb  1 07:56:06 2018 us=951283 HakanUbu/93.122.xxx.xx:59873 SIGUSR1[soft,ping-restart] received, client-instance restarting

Look at the 3rd last line (MULTI: bad source address from client [::]) where it looks like some IPv6 transaction is happening!
The client side log looks like this (there is a 1 hour time difference between our locations):

Thu Feb 01 08:52:00 2018 OpenVPN 2.4.4 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Sep 26 2017
Thu Feb 01 08:52:00 2018 Windows version 6.1 (Windows 7) 64bit
Thu Feb 01 08:52:00 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.10
Enter Management Password:
Thu Feb 01 08:52:01 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]81.170.xxx.xxx:1191
Thu Feb 01 08:52:01 2018 UDP link local: (not bound)
Thu Feb 01 08:52:01 2018 UDP link remote: [AF_INET]81.170.xxx.xxx:1191
Thu Feb 01 08:52:01 2018 [BosseOVPN] Peer Connection Initiated with [AF_INET]81.170.xxx.xxx:1191
Thu Feb 01 08:52:02 2018 open_tun
Thu Feb 01 08:52:02 2018 TAP-WIN32 device [Local Area Connection 3] opened: \\.\Global\{B76189C6-EC04-4A83-B7EE-01CCA9B5F0BB}.tap
Thu Feb 01 08:52:02 2018 Set TAP-Windows TUN subnet mode network/local/netmask = 10.8.0.0/10.8.0.3/255.255.255.0 [SUCCEEDED]
Thu Feb 01 08:52:02 2018 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.3/255.255.255.0 on interface {B76189C6-EC04-4A83-B7EE-01CCA9B5F0BB} [DHCP-serv: 10.8.0.254, lease-time: 31536000]
Thu Feb 01 08:52:02 2018 Successful ARP Flush on interface [27] {B76189C6-EC04-4A83-B7EE-01CCA9B5F0BB}
Thu Feb 01 08:52:02 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Thu Feb 01 08:52:07 2018 Initialization Sequence Completed
Thu Feb 01 08:54:09 2018 SIGTERM[hard,] received, process exiting

So what I wonder is if there is some setting I can apply either in the server conf file or in the client ovpn file to make the Win7 PC perform the same as the iPad does? It seems ridiculously strange that there should be such a big difference in performance!
And I have disabled IPv6 completely on the Ubuntu server via /etc/sysctl.d/99-sysctl.conf!
IPv6 should not be used at all.....

For completeness here are the server and client configs:
port 1191
proto udp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key # This file should be kept secret
dh /etc/openvpn/keys/dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0 'nopool'
ifconfig-pool 10.8.0.2 10.8.0.127 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.119.0 255.255.255.0"
push "redirect-gateway def1 bypass-dhcp"
keepalive 10 120
tls-auth /etc/openvpn/keys/ta.key 0 # This file is secret
cipher AES-256-CBC
comp-lzo
max-clients 20
#user openvpn
#group nogroup
persist-key
persist-tun
status /etc/openvpn/log/openvpn-status.log
log /etc/openvpn/log/openvpn.log
verb 4
mute 10
explicit-exit-notify 1

And here is the client ovpn file with certificates and keys removed:
client
dev tun
proto udp
remote home.xxxxxxxxx.com 1191
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
auth-nocache
remote-cert-tls server
key-direction 1
cipher AES-256-CBC
comp-lzo
verb 1
mute 20

TinCanTech

BobAGI wrote MULTI: bad source address from client [::])

You can ignore this or disable IPv6 on the client.

BobAGI wrote [HakanUbu] Inactivity timeout (--ping-restart), restarting

Push explicit-exit-notify to the client as well.

BobAGI wrote when he next tested with his laptop (running Windows 7) he got a dismal 3 Mb/s download but 68 Mb/s upload

Sorry .. no idea what would cause that. Try from a different location with different internet provider.

BobAGI

TinCanTech wrote
BobAGI wrote MULTI: bad source address from client [::])
You can ignore this or disable IPv6 on the client.

I cannot do that unless there is a server push command that can tell the client to only use IPv4...

BobAGI wrote [HakanUbu] Inactivity timeout (--ping-restart), restarting
Push explicit-exit-notify to the client as well.

But that is done, see line 25 of the server.conf...
Hmm, is this really a pushable option? Maybe you are supposed to enter this in the client's ovpn file too??

BobAGI wrote when he next tested with his laptop (running Windows 7) he got a dismal 3 Mb/s download but 68 Mb/s upload
Sorry .. no idea what would cause that. Try from a different location with different internet provider.

The thing is that this only affect the performance with speedtest.net in the case where he has connected VPN.
With VPN disconnected it works in full speed....
Well, we have to test again when he is back home in a couple of hours, would be nice to have some suggested actions to take to improve speed.
I now know after my tests here that the server is not throttling at least.

TinCanTech

BobAGI wrote
TinCanTech wrote
BobAGI wrote MULTI: bad source address from client [::])
You can ignore this or disable IPv6 on the client.
I cannot do that unless there is a server push command that can tell the client to only use IPv4...

Then just ignore it ..

BobAGI wrote
TinCanTech wrote
BobAGI wrote [HakanUbu] Inactivity timeout (--ping-restart), restarting
Push explicit-exit-notify to the client as well.
But that is done, see line 25 of the server.conf...
Hmm, is this really a pushable option? Maybe you are supposed to enter this in the client's ovpn file too??

Look again .. it is not being pushed so push it aswell .. or add it to the client either way works.

BobAGI

So you mean adding this to the server.conf file:

push "explicit-exit-notify 1"

Is that legal?
It would make it less problematic because it will not need any editing by the client who has already received his ovpn file...
Just an edit of the server.conf file plus a restart of openvpn.

BobAGI

And does it matter where in the server.conf file it appears?
Can I append it last in the file?

EDIT:
I added it last in the server side file and then restarted openvpn server.
On connection from my phone I could see this in the server log:

Fri Feb  2 11:23:13 2018 us=589856 BosseUbu/85.24.xxx.xxx:50033 SENT CONTROL [BosseUbu]: 'PUSH_REPLY,route 192.168.xxx.0 255.255.255.0,redirect-gateway def1 bypass-dhcp,explicit-exit-notify 1,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)

and on the client log (impossible to transfer here) I could see that the option was listed among the accepted pushed options.
Finally I also saw this in the log when I disconnected the phone:

Fri Feb  2 11:27:47 2018 us=813741 BosseUbu/85.24.202.216:50033 SIGTERM[soft,remote-exit] received, client-instance exiting

So I guess that part is at least solved.

Pippin

Hi,

Find in the client log:

Socket Buffers: R=[212992->425984] S=[212992->425984]

Then play with

push sndbuf xxxxxx
push rcvbuf xxxxxx

in client ccd file for just that client,
or globally for all clients in server config file and see if it improves.
You can also put it in client config without push.
xxxxxx can for instance be between 131072 (128k) and 524288 (512k)
See --sndbuf and --rcvbuf in manual 2.4:
https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage

BobAGI

I cannot find the mentioned line in the client log on Android....
So I simply added the following to the server.conf at the bottom and restarted openvpn.

#Testing to use larger buffers for tunnel
push "sndbuf 262144"
push "rcvbuf 262144"

On my phone I can see this being pushed to the client at least, if it helps is not known yet because I have to ask my brother-in-law to connect and do the speed tests.
He has two devices, one a Win7 laptop and the other an iPad, both connected to his local LAN via WiFi.
We'll see.

While I ask, is it advised to push DNC when using the tunnel for all traffic?
If so should I push the local DNC on the server's LAN (i.e. 192.168.xxx.1) or should I push the OpenDNS or GoogleDNS addresses?
My home LAN uses the gateway (...1) as DNC server and it is itself configured for external server at OpenDNS.

Pippin

I cannot find the mentioned line in the client log on Android

Try

verb 4

in it`s config.

Routing DNS over the tunnel, it depends.
For instance, when connecting from public hotspots it is desirable to send all traffic down the tunnel.
Or ISP logging/selling/blocking etc.

Personally I send all traffic over the tunnel, no matter what.
On the server I run a DNS server (BIND) with Pi-Hole ad-block, that is being pushed to clients.
From there I forward to Quad9 DNS, 9.9.9.9 and 149.112.112.112, which is a free malicious domain block service.
Quad9 also supports DNS-over-TLS, maybe in future I will try that too.

BobAGI

OK,
just to clarify if I understand this correctly:
1) If I push a DNS server then it is used by the client.
2) If I do not push a DNS server then the fallback is Google's server, which will be set on the client.
But in both cases any call to the DNS server must go through the tunnel, right?
Is there any situation when the OpenVPN tunnel is connected and the redirect is pushed when the client talks on the side of the tunnel to the DNS server????