This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

UTM dropping traffic from PCs with Teamviewer Host(?)

At work, we use Teamviewer (version 10 currently) for remote support.  All of our end-user PCs have Teamviewer Host installed, and the support staff's PCs have the full Teamviewer application.  

Last Thursday morning I started getting reports of intermittent loss in network connectivity.  After ruling out switch problems, I dug a little deeper.  The outage only affected traffic attempting to traverse the UTM--traffic to and from the local subnet was not affected.  The outages would last only a few minutes, then the problem would magically correct itself.  

Prior to these outages, it had been probably two weeks since I had made any configuration changes on the UTM, so I wasn't sure why this was happening.  There was a lot of troubleshooting, several UTM reboots, disabling security features, reviewing firewall rules, making sure IPS wasn't enabled, etc.  

I contacted Sophos support, who seemed to think the problems were due to CPU spikes (there had been only one in the last 24 hours).  He created some sort of cron job that was supposed to more accurately monitor CPU spikes and said to email him back if it happened again.

Thursday evening around 5 things seemed to have settled down, so I thought maybe one of the dozen or so desperate configuration changes I had made that day fixed the problem.

Friday morning it started happening again.

I did more troubleshooting, more log monitoring, fired up Wireshark a few times--I never could figure out why this was happening until about 4:30 Friday afternoon.  I got a support call from a user on my subnet, so I opened up Teamviewer to establish a remote control session.  Coincidentally, at the time this happened, I had an SSH session open with the UTM, I was running a continuous ping in a command window to a host on another subnet, and I had an RDP session open to a server on my local subnet.  Teamviewer contacted the user's PC, started going through the authentication process, and boom--my SSH session to the UTM was disconnected, and my pings started failing.  The user said her network stopped working at the same time.  My RDP session stayed open, however, and its traffic was still able to traverse the UTM.  I closed Teamviewer, and a few minutes later the UTM resumed passing traffic from both my PC and the user's PC.  I tried it again--the same thing happened.

It was at this moment that I realized that the UTM was dropping all traffic from PCs which it observed communicating with the Teamviewer servers.  

I repeated this process with two separate PCs and got the same result.

Teamviewer Host periodically "phones home" to their servers, so that explains the periodic loss of the users' connectivity.  

I think a pattern update last Thursday is the cause of this problem.

I have sent all of this information to support, but they haven't responded.  Has anyone else seen this?



This thread was automatically locked due to age.
Parents
  • Has there been any actual resolution to this because it did not resolve on its own for me.  I had the same issue that started months ago min Jan 2016.  Due to many high priority items this took a back seat.  I am now up against a wall.  I have 3 offices 2 of which are behind a Sophos SG115 UTM9.  Prior to implementing we used Cisco ASA with no issues.  I have tested this locally to be sure the Sophos was the issue and it is.  If I change the gateway to use the Sophos I lose access to those machines via TeamViewer.  I have turned off IPS, I have added firewall rules and nothing works.  This can cause nightmares for helpdesk as we can no longer access the machines to offer assistance.  Any help to resolve is greatly appreciated.  

  • What do you get from #1 in

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Reply Children
  • Thanks but Ive got nothing.  The weird part is that I have 1 user right now that is visible behind the Sophos and the others aren't.  This doesn't make any sense to me.  How can 1 pc with TV be allowed and the rest be denied or cut off.  I see nothing in the logs.  The setup is this: ThinClients with internet access live in the remote offices.  These are behind the Sophos which has an active VPN tunnel back to a Sophos in our main office(where I am). Those thinclients connect to a citrix receiver and each user logs onto a VM also located in our main office.  TV allows us to connect to their machines to offer assistance with connection issues to those VMs.  Upon initial installation of the Sophos all was fine.  Then 1 day no more access over TV with the exception of 1 or 2 lone machines from time to time. 

  • Did you check both the main- and branch-office logs?  If there's nothing in those logs, this must be a routing issue.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Not sure if you already found a fix for this or if it's related. I was having issues connecting to Teamviewer clients after enabling the "Decrypt and scan" option (Web Filtering > HTTPS > HTTPS Scan Settings) in a Transparent Mode filter profile. The issue would go away if the "URL filtering only" was enable, but that's not sufficient in today's environment.

    The error messages on the Web Filtering logs were showing as: 


    name="web request warned, forbidden mimetype detected" action="warn" method="GET" ... url="ping3.teamviewer.com/din.aspx .... application="teamview" app-id="584" content-type="application/octet-stream"

    Also, 
     
    name="web request warned, forbidden mimetype detected" action="warn" method="GET" ... url="master9.teamviewer.com/din.aspx ... application="teamview" app-id="584" content-type="application/octet-stream"

    I did setup a MIME Type warning for application/octet-stream in this profile's Policy Filter Action. So that info error was expected, however after removing that MIME Type warning from the filter action the issue persisted. 

    I created a Filter Exception as follow:

    Teamviewer [Allow Teamviewer SSL traffic.]
    Skipping: Caching / SSL scanning / Do not display download/scan progress page

     

    Matching these URLs: ^https?://[A-Za-z0-9.-]*\.teamviewer\.com/

     


    To find what was breaking the connection, I initially enabled all skipping options, and then started narrowing down until I found Teamviewer doesn't like its SSL probed. [;)] After that, I enabled to skip caching as well, for good measure.