Jump to content

ESET endpoint AV causing Google Meet Network error


Recommended Posts

You can also try the Edge Chromium browser assuming that you have that installed on your Win 10 build.

I also have an idea on what might be going on in regards to Firefox. Appears Google Meet is performig root CA cert. thumbprint validation to detect any MITM activity. Also assumed is this Meet web site cert. is chained to one of the four Google Trust root certificates. Firefox root Authorities contains these four Google Trust root certificates.  However, Firefox now defers to the Windows root CA certificate which does not contain these Google Trust root certificates.  This facilitates Eset SSL/TLS protocol scanning MITM activity but busts Google Meet communication.

Link to post
Share on other sites
4 hours ago, itman said:

Did you try using Google Meet via Chrome browser as @Marcos suggested? To test if there are no issues, you can set the *.goggle.com certificate in Eset certificate exclusions from "Ignore" to "Auto" prior to opening the Chrome browser.

Google Chrome browser is all we use as that is a requirement of the local school district to guarantee compatibility. I have not tried using Firefox or Edge Chromium.

Link to post
Share on other sites
10 hours ago, Marcos said:

I would add that I was able to present via Google Meet in Chrome without issues and with no exceptions created.

Did you actually join or start a Meet session?

I believe the issue is once a session is established is when the disconnection occurs. This in itself is odd. You would think that if it was a certificate issue, you couldn't establish a Meet session in the first place.

Link to post
Share on other sites

There is also a possible Google Advanced Protection Program element that could be in play here if that is applicable:

Quote

Advanced Protection Program—Meet users can enroll in Google’s Advanced Protection Program (APP). APP provides our strongest protections available against phishing and account hijacking, is specifically designed for the highest-risk accounts, and we’ve yet to see people successfully phished if they participate in APP, even if they are repeatedly targeted. Learn more

Link to post
Share on other sites

@Marcos, Google Meet has some network requirements listed here: https://support.google.com/a/answer/1279090 .

I didn't see anything that "smacked me in the face" other than it does use WebRTC.  Now I blocked WebRTC in Firefox via uBlock Origin option. Don't believe Eset monitors anything in regard to WebRTC?

Link to post
Share on other sites
1 hour ago, itman said:

There is also a possible Google Advanced Protection Program element that could be in play here if that is applicable:

Just using free google account on this end with no additional bells n' whistles. 

Quote

 

Did you actually join or start a Meet session?

I believe the issue is once a session is established is when the disconnection occurs. This in itself is odd. You would think that if it was a certificate issue, you couldn't establish a Meet session in the first place.

 

Correct. Its after starting the Meet session. I can start a meeting and be sitting in it alone and it just abruptly end with "A Network Error has occurred". It never takes long to error out.

Edited by denzilla
Link to post
Share on other sites

Also of note is the following excerpt from the Meet network requirements link I previously posted:

Quote

The core Google services need full network access. If there are restrictions or filtering policies for users on your network, give network access to the following URI patterns using port 443.

Note: If you're using Meet on Chromebox for Meetings devices, please also review the networking requirements for ChromeOS.

For web traffic, APIs, feedback reports, logs upload, and connectivity setup patterns:

  • https://*.google.com/*
  • https://*.googleapis.com/*
  • https://*.gstatic.com/* 
  • https://*.googleusercontent.com/*

For live streaming patterns:

  • https://*.googlevideo.com/*
  • https://*.youtube-nocookie.com/*
  • https://*.ytimg.com/*

 

You could add all the above https domains as shown to the Eset Context Scanning exclusion URL list. Then set the existing Eset Google certificate exclusion from Ignore to Auto. Then test if this does the trick.

If it doesn't help, make sure you delete these from the Eset Context Scanning exclusion URL list. Then reset the Eset Google certificate exclusion back to Ignore.

Edited by itman
Link to post
Share on other sites

I believe the problem is now resolved by creating a rule in our firewall allowing outbound UDP ports to 19302–19309 per the Google article: https://support.google.com/a/answer/1279090

Backed out all the changes made in ESET and its still working. 

Guess the content inspection being done by ESET and our firewall simultaneously was causing the problem. Google meet could deal with one, but not both at the same time. 

Sorry to bother everyone. I sincerely thought this was an ESET issue since the problem disappeared after uninstalling it.

Link to post
Share on other sites
13 hours ago, denzilla said:

Guess the content inspection being done by ESET and our firewall simultaneously was causing the problem. Google meet could deal with one, but not both at the same time. 

Believe I know the culprit and not being a Chrome using myself, it never dawned on me:

Quote

Nowadays HTTPS can run above either TCP or UDP.

The new "QUIC" protocol aims to replace multiple TCP connections with one multiplexed UDP connection, and hence can handle SSL and HTTPS:

HTTPS → SSL → QUIC flow → UDP → IP

QUIC was originally developped in 2012 by Google and is undergoing IETF review. For more details, see Wikipedia.

https://serverfault.com/questions/98951/does-https-use-tcp-or-udp

There is also a WebRTC element involved since this is what Google Meet is using the referenced UDP ports for.

It is still a bit "murkey" though if Google Meet was actually sending HTTPS traffic using UDP and ports 19302–19309. Also of note is if UDP ports are not accessible:

Quote

Note: TCP will be used if these UDP ports are blocked.

 

Edited by itman
Link to post
Share on other sites

Creating the rule for the UDP ports bypasses our webfilter proxies. I think the proxy was causing issues and the google support doc specifically mentioned proxies as a no no. I figured at the time that they weren't the issue since the meetings would start.

I'm learning as I go and definitely not on your level, itman.

Edited by denzilla
Link to post
Share on other sites
2 hours ago, denzilla said:

I think the proxy was causing issues and the google support doc specifically mentioned proxies as a no no.

👍

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...