Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 15 replies
  • Subscribers 27 subscribers
  • Views 7131 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 17.5, gotomeeting, and chrome...having lots of issues.

Paul Schwegler

I have an issue where having the SSL inspection option turned on for malware filtering is causing app.gotomeeting.com URLs to fail to load. I turn off SSL inspection, the meeting loads. I HAVE added exceptions for gotmeeting.com, citrix.com, etc, but it does not make a difference. I look at the logs and there is no blocked traffic from that computer. I have tried multiple different options in the malware settings, Avira vs Sophos, allowing traffic to pass on malware scan failure, Real-time vs batch, etc...nothing makes a difference. 

Now, what I have noticed is that when launching a link through chrome, it is redirected to app.gotomeeting.com which is a web application. When opening the link in edge, it defaults to global.gotomeeting.com which does work fine. It's like the chrome web app is seeing that we are performing inspection and flips out even though the sophos is supposed to NOT inspect traffic for exceptions. Has anyone else seen this or can replicate it? Is there anyway to make an exception that actually works?



This thread was automatically locked due to age.
  • 0 in reply to Paul Schwegler

    So it isn't a URL filtering issue, can we try adding each of the domains listed in that HTML to the HTTPS exceptions? Then testing again?

  • 0 in reply to MasterRoshi

    I added a few more domains, the rules for bypassing SSL inspection are now:

    ^([A-Za-z0-9.-]*\.)?jsdelivr\.com/?
    ^([A-Za-z0-9.-]*\.)?joingotomeeting\.com/?
    ^([A-Za-z0-9.-]*\.)?gotomeeting\.com/?
    ^([A-Za-z0-9.-]*\.)?citrixonline\.com/?
    ^([A-Za-z0-9.-]*\.)?qualtrics\.com/?
    ^([A-Za-z0-9.-]*\.)?citrix\.com/?
    ^([A-Za-z0-9.-]*\.)?gotomeet\.me/?
    ^([A-Za-z0-9.-]*\.)?gotomeet\.at/?
    ^([A-Za-z0-9.-]*\.)?openvoice\.com/?
    ^([A-Za-z0-9.-]*\.)?getgo\.com/?
    ^([A-Za-z0-9.-]*\.)?goto-rtc\.com/?
    ^([A-Za-z0-9.-]*\.)?cloudfront\.net/?

    Note, I added CloudFront even since it was listed in the headers of the home.html. But, I'm not crazy about bypassing all of CloudFront!

    All that being said, still failing :(

  • 0 in reply to Paul Schwegler

    Can you try adding enable-javascript.com and the google domains as well as a test?

    Last thing I would check is if pharming protection is enabled. Try disabling that as well. 

    Do you see anything in the IPS/APP log for this source IP?

  • 0 in reply to MasterRoshi
    So the 403 is basically it complaining you don't have javascript enabled.  Which probably means it is doing some detection which is failing.  That could be an underlying issue, or it could be unrelated.
    A few suggestions, in order of usefulness.
    1) The F12 Developer tools should give you a bunch of information, but you can get more by running WireShark on the computer and looking at the actual packets.  Look for drops and especially for incomplete SSL handshakes.
    2) Close all instances of Chrome.  Start Chrome with the following command:
    "C:\Users\michaeldunn\AppData\Local\Google\Chrome SxS\Application\chrome.exe" --ignore-certificate-errors
    You should be a bar at the top warning you about unsupported option - if you do not, make sure Chrome is fully quit before starting it like this.  This will make Chrome not care about any certificate issues.  See if it works then.  If it does, quite Chrome (make sure it closes connections so that the proxy logs) and then take a look at the web filter log and see if there are any domains that it is going to that you did not have in your exception.
    3)
    Add the following exception:
    .*\.com
    Now try it with the big hammer exception.  If it works, see if you can modify it to narrow it down.
    4)
    In WebAdmin, start the Log Viewer.  Click the icon to switch to detailed view.  Select only the Web Filter log.  While it is in its broken loop, watch the web log.  Anything interesting?  You can also post it here.  Note that if the client starts an SSL connection but never completes the handshake (eg because it does not like the certificate) it will not print anything here.
     
     
    Actually I had one more thought before any of that.  In Chrome go to chrome://extensions/  Temporarily disable all extensions, and try.
  • 0 in reply to Michael Dunn

    So...I am bringing this thread back to life because this problem is still happening. We worked around it for a bit by using edge, but now that it is chrome based, this is broken again. I tried adding the exceptions for enable-javascript.com, and looked through the GUI log to find another URL that was being used, launchdarkly.com and added that too. No change. When I added the .*\.com exception as Michael Dunn proposed, it worked! However, I am not sure how to narrow it down from that...and I obviously can't leave that in place. 

    So, I installed Wireshark and ran a capture when the .*\.com rule was disabled and one when it was enabled. I looked through the captures, but my limited knowledge of Wireshark came up short...I just can't find an appreciable difference that I can use to figure this out. I saved the captures, so if someone is willing to look at them, I can send them out to a trusted party. 

    It seems to be an issue with the gotomeeting app itself in that even if I close chrome, the app is still open, and it still fails. This has to be some kind of traffic modification that the sophos is doing that the app doesn't like...I just can't find anything in any log that would point me in the right direction...Does no one else have this issue with SSL inspection and GoToMeeting???