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

     

  • 0 in reply to Mr.Roboto

    Hi,

     

    I'm relation the same problems with XG330 (SFOS 17.5.8 MR-8).

    Is there any bug issues still open ?

     

    Thank you