OpenVPN client drops connection when user needs to use it

dr_deo

Hi all,

Open VPN software on client and on the server side is the latest version downloaded from openvpn.net

Server (installed on CentOS 6.5) Note, i'm using TCP protocol, not UDP.

#server
port 1723
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.10.1.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.10.1.0 255.255.255.0"
client-config-dir ccd
route 10.10.10.0 255.255.255.0
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 4.4.4.4"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

I have a number of clients connecting to it from various OS, all 64bit:

from Linux - OK, no issues
from MacOS - OK, no issues
from Windows 8.1 - OK, no issues
from Windows 8 - OK, no issues
from Win 7 Ultimate - some clients are OK, NO issues, but i have a number of issues with the others.
I will post the biggest issue here as all of them are different.

the client config is the same for all windows clients except for certificates.

#client
client
dev tun
proto tcp
remote myserver 1723
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
verb 3

Problem: when client connects to OpenVPN, connection is setup and can stay connected for unlimited time. It is also possible to PING servers available via VPN.
However, as soon as you attempt to connect to any of servers using any connection that requeres TCP (RDP, for example), Open VPN client immediately drops VPN connection.
Now, as soon as you stop connection attempt, it re-establish VPN connection and you are able to PING again 🙂
I can confirm Firewall and Anivirus software was turned off when tests were made. Actually it makes no difference with those being set ON.

Thu Jul 03 17:51:47 2014 Initialization Sequence Completed
Thu Jul 03 17:51:47 2014 MANAGEMENT: >STATE:1404395507,CONNECTED,SUCCESS,10.10.3.14,myserver
Thu Jul 03 17:52:04 2014 write TCPv4_CLIENT: Connection reset by peer (WSAECONNRESET) (code=10054)
Thu Jul 03 17:52:04 2014 read TCPv4_CLIENT: Connection timed out (WSAETIMEDOUT) (code=10060)
Thu Jul 03 17:52:04 2014 Connection reset, restarting [-1]
Thu Jul 03 17:52:04 2014 SIGUSR1[soft,connection-reset] received, process restarting
Thu Jul 03 17:52:04 2014 MANAGEMENT: >STATE:1404395524,RECONNECTING,connection-reset,,
Thu Jul 03 17:52:04 2014 Restart pause, 5 second(s)

this is happening immediately after you start connecting to RDP, so i do not think timout has anything to do with it.
on the server side, i see that client has disconnected (can't post log rigth now, but can do later if need be).

Any help is greatly appreciated.

dr_deo

debbie10t

Thanks for the reply. I did played with MTU before posting this with no success.
The reason i'm using TCP is because UDP does not seem to be working for me: most of the clients need to use RDP over that VPN and it times out during connection attempt for most of the servers they need to access, when UDP is used.
TCP is working great, but i have problems with just 3 clients that i need to sort out. The biggest one is the one i outlined. I'll check if it will be possible to use another modem.

thanks.

dr_deo

debbie10t

I'm not saying UDP does not work at all. It does work, BUT: 1. servers are randomliy not accessable due to timeouts when RDP connection is setup, which is really annoying and 2. RDP insists on using low colours mode ALWAYS, which is a problem for GUI designers.
With TCP being used, RDP never times out and uses highest colour mode available.
I have never bothered getting to a bottom of the problems with UDP as TCP sorted all of the issues. I believe, there should be a solution for those client i have problems with. I will try to ge him using anothe internet connection (if possible) after week-end.

thanks.

dr_deo

issue has been solved by updating router's firmware for the affected client and installing pending updates on the OS. No idea which of these two steps have done the trick, but it now works.

thanks.