Remote Desktop Disconnecting

evolvetechllc

I've tried searching these forums and not found a related topic, but forgive me if this has been asked before.

I'm running OpenVPN AS using the VMware Player appliance, which I've setup at home to test with. I've got it all setup and running generally without issue. I can connect remotely (from work), ping machines on the server side, share files, etc. However, if I Remote Desktop into the computer VMware Player is running on, I can connect and login, but the RD session swiftly drops. If I turn around and use VNC, I have ZERO problems whatsoever. If I'm at home I can RD into the same machine with no problems.

I'm setup with routing. Firewall is disabled on the server (I've also tried just opening the ports).
Should client Internet traffic be routed through the VPN? YES
Do not alter clients' DNS server settings is selected.
Select OSI layer for VPN tunneling: Layer 3

If there are any other settings that might be of interest I'd be happy to supply them.

I'm very new to this, so please bear with me.

swg0101

When in doubt, use Wireshark. :lol:

jmartin

Did you ever find a solution to this problem? I'm having a similar issue. I have a newly setup network with a pfsense box portforwarding connections to my openvpn access server on the lan, everything appears to be setup and working properly, I can connect to all lan resources from a vpn client. I can ping, ftp, ssh, etc to the lan with no issues but when I use remote desktop its hit and miss. Remote Desktop will work for awhile and then the screen stop refreshing or I get disconnected. I'm not sure if it's a problem with the pfsense firewall or openvpn access server.

pese

jmartin wroteDid you ever find a solution to this problem? I'm having a similar issue. I have a newly setup network with a pfsense box portforwarding connections to my openvpn access server on the lan, everything appears to be setup and working properly, I can connect to all lan resources from a vpn client. I can ping, ftp, ssh, etc to the lan with no issues but when I use remote desktop its hit and miss. Remote Desktop will work for awhile and then the screen stop refreshing or I get disconnected. I'm not sure if it's a problem with the pfsense firewall or openvpn access server.

any new infos about this topic? i've the same isuue....
thanks

sconsulting

I am experiencing the same. Any updates?

The Johan

From reports from other users, we have found that the firewall settings in pfsense could actually be blocking the connection, killing it at some point.

Also try checking the MTU settings:

http://www.dslreports.com/faq/5793

WireShark is indeed a good program to check programs. If packets are too large and get fragmented, this will screw with the OpenVPN connection.

sconsulting

Thanks for your reply. In my case the following constellation exists:

We have a OpenVPN Access Server (Version 1.8.4 - licensed for 10 Users) behind a Zyxel USG-100 Firewall which forwards the OpenVPN UDP Packets (Port 1194) to a Microsoft Isa Server 2004 which forwards the UDP Packets to the actual OpenVPN Access Server. There are two external locations (Centos Boxes w/ standard OpenVPN client) constantly connected to this OpenVPN Access Server (VMware Appliance). In the server and client config I have added the keepalive 10 20 directive. Everything works great through the VPN link (mostly DNS, Outlook/Exchange and HTTP(s) connections) except the following RDP related issue which can be reproduced as follows:

Whenever the OpenVPN Access Server's WAN link gets rebooted (either ISA Server or Zyxel Firewall) both OpenVPN clients successfully re-establish the link according to the keepalive directive. However, as soon as you try to establish an RDP connection from one of the clients, the VPN connection gets cut until the client re-establishes the connection after 20 seconds. The only solution is then to manually restart the OpenVPN service, which solves the issue until the Zyxel Firewall or ISA Server gets rebooted again.

After further studying the OpenVPN manual I found the mssfix 1400 directive which I have added just now to the server config. I'll do some trials in the coming days and will post the results here.

The Johan

There are too many possible issues in the setup you have that could cause your problems for me to make a sensible comment on, sorry. Yes, try mssfix 1400, and run WireShark and tcpdump to find out what errors are reported, and by which device exactly.

Please note also that VMWare Player is an interesting application but our experience has shown that there are some unexplained problems with OpenVPN in combination with VMWare Player that we haven't been able to nail down, but have something to do with the networking implementation in VMWare Player. We're not quite convinced here that it's a suitable solution for production.

sconsulting

Thank you very much for your feedback. Yes, I am aware that there are many factors in this setup but at the moment it cannot be changed so easily. The appliance is used on a VSphere ESXI 5 host, I am not sure whether this makes any difference to VMware Player but moving to a physical box will be the next step if the mssfix 1400 directive won't help.

The Johan

Oh, I am sorry. Perhaps I misunderstood then.

No, VMWare ESXi 5 is a perfect solution for Access Server in routed mode. On bridged mode only promiscuous needs to be allowed on the virtual switch, but you are using routed mode, so no problem there.

sconsulting

No problem, I didn't mention which VMware product we're using :-) Let's see how it goes w/ the mssfix directive. If I understood the manual correctly, it is sufficient to add it only in the server config?

