Connected client blocks after Windows 10 opens new connection

[Puzovic]

When a new client with Windows 10 Home connects to the server using OpenVPN GUI all existing clients that are connected to the server blocks temporarily (it usually last for about 5 minutes). If in that period already connected clients try to reconnect to the server the error message "TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)" is reported. They successfully reconnect after about 5 minutes.

This only happens with Windows 10 Home as client. All other versions of Windows including Windows 10 Enterprise do not block already connected clients.

It looks like that after client with Windows 10 Home has connected it doesn't immediately releases port or somehow hogs the virtual network?

[Gert Döring]

server log?

[Puzovic]

Once mp6 machine that is Win10 inititate connection the message outgoing TUN queue full is reported. Other two machines pro and mp4 that are Win7 are reporting the same error. Log is in attachment.

[Puzovic]

Replying to cron2:

server log?

Wed Jun 08 06:43:21 2016 mp6/13.13.13.177:50185 MULTI_sva: pool returned IPv4=127.0.0.11, IPv6=(Not enabled)
Wed Jun 08 06:43:24 2016 mp6/13.13.13.177:50185 send_push_reply(): safe_cap=940
Wed Jun 08 06:43:25 2016 mp6/13.13.13.177:50185 MULTI: Outgoing TUN queue full, dropped packet len=183
Wed Jun 08 06:43:25 2016 TCP connection established with [AF_INET]14.14.14.19:50413
Wed Jun 08 06:43:26 2016 pro/11.11.11.229:17351 MULTI: Outgoing TUN queue full, dropped packet len=92
Wed Jun 08 06:43:27 2016 mp6/13.13.13.177:50185 MULTI: Outgoing TUN queue full, dropped packet len=169

[Gert Döring]

do not use 127.0.0.x for your pool range, this is special address space and might trigger interesting misbehaviour here (and from the looks it seems as if it causes some sort of loop/overload on the Win10 machine).

[Puzovic]

Replying to cron2:

do not use 127.0.0.x for your pool range, this is special address space and might trigger interesting misbehaviour here (and from the looks it seems as if it causes some sort of loop/overload on the Win10 machine).

I have set it for the pool range to be 192.168.150.x but still getting the same error. Below is short log (I have tried attaching log file to the ticket but was getting trac error index out of range). Should I use some other pool range other than 127.0.0.x and 192.168.150.x?

Fri Jun 10 10:15:33 2016 mp6/13.13.13.177:50185 MULTI_sva: pool returned IPv4=192.168.150.11, IPv6=(Not enabled)
Fri Jun 10 10:15:36 2016 mp6/13.13.13.177:50185 send_push_reply(): safe_cap=940
Fri Jun 10 10:15:37 2016 mp6/13.13.13.177:50185 MULTI: Outgoing TUN queue full, dropped packet len=183
Fri Jun 10 10:15:37 2016 TCP connection established with [AF_INET]14.14.14.19:50413
Fri Jun 10 10:15:39 2016 pro/11.11.11.229:17351 MULTI: Outgoing TUN queue full, dropped packet len=92
Fri Jun 10 10:15:39 2016 mp6/13.13.13.177:50185 MULTI: Outgoing TUN queue full, dropped packet len=169

[Gert Döring]

ok, so it was not 127.0.0.x - how unfortunate, that would have been an easy answer :)

Nevertheless, it seems the Win10 box is doing something funky on connecting, filling up all the bandwidth between openvpn process and server side tun with packets (which then drowns up bandwidth for everyone else).

Can you run "tcpdump -n -s0 -i tun0" (or tunX, whatever the interface is) on the server, and then have the win10 machine connect? I'm very curious what that traffic might be.

[Puzovic]

traffic on TUN from win10 home

[Puzovic]

Replying to cron2:

Can you run "tcpdump -n -s0 -i tun0" (or tunX, whatever the interface is) on the server, and then have the win10 machine connect? I'm very curious what that traffic might be.

I have attached the out.pcap file that is traffic from win10 home machine. The server is on windows 7 machine so I had to use wireshak's dumpcap command to listen to the traffic. I hope that is fine. What I have noticed when comparing with win10 enterprise is that there is a "multicast listener report message" and lots of "Standard query" messages.

I also have logs with win10 enterprise that works fine and also logs when win10 home initiate connection and then win10 enterprise immediately afterwards.

[Selva Nair]

Replying to Puzovic:

Replying to cron2:

do not use 127.0.0.x for your pool range, this is special address space and might trigger interesting misbehaviour here (and from the looks it seems as if it causes some sort of loop/overload on the Win10 machine).

I have set it for the pool range to be 192.168.150.x but still getting the same error. Below is short log (I have tried attaching log file to the ticket but was getting trac error index out of range). Should I use some other pool range other than 127.0.0.x and 192.168.150.x?

I thought the 127.0.0.11 in the original log was a masked address or a joke.. If you were originally using a pool in the loopback block (127.0.0.0/8), none of the clients would have worked. Even windows, no matter how hard MS breaks standrads, won't route anything meant for 127.0.0.0/8 out of the host. I think it won't even allow you to set such an ip to tun/tap. Linux will allow tun to be assigned such an address but will still (correctly) loopback all packets sent to it instead routing to the tun. I suspect the setup never worked, so not clear what was meant by the original post that referred to connected clients other than win10.

Could you please post your server config?

When you say the new pool is 192.168.150.x what is that x? The pool has just one IP number?

[Puzovic]

server config file

[Puzovic]

Replying to selvanair:

Could you please post your server config?

When you say the new pool is 192.168.150.x what is that x? The pool has just one IP number?

I have just attached the config file. The name of the file is server.ovpn. The pool is 192.168.150.1

[Gert Döring]

Have looked at the log file - while the amount of windows "I want to tell the world about me, and my friends!" blabbering is amazing (UDP/137 is windows naming, UDP/5355 is mDNS) it should not hog the server for full *5 minutes* - are the "queue full" messages continueing for all these 5 minutes?

Random idea out of the blue: I see you use "dev tap", which is generally not a really good idea unless required (for example in a bridged setup). You could try changing to "dev tun" (on both client and server side), which might make this go away.

[Puzovic]

Replying to cron2:

Random idea out of the blue: I see you use "dev tap", which is generally not a really good idea unless required (for example in a bridged setup). You could try changing to "dev tun" (on both client and server side), which might make this go away.

By replacing "dev tap" with "dev tun" the problem went away.

Thank you very much for your help.

[David Sommerseth]

Closing as it seems to be related to a very busy network with lots of broadcast traffic overloading either the TAP driver or Windows network stack. This isn't an issue which have appeared often anyhow. If it appears again, we can consider to re-open this issue.

As in most cases, switching to TUN mode instead of TAP resolved this issue. Which is not so odd, as the often not needed broadcast noise is not saturating the VPN's TUN/TAP device.