ESET endpoint AV causing Google Meet Network error

[itman 1,659]

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.

[denzilla 0]

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.

[itman 1,659]

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.

[itman 1,659]

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

[itman 1,659]

@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?

[denzilla 0]

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 October 17, 2020 by denzilla

[itman 1,659]

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 October 17, 2020 by itman

[denzilla 0]

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.

[itman 1,659]

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 October 19, 2020 by itman

[denzilla 0]

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 October 19, 2020 by denzilla

[itman 1,659]

2 hours ago, denzilla said:

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

👍