Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 19 replies
  • Subscribers 30 subscribers
  • Views 21659 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

XG is blocking TeamViewer

Mr.Roboto

Hi, I've got a strange problem. A new deployed XG is "blocking" TeamViewer to connect to a remote node. 

Team Viewer says "could not connect to partner". The old UTM works fine. 

I already made a  web/policy exeption and also for ATP.

 

EDIT: The clients using the XG as proxy via 3128, the teamviewer ports are in the allowed destination ports.

This is the log from TeamViewer:

 

2018/08/31 10:01:03.215 23772 20788 G1 Trying connection to 1045613922, mode = 1
2018/08/31 10:01:03.241 5644 6572 S0 Activating Router carrier
2018/08/31 10:01:03.241 5644 6572 S0 CProcessCommandHandlerMasterConnect[437]::CreateMasterConnect(): master13.teamviewer.com:443, Connection 455, proxy='192.168.xxx.xxx'
2018/08/31 10:01:03.272 5644 5920 S0 CProcessCommandHandlerMasterConnect[437]::HandleMasterConnect(): Sending MasterCommand client=TV&connectionmode=1&f=RequestRoute2&homeserver=&ic=512963701&id=370095772&id1=370095772&id2=1045613922&licensedremoteaccesstypes=0&mid=v4c4c4544005436108051c3c04f4c4832a44cc84f64eb7a9c8b3c505ae621be3cd36e78fadda3<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~0dd0c5b4e712d7cef7750d93b4e6b006&midv=2&v=13.2.14327
2018/08/31 10:01:03.350 5644 5920 S0 CProcessCommandHandlerMasterConnect[437]::ReceivedMasterResponse(): Received MasterCommand CONNECT@62.138.209.142_0_128000_1611138130_1045613922_31204__1_0_16778176_128000_16778176:128000;2147483647:1280000;4:640000_2013265791_2013265791_DE-CGN-PLS-R006.teamviewer.com_f///d/3//f/vAA==_f///d/3//f/vAA==
2018/08/31 10:01:03.350 5644 5920 S0! TcpCarrierBase[437]::SendCompleteQueue(): No Connections, Type_Tcp, Dir_Outgoing, Ending 0, SendQueue 1, CurrentSendQueue 0, SendCache 0
2018/08/31 10:01:03.350 5644 5920 S0 Activating Router carrier
2018/08/31 10:01:03.350 5644 5920 S0 CommandHandlerRouting[438]::CreateActiveSession(): outgoing session to 1045613922 via DE-CGN-PLS-R006.teamviewer.com, protocol Port443
2018/08/31 10:01:03.351 5644 6040 S0 Carrier[437]::EndCarrierInternal(): ClientID: 0 SupportsEndSession: 0, SupportsCCmd2: 0, SessionType_MasterConnect, SendQueue: 0 (4 Bytes), CurrentSendQueue: 0 (0 Bytes), SendCache: 0 (0 Bytes)
2018/08/31 10:01:03.394 5644 5920 S0!! HttpRequestImpl::CurlFinished(): curl request failed: Failure when receiving data from the peer (56), Received HTTP code 502 from proxy after CONNECT
2018/08/31 10:01:03.394 5644 5920 S0!! Port443Connection::ConnectInternal: failed with HTTP status code = 502
2018/08/31 10:01:03.394 5644 6364 S0 Activating Router carrier
2018/08/31 10:01:03.394 23772 21104 G1 LoginOutgoing: Terminated by client
2018/08/31 10:01:03.394 5644 6776 S0 CGatewaySession[438]::EndSession(): Session to 1045613922 ended. Estimated capacity=0kBit/s, Latency=0ms
2018/08/31 10:01:03.394 5644 6364 S0 CProcessCommandHandlerMasterConnect[439]::CreateMasterConnect(): master13.teamviewer.com:443, Connection 457, proxy='192.168.xxx.xxx'
2018/08/31 10:01:03.395 23772 21912 G1!! LoginOutgoing: ConnectFinished - wrong state
2018/08/31 10:01:03.399 5644 6284 S0 CProcessCommandHandlerMasterConnect[439]::HandleMasterConnect(): Sending MasterCommand actionid=1611138130&f=ServerUnavailable&ic=512963701&id=370095772&mid=v4c4c4544005436108051c3c04f4c4832a44cc84f64eb7a9c8b3c505ae621be3cd36e78fadda3<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~0dd0c5b4e712d7cef7750d93b4e6b006&midv=2&serverip=DE-CGN-PLS-R006.teamviewer.com&v=13.2.14327
2018/08/31 10:01:03.446 5644 6284 S0 CProcessCommandHandlerMasterConnect[439]::ReceivedMasterResponse(): Received MasterCommand OK
2018/08/31 10:01:03.446 5644 6284 S0! TcpCarrierBase[439]::SendCompleteQueue(): No Connections, Type_Tcp, Dir_Outgoing, Ending 0, SendQueue 1, CurrentSendQueue 0, SendCache 0
2018/08/31 10:01:03.446 5644 6284 S0 Carrier[439]::EndCarrierInternal(): ClientID: 0 SupportsEndSession: 0, SupportsCCmd2: 0, SessionType_MasterConnect, SendQueue: 0 (4 Bytes), CurrentSendQueue: 0 (0 Bytes), SendCache: 0 (0 Bytes)



