Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 6 subscribers
  • Views 18255 views
  • Users 0 members are here
Options
Suggested
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

Teamviewer Connections Blocked In Proxy Standard Mode

Philipp N.

Hi community,

last week our Teamviewer connections suddenly stopped working from one day to the other. After hours of searching the source of the issue, I finally reached the point where I can tell it is caused by the webfilter of our SG230 UTM 9.510-5. Following behaviour:

- proxy in standard mode
- webfilter log shows 504 errors with timeouts while trying to reach ping3.teamviewer.com
- tcpdump on client shows the the connection gets interrupted and tries to retransmit the initial packet several times
- firewall log shows blocked packages from client to teamviewer server (I assume the retransmit packages get blocked because they do not pass thru the webfilter but over 443)

If I switch to transparent mode and add the destination host to the skip list, the teamviewer connections start working again.

So my question is: how can I teach the SG in transparent mode to do the "same" it does with the hosts in the skip list in transparent mode?



This thread was automatically locked due to age.
  • 0

    Do you have the following Exception?

    Teamviewer Remote Access 
    Skipping: Sandstorm / SSL scanning
    Matching these URLs: ^https?://(?:[A-Za-z0-9-]+\.)+teamviewer\.com/?

    If that doesn't work in Standard mode, you must skip *.teamviewer.com in 'Proxy Settings' in your browser.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Bob,

    first things first, thank you very much for spending your time for help and answering our questions here. I realen appreciate the effort, I am doing the same for network monitoring. :D

    Yes I have this exeption and no, this proxy setting does not work.

    I also played around a lot with web filtering options, settings, website tagging, etc. Without any success...  well, at some point I got rid of webfilter and firewall log entries, but the connection still die not work.

  • 0 in reply to Philipp N.

    Do you have an FQDN in 'Address' and *.teamviewer.com in 'Exceptions'?  If you do that, your browser should skip the Proxy in Standard mode.  The 'Transparent Mode Skiplist' does not apply in Standard Mode.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    I tried your suggestion, but it does not work.

    What I forgot to mention is, that our firewall does not connect to the internet directly. Because we are in a governmental network (called "KDN"), our SG forwards http/s traffic to a parent web proxy. That's why the settings on client side do not have any effect I guess. But: skipping our proxy on client side by entering the KDN proxy directly to the proxy settings does not work either.

    If I eliminate our SG from the equation by connecting a client directly to the KDN switch, teamviewer connections start working again.

    So:

    - no SG -> works
    - SG transparent with skiplist -> works
    - SG standard mode -> does not work

  • 0 in reply to Philipp N.

    With the browser's 'LAN Settings' properly configured, it will work in Standard mode, Philipp.  That causes the browser to skip the Standard Proxy.  For my use of TeamViewer, I don't need to skip the Proxy as the Exception noted above solves the problem for me.  I don't know of any other needed configuration, but it has been several years...  You could check the Web Filtering log file to see what's getting tripped up.  If you do, please post back here to let us know.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Phillip,

    I agree with Bob, defining an exception should have the connection not traveling through proxy. With that configuration it is clear the reason is not UTM related if something is in the proxy logs.

    Maybe one thing which has sometimes crossed my way. Do you use static proxy settings on the client? sometimes an application doesn’t play well with wpad & co.

    Best

    Alex

    -

  • 0 in reply to Alexander Busch

    I know, Teamviewer has some wired connections in it. 

    So basically dumped Teamviewer 12 (i guess) couple of month ago.

    They connect via teamviewer.com and start to use http calls on a ip, which is wired for me. They have hardcoded IP addresses in their calls to access the internet. 

    Could be already fixed but wanted to share my thoughts about this. 

    __________________________________________________________________________________________________________________

  • 0 in reply to BAlfson

    Tools like TeamViewer need a session from the desktop device.   The whole purpose of Standard Mode is to create the session from the UTM device.   So the technologies are fundamentally incompatible.   You need to exclude teamviewer.com from your proxy script rather than at the UTM level.

    Also like most remote access solutions, TeamViewer uses two sessions, one on https for authentication, and one on  port 5938 for the actual session.   As others have noted, the second session uses an IP address instead of a name, and it chooses from servers all over the world.   So Country Blocking can cause problems as well.

    I have Transparent Mode enabled as well as Standard mode, so the Standard Mode bypass still hits the webfilter in transparent mode, but transparent mode only affects the port 443 session.   Then I have a rule to override country blocking for designated source addresses connecting to port 5938.  

  • 0 in reply to BAlfson

    A few days ago it suddenly started working again. Probably wasn't an issue caused by the firewall. Probably a couple of problems between our government net and some teamviewer servers. This answer of Bob probably would fit best as answer if it have not been a problem caused by "external" issues.

    Thanks all

Unfiltered HTML