sconsulting

The mssfix 1400 in the server config didn't help, however, I've discovered the following in the log:

disconnected because user-specific properties prevent concurrent VPN connections by this user

this happens as soon as I start an RDP connection.

sconsulting

We're still facing this issue, the mssfix 1400 directive didn't help. However, the problem seems to be in general with encrypted connections over the VPN link, I am also experiencing this issue with Outlook -> Exchange and HTTPS connections.

Whenever this happens, it looks like that for some reason the VPN client establishes a second connection (screenshot):
https://docs.google.com/file/d/0B1sm5WQnAgofZzlUak1FbzI3Qms/edit?usp=sharing

According to the log, the connection gets disconnected due to multiple logins:

disconnected because user-specific properties prevent concurrent VPN connections by this user

See screenshot
https://docs.google.com/file/d/0B1sm5WQnAgofdmE4WGFzYldJbGM/edit?usp=sharing

I've then added the duplicate-cn directive to the server config but that didn't help neither. Later I found that under Advanced VPN Settings there is a check-mark already under Multiple Sessions per User.

As stated before this only happens when:

1. The connection between client and server gets temporarily disconnected (e.g Router reboot) and
2. The connection gets re-established by the client itself (using the keepalive directive)

If I restart the Openvpn service manually on the client (/etc/init.d/openvpn restart) then everything is fine again, at least until the next router reboot. Instead of using keepalive, is there is a possibility to restart the Openvpn service automatically when there is no ping anymore to the server?

Thanks for any help.

The Johan

Right, the message "disconnected because user-specific properties prevent concurrent VPN connections by this user" means exactly that - there are properties in the user that prevents multiple concurrent sessions. Almost anything you set in the Access Server's section User Permissions for that user will cause that. Unfortunately VPN gateway is one of those options. That is because routes must be set up on the Access Server to route to the subnets behind the client. Having multiple clients connected with the same subnets and same routes would cause collissions in routing and subnetting and therefore the Access Server will not allow this. So multiple concurrent connections on a VPN gateway user simply cannot work.

What I suspect is happening is that for some unexplained reason the OpenVPN process on the client side gets completely hung up. Normally when a connection gets interrupted uncleanly, the client side will attempt to reconnect to the server. The server may yet be waiting for a response on the original connection before dropping it. But during that time it will see the reconnect attempt as a new second connection and treat it as such. And that's why you see the "disconnected because user-specific properties prevent concurrent VPN connections by this user" message because that user cannot be connected twice. It should then retry, and when the first connection drops off at the server end then the client should reconnect.

By the way, you speak of directives and adding it to the config and such. Are you manually editing the configuration files? Because if so, could you try just using the stock 'autologin' profile that you can download at the Access Server's client web server interface? It should be preconfigured to the proper settings.

Can you take a look on your client side next time and see if, after the connection breaks, there is a second tun interface? With only 1 openvpn connection it should have only tun0. But if there is a tun1, then it seems the openvpn process is getting hung up in some quite unique way.

sconsulting

Thank you very much for your reply. I will do some further tests on the client side and will let you know about the result.

sconsulting

There seems to be definitely something wrong with the tun interfaces. I have two tun interfaces (tun0 and tun1) and strangely they don't get closed after shutting down the OpenVPN client. Even after removing the OpenVPN package the tun interfaces are still listed under ifconfig. Is there any way I can remove them?

sconsulting

I completely uninstalled and reinstalled OpenVPN on the client and it seems that the tun interface is now fine, it only comes up when OpenVPN establishes a connection. However, the problem remains. I've checked and there is no second tun interface after the disconnect happens but I've noticed that something goes wrong with the encryption when the disconnect happens, every time I get the following error message in the client's log files:

May 29 17:36:15 localhost openvpn[18290]: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #404 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
May 29 17:36:16 localhost openvpn[18290]: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #405 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
May 29 17:36:17 localhost openvpn[18290]: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #406 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
May 29 17:36:18 localhost openvpn[18290]: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #407 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
May 29 17:36:19 localhost openvpn[18290]: [OpenVPN_Server] Inactivity timeout (--ping-restart), restarting
May 29 17:36:19 localhost openvpn[18290]: TCP/UDP: Closing socket

sconsulting

I was able to fix the issue, the client had OpenVPN 2.2.2-1 installed. I've now upgraded to OpenVPN Version 2.3.1-1 and so far so good 😃 To verify this I rebooted the routers between the VPN tunnel several times and after the client re-connected I had no more disconnects when using RDP or HTTPS.

lhooten

I know this is an old forum, but I had the issue as well and wanted to say the solution for my client was indeed allowing duplicate connections on the router (we use OPNSense, but relatively same as PF). The client had a session running 24/7 at home that we didn't know about. By allowing duplicate connections, the RDP session stopped timing out and all worked.

Thank you to the poster above who suggested this!