This thread was automatically locked due to age.
Parents
  • 0

    Hi,

    Please post the rule and a log entry from log viewer when you try to connect.

    Ian

  • 0 in reply to rfcat_vk

    Thats the thing, I can't find nothing blocked in the logs.

    The rule is simple, any any via proxy @ 3128.

     

    I'll test this in lab next week.

  • 0 in reply to Mr.Roboto

    Hi,

    I was hoping you would post a copy of the rule from the XG in expanded format.

    Ian

  • 0 in reply to rfcat_vk

    You mean so:

    Rule

    Apply "Block very high risk (Risk Level 5) apps" app filter, "No Ads or Explicit Content" web filter, IPS, for "Clientless Open Group " and " internet(UG)" groups, when in "LAN" zone, and coming from any network, decrypt and scan for malware then check with Sandstorm

    Source & Schedule
    LAN

    Source Networks and Devices : Any
    During Scheduled Time : All the Time

    Destination & Services
    WAN

    Destination Networks : Any
    Services : HTTPProxy

    Identity

    Clientless Open Group,internet

  • 0 in reply to Mr.Roboto

    Good  morning,

    I was hoping for a pretty picture but that will do. You will need to create an exception to bypass the proxy and application rules. Teamviewer objects to proxies. Either that or you create another rule at the top of your rule list for teamviewer not specifically using the proxy.

    Ian

  • 0 in reply to Mr.Roboto

    I had the same issue on mine.

    When users were logged off the PC's were not authenticating and so Teamviewer stopped.

    I crated a Firewall Rule to allow *.teamviewer.com and port 5938 access to the internets above the default blocking rule.

  • 0 in reply to M8ey

    Thank you for the help to solve the problem.
    The clients are using the XG only as proxy-server. There is no routing via the XG into the internet.
    And there is only one rule: LAN any -> WAN any Port 3128
    The required ports are set up and there is an exeption for *.teamviewer.com for scanning, policy and authentication.

  • 0 in reply to Mr.Roboto

    Does the log viewer show anything blocked?

    Maybe take a screen shot of your firewall rule and post it to see. Mine is like this:

     

     

    Maybe also check under Web / General Settings / Web Proxy Configuration and allow the port in Allowed Destination ports

Reply
  • 0 in reply to Mr.Roboto

    Does the log viewer show anything blocked?

    Maybe take a screen shot of your firewall rule and post it to see. Mine is like this:

     

     

    Maybe also check under Web / General Settings / Web Proxy Configuration and allow the port in Allowed Destination ports

Children
  • 0 in reply to M8ey

    Hi,

     

    your screenshot shows a rule for direct internet access for teamviewer.

    Our customer can access the internet only via the proxy :/

     

    Iam working on that.

  • 0 in reply to Mr.Roboto

    Can you show us a dump of those connections? 

    Looks like the connections gets killed because of the HTTP502.

    https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

    So i assume teamviewer is building up the connection but the correct proxy ports are not in place. 

    You could use wireshark to dump the connection to check out, what is happening on the client. 

  • 0 in reply to LuCar Toni

    has anyone found a solution in the meantime? i haven't been able to do a Wireshark Trace yet.

  • 0 in reply to Mr.Roboto

    Even after hours of testing I can't figure out the exakt problem. The TeamViewer receives a 502 status from the XG proxy-service.
    At the moment at SFOS 17.0.6-MR6 this behavior does not exist.

     

    EDIT:
    So I finished testing with a result but no solution :(
    Testing was done with a fresh installed XG, Win7 and Win10 desktops and a separate DSL line.
    There were no changed made in teamviewer or inside the XG, only the firmware upgrade to 17.5.1. I can reproduce this while switching between these two firmware's.

    Teamviewer connections are working fine till 17.1.4 (the latest 17.1 firmware I remember).
    Since 17.5.1 TV connections are not working. So I looked in the TV log and found that the proxy, the Sophos XG, returned a HTTP status of 502.
    I searched the XG logfiles, first the normal logs in the "log viewer". But I can't found anything. Next in the internal logfiles via console I also found anything.
    Logging is still a crappy thing at XG.

    So I run a WireShark trace and found out that the TV is not lying, with SFOS 17.5.x the XG sends a HTTP 502 back to the client.

    If I now try to open the URI in a normal browser the result is the same.
    DE-DUS-PLS-R008.teamviewer.com:443 -> HTTP 502

    Again with 17.1.x HTTP 200 :=).

    I asked myself is nobody using TeamViewer or a XG with 17.5.
    So I write an ticket and hope for help.

  • 0 in reply to LuCar Toni

    Good morning,

    Ticket is open but without any response....arghhh.

    Any kind of help is welcome :)

  • 0 in reply to Mr.Roboto

    Any kind of help is welcome :)

     

    Hey there,

     

    I added this rule in my Firewall Rules somewhere close to the top:

     

     

    So now it bypasses the other stuff and TV isn't blocked even if the user is not on etc.

    Have you tried something like this?

  • 0 in reply to M8ey

    Thank you so much :)

    The problem is that these customer use the XG only a Proxy at port 3128 to access the internet.
    There is no routing to the WAN at the clients.

  • 0 in reply to Mr.Roboto

    Is the XG the default Gateway?

     

    I added this rule when I used 3128 as well and it fixed it as its a Proxy bypass- maybe try it?

    Also did you add port 5938 into the Web / General Settings / Allowed Destination ports? Not sure if that will help but.....  :-)

  • 0 in reply to M8ey

    No, the XG is only used as proxy-server. The default-gateway is only for internal routing.
    5938 is normally in the allowed range per default.

    For locations where the XG is the default-gw I'am using a rule with FQDN-Host *.teamviewer.com and port 5938.

    The bad thing is that many customers where using a old proxy for Team-Viewer. And if they're migrating more and more applications to the new XG we figured out this problem.

    It's affecting every installation where the XG is not the default GW and at the moment we also stopped the UTM>XG migration.
    At the moment about 30 installations stranded with TeamViewer.

  • +1 in reply to Mr.Roboto

    Got an answer from support.

    It's a known bug (NC-44609) and get fixed in SFOS 17.5 MR-6.