Jump to content

KES 11.4 - Network Threat Protection kills OpenVPN Tunnel when using Remote Desktop


Recommended Posts

Hello,

We are using KES11.4.0.233 for Windows and got the situation that the Network Threat Protection Module kills the OpenVPN connection under certain conditions. OpenVPN isn't even aware of it and still says it's connected but nothing goes through the VPN tunnel.

It consistently happens with all Systems from one remote branches and them all having 11.x.x.x. KES installed but also to some people working from home.

They dial in via OpenVPN and try to access virtual machines via RDP which are hosted on an older ESXi 5.1 machines. Newer ESXi hosts do not cause a problem when they try to access VMs hosted there 
It also only happens if they try to use Remote Desktop. They can access shares or the Webserver (:80) of these virtual machines just fine.  

 

If they use Remote Desktop they can login, but before the remote Desktop is even fully available (background might load, but Desktop Icons do not) they already get the “connection lost, trying to reconnect.” At that point the VPN tunnel is already inaccessible. If reconnecting to VPN and RDP is still doing it’s reconnect attempts, the tunnel will be made inaccessible momentarily as soon as rdp attempts to connect again.

 

I tried to replicate the issue on other systems but i failed to pinpoint it as of now.  I tried with different 11.x KES Versions, tried with newer and older OpenVPN Clients and different Windows 10 Versions 1709, 1803, 1909.


What also adds to the problem is that nothing gets logged in Kaspersky. So i didn't even know which module caused this behavior initially.

Network Threat Protection Module has very few Options for changing the behavior.

Any ways how i can further analyse this problem?

Link to comment
Share on other sites

Hello alexcad,

 

thank your for your reply. The  IPs of the company and the VPN network are already entered in Firewall → Available Networks, as local Networks however.  Furthermore is the Firewall Module not active in the current policy used and thus the settings cannot be modified (they are greyed out). Would they still affect functionality despite being greyed out and the firewall module disabled?

 

Link to comment
Share on other sites

I had mystic problems with OpenVPN (TAP) and Kaspersky 11 on Windows 10. The effect was “the first ping after VPN connection comes up goes through, then something becomes broken in the routing (looks like OS decides VPN route is not acceptable and tries to send packets over the default gateway), then usually some minutes of settling the things, then VPN works again (or does not)”. The most irritating thing was that this “came in suddenly” on W10 machines that did work OK before with the same OpenVPN client/setup. About 10% of my machines were affected; others built from the same base image were not.
Disabling Windows/Kaspersky firewall (either of them) did help… only until some time, when enabling of the firewall helped. I.e. what did actually help was some “change in firewall” in OS.
The only way to overcome the problem was… full Windows reinstall; seriously; I did not take this path-of-desperates for the last 8-10 years.

Link to comment
Share on other sites

  • 2 months later...

I have noticed this too. Remote Desktop to windows server 2019 will result black screen and kill OpenVpn tunnel. However very strange is that remote desktop to any windows server 2008 does not!

I have proven this openvpn tunnel killing behaviour with two windows server 2019.

What could cause this behaviour? Otherwise Openvpn seems to work with other services besides rdp I use

How can I tell Kaspersky dont touch OpenVPN operation in anyway, dont block any inbound nor outbound traffic through OpenVPN.  I have tried on disable all ssl certificate actions and allow anything to local port 1194. I added OpenVPNSrv.exe  to exceptions. What else should I disable? Is this relaved to false positive network thread analysis?

Link to comment
Share on other sites

I have noticed this too. Remote Desktop to windows server 2019 will result black screen and kill OpenVpn tunnel. However very strange is that remote desktop to any windows server 2008 does not!

I have proven this openvpn tunnel killing behaviour with two windows server 2019.

What could cause this behaviour? Otherwise Openvpn seems to work with other services besides rdp I use

How can I tell Kaspersky dont touch OpenVPN operation in anyway, dont block any inbound nor outbound traffic through OpenVPN.  I have tried on disable all ssl certificate actions and allow anything to local port 1194. I added OpenVPNSrv.exe  to exceptions. What else should I disable? Is this relaved to false positive network thread analysis?

 

I made further testing. Pausing Kaspersky will allow connection be opened and after connection is established (rdp session to Windows 2019 server) I can use that session even when Kaspersky is on. But when I sign out from rdp session that will kill also OpenVPN tunnel if Kaspersky is on.

So clearly there is something wrong with Kaspersky dealing with OpenVPN. This is very annoying to us bc Corona virus and remote working. Is there anybody looking into this issue at Kaspersky? We have 50 licenses from Kaspersky Cloud.

We did not have this problem with earlier Symantec Endpoint protection cloud.

Link to comment
Share on other sites

  • 3 months later...

What I noticed and now trying to get help for is that KIS blocks OpenVPN client to create static routes in Windows routing table, so your Windows/apps do not know how to reach your internal servers/resources because they are going outside via default gateway.
If KIS is disabled then route is added and Windows connects to  server/resources via OpenVPN.

Link to comment
Share on other sites

I’ve seen no (more) problems since switching to

dev tun
windows-driver wintun

It means, of course, that you do use TUN and not TAP (I made this shift in my network). WinTun driver is available starting from OpenVPN 2.5.0 AFAIK.

Interestingly, some Windows clients are still on old 2.4 and TAP and have no problems.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now


×
×
  • Create New...